Date: Thu, 12 Sep 2024 21:44:59 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 280978] Kernel panics with vfs.nfsd.enable_locallocks=1 and nfs clients doing hdf5 file operations Message-ID: <bug-280978-227-mArSAG4G8s@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-280978-227@https.bugs.freebsd.org/bugzilla/>
index | next in thread | previous in thread | raw e-mail
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=280978 Rick Macklem <rmacklem@FreeBSD.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|bugs@FreeBSD.org |rmacklem@FreeBSD.org Status|New |Open --- Comment #3 from Rick Macklem <rmacklem@FreeBSD.org> --- Created attachment 253528 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=253528&action=edit Fix close handling when vfs.nfsd.enable_locallocks=1 I think this patch might fix the problem. nfsrv_freeopen() was being called after the mutex lock was released, making it possible for other kernel threads to change the lists while nfsrv_freeopen() took the nfsstateid out of the lists. This patch moves the code around "if (nfsrv_freeopen(stp, vp, 1 p) == 0) {" into nfsrv_freeopen(), so that it can remove the nfsstateid structure from all lists before unlocking the mutex. This should avoid any race between CLOSE and other nfsd threads updating the NFSv4 state. The patch does not affect the semantics when vfs.nfsd.enable_locallocks=0. If the reporter can test this patch, that would be great. -- You are receiving this mail because: You are the assignee for the bug.home | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-280978-227-mArSAG4G8s>