* Re: [PATCH bpf-next] tools: libbpf: update extended attributes version of bpf_object__open()
From: Song Liu @ 2019-08-30 19:24 UTC (permalink / raw)
To: Anton Protopopov
Cc: Andrii Nakryiko, Alexei Starovoitov, Daniel Borkmann, Martin Lau,
Yonghong Song, Networking, bpf, linux-kernel@vger.kernel.org
In-Reply-To: <CAGn_itwS=bLf8NGVNbByNx8FmR_JtPWnuEnKO23ig8xnK_GYOw@mail.gmail.com>
> On Aug 30, 2019, at 11:53 AM, Anton Protopopov <a.s.protopopov@gmail.com> wrote:
>
> чт, 29 авг. 2019 г. в 16:02, Song Liu <songliubraving@fb.com>:
>>
>>
>>
>>> On Aug 14, 2019, at 5:03 PM, Anton Protopopov <a.s.protopopov@gmail.com> wrote:
>>>
>>
>> [...]
>>
>>>
>>>
>>> int bpf_object__unload(struct bpf_object *obj)
>>> diff --git a/tools/lib/bpf/libbpf.h b/tools/lib/bpf/libbpf.h
>>> index e8f70977d137..634f278578dd 100644
>>> --- a/tools/lib/bpf/libbpf.h
>>> +++ b/tools/lib/bpf/libbpf.h
>>> @@ -63,8 +63,13 @@ LIBBPF_API libbpf_print_fn_t libbpf_set_print(libbpf_print_fn_t fn);
>>> struct bpf_object;
>>>
>>> struct bpf_object_open_attr {
>>> - const char *file;
>>> + union {
>>> + const char *file;
>>> + const char *obj_name;
>>> + };
>>> enum bpf_prog_type prog_type;
>>> + void *obj_buf;
>>> + size_t obj_buf_sz;
>>> };
>>
>> I think this would break dynamically linked libbpf. No?
>
> Ah, yes, sure. What is the right way to make changes which break ABI in libbpf?
I don't have a good idea here on the top of my head.
Maybe we need a new struct and/or function for this.
>
> BTW, does the commit ddc7c3042614 ("libbpf: implement BPF CO-RE offset
> relocation algorithm") which adds a new field to the struct
> bpf_object_load_attr also break ABI?
I think this change was in the same release, so it is OK.
Thanks,
Song
^ permalink raw reply
* memory leak in hci_inquiry_cache_update
From: syzbot @ 2019-08-30 19:28 UTC (permalink / raw)
To: davem, johan.hedberg, linux-bluetooth, linux-kernel, marcel,
netdev, syzkaller-bugs
Hello,
syzbot found the following crash on:
HEAD commit: 6525771f Merge tag 'arc-5.3-rc7' of git://git.kernel.org/p..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=11ce405c600000
kernel config: https://syzkaller.appspot.com/x/.config?x=e6131eafb9408877
dashboard link: https://syzkaller.appspot.com/bug?extid=82e5dfb66f1a36c0ffbb
compiler: gcc (GCC) 9.0.0 20181231 (experimental)
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=16ef5ade600000
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+82e5dfb66f1a36c0ffbb@syzkaller.appspotmail.com
2019/08/30 10:10:13 executed programs: 1
2019/08/30 10:10:24 executed programs: 2
2019/08/30 10:10:39 executed programs: 3
2019/08/30 10:10:49 executed programs: 4
BUG: memory leak
unreferenced object 0xffff8881227b8ac0 (size 64):
comm "kworker/u5:0", pid 1543, jiffies 4294990660 (age 28.050s)
hex dump (first 32 bytes):
70 2a b0 2a 81 88 ff ff c0 7e c6 1a 81 88 ff ff p*.*.....~......
80 2a b0 2a 81 88 ff ff d0 7e c6 1a 81 88 ff ff .*.*.....~......
backtrace:
[<0000000003c40121>] kmemleak_alloc_recursive
include/linux/kmemleak.h:43 [inline]
[<0000000003c40121>] slab_post_alloc_hook mm/slab.h:522 [inline]
[<0000000003c40121>] slab_alloc mm/slab.c:3319 [inline]
[<0000000003c40121>] kmem_cache_alloc_trace+0x145/0x2c0 mm/slab.c:3548
[<00000000bdd76485>] kmalloc include/linux/slab.h:552 [inline]
[<00000000bdd76485>] kzalloc include/linux/slab.h:748 [inline]
[<00000000bdd76485>] hci_inquiry_cache_update+0x138/0x2b0
net/bluetooth/hci_core.c:1183
[<000000000fa97823>] hci_inquiry_result_with_rssi_evt
net/bluetooth/hci_event.c:4079 [inline]
[<000000000fa97823>] hci_event_packet+0x1224/0x3453
net/bluetooth/hci_event.c:5952
[<0000000021923028>] hci_rx_work+0x1b6/0x2f0
net/bluetooth/hci_core.c:4462
[<00000000eb63bebf>] process_one_work+0x210/0x490
kernel/workqueue.c:2269
[<00000000873e1703>] worker_thread+0x56/0x4c0 kernel/workqueue.c:2415
[<00000000a3c26b57>] kthread+0x13e/0x160 kernel/kthread.c:255
[<00000000c66acc55>] ret_from_fork+0x1f/0x30
arch/x86/entry/entry_64.S:352
BUG: memory leak
unreferenced object 0xffff88811ac67ec0 (size 64):
comm "kworker/u5:0", pid 1543, jiffies 4294990660 (age 28.050s)
hex dump (first 32 bytes):
c0 8a 7b 22 81 88 ff ff 80 7e c6 1a 81 88 ff ff ..{".....~......
d0 8a 7b 22 81 88 ff ff 90 7e c6 1a 81 88 ff ff ..{".....~......
backtrace:
[<0000000003c40121>] kmemleak_alloc_recursive
include/linux/kmemleak.h:43 [inline]
[<0000000003c40121>] slab_post_alloc_hook mm/slab.h:522 [inline]
[<0000000003c40121>] slab_alloc mm/slab.c:3319 [inline]
[<0000000003c40121>] kmem_cache_alloc_trace+0x145/0x2c0 mm/slab.c:3548
[<00000000bdd76485>] kmalloc include/linux/slab.h:552 [inline]
[<00000000bdd76485>] kzalloc include/linux/slab.h:748 [inline]
[<00000000bdd76485>] hci_inquiry_cache_update+0x138/0x2b0
net/bluetooth/hci_core.c:1183
[<000000000fa97823>] hci_inquiry_result_with_rssi_evt
net/bluetooth/hci_event.c:4079 [inline]
[<000000000fa97823>] hci_event_packet+0x1224/0x3453
net/bluetooth/hci_event.c:5952
[<0000000021923028>] hci_rx_work+0x1b6/0x2f0
net/bluetooth/hci_core.c:4462
[<00000000eb63bebf>] process_one_work+0x210/0x490
kernel/workqueue.c:2269
[<00000000873e1703>] worker_thread+0x56/0x4c0 kernel/workqueue.c:2415
[<00000000a3c26b57>] kthread+0x13e/0x160 kernel/kthread.c:255
[<00000000c66acc55>] ret_from_fork+0x1f/0x30
arch/x86/entry/entry_64.S:352
BUG: memory leak
unreferenced object 0xffff88811ac67e80 (size 64):
comm "kworker/u5:0", pid 1543, jiffies 4294990660 (age 28.050s)
hex dump (first 32 bytes):
c0 7e c6 1a 81 88 ff ff 40 7e c6 1a 81 88 ff ff .~......@~......
d0 7e c6 1a 81 88 ff ff 50 7e c6 1a 81 88 ff ff .~......P~......
backtrace:
[<0000000003c40121>] kmemleak_alloc_recursive
include/linux/kmemleak.h:43 [inline]
[<0000000003c40121>] slab_post_alloc_hook mm/slab.h:522 [inline]
[<0000000003c40121>] slab_alloc mm/slab.c:3319 [inline]
[<0000000003c40121>] kmem_cache_alloc_trace+0x145/0x2c0 mm/slab.c:3548
[<00000000bdd76485>] kmalloc include/linux/slab.h:552 [inline]
[<00000000bdd76485>] kzalloc include/linux/slab.h:748 [inline]
[<00000000bdd76485>] hci_inquiry_cache_update+0x138/0x2b0
net/bluetooth/hci_core.c:1183
[<000000000fa97823>] hci_inquiry_result_with_rssi_evt
net/bluetooth/hci_event.c:4079 [inline]
[<000000000fa97823>] hci_event_packet+0x1224/0x3453
net/bluetooth/hci_event.c:5952
[<0000000021923028>] hci_rx_work+0x1b6/0x2f0
net/bluetooth/hci_core.c:4462
[<00000000eb63bebf>] process_one_work+0x210/0x490
kernel/workqueue.c:2269
[<00000000873e1703>] worker_thread+0x56/0x4c0 kernel/workqueue.c:2415
[<00000000a3c26b57>] kthread+0x13e/0x160 kernel/kthread.c:255
[<00000000c66acc55>] ret_from_fork+0x1f/0x30
arch/x86/entry/entry_64.S:352
BUG: memory leak
unreferenced object 0xffff88811ac67e40 (size 64):
comm "kworker/u5:0", pid 1543, jiffies 4294990660 (age 28.050s)
hex dump (first 32 bytes):
80 7e c6 1a 81 88 ff ff 00 7e c6 1a 81 88 ff ff .~.......~......
90 7e c6 1a 81 88 ff ff 10 7e c6 1a 81 88 ff ff .~.......~......
backtrace:
[<0000000003c40121>] kmemleak_alloc_recursive
include/linux/kmemleak.h:43 [inline]
[<0000000003c40121>] slab_post_alloc_hook mm/slab.h:522 [inline]
[<0000000003c40121>] slab_alloc mm/slab.c:3319 [inline]
[<0000000003c40121>] kmem_cache_alloc_trace+0x145/0x2c0 mm/slab.c:3548
[<00000000bdd76485>] kmalloc include/linux/slab.h:552 [inline]
[<00000000bdd76485>] kzalloc include/linux/slab.h:748 [inline]
[<00000000bdd76485>] hci_inquiry_cache_update+0x138/0x2b0
net/bluetooth/hci_core.c:1183
[<000000000fa97823>] hci_inquiry_result_with_rssi_evt
net/bluetooth/hci_event.c:4079 [inline]
[<000000000fa97823>] hci_event_packet+0x1224/0x3453
net/bluetooth/hci_event.c:5952
[<0000000021923028>] hci_rx_work+0x1b6/0x2f0
net/bluetooth/hci_core.c:4462
[<00000000eb63bebf>] process_one_work+0x210/0x490
kernel/workqueue.c:2269
[<00000000873e1703>] worker_thread+0x56/0x4c0 kernel/workqueue.c:2415
[<00000000a3c26b57>] kthread+0x13e/0x160 kernel/kthread.c:255
[<00000000c66acc55>] ret_from_fork+0x1f/0x30
arch/x86/entry/entry_64.S:352
BUG: memory leak
unreferenced object 0xffff88811ac67e00 (size 64):
comm "kworker/u5:0", pid 1543, jiffies 4294990660 (age 28.050s)
hex dump (first 32 bytes):
40 7e c6 1a 81 88 ff ff c0 7d c6 1a 81 88 ff ff @~.......}......
50 7e c6 1a 81 88 ff ff d0 7d c6 1a 81 88 ff ff P~.......}......
backtrace:
[<0000000003c40121>] kmemleak_alloc_recursive
include/linux/kmemleak.h:43 [inline]
[<0000000003c40121>] slab_post_alloc_hook mm/slab.h:522 [inline]
[<0000000003c40121>] slab_alloc mm/slab.c:3319 [inline]
[<0000000003c40121>] kmem_cache_alloc_trace+0x145/0x2c0 mm/slab.c:3548
[<00000000bdd76485>] kmalloc include/linux/slab.h:552 [inline]
[<00000000bdd76485>] kzalloc include/linux/slab.h:748 [inline]
[<00000000bdd76485>] hci_inquiry_cache_update+0x138/0x2b0
net/bluetooth/hci_core.c:1183
[<000000000fa97823>] hci_inquiry_result_with_rssi_evt
net/bluetooth/hci_event.c:4079 [inline]
[<000000000fa97823>] hci_event_packet+0x1224/0x3453
net/bluetooth/hci_event.c:5952
[<0000000021923028>] hci_rx_work+0x1b6/0x2f0
net/bluetooth/hci_core.c:4462
[<00000000eb63bebf>] process_one_work+0x210/0x490
kernel/workqueue.c:2269
[<00000000873e1703>] worker_thread+0x56/0x4c0 kernel/workqueue.c:2415
[<00000000a3c26b57>] kthread+0x13e/0x160 kernel/kthread.c:255
[<00000000c66acc55>] ret_from_fork+0x1f/0x30
arch/x86/entry/entry_64.S:352
---
This bug is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.
syzbot will keep track of this bug report. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
syzbot can test patches for this bug, for details see:
https://goo.gl/tpsmEJ#testing-patches
^ permalink raw reply
* INFO: task hung in p9_fd_close
From: syzbot @ 2019-08-30 19:28 UTC (permalink / raw)
To: asmadeus, davem, ericvh, linux-kernel, lucho, netdev,
syzkaller-bugs, v9fs-developer
Hello,
syzbot found the following crash on:
HEAD commit: 6525771f Merge tag 'arc-5.3-rc7' of git://git.kernel.org/p..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=1118a71e600000
kernel config: https://syzkaller.appspot.com/x/.config?x=58485246ad14eafe
dashboard link: https://syzkaller.appspot.com/bug?extid=8b41a1365f1106fd0f33
compiler: clang version 9.0.0 (/home/glider/llvm/clang
80fee25776c2fb61e74c1ecb1a523375c2500b69)
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=1125ee12600000
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+8b41a1365f1106fd0f33@syzkaller.appspotmail.com
INFO: task syz-executor.1:13699 blocked for more than 143 seconds.
Not tainted 5.3.0-rc6+ #94
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
syz-executor.1 D28888 13699 9148 0x00004004
Call Trace:
context_switch kernel/sched/core.c:3254 [inline]
__schedule+0x877/0xc50 kernel/sched/core.c:3880
schedule+0x131/0x1e0 kernel/sched/core.c:3947
schedule_timeout+0x46/0x240 kernel/time/timer.c:1783
do_wait_for_common+0x2e7/0x4d0 kernel/sched/completion.c:83
__wait_for_common kernel/sched/completion.c:104 [inline]
wait_for_common kernel/sched/completion.c:115 [inline]
wait_for_completion+0x47/0x60 kernel/sched/completion.c:136
__flush_work+0xd4/0x150 kernel/workqueue.c:3040
__cancel_work_timer+0x420/0x570 kernel/workqueue.c:3127
cancel_work_sync+0x17/0x20 kernel/workqueue.c:3163
p9_conn_destroy net/9p/trans_fd.c:868 [inline]
p9_fd_close+0x297/0x3c0 net/9p/trans_fd.c:898
p9_client_create+0x974/0xee0 net/9p/client.c:1068
v9fs_session_init+0x192/0x18e0 fs/9p/v9fs.c:406
v9fs_mount+0x82/0x810 fs/9p/vfs_super.c:120
legacy_get_tree+0xf9/0x1a0 fs/fs_context.c:661
vfs_get_tree+0x8f/0x380 fs/super.c:1413
do_new_mount fs/namespace.c:2791 [inline]
do_mount+0x169d/0x2490 fs/namespace.c:3111
ksys_mount+0xcc/0x100 fs/namespace.c:3320
__do_sys_mount fs/namespace.c:3334 [inline]
__se_sys_mount fs/namespace.c:3331 [inline]
__x64_sys_mount+0xbf/0xd0 fs/namespace.c:3331
do_syscall_64+0xfe/0x140 arch/x86/entry/common.c:296
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x459879
Code: 8b 44 24 18 48 8b 4c 24 30 48 83 c1 08 48 89 0c 24 48 89 44 24 08 48
c7 44 24 10 10 00 00 00 e8 0d da fa ff 48 8b 44 24 18 48 <89> 44 24 40 48
8b 6c 24 20 48 83 c4 28 c3 e8 14 b9 ff ff eb 82 cc
RSP: 002b:00007f6b4dda7c78 EFLAGS: 00000246 ORIG_RAX: 00000000000000a5
RAX: ffffffffffffffda RBX: 0000000000000005 RCX: 0000000000459879
RDX: 0000000020000140 RSI: 0000000020000000 RDI: 0000000000000000
RBP: 000000000075c118 R08: 0000000020000480 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 00007f6b4dda86d4
R13: 00000000004c5e2f R14: 00000000004da930 R15: 00000000ffffffff
INFO: lockdep is turned off.
NMI backtrace for cpu 0
CPU: 0 PID: 1057 Comm: khungtaskd Not tainted 5.3.0-rc6+ #94
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x1d8/0x2f8 lib/dump_stack.c:113
nmi_cpu_backtrace+0xaf/0x1a0 lib/nmi_backtrace.c:101
nmi_trigger_cpumask_backtrace+0x174/0x290 lib/nmi_backtrace.c:62
arch_trigger_cpumask_backtrace+0x10/0x20 arch/x86/kernel/apic/hw_nmi.c:38
trigger_all_cpu_backtrace+0x17/0x20 include/linux/nmi.h:146
check_hung_uninterruptible_tasks kernel/hung_task.c:205 [inline]
watchdog+0xbb9/0xbd0 kernel/hung_task.c:289
kthread+0x332/0x350 kernel/kthread.c:255
ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:352
Sending NMI from CPU 0 to CPUs 1:
NMI backtrace for cpu 1 skipped: idling at native_safe_halt+0xe/0x10
arch/x86/include/asm/irqflags.h:60
---
This bug is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.
syzbot will keep track of this bug report. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
syzbot can test patches for this bug, for details see:
https://goo.gl/tpsmEJ#testing-patches
^ permalink raw reply
* memory leak in nr_rx_frame (2)
From: syzbot @ 2019-08-30 19:28 UTC (permalink / raw)
To: davem, linux-hams, linux-kernel, netdev, ralf, syzkaller-bugs
Hello,
syzbot found the following crash on:
HEAD commit: 6525771f Merge tag 'arc-5.3-rc7' of git://git.kernel.org/p..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=10200912600000
kernel config: https://syzkaller.appspot.com/x/.config?x=e6131eafb9408877
dashboard link: https://syzkaller.appspot.com/bug?extid=0145ea560de205bc09f0
compiler: gcc (GCC) 9.0.0 20181231 (experimental)
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=12b51f9c600000
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+0145ea560de205bc09f0@syzkaller.appspotmail.com
2019/08/29 23:31:49 executed programs: 8
2019/08/29 23:31:56 executed programs: 15
2019/08/29 23:32:02 executed programs: 24
BUG: memory leak
unreferenced object 0xffff888123355800 (size 2048):
comm "softirq", pid 0, jiffies 4295062008 (age 25.620s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
06 00 07 40 00 00 00 00 00 00 00 00 00 00 00 00 ...@............
backtrace:
[<00000000bbb1ff80>] kmemleak_alloc_recursive
include/linux/kmemleak.h:43 [inline]
[<00000000bbb1ff80>] slab_post_alloc_hook mm/slab.h:522 [inline]
[<00000000bbb1ff80>] slab_alloc mm/slab.c:3319 [inline]
[<00000000bbb1ff80>] __do_kmalloc mm/slab.c:3653 [inline]
[<00000000bbb1ff80>] __kmalloc+0x169/0x300 mm/slab.c:3664
[<000000003948180d>] kmalloc include/linux/slab.h:557 [inline]
[<000000003948180d>] sk_prot_alloc+0x112/0x170 net/core/sock.c:1603
[<00000000ad5c33ee>] sk_alloc+0x35/0x2f0 net/core/sock.c:1657
[<000000004e2b1f5c>] nr_make_new net/netrom/af_netrom.c:476 [inline]
[<000000004e2b1f5c>] nr_rx_frame+0x339/0x8ee net/netrom/af_netrom.c:959
[<00000000df4c3d82>] nr_loopback_timer+0x4e/0xd0
net/netrom/nr_loopback.c:59
[<00000000e886ef23>] call_timer_fn+0x45/0x1e0 kernel/time/timer.c:1322
[<00000000cc0c55bd>] expire_timers kernel/time/timer.c:1366 [inline]
[<00000000cc0c55bd>] __run_timers kernel/time/timer.c:1685 [inline]
[<00000000cc0c55bd>] __run_timers kernel/time/timer.c:1653 [inline]
[<00000000cc0c55bd>] run_timer_softirq+0x256/0x740
kernel/time/timer.c:1698
[<000000008a8ac853>] __do_softirq+0x115/0x33f kernel/softirq.c:292
[<00000000c33f7c40>] invoke_softirq kernel/softirq.c:373 [inline]
[<00000000c33f7c40>] irq_exit+0xbb/0xe0 kernel/softirq.c:413
[<00000000dc851865>] exiting_irq arch/x86/include/asm/apic.h:537
[inline]
[<00000000dc851865>] smp_apic_timer_interrupt+0x96/0x190
arch/x86/kernel/apic/apic.c:1133
[<000000006a57c22f>] apic_timer_interrupt+0xf/0x20
arch/x86/entry/entry_64.S:830
[<00000000ec52384e>] arch_local_irq_restore
arch/x86/include/asm/paravirt.h:768 [inline]
[<00000000ec52384e>] console_unlock.part.0+0x5f0/0x6d0
kernel/printk/printk.c:2471
[<0000000013f07031>] console_unlock kernel/printk/printk.c:2364 [inline]
[<0000000013f07031>] vprintk_emit+0x251/0x360
kernel/printk/printk.c:1986
[<00000000704abaae>] vprintk_default+0x28/0x30
kernel/printk/printk.c:2013
[<000000008aa8a0ba>] vprintk_func+0x59/0xfa
kernel/printk/printk_safe.c:386
[<000000004d884645>] printk+0x60/0x7d kernel/printk/printk.c:2046
BUG: memory leak
unreferenced object 0xffff88810e8bd820 (size 32):
comm "softirq", pid 0, jiffies 4295062008 (age 25.620s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
03 00 00 00 03 00 00 00 0f 00 00 00 00 00 00 00 ................
backtrace:
[<0000000092f05cd5>] kmemleak_alloc_recursive
include/linux/kmemleak.h:43 [inline]
[<0000000092f05cd5>] slab_post_alloc_hook mm/slab.h:522 [inline]
[<0000000092f05cd5>] slab_alloc mm/slab.c:3319 [inline]
[<0000000092f05cd5>] kmem_cache_alloc_trace+0x145/0x2c0 mm/slab.c:3548
[<00000000f2b13853>] kmalloc include/linux/slab.h:552 [inline]
[<00000000f2b13853>] kzalloc include/linux/slab.h:748 [inline]
[<00000000f2b13853>] selinux_sk_alloc_security+0x48/0xb0
security/selinux/hooks.c:5073
[<000000002301f7f8>] security_sk_alloc+0x49/0x70
security/security.c:2029
[<000000009fb5708b>] sk_prot_alloc+0x12d/0x170 net/core/sock.c:1606
[<00000000ad5c33ee>] sk_alloc+0x35/0x2f0 net/core/sock.c:1657
[<000000004e2b1f5c>] nr_make_new net/netrom/af_netrom.c:476 [inline]
[<000000004e2b1f5c>] nr_rx_frame+0x339/0x8ee net/netrom/af_netrom.c:959
[<00000000df4c3d82>] nr_loopback_timer+0x4e/0xd0
net/netrom/nr_loopback.c:59
[<00000000e886ef23>] call_timer_fn+0x45/0x1e0 kernel/time/timer.c:1322
[<00000000cc0c55bd>] expire_timers kernel/time/timer.c:1366 [inline]
[<00000000cc0c55bd>] __run_timers kernel/time/timer.c:1685 [inline]
[<00000000cc0c55bd>] __run_timers kernel/time/timer.c:1653 [inline]
[<00000000cc0c55bd>] run_timer_softirq+0x256/0x740
kernel/time/timer.c:1698
[<000000008a8ac853>] __do_softirq+0x115/0x33f kernel/softirq.c:292
[<00000000c33f7c40>] invoke_softirq kernel/softirq.c:373 [inline]
[<00000000c33f7c40>] irq_exit+0xbb/0xe0 kernel/softirq.c:413
[<00000000dc851865>] exiting_irq arch/x86/include/asm/apic.h:537
[inline]
[<00000000dc851865>] smp_apic_timer_interrupt+0x96/0x190
arch/x86/kernel/apic/apic.c:1133
[<000000006a57c22f>] apic_timer_interrupt+0xf/0x20
arch/x86/entry/entry_64.S:830
[<00000000ec52384e>] arch_local_irq_restore
arch/x86/include/asm/paravirt.h:768 [inline]
[<00000000ec52384e>] console_unlock.part.0+0x5f0/0x6d0
kernel/printk/printk.c:2471
[<0000000013f07031>] console_unlock kernel/printk/printk.c:2364 [inline]
[<0000000013f07031>] vprintk_emit+0x251/0x360
kernel/printk/printk.c:1986
[<00000000704abaae>] vprintk_default+0x28/0x30
kernel/printk/printk.c:2013
---
This bug is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.
syzbot will keep track of this bug report. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
syzbot can test patches for this bug, for details see:
https://goo.gl/tpsmEJ#testing-patches
^ permalink raw reply
* Re: [PATCH v6 net-next 07/19] ionic: Add basic adminq support
From: Shannon Nelson @ 2019-08-30 19:31 UTC (permalink / raw)
To: Jakub Kicinski; +Cc: netdev, davem
In-Reply-To: <20190829155251.3b2d86c7@cakuba.netronome.com>
On 8/29/19 3:52 PM, Jakub Kicinski wrote:
> On Thu, 29 Aug 2019 11:27:08 -0700, Shannon Nelson wrote:
>> +static void ionic_lif_qcq_deinit(struct ionic_lif *lif, struct ionic_qcq *qcq)
>> +{
>> + struct ionic_dev *idev = &lif->ionic->idev;
>> + struct device *dev = lif->ionic->dev;
>> +
>> + if (!qcq)
>> + return;
>> +
>> + ionic_debugfs_del_qcq(qcq);
>> +
>> + if (!(qcq->flags & IONIC_QCQ_F_INITED))
>> + return;
>> +
>> + if (qcq->flags & IONIC_QCQ_F_INTR) {
>> + ionic_intr_mask(idev->intr_ctrl, qcq->intr.index,
>> + IONIC_INTR_MASK_SET);
>> + synchronize_irq(qcq->intr.vector);
>> + devm_free_irq(dev, qcq->intr.vector, &qcq->napi);
> Doesn't free_irq() basically imply synchronize_irq()?
The synchronize_irq() waits for any threaded handlers to finish, while
free_irq() only waits for HW handling. This helps makes sure we don't
have anything still running before we remove resources.
sln
>
>> + netif_napi_del(&qcq->napi);
>> + }
>> +
>> + qcq->flags &= ~IONIC_QCQ_F_INITED;
^ permalink raw reply
* Re: [PATCH][V2] wimax/i2400m: remove debug containing bogus calculation of index
From: David Miller @ 2019-08-30 19:32 UTC (permalink / raw)
To: colin.king
Cc: inaky.perez-gonzalez, linux-wimax, netdev, kernel-janitors,
linux-kernel
In-Reply-To: <20190830090711.15300-1-colin.king@canonical.com>
From: Colin King <colin.king@canonical.com>
Date: Fri, 30 Aug 2019 10:07:11 +0100
> From: Colin Ian King <colin.king@canonical.com>
>
> The subtraction of the two pointers is automatically scaled by the
> size of the size of the object the pointers point to, so the division
> by sizeof(*i2400m->barker) is incorrect. This has been broken since
> day one of the driver and is only debug, so remove the debug completely.
>
> Also move && in condition to clean up a checkpatch warning.
>
> Addresses-Coverity: ("Extra sizeof expression")
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
> ---
>
> V2: completely remove debug, clean up checkpatch warning, change subject line
Applied to net-next, thanks Colin.
^ permalink raw reply
* Re: [PATCH v6 net-next 12/19] ionic: Add Rx filter and rx_mode ndo support
From: Shannon Nelson @ 2019-08-30 19:35 UTC (permalink / raw)
To: Jakub Kicinski; +Cc: netdev, davem
In-Reply-To: <20190829160610.60563ca0@cakuba.netronome.com>
On 8/29/19 4:06 PM, Jakub Kicinski wrote:
> On Thu, 29 Aug 2019 11:27:13 -0700, Shannon Nelson wrote:
>> @@ -588,8 +866,26 @@ static int ionic_set_features(struct net_device *netdev,
>>
>> static int ionic_set_mac_address(struct net_device *netdev, void *sa)
>> {
>> - netdev_info(netdev, "%s: stubbed\n", __func__);
>> - return 0;
>> + struct sockaddr *addr = sa;
>> + u8 *mac;
>> +
>> + mac = (u8 *)addr->sa_data;
>> + if (ether_addr_equal(netdev->dev_addr, mac))
>> + return 0;
>> +
>> + if (!is_valid_ether_addr(mac))
>> + return -EADDRNOTAVAIL;
>> +
>> + if (!is_zero_ether_addr(netdev->dev_addr)) {
>> + netdev_info(netdev, "deleting mac addr %pM\n",
>> + netdev->dev_addr);
>> + ionic_addr_del(netdev, netdev->dev_addr);
>> + }
>> +
>> + memcpy(netdev->dev_addr, mac, netdev->addr_len);
>> + netdev_info(netdev, "updating mac addr %pM\n", mac);
>> +
>> + return ionic_addr_add(netdev, mac);
>> }
> Please use the eth_prepare_mac_addr_change() and
> eth_commit_mac_addr_change() helpers.
Oh, hadn't seen those before... sure.
sln
^ permalink raw reply
* Re: [v2] iproute2-next: police: support 64bit rate and peakrate in tc utility
From: Stephen Hemminger @ 2019-08-30 19:37 UTC (permalink / raw)
To: David Dai; +Cc: jhs, xiyou.wangcong, jiri, netdev, linux-kernel, zdai
In-Reply-To: <1567192037-11684-1-git-send-email-zdai@linux.vnet.ibm.com>
On Fri, 30 Aug 2019 14:07:17 -0500
David Dai <zdai@linux.vnet.ibm.com> wrote:
> + if (rate64) {
> fprintf(stderr, "Double \"rate\" spec\n");
> return -1;
> }
The m_police filter should start using the common functions
for duparg and invarg that are in lib/utils.c
^ permalink raw reply
* Re: [v2] net_sched: act_police: add 2 new attributes to support police 64bit rate and peakrate
From: David Z. Dai @ 2019-08-30 20:03 UTC (permalink / raw)
To: Cong Wang
Cc: Jamal Hadi Salim, Jiri Pirko, David Miller,
Linux Kernel Network Developers, LKML, zdai
In-Reply-To: <CAM_iQpVMYQUdQN5L+ntXZTffZkW4q659bvXoZ8+Ar+zeud7Y4Q@mail.gmail.com>
On Fri, 2019-08-30 at 12:11 -0700, Cong Wang wrote:
> On Fri, Aug 30, 2019 at 12:06 PM David Dai <zdai@linux.vnet.ibm.com> wrote:
> > - if (p->peak_present)
> > + if ((police->params->rate.rate_bytes_ps >= (1ULL << 32)) &&
> > + nla_put_u64_64bit(skb, TCA_POLICE_RATE64,
> > + police->params->rate.rate_bytes_ps,
> > + __TCA_POLICE_MAX))
>
> I think the last parameter should be TCA_POLICE_PAD.
Thanks for reviewing it!
I have the impression that last parameter num value should be larger
than the attribute num value in 2nd parameter (TC_POLICE_RATE64 in this
case). This is the reason I changed the last parameter value to
__TCA_POLICE_MAX after I moved the new attributes after TC_POLICE_PAD in
pkt_cls.h header.
I rebuilt the kernel module act_police.ko by using TC_POLICE_PAD in the
4 parameter as before, I am able to set > 32bit rate and peakrate value
in tc command. It also works properly.
If the rest of community thinks I should keep using TC_POLICE_PAD in the
4th parameter too, I can change it to TC_POLICE_PAD in the next version.
Thanks!
^ permalink raw reply
* Re: [v2] net_sched: act_police: add 2 new attributes to support police 64bit rate and peakrate
From: Cong Wang @ 2019-08-30 20:09 UTC (permalink / raw)
To: David Z. Dai
Cc: Jamal Hadi Salim, Jiri Pirko, David Miller,
Linux Kernel Network Developers, LKML, zdai
In-Reply-To: <1567195432.20025.18.camel@oc5348122405>
On Fri, Aug 30, 2019 at 1:03 PM David Z. Dai <zdai@linux.vnet.ibm.com> wrote:
>
> On Fri, 2019-08-30 at 12:11 -0700, Cong Wang wrote:
> > On Fri, Aug 30, 2019 at 12:06 PM David Dai <zdai@linux.vnet.ibm.com> wrote:
> > > - if (p->peak_present)
> > > + if ((police->params->rate.rate_bytes_ps >= (1ULL << 32)) &&
> > > + nla_put_u64_64bit(skb, TCA_POLICE_RATE64,
> > > + police->params->rate.rate_bytes_ps,
> > > + __TCA_POLICE_MAX))
> >
> > I think the last parameter should be TCA_POLICE_PAD.
> Thanks for reviewing it!
> I have the impression that last parameter num value should be larger
> than the attribute num value in 2nd parameter (TC_POLICE_RATE64 in this
Why do you have this impression?
> case). This is the reason I changed the last parameter value to
> __TCA_POLICE_MAX after I moved the new attributes after TC_POLICE_PAD in
> pkt_cls.h header.
The prototype clearly shows it must be a padding attribute:
static inline int nla_put_u64_64bit(struct sk_buff *skb, int attrtype,
u64 value, int padattr)
^ permalink raw reply
* Re: [PATCH bpf-next 00/13] bpf: adding map batch processing support
From: Stanislav Fomichev @ 2019-08-30 20:15 UTC (permalink / raw)
To: Jakub Kicinski
Cc: Brian Vazquez, Yonghong Song, Alexei Starovoitov, bpf, netdev,
Daniel Borkmann, kernel-team
In-Reply-To: <20190829171513.7699dbf3@cakuba.netronome.com>
On 08/29, Jakub Kicinski wrote:
> On Thu, 29 Aug 2019 16:13:59 -0700, Brian Vazquez wrote:
> > > We need a per-map implementation of the exec side, but roughly maps
> > > would do:
> > >
> > > LIST_HEAD(deleted);
> > >
> > > for entry in map {
> > > struct map_op_ctx {
> > > .key = entry->key,
> > > .value = entry->value,
> > > };
> > >
> > > act = BPF_PROG_RUN(filter, &map_op_ctx);
> > > if (act & ~ACT_BITS)
> > > return -EINVAL;
> > >
> > > if (act & DELETE) {
> > > map_unlink(entry);
> > > list_add(entry, &deleted);
> > > }
> > > if (act & STOP)
> > > break;
> > > }
> > >
> > > synchronize_rcu();
> > >
> > > for entry in deleted {
> > > struct map_op_ctx {
> > > .key = entry->key,
> > > .value = entry->value,
> > > };
> > >
> > > BPF_PROG_RUN(dumper, &map_op_ctx);
> > > map_free(entry);
> > > }
> > >
> > Hi Jakub,
> >
> > how would that approach support percpu maps?
> >
> > I'm thinking of a scenario where you want to do some calculations on
> > percpu maps and you are interested on the info on all the cpus not
> > just the one that is running the bpf program. Currently on a pcpu map
> > the bpf_map_lookup_elem helper only returns the pointer to the data of
> > the executing cpu.
>
> Right, we need to have the iteration outside of the bpf program itself,
> and pass the element in through the context. That way we can feed each
> per cpu entry into the program separately.
My 2 cents:
I personally like Jakub's/Quentin's proposal more. So if I get to choose
between this series and Jakub's filter+dump in BPF, I'd pick filter+dump
(pending per-cpu issue which we actually care about).
But if we can have both, I don't have any objections; this patch
series looks to me a lot like what Brian did, just extended to more
commands. If we are fine with the shortcomings raised about the
original series, then let's go with this version. Maybe we can also
look into addressing these independently.
But if I pretend that we live in an ideal world, I'd just go with
whatever Jakub and Quentin are doing so we don't have to support
two APIs that essentially do the same (minus batching update, but
it looks like there is no clear use case for that yet; maybe).
I guess you can hold off this series a bit and discuss it at LPC,
you have a talk dedicated to that :-) (and afaiu, you are all going)
^ permalink raw reply
* [PATCH] enetc: Add missing call to 'pci_free_irq_vectors()' in probe and remove functions
From: Christophe JAILLET @ 2019-08-30 20:23 UTC (permalink / raw)
To: yangbo.lu, claudiu.manoil, davem
Cc: netdev, linux-kernel, kernel-janitors, Christophe JAILLET
Call to 'pci_free_irq_vectors()' are missing both in the error handling
path of the probe function, and in the remove function.
Add them.
Fixes: 19971f5ea0ab ("enetc: add PTP clock driver")
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
---
drivers/net/ethernet/freescale/enetc/enetc_ptp.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/freescale/enetc/enetc_ptp.c b/drivers/net/ethernet/freescale/enetc/enetc_ptp.c
index 2fd2586e42bf..bc594892507a 100644
--- a/drivers/net/ethernet/freescale/enetc/enetc_ptp.c
+++ b/drivers/net/ethernet/freescale/enetc/enetc_ptp.c
@@ -82,7 +82,7 @@ static int enetc_ptp_probe(struct pci_dev *pdev,
n = pci_alloc_irq_vectors(pdev, 1, 1, PCI_IRQ_MSIX);
if (n != 1) {
err = -EPERM;
- goto err_irq;
+ goto err_irq_vectors;
}
ptp_qoriq->irq = pci_irq_vector(pdev, 0);
@@ -107,6 +107,8 @@ static int enetc_ptp_probe(struct pci_dev *pdev,
err_no_clock:
free_irq(ptp_qoriq->irq, ptp_qoriq);
err_irq:
+ pci_free_irq_vectors(pdev);
+err_irq_vectors:
iounmap(base);
err_ioremap:
kfree(ptp_qoriq);
@@ -125,6 +127,7 @@ static void enetc_ptp_remove(struct pci_dev *pdev)
enetc_phc_index = -1;
ptp_qoriq_free(ptp_qoriq);
+ pci_free_irq_vectors(pdev);
kfree(ptp_qoriq);
pci_release_mem_regions(pdev);
--
2.20.1
^ permalink raw reply related
* Re: Is bug 200755 in anyone's queue??
From: Willem de Bruijn @ 2019-08-30 20:30 UTC (permalink / raw)
To: Eric Dumazet
Cc: Steve Zabele, Network Development, shum, vladimir116, saifi.khan,
Daniel Borkmann, on2k16nm, Stephen Hemminger
In-Reply-To: <8f4bda24-5bd4-3f12-4c98-5e1097dde84a@gmail.com>
On Fri, Aug 30, 2019 at 4:54 AM Eric Dumazet <eric.dumazet@gmail.com> wrote:
>
>
>
> On 8/29/19 9:26 PM, Willem de Bruijn wrote:
>
> > SO_REUSEPORT was not intended to be used in this way. Opening
> > multiple connected sockets with the same local port.
> >
> > But since the interface allowed connect after joining a group, and
> > that is being used, I guess that point is moot. Still, I'm a bit
> > surprised that it ever worked as described.
> >
> > Also note that the default distribution algorithm is not round robin
> > assignment, but hash based. So multiple consecutive datagrams arriving
> > at the same socket is not unexpected.
> >
> > I suspect that this quick hack might "work". It seemed to on the
> > supplied .c file:
> >
> > score = compute_score(sk, net, saddr, sport,
> > daddr, hnum, dif, sdif);
> > if (score > badness) {
> > - if (sk->sk_reuseport) {
> > + if (sk->sk_reuseport && !sk->sk_state !=
> > TCP_ESTABLISHED) {
This won't work for a mix of connected and connectionless sockets, of
course (even ignoring the typo), as it only skips reuseport on the
connected sockets.
> >
> > But a more robust approach, that also works on existing kernels, is to
> > swap the default distribution algorithm with a custom BPF based one (
> > SO_ATTACH_REUSEPORT_EBPF).
> >
>
> Yes, I suspect that reuseport could still be used by to load-balance incoming packets
> targetting the same 4-tuple.
>
> So all sockets would have the same score, and we would select the first socket in
> the list (if not applying reuseport hashing)
Can you elaborate a bit?
One option I see is to record in struct sock_reuseport if any port in
the group is connected and, if so, don't return immediately on the
first reuseport_select_sock hit, but continue the search for a higher
scoring connected socket.
Or do return immediately, but do this refined search in
reuseport_select_sock itself, as it has a reference to all sockets in the
group in sock_reuseport->socks[]. Instead of the straightforward hash.
Steve, Re: your point on a scalable QUIC server. That is an
interesting case certainly. Opening a connected socket per flow adds
both memory and port table pressure. I once looked into an SO_TXONLY
udp socket option that does not hash connected sockets into the port
table. In effect receiving on a small set of listening sockets (e.g.,
one per cpu) and sending over separate tx-only sockets. That still
introduces unnecessary memory allocation. OTOH it amortizes some
operations, such as route lookup.
Anyway, that does not fix the immediate issue you reported when using
SO_REUSEPORT as described.
^ permalink raw reply
* Re: [v2] net_sched: act_police: add 2 new attributes to support police 64bit rate and peakrate
From: David Miller @ 2019-08-30 20:33 UTC (permalink / raw)
To: zdai; +Cc: xiyou.wangcong, jhs, jiri, netdev, linux-kernel, zdai
In-Reply-To: <1567195432.20025.18.camel@oc5348122405>
From: "David Z. Dai" <zdai@linux.vnet.ibm.com>
Date: Fri, 30 Aug 2019 15:03:52 -0500
> I have the impression that last parameter num value should be larger
> than the attribute num value in 2nd parameter (TC_POLICE_RATE64 in this
> case).
The argument in question is explicitly the "padding" value.
Please explain in detail where you got the impression that the
argument has to be larger?
^ permalink raw reply
* [PATCH v2 net-next] net/ncsi: add response handlers for PLDM over NC-SI
From: Ben Wei @ 2019-08-30 20:50 UTC (permalink / raw)
To: David Miller, sam@mendozajonas.com, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, openbmc@lists.ozlabs.org
Cc: Ben Wei
This patch adds handlers for PLDM over NC-SI command response.
This enables NC-SI driver recognizes the packet type so the responses
don't get dropped as unknown packet type.
PLDM over NC-SI are not handled in kernel driver for now, but can be
passed back to user space via Netlink for further handling.
Signed-off-by: Ben Wei <benwei@fb.com>
---
Changes in v2
- fix function definition spacing
net/ncsi/ncsi-pkt.h | 5 +++++
net/ncsi/ncsi-rsp.c | 11 +++++++++--
2 files changed, 14 insertions(+), 2 deletions(-)
diff --git a/net/ncsi/ncsi-pkt.h b/net/ncsi/ncsi-pkt.h
index a8e9def593f2..80938b338fee 100644
--- a/net/ncsi/ncsi-pkt.h
+++ b/net/ncsi/ncsi-pkt.h
@@ -387,6 +387,9 @@ struct ncsi_aen_hncdsc_pkt {
#define NCSI_PKT_CMD_OEM 0x50 /* OEM */
#define NCSI_PKT_CMD_PLDM 0x51 /* PLDM request over NCSI over RBT */
#define NCSI_PKT_CMD_GPUUID 0x52 /* Get package UUID */
+#define NCSI_PKT_CMD_QPNPR 0x56 /* Query Pending NC PLDM request */
+#define NCSI_PKT_CMD_SNPR 0x57 /* Send NC PLDM Reply */
+
/* NCSI packet responses */
#define NCSI_PKT_RSP_CIS (NCSI_PKT_CMD_CIS + 0x80)
@@ -419,6 +422,8 @@ struct ncsi_aen_hncdsc_pkt {
#define NCSI_PKT_RSP_OEM (NCSI_PKT_CMD_OEM + 0x80)
#define NCSI_PKT_RSP_PLDM (NCSI_PKT_CMD_PLDM + 0x80)
#define NCSI_PKT_RSP_GPUUID (NCSI_PKT_CMD_GPUUID + 0x80)
+#define NCSI_PKT_RSP_QPNPR (NCSI_PKT_CMD_QPNPR + 0x80)
+#define NCSI_PKT_RSP_SNPR (NCSI_PKT_CMD_SNPR + 0x80)
/* NCSI response code/reason */
#define NCSI_PKT_RSP_C_COMPLETED 0x0000 /* Command Completed */
diff --git a/net/ncsi/ncsi-rsp.c b/net/ncsi/ncsi-rsp.c
index 5254004f2b42..524974af0db6 100644
--- a/net/ncsi/ncsi-rsp.c
+++ b/net/ncsi/ncsi-rsp.c
@@ -1035,6 +1035,11 @@ static int ncsi_rsp_handler_gpuuid(struct ncsi_request *nr)
return 0;
}
+static int ncsi_rsp_handler_pldm(struct ncsi_request *nr)
+{
+ return 0;
+}
+
static int ncsi_rsp_handler_netlink(struct ncsi_request *nr)
{
struct ncsi_dev_priv *ndp = nr->ndp;
@@ -1088,8 +1093,10 @@ static struct ncsi_rsp_handler {
{ NCSI_PKT_RSP_GNPTS, 48, ncsi_rsp_handler_gnpts },
{ NCSI_PKT_RSP_GPS, 8, ncsi_rsp_handler_gps },
{ NCSI_PKT_RSP_OEM, -1, ncsi_rsp_handler_oem },
- { NCSI_PKT_RSP_PLDM, 0, NULL },
- { NCSI_PKT_RSP_GPUUID, 20, ncsi_rsp_handler_gpuuid }
+ { NCSI_PKT_RSP_PLDM, -1, ncsi_rsp_handler_pldm },
+ { NCSI_PKT_RSP_GPUUID, 20, ncsi_rsp_handler_gpuuid },
+ { NCSI_PKT_RSP_QPNPR, -1, ncsi_rsp_handler_pldm },
+ { NCSI_PKT_RSP_SNPR, -1, ncsi_rsp_handler_pldm }
};
int ncsi_rcv_rsp(struct sk_buff *skb, struct net_device *dev,
--
2.17.1
^ permalink raw reply related
* Re: [PATCH v3 net-next 00/15] ioc3-eth improvements
From: David Miller @ 2019-08-30 20:55 UTC (permalink / raw)
To: tbogendoerfer; +Cc: ralf, paul.burton, jhogan, linux-mips, linux-kernel, netdev
In-Reply-To: <20190830092539.24550-1-tbogendoerfer@suse.de>
From: Thomas Bogendoerfer <tbogendoerfer@suse.de>
Date: Fri, 30 Aug 2019 11:25:23 +0200
> In my patch series for splitting out the serial code from ioc3-eth
> by using a MFD device there was one big patch for ioc3-eth.c,
> which wasn't really usefull for reviews. This series contains the
> ioc3-eth changes splitted in smaller steps and few more cleanups.
> Only the conversion to MFD will be done later in a different series.
>
> Changes in v3:
> - no need to check skb == NULL before passing it to dev_kfree_skb_any
> - free memory allocated with get_page(s) with free_page(s)
> - allocate rx ring with just GFP_KERNEL
> - add required alignment for rings in comments
>
> Changes in v2:
> - use net_err_ratelimited for printing various ioc3 errors
> - added missing clearing of rx buf valid flags into ioc3_alloc_rings
> - use __func__ for printing out of memory messages
Series applied, thanks.
I might be nice to use get_order() instead of hardcoding the page size
when "2" is passed into the page alloc/free calls. Just FYI...
^ permalink raw reply
* Re: [PATCH v4 2/2] net: br_netfiler_hooks: Drops IPv6 packets if IPv6 module is not loaded
From: Florian Westphal @ 2019-08-30 20:55 UTC (permalink / raw)
To: Leonardo Bras
Cc: netfilter-devel, coreteam, bridge, netdev, linux-kernel,
Pablo Neira Ayuso, Jozsef Kadlecsik, Florian Westphal,
Roopa Prabhu, Nikolay Aleksandrov, David S. Miller
In-Reply-To: <20190830181354.26279-3-leonardo@linux.ibm.com>
Leonardo Bras <leonardo@linux.ibm.com> wrote:
> A kernel panic can happen if a host has disabled IPv6 on boot and have to
> process guest packets (coming from a bridge) using it's ip6tables.
>
> IPv6 packets need to be dropped if the IPv6 module is not loaded.
>
> Signed-off-by: Leonardo Bras <leonardo@linux.ibm.com>
> ---
> net/bridge/br_netfilter_hooks.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/net/bridge/br_netfilter_hooks.c b/net/bridge/br_netfilter_hooks.c
> index d3f9592f4ff8..5e8693730df1 100644
> --- a/net/bridge/br_netfilter_hooks.c
> +++ b/net/bridge/br_netfilter_hooks.c
> @@ -493,6 +493,8 @@ static unsigned int br_nf_pre_routing(void *priv,
> brnet = net_generic(state->net, brnf_net_id);
> if (IS_IPV6(skb) || is_vlan_ipv6(skb, state->net) ||
> is_pppoe_ipv6(skb, state->net)) {
> + if (!ipv6_mod_enabled())
> + return NF_DROP;
> if (!brnet->call_ip6tables &&
> !br_opt_get(br, BROPT_NF_CALL_IP6TABLES))
> return NF_ACCEPT;
No, thats too aggressive and turns the bridge into an ipv6 blackhole.
There are two solutions:
1. The above patch, but use NF_ACCEPT instead
2. keep the DROP, but move it below the call_ip6tables test,
so that users can tweak call-ip6tables to accept packets.
Perhaps it would be good to also add a pr_warn_once() that
tells that ipv6 was disabled on command line and
call-ip6tables isn't supported in this configuration.
I would go with option two.
^ permalink raw reply
* Re: [PATCH bpf-next 00/13] bpf: adding map batch processing support
From: Yonghong Song @ 2019-08-30 20:55 UTC (permalink / raw)
To: Stanislav Fomichev, Jakub Kicinski
Cc: Brian Vazquez, Alexei Starovoitov, bpf@vger.kernel.org,
netdev@vger.kernel.org, Daniel Borkmann, Kernel Team
In-Reply-To: <20190830201513.GA2101@mini-arch>
On 8/30/19 1:15 PM, Stanislav Fomichev wrote:
> On 08/29, Jakub Kicinski wrote:
>> On Thu, 29 Aug 2019 16:13:59 -0700, Brian Vazquez wrote:
>>>> We need a per-map implementation of the exec side, but roughly maps
>>>> would do:
>>>>
>>>> LIST_HEAD(deleted);
>>>>
>>>> for entry in map {
>>>> struct map_op_ctx {
>>>> .key = entry->key,
>>>> .value = entry->value,
>>>> };
>>>>
>>>> act = BPF_PROG_RUN(filter, &map_op_ctx);
>>>> if (act & ~ACT_BITS)
>>>> return -EINVAL;
>>>>
>>>> if (act & DELETE) {
>>>> map_unlink(entry);
>>>> list_add(entry, &deleted);
>>>> }
>>>> if (act & STOP)
>>>> break;
>>>> }
>>>>
>>>> synchronize_rcu();
>>>>
>>>> for entry in deleted {
>>>> struct map_op_ctx {
>>>> .key = entry->key,
>>>> .value = entry->value,
>>>> };
>>>>
>>>> BPF_PROG_RUN(dumper, &map_op_ctx);
>>>> map_free(entry);
>>>> }
>>>>
>>> Hi Jakub,
>>>
>>> how would that approach support percpu maps?
>>>
>>> I'm thinking of a scenario where you want to do some calculations on
>>> percpu maps and you are interested on the info on all the cpus not
>>> just the one that is running the bpf program. Currently on a pcpu map
>>> the bpf_map_lookup_elem helper only returns the pointer to the data of
>>> the executing cpu.
>>
>> Right, we need to have the iteration outside of the bpf program itself,
>> and pass the element in through the context. That way we can feed each
>> per cpu entry into the program separately.
> My 2 cents:
>
> I personally like Jakub's/Quentin's proposal more. So if I get to choose
> between this series and Jakub's filter+dump in BPF, I'd pick filter+dump
> (pending per-cpu issue which we actually care about).
>
> But if we can have both, I don't have any objections; this patch
> series looks to me a lot like what Brian did, just extended to more
> commands. If we are fine with the shortcomings raised about the
> original series, then let's go with this version. Maybe we can also
> look into addressing these independently.
>
> But if I pretend that we live in an ideal world, I'd just go with
> whatever Jakub and Quentin are doing so we don't have to support
> two APIs that essentially do the same (minus batching update, but
> it looks like there is no clear use case for that yet; maybe).
>
> I guess you can hold off this series a bit and discuss it at LPC,
> you have a talk dedicated to that :-) (and afaiu, you are all going)
Absolutely. We will have a discussion on map batching and I signed
on with that :-). One of goals for this patch set is for me to explore
what uapi (attr and bpf subcommands) we should expose to users.
Hopefully at that time we will get more clarity
on Jakub's approach and we can discuss how to proceed.
^ permalink raw reply
* Re: [PATCH net-next] net/ncsi: add response handlers for PLDM over NC-SI
From: Ben Wei @ 2019-08-30 20:57 UTC (permalink / raw)
To: David Miller
Cc: sam@mendozajonas.com, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, openbmc@lists.ozlabs.org
In-Reply-To: <20190828.160032.599086044004802986.davem@davemloft.net>
> > This patch adds handlers for PLDM over NC-SI command response.
> >
> > This enables NC-SI driver recognizes the packet type so the responses don't get dropped as unknown packet type.
> >
> > PLDM over NC-SI are not handled in kernel driver for now, but can be passed back to user space via Netlink for further handling.
> >
> > Signed-off-by: Ben Wei <benwei@fb.com>
>
> I don't know why but patchwork puts part of your patch into the commit message, see:
>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__patchwork.ozlabs.org_patch_1154104_&d=DwICAg&c=5VD0RTtNlTh3ycd41b3MUw&r=U35IaQ-> 7Tnwjs7q_Fwf_bQ&m=vxOIQa5Sv7aY4LKSUvlobJd_TtHOz1KLjxZw8WXmkJM&s=A8rpxgac6iuSEH2DqCSzBDdM82Eu3pD8_nGHx9YtGW8&e=
>
> It's probably an encoding issue or similar.
>
> > +static int ncsi_rsp_handler_pldm(struct ncsi_request *nr) {
>> + return 0;
> > +}
> > +
> > static int ncsi_rsp_handler_netlink(struct ncsi_request *nr) {
>
> I know other functions in this file do it, but please put the openning
> curly braces of a function on a separate line.
>
> Thank you.
Thanks David. I think the issue is related to my email client setting. I fixed it and resubmitted a v2 version of this patch.
Thanks,
-Ben
^ permalink raw reply
* Re: [PATCH v4 1/2] netfilter: Terminate rule eval if protocol=IPv6 and ipv6 module is disabled
From: Florian Westphal @ 2019-08-30 20:58 UTC (permalink / raw)
To: Leonardo Bras
Cc: netfilter-devel, coreteam, bridge, netdev, linux-kernel,
Pablo Neira Ayuso, Jozsef Kadlecsik, Florian Westphal,
Roopa Prabhu, Nikolay Aleksandrov, David S. Miller
In-Reply-To: <20190830181354.26279-2-leonardo@linux.ibm.com>
Leonardo Bras <leonardo@linux.ibm.com> wrote:
> If IPv6 is disabled on boot (ipv6.disable=1), but nft_fib_inet ends up
> dealing with a IPv6 packet, it causes a kernel panic in
> fib6_node_lookup_1(), crashing in bad_page_fault.
>
> The panic is caused by trying to deference a very low address (0x38
> in ppc64le), due to ipv6.fib6_main_tbl = NULL.
> BUG: Kernel NULL pointer dereference at 0x00000038
>
> The kernel panic was reproduced in a host that disabled IPv6 on boot and
> have to process guest packets (coming from a bridge) using it's ip6tables.
>
> Terminate rule evaluation when packet protocol is IPv6 but the ipv6 module
> is not loaded.
>
> Signed-off-by: Leonardo Bras <leonardo@linux.ibm.com>
Acked-by: Florian Westphal <fw@strlen.de>
^ permalink raw reply
* Re: [PATCH net-next v2 00/22] bnxt_en: health and error recovery.
From: David Miller @ 2019-08-30 21:02 UTC (permalink / raw)
To: michael.chan; +Cc: netdev, vasundhara-v.volam, ray.jui
In-Reply-To: <1567137305-5853-1-git-send-email-michael.chan@broadcom.com>
From: Michael Chan <michael.chan@broadcom.com>
Date: Thu, 29 Aug 2019 23:54:43 -0400
> This patchset implements adapter health and error recovery. The status
> is reported through several devlink reporters and the driver will
> initiate and complete the recovery process using the devlink infrastructure.
>
> v2: Added 4 patches at the beginning of the patchset to clean up error code
> handling related to firmware messages and to convert to use standard
> error codes.
>
> Removed the dropping of rtnl_lock in bnxt_close().
>
> Broke up the patches some more for better patch organization and
> future bisection.
The return value handling looks a lot better now, thanks for cleaning that
up.
Series applied, thanks Michael.
^ permalink raw reply
* Re: [PATCH net] dev: Delay the free of the percpu refcount
From: Subash Abhinov Kasiviswanathan @ 2019-08-30 21:03 UTC (permalink / raw)
To: Eric Dumazet; +Cc: davem, netdev, Sean Tranchetti
In-Reply-To: <959f4b3e-387d-a148-3281-aed26a6a7aa5@gmail.com>
> This looks bogus.
>
> Whatever layer tries to access dev refcnt after free_netdev() has been
> called is buggy.
>
> I would rather trap early and fix the root cause.
>
> Untested patch :
>
> diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
> index b5d28dadf964..8080f1305417 100644
> --- a/include/linux/netdevice.h
> +++ b/include/linux/netdevice.h
> @@ -3723,6 +3723,7 @@ void netdev_run_todo(void);
> */
> static inline void dev_put(struct net_device *dev)
> {
> + BUG_ON(!dev->pcpu_refcnt);
> this_cpu_dec(*dev->pcpu_refcnt);
> }
>
> @@ -3734,6 +3735,7 @@ static inline void dev_put(struct net_device
> *dev)
> */
> static inline void dev_hold(struct net_device *dev)
> {
> + BUG_ON(!dev->pcpu_refcnt);
> this_cpu_inc(*dev->pcpu_refcnt);
> }
Hello Eric
I am seeing a similar crash with your patch as well.
The NULL dev->pcpu_refcnt was caught by the BUG you added.
786.510217: <6> kernel BUG at include/linux/netdevice.h:3633!
786.510263: <2> pc : in_dev_finish_destroy+0xcc/0xd0
786.510267: <2> lr : in_dev_finish_destroy+0x2c/0xd0
786.511220: <2> Call trace:
786.511225: <2> in_dev_finish_destroy+0xcc/0xd0
786.511230: <2> in_dev_rcu_put+0x24/0x30
786.511237: <2> rcu_nocb_kthread+0x43c/0x468
786.511243: <2> kthread+0x118/0x128
786.511249: <2> ret_from_fork+0x10/0x1c
This seems to be happening when there is an allocation failure
in the IPv6 notifier callback only.
I had added some additional debug to narrow down the refcount
validity along the callers of the dev_put/dev_hold.
refcnt valid below shows that the pointer dev->pcpu_refcnt is valid
while refcnt null shows the case where dev->pcpu_refcnt is NULL.
The last dev_put happens after free_netdev leading to the
dev->pcpu_refcnt to be accessed when NULL.
309.908501: <6> dev_hold() ffffffe13c9df000 ip6_vti0 refcnt valid
setup_net+0xa0/0x210 -> ops_init+0x88/0x110
309.908674: <6> dev_hold() ffffffe13c9df000 ip6_vti0 refcnt valid
register_netdevice+0x29c/0x5b0 -> netdev_register_kobject+0xd8/0x150
309.908696: <6> dev_hold() ffffffe13c9df000 ip6_vti0 refcnt valid
register_netdevice+0x29c/0x5b0 -> netdev_register_kobject+0x100/0x150
309.908717: <6> dev_hold() ffffffe13c9df000 ip6_vti0 refcnt valid
vti6_init_net+0x188/0x1c0 -> register_netdev+0x28/0x40
309.908763: <6> neighbour: dev_hold() ffffffe13c9df000 ip6_vti0 refcnt
valid inetdev_event+0x43c/0x528 -> inetdev_init+0x80/0x1e0
309.908835: <6> dev_hold() ffffffe13c9df000 ip6_vti0 refcnt valid
raw_notifier_call_chain+0x3c/0x68 -> inetdev_event+0x43c/0x528
309.908882: <6> neighbour: dev_hold() ffffffe13c9df000 ip6_vti0 refcnt
valid addrconf_notify+0x42c/0xe58 -> ipv6_add_dev+0xe4/0x588
309.908890: <6> IPv6: dev_hold() ffffffe13c9df000 ip6_vti0 refcnt
valid raw_notifier_call_chain+0x3c/0x68 -> addrconf_notify+0x42c/0xe58
309.908906: <6> stress-ng-clone: page allocation failure: order:0,
mode:0x6040c0(GFP_KERNEL|__GFP_COMP), nodemask=(null)
309.908910: <6> stress-ng-clone cpuset=foreground mems_allowed=0
309.908925: <2> Call trace:
309.908931: <2> dump_backtrace+0x0/0x158
309.908934: <2> show_stack+0x14/0x20
309.908939: <2> dump_stack+0xc4/0xfc
309.908944: <2> warn_alloc+0xf8/0x168
309.908947: <2> __alloc_pages_nodemask+0xff4/0x1018
309.908955: <2> new_slab+0x128/0x5b8
309.908958: <2> ___slab_alloc+0x4cc/0x5f8
309.908960: <2> kmem_cache_alloc_trace+0x2a4/0x2c0
309.908963: <2> ipv6_add_dev+0x220/0x588
309.908966: <2> addrconf_notify+0x42c/0xe58
309.908969: <2> raw_notifier_call_chain+0x3c/0x68
309.908972: <2> register_netdevice+0x3c4/0x5b0
309.908974: <2> register_netdev+0x28/0x40
309.908978: <2> vti6_init_net+0x188/0x1c0
309.908981: <2> ops_init+0x88/0x110
309.908983: <2> setup_net+0xa0/0x210
309.908986: <2> copy_net_ns+0xa8/0x130
309.908990: <2> create_new_namespaces+0x138/0x170
309.908993: <2> unshare_nsproxy_namespaces+0x68/0x90
309.908999: <2> ksys_unshare+0x17c/0x248
309.909001: <2> __arm64_sys_unshare+0x10/0x20
309.909004: <2> el0_svc_common+0xa0/0x158
309.909007: <2> el0_svc_handler+0x6c/0x88
309.909010: <2> el0_svc+0x8/0xc
309.909021: <6> neighbour: dev_put() ffffffe13c9df000 ip6_vti0 refcnt
valid addrconf_notify+0x42c/0xe58 -> ipv6_add_dev+0x400/0x588
309.909030: <6> IPv6: dev_put() ffffffe13c9df000 ip6_vti0 refcnt valid
raw_notifier_call_chain+0x3c/0x68 -> addrconf_notify+0x42c/0xe58
309.918097: <6> neighbour: dev_put() ffffffe13c9df000 ip6_vti0 refcnt
valid raw_notifier_call_chain+0x3c/0x68 -> inetdev_event+0x290/0x528
309.918249: <6> dev_put() ffffffe13c9df000 ip6_vti0 refcnt valid
register_netdevice+0x3f8/0x5b0 -> rollback_registered_many+0x488/0x658
309.918318: <6> dev_put() ffffffe13c9df000 ip6_vti0 refcnt valid
net_rx_queue_update_kobjects+0x1ec/0x238 -> kobject_put+0x7c/0xc0
309.918405: <6> dev_put() ffffffe13c9df000 ip6_vti0 refcnt valid
netdev_queue_update_kobjects+0x1dc/0x228 -> kobject_put+0x7c/0xc0
309.918759: <6> dev_put() ffffffe13c9df000 ip6_vti0 refcnt valid
register_netdev+0x28/0x40 -> register_netdevice+0x3f8/0x5b0
309.918778: <6> free_netdev() ffffffe13c9df000 ip6_vti0 refcnt valid
ops_init+0x88/0x110 -> vti6_init_net+0x1ac/0x1c0
309.980671: <6> dev_put() ffffffe13c9df000 ip6_vti0 refcnt null
rcu_nocb_kthread+0x43c/0x468 -> in_dev_rcu_put+0x24/0x30
309.980838: <6> kernel BUG at include/linux/netdevice.h:3636!
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* Re: [PATCH bpf-next 00/13] bpf: adding map batch processing support
From: Jakub Kicinski @ 2019-08-30 21:10 UTC (permalink / raw)
To: Yonghong Song
Cc: Stanislav Fomichev, Brian Vazquez, Alexei Starovoitov,
bpf@vger.kernel.org, netdev@vger.kernel.org, Daniel Borkmann,
Kernel Team, Quentin Monnet
In-Reply-To: <eda3c9e0-8ad6-e684-0aeb-d63b9ed60aa7@fb.com>
On Fri, 30 Aug 2019 20:55:33 +0000, Yonghong Song wrote:
> > I guess you can hold off this series a bit and discuss it at LPC,
> > you have a talk dedicated to that :-) (and afaiu, you are all going)
>
> Absolutely. We will have a discussion on map batching and I signed
> on with that :-)
FWIW unfortunately neither Quentin nor I will be able to make the LPC
this year :( But the idea had been floated a few times (I'd certainly
not claim more authorship here than Ed or Alexei), and is simple enough
to move forward over email (I hope).
^ permalink raw reply
* Re: [PATCH net v1] net/sched: cbs: Fix not adding cbs instance to list
From: David Miller @ 2019-08-30 21:12 UTC (permalink / raw)
To: vinicius.gomes; +Cc: netdev, jhs, xiyou.wangcong, jiri, olteanv
In-Reply-To: <20190828173615.4264-1-vinicius.gomes@intel.com>
From: Vinicius Costa Gomes <vinicius.gomes@intel.com>
Date: Wed, 28 Aug 2019 10:36:15 -0700
> When removing a cbs instance when offloading is enabled, the crash
> below can be observed. Also, the current code doesn't handle correctly
> the case when offload is disabled without removing the qdisc: if the
> link speed changes the credit calculations will be wrong.
I think it does handle that case correctly, because in the !offloaded
code path of cbs_change() it makes an explict call to the function
cbs_set_port_rate().
And that is the only location where offload can be disabled on an
already existing instance.
If you agree, please fix your commit message to be more accurate on
this point.
Thank you.
^ permalink raw reply
* Re: [PATCH][V2] arcnet: capmode: remove redundant assignment to pointer pkt
From: David Miller @ 2019-08-30 21:15 UTC (permalink / raw)
To: colin.king; +Cc: m.grzeschik, netdev, kernel-janitors, linux-kernel
In-Reply-To: <20190828231450.22424-1-colin.king@canonical.com>
From: Colin King <colin.king@canonical.com>
Date: Thu, 29 Aug 2019 00:14:50 +0100
> From: Colin Ian King <colin.king@canonical.com>
>
> Pointer pkt is being initialized with a value that is never read
> and pkt is being re-assigned a little later on. The assignment is
> redundant and hence can be removed.
>
> Addresses-Coverity: ("Ununsed value")
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
> ---
>
> V2: fix typo in patch description, pkg -> pkt
Applied to net-next.
^ 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