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(-)

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);
 }
 
-- 
2.36.1

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