[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250812062825.391c030c@kernel.org>
Date: Tue, 12 Aug 2025 06:28:25 -0700
From: Jakub Kicinski <kuba@...nel.org>
To: Paolo Abeni <pabeni@...hat.com>
Cc: davem@...emloft.net, netdev@...r.kernel.org, edumazet@...gle.com,
andrew+netdev@...n.ch, horms@...nel.org, borisp@...dia.com,
john.fastabend@...il.com, shuah@...nel.org,
linux-kselftest@...r.kernel.org, sd@...asysnail.net, will@...lsroot.io,
savy@...t3mfailure.io
Subject: Re: [PATCH net v2 1/2] tls: handle data disappearing from under the
TLS ULP
On Tue, 12 Aug 2025 12:45:56 +0200 Paolo Abeni wrote:
> On 8/8/25 1:29 AM, Jakub Kicinski wrote:
> > diff --git a/net/tls/tls_sw.c b/net/tls/tls_sw.c
> > index 549d1ea01a72..51c98a007dda 100644
> > --- a/net/tls/tls_sw.c
> > +++ b/net/tls/tls_sw.c
> > @@ -1384,7 +1384,8 @@ tls_rx_rec_wait(struct sock *sk, struct sk_psock *psock, bool nonblock,
> > return sock_intr_errno(timeo);
> > }
> >
> > - tls_strp_msg_load(&ctx->strp, released);
> > + if (unlikely(!tls_strp_msg_load(&ctx->strp, released)))
> > + return tls_rx_rec_wait(sk, psock, nonblock, false);
>
> I'm probably missing something relevant, but I don't see anything
> preventing the above recursion from going very deep and cause stack
> overflow.
>
> Perhaps something alike:
>
> released = false;
> goto <function start>
>
> would be safer?
It's a tail call to the same function, the compiler should do that for
us automatically. Can we not trust the compiler to be sensible? Both
clang and gcc get it right.
Powered by blists - more mailing lists