From: 배석진 <soukjin.bae@samsung.com>
To: Eric Dumazet <eric.dumazet@gmail.com>,
"netdev@vger.kernel.org" <netdev@vger.kernel.org>
Subject: RE:(2) (2) (2) [Kernel][NET] Bug report on packet defragmenting
Date: Thu, 08 Nov 2018 16:58:37 +0900 [thread overview]
Message-ID: <20181108075837epcms1p2747d212aee83ba0df60cc14ffac316aa@epcms1p2> (raw)
In-Reply-To: <b03af88f-8f18-bdac-ae64-c3c0688008d3@gmail.com>
>--------- Original Message ---------
>Sender : Eric Dumazet <eric.dumazet@gmail.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@gmail.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
next prev parent reply other threads:[~2018-11-08 17:33 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CGME20181108012927epcms1p47f719c1908da64a378690362901644ee@epcms1p4>
2018-11-08 1:29 ` [Kernel][NET] Bug report on packet defragmenting 배석진
2018-11-08 1:43 ` Eric Dumazet
2018-11-08 2:05 ` 배석진
2018-11-08 3:24 ` (2) " Eric Dumazet
2018-11-08 3:56 ` Eric Dumazet
2018-11-08 4:10 ` 배석진
2018-11-08 4:26 ` (2) " Eric Dumazet
2018-11-08 6:13 ` Eric Dumazet
2018-11-08 7:58 ` 배석진 [this message]
2018-11-08 15:12 ` (2) " Eric Dumazet
2018-11-09 0:42 ` 배석진
2018-11-09 1:58 ` (2) " Eric Dumazet
2018-11-09 2:24 ` 배석진
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20181108075837epcms1p2747d212aee83ba0df60cc14ffac316aa@epcms1p2 \
--to=soukjin.bae@samsung.com \
--cc=eric.dumazet@gmail.com \
--cc=netdev@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox