| Message ID | 20190307000316.31133-2-viro@ZenIV.linux.org.uk |
|---|---|
| State | Not Applicable |
| Delegated to: | David Miller |
| Headers | show |
| Series | [1/8] aio: make sure file is pinned | expand |
On Thu, Mar 07, 2019 at 12:03:10AM +0000, Al Viro wrote: > From: Al Viro <viro@zeniv.linux.org.uk> > > In case of early wakeups, aio_poll() assumes that aio_poll_complete() > has either already happened or is imminent. In that case we do not > want to put iocb on the list of cancellables. However, ignored > wakeups need to be treated as if wakeup has not happened at all. > Trivially fixed by having aio_poll_wake() set ->woken only after > it's committed to taking iocb out of the waitqueue. > > Spotted-by: zhengbin <zhengbin13@huawei.com> > Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> ... and unfortunately it's worse than just that - what both of us have missed is that one could have non-specific wakep + schedule_work + aio_poll_complete_work() rechecking ->poll(), seeing nothing of interest and reinserting into queue. All before vfs_poll() manages to return into aio_poll(). The window is harder to hit, but it's still there, with exact same "failed to add to cancel list" kind of bug if we do hit it ;-/
So, what should we do? On 2019/3/7 10:18, Al Viro wrote: > On Thu, Mar 07, 2019 at 12:03:10AM +0000, Al Viro wrote: >> From: Al Viro <viro@zeniv.linux.org.uk> >> >> In case of early wakeups, aio_poll() assumes that aio_poll_complete() >> has either already happened or is imminent. In that case we do not >> want to put iocb on the list of cancellables. However, ignored >> wakeups need to be treated as if wakeup has not happened at all. >> Trivially fixed by having aio_poll_wake() set ->woken only after >> it's committed to taking iocb out of the waitqueue. >> >> Spotted-by: zhengbin <zhengbin13@huawei.com> >> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> > > ... and unfortunately it's worse than just that - what both of us > have missed is that one could have non-specific wakep + schedule_work + > aio_poll_complete_work() rechecking ->poll(), seeing nothing of > interest and reinserting into queue. All before vfs_poll() manages > to return into aio_poll(). The window is harder to hit, but it's > still there, with exact same "failed to add to cancel list" kind of bug > if we do hit it ;-/ > > . >
diff --git a/fs/aio.c b/fs/aio.c index ea30b78187ed..3a8b894378e0 100644 --- a/fs/aio.c +++ b/fs/aio.c @@ -1668,13 +1668,13 @@ static int aio_poll_wake(struct wait_queue_entry *wait, unsigned mode, int sync, __poll_t mask = key_to_poll(key); unsigned long flags; + /* for instances that support it check for an event match first: */ + if (mask && !(mask & req->events)) + return 0; + req->woken = true; - /* for instances that support it check for an event match first: */ if (mask) { - if (!(mask & req->events)) - return 0; - /* * Try to complete the iocb inline if we can. Use * irqsave/irqrestore because not all filesystems (e.g. fuse)