qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v10 10/21] block/mirror.c: use of job helpers in drivers to a


From: Kevin Wolf
Subject: Re: [PATCH v10 10/21] block/mirror.c: use of job helpers in drivers to avoid TOC/TOU
Date: Thu, 4 Aug 2022 18:35:19 +0200

Am 25.07.2022 um 09:38 hat Emanuele Giuseppe Esposito geschrieben:
> Once job lock is used and aiocontext is removed, mirror has
> to perform job operations under the same critical section,
> using the helpers prepared in previous commit.
> 
> Note: at this stage, job_{lock/unlock} and job lock guard macros
> are *nop*.
> 
> 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>

Can you explain in the commit message what the TOC/TOU case is that this
patch is addressing? It's not obvious to me why you picked exactly these
places to add locking.

> diff --git a/block/mirror.c b/block/mirror.c
> index d8ecb9efa2..b38676e19d 100644
> --- a/block/mirror.c
> +++ b/block/mirror.c
> @@ -654,9 +654,13 @@ static int mirror_exit_common(Job *job)
>      BlockDriverState *target_bs;
>      BlockDriverState *mirror_top_bs;
>      Error *local_err = NULL;
> -    bool abort = job->ret < 0;
> +    bool abort;
>      int ret = 0;
>  
> +    WITH_JOB_LOCK_GUARD() {
> +        abort = job->ret < 0;
> +    }

This is the most mysterious hunk to me. The only thing that should
modify job->ret is the caller of this function anyway, but let's assume
for a moment that another thread could write to it.

Then why is it only important that we hold the lock when we're reading
the value, but not any more when we are actually using it? And what is
the TOC/TOU that this fixes?

Kevin




reply via email to

[Prev in Thread] Current Thread [Next in Thread]