On Tue, Jun 06, 2006 at 11:25:29AM +0300, Andrey Simonenko wrote: > On Mon, Jun 05, 2006 at 08:30:45PM +0300, Konstantin Belousov wrote: > > On Mon, Jun 05, 2006 at 02:01:36PM +0300, Andrey Simonenko wrote: > > > 2. > > > > > > If vfs_busy() is called without LK_NOWAIT flag, then it can sleep > > > if a filesystem is being unmounted. At some point unmount() will > > If vfs_busy() is called without LK_NOWAIT and fs is being unmounted, > > then vfs_busy returns with ENOENT error, isn't it ? > > > > Yes, it returns ENOENT, but before this event vfs_busy() sets MNTK_MWAIT > flag and sleeps on mount point address. When vfs_mount_destroy() sees > MNTK_MWAIT, it wakes up a thread which sleeps in vfs_busy(). Since > vfs_busy() and vfs_mount_destroy() are active only if MNT_MTX(mp) is > acquired, vfs_mount_destroy() continues own execution, deallocating > mount point, so mutex address passed to msleep() in vfs_busy() is not > valid any more. Are you concerned about invocation of vfs_mount_destroy() at line 1224 of vfs_mount.c, in dounmount ? Do you experience problems (panics, etc) caused by this issue ?
It seems that this scenario is impossible for some reasons that are external to vfs_busy, because dounmount() aquires exclusive lock on the vnode covered by mount point. As far as I see, all invocations of vfs_busy() without LK_NOWAIT flag are done while holding at least shared lock on that vnode. See, for instance, fchdir() from vfs_syscalls.c.
pgpPF4FYKgSYX.pgp
Description: PGP signature
