On Mon, 05 Apr 2021, Andrew Morton wrote:
Tricky. 339ddb53d373 was merged in December 2019. So do we backport
this fix? Could any userspace code be depending upon the
post-339ddb53d373 behavior?
As with previous trouble caused by this commit, I vote for restoring the
behavior
backporting the fix, basically the equivalent of adding (which was my
intention):
Fixes: 339ddb53d373 ("fs/epoll: remove unnecessary wakeups of nested epoll")
Or do we just leave the post-339ddb53d373 code as-is? Presumably the
issue is very rarely encountered, and changeing it back has its own
risks.
While I also consider this scenario rare (normally new ready events can become
ready and trigger new wakeups), I'm seeing reports in real applications of task
hangs due to this change of semantics. Alternatively, users can update their
code
to timeout in such scenarios, but it is ultimately the kernel's fault.
Furthermore
it hasn't really been all _that_ long since the commit was merged, so I don't
think
it merits a change in behavior.
As for the risks of restoring the behavior, afaict this only fixed a double
wakeup
in an obscure nested epoll scenario, so I'm not too worried there sacrificing
performance for functionality. That said, there are fixes, for example
65759097d80
(epoll: call final ep_events_available() check under the lock) that would
perhaps
be rendered unnecessary.
Thanks,
Davidlohr
