netdev - Re: [PATCH] tcp_nv: fix division by zero in tcpnv

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: <20171101151351.42e699cf@shemminger-XPS-13-9360>
Date:   Wed, 1 Nov 2017 15:13:51 +0100
From:   Stephen Hemminger <stephen@...workplumber.org>
To:     Lawrence Brakmo <brakmo@...com>
Cc:     Konstantin Khlebnikov <khlebnikov@...dex-team.ru>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "David S. Miller" <davem@...emloft.net>,
        Alexey Kuznetsov <kuznet@....inr.ac.ru>,
        Hideaki YOSHIFUJI <yoshfuji@...ux-ipv6.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] tcp_nv: fix division by zero in tcpnv_acked()

On Wed, 1 Nov 2017 13:47:17 +0000
Lawrence Brakmo <brakmo@...com> wrote:

> Thank you for finding and fixing this.
> 
> On 11/1/17, 6:32 AM, "Konstantin Khlebnikov" <khlebnikov@...dex-team.ru> wrote:
> 
>     Average RTT could become zero. This happened in real life at least twice.
>     This patch treats zero as 1us.
>     
>     Signed-off-by: Konstantin Khlebnikov khlebnikov@...dex-team.ru
> Acked-by: Lawrence Brakmo <Brakmo@...com>
>     ---
>      net/ipv4/tcp_nv.c |    2 +-
>      1 file changed, 1 insertion(+), 1 deletion(-)
>     
>     diff --git a/net/ipv4/tcp_nv.c b/net/ipv4/tcp_nv.c
>     index 1ff73982e28c..125fc1450b01 100644
>     --- a/net/ipv4/tcp_nv.c
>     +++ b/net/ipv4/tcp_nv.c
>     @@ -252,7 +252,7 @@ static void tcpnv_acked(struct sock *sk, const struct ack_sample *sample)
>      
>      	/* rate in 100's bits per second */
>      	rate64 = ((u64)sample->in_flight) * 8000000;
>     -	rate = (u32)div64_u64(rate64, (u64)(avg_rtt * 100));
>     +	rate = (u32)div64_u64(rate64, (u64)(avg_rtt ?: 1) * 100);

Why is this code using expensive 64 bit by 64 bit divide when avg_rtt should never be bigger
than 32 bits?