On Thu, Jun 28, 2018 at 10:30:27PM +0100, Al Viro wrote:
> I'm not saying that blocking on other things is a bug; some of such *are*
> bogus,
> but a lot aren't really broken. What I said is that in a lot of cases we
> really
> have hard "no blocking other than in callback" (and on subsequent passes
> there's
> no callback at all). Which is just about perfect for AIO purposes, so *IF* we
> go for "new method just for AIO, those who don't have it can take a hike", we
> might
> as well indicate that "can take a hike" in some way (be it opt-in or opt-out)
> and
> use straight unchanged ->poll(), with alternative callback.
PS: one way of doing that would be to steal a flag from pt->_key and have
->poll()
instances do an equivalent of
if (flags & LOOKUP_RCU)
return -ECHILD;
we have in a lot of ->d_revalidate() instances for "need to block" case. Only
here they would've returned EPOLLNVAL.
Most of the ->poll() instances wouldn't care at all - they do not block unless
the callback does (and in this case it wouldn't have). Normal poll(2)/select(2)
are completely unaffected. And AIO would just have that bit set in its
poll_table_struct.
The rules for drivers change only in one respect - if your ->poll() is going to
need to block, check poll_requested_events(pt) & EPOLL_ATOMIC and return
EPOLLNVAL
in such case.
