netdev - Re: [net-next PATCH 1/5] udp: Record gso_segs when supporting UDP segmentation offload

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <ecc3cc22-5e81-a4e5-46c4-cd30687f0358@gmail.com>
Date:   Thu, 3 May 2018 18:50:05 -0700
From:   Eric Dumazet <eric.dumazet@...il.com>
To:     Alexander Duyck <alexander.duyck@...il.com>,
        netdev@...r.kernel.org, willemb@...gle.com, davem@...emloft.net
Subject: Re: [net-next PATCH 1/5] udp: Record gso_segs when supporting UDP
 segmentation offload



On 05/03/2018 05:33 PM, Alexander Duyck wrote:
> From: Alexander Duyck <alexander.h.duyck@...el.com>
> 
> We need to record the number of segments that will be generated when this
> frame is segmented. The expectation is that if gso_size is set then
> gso_segs is set as well. Without this some drivers such as ixgbe get
> confused if they attempt to offload this as they record 0 segments for the
> entire packet instead of the correct value.
> 
> Signed-off-by: Alexander Duyck <alexander.h.duyck@...el.com>
> ---
>  net/ipv4/udp.c |    2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/net/ipv4/udp.c b/net/ipv4/udp.c
> index dd3102a37ef9..e07db83b311e 100644
> --- a/net/ipv4/udp.c
> +++ b/net/ipv4/udp.c
> @@ -793,6 +793,8 @@ static int udp_send_skb(struct sk_buff *skb, struct flowi4 *fl4,
>  
>  		skb_shinfo(skb)->gso_size = cork->gso_size;
>  		skb_shinfo(skb)->gso_type = SKB_GSO_UDP_L4;
> +		skb_shinfo(skb)->gso_segs = DIV_ROUND_UP(len - sizeof(uh),
> +							 cork->gso_size);
>  		goto csum_partial;
>  	}
>  
> 

Yes, this also fixes qdisc_pkt_len_init()

Reviewed-by: Eric Dumazet <edumazet@...gle.com>