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.
