Date: Sun, 20 May 2018 22:52:30 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 228384] zfs utilities hang on [spa_namespace_lock] (transferred from 203906 as an unrelated issue) Message-ID: <bug-228384-227@https.bugs.freebsd.org/bugzilla/>
next in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D228384 Bug ID: 228384 Summary: zfs utilities hang on [spa_namespace_lock] (transferred from 203906 as an unrelated issue) Product: Base System Version: 11.1-STABLE Hardware: i386 OS: Any Status: New Severity: Affects Only Me Priority: --- Component: kern Assignee: bugs@FreeBSD.org Reporter: bsd.gaijin@gmail.com Created attachment 193578 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D193578&action= =3Dedit procstat output zpool status hangs on [spa_namespace_lock]. Output of the procstat -a -kk a= nd pictures of the stack trace from thread holding the lock attached. >From Andriy Gapon <avg@FreeBSD.org>: So, it's: 13 100015 geom g_event mi_switch+0xe6 sleepq_wait+0x2c _sx_xlock_hard+0x314 zvol_geom_access+0x148 g_access+0x1fd g_eli_read_metadata+0x249 g_eli_config+0x3ed g_run_events+0x13e fork_exit+0= x83 fork_trampoline+0xe 930 100354 zfsd - mi_switch+0xe6 sleepq_wait+0x2c _sleep+0x23e g_access+0xf7 vdev_geom_attach+0x61c vdev_attach_ok+0x29 vdev_geom_open+0x394 vdev_open+0x115 vdev_open_children+0x30 vdev_root_open+0x3a vdev_open+0x115 spa_ld_open_vdevs+0x5e spa_ld_mos_init+0x1be spa_ld_mos_with_trusted_config+0x19 spa_load+0x5c spa_load_best+0x6b spa_open_common+0x11d spa_get_stats+0x4f I think I know what's going on in your case (not sure if it's the same a as previous reports in this bug). It's probably a consequence of base r330977= , a fix to bug 225960. I didn't fully realize at that time, but that commit introduced a "g_access lock" in disguise. So, we went from a LOR between geom topology lock and spa_namespace_lock to= a race caused by dropping the topology lock to a LOR between spa_namespace_lo= ck and "g_access lock". The toughest part now is to decide how to solve the LOR without re-introduc= ing the race. Or alternatively, how to solve the race without introducing a deadlock. --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-228384-227>