ZFS : panic("sleeping thread")

John Baldwin jhb at freebsd.org
Wed May 27 18:22:33 UTC 2009

On Wednesday 27 May 2009 1:58:49 pm Artem Belevich wrote:
> Hi,
> While recent ZFS improvements got rid of random hangs I used to see,
> there's still one problem that I keep running into -- panic in ZFS
> under heavy load. I can reproduce it by doing a build with -j16 in a
> jail running i386 binaries on -CURRENT/amd64 running on a box with
> quad-core CPU. It takes a while to reproduce, but it usually shows up
> within couple of hours.
> Sleeping thread (tid 100606, pid 32147) owns a non-sleepable lock
> sched_switch() at sched_switch+0xed
> mi_switch() at mi_switch+0x16f
> sleepq_wait() at sleepq_wait+0x42
> _sx_xlock_hard() at _sx_xlock_hard+0x1f0
> _sx_xlock() at _sx_xlock+0x4e
> rrw_exit() at rrw_exit+0x1d
> zfs_freebsd_getattr() at zfs_freebsd_getattr+0x2be
> filt_vfsread() at filt_vfsread+0x51
> knote() at knote+0xc2
> vn_write() at vn_write+0x279
> dofilewrite() at dofilewrite+0x85
> kern_writev() at kern_writev+0x60
> write() at write+0x54
> ia32_syscall() at ia32_syscall+0x236
> Xint0x80_syscall() at Xint0x80_syscall+0x85
> --- syscall (4, FreeBSD ELF32, write), rip = 0x78162153, rsp =
> 0xffff945c, rbp = 0xffff9478 ---
> It appears that locking within ZFS conflicts with vnode locking. The
> back-trace is always the same.

I think it is the knote locking that is actually the problem.  knote()
is acquiring the KQ_LOCK and I think this lock needs to be dropped while
invoking VOP_GETATTR().

John Baldwin

More information about the freebsd-current mailing list