From: Sabrina Dubroca <sd@queasysnail.net>
To: Chuck Lever <cel@kernel.org>
Cc: John Fastabend <john.fastabend@gmail.com>,
Jakub Kicinski <kuba@kernel.org>,
"David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Paolo Abeni <pabeni@redhat.com>, Simon Horman <horms@kernel.org>,
Dave Watson <davejwatson@fb.com>, Shuah Khan <shuah@kernel.org>,
netdev@vger.kernel.org, linux-kselftest@vger.kernel.org
Subject: Re: [PATCH net 6/9] selftests: tls: add peek and splice coverage for zero-length records
Date: Mon, 27 Jul 2026 16:07:32 +0200 [thread overview]
Message-ID: <amdmJHNBGL4tzQVH@krikkit> (raw)
In-Reply-To: <20260726-tls-follow-on-v1-6-99bf4cc1c729@kernel.org>
2026-07-26, 20:33:34 -0400, Chuck Lever wrote:
> +static void zero_len_sock_pair(struct __test_metadata *_metadata,
> + int *fd, int *cfd, bool *notls)
> +{
> + struct tls_crypto_info_keys tls12;
> + int ret;
> +
> + tls_crypto_info_init(TLS_1_2_VERSION, TLS_CIPHER_AES_CCM_128,
> + &tls12, 0);
> +
> + ulp_sock_pair(_metadata, fd, cfd, notls);
> + if (*notls)
> + return;
> +
> + /* fd stays keyless; these fixtures send raw records over it */
> + ret = setsockopt(*cfd, SOL_TLS, TLS_RX, &tls12, tls12.len);
> + ASSERT_EQ(ret, 0);
> +}
> +
> +/* Send a variant's records; return the last one carrying payload */
> +static const struct raw_rec *
> +zero_len_send_recs(struct __test_metadata *_metadata, int fd,
> + const struct raw_rec *const *recs)
> +{
> + const struct raw_rec *payload = NULL;
> + int i;
> +
> + for (i = 0; i < 4 && recs[i]; i++) {
> + EXPECT_EQ(send(fd, recs[i]->cipher_data, recs[i]->cipher_len, 0),
> + recs[i]->cipher_len);
> + if (recs[i]->plain_len)
> + payload = recs[i];
> + }
> +
> + return payload;
> +}
nit: those are identical to the existing FIXTURE_SETUP(zero_len) and
the TX part of TEST_F(zero_len, test), so they should also be used
there.
Or since you're reusing similar variants (for both zero_len_peek and
zero_len_splice), maybe just add the new TEST_F chunks as subtests of
the existing zero_len FIXTURE? There's only partial overlap in the
current version, but there should be a set of {recv_ret, peek_ret,
splice_ret} that works for each.
--
Sabrina
next prev parent reply other threads:[~2026-07-27 14:07 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-27 0:33 [PATCH net 0/9] net/tls: Receive-path fixes for zero-length data records Chuck Lever
2026-07-27 0:33 ` [PATCH net 1/9] net/tls: Bound time spent on no-data records in tls_sw_read_sock() Chuck Lever
2026-07-30 9:12 ` Sabrina Dubroca
2026-07-30 13:05 ` Chuck Lever
2026-07-30 17:21 ` Sabrina Dubroca
2026-08-07 0:17 ` Chuck Lever
2026-08-03 22:39 ` Jakub Kicinski
2026-08-04 0:35 ` Chuck Lever
2026-08-04 1:19 ` Jakub Kicinski
2026-07-27 0:33 ` [PATCH net 2/9] net/tls: Consume empty data records in tls_sw_splice_read() Chuck Lever
2026-07-30 10:38 ` Sabrina Dubroca
2026-08-07 0:19 ` Chuck Lever
2026-07-27 0:33 ` [PATCH net 3/9] net/tls: Fail tls_sw_splice_read() after a failed async decrypt Chuck Lever
2026-08-03 22:59 ` Jakub Kicinski
2026-07-27 0:33 ` [PATCH net 4/9] net/tls: Honor O_NONBLOCK in tls_sw_splice_read() Chuck Lever
2026-07-30 10:59 ` Sabrina Dubroca
2026-08-07 0:19 ` Chuck Lever
2026-07-27 0:33 ` [PATCH net 5/9] net/tls: Consume empty data records in tls_sw_recvmsg() Chuck Lever
2026-07-30 12:40 ` Sabrina Dubroca
2026-08-07 0:21 ` Chuck Lever
2026-08-03 22:47 ` Jakub Kicinski
2026-08-07 0:20 ` Chuck Lever
2026-07-27 0:33 ` [PATCH net 6/9] selftests: tls: add peek and splice coverage for zero-length records Chuck Lever
2026-07-27 14:07 ` Sabrina Dubroca [this message]
2026-07-27 0:33 ` [PATCH net 7/9] selftests: tls: skip the zero_len tests when TLS is unavailable Chuck Lever
2026-07-27 0:33 ` [PATCH net 8/9] selftests: tls: cover splice on a nonblocking socket Chuck Lever
2026-07-27 0:33 ` [PATCH net 9/9] selftests: tls: cover splice after a failed decrypt Chuck Lever
2026-07-27 15:19 ` Sabrina Dubroca
2026-08-03 22:58 ` [PATCH net 0/9] net/tls: Receive-path fixes for zero-length data records Jakub Kicinski
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=amdmJHNBGL4tzQVH@krikkit \
--to=sd@queasysnail.net \
--cc=cel@kernel.org \
--cc=davejwatson@fb.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=horms@kernel.org \
--cc=john.fastabend@gmail.com \
--cc=kuba@kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=shuah@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.