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

[Christian Brauner <brauner@kernel.org>]

On Wed, Apr 10, 2024 at 11:34:43PM +0100, Al Viro wrote:
> On Wed, Apr 10, 2024 at 12:59:11PM +0200, Jan Kara wrote:
> 
> > I agree with Christian and Al - and I think I've expressed that already in
> > the previous version of the series [1] but I guess I was not explicit
> > enough :). I think the initial part of the series (upto patch 21, perhaps
> > excluding patch 20) is a nice cleanup but the latter part playing with
> > stashing struct file is not an improvement and seems pointless to me. So
> > I'd separate the initial part cleaning up the obvious places and let
> > Christian merge it and then we can figure out what (if anything) to do with
> > remaining bd_inode uses in fs/buffer.c etc. E.g. what Al suggests with
> > bd_mapping makes sense to me but I didn't check what's left after your
> > initial patches...
> 
> FWIW, experimental on top of -next:

Ok, let's move forward with this. I've applied the first 19 patches.
Patch 20 is the start of what we all disliked. 21 is clearly a bugfix
for current code so that'll go separately from the rest. I've replaced
open-code f_mapping access with file_mapping(). The symmetry between
file_inode() and file_mapping() is quite nice.

Al, your idea to switch erofs away from buf->inode can go on top of what
Yu did imho. There's no real reason to throw it away imho.

I've exported bdev_mapping() because it really makes the btrfs change a
lot slimmer and we don't need to care about messing with a lot of that
code. I didn't care about making it static inline because that might've
meant we need to move other stuff into the header as well. Imho, it's
not that important but if it's a big deal to any of you just do the
changes on top of it, please.

Pushed to
https://git.kernel.org/pub/scm/linux/kernel/git/vfs/vfs.git vfs.super

If I hear no objections that'll show up in -next tomorrow. Al, would be
nice if you could do your changes on top of this, please.