Re: [PATCH net 1/9] net/tls: Bound time spent on no-data records in tls_sw_read_sock()

On Mon, 03 Aug 2026 20:35:54 -0400 Chuck Lever wrote:
> On Mon, Aug 3, 2026, at 6:39 PM, Jakub Kicinski wrote:
> > On Sun, 26 Jul 2026 20:33:29 -0400 Chuck Lever wrote: =20
> >> +/* Bound the time that consecutive empty ingress data records keep
> >> + * the socket lock held without releasing it.
> >> + */
> >> +#define TLS_RX_NODATA_NS NSEC_PER_MSEC =20
> >
> > A time bound is a bad idea in the kernel, a softirq can easily=20
> > take >1msec and turn 2 consecutive zero length records into
> > a fatal error for the connection. =20
>=20
> I don=E2=80=99t have a particular dog in this race, but you and Sabrina n=
eed
> to thumb wrestle to decide which way this needs to go. My original
> thought was to use a count of zero-length packets.

There's a time limit on rx_action processing which is super noise prone
on production systems, hence my preference to avoid any time bounds on
in kernel processing.

And looks like user space libs generally put a numeric cap on the
zero-len record count within a batch?

FWIW I'm not super convinced this is actually an issue for TLS 1.3.
DoS generally means that attacker has some leverage but here attacker
has to encrypt the records for real, so I don't really see this as
a DoS vector. But better safe than sorry, I guess.