Date: Wed, 04 Feb 2026 00:07:31 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 292884] nfsd causes kernel panic Message-ID: <bug-292884-227-NEzc5cJb80@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-292884-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=292884 --- Comment #11 from Rick Macklem <rmacklem@FreeBSD.org> --- (In reply to Mark Johnston from comment #10) Actually, I don't have a patch. When I first saw this, I thought that the xprt refcnt had somehow gone to 0 and I was going to add a SVC_ACQUIRE()/SVC_RELEASE(). But, as we now see, that is not the problem. There is also the weirdness that it crashes in svc_dg_recv() { "dg" refers to datagram or UDP if you prefer }. However, it seems that the socket would have been a TCP one, since that is what his mounts are? It definitely is a puzzle and something is getting confused. This code hasn't changed in at least a decade, so?? Is the OpenBSD client doing something really weird, like closing the socket and then sending an RPC on it or somehow his configuration of bhyve instances/bridges somehow confusing the TCP stack and resulting in a socket getting socose()'d by something else. --> And then, how did svc_vc_recv() get replaced by svc_dg_recv(). I'm pretty sure the svc_vc.c code only does soclose() once the xprt refcnt goes to 0, but I cannot be absolutely sure that can never happen prematurely, although I've never seen a crash like this before. Maybe I will generate the SVC_ACQUIRE()/SVC_RELEASE() patch wrapped around SVC_RECV(), so he can try it. -- 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-292884-227-NEzc5cJb80>