* Re: INFO: task hung in ip6gre_exit_batch_net
From: Dmitry Vyukov @ 2018-06-08 8:18 UTC (permalink / raw)
To: Kirill Tkhai
Cc: syzbot, Christian Brauner, David Miller, David Ahern,
Florian Westphal, Jiri Benc, LKML, Xin Long, mschiffer, netdev,
syzkaller-bugs, Vladislav Yasevich
In-Reply-To: <6b14e8b9-c335-dd46-98a6-7f58a624fcea@virtuozzo.com>
On Thu, Jun 7, 2018 at 9:59 PM, Kirill Tkhai <ktkhai@virtuozzo.com> wrote:
> On 07.06.2018 22:03, Dmitry Vyukov wrote:
>> On Thu, Jun 7, 2018 at 8:54 PM, Kirill Tkhai <ktkhai@virtuozzo.com> wrote:
>>>>>>> Hi, Dmirty!
>>>>>>>
>>>>>>> On 04.06.2018 18:22, Dmitry Vyukov wrote:
>>>>>>>> On Mon, Jun 4, 2018 at 5:03 PM, syzbot
>>>>>>>> <syzbot+bf78a74f82c1cf19069e@syzkaller.appspotmail.com> wrote:
>>>>>>>>> Hello,
>>>>>>>>>
>>>>>>>>> syzbot found the following crash on:
>>>>>>>>>
>>>>>>>>> HEAD commit: bc2dbc5420e8 Merge branch 'akpm' (patches from Andrew)
>>>>>>>>> git tree: upstream
>>>>>>>>> console output: https://syzkaller.appspot.com/x/log.txt?x=164e42b7800000
>>>>>>>>> kernel config: https://syzkaller.appspot.com/x/.config?x=982e2df1b9e60b02
>>>>>>>>> dashboard link: https://syzkaller.appspot.com/bug?extid=bf78a74f82c1cf19069e
>>>>>>>>> compiler: gcc (GCC) 8.0.1 20180413 (experimental)
>>>>>>>>>
>>>>>>>>> Unfortunately, I don't have any reproducer for this crash yet.
>>>>>>>>>
>>>>>>>>> IMPORTANT: if you fix the bug, please add the following tag to the commit:
>>>>>>>>> Reported-by: syzbot+bf78a74f82c1cf19069e@syzkaller.appspotmail.com
>>>>>>>>
>>>>>>>> Another hang on rtnl lock:
>>>>>>>>
>>>>>>>> #syz dup: INFO: task hung in netdev_run_todo
>>>>>>>>
>>>>>>>> May be related to "unregister_netdevice: waiting for DEV to become free":
>>>>>>>> https://syzkaller.appspot.com/bug?id=1a97a5bd119fd97995f752819fd87840ab9479a9
>>>>>>
>>>>>> netdev_wait_allrefs does not hold rtnl lock during waiting, so it must
>>>>>> be something different.
>>>>>>
>>>>>>
>>>>>>>> Any other explanations for massive hangs on rtnl lock for minutes?
>>>>>>>
>>>>>>> To exclude the situation, when a task exists with rtnl_mutex held:
>>>>>>>
>>>>>>> would the pr_warn() from print_held_locks_bug() be included in the console output
>>>>>>> if they appear?
>>>>>>
>>>>>> Yes, everything containing "WARNING:" is detected as bug.
>>>>>
>>>>> OK, then dead task not releasing the lock is excluded.
>>>>>
>>>>> One more assumption: someone corrupted memory around rtnl_mutex and it looks like locked.
>>>>> (I track lockdep "(rtnl_mutex){+.+.}" prints in initial message as "nobody owns rtnl_mutex").
>>>>> There may help a crash dump of the VM.
>>>>
>>>> I can't find any legend for these +'s and .'s, but {+.+.} is present
>>>> in large amounts in just any task hung report for different mutexes,
>>>> so I would not expect that it means corruption.
>>>>
>>>> Are dozens of known corruptions that syzkaller can trigger. But
>>>> usually they are reliably caught by KASAN. If any of them would lead
>>>> to silent memory corruption, we would got dozens of assorted crashes
>>>> throughout the kernel. We've seen that at some points, but not
>>>> recently. So I would assume that memory is not corrupted in all these
>>>> cases:
>>>> https://syzkaller.appspot.com/bug?id=2503c576cabb08d41812e732b390141f01a59545
>>>
>>> This BUG clarifies the {+.+.}:
>>>
>>> 4 locks held by kworker/0:145/381:
>>> #0: ((wq_completion)"hwsim_wq"){+.+.}, at: [<000000003f9487f0>] work_static include/linux/workqueue.h:198 [inline]
>>> #0: ((wq_completion)"hwsim_wq"){+.+.}, at: [<000000003f9487f0>] set_work_data kernel/workqueue.c:619 [inline]
>>> #0: ((wq_completion)"hwsim_wq"){+.+.}, at: [<000000003f9487f0>] set_work_pool_and_clear_pending kernel/workqueue.c:646 [inline]
>>> #0: ((wq_completion)"hwsim_wq"){+.+.}, at: [<000000003f9487f0>] process_one_work+0xb12/0x1bb0 kernel/workqueue.c:2084
>>> #1: ((work_completion)(&data->destroy_work)){+.+.}, at: [<00000000bbdd2115>] process_one_work+0xb89/0x1bb0 kernel/workqueue.c:2088
>>> #2: (rtnl_mutex){+.+.}, at: [<000000009c9d14f8>] rtnl_lock+0x17/0x20 net/core/rtnetlink.c:74
>>> #3: (rcu_sched_state.exp_mutex){+.+.}, at: [<000000001ba1a807>] exp_funnel_lock kernel/rcu/tree_exp.h:272 [inline]
>>> #3: (rcu_sched_state.exp_mutex){+.+.}, at: [<000000001ba1a807>] _synchronize_rcu_expedited.constprop.72+0x9fa/0xac0 kernel/rcu/tree_exp.h:596
>>>
>>> There we have rtnl_mutex locked and the {..} is like above. It's definitely locked
>>> since there is one more lock after it.
>>>
>>> This BUG happen because of there are many rtnl_mutex waiters while owner
>>> is synchronizing RCU. Rather clear for me in comparison to the topic's hung.
>>
>>
>> You mean that it's not hanged, but rather needs more than 2 minutes to
>> complete, right?
>
> Yeah, I think, this is possible. I've seen the situations like that.
> Let synchronize_rcu_expedited() is executed for X seconds. Then,
> it's need just 120/x calls of "this function under rtnl_mutex" to make
> a soft lockup of someone else who wants the mutex too.
>
> Also, despite the CFS is fair scheduler, in case of the calls are
> made from workqueue, every work will cause sleep. So, every work
> will be executed in separate worker task. Every worker will haved its
> own time slice. This increases the probability these tasks will
> take cpu time before the task in the header of the hang.
OK, let's stick with this theory for now. Looking at the crash frequencies here:
https://syzkaller.appspot.com/bug?id=2503c576cabb08d41812e732b390141f01a59545
I can actually believe that this is just flakes due to too slow execution.
I've noted that we need either reduce load and/or increase timeouts:
https://github.com/google/syzkaller/issues/516#issuecomment-395685629
Let's keep duping new such reports onto "INFO: task hung in
netdev_run_todo" so that they are all collected at a single location.
Thanks for help
^ permalink raw reply
* Re: INFO: task hung in netdev_run_todo
From: Dmitry Vyukov @ 2018-06-08 8:20 UTC (permalink / raw)
To: syzbot
Cc: Christian Brauner, Daniel Borkmann, David Miller, David Ahern,
Florian Westphal, Jakub Kicinski, Jiri Benc, LKML, Xin Long,
mschiffer, netdev, syzkaller-bugs, Vladislav Yasevich
In-Reply-To: <089e0826d4d4bdb7c5056500fb67@google.com>
On Mon, Feb 12, 2018 at 11:03 AM, syzbot
<syzbot+8cd13ab48843d67c58f0@syzkaller.appspotmail.com> wrote:
> Hello,
>
> syzbot hit the following crash on upstream commit
> 581e400ff935d34d95811258586128bf11baef15 (Wed Feb 7 22:29:34 2018 +0000)
> Merge tag 'modules-for-v4.16' of
> git://git.kernel.org/pub/scm/linux/kernel/git/jeyu/linux
>
> Unfortunately, I don't have any reproducer for this crash yet.
> Raw console output is attached.
> compiler: gcc (GCC) 7.1.1 20170620
> .config is attached.
> user-space arch: i386
>
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+8cd13ab48843d67c58f0@syzkaller.appspotmail.com
> It will help syzbot understand when the bug is fixed. See footer for
> details.
> If you forward the report, please keep this part and the footer.
>
> INFO: task kworker/u4:1:21 blocked for more than 120 seconds.
> Not tainted 4.15.0+ #213
> "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
> kworker/u4:1 D12208 21 2 0x80000000
> Workqueue: netns cleanup_net
> Call Trace:
> context_switch kernel/sched/core.c:2857 [inline]
> __schedule+0x8e2/0x2040 kernel/sched/core.c:3435
> schedule+0xf5/0x430 kernel/sched/core.c:3494
> schedule_preempt_disabled+0x10/0x20 kernel/sched/core.c:3552
> __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
> netdev_wait_allrefs+0x1cb/0x410 net/core/dev.c:8035
> netdev_run_todo+0x478/0xae0 net/core/dev.c:8129
> rtnl_unlock+0xe/0x10 net/core/rtnetlink.c:108
> default_device_exit_batch+0x4b4/0x5d0 net/core/dev.c:8930
> ops_exit_list.isra.6+0x100/0x150 net/core/net_namespace.c:145
> cleanup_net+0x6a3/0xcc0 net/core/net_namespace.c:517
> process_one_work+0xbbf/0x1af0 kernel/workqueue.c:2113
> worker_thread+0x223/0x1990 kernel/workqueue.c:2247
> kthread+0x33c/0x400 kernel/kthread.c:238
> ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:429
>
> Showing all locks held in the system:
> 4 locks held by kworker/u4:1/21:
> #0: ((wq_completion)"%s""netns"){+.+.}, at: [<000000008671663e>]
> process_one_work+0xaaf/0x1af0 kernel/workqueue.c:2084
> #1: (net_cleanup_work){+.+.}, at: [<0000000098e1951b>]
> process_one_work+0xb01/0x1af0 kernel/workqueue.c:2088
> #2: (net_mutex){+.+.}, at: [<000000009da3dcc8>] cleanup_net+0x242/0xcc0
> net/core/net_namespace.c:484
> #3: (rtnl_mutex){+.+.}, at: [<000000000b60ddd2>] rtnl_lock+0x17/0x20
> net/core/rtnetlink.c:74
> 2 locks held by khungtaskd/758:
> #0: (rcu_read_lock){....}, at: [<0000000032c7899a>]
> check_hung_uninterruptible_tasks kernel/hung_task.c:175 [inline]
> #0: (rcu_read_lock){....}, at: [<0000000032c7899a>] watchdog+0x1c5/0xd60
> kernel/hung_task.c:249
> #1: (tasklist_lock){.+.+}, at: [<000000008744ddaf>]
> debug_show_all_locks+0xd3/0x3d0 kernel/locking/lockdep.c:4470
> 1 lock held by rsyslogd/3947:
> #0: (&f->f_pos_lock){+.+.}, at: [<00000000f50ca942>]
> __fdget_pos+0x12b/0x190 fs/file.c:765
> 2 locks held by getty/4070:
> #0: (&tty->ldisc_sem){++++}, at: [<000000004fdd9acb>]
> ldsem_down_read+0x37/0x40 drivers/tty/tty_ldsem.c:365
> #1: (&ldata->atomic_read_lock){+.+.}, at: [<0000000033740686>]
> n_tty_read+0x2ef/0x1a00 drivers/tty/n_tty.c:2131
> 2 locks held by getty/4071:
> #0: (&tty->ldisc_sem){++++}, at: [<000000004fdd9acb>]
> ldsem_down_read+0x37/0x40 drivers/tty/tty_ldsem.c:365
> #1: (&ldata->atomic_read_lock){+.+.}, at: [<0000000033740686>]
> n_tty_read+0x2ef/0x1a00 drivers/tty/n_tty.c:2131
> 2 locks held by getty/4072:
> #0: (&tty->ldisc_sem){++++}, at: [<000000004fdd9acb>]
> ldsem_down_read+0x37/0x40 drivers/tty/tty_ldsem.c:365
> #1: (&ldata->atomic_read_lock){+.+.}, at: [<0000000033740686>]
> n_tty_read+0x2ef/0x1a00 drivers/tty/n_tty.c:2131
> 2 locks held by getty/4073:
> #0: (&tty->ldisc_sem){++++}, at: [<000000004fdd9acb>]
> ldsem_down_read+0x37/0x40 drivers/tty/tty_ldsem.c:365
> #1: (&ldata->atomic_read_lock){+.+.}, at: [<0000000033740686>]
> n_tty_read+0x2ef/0x1a00 drivers/tty/n_tty.c:2131
> 2 locks held by getty/4074:
> #0: (&tty->ldisc_sem){++++}, at: [<000000004fdd9acb>]
> ldsem_down_read+0x37/0x40 drivers/tty/tty_ldsem.c:365
> #1: (&ldata->atomic_read_lock){+.+.}, at: [<0000000033740686>]
> n_tty_read+0x2ef/0x1a00 drivers/tty/n_tty.c:2131
> 2 locks held by getty/4075:
> #0: (&tty->ldisc_sem){++++}, at: [<000000004fdd9acb>]
> ldsem_down_read+0x37/0x40 drivers/tty/tty_ldsem.c:365
> #1: (&ldata->atomic_read_lock){+.+.}, at: [<0000000033740686>]
> n_tty_read+0x2ef/0x1a00 drivers/tty/n_tty.c:2131
> 2 locks held by getty/4076:
> #0: (&tty->ldisc_sem){++++}, at: [<000000004fdd9acb>]
> ldsem_down_read+0x37/0x40 drivers/tty/tty_ldsem.c:365
> #1: (&ldata->atomic_read_lock){+.+.}, at: [<0000000033740686>]
> n_tty_read+0x2ef/0x1a00 drivers/tty/n_tty.c:2131
> 1 lock held by syz-executor2/4154:
> #0: (rtnl_mutex){+.+.}, at: [<000000000b60ddd2>] rtnl_lock+0x17/0x20
> net/core/rtnetlink.c:74
> 3 locks held by kworker/1:3/7524:
> #0: ((wq_completion)"%s"("ipv6_addrconf")){+.+.}, at: [<000000008671663e>]
> process_one_work+0xaaf/0x1af0 kernel/workqueue.c:2084
> #1: ((addr_chk_work).work){+.+.}, at: [<0000000098e1951b>]
> process_one_work+0xb01/0x1af0 kernel/workqueue.c:2088
> #2: (rtnl_mutex){+.+.}, at: [<000000000b60ddd2>] rtnl_lock+0x17/0x20
> net/core/rtnetlink.c:74
> 1 lock held by syz-executor0/10595:
> #0: (rtnl_mutex){+.+.}, at: [<000000000b60ddd2>] rtnl_lock+0x17/0x20
> net/core/rtnetlink.c:74
> 1 lock held by syz-executor3/13841:
> #0: (sk_lock-AF_INET6){+.+.}, at: [<0000000063f9b07b>] lock_sock
> include/net/sock.h:1463 [inline]
> #0: (sk_lock-AF_INET6){+.+.}, at: [<0000000063f9b07b>]
> compat_ipv6_getsockopt+0x1f1/0x390 net/ipv6/ipv6_sockglue.c:1412
> 1 lock held by syz-executor3/13845:
> #0: (rtnl_mutex){+.+.}, at: [<000000000b60ddd2>] rtnl_lock+0x17/0x20
> net/core/rtnetlink.c:74
> 1 lock held by syz-executor3/13851:
> #0: (rtnl_mutex){+.+.}, at: [<000000000b60ddd2>] rtnl_lock+0x17/0x20
> net/core/rtnetlink.c:74
> 1 lock held by syz-executor3/13862:
> #0: (rtnl_mutex){+.+.}, at: [<000000000b60ddd2>] rtnl_lock+0x17/0x20
> net/core/rtnetlink.c:74
> 1 lock held by syz-executor0/13866:
> #0: (rtnl_mutex){+.+.}, at: [<000000000b60ddd2>] rtnl_lock+0x17/0x20
> net/core/rtnetlink.c:74
> 1 lock held by syz-executor2/13868:
> #0: (rtnl_mutex){+.+.}, at: [<000000000b60ddd2>] rtnl_lock+0x17/0x20
> net/core/rtnetlink.c:74
>
> =============================================
>
> NMI backtrace for cpu 1
> CPU: 1 PID: 758 Comm: khungtaskd Not tainted 4.15.0+ #213
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> Call Trace:
> __dump_stack lib/dump_stack.c:17 [inline]
> dump_stack+0x194/0x257 lib/dump_stack.c:53
> nmi_cpu_backtrace+0x1d2/0x210 lib/nmi_backtrace.c:103
> nmi_trigger_cpumask_backtrace+0x122/0x180 lib/nmi_backtrace.c:62
> arch_trigger_cpumask_backtrace+0x14/0x20 arch/x86/kernel/apic/hw_nmi.c:38
> trigger_all_cpu_backtrace include/linux/nmi.h:138 [inline]
> check_hung_task kernel/hung_task.c:132 [inline]
> check_hung_uninterruptible_tasks kernel/hung_task.c:190 [inline]
> watchdog+0x90c/0xd60 kernel/hung_task.c:249
> kthread+0x33c/0x400 kernel/kthread.c:238
> ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:429
> Sending NMI from CPU 1 to CPUs 0:
> NMI backtrace for cpu 0
> CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.15.0+ #213
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> RIP: 0010:rcu_lockdep_current_cpu_online+0x52/0x190 kernel/rcu/tree.c:1123
> RSP: 0018:ffff8801db407780 EFLAGS: 00000282
> RAX: ffffed003b680ef0 RBX: 1ffff1003b680ef0 RCX: 1ffff1003b680ef6
> RDX: dffffc0000000000 RSI: ffffffff86b290c0 RDI: ffff8801db423750
> RBP: ffff8801db407808 R08: 1ffff1003b680e47 R09: 0000000000000002
> R10: ffff8801db4076f8 R11: 0000000000000020 R12: 1ffff1003b680f20
> R13: ffff8801d9e66a00 R14: ffff8801db4079c0 R15: 1ffff1003b680f14
> FS: 0000000000000000(0000) GS:ffff8801db400000(0000) knlGS:0000000000000000
> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 000000000240f000 CR3: 0000000006a22003 CR4: 00000000001606f0
> DR0: 0000000020000000 DR1: 0000000000000000 DR2: 0000000000000000
> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000600
> Call Trace:
> <IRQ>
> rcu_read_lock_held+0x94/0xc0 kernel/rcu/update.c:331
> rebalance_domains+0x945/0xcc0 kernel/sched/fair.c:9147
> run_rebalance_domains+0x378/0x770 kernel/sched/fair.c:9405
> __do_softirq+0x2d7/0xb85 kernel/softirq.c:285
> invoke_softirq kernel/softirq.c:365 [inline]
> irq_exit+0x1cc/0x200 kernel/softirq.c:405
> scheduler_ipi+0x318/0x820 kernel/sched/core.c:1804
> smp_reschedule_interrupt+0xe6/0x650 arch/x86/kernel/smp.c:277
> reschedule_interrupt+0xa9/0xb0 arch/x86/entry/entry_64.S:853
> </IRQ>
> RIP: 0010:native_safe_halt+0x6/0x10 arch/x86/include/asm/irqflags.h:54
> RSP: 0018:ffffffff86a07c38 EFLAGS: 00000286 ORIG_RAX: ffffffffffffff02
> RAX: dffffc0000000000 RBX: 1ffffffff0d40f8a RCX: 0000000000000000
> RDX: 1ffffffff0d59278 RSI: 0000000000000001 RDI: ffffffff86ac93c0
> RBP: ffffffff86a07c38 R08: 0000000000000000 R09: 0000000000000000
> R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000
> R13: ffffffff86a07cf0 R14: ffffffff87269560 R15: 0000000000000000
> arch_safe_halt arch/x86/include/asm/paravirt.h:93 [inline]
> default_idle+0xbf/0x430 arch/x86/kernel/process.c:354
> arch_cpu_idle+0xa/0x10 arch/x86/kernel/process.c:345
> default_idle_call+0x36/0x90 kernel/sched/idle.c:98
> cpuidle_idle_call kernel/sched/idle.c:156 [inline]
> do_idle+0x24a/0x3b0 kernel/sched/idle.c:246
> cpu_startup_entry+0x104/0x120 kernel/sched/idle.c:351
> rest_init+0xed/0xf0 init/main.c:436
> start_kernel+0x7f1/0x819 init/main.c:716
> x86_64_start_reservations+0x2a/0x2c arch/x86/kernel/head64.c:378
> x86_64_start_kernel+0x77/0x7a arch/x86/kernel/head64.c:359
> secondary_startup_64+0xa5/0xb0 arch/x86/kernel/head_64.S:237
> Code: c7 85 78 ff ff ff b3 8a b5 41 48 8d 04 13 48 c7 45 80 b5 14 7d 86 48
> c7 45 88 50 e2 5d 81 c7 00 f1 f1 f1 f1 c7 40 04 00 f2 f2 f2 <c7> 40 08 f3 f3
> f3 f3 b8 01 00 00 00 65 8b 0d 9b 0a a4 7e 81 e1
Presumably this is just a flake due to too slow execution. A thread
can't actually take the mutex for 2 minutes, but nothing has hanged
entirely. See detailed discussion here:
https://groups.google.com/d/msg/syzkaller-bugs/JwoXRjOYNnY/pIZWcXAoBQAJ
^ permalink raw reply
* Re: INFO: task hung in ip6gre_exit_batch_net
From: Kirill Tkhai @ 2018-06-08 8:31 UTC (permalink / raw)
To: Dmitry Vyukov
Cc: syzbot, Christian Brauner, David Miller, David Ahern,
Florian Westphal, Jiri Benc, LKML, Xin Long, mschiffer, netdev,
syzkaller-bugs, Vladislav Yasevich
In-Reply-To: <CACT4Y+a57xaVfph_u78Z+kM8xUF=8fVk-VSA+xqok38Zm4bhFw@mail.gmail.com>
On 08.06.2018 11:18, Dmitry Vyukov wrote:
> On Thu, Jun 7, 2018 at 9:59 PM, Kirill Tkhai <ktkhai@virtuozzo.com> wrote:
>> On 07.06.2018 22:03, Dmitry Vyukov wrote:
>>> On Thu, Jun 7, 2018 at 8:54 PM, Kirill Tkhai <ktkhai@virtuozzo.com> wrote:
>>>>>>>> Hi, Dmirty!
>>>>>>>>
>>>>>>>> On 04.06.2018 18:22, Dmitry Vyukov wrote:
>>>>>>>>> On Mon, Jun 4, 2018 at 5:03 PM, syzbot
>>>>>>>>> <syzbot+bf78a74f82c1cf19069e@syzkaller.appspotmail.com> wrote:
>>>>>>>>>> Hello,
>>>>>>>>>>
>>>>>>>>>> syzbot found the following crash on:
>>>>>>>>>>
>>>>>>>>>> HEAD commit: bc2dbc5420e8 Merge branch 'akpm' (patches from Andrew)
>>>>>>>>>> git tree: upstream
>>>>>>>>>> console output: https://syzkaller.appspot.com/x/log.txt?x=164e42b7800000
>>>>>>>>>> kernel config: https://syzkaller.appspot.com/x/.config?x=982e2df1b9e60b02
>>>>>>>>>> dashboard link: https://syzkaller.appspot.com/bug?extid=bf78a74f82c1cf19069e
>>>>>>>>>> compiler: gcc (GCC) 8.0.1 20180413 (experimental)
>>>>>>>>>>
>>>>>>>>>> Unfortunately, I don't have any reproducer for this crash yet.
>>>>>>>>>>
>>>>>>>>>> IMPORTANT: if you fix the bug, please add the following tag to the commit:
>>>>>>>>>> Reported-by: syzbot+bf78a74f82c1cf19069e@syzkaller.appspotmail.com
>>>>>>>>>
>>>>>>>>> Another hang on rtnl lock:
>>>>>>>>>
>>>>>>>>> #syz dup: INFO: task hung in netdev_run_todo
>>>>>>>>>
>>>>>>>>> May be related to "unregister_netdevice: waiting for DEV to become free":
>>>>>>>>> https://syzkaller.appspot.com/bug?id=1a97a5bd119fd97995f752819fd87840ab9479a9
>>>>>>>
>>>>>>> netdev_wait_allrefs does not hold rtnl lock during waiting, so it must
>>>>>>> be something different.
>>>>>>>
>>>>>>>
>>>>>>>>> Any other explanations for massive hangs on rtnl lock for minutes?
>>>>>>>>
>>>>>>>> To exclude the situation, when a task exists with rtnl_mutex held:
>>>>>>>>
>>>>>>>> would the pr_warn() from print_held_locks_bug() be included in the console output
>>>>>>>> if they appear?
>>>>>>>
>>>>>>> Yes, everything containing "WARNING:" is detected as bug.
>>>>>>
>>>>>> OK, then dead task not releasing the lock is excluded.
>>>>>>
>>>>>> One more assumption: someone corrupted memory around rtnl_mutex and it looks like locked.
>>>>>> (I track lockdep "(rtnl_mutex){+.+.}" prints in initial message as "nobody owns rtnl_mutex").
>>>>>> There may help a crash dump of the VM.
>>>>>
>>>>> I can't find any legend for these +'s and .'s, but {+.+.} is present
>>>>> in large amounts in just any task hung report for different mutexes,
>>>>> so I would not expect that it means corruption.
>>>>>
>>>>> Are dozens of known corruptions that syzkaller can trigger. But
>>>>> usually they are reliably caught by KASAN. If any of them would lead
>>>>> to silent memory corruption, we would got dozens of assorted crashes
>>>>> throughout the kernel. We've seen that at some points, but not
>>>>> recently. So I would assume that memory is not corrupted in all these
>>>>> cases:
>>>>> https://syzkaller.appspot.com/bug?id=2503c576cabb08d41812e732b390141f01a59545
>>>>
>>>> This BUG clarifies the {+.+.}:
>>>>
>>>> 4 locks held by kworker/0:145/381:
>>>> #0: ((wq_completion)"hwsim_wq"){+.+.}, at: [<000000003f9487f0>] work_static include/linux/workqueue.h:198 [inline]
>>>> #0: ((wq_completion)"hwsim_wq"){+.+.}, at: [<000000003f9487f0>] set_work_data kernel/workqueue.c:619 [inline]
>>>> #0: ((wq_completion)"hwsim_wq"){+.+.}, at: [<000000003f9487f0>] set_work_pool_and_clear_pending kernel/workqueue.c:646 [inline]
>>>> #0: ((wq_completion)"hwsim_wq"){+.+.}, at: [<000000003f9487f0>] process_one_work+0xb12/0x1bb0 kernel/workqueue.c:2084
>>>> #1: ((work_completion)(&data->destroy_work)){+.+.}, at: [<00000000bbdd2115>] process_one_work+0xb89/0x1bb0 kernel/workqueue.c:2088
>>>> #2: (rtnl_mutex){+.+.}, at: [<000000009c9d14f8>] rtnl_lock+0x17/0x20 net/core/rtnetlink.c:74
>>>> #3: (rcu_sched_state.exp_mutex){+.+.}, at: [<000000001ba1a807>] exp_funnel_lock kernel/rcu/tree_exp.h:272 [inline]
>>>> #3: (rcu_sched_state.exp_mutex){+.+.}, at: [<000000001ba1a807>] _synchronize_rcu_expedited.constprop.72+0x9fa/0xac0 kernel/rcu/tree_exp.h:596
>>>>
>>>> There we have rtnl_mutex locked and the {..} is like above. It's definitely locked
>>>> since there is one more lock after it.
>>>>
>>>> This BUG happen because of there are many rtnl_mutex waiters while owner
>>>> is synchronizing RCU. Rather clear for me in comparison to the topic's hung.
>>>
>>>
>>> You mean that it's not hanged, but rather needs more than 2 minutes to
>>> complete, right?
>>
>> Yeah, I think, this is possible. I've seen the situations like that.
>> Let synchronize_rcu_expedited() is executed for X seconds. Then,
>> it's need just 120/x calls of "this function under rtnl_mutex" to make
>> a soft lockup of someone else who wants the mutex too.
>>
>> Also, despite the CFS is fair scheduler, in case of the calls are
>> made from workqueue, every work will cause sleep. So, every work
>> will be executed in separate worker task. Every worker will haved its
>> own time slice. This increases the probability these tasks will
>> take cpu time before the task in the header of the hang.
>
>
> OK, let's stick with this theory for now. Looking at the crash frequencies here:
> https://syzkaller.appspot.com/bug?id=2503c576cabb08d41812e732b390141f01a59545
> I can actually believe that this is just flakes due to too slow execution.
>
> I've noted that we need either reduce load and/or increase timeouts:
> https://github.com/google/syzkaller/issues/516#issuecomment-395685629
Hm, I'm not sure we should hide such the situations from syzbot,
because the load like this may occur in real life on real workload.
They may help us to understand whether rtnl_mutex already needs
a redesign came from this statistics. Also, these hungs may happen
in a place, which can be rewritten without rtnl_mutex, so we focus
attention on it.
> Let's keep duping new such reports onto "INFO: task hung in
> netdev_run_todo" so that they are all collected at a single location.
>
> Thanks for help
Thanks,
Kirill
^ permalink raw reply
* Re: [RFC v6 4/5] virtio_ring: add event idx support in packed ring
From: Tiwei Bie @ 2018-06-08 8:32 UTC (permalink / raw)
To: Jason Wang; +Cc: mst, virtualization, linux-kernel, netdev, wexu, jfreimann
In-Reply-To: <c0621b16-3143-0bf7-f44f-3d1173577734@redhat.com>
On Thu, Jun 07, 2018 at 05:50:32PM +0800, Jason Wang wrote:
> On 2018年06月05日 15:40, Tiwei Bie wrote:
> > static bool virtqueue_enable_cb_delayed_packed(struct virtqueue *_vq)
> > {
> > struct vring_virtqueue *vq = to_vvq(_vq);
> > + u16 bufs, used_idx, wrap_counter;
> > START_USE(vq);
> > /* We optimistically turn back on interrupts, then check if there was
> > * more to do. */
> > + /* Depending on the VIRTIO_RING_F_EVENT_IDX feature, we need to
> > + * either clear the flags bit or point the event index at the next
> > + * entry. Always update the event index to keep code simple. */
> > +
>
> Maybe for packed ring, it's time to treat event index separately to avoid a
> virtio_wmb() for event idx is off.
Okay. I'll do it.
>
> > + /* TODO: tune this threshold */
> > + if (vq->next_avail_idx < vq->last_used_idx)
> > + bufs = (vq->vring_packed.num + vq->next_avail_idx -
> > + vq->last_used_idx) * 3 / 4;
> > + else
> > + bufs = (vq->next_avail_idx - vq->last_used_idx) * 3 / 4;
>
> vq->next_avail-idx could be equal to vq->last_usd_idx when the ring is full.
> Though virito-net is the only user now and it can guarantee this won't
> happen. But consider this is a core API, we should make sure it can work for
> any cases.
>
> It looks to me that bufs is just vq->vring_packed.num - vq->num_free?
I'll try it! Thanks for the suggestion! :)
>
> > +
> > + wrap_counter = vq->used_wrap_counter;
> > +
> > + used_idx = vq->last_used_idx + bufs;
> > + if (used_idx >= vq->vring_packed.num) {
> > + used_idx -= vq->vring_packed.num;
> > + wrap_counter ^= 1;
> > + }
> > +
> > + vq->vring_packed.driver->off_wrap = cpu_to_virtio16(_vq->vdev,
> > + used_idx | (wrap_counter << 15));
> > if (vq->event_flags_shadow == VRING_EVENT_F_DISABLE) {
> > - vq->event_flags_shadow = VRING_EVENT_F_ENABLE;
> > + /* We need to update event offset and event wrap
> > + * counter first before updating event flags. */
> > + virtio_wmb(vq->weak_barriers);
> > + vq->event_flags_shadow = vq->event ? VRING_EVENT_F_DESC :
> > + VRING_EVENT_F_ENABLE;
> > vq->vring_packed.driver->flags = cpu_to_virtio16(_vq->vdev,
> > vq->event_flags_shadow);
> > - /* We need to enable interrupts first before re-checking
> > - * for more used buffers. */
> > - virtio_mb(vq->weak_barriers);
> > }
> > + /* We need to update event suppression structure first
> > + * before re-checking for more used buffers. */
> > + virtio_mb(vq->weak_barriers);
> > +
> > if (more_used_packed(vq)) {
> > END_USE(vq);
> > return false;
>
> I think what we need to to make sure the descriptor used_idx is used?
> Otherwise we may stop and restart qdisc too frequently?
Good catch! Yeah. It's not the best choice to check the
descriptor at last_used_idx. I'll try to fix this!
Best regards,
Tiwei Bie
>
> Thanks
>
> > --
>
^ permalink raw reply
* Re: INFO: task hung in ip6gre_exit_batch_net
From: Dmitry Vyukov @ 2018-06-08 8:38 UTC (permalink / raw)
To: Kirill Tkhai
Cc: syzbot, Christian Brauner, David Miller, David Ahern,
Florian Westphal, Jiri Benc, LKML, Xin Long, mschiffer, netdev,
syzkaller-bugs, Vladislav Yasevich
In-Reply-To: <d544eb27-339b-a7df-3143-08ac0fc9bc69@virtuozzo.com>
On Fri, Jun 8, 2018 at 10:31 AM, Kirill Tkhai <ktkhai@virtuozzo.com> wrote:
>>>>>>>>> Hi, Dmirty!
>>>>>>>>>
>>>>>>>>> On 04.06.2018 18:22, Dmitry Vyukov wrote:
>>>>>>>>>> On Mon, Jun 4, 2018 at 5:03 PM, syzbot
>>>>>>>>>> <syzbot+bf78a74f82c1cf19069e@syzkaller.appspotmail.com> wrote:
>>>>>>>>>>> Hello,
>>>>>>>>>>>
>>>>>>>>>>> syzbot found the following crash on:
>>>>>>>>>>>
>>>>>>>>>>> HEAD commit: bc2dbc5420e8 Merge branch 'akpm' (patches from Andrew)
>>>>>>>>>>> git tree: upstream
>>>>>>>>>>> console output: https://syzkaller.appspot.com/x/log.txt?x=164e42b7800000
>>>>>>>>>>> kernel config: https://syzkaller.appspot.com/x/.config?x=982e2df1b9e60b02
>>>>>>>>>>> dashboard link: https://syzkaller.appspot.com/bug?extid=bf78a74f82c1cf19069e
>>>>>>>>>>> compiler: gcc (GCC) 8.0.1 20180413 (experimental)
>>>>>>>>>>>
>>>>>>>>>>> Unfortunately, I don't have any reproducer for this crash yet.
>>>>>>>>>>>
>>>>>>>>>>> IMPORTANT: if you fix the bug, please add the following tag to the commit:
>>>>>>>>>>> Reported-by: syzbot+bf78a74f82c1cf19069e@syzkaller.appspotmail.com
>>>>>>>>>>
>>>>>>>>>> Another hang on rtnl lock:
>>>>>>>>>>
>>>>>>>>>> #syz dup: INFO: task hung in netdev_run_todo
>>>>>>>>>>
>>>>>>>>>> May be related to "unregister_netdevice: waiting for DEV to become free":
>>>>>>>>>> https://syzkaller.appspot.com/bug?id=1a97a5bd119fd97995f752819fd87840ab9479a9
>>>>>>>>
>>>>>>>> netdev_wait_allrefs does not hold rtnl lock during waiting, so it must
>>>>>>>> be something different.
>>>>>>>>
>>>>>>>>
>>>>>>>>>> Any other explanations for massive hangs on rtnl lock for minutes?
>>>>>>>>>
>>>>>>>>> To exclude the situation, when a task exists with rtnl_mutex held:
>>>>>>>>>
>>>>>>>>> would the pr_warn() from print_held_locks_bug() be included in the console output
>>>>>>>>> if they appear?
>>>>>>>>
>>>>>>>> Yes, everything containing "WARNING:" is detected as bug.
>>>>>>>
>>>>>>> OK, then dead task not releasing the lock is excluded.
>>>>>>>
>>>>>>> One more assumption: someone corrupted memory around rtnl_mutex and it looks like locked.
>>>>>>> (I track lockdep "(rtnl_mutex){+.+.}" prints in initial message as "nobody owns rtnl_mutex").
>>>>>>> There may help a crash dump of the VM.
>>>>>>
>>>>>> I can't find any legend for these +'s and .'s, but {+.+.} is present
>>>>>> in large amounts in just any task hung report for different mutexes,
>>>>>> so I would not expect that it means corruption.
>>>>>>
>>>>>> Are dozens of known corruptions that syzkaller can trigger. But
>>>>>> usually they are reliably caught by KASAN. If any of them would lead
>>>>>> to silent memory corruption, we would got dozens of assorted crashes
>>>>>> throughout the kernel. We've seen that at some points, but not
>>>>>> recently. So I would assume that memory is not corrupted in all these
>>>>>> cases:
>>>>>> https://syzkaller.appspot.com/bug?id=2503c576cabb08d41812e732b390141f01a59545
>>>>>
>>>>> This BUG clarifies the {+.+.}:
>>>>>
>>>>> 4 locks held by kworker/0:145/381:
>>>>> #0: ((wq_completion)"hwsim_wq"){+.+.}, at: [<000000003f9487f0>] work_static include/linux/workqueue.h:198 [inline]
>>>>> #0: ((wq_completion)"hwsim_wq"){+.+.}, at: [<000000003f9487f0>] set_work_data kernel/workqueue.c:619 [inline]
>>>>> #0: ((wq_completion)"hwsim_wq"){+.+.}, at: [<000000003f9487f0>] set_work_pool_and_clear_pending kernel/workqueue.c:646 [inline]
>>>>> #0: ((wq_completion)"hwsim_wq"){+.+.}, at: [<000000003f9487f0>] process_one_work+0xb12/0x1bb0 kernel/workqueue.c:2084
>>>>> #1: ((work_completion)(&data->destroy_work)){+.+.}, at: [<00000000bbdd2115>] process_one_work+0xb89/0x1bb0 kernel/workqueue.c:2088
>>>>> #2: (rtnl_mutex){+.+.}, at: [<000000009c9d14f8>] rtnl_lock+0x17/0x20 net/core/rtnetlink.c:74
>>>>> #3: (rcu_sched_state.exp_mutex){+.+.}, at: [<000000001ba1a807>] exp_funnel_lock kernel/rcu/tree_exp.h:272 [inline]
>>>>> #3: (rcu_sched_state.exp_mutex){+.+.}, at: [<000000001ba1a807>] _synchronize_rcu_expedited.constprop.72+0x9fa/0xac0 kernel/rcu/tree_exp.h:596
>>>>>
>>>>> There we have rtnl_mutex locked and the {..} is like above. It's definitely locked
>>>>> since there is one more lock after it.
>>>>>
>>>>> This BUG happen because of there are many rtnl_mutex waiters while owner
>>>>> is synchronizing RCU. Rather clear for me in comparison to the topic's hung.
>>>>
>>>>
>>>> You mean that it's not hanged, but rather needs more than 2 minutes to
>>>> complete, right?
>>>
>>> Yeah, I think, this is possible. I've seen the situations like that.
>>> Let synchronize_rcu_expedited() is executed for X seconds. Then,
>>> it's need just 120/x calls of "this function under rtnl_mutex" to make
>>> a soft lockup of someone else who wants the mutex too.
>>>
>>> Also, despite the CFS is fair scheduler, in case of the calls are
>>> made from workqueue, every work will cause sleep. So, every work
>>> will be executed in separate worker task. Every worker will haved its
>>> own time slice. This increases the probability these tasks will
>>> take cpu time before the task in the header of the hang.
>>
>>
>> OK, let's stick with this theory for now. Looking at the crash frequencies here:
>> https://syzkaller.appspot.com/bug?id=2503c576cabb08d41812e732b390141f01a59545
>> I can actually believe that this is just flakes due to too slow execution.
>>
>> I've noted that we need either reduce load and/or increase timeouts:
>> https://github.com/google/syzkaller/issues/516#issuecomment-395685629
>
> Hm, I'm not sure we should hide such the situations from syzbot,
> because the load like this may occur in real life on real workload.
> They may help us to understand whether rtnl_mutex already needs
> a redesign came from this statistics. Also, these hungs may happen
> in a place, which can be rewritten without rtnl_mutex, so we focus
> attention on it.
If somebody wants to act on these reports:
https://syzkaller.appspot.com/bug?id=2503c576cabb08d41812e732b390141f01a59545
it's even better. The point is that testing must not have false
positives, one way or another. If we do nothing then syzbot will
slowly discover all 250 usages of rtnl_lock and produce unique bugs
for them. Each and every of these bug reports will need to handled by
somebody.
Does somebody want to act on these and improve rtnl performance in
foreseeable future?
^ permalink raw reply
* Re: [v3, 07/10] fsl/fman_port: support getting timestamp
From: kbuild test robot @ 2018-06-08 8:39 UTC (permalink / raw)
To: Yangbo Lu
Cc: kbuild-all, netdev, madalin.bucur, Richard Cochran, Rob Herring,
Shawn Guo, David S . Miller, devicetree, linuxppc-dev,
linux-arm-kernel, linux-kernel, Yangbo Lu
In-Reply-To: <20180607092050.46128-8-yangbo.lu@nxp.com>
Hi Yangbo,
I love your patch! Perhaps something to improve:
[auto build test WARNING on net-next/master]
[also build test WARNING on next-20180608]
[cannot apply to v4.17]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Yangbo-Lu/Support-DPAA-PTP-clock-and-timestamping/20180608-131649
reproduce:
# apt-get install sparse
make ARCH=x86_64 allmodconfig
make C=1 CF=-D__CHECK_ENDIAN__
sparse warnings: (new ones prefixed by >>)
drivers/net/ethernet/freescale/fman/fman_port.c:879:26: sparse: expression using sizeof(void)
drivers/net/ethernet/freescale/fman/fman_port.c:879:26: sparse: expression using sizeof(void)
drivers/net/ethernet/freescale/fman/fman_port.c:1035:36: sparse: expression using sizeof(void)
drivers/net/ethernet/freescale/fman/fman_port.c:1247:17: sparse: expression using sizeof(void)
drivers/net/ethernet/freescale/fman/fman_port.c:1249:17: sparse: expression using sizeof(void)
drivers/net/ethernet/freescale/fman/fman_port.c:1249:17: sparse: expression using sizeof(void)
>> drivers/net/ethernet/freescale/fman/fman_port.c:1739:19: sparse: cast to restricted __be64
>> drivers/net/ethernet/freescale/fman/fman_port.c:1739:19: sparse: cast to restricted __be64
>> drivers/net/ethernet/freescale/fman/fman_port.c:1739:19: sparse: cast to restricted __be64
>> drivers/net/ethernet/freescale/fman/fman_port.c:1739:19: sparse: cast to restricted __be64
>> drivers/net/ethernet/freescale/fman/fman_port.c:1739:19: sparse: cast to restricted __be64
>> drivers/net/ethernet/freescale/fman/fman_port.c:1739:19: sparse: cast to restricted __be64
>> drivers/net/ethernet/freescale/fman/fman_port.c:1739:19: sparse: cast to restricted __be64
>> drivers/net/ethernet/freescale/fman/fman_port.c:1739:19: sparse: cast to restricted __be64
>> drivers/net/ethernet/freescale/fman/fman_port.c:1739:19: sparse: cast to restricted __be64
>> drivers/net/ethernet/freescale/fman/fman_port.c:1739:19: sparse: cast to restricted __be64
vim +1739 drivers/net/ethernet/freescale/fman/fman_port.c
1733
1734 int fman_port_get_tstamp(struct fman_port *port, const void *data, u64 *tstamp)
1735 {
1736 if (port->buffer_offsets.time_stamp_offset == ILLEGAL_BASE)
1737 return -EINVAL;
1738
> 1739 *tstamp = be64_to_cpu(*(u64 *)(data +
1740 port->buffer_offsets.time_stamp_offset));
1741
1742 return 0;
1743 }
1744 EXPORT_SYMBOL(fman_port_get_tstamp);
1745
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
^ permalink raw reply
* Re: BUG: 4.14.11 unable to handle kernel NULL pointer dereference in xfrm_lookup
From: Kristian Evensen @ 2018-06-08 8:41 UTC (permalink / raw)
To: Tobias Hommel; +Cc: Steffen Klassert, Markus Berner, Network Development
In-Reply-To: <20180606160318.cg556jqobvd5z3ja@delI>
Hi,
On Wed, Jun 6, 2018 at 6:03 PM, Tobias Hommel <netdev-list@genoetigt.de> wrote:
> Sorry no progress until now, I currently do not get time to have a deeper look
> into that. We're back to 4.1.6 right now.
Thanks for letting me know. In the project I am currently involved in,
we unfortunately don't have the option of reverting the kernel, so we
are finding ways to live with the error. We have been looking into the
error a bit more, and have made the following observations:
* First of all, as discussed earlier in the thread, the error is
triggered by dst_orig being NULL. Our current work-around is just to
return from xfrm_lookup if dst_orig is NULL and this seems to work
fine, the error doesn't happen that often (in our use-cases at least).
* The machine we use for testing (and where we first saw the error) is
used as initiator.
* When we compare the logs from Strongswan with the ones from the
kernel, it seems that the error is typically triggered when a tunnels
is teared down/about to come up. We need quite a lot of tunnels for
the error to trigger, usually around 30+. I guess this might point to
some race or some condition not being met when packets are
sent/received.
* We see the error much more frequently when hardware encryption is enabled.
* Yesterday, we upgraded the kernel from 4.14.34 to 4.14.48, and the
error happens much less frequently. I see that 4.14.48 includes
several IPsec fixes (for example the previously mentioned ("xfrm: Fix
a race in the xdst pcpu cache.")).
BR,
Kristian
^ permalink raw reply
* Re: INFO: task hung in ip6gre_exit_batch_net
From: Kirill Tkhai @ 2018-06-08 8:43 UTC (permalink / raw)
To: Dmitry Vyukov
Cc: syzbot, Christian Brauner, David Miller, David Ahern,
Florian Westphal, Jiri Benc, LKML, Xin Long, mschiffer, netdev,
syzkaller-bugs, Vladislav Yasevich
In-Reply-To: <CACT4Y+Zo1e3VFEtXRUToM6Gk_pD7egdi6c-VbAhCOc-=cdfJWA@mail.gmail.com>
On 08.06.2018 11:38, Dmitry Vyukov wrote:
> On Fri, Jun 8, 2018 at 10:31 AM, Kirill Tkhai <ktkhai@virtuozzo.com> wrote:
>>>>>>>>>> Hi, Dmirty!
>>>>>>>>>>
>>>>>>>>>> On 04.06.2018 18:22, Dmitry Vyukov wrote:
>>>>>>>>>>> On Mon, Jun 4, 2018 at 5:03 PM, syzbot
>>>>>>>>>>> <syzbot+bf78a74f82c1cf19069e@syzkaller.appspotmail.com> wrote:
>>>>>>>>>>>> Hello,
>>>>>>>>>>>>
>>>>>>>>>>>> syzbot found the following crash on:
>>>>>>>>>>>>
>>>>>>>>>>>> HEAD commit: bc2dbc5420e8 Merge branch 'akpm' (patches from Andrew)
>>>>>>>>>>>> git tree: upstream
>>>>>>>>>>>> console output: https://syzkaller.appspot.com/x/log.txt?x=164e42b7800000
>>>>>>>>>>>> kernel config: https://syzkaller.appspot.com/x/.config?x=982e2df1b9e60b02
>>>>>>>>>>>> dashboard link: https://syzkaller.appspot.com/bug?extid=bf78a74f82c1cf19069e
>>>>>>>>>>>> compiler: gcc (GCC) 8.0.1 20180413 (experimental)
>>>>>>>>>>>>
>>>>>>>>>>>> Unfortunately, I don't have any reproducer for this crash yet.
>>>>>>>>>>>>
>>>>>>>>>>>> IMPORTANT: if you fix the bug, please add the following tag to the commit:
>>>>>>>>>>>> Reported-by: syzbot+bf78a74f82c1cf19069e@syzkaller.appspotmail.com
>>>>>>>>>>>
>>>>>>>>>>> Another hang on rtnl lock:
>>>>>>>>>>>
>>>>>>>>>>> #syz dup: INFO: task hung in netdev_run_todo
>>>>>>>>>>>
>>>>>>>>>>> May be related to "unregister_netdevice: waiting for DEV to become free":
>>>>>>>>>>> https://syzkaller.appspot.com/bug?id=1a97a5bd119fd97995f752819fd87840ab9479a9
>>>>>>>>>
>>>>>>>>> netdev_wait_allrefs does not hold rtnl lock during waiting, so it must
>>>>>>>>> be something different.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>> Any other explanations for massive hangs on rtnl lock for minutes?
>>>>>>>>>>
>>>>>>>>>> To exclude the situation, when a task exists with rtnl_mutex held:
>>>>>>>>>>
>>>>>>>>>> would the pr_warn() from print_held_locks_bug() be included in the console output
>>>>>>>>>> if they appear?
>>>>>>>>>
>>>>>>>>> Yes, everything containing "WARNING:" is detected as bug.
>>>>>>>>
>>>>>>>> OK, then dead task not releasing the lock is excluded.
>>>>>>>>
>>>>>>>> One more assumption: someone corrupted memory around rtnl_mutex and it looks like locked.
>>>>>>>> (I track lockdep "(rtnl_mutex){+.+.}" prints in initial message as "nobody owns rtnl_mutex").
>>>>>>>> There may help a crash dump of the VM.
>>>>>>>
>>>>>>> I can't find any legend for these +'s and .'s, but {+.+.} is present
>>>>>>> in large amounts in just any task hung report for different mutexes,
>>>>>>> so I would not expect that it means corruption.
>>>>>>>
>>>>>>> Are dozens of known corruptions that syzkaller can trigger. But
>>>>>>> usually they are reliably caught by KASAN. If any of them would lead
>>>>>>> to silent memory corruption, we would got dozens of assorted crashes
>>>>>>> throughout the kernel. We've seen that at some points, but not
>>>>>>> recently. So I would assume that memory is not corrupted in all these
>>>>>>> cases:
>>>>>>> https://syzkaller.appspot.com/bug?id=2503c576cabb08d41812e732b390141f01a59545
>>>>>>
>>>>>> This BUG clarifies the {+.+.}:
>>>>>>
>>>>>> 4 locks held by kworker/0:145/381:
>>>>>> #0: ((wq_completion)"hwsim_wq"){+.+.}, at: [<000000003f9487f0>] work_static include/linux/workqueue.h:198 [inline]
>>>>>> #0: ((wq_completion)"hwsim_wq"){+.+.}, at: [<000000003f9487f0>] set_work_data kernel/workqueue.c:619 [inline]
>>>>>> #0: ((wq_completion)"hwsim_wq"){+.+.}, at: [<000000003f9487f0>] set_work_pool_and_clear_pending kernel/workqueue.c:646 [inline]
>>>>>> #0: ((wq_completion)"hwsim_wq"){+.+.}, at: [<000000003f9487f0>] process_one_work+0xb12/0x1bb0 kernel/workqueue.c:2084
>>>>>> #1: ((work_completion)(&data->destroy_work)){+.+.}, at: [<00000000bbdd2115>] process_one_work+0xb89/0x1bb0 kernel/workqueue.c:2088
>>>>>> #2: (rtnl_mutex){+.+.}, at: [<000000009c9d14f8>] rtnl_lock+0x17/0x20 net/core/rtnetlink.c:74
>>>>>> #3: (rcu_sched_state.exp_mutex){+.+.}, at: [<000000001ba1a807>] exp_funnel_lock kernel/rcu/tree_exp.h:272 [inline]
>>>>>> #3: (rcu_sched_state.exp_mutex){+.+.}, at: [<000000001ba1a807>] _synchronize_rcu_expedited.constprop.72+0x9fa/0xac0 kernel/rcu/tree_exp.h:596
>>>>>>
>>>>>> There we have rtnl_mutex locked and the {..} is like above. It's definitely locked
>>>>>> since there is one more lock after it.
>>>>>>
>>>>>> This BUG happen because of there are many rtnl_mutex waiters while owner
>>>>>> is synchronizing RCU. Rather clear for me in comparison to the topic's hung.
>>>>>
>>>>>
>>>>> You mean that it's not hanged, but rather needs more than 2 minutes to
>>>>> complete, right?
>>>>
>>>> Yeah, I think, this is possible. I've seen the situations like that.
>>>> Let synchronize_rcu_expedited() is executed for X seconds. Then,
>>>> it's need just 120/x calls of "this function under rtnl_mutex" to make
>>>> a soft lockup of someone else who wants the mutex too.
>>>>
>>>> Also, despite the CFS is fair scheduler, in case of the calls are
>>>> made from workqueue, every work will cause sleep. So, every work
>>>> will be executed in separate worker task. Every worker will haved its
>>>> own time slice. This increases the probability these tasks will
>>>> take cpu time before the task in the header of the hang.
>>>
>>>
>>> OK, let's stick with this theory for now. Looking at the crash frequencies here:
>>> https://syzkaller.appspot.com/bug?id=2503c576cabb08d41812e732b390141f01a59545
>>> I can actually believe that this is just flakes due to too slow execution.
>>>
>>> I've noted that we need either reduce load and/or increase timeouts:
>>> https://github.com/google/syzkaller/issues/516#issuecomment-395685629
>>
>> Hm, I'm not sure we should hide such the situations from syzbot,
>> because the load like this may occur in real life on real workload.
>> They may help us to understand whether rtnl_mutex already needs
>> a redesign came from this statistics. Also, these hungs may happen
>> in a place, which can be rewritten without rtnl_mutex, so we focus
>> attention on it.
>
> If somebody wants to act on these reports:
> https://syzkaller.appspot.com/bug?id=2503c576cabb08d41812e732b390141f01a59545
> it's even better. The point is that testing must not have false
> positives, one way or another. If we do nothing then syzbot will
> slowly discover all 250 usages of rtnl_lock and produce unique bugs
> for them. Each and every of these bug reports will need to handled by
> somebody.
>
> Does somebody want to act on these and improve rtnl performance in
> foreseeable future?
I just analyzed this question a little bit, and it looks like only
the preparations for improving the performance will take much much time.
And the performance won't change till preparations are finished.
So, this looks like "not a foreseeable future".
Kirill
^ permalink raw reply
* Re: [PATCH] [net-next, wrong] make BPFILTER_UMH depend on X86
From: Geert Uytterhoeven @ 2018-06-08 8:57 UTC (permalink / raw)
To: Arnd Bergmann, Alexei Starovoitov
Cc: David S. Miller, Masahiro Yamada, linux-kbuild, netdev,
Linux Kernel Mailing List
In-Reply-To: <20180528153222.2037158-1-arnd@arndb.de>
Hi Arnd, Alexei,
On Mon, May 28, 2018 at 5:31 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> When build testing across architectures, I run into a build error on
> all targets other than X86:
>
> gcc-8.1.0-nolibc/arm-linux-gnueabi/bin/arm-linux-gnueabi-objdump: net/bpfilter/bpfilter_umh: File format not recognized
> gcc-8.1.0-nolibc/arm-linux-gnueabi/bin/arm-linux-gnueabi-objcopy:net/bpfilter/bpfilter_umh.o: Invalid bfd target
>
> The problem is that 'hostprogs' get built with 'gcc' rather than
> '$(CROSS_COMPILE)gcc', and my default gcc (as most people's) targets x86.
>
> To work around it, adding an X86 dependency gets randconfigs building
> again on my box.
>
> Clearly, this is not a good solution, since it should actually work fine
> when building native kernels on other architectures but that is now
> disabled, while cross building an x86 kernel on another host is still
> broken after my patch.
>
> What we probably want here is to try out if the compiler is able to build
> executables for the target architecture and not build the helper otherwise,
> at least when compile-testing. No idea how to do that though.
So that was done in commit 819dd92b9c0bc7bc ("bpfilter: switch to CC
from HOSTCC"), but it is not sufficient:
GEN net/bpfilter/bpfilter_umh.o
Usage: m68k-linux-gnu-objcopy [option(s)] in-file [out-file]
Copies a binary file, possibly transforming it in the process
The options are:
[...]
net/bpfilter/Makefile:29: recipe for target 'net/bpfilter/bpfilter_umh.o' failed
make[5]: *** [net/bpfilter/bpfilter_umh.o] Error 1
> --- a/net/bpfilter/Kconfig
> +++ b/net/bpfilter/Kconfig
> @@ -9,6 +9,7 @@ menuconfig BPFILTER
> if BPFILTER
> config BPFILTER_UMH
> tristate "bpfilter kernel module with user mode helper"
> + depends on X86 # actually depends on native builds
No, (currently) it does depend on X86, due to its use of:
$(OBJCOPY) -I binary -O $(CONFIG_OUTPUT_FORMAT)
with CONFIG_OUTPUT_FORMAT being defined on X86 only...
> default m
> help
> This builds bpfilter kernel module with embedded user mode helper
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [PATCH v6 net] stmmac: strip all VLAN tag types when kernel 802.1Q support is selected
From: Elad Nachman @ 2018-06-08 9:19 UTC (permalink / raw)
To: Toshiaki Makita, David Miller
Cc: Jose.Abreu, f.fainelli, netdev, peppe.cavallaro, alexandre.torgue,
eladv6
In-Reply-To: <7b97acda-c9c9-2651-6803-22225d7b47f7@lab.ntt.co.jp>
stmmac reception handler calls stmmac_rx_vlan() to strip the vlan before
calling napi_gro_receive().
The function assumes VLAN tagged frames are always tagged with
802.1Q protocol, and assigns ETH_P_8021Q to the skb by hard-coding
the parameter on call to __vlan_hwaccel_put_tag() .
This causes packets not to be passed to the VLAN slave if it was created
with 802.1AD protocol
(ip link add link eth0 eth0.100 type vlan proto 802.1ad id 100).
This fix passes the protocol from the VLAN header into
__vlan_hwaccel_put_tag() instead of using the hard-coded value of
ETH_P_8021Q.
NETIF_F_HW_VLAN_CTAG_RX check was removed and instead the strip action
is dependent upon a preprocessor define which is defined when 802.1Q
support is selected in the kernel config.
NETIF_F_HW_VLAN_STAG_RX feature was added to be in line with the driver
actual abilities.
Signed-off-by: Elad Nachman <eladn@gilat.com>
---
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 18 ++++++++++--------
1 file changed, 10 insertions(+), 8 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index b65e2d1..707917d 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -3293,18 +3293,20 @@ static netdev_tx_t stmmac_xmit(struct sk_buff *skb, struct net_device *dev)
static void stmmac_rx_vlan(struct net_device *dev, struct sk_buff *skb)
{
- struct ethhdr *ehdr;
+#ifdef STMMAC_VLAN_TAG_USED
+ struct vlan_ethhdr *veth;
+ __be16 vlan_proto;
u16 vlanid;
- if ((dev->features & NETIF_F_HW_VLAN_CTAG_RX) ==
- NETIF_F_HW_VLAN_CTAG_RX &&
- !__vlan_get_tag(skb, &vlanid)) {
+ if (!__vlan_get_tag(skb, &vlanid)) {
/* pop the vlan tag */
- ehdr = (struct ethhdr *)skb->data;
- memmove(skb->data + VLAN_HLEN, ehdr, ETH_ALEN * 2);
+ veth = (struct vlan_ethhdr *)skb->data;
+ vlan_proto = veth->h_vlan_proto;
+ memmove(skb->data + VLAN_HLEN, veth, ETH_ALEN * 2);
skb_pull(skb, VLAN_HLEN);
- __vlan_hwaccel_put_tag(skb, htons(ETH_P_8021Q), vlanid);
+ __vlan_hwaccel_put_tag(skb, vlan_proto, vlanid);
}
+#endif
}
@@ -4344,7 +4346,7 @@ int stmmac_dvr_probe(struct device *device,
ndev->watchdog_timeo = msecs_to_jiffies(watchdog);
#ifdef STMMAC_VLAN_TAG_USED
/* Both mac100 and gmac support receive VLAN tag detection */
- ndev->features |= NETIF_F_HW_VLAN_CTAG_RX;
+ ndev->features |= NETIF_F_HW_VLAN_CTAG_RX | NETIF_F_HW_VLAN_STAG_RX;
#endif
priv->msg_enable = netif_msg_init(debug, default_msg_level);
--
2.7.4
^ permalink raw reply related
* [PATCH ethtool 1/6] ethtool: fix uninitialized return value
From: Ivan Vecera @ 2018-06-08 9:20 UTC (permalink / raw)
To: linville; +Cc: netdev
Fixes: b0fe96d ("Ethtool: Implements ETHTOOL_PHY_GTUNABLE/ETHTOOL_PHY_STUNABLE and PHY downshift")
Signed-off-by: Ivan Vecera <cera@cera.cz>
---
ethtool.c | 7 +++----
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/ethtool.c b/ethtool.c
index 2e87384..e7495fe 100644
--- a/ethtool.c
+++ b/ethtool.c
@@ -4723,8 +4723,8 @@ static int do_get_phy_tunable(struct cmd_context *ctx)
{
int argc = ctx->argc;
char **argp = ctx->argp;
- int err, i;
u8 downshift_changed = 0;
+ int i;
if (argc < 1)
exit_bad_args();
@@ -4750,8 +4750,7 @@ static int do_get_phy_tunable(struct cmd_context *ctx)
cont.ds.id = ETHTOOL_PHY_DOWNSHIFT;
cont.ds.type_id = ETHTOOL_TUNABLE_U8;
cont.ds.len = 1;
- err = send_ioctl(ctx, &cont.ds);
- if (err < 0) {
+ if (send_ioctl(ctx, &cont.ds) < 0) {
perror("Cannot Get PHY downshift count");
return 87;
}
@@ -4762,7 +4761,7 @@ static int do_get_phy_tunable(struct cmd_context *ctx)
fprintf(stdout, "Downshift disabled\n");
}
- return err;
+ return 0;
}
static __u32 parse_reset(char *val, __u32 bitset, char *arg, __u32 *data)
--
2.16.4
^ permalink raw reply related
* [PATCH ethtool 2/6] ethtool: fix RING_VF assignment
From: Ivan Vecera @ 2018-06-08 9:20 UTC (permalink / raw)
To: linville; +Cc: netdev, Jacob Keller
In-Reply-To: <20180608092010.13041-1-cera@cera.cz>
Fixes: 36ee712 ("ethtool: support queue and VF fields for rxclass filters")
Cc: Jacob Keller <jacob.e.keller@intel.com>
Signed-off-by: Ivan Vecera <cera@cera.cz>
---
rxclass.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/rxclass.c b/rxclass.c
index ce4b382..42d122d 100644
--- a/rxclass.c
+++ b/rxclass.c
@@ -1066,7 +1066,7 @@ static int rxclass_get_val(char *str, unsigned char *p, u32 *flags,
val++;
*(u64 *)&p[opt->offset] &= ~ETHTOOL_RX_FLOW_SPEC_RING_VF;
- *(u64 *)&p[opt->offset] = (u64)val << ETHTOOL_RX_FLOW_SPEC_RING_VF_OFF;
+ *(u64 *)&p[opt->offset] |= (u64)val << ETHTOOL_RX_FLOW_SPEC_RING_VF_OFF;
break;
}
case OPT_RING_QUEUE: {
--
2.16.4
^ permalink raw reply related
* [PATCH ethtool 3/6] ethtool: remove unused global variable
From: Ivan Vecera @ 2018-06-08 9:20 UTC (permalink / raw)
To: linville; +Cc: netdev
In-Reply-To: <20180608092010.13041-1-cera@cera.cz>
Fixes: 2c2ee7a ("ethtool: Add support for sfc register dumps")
Signed-off-by: Ivan Vecera <cera@cera.cz>
---
sfc.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/sfc.c b/sfc.c
index 9478b38..b4c590f 100644
--- a/sfc.c
+++ b/sfc.c
@@ -3083,9 +3083,6 @@ static const struct efx_nic_reg_field efx_nic_reg_fields_TX_PACE[] = {
REGISTER_FIELD_BZ(TX_PACE_SB_AF),
REGISTER_FIELD_BZ(TX_PACE_SB_NOT_AF),
};
-static const struct efx_nic_reg_field efx_nic_reg_fields_TX_PACE_DROP_QID[] = {
- REGISTER_FIELD_BZ(TX_PACE_QID_DRP_CNT),
-};
static const struct efx_nic_reg_field efx_nic_reg_fields_TX_VLAN[] = {
REGISTER_FIELD_BB(TX_VLAN0),
REGISTER_FIELD_BB(TX_VLAN0_PORT0_EN),
--
2.16.4
^ permalink raw reply related
* [PATCH ethtool 4/6] ethtool: several fixes in do_gregs()
From: Ivan Vecera @ 2018-06-08 9:20 UTC (permalink / raw)
To: linville; +Cc: netdev, David Decotigny
In-Reply-To: <20180608092010.13041-1-cera@cera.cz>
- correctly close gregs_dump_file in case of fstat() failure
- check for error from realloc
Fixes: be4c2d0 ("ethtool.c: fix dump_regs heap corruption")
Cc: David Decotigny <decot@googlers.com>
Signed-off-by: Ivan Vecera <cera@cera.cz>
---
ethtool.c | 11 ++++++++++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/ethtool.c b/ethtool.c
index e7495fe..2b90984 100644
--- a/ethtool.c
+++ b/ethtool.c
@@ -3179,17 +3179,26 @@ static int do_gregs(struct cmd_context *ctx)
if (!gregs_dump_raw && gregs_dump_file != NULL) {
/* overwrite reg values from file dump */
FILE *f = fopen(gregs_dump_file, "r");
+ struct ethtool_regs *nregs;
struct stat st;
size_t nread;
if (!f || fstat(fileno(f), &st) < 0) {
fprintf(stderr, "Can't open '%s': %s\n",
gregs_dump_file, strerror(errno));
+ if (f)
+ fclose(f);
free(regs);
return 75;
}
- regs = realloc(regs, sizeof(*regs) + st.st_size);
+ nregs = realloc(regs, sizeof(*regs) + st.st_size);
+ if (!nregs) {
+ perror("Cannot allocate memory for register dump");
+ free(regs); /* was not freed by realloc */
+ return 73;
+ }
+ regs = nregs;
regs->len = st.st_size;
nread = fread(regs->data, regs->len, 1, f);
fclose(f);
--
2.16.4
^ permalink raw reply related
* [PATCH ethtool 5/6] ethtool: correctly free hkey when get_stringset() fails
From: Ivan Vecera @ 2018-06-08 9:20 UTC (permalink / raw)
To: linville; +Cc: netdev, Gal Pressman
In-Reply-To: <20180608092010.13041-1-cera@cera.cz>
Memory allocated for 'hkey' is not freed when
get_stringset(..., ETH_SS_RSS_HASH_FUNCS...) fails.
Fixes: b888f35 ("ethtool: Support for configurable RSS hash function")
Cc: Gal Pressman <galp@mellanox.com>
Signed-off-by: Ivan Vecera <cera@cera.cz>
---
ethtool.c | 13 ++++++-------
1 file changed, 6 insertions(+), 7 deletions(-)
diff --git a/ethtool.c b/ethtool.c
index 2b90984..fb93ae8 100644
--- a/ethtool.c
+++ b/ethtool.c
@@ -3910,7 +3910,7 @@ static int do_srxfhindir(struct cmd_context *ctx, int rxfhindir_default,
static int do_srxfh(struct cmd_context *ctx)
{
struct ethtool_rxfh rss_head = {0};
- struct ethtool_rxfh *rss;
+ struct ethtool_rxfh *rss = NULL;
struct ethtool_rxnfc ring_count;
int rxfhindir_equal = 0, rxfhindir_default = 0;
struct ethtool_gstrings *hfuncs = NULL;
@@ -4064,7 +4064,8 @@ static int do_srxfh(struct cmd_context *ctx)
hfuncs = get_stringset(ctx, ETH_SS_RSS_HASH_FUNCS, 0, 1);
if (!hfuncs) {
perror("Cannot get hash functions names");
- return 1;
+ err = 1;
+ goto free;
}
for (i = 0; i < hfuncs->len && !req_hfunc ; i++) {
@@ -4078,8 +4079,8 @@ static int do_srxfh(struct cmd_context *ctx)
if (!req_hfunc) {
fprintf(stderr,
"Unknown hash function: %s\n", req_hfunc_name);
- free(hfuncs);
- return 1;
+ err = 1;
+ goto free;
}
}
@@ -4120,9 +4121,7 @@ static int do_srxfh(struct cmd_context *ctx)
}
free:
- if (hkey)
- free(hkey);
-
+ free(hkey);
free(rss);
free(hfuncs);
return err;
--
2.16.4
^ permalink raw reply related
* [PATCH ethtool 6/6] ethtool: remove unreachable code
From: Ivan Vecera @ 2018-06-08 9:20 UTC (permalink / raw)
To: linville; +Cc: netdev, Vidya Sagar Ravipati
In-Reply-To: <20180608092010.13041-1-cera@cera.cz>
The default switch case is unreachable as the MAX_CHANNEL_NUM == 4.
Fixes: a5e73bb ("ethtool:QSFP Plus/QSFP28 Diagnostics Information Support")
Cc: Vidya Sagar Ravipati <vidya@cumulusnetworks.com>
Signed-off-by: Ivan Vecera <cera@cera.cz>
---
qsfp.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/qsfp.c b/qsfp.c
index aecd5bb..32e195d 100644
--- a/qsfp.c
+++ b/qsfp.c
@@ -661,9 +661,6 @@ static void sff8636_dom_parse(const __u8 *id, struct sff_diags *sd)
tx_power_offset = SFF8636_TX_PWR_4_OFFSET;
tx_bias_offset = SFF8636_TX_BIAS_4_OFFSET;
break;
- default:
- printf(" Invalid channel: %d\n", i);
- break;
}
sd->scd[i].bias_cur = OFFSET_TO_U16(tx_bias_offset);
sd->scd[i].rx_power = OFFSET_TO_U16(rx_power_offset);
--
2.16.4
^ permalink raw reply related
* [PATCH] net: thunderx: prevent concurrent data re-writing by nicvf_set_rx_mode
From: Vadim Lomovtsev @ 2018-06-08 9:27 UTC (permalink / raw)
To: davem, rric, sgoutham, linux-arm-kernel, netdev, linux-kernel
Cc: dnelson, Vadim Lomovtsev
From: Vadim Lomovtsev <Vadim.Lomovtsev@cavium.com>
For each network interface linux network stack issue ndo_set_rx_mode call
in order to configure MAC address filters (e.g. for multicast filtering).
Currently ThunderX NICVF driver has only one ordered workqueue to process
such requests for all VFs.
And because of that it is possible that subsequent call to
ndo_set_rx_mode would corrupt data which is currently in use
by nicvf_set_rx_mode_task. Which in turn could cause following issue:
[...]
[ 48.978341] Unable to handle kernel paging request at virtual address 1fffff0000000000
[ 48.986275] Mem abort info:
[ 48.989058] Exception class = DABT (current EL), IL = 32 bits
[ 48.994965] SET = 0, FnV = 0
[ 48.998020] EA = 0, S1PTW = 0
[ 49.001152] Data abort info:
[ 49.004022] ISV = 0, ISS = 0x00000004
[ 49.007869] CM = 0, WnR = 0
[ 49.010826] [1fffff0000000000] address between user and kernel address ranges
[ 49.017963] Internal error: Oops: 96000004 [#1] SMP
[...]
[ 49.072138] task: ffff800fdd675400 task.stack: ffff000026440000
[ 49.078051] PC is at prefetch_freepointer.isra.37+0x28/0x3c
[ 49.083613] LR is at kmem_cache_alloc_trace+0xc8/0x1fc
[...]
[ 49.272684] [<ffff0000082738f0>] prefetch_freepointer.isra.37+0x28/0x3c
[ 49.279286] [<ffff000008276bc8>] kmem_cache_alloc_trace+0xc8/0x1fc
[ 49.285455] [<ffff0000082c0c0c>] alloc_fdtable+0x78/0x134
[ 49.290841] [<ffff0000082c15c0>] dup_fd+0x254/0x2f4
[ 49.295709] [<ffff0000080d1954>] copy_process.isra.38.part.39+0x64c/0x1168
[ 49.302572] [<ffff0000080d264c>] _do_fork+0xfc/0x3b0
[ 49.307524] [<ffff0000080d29e8>] SyS_clone+0x44/0x50
[...]
This patch is to prevent such concurrent data write with spinlock.
Reported-by: Dean Nelson <dnelson@redhat.com>
Signed-off-by: Vadim Lomovtsev <Vadim.Lomovtsev@cavium.com>
---
drivers/net/ethernet/cavium/thunder/nic.h | 2 +
drivers/net/ethernet/cavium/thunder/nicvf_main.c | 50 +++++++++++++++++-------
2 files changed, 38 insertions(+), 14 deletions(-)
diff --git a/drivers/net/ethernet/cavium/thunder/nic.h b/drivers/net/ethernet/cavium/thunder/nic.h
index 448d1fafc827..f4d81765221e 100644
--- a/drivers/net/ethernet/cavium/thunder/nic.h
+++ b/drivers/net/ethernet/cavium/thunder/nic.h
@@ -325,6 +325,8 @@ struct nicvf {
struct tasklet_struct qs_err_task;
struct work_struct reset_task;
struct nicvf_work rx_mode_work;
+ /* spinlock to protect workqueue arguments from concurrent access */
+ spinlock_t rx_mode_wq_lock;
/* PTP timestamp */
struct cavium_ptp *ptp_clock;
diff --git a/drivers/net/ethernet/cavium/thunder/nicvf_main.c b/drivers/net/ethernet/cavium/thunder/nicvf_main.c
index 7135db45927e..135766c4296b 100644
--- a/drivers/net/ethernet/cavium/thunder/nicvf_main.c
+++ b/drivers/net/ethernet/cavium/thunder/nicvf_main.c
@@ -1923,17 +1923,12 @@ static int nicvf_ioctl(struct net_device *netdev, struct ifreq *req, int cmd)
}
}
-static void nicvf_set_rx_mode_task(struct work_struct *work_arg)
+static void __nicvf_set_rx_mode_task(u8 mode, struct xcast_addr_list *mc_addrs,
+ struct nicvf *nic)
{
- struct nicvf_work *vf_work = container_of(work_arg, struct nicvf_work,
- work.work);
- struct nicvf *nic = container_of(vf_work, struct nicvf, rx_mode_work);
union nic_mbx mbx = {};
int idx;
- if (!vf_work)
- return;
-
/* From the inside of VM code flow we have only 128 bits memory
* available to send message to host's PF, so send all mc addrs
* one by one, starting from flush command in case if kernel
@@ -1944,7 +1939,7 @@ static void nicvf_set_rx_mode_task(struct work_struct *work_arg)
mbx.xcast.msg = NIC_MBOX_MSG_RESET_XCAST;
nicvf_send_msg_to_pf(nic, &mbx);
- if (vf_work->mode & BGX_XCAST_MCAST_FILTER) {
+ if (mode & BGX_XCAST_MCAST_FILTER) {
/* once enabling filtering, we need to signal to PF to add
* its' own LMAC to the filter to accept packets for it.
*/
@@ -1954,23 +1949,46 @@ static void nicvf_set_rx_mode_task(struct work_struct *work_arg)
}
/* check if we have any specific MACs to be added to PF DMAC filter */
- if (vf_work->mc) {
+ if (mc_addrs) {
/* now go through kernel list of MACs and add them one by one */
- for (idx = 0; idx < vf_work->mc->count; idx++) {
+ for (idx = 0; idx < mc_addrs->count; idx++) {
mbx.xcast.msg = NIC_MBOX_MSG_ADD_MCAST;
- mbx.xcast.data.mac = vf_work->mc->mc[idx];
+ mbx.xcast.data.mac = mc_addrs->mc[idx];
nicvf_send_msg_to_pf(nic, &mbx);
}
- kfree(vf_work->mc);
+ kfree(mc_addrs);
}
/* and finally set rx mode for PF accordingly */
mbx.xcast.msg = NIC_MBOX_MSG_SET_XCAST;
- mbx.xcast.data.mode = vf_work->mode;
+ mbx.xcast.data.mode = mode;
nicvf_send_msg_to_pf(nic, &mbx);
}
+static void nicvf_set_rx_mode_task(struct work_struct *work_arg)
+{
+ struct nicvf_work *vf_work = container_of(work_arg, struct nicvf_work,
+ work.work);
+ struct nicvf *nic = container_of(vf_work, struct nicvf, rx_mode_work);
+ u8 mode;
+ struct xcast_addr_list *mc;
+
+ if (!vf_work)
+ return;
+
+ /* Save message data locally to prevent them from
+ * being overwritten by next ndo_set_rx_mode call().
+ */
+ spin_lock(&nic->rx_mode_wq_lock);
+ mode = vf_work->mode;
+ mc = vf_work->mc;
+ vf_work->mc = NULL;
+ spin_unlock(&nic->rx_mode_wq_lock);
+
+ __nicvf_set_rx_mode_task(mode, mc, nic);
+}
+
static void nicvf_set_rx_mode(struct net_device *netdev)
{
struct nicvf *nic = netdev_priv(netdev);
@@ -2004,9 +2022,12 @@ static void nicvf_set_rx_mode(struct net_device *netdev)
}
}
}
+ spin_lock(&nic->rx_mode_wq_lock);
+ kfree(nic->rx_mode_work.mc);
nic->rx_mode_work.mc = mc_list;
nic->rx_mode_work.mode = mode;
- queue_delayed_work(nicvf_rx_mode_wq, &nic->rx_mode_work.work, 2 * HZ);
+ queue_delayed_work(nicvf_rx_mode_wq, &nic->rx_mode_work.work, 0);
+ spin_unlock(&nic->rx_mode_wq_lock);
}
static const struct net_device_ops nicvf_netdev_ops = {
@@ -2163,6 +2184,7 @@ static int nicvf_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
INIT_WORK(&nic->reset_task, nicvf_reset_task);
INIT_DELAYED_WORK(&nic->rx_mode_work.work, nicvf_set_rx_mode_task);
+ spin_lock_init(&nic->rx_mode_wq_lock);
err = register_netdev(netdev);
if (err) {
--
2.14.4
^ permalink raw reply related
* Re: [PATCH v4 9/9] net-next: New ax88796 platform driver for Amiga X-Surf 100 Zorro board (m68k)
From: Michael Karcher @ 2018-06-08 9:28 UTC (permalink / raw)
To: Michael Schmitz
Cc: Geert Uytterhoeven, netdev, Andrew Lunn, Finn Thain,
Florian Fainelli, Linux/m68k, Michael Karcher, Michael Karcher
In-Reply-To: <643cf1a7-b91c-bda6-d5b0-52b7f84377e6@gmail.com>
Let me add my 2 cents as main author of that code:
Michael Schmitz wrote:
> Am 08.06.2018 um 02:36 schrieb Geert Uytterhoeven:
>> So I was wondering: why is this file included, as XSURF100 selects
>> AX88796,
>> while ax88796.c includes lib8390.c anyway?
>>
>> Apparently lib8390.c is included for register definitions (provided by
>> 8390.h, and can easily be fixed), and for the __NS8390_init()
>> implementation, called below.
>
> Mostly the latter.
>
>>
>>> +static void xs100_block_output(struct net_device *dev, int count,
>>> + const unsigned char *buf, const int
>>> start_page)
>>> +{
>>
>> [...]
>>
>>> + while ((ei_inb(nic_base + EN0_ISR) & ENISR_RDC) == 0) {
>>> + if (jiffies - dma_start > 2 * HZ / 100) { /* 20ms
>>> */
>>> + netdev_warn(dev, "timeout waiting for Tx
>>> RDC.\n");
>>> + ei_local->reset_8390(dev);
>>> + ax_NS8390_init(dev, 1);
>>> + break;
>>> + }
>>> + }
>>> +
>>> + ei_outb(ENISR_RDC, nic_base + EN0_ISR); /* Ack intr. */
>>> + ei_local->dmaing &= ~0x01;
>>> +}
actually, the the block_input / block_output functions were the reason I
included the lib8390.c file. Except for xs100_write / xs100_read, they are
a verbatim copy from ax88796.c I'm not that enthusiastic about that idea
anymore, but did not get around to improve it. I added a customization
point to ax88796 for a custom block_input / block_output, because the 8390
core already provides that customization point. What I really need is a
customization point just for the 8390-remote-DMA-via-MMIO functions (i.e.
xs100_write, xs100_read) instead of the whole block transfer core that
also sets up the remote DMA engine and tries to re-initialize the card in
case of unexplained problems.
This should get rid of
- xs100_block_output
- xs100_block_input (which has the calls to ax_reset_8390 and
ax_NS8390_init)
- ax_reset_8390
- and thus the include of lib8390.c (which should be included only by
ax88796.c, not by xsurf100.c)
Regards,
Michael Karcher
^ permalink raw reply
* Re: [PATCH] [net-next, wrong] make BPFILTER_UMH depend on X86
From: Daniel Borkmann @ 2018-06-08 9:33 UTC (permalink / raw)
To: Geert Uytterhoeven, Arnd Bergmann, Alexei Starovoitov
Cc: David S. Miller, Masahiro Yamada, linux-kbuild, netdev,
Linux Kernel Mailing List
In-Reply-To: <CAMuHMdXy0uHXaGkFBh9_tr2VzmJF+8KtraTuFHJwcmqhcHs4Dg@mail.gmail.com>
Hi Geert,
On 06/08/2018 10:57 AM, Geert Uytterhoeven wrote:
> On Mon, May 28, 2018 at 5:31 PM, Arnd Bergmann <arnd@arndb.de> wrote:
>> When build testing across architectures, I run into a build error on
>> all targets other than X86:
>>
>> gcc-8.1.0-nolibc/arm-linux-gnueabi/bin/arm-linux-gnueabi-objdump: net/bpfilter/bpfilter_umh: File format not recognized
>> gcc-8.1.0-nolibc/arm-linux-gnueabi/bin/arm-linux-gnueabi-objcopy:net/bpfilter/bpfilter_umh.o: Invalid bfd target
>>
>> The problem is that 'hostprogs' get built with 'gcc' rather than
>> '$(CROSS_COMPILE)gcc', and my default gcc (as most people's) targets x86.
>>
>> To work around it, adding an X86 dependency gets randconfigs building
>> again on my box.
>>
>> Clearly, this is not a good solution, since it should actually work fine
>> when building native kernels on other architectures but that is now
>> disabled, while cross building an x86 kernel on another host is still
>> broken after my patch.
>>
>> What we probably want here is to try out if the compiler is able to build
>> executables for the target architecture and not build the helper otherwise,
>> at least when compile-testing. No idea how to do that though.
>
> So that was done in commit 819dd92b9c0bc7bc ("bpfilter: switch to CC
> from HOSTCC"), but it is not sufficient:
>
> GEN net/bpfilter/bpfilter_umh.o
> Usage: m68k-linux-gnu-objcopy [option(s)] in-file [out-file]
> Copies a binary file, possibly transforming it in the process
> The options are:
> [...]
>
> net/bpfilter/Makefile:29: recipe for target 'net/bpfilter/bpfilter_umh.o' failed
> make[5]: *** [net/bpfilter/bpfilter_umh.o] Error 1
>
>> --- a/net/bpfilter/Kconfig
>> +++ b/net/bpfilter/Kconfig
>> @@ -9,6 +9,7 @@ menuconfig BPFILTER
>> if BPFILTER
>> config BPFILTER_UMH
>> tristate "bpfilter kernel module with user mode helper"
>> + depends on X86 # actually depends on native builds
>
> No, (currently) it does depend on X86, due to its use of:
>
> $(OBJCOPY) -I binary -O $(CONFIG_OUTPUT_FORMAT)
>
> with CONFIG_OUTPUT_FORMAT being defined on X86 only...
That hard dependency should have been fixed with the following patch in -net tree:
https://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git/commit/?id=8d97ca6b6755bf7ef57d323642ca9ee80d689782
Thanks,
Daniel
^ permalink raw reply
* [PATCH net] udp: fix rx queue len reported by diag and proc interface
From: Paolo Abeni @ 2018-06-08 9:35 UTC (permalink / raw)
To: netdev; +Cc: David S. Miller, Eric Dumazet, trevor.francis
After commit 6b229cf77d68 ("udp: add batching to udp_rmem_release()")
the sk_rmem_alloc field does not measure exactly anymore the
receive queue length, because we batch the rmem release. The issue
is really apparent only after commit 0d4a6608f68c ("udp: do rmem bulk
free even if the rx sk queue is empty"): the user space can easily
check for an empty socket with not-0 queue length reported by the 'ss'
tool or the procfs interface.
We need to use a custom UDP helper to report the correct queue length,
taking into account the forward allocation deficit.
Reported-by: trevor.francis@46labs.com
Fixes: 6b229cf77d68 ("UDP: add batching to udp_rmem_release()")
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
---
include/net/transp_v6.h | 11 +++++++++--
include/net/udp.h | 5 +++++
net/ipv4/udp.c | 2 +-
net/ipv4/udp_diag.c | 2 +-
net/ipv6/datagram.c | 6 +++---
net/ipv6/udp.c | 3 ++-
6 files changed, 21 insertions(+), 8 deletions(-)
diff --git a/include/net/transp_v6.h b/include/net/transp_v6.h
index c4f5caaf3778..f6a3543e5247 100644
--- a/include/net/transp_v6.h
+++ b/include/net/transp_v6.h
@@ -45,8 +45,15 @@ int ip6_datagram_send_ctl(struct net *net, struct sock *sk, struct msghdr *msg,
struct flowi6 *fl6, struct ipcm6_cookie *ipc6,
struct sockcm_cookie *sockc);
-void ip6_dgram_sock_seq_show(struct seq_file *seq, struct sock *sp,
- __u16 srcp, __u16 destp, int bucket);
+void __ip6_dgram_sock_seq_show(struct seq_file *seq, struct sock *sp,
+ __u16 srcp, __u16 destp, int rqueue, int bucket);
+static inline void
+ip6_dgram_sock_seq_show(struct seq_file *seq, struct sock *sp, __u16 srcp,
+ __u16 destp, int bucket)
+{
+ __ip6_dgram_sock_seq_show(seq, sp, srcp, destp, sk_rmem_alloc_get(sp),
+ bucket);
+}
#define LOOPBACK4_IPV6 cpu_to_be32(0x7f000006)
diff --git a/include/net/udp.h b/include/net/udp.h
index 7ba0ed252c52..b1ea8b0f5e6a 100644
--- a/include/net/udp.h
+++ b/include/net/udp.h
@@ -247,6 +247,11 @@ static inline __be16 udp_flow_src_port(struct net *net, struct sk_buff *skb,
return htons((((u64) hash * (max - min)) >> 32) + min);
}
+static inline int udp_rqueue_get(struct sock *sk)
+{
+ return sk_rmem_alloc_get(sk) - READ_ONCE(udp_sk(sk)->forward_deficit);
+}
+
/* net/ipv4/udp.c */
void udp_destruct_sock(struct sock *sk);
void skb_consume_udp(struct sock *sk, struct sk_buff *skb, int len);
diff --git a/net/ipv4/udp.c b/net/ipv4/udp.c
index 3365362cac88..9bb27df4dac5 100644
--- a/net/ipv4/udp.c
+++ b/net/ipv4/udp.c
@@ -2772,7 +2772,7 @@ static void udp4_format_sock(struct sock *sp, struct seq_file *f,
" %02X %08X:%08X %02X:%08lX %08X %5u %8d %lu %d %pK %d",
bucket, src, srcp, dest, destp, sp->sk_state,
sk_wmem_alloc_get(sp),
- sk_rmem_alloc_get(sp),
+ udp_rqueue_get(sp),
0, 0L, 0,
from_kuid_munged(seq_user_ns(f), sock_i_uid(sp)),
0, sock_i_ino(sp),
diff --git a/net/ipv4/udp_diag.c b/net/ipv4/udp_diag.c
index d0390d844ac8..d9ad986c7b2c 100644
--- a/net/ipv4/udp_diag.c
+++ b/net/ipv4/udp_diag.c
@@ -163,7 +163,7 @@ static int udp_diag_dump_one(struct sk_buff *in_skb, const struct nlmsghdr *nlh,
static void udp_diag_get_info(struct sock *sk, struct inet_diag_msg *r,
void *info)
{
- r->idiag_rqueue = sk_rmem_alloc_get(sk);
+ r->idiag_rqueue = udp_rqueue_get(sk);
r->idiag_wqueue = sk_wmem_alloc_get(sk);
}
diff --git a/net/ipv6/datagram.c b/net/ipv6/datagram.c
index a02ad100f0d7..2ee08b6a86a4 100644
--- a/net/ipv6/datagram.c
+++ b/net/ipv6/datagram.c
@@ -1019,8 +1019,8 @@ int ip6_datagram_send_ctl(struct net *net, struct sock *sk,
}
EXPORT_SYMBOL_GPL(ip6_datagram_send_ctl);
-void ip6_dgram_sock_seq_show(struct seq_file *seq, struct sock *sp,
- __u16 srcp, __u16 destp, int bucket)
+void __ip6_dgram_sock_seq_show(struct seq_file *seq, struct sock *sp,
+ __u16 srcp, __u16 destp, int rqueue, int bucket)
{
const struct in6_addr *dest, *src;
@@ -1036,7 +1036,7 @@ void ip6_dgram_sock_seq_show(struct seq_file *seq, struct sock *sp,
dest->s6_addr32[2], dest->s6_addr32[3], destp,
sp->sk_state,
sk_wmem_alloc_get(sp),
- sk_rmem_alloc_get(sp),
+ rqueue,
0, 0L, 0,
from_kuid_munged(seq_user_ns(seq), sock_i_uid(sp)),
0,
diff --git a/net/ipv6/udp.c b/net/ipv6/udp.c
index 164afd31aebf..e6645cae403e 100644
--- a/net/ipv6/udp.c
+++ b/net/ipv6/udp.c
@@ -1523,7 +1523,8 @@ int udp6_seq_show(struct seq_file *seq, void *v)
struct inet_sock *inet = inet_sk(v);
__u16 srcp = ntohs(inet->inet_sport);
__u16 destp = ntohs(inet->inet_dport);
- ip6_dgram_sock_seq_show(seq, v, srcp, destp, bucket);
+ __ip6_dgram_sock_seq_show(seq, v, srcp, destp,
+ udp_rqueue_get(v), bucket);
}
return 0;
}
--
2.17.1
^ permalink raw reply related
* Re: [PATCH] [net-next, wrong] make BPFILTER_UMH depend on X86
From: Geert Uytterhoeven @ 2018-06-08 9:40 UTC (permalink / raw)
To: Daniel Borkmann
Cc: Arnd Bergmann, Alexei Starovoitov, David S. Miller,
Masahiro Yamada, linux-kbuild, netdev, Linux Kernel Mailing List
In-Reply-To: <8c0f8cc4-b919-9b69-4144-fd216253aa24@iogearbox.net>
Hi Daniel,
On Fri, Jun 8, 2018 at 11:33 AM, Daniel Borkmann <daniel@iogearbox.net> wrote:
> On 06/08/2018 10:57 AM, Geert Uytterhoeven wrote:
>> On Mon, May 28, 2018 at 5:31 PM, Arnd Bergmann <arnd@arndb.de> wrote:
>>> When build testing across architectures, I run into a build error on
>>> all targets other than X86:
>>>
>>> gcc-8.1.0-nolibc/arm-linux-gnueabi/bin/arm-linux-gnueabi-objdump: net/bpfilter/bpfilter_umh: File format not recognized
>>> gcc-8.1.0-nolibc/arm-linux-gnueabi/bin/arm-linux-gnueabi-objcopy:net/bpfilter/bpfilter_umh.o: Invalid bfd target
>>>
>>> The problem is that 'hostprogs' get built with 'gcc' rather than
>>> '$(CROSS_COMPILE)gcc', and my default gcc (as most people's) targets x86.
>>>
>>> To work around it, adding an X86 dependency gets randconfigs building
>>> again on my box.
>>>
>>> Clearly, this is not a good solution, since it should actually work fine
>>> when building native kernels on other architectures but that is now
>>> disabled, while cross building an x86 kernel on another host is still
>>> broken after my patch.
>>>
>>> What we probably want here is to try out if the compiler is able to build
>>> executables for the target architecture and not build the helper otherwise,
>>> at least when compile-testing. No idea how to do that though.
>>
>> So that was done in commit 819dd92b9c0bc7bc ("bpfilter: switch to CC
>> from HOSTCC"), but it is not sufficient:
>>
>> GEN net/bpfilter/bpfilter_umh.o
>> Usage: m68k-linux-gnu-objcopy [option(s)] in-file [out-file]
>> Copies a binary file, possibly transforming it in the process
>> The options are:
>> [...]
>>
>> net/bpfilter/Makefile:29: recipe for target 'net/bpfilter/bpfilter_umh.o' failed
>> make[5]: *** [net/bpfilter/bpfilter_umh.o] Error 1
>>
>>> --- a/net/bpfilter/Kconfig
>>> +++ b/net/bpfilter/Kconfig
>>> @@ -9,6 +9,7 @@ menuconfig BPFILTER
>>> if BPFILTER
>>> config BPFILTER_UMH
>>> tristate "bpfilter kernel module with user mode helper"
>>> + depends on X86 # actually depends on native builds
>>
>> No, (currently) it does depend on X86, due to its use of:
>>
>> $(OBJCOPY) -I binary -O $(CONFIG_OUTPUT_FORMAT)
>>
>> with CONFIG_OUTPUT_FORMAT being defined on X86 only...
>
> That hard dependency should have been fixed with the following patch in -net tree:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git/commit/?id=8d97ca6b6755bf7ef57d323642ca9ee80d689782
Thanks, confirmed.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH ethtool 5/6] ethtool: correctly free hkey when get_stringset() fails
From: Gal Pressman @ 2018-06-08 9:46 UTC (permalink / raw)
To: Ivan Vecera, linville; +Cc: netdev, Gal Pressman
In-Reply-To: <20180608092010.13041-5-cera@cera.cz>
On 08-Jun-18 12:20, Ivan Vecera wrote:
> Memory allocated for 'hkey' is not freed when
> get_stringset(..., ETH_SS_RSS_HASH_FUNCS...) fails.
>
> Fixes: b888f35 ("ethtool: Support for configurable RSS hash function")
Thanks for fixing this!
Please use the first 12 characters of the sha1 in the Fixes line.
> Cc: Gal Pressman <galp@mellanox.com>
> Signed-off-by: Ivan Vecera <cera@cera.cz>
> ---
> ethtool.c | 13 ++++++-------
> 1 file changed, 6 insertions(+), 7 deletions(-)
>
> diff --git a/ethtool.c b/ethtool.c
> index 2b90984..fb93ae8 100644
> --- a/ethtool.c
> +++ b/ethtool.c
> @@ -3910,7 +3910,7 @@ static int do_srxfhindir(struct cmd_context *ctx, int rxfhindir_default,
> static int do_srxfh(struct cmd_context *ctx)
> {
> struct ethtool_rxfh rss_head = {0};
> - struct ethtool_rxfh *rss;
> + struct ethtool_rxfh *rss = NULL;
> struct ethtool_rxnfc ring_count;
> int rxfhindir_equal = 0, rxfhindir_default = 0;
> struct ethtool_gstrings *hfuncs = NULL;
> @@ -4064,7 +4064,8 @@ static int do_srxfh(struct cmd_context *ctx)
> hfuncs = get_stringset(ctx, ETH_SS_RSS_HASH_FUNCS, 0, 1);
> if (!hfuncs) {
> perror("Cannot get hash functions names");
> - return 1;
> + err = 1;
> + goto free;
> }
>
> for (i = 0; i < hfuncs->len && !req_hfunc ; i++) {
> @@ -4078,8 +4079,8 @@ static int do_srxfh(struct cmd_context *ctx)
> if (!req_hfunc) {
> fprintf(stderr,
> "Unknown hash function: %s\n", req_hfunc_name);
> - free(hfuncs);
> - return 1;
> + err = 1;
> + goto free;
> }
> }
>
> @@ -4120,9 +4121,7 @@ static int do_srxfh(struct cmd_context *ctx)
> }
>
> free:
> - if (hkey)
> - free(hkey);
> -
> + free(hkey);
> free(rss);
> free(hfuncs);
> return err;
>
^ permalink raw reply
* Re: KASAN: null-ptr-deref Write in xdp_umem_unaccount_pages
From: Daniel Borkmann @ 2018-06-08 9:50 UTC (permalink / raw)
To: syzbot, bjorn.topel, davem, linux-kernel, magnus.karlsson, netdev,
syzkaller-bugs
In-Reply-To: <00000000000037bf29056e114a86@google.com>
On 06/07/2018 08:17 PM, syzbot wrote:
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit: 1c8c5a9d38f6 Merge git://git.kernel.org/pub/scm/linux/kern..
> git tree: upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=13a72bdf800000
> kernel config: https://syzkaller.appspot.com/x/.config?x=4f1acdf888c9d4e9
> dashboard link: https://syzkaller.appspot.com/bug?extid=979217770b09ebf5c407
> compiler: gcc (GCC) 8.0.1 20180413 (experimental)
> syzkaller repro:https://syzkaller.appspot.com/x/repro.syz?x=12aca2af800000
> C reproducer: https://syzkaller.appspot.com/x/repro.c?x=161d4ddf800000
>
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+979217770b09ebf5c407@syzkaller.appspotmail.com
#syz fix: bpf, xdp: fix crash in xdp_umem_unaccount_pages
^ permalink raw reply
* Re: [PATCH bpf-next v6 1/2] trace_helpers.c: Add helpers to poll multiple perf FDs for events
From: Toke Høiland-Jørgensen @ 2018-06-08 9:52 UTC (permalink / raw)
To: Daniel Borkmann, netdev; +Cc: Jakub Kicinski, Jesper Dangaard Brouer
In-Reply-To: <6eea45bd-6231-9cba-692a-2aefab636c7d@iogearbox.net>
Daniel Borkmann <daniel@iogearbox.net> writes:
> Hi Toke,
>
> On 06/06/2018 07:58 PM, Toke Høiland-Jørgensen wrote:
>> Add two new helper functions to trace_helpers that supports polling
>> multiple perf file descriptors for events. These are used to the XDP
>> perf_event_output example, which needs to work with one perf fd per CPU.
>>
>> Reviewed-by: Jakub Kicinski <jakub.kicinski@netronome.com>
>> Signed-off-by: Toke Høiland-Jørgensen <toke@toke.dk>
>
> Didn't make it in time unfortunately as bpf-next closed, please resend
> these two once merge window is over and bpf-next open again.
Will do!
-Toke
^ permalink raw reply
* Re: KASAN: use-after-free Read in bpf_csum_update
From: Daniel Borkmann @ 2018-06-08 9:52 UTC (permalink / raw)
To: syzbot, ast, davem, linux-kernel, netdev, syzkaller-bugs
In-Reply-To: <000000000000bec587056dc547ba@google.com>
On 06/04/2018 01:36 AM, syzbot wrote:
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit: bcece5dc40b9 bpf: Change bpf_fib_lookup to return -EAFNOSU..
> git tree: bpf-next
> console output: https://syzkaller.appspot.com/x/log.txt?x=161e2c6f800000
> kernel config: https://syzkaller.appspot.com/x/.config?x=e4078980b886800c
> dashboard link: https://syzkaller.appspot.com/bug?extid=3d0b2441dbb71751615e
> compiler: gcc (GCC) 8.0.1 20180413 (experimental)
> syzkaller repro:https://syzkaller.appspot.com/x/repro.syz?x=17cb5adf800000
> C reproducer: https://syzkaller.appspot.com/x/repro.c?x=17ebf19f800000
#syz fix: bpf: reject passing modified ctx to helper functions
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox