[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZHo0rNlhJCRE4msb@corigine.com>
Date: Fri, 2 Jun 2023 20:27:56 +0200
From: Simon Horman <simon.horman@...igine.com>
To: David Howells <dhowells@...hat.com>
Cc: netdev@...r.kernel.org,
Linus Torvalds <torvalds@...ux-foundation.org>,
Chuck Lever <chuck.lever@...cle.com>,
Boris Pismenny <borisp@...dia.com>,
John Fastabend <john.fastabend@...il.com>,
Jakub Kicinski <kuba@...nel.org>,
"David S. Miller" <davem@...emloft.net>,
Eric Dumazet <edumazet@...gle.com>,
Paolo Abeni <pabeni@...hat.com>,
Willem de Bruijn <willemdebruijn.kernel@...il.com>,
David Ahern <dsahern@...nel.org>,
Matthew Wilcox <willy@...radead.org>,
Jens Axboe <axboe@...nel.dk>, linux-mm@...ck.org,
linux-kernel@...r.kernel.org,
Dan Carpenter <dan.carpenter@...aro.org>
Subject: Re: [PATCH net-next v3 03/11] tls/sw: Use zero-length sendmsg()
without MSG_MORE to flush
+ 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@...hat.com>
> cc: Chuck Lever <chuck.lever@...cle.com>
> cc: Boris Pismenny <borisp@...dia.com>
> cc: John Fastabend <john.fastabend@...il.com>
> cc: Jakub Kicinski <kuba@...nel.org>
> cc: Eric Dumazet <edumazet@...gle.com>
> cc: "David S. Miller" <davem@...emloft.net>
> cc: Paolo Abeni <pabeni@...hat.com>
> cc: Jens Axboe <axboe@...nel.dk>
> cc: Matthew Wilcox <willy@...radead.org>
> cc: netdev@...r.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,
>
>
Powered by blists - more mailing lists