summaryrefslogtreecommitdiff
path: root/net/dccp/proto.c
diff options
context:
space:
mode:
authorDavide Libenzi <davidel@xmailserver.org>2006-06-25 05:48:14 -0700
committerLinus Torvalds <torvalds@g5.osdl.org>2006-06-25 10:01:13 -0700
commit3419b23a919698f75944d3e0d97eb1d9c51e4bb6 (patch)
treee1b4b6aad754c6a40137c0a563d823074501da2d /net/dccp/proto.c
parent4ad3bcf3146aa12f41262bb5dd1d9f1778e085b1 (diff)
[PATCH] epoll: use unlocked wqueue operations
A few days ago Arjan signaled a lockdep red flag on epoll locks, and precisely between the epoll's device structure lock (->lock) and the wait queue head lock (->lock). Like I explained in another email, and directly to Arjan, this can't happen in reality because of the explicit check at eventpoll.c:592, that does not allow to drop an epoll fd inside the same epoll fd. Since lockdep is working on per-structure locks, it will never be able to know of policies enforced in other parts of the code. It was decided time ago of having the ability to drop epoll fds inside other epoll fds, that triggers a very trick wakeup operations (due to possibly reentrant callback-driven wakeups) handled by the ep_poll_safewake() function. While looking again at the code though, I noticed that all the operations done on the epoll's main structure wait queue head (->wq) are already protected by the epoll lock (->lock), so that locked-style functions can be used to manipulate the ->wq member. This makes both a lock-acquire save, and lockdep happy. Running totalmess on my dual opteron for a while did not reveal any problem so far: http://www.xmailserver.org/totalmess.c Signed-off-by: Davide Libenzi <davidel@xmailserver.org> Cc: Arjan van de Ven <arjan@linux.intel.com> Cc: Ingo Molnar <mingo@elte.hu> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Diffstat (limited to 'net/dccp/proto.c')
0 files changed, 0 insertions, 0 deletions