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.
--
To unsubscribe from this list: send the line "unsubscribe linux-next" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
