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
next prev parent 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.