Question about synchronization (nfssvc, vfs_busy)

[Konstantin Belousov]

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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20060606/5a2e2392/attachment.pgp