[Bug 289734] panic tcp_usr_close while running mount command after configure NFS over TLS

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=289734

--- 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.

-- 
You are receiving this mail because:
You are the assignee for the bug.