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, 08 Nov 2018 16:58:37 +0900
From:   배석진 <soukjin.bae@...sung.com>
To:     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

>--------- 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