linux-kernel - Re: [PATCH RFC v2 00/14] md: 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: <28bb1c35-5f75-4e1c-4b5d-32bcb87050ce@huaweicloud.com>
Date: Fri, 11 Apr 2025 09:36:45 +0800
From: Yu Kuai <yukuai1@...weicloud.com>
To: Christoph Hellwig <hch@....de>, Yu Kuai <yukuai1@...weicloud.com>
Cc: xni@...hat.com, colyli@...nel.org, axboe@...nel.dk, agk@...hat.com,
 snitzer@...nel.org, mpatocka@...hat.com, song@...nel.org,
 linux-block@...r.kernel.org, linux-kernel@...r.kernel.org,
 dm-devel@...ts.linux.dev, linux-raid@...r.kernel.org, yi.zhang@...wei.com,
 yangerkun@...wei.com, kbusch@...nel.org, "yukuai (C)" <yukuai3@...wei.com>
Subject: Re: [PATCH RFC v2 00/14] md: introduce a new lockless bitmap

Hi,

在 2025/04/09 17:40, Christoph Hellwig 写道:
> On Wed, Apr 09, 2025 at 05:27:11PM +0800, Yu Kuai wrote:
>>> For that you'd be much better of just creating your own trivial
>>> file_system_type with an inode fully controlled by your driver
>>> that has a trivial set of address_space ops instead of oddly
>>> mixing with the block layer.
>>
>> Yes, this is exactly what I said implement a new file_operations(and
>> address_space ops), I wanted do this the easy way, just reuse the raw
>> block device ops, this way I just need to implement the submit_bio ops
>> for new hidden disk.
>>
>> I can try with new fs type if we really think this solution is too
>> hacky, however, the code line will be much more. :(
> 
> I don't think it should be much more.  It'll also remove the rather
> unexpected indirection through submit_bio.  Just make sure you use
> iomap for your operations, and implement the submit_io hook.  That
> will also be more efficient than the buffer_head based block ops
> for writes.
> 
>>>
>>> Note that either way I'm not sure using the page cache here is an
>>> all that good idea, as we're at the bottom of the I/O stack and
>>> thus memory allocations can very easily deadlock.
>>
>> Yes, for the page from bitmap, this set do the easy way just read and
>> ping all realted pages while loading the bitmap. For two reasons:
>>
>> 1) We don't need to allocate and read pages from IO path;(In the first
>> RFC version, I'm using a worker to do that).
> 
> You still depend on the worker, which will still deadlock.
> 
>>> What speaks against using your own folios explicitly allocated at
>>> probe time and then just doing manual submit_bio on that?  That's
>>> probably not much more code but a lot more robust.
>>
>> I'm not quite sure if I understand you correctly. Do you means don't use
>> pagecache for bitmap IO, and manually create BIOs like the old bitmap,
>> meanwhile invent a new solution for synchronism instead of the global
>> spin_lock from old bitmap?
> 
> Yes.  Alternatively you need to pre-populate the page cache and keep
> extra page references.

Ok, I'll think about self managed pages and IO path. Meanwhile, please
let me know if you have questions with other parts.

Thanks,
Kuai

> 
> .
>