| Message ID | 20220725073855.76049-13-eesposit@redhat.com |
|---|---|
| State | New |
| Headers | show |
| Series | job: replace AioContext lock with job_mutex | expand |
Am 25.07.2022 um 09:38 hat Emanuele Giuseppe Esposito geschrieben: > We are always using the given bs AioContext, so there is no need > to take the job ones (which is identical anyways). > This also reduces the point we need to check when protecting > job.aio_context field. > > Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru> > Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> > Signed-off-by: Emanuele Giuseppe Esposito <eesposit@redhat.com> I'm not sure against which scenario this is actually protecting. The only reason for not using job.aio_context seems to be if someone else can change the job AioContext in parallel. However, if that is the case (I don't think it is, but for the hypothetical case this patch seems to address), the AioContext is not identical any more and the change is wrong because we actually want things to run in the job AioContext - otherwise accessing the BlockBackend from the job coroutine wouldn't be possible. So I believe the current code expresses how we actually want to use the BlockBackend and the change doesn't only protect nothing, but is even misleading because it implies that the job can work with any AioContext, which is not true. Kevin
Am 05/08/2022 um 10:14 schrieb Kevin Wolf: > Am 25.07.2022 um 09:38 hat Emanuele Giuseppe Esposito geschrieben: >> We are always using the given bs AioContext, so there is no need >> to take the job ones (which is identical anyways). >> This also reduces the point we need to check when protecting >> job.aio_context field. >> >> Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru> >> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> >> Signed-off-by: Emanuele Giuseppe Esposito <eesposit@redhat.com> > > I'm not sure against which scenario this is actually protecting. The > only reason for not using job.aio_context seems to be if someone else > can change the job AioContext in parallel. However, if that is the case > (I don't think it is, but for the hypothetical case this patch seems to > address), the AioContext is not identical any more and the change is > wrong because we actually want things to run in the job AioContext - > otherwise accessing the BlockBackend from the job coroutine wouldn't be > possible. > > So I believe the current code expresses how we actually want to use the > BlockBackend and the change doesn't only protect nothing, but is even > misleading because it implies that the job can work with any AioContext, > which is not true. > > Kevin > Ok, dropped
diff --git a/block/commit.c b/block/commit.c index 851d1c557a..336f799172 100644 --- a/block/commit.c +++ b/block/commit.c @@ -370,7 +370,7 @@ void commit_start(const char *job_id, BlockDriverState *bs, goto fail; } - s->base = blk_new(s->common.job.aio_context, + s->base = blk_new(bdrv_get_aio_context(bs), base_perms, BLK_PERM_CONSISTENT_READ | BLK_PERM_WRITE_UNCHANGED); @@ -382,7 +382,7 @@ void commit_start(const char *job_id, BlockDriverState *bs, s->base_bs = base; /* Required permissions are already taken with block_job_add_bdrv() */ - s->top = blk_new(s->common.job.aio_context, 0, BLK_PERM_ALL); + s->top = blk_new(bdrv_get_aio_context(bs), 0, BLK_PERM_ALL); ret = blk_insert_bs(s->top, top, errp); if (ret < 0) { goto fail; diff --git a/block/mirror.c b/block/mirror.c index b38676e19d..1977e25171 100644 --- a/block/mirror.c +++ b/block/mirror.c @@ -1728,7 +1728,7 @@ static BlockJob *mirror_start_job( goto fail; } - s->target = blk_new(s->common.job.aio_context, + s->target = blk_new(bdrv_get_aio_context(bs), target_perms, target_shared_perms); ret = blk_insert_bs(s->target, target, errp); if (ret < 0) {