Re: [PULL 17/18] aio-posix: do not nest poll handlers

[Stefan Hajnoczi]

On Thu, May 18, 2023 at 10:13:23AM +0300, Michael Tokarev wrote:
> 17.05.2023 19:51, Kevin Wolf wrote:
> > From: Stefan Hajnoczi <stefanha@redhat.com>
> > 
> > QEMU's event loop supports nesting, which means that event handler
> > functions may themselves call aio_poll(). The condition that triggered a
> > handler must be reset before the nested aio_poll() call, otherwise the
> > same handler will be called and immediately re-enter aio_poll. This
> > leads to an infinite loop and stack exhaustion.
> > 
> > Poll handlers are especially prone to this issue, because they typically
> > reset their condition by finishing the processing of pending work.
> > Unfortunately it is during the processing of pending work that nested
> > aio_poll() calls typically occur and the condition has not yet been
> > reset.
> > 
> > Disable a poll handler during ->io_poll_ready() so that a nested
> > aio_poll() call cannot invoke ->io_poll_ready() again. As a result, the
> > disabled poll handler and its associated fd handler do not run during
> > the nested aio_poll(). Calling aio_set_fd_handler() from inside nested
> > aio_poll() could cause it to run again. If the fd handler is pending
> > inside nested aio_poll(), then it will also run again.
> > 
> > In theory fd handlers can be affected by the same issue, but they are
> > more likely to reset the condition before calling nested aio_poll().
> > 
> > This is a special case and it's somewhat complex, but I don't see a way
> > around it as long as nested aio_poll() is supported.
> > 
> > Buglink: https://bugzilla.redhat.com/show_bug.cgi?id=2186181
> > Fixes: c38270692593 ("block: Mark bdrv_co_io_(un)plug() and callers 
> > GRAPH_RDLOCK")
> 
> Is it not a stable-8.0 material?

Yes.

Stefan

signature.asc
Description: PGP signature