All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sabrina Dubroca <sd@queasysnail.net>
To: chanyoung <ppoo1220@gmail.com>
Cc: netdev@vger.kernel.org, John Fastabend <john.fastabend@gmail.com>,
	Jakub Kicinski <kuba@kernel.org>,
	David Howells <dhowells@redhat.com>,
	Shuah Khan <shuah@kernel.org>,
	linux-kselftest@vger.kernel.org
Subject: Re: [PATCH net 2/2] selftests: tls: add a test for splicing onto a full plaintext record
Date: Mon, 27 Jul 2026 13:55:00 +0200	[thread overview]
Message-ID: <amdHFJlOVpACBir6@krikkit> (raw)
In-Reply-To: <20260726105556.2719227-3-ppoo1220@gmail.com>

2026-07-26, 19:55:56 +0900, chanyoung wrote:
> diff --git a/tools/testing/selftests/net/tls.c b/tools/testing/selftests/net/tls.c
> index cbdd3ea28b9..d2666884ea8 100644
> --- a/tools/testing/selftests/net/tls.c
> +++ b/tools/testing/selftests/net/tls.c
> @@ -835,6 +835,58 @@ TEST_F(tls, send_and_splice)
>  	EXPECT_EQ(memcmp(mem_send, mem_recv, send_len), 0);
>  }
>  
> +/* Splicing into an open record whose plaintext scatterlist ring is already
> + * full used to wrap the ring's end index onto its start, after which
> + * sk_msg_full() reported the full ring as empty: further pages overwrote
> + * live entries and sg.size desynced from the walkable scatterlist, which
> + * oopsed in the AEAD walk once the record was pushed.  The ring is left
> + * full and unpushed by the copy path, which does not push the record when
> + * the fragment it adds is the one that fills the ring.
> + */

This comment (and the other one above the loop) duplicates contents of
the commit message. Please drop them.

> +TEST_F(tls, splice_onto_full_record)
> +{
> +	int frag_len = 100, extra = 4;

Why 4 extra splices? One should be enough to hit tls_sw_sendmsg_splice
with the skmsg already full?

> +	char mem_send[5000];
> +	char mem_recv[5000];
> +	int nfrags, i, total;
> +	int p[2];
> +
> +	memrnd(mem_send, sizeof(mem_send));
> +
> +	/* MAX_SKB_FRAGS is configurable (17 by default), so sweep the
> +	 * plausible range to land the one-byte send exactly on a full ring
> +	 * whatever this kernel was built with.
> +	 */
> +	for (nfrags = 12; nfrags <= 45; nfrags++) {
> +		total = (nfrags + extra) * frag_len + 2;
> +
> +		for (i = 0; i < nfrags; i++) {
> +			ASSERT_GE(pipe(p), 0);

Do we really need a fresh pipe for each iteration?

> +			EXPECT_EQ(write(p[1], mem_send, frag_len), frag_len);
> +			EXPECT_EQ(splice(p[0], NULL, self->fd, NULL, frag_len,
> +					 SPLICE_F_MORE), frag_len);
> +			close(p[0]);
> +			close(p[1]);
> +		}
> +
> +		EXPECT_EQ(send(self->fd, mem_send, 1, MSG_MORE), 1);
> +
> +		for (i = 0; i < extra; i++) {
> +			ASSERT_GE(pipe(p), 0);
> +			EXPECT_EQ(write(p[1], mem_send, frag_len), frag_len);
> +			EXPECT_EQ(splice(p[0], NULL, self->fd, NULL, frag_len,
> +					 SPLICE_F_MORE), frag_len);
> +			close(p[0]);
> +			close(p[1]);
> +		}
> +
> +		EXPECT_EQ(send(self->fd, mem_send, 1, 0), 1);
> +
> +		EXPECT_EQ(recv(self->cfd, mem_recv, total, MSG_WAITALL), total);
> +		EXPECT_EQ(memcmp(mem_send, mem_recv, frag_len), 0);

Only comparing the first chunk ("frag_len" bytes) and not the full blob
("total" bytes) isn't very useful.

> +	}
> +}
> +
>  TEST_F(tls, splice_to_pipe)
>  {
>  	int send_len = TLS_PAYLOAD_MAX_LEN;
> -- 
> 2.43.0
> 

-- 
Sabrina

  reply	other threads:[~2026-07-27 11:55 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-26 10:55 [PATCH net 0/2] tls: fix plaintext sk_msg ring over-fill in tls_sw_sendmsg_splice() chanyoung
2026-07-26 10:55 ` [PATCH net 1/2] tls: don't over-fill the plaintext sk_msg ring " chanyoung
2026-07-27 10:30   ` Sabrina Dubroca
2026-07-27 12:58     ` chanyoung
2026-07-26 10:55 ` [PATCH net 2/2] selftests: tls: add a test for splicing onto a full plaintext record chanyoung
2026-07-27 11:55   ` Sabrina Dubroca [this message]
2026-07-27 12:59     ` chanyoung

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=amdHFJlOVpACBir6@krikkit \
    --to=sd@queasysnail.net \
    --cc=dhowells@redhat.com \
    --cc=john.fastabend@gmail.com \
    --cc=kuba@kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=ppoo1220@gmail.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.