panic: mutex Giant owned at /tank/usr/src/sys/kern/kern_thread.c:357

[John Baldwin]

On Wednesday 30 December 2009 4:55:44 pm Marcel Moolenaar wrote:
> All,
> 
> We still have a ZFS-triggerable panic. The conditions under which the panic
> happens are "simple":
> 
> 1.  Create a mount-point /dos, and mount a MS-DOS file system
>     there.
> 2.  Create directory /dos/zfs
> 3.  Make /boot/zfs a symlink to /dos/zfs
> 4.  create or import a pool, like "zpool import tank"
> 
> ZFS will create/update the zpool cache (/boot/zfs/zpool.cache)
> and when done exits the zfskern/solthread thread, at which time
> the panic happens:
> 
> panic: mutex Giant owned at /tank/usr/src/sys/kern/kern_thread.c:357
> cpuid = 0
> KDB: enter: panic
> [thread pid 8 tid 100147 ]
> Stopped at      kdb_enter+0x92: [I2]    addl r14=0xffffffffffe1f3f0,gp ;;
> db> show alllocks
> Process 8 (zfskern) thread 0xe000000010df4a20 (100147)
> exclusive sleep mutex process lock (process lock) r = 0 (0xe000000010407660) 
locked @ /tank/usr/src/sys/kern/kern_kthread.c:326
> exclusive sleep mutex Giant (Giant) r = 1 (0xe0000000048f8da8) locked @ 
/tank/usr/src/sys/kern/vfs_lookup.c:755
> 
> It looks to me that this is a bug in vfs_lookup.c, but I'm not
> savvy enough to know this for sure or fix it fast myself. Help
> is welcome, because this particular bug hits ia64 hard: /boot
> is a symlink to /efi/boot, where /efi is a msdosfs mount point.

Can you get a stack trace?  The bug is probably that ZFS isn't properly 
honoring NDHASGIANT() someplace.  Hmm, it certainly doesn't honor it
in lookupnameat().  You could maybe have it unlock Giant there, but I
believe that will result in ZFS not acquiring Giant for any vnode
operations on a returned vnode from a !MPSAFE filesystem.

-- 
John Baldwin