linux-kernel - Re: [PATCH v5 11/11] md/md-llbitmap: introduce 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: <2b099a1c-ba85-4397-a5b1-47f74777703a@kernel.org>
Date: Sun, 3 Aug 2025 18:33:32 +0800
From: Yu Kuai <yukuai@...nel.org>
To: Li Nan <linan666@...weicloud.com>, Yu Kuai <yukuai1@...weicloud.com>,
 hch@....de, corbet@....net, song@...nel.org, yukuai3@...wei.com,
 agk@...hat.com, snitzer@...nel.org, mpatocka@...hat.com, xni@...hat.com,
 hare@...e.de
Cc: linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org,
 linux-raid@...r.kernel.org, dm-devel@...ts.linux.dev, yi.zhang@...wei.com,
 yangerkun@...wei.com, johnny.chenyi@...wei.com
Subject: Re: [PATCH v5 11/11] md/md-llbitmap: introduce new lockless bitmap



在 2025/8/3 17:48, Li Nan 写道:
>
>
> 在 2025/8/1 15:03, Yu Kuai 写道:
>> From: Yu Kuai <yukuai3@...wei.com>
>>
>> Redundant data is used to enhance data fault tolerance, and the storage
>> method for redundant data vary depending on the RAID levels. And it's
>> important to maintain the consistency of redundant data.
>>
>> Bitmap is used to record which data blocks have been synchronized and 
>> which
>> ones need to be resynchronized or recovered. Each bit in the bitmap
>> represents a segment of data in the array. When a bit is set, it 
>> indicates
>> that the multiple redundant copies of that data segment may not be
>> consistent. Data synchronization can be performed based on the bitmap 
>> after
>> power failure or readding a disk. If there is no bitmap, a full disk
>> synchronization is required.
>
> This is a large patch, I've found a few minor issues so far.
> And I'm still working through it.
>
> [...]
>
>> +    [BitDirty] = {
>> +        [BitmapActionStartwrite]    = BitNone,
>> +        [BitmapActionStartsync]        = BitNone,
>> +        [BitmapActionEndsync]        = BitNone,
>> +        [BitmapActionAbortsync]        = BitNone,
>> +        [BitmapActionReload]        = BitNeedSync,
>> +        [BitmapActionDaemon]        = BitClean,
>> +        [BitmapActionDiscard]        = BitUnwritten,
>> +        [BitmapActionStale]        = BitNeedSync,
>> +    },
>
> Bits becomes BitDirt during degraded remains BitDirty even after 
> recover and re-write. Should we consider adjusting this state 
> transition, or maybe trigger the daemon after the recovery is complete?
We should keep this behavior, otherwise readd a disk will be broken, 
we'll have
do do a full resync for the disk instead.

>
> [...]
>
>> +
>> +static int llbitmap_create(struct mddev *mddev)
>> +{
>> +    struct llbitmap *llbitmap;
>> +    int ret;
>> +
>> +    ret = llbitmap_check_support(mddev);
>> +    if (ret)
>> +        return ret;
>> +
>> +    llbitmap = kzalloc(sizeof(*llbitmap), GFP_KERNEL);
>> +    if (!llbitmap)
>> +        return -ENOMEM;
>> +
>> +    llbitmap->mddev = mddev;
>> +    llbitmap->io_size = bdev_logical_block_size(mddev->gendisk->part0);
>> +    llbitmap->blocks_per_page = PAGE_SIZE / llbitmap->io_size;
>
> logical_block_size can > PAGE_SIZE, blocks_per_page is set to 0 which can
> cause issues in later computations.
>
I do not expect this can happen, it's right large lbs for raw disk is 
supported
now, however, mdraid still handles metadata by page, and should forbid large
lbz while assembling the array for now. mdraid need to switch page to folio
to support large lbs, and this will be done later.

Thanks,
Kuai