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: <20250409094019.GA3890@lst.de>
Date: Wed, 9 Apr 2025 11:40:19 +0200
From: Christoph Hellwig <hch@....de>
To: Yu Kuai <yukuai1@...weicloud.com>
Cc: Christoph Hellwig <hch@....de>, 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

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.