|
From: | Vladimir Sementsov-Ogievskiy |
Subject: | Re: [PATCH v8 13/20] jobs: group together API calls under the same job lock |
Date: | Tue, 5 Jul 2022 16:22:41 +0300 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.8.1 |
On 7/5/22 16:01, Emanuele Giuseppe Esposito wrote:
Am 05/07/2022 um 10:17 schrieb Emanuele Giuseppe Esposito:Am 05/07/2022 um 10:14 schrieb Stefan Hajnoczi:On Wed, Jun 29, 2022 at 10:15:31AM -0400, Emanuele Giuseppe Esposito wrote:diff --git a/blockdev.c b/blockdev.c index 71f793c4ab..5b79093155 100644 --- a/blockdev.c +++ b/blockdev.c @@ -150,12 +150,15 @@ void blockdev_mark_auto_del(BlockBackend *blk) return; }- for (job = block_job_next(NULL); job; job = block_job_next(job)) {+ JOB_LOCK_GUARD(); + + for (job = block_job_next_locked(NULL); job; + job = block_job_next_locked(job)) { if (block_job_has_bdrv(job, blk_bs(blk))) { AioContext *aio_context = job->job.aio_context; aio_context_acquire(aio_context);Is there a lock ordering rule for job_mutex and the AioContext lock? I haven't audited the code, but there might be ABBA lock ordering issues.Doesn't really matter here, as lock is nop. To be honest I forgot which one should go first, probably job_lock because the aiocontext lock can be taken and released in callbacks. Should I resend with ordering fixed? Just to have a consistent logicWell actually how do I fix that? I would just add useless additional changes into the diff, because for example in the case below I am not even sure what exactly is the aiocontext protecting. So I guess I'll leave as it is. I will just update the commit message to make sure it is clear that the lock is nop and ordering is mixed.
Yes, I think it's OK. As far as I understand, our final ordering rule is that job_mutex can be taken under aio context lock but not visa-versa. Still, there some aio-context-lock critical sections that are inside job_mutex-lock critical section during the series, just because we don't know the way to avoid it except just merge almost the whole series into one patch. That's why job_mutex is a noop during the series and should become real mutex in the same time with removing these aio-context-lock critical section which breaks the ordering rule. -- Best regards, Vladimir
[Prev in Thread] | Current Thread | [Next in Thread] |