From: Simon Horman <simon.horman@corigine.com>
To: David Howells <dhowells@redhat.com>
Cc: netdev@vger.kernel.org,
Linus Torvalds <torvalds@linux-foundation.org>,
Chuck Lever <chuck.lever@oracle.com>,
Boris Pismenny <borisp@nvidia.com>,
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>,
Willem de Bruijn <willemdebruijn.kernel@gmail.com>,
David Ahern <dsahern@kernel.org>,
Matthew Wilcox <willy@infradead.org>,
Jens Axboe <axboe@kernel.dk>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
Dan Carpenter <dan.carpenter@linaro.org>
Subject: Re: [PATCH net-next v3 03/11] tls/sw: Use zero-length sendmsg() without MSG_MORE to flush
Date: Fri, 2 Jun 2023 20:27:56 +0200 [thread overview]
Message-ID: <ZHo0rNlhJCRE4msb@corigine.com> (raw)
In-Reply-To: <20230602150752.1306532-4-dhowells@redhat.com>
+ dan Carpenter
On Fri, Jun 02, 2023 at 04:07:44PM +0100, David Howells wrote:
> Allow userspace to end a TLS record without supplying any data by calling
> send()/sendto()/sendmsg() with no data and no MSG_MORE flag. This can be
> used to flush a previous send/splice that had MSG_MORE or SPLICE_F_MORE set
> or a sendfile() that was incomplete.
>
> Without this, a zero-length send to tls-sw is just ignored. I think
> tls-device will do the right thing without modification.
>
> Signed-off-by: David Howells <dhowells@redhat.com>
> cc: Chuck Lever <chuck.lever@oracle.com>
> cc: Boris Pismenny <borisp@nvidia.com>
> cc: John Fastabend <john.fastabend@gmail.com>
> cc: Jakub Kicinski <kuba@kernel.org>
> cc: Eric Dumazet <edumazet@google.com>
> cc: "David S. Miller" <davem@davemloft.net>
> cc: Paolo Abeni <pabeni@redhat.com>
> cc: Jens Axboe <axboe@kernel.dk>
> cc: Matthew Wilcox <willy@infradead.org>
> cc: netdev@vger.kernel.org
> ---
> net/tls/tls_sw.c | 6 +++++-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/net/tls/tls_sw.c b/net/tls/tls_sw.c
> index cac1adc968e8..6aa6d17888f5 100644
> --- a/net/tls/tls_sw.c
> +++ b/net/tls/tls_sw.c
> @@ -945,7 +945,7 @@ int tls_sw_sendmsg(struct sock *sk, struct msghdr *msg, size_t size)
> struct tls_rec *rec;
> int required_size;
> int num_async = 0;
> - bool full_record;
> + bool full_record = false;
> int record_room;
> int num_zc = 0;
> int orig_size;
> @@ -971,6 +971,9 @@ int tls_sw_sendmsg(struct sock *sk, struct msghdr *msg, size_t size)
> }
> }
>
> + if (!msg_data_left(msg) && eor)
> + goto just_flush;
> +
Hi David,
the flow of this function is not entirely simple, so it is not easy for me
to manually verify this. But in combination gcc-12 -Wmaybe-uninitialized
and Smatch report that the following may be used uninitialised as a result
of this change:
* msg_pl
* orig_size
* msg_en
* required_size
* try_to_copy
> while (msg_data_left(msg)) {
> if (sk->sk_err) {
> ret = -sk->sk_err;
> @@ -1082,6 +1085,7 @@ int tls_sw_sendmsg(struct sock *sk, struct msghdr *msg, size_t size)
> */
> tls_ctx->pending_open_record_frags = true;
> copied += try_to_copy;
> +just_flush:
> if (full_record || eor) {
> ret = bpf_exec_tx_verdict(msg_pl, sk, full_record,
> record_type, &copied,
>
>
next prev parent reply other threads:[~2023-06-02 18:28 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-06-02 15:07 [PATCH net-next v3 00/11] splice, net: Rewrite splice-to-socket, fix SPLICE_F_MORE and handle MSG_SPLICE_PAGES in AF_TLS David Howells
2023-06-02 15:07 ` [PATCH net-next v3 01/11] net: Block MSG_SENDPAGE_* from being passed to sendmsg() by userspace David Howells
2023-06-02 15:07 ` [PATCH net-next v3 02/11] tls: Allow MSG_SPLICE_PAGES but treat it as normal sendmsg David Howells
2023-06-02 15:07 ` [PATCH net-next v3 03/11] tls/sw: Use zero-length sendmsg() without MSG_MORE to flush David Howells
2023-06-02 18:27 ` Simon Horman [this message]
2023-06-02 19:00 ` Dan Carpenter
2023-06-03 14:51 ` Simon Horman
2023-06-02 15:07 ` [PATCH net-next v3 04/11] splice, net: Use sendmsg(MSG_SPLICE_PAGES) rather than ->sendpage() David Howells
2023-06-02 15:07 ` [PATCH net-next v3 05/11] splice, net: Fix SPLICE_F_MORE signalling in splice_direct_to_actor() David Howells
2023-06-02 16:36 ` Linus Torvalds
2023-06-02 15:07 ` [PATCH net-next v3 06/11] tls: Address behaviour change in multi_chunk_sendfile kselftest David Howells
2023-06-02 15:07 ` [PATCH net-next v3 07/11] tls/sw: Support MSG_SPLICE_PAGES David Howells
2023-06-02 15:07 ` [PATCH net-next v3 08/11] tls/sw: Convert tls_sw_sendpage() to use MSG_SPLICE_PAGES David Howells
2023-06-02 15:07 ` [PATCH net-next v3 09/11] tls/device: Support MSG_SPLICE_PAGES David Howells
2023-06-02 15:07 ` [PATCH net-next v3 10/11] tls/device: Convert tls_device_sendpage() to use MSG_SPLICE_PAGES David Howells
2023-06-02 15:07 ` [PATCH net-next v3 11/11] net: Add samples for network I/O and splicing David Howells
2023-06-03 6:38 ` 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=ZHo0rNlhJCRE4msb@corigine.com \
--to=simon.horman@corigine.com \
--cc=axboe@kernel.dk \
--cc=borisp@nvidia.com \
--cc=chuck.lever@oracle.com \
--cc=dan.carpenter@linaro.org \
--cc=davem@davemloft.net \
--cc=dhowells@redhat.com \
--cc=dsahern@kernel.org \
--cc=edumazet@google.com \
--cc=john.fastabend@gmail.com \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=torvalds@linux-foundation.org \
--cc=willemdebruijn.kernel@gmail.com \
--cc=willy@infradead.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.