| Message ID | 20220923125227.300202-2-hreitz@redhat.com |
|---|---|
| State | New |
| Headers | show |
| Series | blcok: Start/end drain on correct AioContext | expand |
Am 23.09.2022 um 14:52 hat Hanna Reitz geschrieben: > All implementations of bdrv_child_get_parent_aio_context() are IO_CODE > (or do not mark anything in the case of block jobs), so this too can be > IO_CODE. By the definition of "I/O API functions" in block-io.h, this > is a strict relaxation, as I/O code can be run from both GS and I/O code > arbitrarily. > > Signed-off-by: Hanna Reitz <hreitz@redhat.com> There are three implementations of .get_parent_aio_context in the tree: 1. child_of_bds_get_parent_aio_context() in block.c This is already IO_CODE(), good. 2. child_job_get_parent_aio_context() in blockjob.c This is explicitly marked GLOBAL_STATE_CODE() after Emanuele's series to avoid the AioContext lock in jobs. I suppose it could be made IO_CODE() if it also used JOB_LOCK_GUARD(). 3. blk_root_get_parent_aio_context() in block-backend.c This doesn't have any annotation, but it only calls blk_get_aio_context(), which is IO_CODE. So this one is good, too. Seems we just have a semantic merge conflict with Emanuele's series. Can you rebase on top of my tree? Kevin
diff --git a/block.c b/block.c index bc85f46eed..7f2a9d4df0 100644 --- a/block.c +++ b/block.c @@ -1499,7 +1499,7 @@ const BdrvChildClass child_of_bds = { AioContext *bdrv_child_get_parent_aio_context(BdrvChild *c) { - GLOBAL_STATE_CODE(); + IO_CODE(); return c->klass->get_parent_aio_context(c); }
All implementations of bdrv_child_get_parent_aio_context() are IO_CODE (or do not mark anything in the case of block jobs), so this too can be IO_CODE. By the definition of "I/O API functions" in block-io.h, this is a strict relaxation, as I/O code can be run from both GS and I/O code arbitrarily. Signed-off-by: Hanna Reitz <hreitz@redhat.com> --- block.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)