Re: [RFC PATCH v2 0/8] Removal of AioContext lock, bs->parents and ->children: new rwlock

[Stefan Hajnoczi]

On Wed, May 18, 2022 at 06:14:17PM +0200, Kevin Wolf wrote:
> If we want to use drain for locking, we need to make sure that drain
> actually does the job correctly. I see two major problems with it:
> 
> The first one is that drain only covers I/O paths, but we need to
> protect against _anything_ touching block nodes. This might mean a
> massive audit and making sure that everything in QEMU that could
> possibly touch a block node is integrated with drain.

> I think Emanuele has argued before that because writes to the graph only
> happen in the main thread and we believe that currently only I/O
> requests are processed in iothreads, this is safe and we don't actually
> need to audit everything.

I'm interested in the non-I/O code path cases you're thinking about:

Block jobs receive callbacks during drain. They are safe.

Exports:
- The nbd export has code to deal with drain and looks safe.
- vhost-user-blk uses aio_set_fd_handler(is_external=true) for virtqueue
  kick fds but not for the vhost-user UNIX domain socket (not sure if
  that's a problem).
- FUSE uses aio_set_fd_handler(is_external=true) and looks safe.

The monitor runs with the BQL in the main loop and doesn't use
coroutines. It should be safe.

Anything else?

Stefan

signature.asc
Description: PGP signature