From: Jakub Kicinski <kuba@kernel.org>
To: Sabrina Dubroca <sd@queasysnail.net>
Cc: netdev@vger.kernel.org, Boris Pismenny <borisp@nvidia.com>,
John Fastabend <john.fastabend@gmail.com>,
"David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Paolo Abeni <pabeni@redhat.com>, Shuah Khan <shuah@kernel.org>,
Vakul Garg <vakul.garg@nxp.com>,
linux-kselftest@vger.kernel.org
Subject: Re: [PATCH net 3/5] tls: don't skip over different type records from the rx_list
Date: Wed, 21 Feb 2024 10:33:30 -0800 [thread overview]
Message-ID: <20240221103330.2ae35871@kernel.org> (raw)
In-Reply-To: <ZdYBzKcmIorAO47N@hog>
On Wed, 21 Feb 2024 14:59:40 +0100 Sabrina Dubroca wrote:
> It's not exactly enough, since tls_record_content_type will return 0
> on a content type mismatch. We'll have to translate that into an
> "error".
Ugh, that's unpleasant.
> I think it would be a bit nicer to set err=1 and then check
> err != 0 in tls_sw_recvmsg (we can document that in a comment above
> process_rx_list) rather than making up a fake errno. See diff [1].
>
> Or we could swap the 0/1 returns from tls_record_content_type and
> switch the err <= 0 tests to err != 0 after the existing calls, then
> process_rx_list doesn't have a weird special case [2].
>
> What do you think?
I missed the error = 1 case, sorry. No strong preference, then.
Checking for error = 1 will be as special as the new rx_more
flag. Should I apply this version as is, then?
next prev parent reply other threads:[~2024-02-21 18:33 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-15 16:17 [PATCH net 0/5] tls: fixes for record type handling with PEEK Sabrina Dubroca
2024-02-15 16:17 ` [PATCH net 1/5] tls: break out of main loop when PEEK gets a non-data record Sabrina Dubroca
2024-02-15 16:17 ` [PATCH net 2/5] tls: stop recv() if initial process_rx_list gave us non-DATA Sabrina Dubroca
2024-02-15 16:17 ` [PATCH net 3/5] tls: don't skip over different type records from the rx_list Sabrina Dubroca
2024-02-19 20:07 ` Jakub Kicinski
2024-02-19 23:10 ` Sabrina Dubroca
2024-02-21 1:50 ` Jakub Kicinski
2024-02-21 13:59 ` Sabrina Dubroca
2024-02-21 18:33 ` Jakub Kicinski [this message]
2024-02-21 18:42 ` Sabrina Dubroca
2024-02-15 16:17 ` [PATCH net 4/5] selftests: tls: add test for merging of same-type control messages Sabrina Dubroca
2024-02-15 16:17 ` [PATCH net 5/5] selftests: tls: add test for peeking past a record of a different type Sabrina Dubroca
2024-02-21 22:30 ` [PATCH net 0/5] tls: fixes for record type handling with PEEK patchwork-bot+netdevbpf
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=20240221103330.2ae35871@kernel.org \
--to=kuba@kernel.org \
--cc=borisp@nvidia.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=john.fastabend@gmail.com \
--cc=linux-kselftest@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=sd@queasysnail.net \
--cc=shuah@kernel.org \
--cc=vakul.garg@nxp.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 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.