Date: Sat, 09 Feb 2019 10:44:08 +0000 From: bugzilla-noreply@freebsd.org To: fs@FreeBSD.org Subject: [Bug 235582] rpc_svc_gss / nfsd kernel panic Message-ID: <bug-235582-3630-bHsPUDiAOX@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 #8 from Peter Eriksson <peter.x.eriksson@liu.se> --- I'll try out the proposed fixes. Sound like it could be the culprit. A pity= I haven't really found a way to force the issue yet (or even pinpointed which= of the 100-200 clients caused it). But perhaps it's just a random thing caused= by network retransmissions and load balancing over multiple LACP trunks... A question - I enabled a lot of debugging output in order to try to see wha= t's happening and I noticed one strange thing in the "dmesg" output: > rpcsec_gss: accepted context for \^D\^A (41 bytes) with <mech { 1 2 840 1= 13554 1 2 2 }, qop 0, svc 1> (I had modified the rpc_gss_log_debug() call to also print the length of the client_principal member) Ie, this call around line 1100 or so: rpc_gss_log_debug("accepted context for %s (%d bytes) with " "<mech %.*s, qop %d, svc %d>", client->cl_rawcred.client_principal->name, client->cl_rawcred.client_principal->len, mechname.length, (char *)mechname.value, client->cl_qop, client->cl_rawcred.service); The "client_principal->name" output looks garbled.. (In /var/log/messages t= hose characters get's filtered out so you won't find it there). Perhaps cl_rawcred.client_principal isn't supposed to be printable at all. --=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-bHsPUDiAOX>