[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH 1/3] block: bdrv_child_get_parent_aio_context is not GS
From: |
Kevin Wolf |
Subject: |
Re: [PATCH 1/3] block: bdrv_child_get_parent_aio_context is not GS |
Date: |
Fri, 7 Oct 2022 10:44:51 +0200 |
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
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- Re: [PATCH 1/3] block: bdrv_child_get_parent_aio_context is not GS,
Kevin Wolf <=