panic: mutex Giant owned at .../base/head/sys/kern/kern_exit.c:131

[John Baldwin]

On Friday 31 July 2009 10:11:25 am Attilio Rao wrote:
> 2009/7/31 John Baldwin <jhb at freebsd.org>:
> > On Friday 31 July 2009 2:36:46 am Marcel Moolenaar wrote:
> >> All,
> >>
> >> I got the following panic after I had to import my ZFS file system on
> >> ia64.
> >> The following panic happened when executing "zpool import":
> >>
> >> panic: mutex Giant owned at /nfs/freebsd/base/head/sys/kern/
> >> kern_exit.c:131
> >> cpuid = 0
> >> KDB: enter: panic
> >
> > It looks like ZFS doesn't actually ever check if any of the namei lookups 
it
> > does internally return with Giant locked.  For example, it doesn't check
> > NDHASGIANT() in lookupnameat().  Fixing this may be a bit of work as I'm 
not
> > sure it is safe to drop Giant right after the namei().  If it is because 
the
> > end vnode's returned are always MPSAFE then that fix is easy.  If not, 
then
> > Giant needs to be held until the code stops frobbing the vnode returned 
from
> > the lookup.
> 
> NDHASGIANT() reflects the locking of the mountpoint where the vnode is
> on so you need to size it in regard of what the namei() consumer is
> going to expect in terms of locking with such vnode/mountpoint.

True, but in this case the Giant lock that is leaked is locked in namei().  If 
you have LOCKPARENT set and you lookup your / then the parent vnode may be 
from a different !MPSAFE filesystem even if your filesystem is safe, yes?

-- 
John Baldwin