Re: [PATCH 3/3] iotests/graph-changes-while-io: New test

[Hanna Reitz]

On 15.02.22 23:22, Eric Blake wrote:
> On Tue, Feb 15, 2022 at 02:57:27PM +0100, Hanna Reitz wrote:
> > Test the following scenario:
> > 1. Some block node (null-co) attached to a user (here: NBD server) that
> >     performs I/O and keeps the node in an I/O thread
> > 2. Repeatedly run blockdev-add/blockdev-del to add/remove an overlay
> >     to/from that node
> >
> > Each blockdev-add triggers bdrv_refresh_limits(), and because
> > blockdev-add runs in the main thread, it does not stop the I/O requests.
> > I/O can thus happen while the limits are refreshed, and when such a
> > request sees a temporarily invalid block limit (e.g. alignment is 0),
> > this may easily crash qemu (or the storage daemon in this case).
> >
> > The block layer needs to ensure that I/O requests to a node are paused
> > while that node's BlockLimits are refreshed.
> >
> > Signed-off-by: Hanna Reitz <hreitz@redhat.com>
> > ---
> >   .../qemu-iotests/tests/graph-changes-while-io | 91 +++++++++++++++++++
> >   .../tests/graph-changes-while-io.out          |  5 +
> >   2 files changed, 96 insertions(+)
> >   create mode 100755 tests/qemu-iotests/tests/graph-changes-while-io
> >   create mode 100644 tests/qemu-iotests/tests/graph-changes-while-io.out
> Reviewed-by: Eric Blake <eblake@redhat.com>
>
> Since we found this with the help of NBD, should I be considering this
> series for my NBD queue, or is there a better block-related maintainer
> queue that it should go through?

Well, we found it by using a guest, it’s just that using a guest in the 
iotests is not quite that great, so we need some other way to induce I/O 
(concurrently to monitor commands).  I could’ve used FUSE, too, but NBD 
is always compiled in, so. :)

In any case, of course I don’t mind who takes this series.  If you want 
to take it, go ahead (and thanks!) – I’ll be sending a v2 to split the 
`try` block in patch 2, though.

Hanna