linux-kernel - Re: [PATCH net-next v4 8/9] tap: Keep hdr_len in tap_get

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <678fb1c3d123b_23e15a2946c@willemb.c.googlers.com.notmuch>
Date: Tue, 21 Jan 2025 09:40:03 -0500
From: Willem de Bruijn <willemdebruijn.kernel@...il.com>
To: Akihiko Odaki <akihiko.odaki@...nix.com>, 
 Willem de Bruijn <willemdebruijn.kernel@...il.com>, 
 Jonathan Corbet <corbet@....net>, 
 Jason Wang <jasowang@...hat.com>, 
 "David S. Miller" <davem@...emloft.net>, 
 Eric Dumazet <edumazet@...gle.com>, 
 Jakub Kicinski <kuba@...nel.org>, 
 Paolo Abeni <pabeni@...hat.com>, 
 "Michael S. Tsirkin" <mst@...hat.com>, 
 Xuan Zhuo <xuanzhuo@...ux.alibaba.com>, 
 Shuah Khan <shuah@...nel.org>, 
 linux-doc@...r.kernel.org, 
 linux-kernel@...r.kernel.org, 
 netdev@...r.kernel.org, 
 kvm@...r.kernel.org, 
 virtualization@...ts.linux-foundation.org, 
 linux-kselftest@...r.kernel.org, 
 Yuri Benditovich <yuri.benditovich@...nix.com>, 
 Andrew Melnychenko <andrew@...nix.com>, 
 Stephen Hemminger <stephen@...workplumber.org>, 
 gur.stavi@...wei.com, 
 devel@...nix.com
Subject: Re: [PATCH net-next v4 8/9] tap: Keep hdr_len in tap_get_user()

Akihiko Odaki wrote:
> On 2025/01/20 20:24, Willem de Bruijn wrote:
> > Akihiko Odaki wrote:
> >> hdr_len is repeatedly used so keep it in a local variable.
> >>
> >> Signed-off-by: Akihiko Odaki <akihiko.odaki@...nix.com>
> >> ---
> >>   drivers/net/tap.c | 17 +++++++----------
> >>   1 file changed, 7 insertions(+), 10 deletions(-)
> >>
> >> diff --git a/drivers/net/tap.c b/drivers/net/tap.c
> >> index 061c2f27dfc83f5e6d0bea4da0e845cc429b1fd8..7ee2e9ee2a89fd539b087496b92d2f6198266f44 100644
> >> --- a/drivers/net/tap.c
> >> +++ b/drivers/net/tap.c
> >> @@ -645,6 +645,7 @@ static ssize_t tap_get_user(struct tap_queue *q, void *msg_control,
> >>   	int err;
> >>   	struct virtio_net_hdr vnet_hdr = { 0 };
> >>   	int vnet_hdr_len = 0;
> >> +	int hdr_len = 0;
> >>   	int copylen = 0;
> >>   	int depth;
> >>   	bool zerocopy = false;
> >> @@ -672,6 +673,7 @@ static ssize_t tap_get_user(struct tap_queue *q, void *msg_control,
> >>   		err = -EINVAL;
> >>   		if (tap16_to_cpu(q, vnet_hdr.hdr_len) > iov_iter_count(from))
> >>   			goto err;
> >> +		hdr_len = tap16_to_cpu(q, vnet_hdr.hdr_len);
> >>   	}
> >>   
> >>   	len = iov_iter_count(from);
> >> @@ -683,11 +685,8 @@ static ssize_t tap_get_user(struct tap_queue *q, void *msg_control,
> >>   	if (msg_control && sock_flag(&q->sk, SOCK_ZEROCOPY)) {
> >>   		struct iov_iter i;
> >>   
> >> -		copylen = vnet_hdr.hdr_len ?
> >> -			tap16_to_cpu(q, vnet_hdr.hdr_len) : GOODCOPY_LEN;
> >> -		if (copylen > good_linear)
> >> -			copylen = good_linear;
> >> -		else if (copylen < ETH_HLEN)
> >> +		copylen = min(hdr_len ? hdr_len : GOODCOPY_LEN, good_linear);
> >> +		if (copylen < ETH_HLEN)
> >>   			copylen = ETH_HLEN;
> >>   		linear = copylen;
> >>   		i = *from;
> >> @@ -698,11 +697,9 @@ static ssize_t tap_get_user(struct tap_queue *q, void *msg_control,
> >>   
> >>   	if (!zerocopy) {
> >>   		copylen = len;
> >> -		linear = tap16_to_cpu(q, vnet_hdr.hdr_len);
> >> -		if (linear > good_linear)
> >> -			linear = good_linear;
> >> -		else if (linear < ETH_HLEN)
> >> -			linear = ETH_HLEN;
> >> +		linear = min(hdr_len, good_linear);
> >> +		if (copylen < ETH_HLEN)
> >> +			copylen = ETH_HLEN;
> > 
> > Similar to previous patch, I don't think this patch is significant
> > enough to warrant the code churn.
> 
> The following patch will require replacing
> tap16_to_cpu(q, vnet_hdr.hdr_len)
> with
> tap16_to_cpu(q->flags, vnet_hdr.hdr_len)
>
> It will make some lines a bit too long. Calling tap16_to_cpu() at 
> multiple places is also not good to keep the vnet implementation unified 
> as the function inspects vnet_hdr.
> 
> This patch is independently too trivial, but I think it is a worthwhile 
> cleanup combined with the following patch.

Ok. I see what you mean.