Hi Davide,

On Fri, Jun 02, 2006 at 04:28:25PM -0700, Davide Libenzi wrote:
> 
> 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

Shouldn't we notice a tiny performance boost by avoiding those useless
locks, or do you consider they are not located in the fast path anyway ?

Regards,
Willy

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/