> 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.
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
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
* 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
> 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
* 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
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
7 matches
Mail list logo