• Davide Libenzi's avatar
    [PATCH] epoll: use unlocked wqueue operations · 3419b23a
    Davide Libenzi authored
    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.cSigned-off-by: default avatarDavide Libenzi <davidel@xmailserver.org>
    Cc: Arjan van de Ven <arjan@linux.intel.com>
    Cc: Ingo Molnar <mingo@elte.hu>
    Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
    Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
    3419b23a
eventpoll.c 44.3 KB