Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 6 Nov 1996 10:33:11 -0700 (MST)
From:      Terry Lambert <terry@lambert.org>
To:        julian@whistle.com (Julian Elischer)
Cc:        archie@whistle.com, freebsd-hackers@freebsd.org
Subject:   Re: Davidg bug (was: mount panics & hangs)
Message-ID:  <199611061733.KAA08415@phaeton.artisoft.com>
In-Reply-To: <327FE834.167EB0E7@whistle.com> from "Julian Elischer" at Nov 5, 96 05:21:56 pm

next in thread | previous in thread | raw e-mail | index | archive | help
> dounmount(mp, flags, p) 
>         register struct mount *mp;
>         int flags;       
>         struct proc *p;  
> {                       
>         struct vnode *coveredvp;
>         int error;          
>                                 
>         coveredvp = mp->mnt_vnodecovered;
>         if (vfs_busy(mp))       
>                 return (EBUSY);
          ^^^^^^^^^^^^^^^^^^^^^^^
>         mp->mnt_flag |= MNT_UNMOUNT;
>         error = vfs_lock(mp); 
>         if (error)      
>                 return (error); <-------line "C"
          ^^^^^^^^^^^^^^^^^^^^^^^

> BTW there is another small bug, which  is.. the return at line "C"
> should also do a vfs_unbusy()    
> 
> suggestions?

Add a "NOWAIT" flags value, obey it at the indicated locations, and
don't pass it in this case (only on shutdown).


In reality, there should be a mutex for the VFS structures, the list
of mounted fs's being one of them, where "dounmount" is called, so you
never have more than one process in the mount code.

The problem is that the vfs_busy/vfs_lock pair create a race condition
because there is not an imposed order of operation.  That comes from
mixing the vfsop and vop layers without regard to structural call
layering (vfsop is hierarchically above vop).

So you're right: it's a "thundering herd" problem, where the wrong
process happens to win the race.

I suspect that this requires the while loop to happen so that the
priority becomes inverted when both processes are marked ready-to-run.


Has this problem *ever* been repeated without that while loop to
torture it into happening?


					Regards,
					Terry Lambert
					terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199611061733.KAA08415>