Date: Sun, 19 Aug 2018 23:25:24 +0000 From: bugzilla-noreply@freebsd.org To: fs@FreeBSD.org Subject: [Bug 230752] panic: excl->share in newnfs_request Message-ID: <bug-230752-3630-wxBgkLRSwn@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-230752-3630@https.bugs.freebsd.org/bugzilla/> References: <bug-230752-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=3D230752 Rick Macklem <rmacklem@FreeBSD.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |rmacklem@FreeBSD.org --- Comment #1 from Rick Macklem <rmacklem@FreeBSD.org> --- Is there a specific situation happening when these panic()s occur? (such as startup, shutdown or ??) Basically, the panic() happens when the kernel RPC code is doing a connect on an AF_LOCAL socket created by the nfsuserd daemon to do an upcall. I'll admit I haven't tested this myself recently, but I'll try running nfsuserd on current. (prior to FreeBSD12, nfsuserd uses a UDP socket, so this panic() wouldn't happen) (Since unp_connectat() does a straightforward namei(), I don't know why there would be an "excl->shared" panic? The code is using LK_SHARED for the lookup, but that happens all the time.) I am wondering if somehow the AF_LOCAL socket got deleted and that confuses the namei()/lookup(). (The socket is /var/run/nfsuserd.sock.) If the panic()s are causing you grief, you can add the -use-udpsock command line option to nfsuserd to make it use the UDP socket, like FreeBSD= -11. --=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-230752-3630-wxBgkLRSwn>