Date: Sun, 12 Oct 2025 00:26:42 +0000 From: bugzilla-noreply@freebsd.org To: net@FreeBSD.org Subject: [Bug 289734] panic tcp_usr_close while running mount command after configure NFS over TLS Message-ID: <bug-289734-7501-HqsOQZ36r4@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-289734-7501@https.bugs.freebsd.org/bugzilla/> References: <bug-289734-7501@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=3D289734 --- Comment #10 from Rick Macklem <rmacklem@FreeBSD.org> --- (In reply to Gleb Smirnoff from comment #9) Well, whoever it belongs to hardly matters. I do plan on looking at it, but I've been busy with other stuff (I know you're busy, too.) My hunch (only a hunch) is that one thread sees the TLS peer reset (sent by the client when it calls SSL_shutdown) and then, while that thread is processing it, another thread does a close() on the socket (or something like that). When one thread in the rpc.tlsservd is doing any SSL library call for a TCP connection, no other thread can be allowed to mess with the same TCP connection. (The old code pinned a TCP connection to a process, but I haven't looked to see how you handled this?) I think a TCP socket must be pinned to a thread or something close to that. Multiple processes/threads were meant to handle the case where many clients tried to TLS handshake (all different TCP connections, of course) after a server reboot. You might need fast hardware to reproduce the race. I cannot reproduce it with my slow junk. --=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-289734-7501-HqsOQZ36r4>