Re: linux-next: manual merge of the vfs tree with the tree

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

On Fri, May 08, 2009 at 03:40:49PM +0200, Miklos Szeredi wrote:
> On Fri, 8 May 2009, Stephen Rothwell wrote:
> > Today's linux-next merge of the vfs tree got a conflict in
> > fs/fuse/inode.c between commit a325f9b92273d6c64ec56167905b951b9827ec33
> > ("fuse: update fuse_conn_init() and separate out fuse_conn_kill()") from
> > the fuse tree and commit 4225d95ddb751e09da0c145b58549da95ba13e3a ("push
> > BKL down into ->put_super") from the vfs tree.
> > 
> > I fixed it up (see below - please check) and can carry the fix as
> > necessary.
> 
> The fixup looks good.
> 
> Al, would it make sense to merge the fuse tree into the vfs tree at
> some point to fix the conflict permanently?

Hmm...  Doable, of course, but I really wonder if that's the right
way to deal with this one.  The thing is, looking at the current VFS
tree I see very few places where FUSE gets called with BKL (essentially,
->get_sb(), ->remount_fs()) and ->...ioctl()).  ->remount_fs() is absolutely
locking-agnostic there and ->get_sb(), ->put_super() and ->umount_begin()
are all serialized per superblock.  And for data structures that are
not per-superblock FUSE doesn't rely on BKL in any of those, AFAICT.

If you can ACK that, we could simply leave FUSE out of all the "push
BKL down into get_sb/umount_begin/put_super/remount_fs" series.