Re: updated orangefs tree at kernel.org

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

	Superblock handling:

1) aside of the pointlessness of struct pvfs2_mount_sb_info_s, now that
pvfs2_fill_sb() is called directly and isn't constrained to passing just
one pointer argument, you are mishandling its failures.  Note that
mount_nodev() follows a failure of callback with deactivate_locked_super(s);
pvfs2_mount() does not.  It simply ends up leaking a struct super_block in
such case.

2) ->kill_sb() is called for everything that had been created by sget().
IOW, your pvfs2_kill_sb() can be called for something that never got past
the attempt to allocate ->s_fs_info.  You seem to assume that it's only
called for fully set up superblock.

3) the question about protection of pvfs2_superblocks in
dispatch_ioctl_command() remains - handling of PVFS_DEV_REMOUNT_ALL
loops through that list with no locks in common with the call chain
leading through ->kill_sb() to remove_pvfs2_sb().

4) ditto for pvfs2_remount() vs. pvfs2_unmount_sb() - is it OK to have
the former called while the latter is running?  I don't see anything that
would provide an exclusion here.

5) are you sure that pvfs2_unmount_sb() should be done *before*
kill_anon_super()?  At that point we still might have dirty inodes
in cache, etc.  I don't know the protocol - can't tell if that's really
OK.