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.
