The Linux Kernel Mailing List
 help / color / mirror / Atom feed
From: Abd-Alrhman Masalkhi <abd.masalkhi@gmail.com>
To: yu kuai <yukuai@fygo.io>,
	song@kernel.org, magiclinan@didiglobal.com, xiao@kernel.org,
	axboe@kernel.dk, john.g.garry@oracle.com,
	martin.petersen@oracle.com, yukuai@fygo.io
Cc: linux-raid@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 4/7] md/raid10: raid10_write_request() drops the barrier before calling
Date: Wed, 24 Jun 2026 10:12:35 +0200	[thread overview]
Message-ID: <m2cxxg1hn0.fsf@gmail.com> (raw)
In-Reply-To: <7239c50c-b257-4179-827a-9facd48e75e1@fygo.io>


Hi Kaui,

On Wed, Jun 24, 2026 at 15:23 +0800, yu kuai wrote:
> Hi,
>
> 在 2026/6/23 15:24, Abd-Alrhman Masalkhi 写道:
>> bio_submit_split_bioset() and reacquires it afterwards. This is
>> unnecessary because bio_submit_split_bioset() does not require
>> releasing the barrier protection.
>
> Why is this safe?
>
> It's possible plug is not enabled in this context, and the allocated new
> aplit bio will be submitted and enter wait_barrier() again. wait_barrier()
> is not supposed to be called recursively. Otherwise deadlock can happend:
>
> t1: sync_thread grab barrier and waiting for nr_pending to be 0 from raise_barrier()
> t2: wait_barrier() first inc nr_pending, then recursive wait_barrier() waiting
> for barrier to be released.
>

raid10_write_request() is only called from the bio submission path and
not from raid10d thread, so we do not re-enter it while already holding
barrier. Therefore, the split bio submitted by bio_submit_split_bioset()
cannot recurse back into wait_barrier() from the same execution path.

The situation is different for reads, where raid10_read_request() will
be called both from the submission path and from raid10d. There,
dropping and reacquiring the barrier protection remains necessary.

>>
>> Remove the redundant allow_barrier()/wait_barrier() pair around
>> bio_submit_split_bioset().
>>
>> Signed-off-by: Abd-Alrhman Masalkhi <abd.masalkhi@gmail.com>
>> ---
>>   drivers/md/raid10.c | 2 --
>>   1 file changed, 2 deletions(-)
>>
>> diff --git a/drivers/md/raid10.c b/drivers/md/raid10.c
>> index 840f0446c231..4bc1d5553ec7 100644
>> --- a/drivers/md/raid10.c
>> +++ b/drivers/md/raid10.c
>> @@ -1493,10 +1493,8 @@ static bool raid10_write_request(struct mddev *mddev, struct bio *bio,
>>   		if (atomic)
>>   			goto err_handle;
>>   
>> -		allow_barrier(conf);
>>   		bio = bio_submit_split_bioset(bio, r10_bio->sectors,
>>   					      &conf->bio_split);
>> -		wait_barrier(conf, false);
>>   		if (!bio) {
>>   			set_bit(R10BIO_Returned, &r10_bio->state);
>>   			goto err_handle;
>
> -- 
> Thanks,
> Kuai

-- 
Best Regards,
Abd-Alrhman

  reply	other threads:[~2026-06-24  8:12 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-23  7:24 [PATCH 0/7] md/raid10: fixes, atomic write handling, and error-path cleanup Abd-Alrhman Masalkhi
2026-06-23  7:24 ` [PATCH 1/7] md/raid10: fix r10bio leak in raid10_write_request() error paths Abd-Alrhman Masalkhi
2026-06-23  7:24 ` [PATCH 2/7] md/raid1: handle atomic writes that require splitting Abd-Alrhman Masalkhi
2026-06-23  8:11   ` John Garry
2026-06-23  8:58     ` Abd-Alrhman Masalkhi
2026-06-23  9:20       ` John Garry
2026-06-23 10:06         ` Abd-Alrhman Masalkhi
2026-06-23 11:38           ` John Garry
2026-06-23 16:11             ` Abd-Alrhman Masalkhi
2026-06-23  7:24 ` [PATCH 3/7] md/raid10: " Abd-Alrhman Masalkhi
2026-06-23  7:24 ` [PATCH 4/7] md/raid10: raid10_write_request() drops the barrier before calling Abd-Alrhman Masalkhi
2026-06-24  7:23   ` yu kuai
2026-06-24  8:12     ` Abd-Alrhman Masalkhi [this message]
2026-06-23  7:24 ` [PATCH 5/7] md/raid10: replace wait loop with wait_event_idle() Abd-Alrhman Masalkhi
2026-06-23  7:24 ` [PATCH 6/7] md/raid10: simplify write request error handling Abd-Alrhman Masalkhi
2026-06-23  7:24 ` [PATCH 7/7] md/raid10: simplify read " Abd-Alrhman Masalkhi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=m2cxxg1hn0.fsf@gmail.com \
    --to=abd.masalkhi@gmail.com \
    --cc=axboe@kernel.dk \
    --cc=john.g.garry@oracle.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-raid@vger.kernel.org \
    --cc=magiclinan@didiglobal.com \
    --cc=martin.petersen@oracle.com \
    --cc=song@kernel.org \
    --cc=xiao@kernel.org \
    --cc=yukuai@fygo.io \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox