Re: [PATCH 1/2] epoll: use the waitqueue lock to protect ep->wq

2017-12-14 Thread Christoph Hellwig
> Hm, that reads a bit weirdly. How about: > > The epoll code currently uses the unlocked waitqueue helpers for managing > ep->wq, but instead of holding the waitqueue lock around these calls, it > uses its own ep->lock spinlock. Thanks, fixed.

Re: [PATCH 1/2] epoll: use the waitqueue lock to protect ep->wq

2017-12-14 Thread Christoph Hellwig
On Thu, Dec 07, 2017 at 11:09:11AM -0500, Jason Baron wrote: > On 12/06/2017 06:52 PM, Christoph Hellwig wrote: > > The eoll code currently always uses the unlocked waitqueue helpers for > > ep->wq, but instead of holding the lock inside the waitqueue around these > > calls, as expected by the epol

Re: [PATCH 1/2] epoll: use the waitqueue lock to protect ep->wq

2017-12-07 Thread Jason Baron
On 12/06/2017 06:52 PM, Christoph Hellwig wrote: > The eoll code currently always uses the unlocked waitqueue helpers for > ep->wq, but instead of holding the lock inside the waitqueue around these > calls, as expected by the epoll code uses its own lock. Given that the > waitqueue is not exposed

Re: [PATCH 1/2] epoll: use the waitqueue lock to protect ep->wq

2017-12-06 Thread Ingo Molnar
* Andreas Dilger wrote: > > On Dec 6, 2017, at 17:49, Ingo Molnar wrote: > > > > This exposes some waitqueue internals, but AFAICS the FUSE code already > > does a > > similar trick with fiq->waitq.lock so there's precedent. > > What about waitqueue_lock() and waitqueue_unlock() helpers tha

Re: [PATCH 1/2] epoll: use the waitqueue lock to protect ep->wq

2017-12-06 Thread Andreas Dilger
> On Dec 6, 2017, at 17:49, Ingo Molnar wrote: > > This exposes some waitqueue internals, but AFAICS the FUSE code already does > a > similar trick with fiq->waitq.lock so there's precedent. What about waitqueue_lock() and waitqueue_unlock() helpers that lock and unlock, to avoid exposing the

Re: [PATCH 1/2] epoll: use the waitqueue lock to protect ep->wq

2017-12-06 Thread Ingo Molnar
* Christoph Hellwig wrote: > The eoll code currently always uses the unlocked waitqueue helpers for s/eoll /epoll > ep->wq, but instead of holding the lock inside the waitqueue around these > calls, as expected by the epoll code uses its own lock. Hm, that reads a bit weirdly. How about: T

[PATCH 1/2] epoll: use the waitqueue lock to protect ep->wq

2017-12-06 Thread Christoph Hellwig
The eoll code currently always uses the unlocked waitqueue helpers for ep->wq, but instead of holding the lock inside the waitqueue around these calls, as expected by the epoll code uses its own lock. Given that the waitqueue is not exposed to the rest of the kernel this actually works ok at the m