netdev - Re: (2) (2) (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]
Date:   Thu, 8 Nov 2018 07:12:29 -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) (2) (2) [Kernel][NET] Bug report on packet defragmenting



On 11/07/2018 11:58 PM, 배석진 wrote:
>> --------- Original Message ---------
>> Sender : Eric Dumazet <eric.dumazet@...il.com>
>> Date   : 2018-11-08 15:13 (GMT+9)
>> Title  : Re: (2) (2) [Kernel][NET] Bug report on packet defragmenting
>>  
>> On 11/07/2018 08:26 PM, Eric Dumazet wrote:
>>>  
>>>  
>>>  On 11/07/2018 08:10 PM, 배석진 wrote:
>>>>>  --------- Original Message ---------
>>>>>  Sender : Eric Dumazet <eric.dumazet@...il.com>
>>>>>  Date   : 2018-11-08 12:57 (GMT+9)
>>>>>  Title  : Re: (2) [Kernel][NET] Bug report on packet defragmenting
>>>>>   
>>>>>  On 11/07/2018 07:24 PM, Eric Dumazet wrote:
>>>>>
>>>>>>   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.
>>>>>   
>>>>>  BTW, IPv4 defrag seems to have the same issue.
>>>>   
>>>>
>>>>  yes, it could be.
>>>>  key point isn't limitted to ipv6.
>>>>
>>>>  maybe because of faster air-network and modem,
>>>>  it looks like occure more often and we got recognized that.
>>>>
>>>>  anyway,
>>>>  we'll apply our patch to resolve this problem.
>>>  
>>>  Yeah, and I will fix the defrag units.
>>>
>>>  We can not rely on other layers doing proper no-reorder logic for us.
>>>  
>>>  Problem here is that multiple cpus attempt concurrent rhashtable_insert_fast()
>>>  and do not properly recover in case -EEXIST is returned.
>>>  
>>>  This is silly, of course :/
>>  
>> Patch would be https://patchwork.ozlabs.org/patch/994658/
>  
> 
> Dear Dumazet,
> 
> with your patch, kernel got the panic when packet recieved.
> I double checked after disable your patch, then no problem.
> 
> 
> <6>[  119.702054] I[3:  kworker/u18:1: 1705] LNK-RX(1464): 6b 80 00 00 05 90 2c 3e 20 01 44 30 00 05 04 01 ...
> <6>[  119.702120] I[3:  kworker/u18:1: 1705] __skb_flow_dissect: ports: 77500000
> <6>[  119.702153] I[3:  kworker/u18:1: 1705] get_rps_cpu: cpu:2, hash:2055028308
> <6>[  119.702203] I[3:  kworker/u18:1: 1705] LNK-RX(1212): 6b 80 00 00 04 94 2c 3e 20 01 44 30 00 05 04 01 ...
> <6>[  119.702231] I[3:  kworker/u18:1: 1705] __skb_flow_dissect: ports: 3c7e2c6b
> <6>[  119.702258] I[3:  kworker/u18:1: 1705] get_rps_cpu: cpu:1, hash:671343869
> <6>[  119.702365] I[1: Binder:11369_2:11382] ipv6_rcv +++
> <6>[  119.702375] I[2:      swapper/2:    0] ipv6_rcv +++
> <6>[  119.702406] I[2:      swapper/2:    0] ipv6_defrag +++
> <6>[  119.702425] I[1: Binder:11369_2:11382] ipv6_defrag +++
> <6>[  119.702494] I[2:      swapper/2:    0] ipv6_defrag: EINPROGRESS
> <6>[  119.702522] I[2:      swapper/2:    0] ipv6_rcv ---
> <6>[  119.702628] I[1: Binder:11369_2:11382] ipv6_defrag ---
> <6>[  119.702892] I[1: Binder:11369_2:11382] ipv6_defrag +++
> <6>[  119.702922] I[1: Binder:11369_2:11382] ipv6_defrag ---
> <6>[  119.702966] I[1: Binder:11369_2:11382] ipv6_rcv ---
> <0>[  119.703792]  [1: Binder:11369_2:11382] BUG: sleeping function called from invalid context at arch/arm64/mm/fault.c:518
> <3>[  119.703826]  [1: Binder:11369_2:11382] in_atomic(): 0, irqs_disabled(): 0, pid: 11382, name: Binder:11369_2
> <3>[  119.703854]  [1: Binder:11369_2:11382] Preemption disabled at:
> <4>[  119.703888]  [1: Binder:11369_2:11382] [<ffffff80080b13d4>] __do_softirq+0x68/0x3c4
> <4>[  119.703934]  [1: Binder:11369_2:11382] CPU: 1 PID: 11382 Comm: Binder:11369_2 Tainted: G S      W       4.14.75-20181108-163447-eng #0
> <4>[  119.703960]  [1: Binder:11369_2:11382] Hardware name: Samsung BEYOND2LTE KOR SINGLE 19 board based on EXYNOS9820 (DT)
> <4>[  119.703987]  [1: Binder:11369_2:11382] Call trace:
> <4>[  119.704015]  [1: Binder:11369_2:11382] [<ffffff80080bd87c>] dump_backtrace+0x0/0x280
> <4>[  119.704045]  [1: Binder:11369_2:11382] [<ffffff80080bddd4>] show_stack+0x18/0x24
> <4>[  119.704074]  [1: Binder:11369_2:11382] [<ffffff80090bb3f8>] dump_stack+0xb8/0xf8
> <4>[  119.704104]  [1: Binder:11369_2:11382] [<ffffff800811f180>] ___might_sleep+0x16c/0x178
> <4>[  119.704132]  [1: Binder:11369_2:11382] [<ffffff800811efdc>] __might_sleep+0x4c/0x84
> <4>[  119.704164]  [1: Binder:11369_2:11382] [<ffffff80090dcf60>] do_page_fault+0x2e8/0x4b8
> <4>[  119.704193]  [1: Binder:11369_2:11382] [<ffffff80090dcbf4>] do_translation_fault+0x7c/0x100
> <4>[  119.704219]  [1: Binder:11369_2:11382] [<ffffff80080b0d70>] do_mem_abort+0x4c/0x12c
> <4>[  119.704243]  [1: Binder:11369_2:11382] Exception stack(0xffffff8038bf3ec0 to 0xffffff8038bf4000)
> <4>[  119.704266]  [1: Binder:11369_2:11382] 3ec0: 00000077b8262600 00000077b1bd0800 00000000708fcae0 0000000000000018
> ...
> <4>[  119.704459]  [1: Binder:11369_2:11382] 3fe0: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
> <4>[  119.704480]  [1: Binder:11369_2:11382] [<ffffff80080b33d0>] el0_da+0x20/0x24
> <4>[  119.704509]  [1: Binder:11369_2:11382] ------------[ cut here ]------------
> <0>[  119.704541]  [1: Binder:11369_2:11382] kernel BUG at kernel/sched/core.c:6152!
> <2>[  119.704563]  [1: Binder:11369_2:11382] sec_debug_set_extra_info_fault = BUG / 0xffffff800811f180
> <0>[  119.704603]  [1: Binder:11369_2:11382] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP
> 
> 

Thanks for testing.

This is not a pristine net-next tree, this dump seems unrelated to the patch ?