Date: Sun, 20 Oct 2024 15:12:43 +0000 From: bugzilla-noreply@freebsd.org To: fs@FreeBSD.org Subject: [Bug 282169] zfs rename deadlock with mountd, df & fstat (and possibly others) Message-ID: <bug-282169-3630-rOm3ISECEe@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-282169-3630@https.bugs.freebsd.org/bugzilla/> References: <bug-282169-3630@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D282169 Mark Johnston <markj@FreeBSD.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |markj@FreeBSD.org Status|New |Open --- Comment #1 from Mark Johnston <markj@FreeBSD.org> --- Many threads are blocked on the ZFS "teardown" lock. I guess a writer holds the lock, or a reader leaked one. I looked through uses of ZFS_ENTER and couldn't find any leaks. I'm confused by the locking in zfsvfs_teardown(). That function unconditionally acquires the teardown write lock, but there exist cases lat= er in the function where it won't be released. Specifically, if `!unmounting = && !zfsvfs->z_unmounted && zfsvfs->z_ops !=3D NULL` is true, the write lock se= ems to be leaked. I'm not sure if that condition is possible in practice, but it looks rather odd. That code path could potentially be triggered by zfs_suspend_fs(), which is invoked by a couple of dataset operations, rollback and recv specifically, = but as far as I can see renaming a dataset won't trigger suspension. --=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-282169-3630-rOm3ISECEe>