Date: Sat, 10 Feb 2024 16:58:58 +0000 From: bugzilla-noreply@freebsd.org To: fs@FreeBSD.org Subject: [Bug 276341] zfs panic: VERIFY3(rc->rc_count == number) failed Message-ID: <bug-276341-3630-EKtUaoLMTR@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-276341-3630@https.bugs.freebsd.org/bugzilla/> References: <bug-276341-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=3D276341 --- Comment #13 from Rich Ercolani <Rincebrain@gmail.com> --- At least 21fce617d1de231a30833cdd9819ef61277b08d8 ... 3494f7c019fc6558a99f63b7f647373b89bcde92 is a small window. None of the changes in that window seem super obviously fraught or risky he= re, skimming them. Half wondering if 21fce617d1de231a30833cdd9819ef61277b08d8=20 built with LLVM 17 would break the same way and it's some weird optimization going awry, but I haven't remotely tried testing this enough to say that. Anything you can tell us about the datasets on the pool? I'm going to go try reproing this in a 15 VM, but if it doesn't trivially reproduce for me (tho= ugh if syzkaller is hitting it, maybe it will), then knowing things about the s= etup hitting it would be useful. --=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-276341-3630-EKtUaoLMTR>