Re: [PATCH 6.12.y 1/2] selftests: tls: add rekey tests

2026-08-21, 12:51:30 -0400, Sasha Levin wrote:
> On Wed, Aug 19, 2026 at 05:19:24PM +0200, Sabrina Dubroca wrote:
> > All of those rekey tests are going to fail if you don't take the rekey
> > implementation as well (which I hope isn't getting backported to any
> > stable kernels). You probably don't want that.
> 
> You're right, and thanks for catching it.
> 
> To be unambiguous about what this actually affected: the 6.12.y series
> you're replying to here was never queued, so there was nothing to drop
> on 6.12. The same selftest had, however, already been queued for 6.6
> from a separate 6.6.y posting, and that is what I've now dropped. Three

Right. I saw something for 6.6 and kind of assumed that replying to
6.12 would be enough since it should be the exact same situation
there. I won't assume next time.

> patches came out of the 6.6 queue:
> 
>   - selftests: tls: add rekey tests (555f0edb9ff0)
>   - selftests: tls: add test with a partially invalid iov (dc54b813df63)
>   - tls: rx: restore msg_iter before TLS 1.3 optimistic retry (1c8629651cb5)

Sounds ok. I guess you could still backport the retry fix, you would
just get a trivial conflict on the selftest because the context
changed, but it's a minor behavioral bug.

> On 6.6 it's worse than the tests failing - the selftest doesn't even
> build. tls_crypto_info_init() only grew its key_generation argument in
> b2e584aa3c71, which isn't in 6.6, so the ~20 four-argument call sites

Yes, that was also part of the rekey series.

> the rekey patch adds fail to compile, and __test_passed() (69fe8ec4f673,
> v6.9) is missing from 6.6's kselftest_harness.h. And of course the rekey
> implementation itself (0471b1093e3a, 47069594e67e, 510128b30f2d) isn't
> there, so tls_main.c still returns -EBUSY on the second setsockopt()
> that every rekey test expects to succeed.

Thanks.

-- 
Sabrina