From: Jakub Kicinski <kuba@kernel.org>
To: Sabrina Dubroca <sd@queasysnail.net>
Cc: Wilfred Mallawa <wilfred.opensource@gmail.com>,
davem@davemloft.net, edumazet@google.com, pabeni@redhat.com,
horms@kernel.org, corbet@lwn.net, john.fastabend@gmail.com,
netdev@vger.kernel.org, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org, alistair.francis@wdc.com,
dlemoal@kernel.org, Wilfred Mallawa <wilfred.mallawa@wdc.com>
Subject: Re: [PATCH v3] net/tls: support maximum record size limit
Date: Thu, 4 Sep 2025 06:33:44 -0700 [thread overview]
Message-ID: <20250904063344.6507fcc6@kernel.org> (raw)
In-Reply-To: <aLllqGpa2gLVNRbw@krikkit>
On Thu, 4 Sep 2025 12:10:48 +0200 Sabrina Dubroca wrote:
> If we set tx_record_size_limit to TLS_MAX_PAYLOAD_SIZE+1, we'll end up
> sending a record with a plaintext of TLS_MAX_PAYLOAD_SIZE+2 bytes
> (TLS_MAX_PAYLOAD_SIZE+1 of payload, then 1B of content_type), and a
> "normal" implementation will reject the record since it's too big
> (ktls does that in net/tls/tls_sw.c:tls_rx_msg_size).
>
> So we should subtract 1 from the userspace-provided value for 1.3, and
> then add it back in getsockopt/tls_get_info.
>
> Or maybe userspace should provide the desired payload limit, instead
> of the raw record_size_limit it got from the extension (ie, do -1 when
> needed before calling the setsockopt). Then we should rename this
> "tx_payload_size_limit" (and adjust the docs) to make it clear it's
> not the raw record_size_limit.
>
> The "tx_payload_size_limit" approach is maybe a little bit simpler
> (not having to add/subtract 1 in a few places - I think userspace
> would only have to do it in one place).
>
>
> Wilfred, Jakub, what do you think?
I reckon either way is fine, assuming we clearly document the behavior.
I'd lean slightly to using the same definition of the setsockopt as the
RFC, it may be confusing but if it ever interacts with other settings
it may make it easier to refer to other RFCs.
next prev parent reply other threads:[~2025-09-04 13:33 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-03 1:47 [PATCH v3] net/tls: support maximum record size limit Wilfred Mallawa
2025-09-03 10:14 ` Sabrina Dubroca
2025-09-04 9:54 ` Sabrina Dubroca
2025-09-18 0:52 ` Wilfred Mallawa
2025-09-03 22:51 ` Jakub Kicinski
2025-09-04 23:41 ` Wilfred Mallawa
2025-09-04 10:10 ` Sabrina Dubroca
2025-09-04 13:33 ` Jakub Kicinski [this message]
2025-09-18 1:42 ` Wilfred Mallawa
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=20250904063344.6507fcc6@kernel.org \
--to=kuba@kernel.org \
--cc=alistair.francis@wdc.com \
--cc=corbet@lwn.net \
--cc=davem@davemloft.net \
--cc=dlemoal@kernel.org \
--cc=edumazet@google.com \
--cc=horms@kernel.org \
--cc=john.fastabend@gmail.com \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=sd@queasysnail.net \
--cc=wilfred.mallawa@wdc.com \
--cc=wilfred.opensource@gmail.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).