On Fri, Jan 30, 2015 at 01:34:41PM +0800, Miao Xie wrote: > > First of all, ->s_umount is not a mutex; it's rwsem. So you mean > > down_read_trylock(). As for the transient failures - grep for down_write > > on it... E.g. have somebody call mount() from the same device. We call > > sget(), which finds existing superblock and calls grab_super(). Sure, > > that ->s_umount will be released shortly, but in the meanwhile your trylock > > will fail... > > I know it, so I suggested to return -EBUSY in the previous mail. > I think it is acceptable method, mount/umount operations are not so many > after all. Er... What for, when there's a trivial variant that doesn't suffer those spurious -EBUSY? Seriously, just move sysfs removals up to make sure that any possible fs shutdown won't progress past those during sysfs IO and use sb_want_write/sb_dont_write to make sure it'll stay r/w for the duration. What's the problem? -- 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
