Date: Tue, 30 Jun 2020 09:02:37 -0700 From: Benjamin Kaduk <bjkfbsd@gmail.com> To: Rick Macklem <rmacklem@freebsd.org> Cc: src-committers <src-committers@freebsd.org>, svn-src-projects@freebsd.org Subject: Re: svn commit: r362798 - in projects/nfs-over-tls/sys/rpc: . rpcsec_tls Message-ID: <CAJ5_RoDe=_s2LZociYXTmdVOP%2BLJDA5HJ7jZkKr7LChffbaH8w@mail.gmail.com> In-Reply-To: <202006301449.05UEnq2x072917@repo.freebsd.org> References: <202006301449.05UEnq2x072917@repo.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Jun 30, 2020 at 7:49 AM Rick Macklem <rmacklem@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ5_RoDe=_s2LZociYXTmdVOP%2BLJDA5HJ7jZkKr7LChffbaH8w>