Re: [PATCH vfs.all 22/26] block: stash a bdev_file to read/write raw blcok_device

[Al Viro <viro@zeniv.linux.org.uk>]

On Sun, Apr 07, 2024 at 06:11:19AM +0100, Al Viro wrote:
> On Sun, Apr 07, 2024 at 05:57:58AM +0100, Al Viro wrote:
> 
> > PS: in grow_dev_folio() we probably want
> > 	struct address_space *mapping = bdev->bd_inode->i_mapping;
> > instead of
> > 	struct inode *inode = bdev->bd_inode;
> > as one of the preliminary chunks.
> > FWIW, it really looks like address_space (== page cache of block device,
> > not an unreasonably candidate for primitive) and block size (well,
> > logarithm thereof) cover the majority of what remains, with device
> > size possibly being (remote) third...
> 
> Incidentally, how painful would it be to switch __bread_gfp() and __bread()
> to passing *logarithm* of block size instead of block size?  And possibly
> supply the same to clean_bdev_aliases()...
> 
> That would reduce fs/buffer.c uses to just "give me the address_space of
> that block device"...

... and from what I've seen in your series, it very much looks like after
that we could replace ->bd_inode with ->bd_mapping, turning your bdev_mapping()
into an inline and (hopefully) leaving the few remaining uses of bdev_inode()
outside of block/bdev.c _not_ on hot paths.  If nothing else, it would
make it much easier to grep for remaining odd stuff.

Might trim the btrfs parts of the series, at that - a lot of that seems to
be "how do we propagate opened file instead of just bdev, so that we could
get to its ->f_mapping deep in call chain"...

Again, all of that is only if __bread...() conversion to log(size) is feasible
without a massive PITA - there might be dragons...