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 BaldwinReceived on Fri Jul 31 2009 - 13:55:26 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:53 UTC