svn commit: r362798 - in projects/nfs-over-tls/sys/rpc: . rpcsec_tls

[Benjamin Kaduk]

On Tue, Jun 30, 2020 at 7:49 AM Rick Macklem <rmacklem at freebsd.org> wrote:

> Author: rmacklem
> Date: Tue Jun 30 14:49:51 2020
> New Revision: 362798
> URL: https://svnweb.freebsd.org/changeset/base/362798
>
> Log:
>   Testing when a server does not respond to TLS handshake records exposed
>   a couple of problems, since the daemon would be in SSL_connect() for 6
> minutes.
>
>   - When the upcall timed out and was retried, the RPCTLS_SYSC_CLSOCKET
> syscall
>     was broken and did not return an error upon a retry. It allocated a
> file
>     descriptor for a NULL socket.
>   - The socket structure in the kernel could be free'd while the daemon was
>     still using it in SSL_connect().
>   - Adjust the timeout a retry count so that upcalls are only attempted
> once
>     with a 10minute timeout.
>
>
10 minutes seems really long!  It sounds from the description like the
upcall so that
userspace can run SSL_connect() was taking 6 minutes, and you needed 10
minutes so
as to be longer than the 6 minutes that is "out of your control"?

I feel like there should be some sockopts available to get the
SSL_connect() timeout
down, so that the upcall timeout doesn't need to be so long, either.

-Ben