From: "Yu Kuai" <yukuai@fnnas.com>
To: "Xiao Ni" <xni@redhat.com>, <yukuai@fnnas.com>
Cc: <song@kernel.org>, <linan122@huawei.com>, <colyli@fnnas.com>,
<linux-raid@vger.kernel.org>, <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v2 2/5] md/md-llbitmap: raise barrier before state machine transition
Date: Mon, 16 Mar 2026 00:57:08 +0800 [thread overview]
Message-ID: <554d2b1d-e2bc-4723-8862-36961eaa4376@fnnas.com> (raw)
In-Reply-To: <CALTww2-oZrNS8hj+ZnBYmfxOrE6gjwqpvkWex_XCupHPCpyLBw@mail.gmail.com>
Hi,
在 2026/3/9 21:05, Xiao Ni 写道:
> On Mon, Feb 23, 2026 at 10:42 AM Yu Kuai <yukuai@fnnas.com> wrote:
>> Move the barrier raise operation before calling llbitmap_state_machine()
>> in both llbitmap_start_write() and llbitmap_start_discard(). This
>> ensures the barrier is in place before any state transitions occur,
>> preventing potential race conditions where the state machine could
>> complete before the barrier is properly raised.
> Hi Kuai
>
> In the above commit message, race conditions are mentioned. I want to
> give an example here to check if I understand correctly.
>
> raid1 with 2 disks is used in this case.
> T0: Thread A calls llbitmap_state_machine() and state of bit is set to BitDirty
> T1: Thread daemon calls llbitmap_daemon_work() and the state of the
> bit is set to BitClean from BitDirty.
> (Now the state is already wrong)
> T2: Thread A calls llbitmap_raise_barrier to wait Thread daemon
> finishes and go on working
> T3: data is written to disk1 and disk2. A power failure occurs.
> (The data on disk1 and disk2 maybe different, so a data curruption happens)
>
> Does this case belong the race conditions you mentioned in the commit
> message? Can you add one race condtion in your message?
This is not that complex, the reason state machine from fast path can concurrent
with each other is that they both change state to the same state, and obliviously
they can't concurrent from slow path, this is why the barrier is needed. And I
made this mistake in the first version.
>
> Best Regards
> Xiao
>
>> Cc: stable@vger.kernel.org
>> Fixes: 5ab829f1971d ("md/md-llbitmap: introduce new lockless bitmap")
>> Signed-off-by: Yu Kuai <yukuai@fnnas.com>
>> ---
>> drivers/md/md-llbitmap.c | 8 ++++----
>> 1 file changed, 4 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/md/md-llbitmap.c b/drivers/md/md-llbitmap.c
>> index 30d7e36b22c4..5f9e7004e3e3 100644
>> --- a/drivers/md/md-llbitmap.c
>> +++ b/drivers/md/md-llbitmap.c
>> @@ -1070,12 +1070,12 @@ static void llbitmap_start_write(struct mddev *mddev, sector_t offset,
>> int page_start = (start + BITMAP_DATA_OFFSET) >> PAGE_SHIFT;
>> int page_end = (end + BITMAP_DATA_OFFSET) >> PAGE_SHIFT;
>>
>> - llbitmap_state_machine(llbitmap, start, end, BitmapActionStartwrite);
>> -
>> while (page_start <= page_end) {
>> llbitmap_raise_barrier(llbitmap, page_start);
>> page_start++;
>> }
>> +
>> + llbitmap_state_machine(llbitmap, start, end, BitmapActionStartwrite);
>> }
>>
>> static void llbitmap_end_write(struct mddev *mddev, sector_t offset,
>> @@ -1102,12 +1102,12 @@ static void llbitmap_start_discard(struct mddev *mddev, sector_t offset,
>> int page_start = (start + BITMAP_DATA_OFFSET) >> PAGE_SHIFT;
>> int page_end = (end + BITMAP_DATA_OFFSET) >> PAGE_SHIFT;
>>
>> - llbitmap_state_machine(llbitmap, start, end, BitmapActionDiscard);
>> -
>> while (page_start <= page_end) {
>> llbitmap_raise_barrier(llbitmap, page_start);
>> page_start++;
>> }
>> +
>> + llbitmap_state_machine(llbitmap, start, end, BitmapActionDiscard);
>> }
>>
>> static void llbitmap_end_discard(struct mddev *mddev, sector_t offset,
>> --
>> 2.51.0
>>
>>
--
Thansk,
Kuai
next prev parent reply other threads:[~2026-03-15 16:57 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-23 2:40 [PATCH v2 0/5] md/md-llbitmap: fixes and proactive parity building support Yu Kuai
2026-02-23 2:40 ` [PATCH v2 1/5] md/md-llbitmap: skip reading rdevs that are not in_sync Yu Kuai
2026-03-09 7:32 ` Xiao Ni
2026-02-23 2:40 ` [PATCH v2 2/5] md/md-llbitmap: raise barrier before state machine transition Yu Kuai
2026-03-09 13:05 ` Xiao Ni
2026-03-15 16:57 ` Yu Kuai [this message]
2026-02-23 2:40 ` [PATCH v2 3/5] md: add fallback to correct bitmap_ops on version mismatch Yu Kuai
2026-03-10 1:06 ` Xiao Ni
2026-03-15 17:01 ` Yu Kuai
2026-02-23 2:40 ` [PATCH v2 4/5] md/md-llbitmap: add CleanUnwritten state for RAID-5 proactive parity building Yu Kuai
2026-03-13 3:16 ` Xiao Ni
2026-03-17 3:36 ` Yu Kuai
2026-02-23 2:40 ` [PATCH v2 5/5] md/md-llbitmap: optimize initial sync with write_zeroes_unmap support Yu Kuai
2026-03-13 8:12 ` Xiao Ni
2026-03-22 18:30 ` [PATCH v2 0/5] md/md-llbitmap: fixes and proactive parity building support Yu Kuai
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=554d2b1d-e2bc-4723-8862-36961eaa4376@fnnas.com \
--to=yukuai@fnnas.com \
--cc=colyli@fnnas.com \
--cc=linan122@huawei.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-raid@vger.kernel.org \
--cc=song@kernel.org \
--cc=xni@redhat.com \
/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