linux-kernel - Re: [PATCH 00/23] md/llbitmap: md/md-llbitmap: introduce a new lockless bitmap

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <288be678-990b-86f9-1ffd-858cee18eef3@huaweicloud.com>
Date: Mon, 30 Jun 2025 10:34:37 +0800
From: Yu Kuai <yukuai1@...weicloud.com>
To: Xiao Ni <xni@...hat.com>, Yu Kuai <yukuai1@...weicloud.com>, hch@....de,
 colyli@...nel.org, song@...nel.org
Cc: linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org,
 linux-raid@...r.kernel.org, yi.zhang@...wei.com, yangerkun@...wei.com,
 johnny.chenyi@...wei.com, "yukuai (C)" <yukuai3@...wei.com>
Subject: Re: [PATCH 00/23] md/llbitmap: md/md-llbitmap: introduce a new
 lockless bitmap

Hi,

在 2025/06/30 9:59, Xiao Ni 写道:
> 
> After reading other patches, I want to check if I understand right.
> 
> The first write sets the bitmap bit. The second write which hits the 
> same block (one sector, 512 bits) will call llbitmap_infect_dirty_bits 
> to set all other bits. Then the third write doesn't need to set bitmap 
> bits. If I'm right, the comments above should say only the first two 
> writes have additional overhead?

Yes, for the same bit, it's twice; For different bit in the same block,
it's third, by infect all bits in the block in the second.

  For Reload action, if the bitmap bit is
> NeedSync, the changed status will be x. It can't trigger resync/recovery.

This is not expected, see llbitmap_state_machine(), if old or new state
is need_sync, it will trigger a resync.

c = llbitmap_read(llbitmap, start);
if (c == BitNeedSync)
  need_resync = true;
-> for RELOAD case, need_resync is still set.

state = state_machine[c][action];
if (state == BitNone)
  continue
if (state == BitNeedSync)
  need_resync = true;

> 
> For example:
> 
> cat /sys/block/md127/md/llbitmap/bits
> unwritten 3480
> clean 2
> dirty 0
> need sync 510
> 
> It doesn't do resync after aseembling the array. Does it need to modify 
> the changed status from x to NeedSync?

Can you explain in detail how to reporduce this? Aseembling in my VM is
fine.

Thanks,
Kuai