Re: INFO: task hung in bpf_exit_net

9 messages, 5 authors, 2018-02-02 · open the first message on its own page

Re: INFO: task hung in bpf_exit_net

From: Dmitry Vyukov <dvyukov@google.com>
Date: 2017-12-19 12:48:20

On Tue, Dec 19, 2017 at 1:36 PM, syzbot
[off-list ref]
wrote:
Hello,

syzkaller hit the following crash on
7ceb97a071e80f1b5e4cd5a36de135612a836388
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/master
compiler: gcc (GCC) 7.1.1 20170620
.config is attached
Raw console output is attached.

Unfortunately, I don't have any reproducer for this bug yet.


sctp: sctp_transport_update_pmtu: Reported pmtu 508 too low, using default
minimum of 512
INFO: task kworker/u4:0:5 blocked for more than 120 seconds.
      Not tainted 4.15.0-rc2-next-20171205+ #59
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
kworker/u4:0    D15808     5      2 0x80000000
Workqueue: netns cleanup_net
Call Trace:
 context_switch kernel/sched/core.c:2800 [inline]
 __schedule+0x8eb/0x2060 kernel/sched/core.c:3376
 schedule+0xf5/0x430 kernel/sched/core.c:3435
 schedule_preempt_disabled+0x10/0x20 kernel/sched/core.c:3493
 __mutex_lock_common kernel/locking/mutex.c:833 [inline]
 __mutex_lock+0xaad/0x1a80 kernel/locking/mutex.c:893
 mutex_lock_nested+0x16/0x20 kernel/locking/mutex.c:908
 rtnl_lock+0x17/0x20 net/core/rtnetlink.c:74
 tc_action_net_exit include/net/act_api.h:125 [inline]
 bpf_exit_net+0x1a2/0x340 net/sched/act_bpf.c:408
 ops_exit_list.isra.6+0xae/0x150 net/core/net_namespace.c:142
 cleanup_net+0x5c7/0xb60 net/core/net_namespace.c:484
 process_one_work+0xbfd/0x1bc0 kernel/workqueue.c:2113
 worker_thread+0x223/0x1990 kernel/workqueue.c:2247
 kthread+0x37a/0x440 kernel/kthread.c:238
 ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:517

Showing all locks held in the system:
4 locks held by kworker/u4:0/5:
 #0:  ((wq_completion)"%s""netns"){+.+.}, at: [<00000000b9f061a2>]

195 more quoted lines


This looks like +rtnetlink issue.

Re: INFO: task hung in bpf_exit_net

From: Xin Long <lucien.xin@gmail.com>
Date: 2017-12-19 16:21:34

On Tue, Dec 19, 2017 at 8:47 PM, Dmitry Vyukov [off-list ref] wrote:
On Tue, Dec 19, 2017 at 1:36 PM, syzbot
[off-list ref]
wrote:
quoted
Hello,

syzkaller hit the following crash on
7ceb97a071e80f1b5e4cd5a36de135612a836388
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/master
compiler: gcc (GCC) 7.1.1 20170620
.config is attached
Raw console output is attached.

Unfortunately, I don't have any reproducer for this bug yet.


sctp: sctp_transport_update_pmtu: Reported pmtu 508 too low, using default
minimum of 512
INFO: task kworker/u4:0:5 blocked for more than 120 seconds.
      Not tainted 4.15.0-rc2-next-20171205+ #59
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
kworker/u4:0    D15808     5      2 0x80000000
Workqueue: netns cleanup_net
Call Trace:
 context_switch kernel/sched/core.c:2800 [inline]
 __schedule+0x8eb/0x2060 kernel/sched/core.c:3376
 schedule+0xf5/0x430 kernel/sched/core.c:3435
 schedule_preempt_disabled+0x10/0x20 kernel/sched/core.c:3493
 __mutex_lock_common kernel/locking/mutex.c:833 [inline]
 __mutex_lock+0xaad/0x1a80 kernel/locking/mutex.c:893
 mutex_lock_nested+0x16/0x20 kernel/locking/mutex.c:908
 rtnl_lock+0x17/0x20 net/core/rtnetlink.c:74
 tc_action_net_exit include/net/act_api.h:125 [inline]
 bpf_exit_net+0x1a2/0x340 net/sched/act_bpf.c:408
 ops_exit_list.isra.6+0xae/0x150 net/core/net_namespace.c:142
 cleanup_net+0x5c7/0xb60 net/core/net_namespace.c:484
 process_one_work+0xbfd/0x1bc0 kernel/workqueue.c:2113
 worker_thread+0x223/0x1990 kernel/workqueue.c:2247
 kthread+0x37a/0x440 kernel/kthread.c:238
 ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:517
[...]
quoted
Call Trace:
 serial_in drivers/tty/serial/8250/8250.h:111 [inline]
 wait_for_xmitr+0x93/0x1e0 drivers/tty/serial/8250/8250_port.c:2033
I saw this call trace on both 'bpf_exit_net task hung' and
'cleanup_net task hung'.
Note when cpu is here, it's still holding the rtnl_lock in these 2 cases,
one is in nl80211_dump_interface(), and the other one is in dev_ioctl().

I noticed this patch:

commit 54f19b4a679149130f78413c421a5780e90a9d0a
Author: Jiri Olsa [off-list ref]
Date:   Wed Sep 21 16:43:15 2016 +0200

    tty/serial/8250: Touch NMI watchdog in wait_for_xmitr

It means in early time, watchdog timeout can be triggered here,
And this patch was to fix it by restarting NMI watchdog timeout
with calling touch_nmi_watchdog().

But this patch missed that it's still holding the rtnl_lock(), other
threads may timeout on watchdog when trying to acquire
rtnl_lock().

quoted
 serial8250_console_putchar+0x1f/0x60
drivers/tty/serial/8250/8250_port.c:3170
 uart_console_write+0xac/0xe0 drivers/tty/serial/serial_core.c:1858
 serial8250_console_write+0x647/0xa20
drivers/tty/serial/8250/8250_port.c:3236
 univ8250_console_write+0x5f/0x70 drivers/tty/serial/8250/8250_core.c:590
 call_console_drivers kernel/printk/printk.c:1574 [inline]
 console_unlock+0x788/0xd70 kernel/printk/printk.c:2233
 vprintk_emit+0x4ad/0x590 kernel/printk/printk.c:1757
 vprintk_default+0x28/0x30 kernel/printk/printk.c:1796
 vprintk_func+0x57/0xc0 kernel/printk/printk_safe.c:379
 printk+0xaa/0xca kernel/printk/printk.c:1829
 nla_parse+0x374/0x3d0 lib/nlattr.c:257
 nlmsg_parse include/net/netlink.h:398 [inline]
 nl80211_dump_wiphy_parse.isra.37.constprop.83+0x138/0x5c0
net/wireless/nl80211.c:1920
 nl80211_dump_interface+0x596/0x820 net/wireless/nl80211.c:2660
 genl_lock_dumpit+0x68/0x90 net/netlink/genetlink.c:480
 netlink_dump+0x48c/0xce0 net/netlink/af_netlink.c:2186
 __netlink_dump_start+0x4f0/0x6d0 net/netlink/af_netlink.c:2283
 genl_family_rcv_msg+0xd27/0xfc0 net/netlink/genetlink.c:548
 genl_rcv_msg+0xb2/0x140 net/netlink/genetlink.c:624
 netlink_rcv_skb+0x216/0x440 net/netlink/af_netlink.c:2405
 genl_rcv+0x28/0x40 net/netlink/genetlink.c:635
 netlink_unicast_kernel net/netlink/af_netlink.c:1272 [inline]
 netlink_unicast+0x4e8/0x6f0 net/netlink/af_netlink.c:1298
 netlink_sendmsg+0xa4a/0xe70 net/netlink/af_netlink.c:1861
 sock_sendmsg_nosec net/socket.c:636 [inline]
 sock_sendmsg+0xca/0x110 net/socket.c:646
 sock_write_iter+0x320/0x5e0 net/socket.c:915
 call_write_iter include/linux/fs.h:1776 [inline]
 new_sync_write fs/read_write.c:469 [inline]
 __vfs_write+0x68a/0x970 fs/read_write.c:482
 vfs_write+0x18f/0x510 fs/read_write.c:544
 SYSC_write fs/read_write.c:589 [inline]
 SyS_write+0xef/0x220 fs/read_write.c:581
 entry_SYSCALL_64_fastpath+0x1f/0x96
RIP: 0033:0x4529d9
RSP: 002b:00007f6d52e3ec58 EFLAGS: 00000212 ORIG_RAX: 0000000000000001
RAX: ffffffffffffffda RBX: 00007f6d52e3f700 RCX: 00000000004529d9

37 more quoted lines

Re: INFO: task hung in bpf_exit_net

From: David Ahern <hidden>
Date: 2017-12-19 18:20:11

On 12/19/17 5:47 AM, Dmitry Vyukov wrote:
On Tue, Dec 19, 2017 at 1:36 PM, syzbot
[off-list ref]
wrote:
quoted
Hello,

syzkaller hit the following crash on
7ceb97a071e80f1b5e4cd5a36de135612a836388
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/master
compiler: gcc (GCC) 7.1.1 20170620
.config is attached
Raw console output is attached.

Unfortunately, I don't have any reproducer for this bug yet.


sctp: sctp_transport_update_pmtu: Reported pmtu 508 too low, using default
minimum of 512
INFO: task kworker/u4:0:5 blocked for more than 120 seconds.
      Not tainted 4.15.0-rc2-next-20171205+ #59
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
kworker/u4:0    D15808     5      2 0x80000000
Workqueue: netns cleanup_net
Call Trace:
 context_switch kernel/sched/core.c:2800 [inline]
 __schedule+0x8eb/0x2060 kernel/sched/core.c:3376
 schedule+0xf5/0x430 kernel/sched/core.c:3435
 schedule_preempt_disabled+0x10/0x20 kernel/sched/core.c:3493
 __mutex_lock_common kernel/locking/mutex.c:833 [inline]
 __mutex_lock+0xaad/0x1a80 kernel/locking/mutex.c:893
 mutex_lock_nested+0x16/0x20 kernel/locking/mutex.c:908
 rtnl_lock+0x17/0x20 net/core/rtnetlink.c:74
 tc_action_net_exit include/net/act_api.h:125 [inline]
 bpf_exit_net+0x1a2/0x340 net/sched/act_bpf.c:408
 ops_exit_list.isra.6+0xae/0x150 net/core/net_namespace.c:142
 cleanup_net+0x5c7/0xb60 net/core/net_namespace.c:484
 process_one_work+0xbfd/0x1bc0 kernel/workqueue.c:2113
 worker_thread+0x223/0x1990 kernel/workqueue.c:2247
 kthread+0x37a/0x440 kernel/kthread.c:238
 ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:517

202 more quoted lines

Same with this one, perhaps related to / fixed by:
    http://patchwork.ozlabs.org/patch/850957/

Re: INFO: task hung in bpf_exit_net

From: Dmitry Vyukov <dvyukov@google.com>
Date: 2017-12-22 10:58:41

On Tue, Dec 19, 2017 at 7:20 PM, David Ahern [off-list ref] wrote:
On 12/19/17 5:47 AM, Dmitry Vyukov wrote:
quoted
On Tue, Dec 19, 2017 at 1:36 PM, syzbot
[off-list ref]
wrote:
quoted
Hello,

syzkaller hit the following crash on
7ceb97a071e80f1b5e4cd5a36de135612a836388
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/master
compiler: gcc (GCC) 7.1.1 20170620
.config is attached
Raw console output is attached.

Unfortunately, I don't have any reproducer for this bug yet.


sctp: sctp_transport_update_pmtu: Reported pmtu 508 too low, using default
minimum of 512
INFO: task kworker/u4:0:5 blocked for more than 120 seconds.
      Not tainted 4.15.0-rc2-next-20171205+ #59
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
kworker/u4:0    D15808     5      2 0x80000000
Workqueue: netns cleanup_net
Call Trace:
 context_switch kernel/sched/core.c:2800 [inline]
 __schedule+0x8eb/0x2060 kernel/sched/core.c:3376
 schedule+0xf5/0x430 kernel/sched/core.c:3435
 schedule_preempt_disabled+0x10/0x20 kernel/sched/core.c:3493
 __mutex_lock_common kernel/locking/mutex.c:833 [inline]
 __mutex_lock+0xaad/0x1a80 kernel/locking/mutex.c:893
 mutex_lock_nested+0x16/0x20 kernel/locking/mutex.c:908
 rtnl_lock+0x17/0x20 net/core/rtnetlink.c:74
 tc_action_net_exit include/net/act_api.h:125 [inline]
 bpf_exit_net+0x1a2/0x340 net/sched/act_bpf.c:408
 ops_exit_list.isra.6+0xae/0x150 net/core/net_namespace.c:142
 cleanup_net+0x5c7/0xb60 net/core/net_namespace.c:484
 process_one_work+0xbfd/0x1bc0 kernel/workqueue.c:2113
 worker_thread+0x223/0x1990 kernel/workqueue.c:2247
 kthread+0x37a/0x440 kernel/kthread.c:238
 ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:517

207 more quoted lines



Looking at the log, this one seems to be an infinite loop in SCTP code
with console output in it. Kernel is busy printing gazilion of:

[  176.491099] sctp: sctp_transport_update_pmtu: Reported pmtu 508 too
low, using default minimum of 512
** 110 printk messages dropped **
[  176.503409] sctp: sctp_transport_update_pmtu: Reported pmtu 508 too
low, using default minimum of 512
** 103 printk messages dropped **
...
[  246.742374] sctp: sctp_transport_update_pmtu: Reported pmtu 508 too
low, using default minimum of 512
[  246.742484] sctp: sctp_transport_update_pmtu: Reported pmtu 508 too
low, using default minimum of 512
[  246.742590] sctp: sctp_transport_update_pmtu: Reported pmtu 508 too
low, using default minimum of 512

Looks like a different issue.

Re: INFO: task hung in bpf_exit_net

From: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
Date: 2017-12-22 11:16:18

On Fri, Dec 22, 2017 at 11:58:08AM +0100, Dmitry Vyukov wrote:
On Tue, Dec 19, 2017 at 7:20 PM, David Ahern [off-list ref] wrote:
quoted
On 12/19/17 5:47 AM, Dmitry Vyukov wrote:
quoted
On Tue, Dec 19, 2017 at 1:36 PM, syzbot
[off-list ref]
wrote:
quoted
Hello,

syzkaller hit the following crash on
7ceb97a071e80f1b5e4cd5a36de135612a836388
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/master
compiler: gcc (GCC) 7.1.1 20170620
.config is attached
Raw console output is attached.

Unfortunately, I don't have any reproducer for this bug yet.


sctp: sctp_transport_update_pmtu: Reported pmtu 508 too low, using default
minimum of 512
INFO: task kworker/u4:0:5 blocked for more than 120 seconds.
      Not tainted 4.15.0-rc2-next-20171205+ #59
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
kworker/u4:0    D15808     5      2 0x80000000
Workqueue: netns cleanup_net
Call Trace:
 context_switch kernel/sched/core.c:2800 [inline]
 __schedule+0x8eb/0x2060 kernel/sched/core.c:3376
 schedule+0xf5/0x430 kernel/sched/core.c:3435
 schedule_preempt_disabled+0x10/0x20 kernel/sched/core.c:3493
 __mutex_lock_common kernel/locking/mutex.c:833 [inline]
 __mutex_lock+0xaad/0x1a80 kernel/locking/mutex.c:893
 mutex_lock_nested+0x16/0x20 kernel/locking/mutex.c:908
 rtnl_lock+0x17/0x20 net/core/rtnetlink.c:74
 tc_action_net_exit include/net/act_api.h:125 [inline]
 bpf_exit_net+0x1a2/0x340 net/sched/act_bpf.c:408
 ops_exit_list.isra.6+0xae/0x150 net/core/net_namespace.c:142
 cleanup_net+0x5c7/0xb60 net/core/net_namespace.c:484
 process_one_work+0xbfd/0x1bc0 kernel/workqueue.c:2113
 worker_thread+0x223/0x1990 kernel/workqueue.c:2247
 kthread+0x37a/0x440 kernel/kthread.c:238

213 more quoted lines

Do you have a link for such log? I don't seem to have received the
initial syzbot email, so I don't have its attachments. Or if you may,
please fwd it to me/list.

Thanks.
[  176.491099] sctp: sctp_transport_update_pmtu: Reported pmtu 508 too
low, using default minimum of 512
** 110 printk messages dropped **
[  176.503409] sctp: sctp_transport_update_pmtu: Reported pmtu 508 too
low, using default minimum of 512
** 103 printk messages dropped **
...
[  246.742374] sctp: sctp_transport_update_pmtu: Reported pmtu 508 too
low, using default minimum of 512
[  246.742484] sctp: sctp_transport_update_pmtu: Reported pmtu 508 too
low, using default minimum of 512
[  246.742590] sctp: sctp_transport_update_pmtu: Reported pmtu 508 too
low, using default minimum of 512

Looks like a different issue.

Re: INFO: task hung in bpf_exit_net

From: Dmitry Vyukov <dvyukov@google.com>
Date: 2017-12-22 11:25:04

On Fri, Dec 22, 2017 at 12:16 PM, Marcelo Ricardo Leitner
[off-list ref] wrote:
On Fri, Dec 22, 2017 at 11:58:08AM +0100, Dmitry Vyukov wrote:
quoted
On Tue, Dec 19, 2017 at 7:20 PM, David Ahern [off-list ref] wrote:
quoted
On 12/19/17 5:47 AM, Dmitry Vyukov wrote:
quoted
On Tue, Dec 19, 2017 at 1:36 PM, syzbot
[off-list ref]
wrote:
quoted
Hello,

syzkaller hit the following crash on
7ceb97a071e80f1b5e4cd5a36de135612a836388
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/master
compiler: gcc (GCC) 7.1.1 20170620
.config is attached
Raw console output is attached.

Unfortunately, I don't have any reproducer for this bug yet.


sctp: sctp_transport_update_pmtu: Reported pmtu 508 too low, using default
minimum of 512
INFO: task kworker/u4:0:5 blocked for more than 120 seconds.
      Not tainted 4.15.0-rc2-next-20171205+ #59
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
kworker/u4:0    D15808     5      2 0x80000000
Workqueue: netns cleanup_net
Call Trace:
 context_switch kernel/sched/core.c:2800 [inline]
 __schedule+0x8eb/0x2060 kernel/sched/core.c:3376
 schedule+0xf5/0x430 kernel/sched/core.c:3435
 schedule_preempt_disabled+0x10/0x20 kernel/sched/core.c:3493
 __mutex_lock_common kernel/locking/mutex.c:833 [inline]
 __mutex_lock+0xaad/0x1a80 kernel/locking/mutex.c:893
 mutex_lock_nested+0x16/0x20 kernel/locking/mutex.c:908
 rtnl_lock+0x17/0x20 net/core/rtnetlink.c:74
 tc_action_net_exit include/net/act_api.h:125 [inline]
 bpf_exit_net+0x1a2/0x340 net/sched/act_bpf.c:408
 ops_exit_list.isra.6+0xae/0x150 net/core/net_namespace.c:142
 cleanup_net+0x5c7/0xb60 net/core/net_namespace.c:484
 process_one_work+0xbfd/0x1bc0 kernel/workqueue.c:2113
 worker_thread+0x223/0x1990 kernel/workqueue.c:2247

218 more quoted lines

https://groups.google.com/forum/#!searchin/syzkaller-bugs/%22INFO$3A$20task$20hung$20in$20bpf_exit_net%22%7Csort:date


Thanks.
quoted
[  176.491099] sctp: sctp_transport_update_pmtu: Reported pmtu 508 too
low, using default minimum of 512
** 110 printk messages dropped **
[  176.503409] sctp: sctp_transport_update_pmtu: Reported pmtu 508 too
low, using default minimum of 512
** 103 printk messages dropped **
...
[  246.742374] sctp: sctp_transport_update_pmtu: Reported pmtu 508 too
low, using default minimum of 512
[  246.742484] sctp: sctp_transport_update_pmtu: Reported pmtu 508 too
low, using default minimum of 512
[  246.742590] sctp: sctp_transport_update_pmtu: Reported pmtu 508 too
low, using default minimum of 512

Looks like a different issue.

Re: INFO: task hung in bpf_exit_net

From: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
Date: 2017-12-22 18:28:16

On Fri, Dec 22, 2017 at 11:58:08AM +0100, Dmitry Vyukov wrote:
...
quoted
Same with this one, perhaps related to / fixed by:
    http://patchwork.ozlabs.org/patch/850957/


Looking at the log, this one seems to be an infinite loop in SCTP code
with console output in it. Kernel is busy printing gazilion of:

[  176.491099] sctp: sctp_transport_update_pmtu: Reported pmtu 508 too
low, using default minimum of 512
** 110 printk messages dropped **
[  176.503409] sctp: sctp_transport_update_pmtu: Reported pmtu 508 too
low, using default minimum of 512
** 103 printk messages dropped **
...
[  246.742374] sctp: sctp_transport_update_pmtu: Reported pmtu 508 too
low, using default minimum of 512
[  246.742484] sctp: sctp_transport_update_pmtu: Reported pmtu 508 too
low, using default minimum of 512
[  246.742590] sctp: sctp_transport_update_pmtu: Reported pmtu 508 too
low, using default minimum of 512

Looks like a different issue.
Oh. I guess this is caused by the interface having a MTU smaller than
SCTP_DEFAULT_MINSEGMENT (512), as the icmp frag needed handler
(sctp_icmp_frag_needed) will trigger an instant retransmission.
But as the MTU is smaller, SCTP won't update it, but will issue the
retransmission anyway.

I will test this soon. Should be fairly easy to trigger it.

  Marcelo

Re: INFO: task hung in bpf_exit_net

From: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
Date: 2017-12-22 19:04:49

On Fri, Dec 22, 2017 at 04:28:07PM -0200, Marcelo Ricardo Leitner wrote:
On Fri, Dec 22, 2017 at 11:58:08AM +0100, Dmitry Vyukov wrote:
...
quoted
quoted
Same with this one, perhaps related to / fixed by:
    http://patchwork.ozlabs.org/patch/850957/


Looking at the log, this one seems to be an infinite loop in SCTP code
with console output in it. Kernel is busy printing gazilion of:

[  176.491099] sctp: sctp_transport_update_pmtu: Reported pmtu 508 too
low, using default minimum of 512
** 110 printk messages dropped **
[  176.503409] sctp: sctp_transport_update_pmtu: Reported pmtu 508 too
low, using default minimum of 512
** 103 printk messages dropped **
...
[  246.742374] sctp: sctp_transport_update_pmtu: Reported pmtu 508 too
low, using default minimum of 512
[  246.742484] sctp: sctp_transport_update_pmtu: Reported pmtu 508 too
low, using default minimum of 512
[  246.742590] sctp: sctp_transport_update_pmtu: Reported pmtu 508 too
low, using default minimum of 512

Looks like a different issue.
Oh. I guess this is caused by the interface having a MTU smaller than
SCTP_DEFAULT_MINSEGMENT (512), as the icmp frag needed handler
(sctp_icmp_frag_needed) will trigger an instant retransmission.
But as the MTU is smaller, SCTP won't update it, but will issue the
retransmission anyway.

I will test this soon. Should be fairly easy to trigger it.
Reproduced it.

netns A veth0(1500) - veth1(1500) B veth2(508) - veth3(508) C

When A sends a sctp packet bigger than 508, it triggers the issue as B
will reply a icmp frag needed with a size that sctp won't accept but
will retransmit anyway.

  Marcelo

Re: INFO: task hung in bpf_exit_net

From: Eric Biggers <hidden>
Date: 2018-02-02 23:40:01

On Fri, Dec 22, 2017 at 05:04:37PM -0200, Marcelo Ricardo Leitner wrote:
On Fri, Dec 22, 2017 at 04:28:07PM -0200, Marcelo Ricardo Leitner wrote:
quoted
On Fri, Dec 22, 2017 at 11:58:08AM +0100, Dmitry Vyukov wrote:
...
quoted
quoted
Same with this one, perhaps related to / fixed by:
    http://patchwork.ozlabs.org/patch/850957/


Looking at the log, this one seems to be an infinite loop in SCTP code
with console output in it. Kernel is busy printing gazilion of:

[  176.491099] sctp: sctp_transport_update_pmtu: Reported pmtu 508 too
low, using default minimum of 512
** 110 printk messages dropped **
[  176.503409] sctp: sctp_transport_update_pmtu: Reported pmtu 508 too
low, using default minimum of 512
** 103 printk messages dropped **
...
[  246.742374] sctp: sctp_transport_update_pmtu: Reported pmtu 508 too
low, using default minimum of 512
[  246.742484] sctp: sctp_transport_update_pmtu: Reported pmtu 508 too
low, using default minimum of 512
[  246.742590] sctp: sctp_transport_update_pmtu: Reported pmtu 508 too
low, using default minimum of 512

Looks like a different issue.
Oh. I guess this is caused by the interface having a MTU smaller than
SCTP_DEFAULT_MINSEGMENT (512), as the icmp frag needed handler
(sctp_icmp_frag_needed) will trigger an instant retransmission.
But as the MTU is smaller, SCTP won't update it, but will issue the
retransmission anyway.

I will test this soon. Should be fairly easy to trigger it.
Reproduced it.

netns A veth0(1500) - veth1(1500) B veth2(508) - veth3(508) C

5 more quoted lines

syzbot hasn't encountered this hang again (although, it just happened once in
the first place).  I assume it was fixed by commit b6c5734db070, so telling
syzbot this:

#syz fix: sctp: fix the handling of ICMP Frag Needed for too small MTUs

- Eric
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help