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