On Thu, May 18, 2023 at 10:13:23AM +0300, Michael Tokarev wrote: > 17.05.2023 19:51, Kevin Wolf wrote: > > From: Stefan Hajnoczi <stefa...@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