netdev - Re: (2) [Kernel][NET] Bug report on packet defragmenting

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: <eca6b22e-1c8d-d62a-6632-c7e7ffb180c2@gmail.com>
Date:   Wed, 7 Nov 2018 19:24:48 -0800
From:   Eric Dumazet <eric.dumazet@...il.com>
To:     soukjin.bae@...sung.com, Eric Dumazet <eric.dumazet@...il.com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: (2) [Kernel][NET] Bug report on packet defragmenting



On 11/07/2018 06:05 PM, 배석진 wrote:
>  --------- Original Message ---------
> Sender : Eric Dumazet <eric.dumazet@...il.com>
> Date   : 2018-11-08 10:44 (GMT+9)
> Title  : Re: [Kernel][NET] Bug report on packet defragmenting
>  
>> On 11/07/2018 05:29 PM, 배석진 wrote:
>>  
>>> If ipv6_defrag hook is not excuted simultaneously, then it's ok.
>>> ipv6_defrag hook can handle that. [exam 3]
>>  
>> This seems wrong.
>>  
>> This is the root cause, we should not try to work around it but fix it.
>>  
>> There is no guarantee that RSS/RPS/RFS can help here, packets can sit in per-cpu
>> backlogs long enough to reproduce the issue, if RX queues interrupts are spread
>> over many cpus.
>  
> 
> Dear Dumazet,
> 
> Even if rx irq be spread to overal cpu, hash will be made by src/des address.
> then they'll have a same hash and cpu. is it not enough?
> Did you mean that we need total solution for all steering method? not just only RPS?
> 

IPv6 defrag unit should work all the times, even if 10 cpus have to feed fragments for the same
datagram at the same time.

RPS is just a hint to spread packets on different cpus.

Basically we could have the following patch and everything must still work properly
(presumably at lower performance, if RPS/RFS is any good, of course)

diff --git a/net/core/dev.c b/net/core/dev.c
index 0ffcbdd55fa9ee545c807f2ed3fc178830e3075a..c1269bb0d6c86b097cfff2d8395d8cbf2d596537 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -4036,7 +4036,7 @@ static int get_rps_cpu(struct net_device *dev, struct sk_buff *skb,
                goto done;
 
        skb_reset_network_header(skb);
-       hash = skb_get_hash(skb);
+       hash = prandom_u32();
        if (!hash)
                goto done;
 


Sure, it is better if RPS is smarter, but if there is a bug in IPv6 defrag unit
we must investigate and root-cause it.