On Mon, Sep 16, 2013 at 10:42:30AM -0700, Aditya Kali wrote: > During remount of a bind mount (mount -o remount,bind,ro,... /mnt/mntpt), > we currently take down_write(&sb->s_umount). This causes the remount > operation to get blocked behind writes occuring on device (possibly > mounted somewhere else). We have observed that simply trying to change > the bind-mount from read-write to read-only can take several seconds > becuase writeback is in progress. Looking at the code it seems to me that > we need s_umount lock only around the do_remount_sb() call. > vfsmount_lock seems enough to protect the flag change on the mount. > So this patch fixes the locking so that changing of flags can happen > outside the down_write(&sb->s_umount). What's to prevent mount -o remount,ro /mnt and mount -o remount,rw,nodev /mnt racing and ending up with that sucker rw and without nodev? As for lock_mount... nope - we carefully do *not* hold namespace_sem over any kind of fs operations. Anything getting stuck while holding it will have really nasty consequences. So ->s_umount here is inelegant, but alternatives sucks worse... -- 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
