* Andreas Dilger <adilger@xxxxxxxxx> wrote: > > On Dec 6, 2017, at 17:49, Ingo Molnar <mingo@xxxxxxxxxx> 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 internals? Or would that add > confusion by making users think they need their own waitqueue locking? Right now there are just two users (FUSE and epoll), and both are well-maintained, essentially core kernel code - I'd rather prefer the readability of explicitly writing out the locking/unlocking pattern. So while it's a mild layering violation, it's also a valid looking optimization. Thanks, Ingo
