Date: Mon, 11 Feb 2019 22:49:44 +0000 From: bugzilla-noreply@freebsd.org To: fs@FreeBSD.org Subject: [Bug 235582] rpc_svc_gss / nfsd kernel panic Message-ID: <bug-235582-3630-tCzTIvNHdw@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-235582-3630@https.bugs.freebsd.org/bugzilla/> References: <bug-235582-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=3D235582 --- Comment #18 from Rick Macklem <rmacklem@FreeBSD.org> --- Yes, I suspect that "-n 1" on the nfsd startup would probably mask the problem, although I would not recommend that. (This assumes that I am correct to assume this race between threads is the culprit.) Increasing the size of CLIENT_MAX (which recently became a tunable in head) might also mask it and will help w.r.t. performance if you have more than 128 users authenticating from the clients. (In this case, CLIENT refers to a user on an NFS mount and not an NFS mount from a client.) Interesting that the HASH table is set to 256, which is twice the number of elements being kept in the hash lists. (Not sure why anyone would make it that way, but I'm not the author of this stuff.;-) I am really hoping that the 2nd patch "fix race..." will fix the problem. (The first patch would just be a "safety belt" in case the GSSAPI did return GSS_S_COMPLETE for gss_accept_sec_context(), but somehow leave the cname argument NULL. --=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-235582-3630-tCzTIvNHdw>