* Re: [PATCH 1/2] net/macb: bindings doc: add sifive fu540-c000 binding
From: Yash Shah @ 2019-07-17 9:07 UTC (permalink / raw)
To: Nicolas Ferre
Cc: Rob Herring, David Miller, netdev,
linux-kernel@vger.kernel.org List, linux-riscv, devicetree,
Mark Rutland, Palmer Dabbelt, Albert Ou, Petr Štetiar,
Paul Walmsley, Sachin Ghadi
In-Reply-To: <b0c60ec9-2f57-c3f5-c3b4-ee83a5ec4c45@microchip.com>
On Mon, Jun 24, 2019 at 9:08 PM <Nicolas.Ferre@microchip.com> wrote:
>
> On 23/05/2019 at 22:50, Rob Herring wrote:
> > On Thu, May 23, 2019 at 6:46 AM Yash Shah <yash.shah@sifive.com> wrote:
> >>
> >> Add the compatibility string documentation for SiFive FU540-C0000
> >> interface.
> >> On the FU540, this driver also needs to read and write registers in a
> >> management IP block that monitors or drives boundary signals for the
> >> GEMGXL IP block that are not directly mapped to GEMGXL registers.
> >> Therefore, add additional range to "reg" property for SiFive GEMGXL
> >> management IP registers.
> >>
> >> Signed-off-by: Yash Shah <yash.shah@sifive.com>
> >> ---
> >> Documentation/devicetree/bindings/net/macb.txt | 3 +++
> >> 1 file changed, 3 insertions(+)
> >>
> >> diff --git a/Documentation/devicetree/bindings/net/macb.txt b/Documentation/devicetree/bindings/net/macb.txt
> >> index 9c5e944..91a2a66 100644
> >> --- a/Documentation/devicetree/bindings/net/macb.txt
> >> +++ b/Documentation/devicetree/bindings/net/macb.txt
> >> @@ -4,6 +4,7 @@ Required properties:
> >> - compatible: Should be "cdns,[<chip>-]{macb|gem}"
> >> Use "cdns,at91rm9200-emac" Atmel at91rm9200 SoC.
> >> Use "cdns,at91sam9260-macb" for Atmel at91sam9 SoCs.
> >> + Use "cdns,fu540-macb" for SiFive FU540-C000 SoC.
> >
> > This pattern that Atmel started isn't really correct. The vendor
> > prefix here should be sifive. 'cdns' would be appropriate for a
> > fallback.
>
> Ok, we missed this for the sam9x60 SoC that we added recently then.
>
> Anyway a little too late, coming back to this machine, and talking to
> Yash, isn't "sifive,fu540-c000-macb" more specific and a better match
> for being future proof? I would advice for the most specific possible
> with other compatible strings on the same line in the DT, like:
>
> "sifive,fu540-c000-macb", "sifive,fu540-macb"
>
Yes, I agree that "sifive,fu540-c000-macb" is a better match.
> Moreover, is it really a "macb" or a "gem" type of interface from
> Cadence? Not a big deal, but just to discuss the topic to the bone...
I believe it should be "gem". I will plan to submit the patch for
these changes. Thanks for pointing it out.
- Yash
>
> Note that I'm fine if you consider that what you have in net-next new is
> correct.
>
> Regards,
> Nicolas
>
> >> Use "cdns,sam9x60-macb" for Microchip sam9x60 SoC.
> >> Use "cdns,np4-macb" for NP4 SoC devices.
> >> Use "cdns,at32ap7000-macb" for other 10/100 usage or use the generic form: "cdns,macb".
> >> @@ -17,6 +18,8 @@ Required properties:
> >> Use "cdns,zynqmp-gem" for Zynq Ultrascale+ MPSoC.
> >> Or the generic form: "cdns,emac".
> >> - reg: Address and length of the register set for the device
> >> + For "cdns,fu540-macb", second range is required to specify the
> >> + address and length of the registers for GEMGXL Management block.
> >> - interrupts: Should contain macb interrupt
> >> - phy-mode: See ethernet.txt file in the same directory.
> >> - clock-names: Tuple listing input clock names.
> >> --
> >> 1.9.1
> >>
> >
>
>
> --
> Nicolas Ferre
^ permalink raw reply
* WARNING: held lock freed in nr_release
From: syzbot @ 2019-07-17 8:58 UTC (permalink / raw)
To: davem, linux-hams, linux-kernel, netdev, ralf, syzkaller-bugs
Hello,
syzbot found the following crash on:
HEAD commit: 3eb51486 Merge tag 'arc-5.3-rc1' of git://git.kernel.org/p..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=144104d0600000
kernel config: https://syzkaller.appspot.com/x/.config?x=1044f14a33f8bb44
dashboard link: https://syzkaller.appspot.com/bug?extid=a34e5f3d0300163f0c87
compiler: gcc (GCC) 9.0.0 20181231 (experimental)
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=174ef948600000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=12475834600000
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+a34e5f3d0300163f0c87@syzkaller.appspotmail.com
=========================
WARNING: held lock freed!
5.2.0+ #66 Not tainted
-------------------------
syz-executor290/9125 is freeing memory ffff8880936e02c0-ffff8880936e0abf,
with a lock still held there!
000000005bf1c8ae (sk_lock-AF_NETROM){+.+.}, at: lock_sock
include/net/sock.h:1522 [inline]
000000005bf1c8ae (sk_lock-AF_NETROM){+.+.}, at: nr_release+0x130/0x3e0
net/netrom/af_netrom.c:522
2 locks held by syz-executor290/9125:
#0: 0000000027c540ab (&sb->s_type->i_mutex_key#12){+.+.}, at: inode_lock
include/linux/fs.h:778 [inline]
#0: 0000000027c540ab (&sb->s_type->i_mutex_key#12){+.+.}, at:
__sock_release+0x89/0x280 net/socket.c:585
#1: 000000005bf1c8ae (sk_lock-AF_NETROM){+.+.}, at: lock_sock
include/net/sock.h:1522 [inline]
#1: 000000005bf1c8ae (sk_lock-AF_NETROM){+.+.}, at: nr_release+0x130/0x3e0
net/netrom/af_netrom.c:522
stack backtrace:
CPU: 0 PID: 9125 Comm: syz-executor290 Not tainted 5.2.0+ #66
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+0x172/0x1f0 lib/dump_stack.c:113
print_freed_lock_bug kernel/locking/lockdep.c:5185 [inline]
debug_check_no_locks_freed.cold+0x9d/0xa9 kernel/locking/lockdep.c:5218
kfree+0xec/0x2c0 mm/slab.c:3753
sk_prot_free net/core/sock.c:1640 [inline]
__sk_destruct+0x4f7/0x6e0 net/core/sock.c:1726
sk_destruct+0x86/0xa0 net/core/sock.c:1734
__sk_free+0xfb/0x360 net/core/sock.c:1745
sk_free+0x42/0x50 net/core/sock.c:1756
sock_put include/net/sock.h:1725 [inline]
nr_destroy_socket+0x3ea/0x4b0 net/netrom/af_netrom.c:288
nr_release+0x347/0x3e0 net/netrom/af_netrom.c:530
__sock_release+0xce/0x280 net/socket.c:586
sock_close+0x1e/0x30 net/socket.c:1264
__fput+0x2ff/0x890 fs/file_table.c:280
____fput+0x16/0x20 fs/file_table.c:313
task_work_run+0x145/0x1c0 kernel/task_work.c:113
exit_task_work include/linux/task_work.h:22 [inline]
do_exit+0x904/0x2eb0 kernel/exit.c:877
do_group_exit+0x135/0x370 kernel/exit.c:981
get_signal+0x48a/0x2510 kernel/signal.c:2728
do_signal+0x87/0x1670 arch/x86/kernel/signal.c:815
exit_to_usermode_loop+0x286/0x380 arch/x86/entry/common.c:159
prepare_exit_to_usermode arch/x86/entry/common.c:194 [inline]
syscall_return_slowpath arch/x86/entry/common.c:274 [inline]
do_syscall_64+0x5a9/0x6a0 arch/x86/entry/common.c:299
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x442609
Code: Bad RIP value.
RSP: 002b:00007ffc16869ec8 EFLAGS: 00000246 ORIG_RAX: 000000000000002b
RAX: 0000000000000003 RBX: 0000000000000003 RCX: 0000000000442609
RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000004
RBP: 0000000000017e2c R08: 0000000000000003 R09: 0000000400000009
R10: 0000000400000009 R11: 0000000000000246 R12: 0000000000403440
R13: 00000000004034d0 R14: 0000000000000000 R15: 0000000000000000
==================================================================
BUG: KASAN: use-after-free in debug_spin_lock_before
kernel/locking/spinlock_debug.c:83 [inline]
BUG: KASAN: use-after-free in do_raw_spin_lock+0x28a/0x2e0
kernel/locking/spinlock_debug.c:112
Read of size 4 at addr ffff8880936e034c by task syz-executor290/9125
CPU: 0 PID: 9125 Comm: syz-executor290 Not tainted 5.2.0+ #66
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+0x172/0x1f0 lib/dump_stack.c:113
print_address_description.cold+0xd4/0x306 mm/kasan/report.c:351
__kasan_report.cold+0x1b/0x36 mm/kasan/report.c:482
kasan_report+0x12/0x20 mm/kasan/common.c:612
__asan_report_load4_noabort+0x14/0x20 mm/kasan/generic_report.c:131
debug_spin_lock_before kernel/locking/spinlock_debug.c:83 [inline]
do_raw_spin_lock+0x28a/0x2e0 kernel/locking/spinlock_debug.c:112
__raw_spin_lock_bh include/linux/spinlock_api_smp.h:136 [inline]
_raw_spin_lock_bh+0x3b/0x50 kernel/locking/spinlock.c:175
spin_lock_bh include/linux/spinlock.h:343 [inline]
release_sock+0x20/0x1c0 net/core/sock.c:2932
nr_release+0x303/0x3e0 net/netrom/af_netrom.c:553
__sock_release+0xce/0x280 net/socket.c:586
sock_close+0x1e/0x30 net/socket.c:1264
__fput+0x2ff/0x890 fs/file_table.c:280
____fput+0x16/0x20 fs/file_table.c:313
task_work_run+0x145/0x1c0 kernel/task_work.c:113
exit_task_work include/linux/task_work.h:22 [inline]
do_exit+0x904/0x2eb0 kernel/exit.c:877
do_group_exit+0x135/0x370 kernel/exit.c:981
get_signal+0x48a/0x2510 kernel/signal.c:2728
do_signal+0x87/0x1670 arch/x86/kernel/signal.c:815
exit_to_usermode_loop+0x286/0x380 arch/x86/entry/common.c:159
prepare_exit_to_usermode arch/x86/entry/common.c:194 [inline]
syscall_return_slowpath arch/x86/entry/common.c:274 [inline]
do_syscall_64+0x5a9/0x6a0 arch/x86/entry/common.c:299
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x442609
Code: Bad RIP value.
RSP: 002b:00007ffc16869ec8 EFLAGS: 00000246 ORIG_RAX: 000000000000002b
RAX: 0000000000000003 RBX: 0000000000000003 RCX: 0000000000442609
RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000004
RBP: 0000000000017e2c R08: 0000000000000003 R09: 0000000400000009
R10: 0000000400000009 R11: 0000000000000246 R12: 0000000000403440
R13: 00000000004034d0 R14: 0000000000000000 R15: 0000000000000000
Allocated by task 9130:
save_stack+0x23/0x90 mm/kasan/common.c:69
set_track mm/kasan/common.c:77 [inline]
__kasan_kmalloc mm/kasan/common.c:487 [inline]
__kasan_kmalloc.constprop.0+0xcf/0xe0 mm/kasan/common.c:460
kasan_kmalloc+0x9/0x10 mm/kasan/common.c:501
__do_kmalloc mm/slab.c:3655 [inline]
__kmalloc+0x163/0x780 mm/slab.c:3664
kmalloc include/linux/slab.h:557 [inline]
sk_prot_alloc+0x23a/0x310 net/core/sock.c:1603
sk_alloc+0x39/0xf70 net/core/sock.c:1657
nr_make_new net/netrom/af_netrom.c:476 [inline]
nr_rx_frame+0x733/0x1e80 net/netrom/af_netrom.c:959
nr_loopback_timer+0x7b/0x170 net/netrom/nr_loopback.c:59
call_timer_fn+0x1ac/0x780 kernel/time/timer.c:1322
expire_timers kernel/time/timer.c:1366 [inline]
__run_timers kernel/time/timer.c:1685 [inline]
__run_timers kernel/time/timer.c:1653 [inline]
run_timer_softirq+0x697/0x17a0 kernel/time/timer.c:1698
__do_softirq+0x262/0x98c kernel/softirq.c:292
Freed by task 9125:
save_stack+0x23/0x90 mm/kasan/common.c:69
set_track mm/kasan/common.c:77 [inline]
__kasan_slab_free+0x102/0x150 mm/kasan/common.c:449
kasan_slab_free+0xe/0x10 mm/kasan/common.c:457
__cache_free mm/slab.c:3425 [inline]
kfree+0x10a/0x2c0 mm/slab.c:3756
sk_prot_free net/core/sock.c:1640 [inline]
__sk_destruct+0x4f7/0x6e0 net/core/sock.c:1726
sk_destruct+0x86/0xa0 net/core/sock.c:1734
__sk_free+0xfb/0x360 net/core/sock.c:1745
sk_free+0x42/0x50 net/core/sock.c:1756
sock_put include/net/sock.h:1725 [inline]
nr_destroy_socket+0x3ea/0x4b0 net/netrom/af_netrom.c:288
nr_release+0x347/0x3e0 net/netrom/af_netrom.c:530
__sock_release+0xce/0x280 net/socket.c:586
sock_close+0x1e/0x30 net/socket.c:1264
__fput+0x2ff/0x890 fs/file_table.c:280
____fput+0x16/0x20 fs/file_table.c:313
task_work_run+0x145/0x1c0 kernel/task_work.c:113
exit_task_work include/linux/task_work.h:22 [inline]
do_exit+0x904/0x2eb0 kernel/exit.c:877
do_group_exit+0x135/0x370 kernel/exit.c:981
get_signal+0x48a/0x2510 kernel/signal.c:2728
do_signal+0x87/0x1670 arch/x86/kernel/signal.c:815
exit_to_usermode_loop+0x286/0x380 arch/x86/entry/common.c:159
prepare_exit_to_usermode arch/x86/entry/common.c:194 [inline]
syscall_return_slowpath arch/x86/entry/common.c:274 [inline]
do_syscall_64+0x5a9/0x6a0 arch/x86/entry/common.c:299
entry_SYSCALL_64_after_hwframe+0x49/0xbe
The buggy address belongs to the object at ffff8880936e02c0
which belongs to the cache kmalloc-2k of size 2048
The buggy address is located 140 bytes inside of
2048-byte region [ffff8880936e02c0, ffff8880936e0ac0)
The buggy address belongs to the page:
page:ffffea00024db800 refcount:1 mapcount:0 mapping:ffff8880aa400e00
index:0x0 compound_mapcount: 0
flags: 0x1fffc0000010200(slab|head)
raw: 01fffc0000010200 ffffea000257f988 ffffea00024ef988 ffff8880aa400e00
raw: 0000000000000000 ffff8880936e02c0 0000000100000003 0000000000000000
page dumped because: kasan: bad access detected
Memory state around the buggy address:
ffff8880936e0200: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
ffff8880936e0280: fc fc fc fc fc fc fc fc fb fb fb fb fb fb fb fb
> ffff8880936e0300: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
^
ffff8880936e0380: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
ffff8880936e0400: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
==================================================================
---
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
* kernel panic: stack is corrupted in pointer
From: syzbot @ 2019-07-17 8:58 UTC (permalink / raw)
To: airlied, alexander.deucher, amd-gfx, ast, christian.koenig,
daniel, david1.zhou, dri-devel, leo.liu, linux-kernel, netdev,
syzkaller-bugs
Hello,
syzbot found the following crash on:
HEAD commit: 1438cde7 Add linux-next specific files for 20190716
git tree: linux-next
console output: https://syzkaller.appspot.com/x/log.txt?x=13988058600000
kernel config: https://syzkaller.appspot.com/x/.config?x=3430a151e1452331
dashboard link: https://syzkaller.appspot.com/bug?extid=79f5f028005a77ecb6bb
compiler: gcc (GCC) 9.0.0 20181231 (experimental)
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=111fc8afa00000
The bug was bisected to:
commit 96a5d8d4915f3e241ebb48d5decdd110ab9c7dcf
Author: Leo Liu <leo.liu@amd.com>
Date: Fri Jul 13 15:26:28 2018 +0000
drm/amdgpu: Make sure IB tests flushed after IP resume
bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=14a46200600000
final crash: https://syzkaller.appspot.com/x/report.txt?x=16a46200600000
console output: https://syzkaller.appspot.com/x/log.txt?x=12a46200600000
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+79f5f028005a77ecb6bb@syzkaller.appspotmail.com
Fixes: 96a5d8d4915f ("drm/amdgpu: Make sure IB tests flushed after IP
resume")
Kernel panic - not syncing: stack-protector: Kernel stack is corrupted in:
pointer+0x702/0x750 lib/vsprintf.c:2187
Shutting down cpus with NMI
Kernel Offset: disabled
---
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.
For information about bisection process see: https://goo.gl/tpsmEJ#bisection
syzbot can test patches for this bug, for details see:
https://goo.gl/tpsmEJ#testing-patches
^ permalink raw reply
* KASAN: use-after-free Write in check_noncircular
From: syzbot @ 2019-07-17 8:58 UTC (permalink / raw)
To: ast, daniel, jmorris, john.fastabend, linux-kernel,
linux-security-module, netdev, penguin-kernel, serge,
syzkaller-bugs, takedakn
Hello,
syzbot found the following crash on:
HEAD commit: 9637d517 Merge tag 'for-linus-20190715' of git://git.kerne..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=12f42e1fa00000
kernel config: https://syzkaller.appspot.com/x/.config?x=88095c4f62402bcd
dashboard link: https://syzkaller.appspot.com/bug?extid=f5ceb7c55f59455035ca
compiler: clang version 9.0.0 (/home/glider/llvm/clang
80fee25776c2fb61e74c1ecb1a523375c2500b69)
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=12cfbe1fa00000
The bug was bisected to:
commit e9db4ef6bf4ca9894bb324c76e01b8f1a16b2650
Author: John Fastabend <john.fastabend@gmail.com>
Date: Sat Jun 30 13:17:47 2018 +0000
bpf: sockhash fix omitted bucket lock in sock_close
bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=109c3078600000
final crash: https://syzkaller.appspot.com/x/report.txt?x=129c3078600000
console output: https://syzkaller.appspot.com/x/log.txt?x=149c3078600000
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+f5ceb7c55f59455035ca@syzkaller.appspotmail.com
Fixes: e9db4ef6bf4c ("bpf: sockhash fix omitted bucket lock in sock_close")
==================================================================
BUG: KASAN: use-after-free in check_noncircular+0x91/0x560
kernel/locking/lockdep.c:1722
Write of size 56 at addr ffff888089815160 by task syz-executor.4/8772
CPU: 1 PID: 8772 Comm: syz-executor.4 Not tainted 5.2.0+ #31
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Call Trace:
Allocated by task 8457:
save_stack mm/kasan/common.c:69 [inline]
set_track mm/kasan/common.c:77 [inline]
__kasan_kmalloc+0x11c/0x1b0 mm/kasan/common.c:487
kasan_kmalloc+0x9/0x10 mm/kasan/common.c:501
kmem_cache_alloc_trace+0x221/0x2f0 mm/slab.c:3550
kmalloc include/linux/slab.h:552 [inline]
tomoyo_print_header security/tomoyo/audit.c:156 [inline]
tomoyo_init_log+0x176/0x1f20 security/tomoyo/audit.c:255
tomoyo_supervisor+0x39c/0x13f0 security/tomoyo/common.c:2095
tomoyo_audit_path_log security/tomoyo/file.c:168 [inline]
tomoyo_path_permission security/tomoyo/file.c:587 [inline]
tomoyo_check_open_permission+0x488/0x9e0 security/tomoyo/file.c:777
tomoyo_file_open+0x141/0x190 security/tomoyo/tomoyo.c:319
security_file_open+0x65/0x2f0 security/security.c:1457
do_dentry_open+0x397/0x1060 fs/open.c:765
vfs_open+0x73/0x80 fs/open.c:887
do_last fs/namei.c:3416 [inline]
path_openat+0x136d/0x4400 fs/namei.c:3533
do_filp_open+0x1f7/0x430 fs/namei.c:3563
do_sys_open+0x343/0x620 fs/open.c:1070
__do_sys_open fs/open.c:1088 [inline]
__se_sys_open fs/open.c:1083 [inline]
__x64_sys_open+0x87/0x90 fs/open.c:1083
do_syscall_64+0xfe/0x140 arch/x86/entry/common.c:296
entry_SYSCALL_64_after_hwframe+0x49/0xbe
Freed by task 8457:
save_stack mm/kasan/common.c:69 [inline]
set_track mm/kasan/common.c:77 [inline]
__kasan_slab_free+0x12a/0x1e0 mm/kasan/common.c:449
kasan_slab_free+0xe/0x10 mm/kasan/common.c:457
__cache_free mm/slab.c:3425 [inline]
kfree+0x115/0x200 mm/slab.c:3756
tomoyo_init_log+0x1bf7/0x1f20 security/tomoyo/audit.c:294
tomoyo_supervisor+0x39c/0x13f0 security/tomoyo/common.c:2095
tomoyo_audit_path_log security/tomoyo/file.c:168 [inline]
tomoyo_path_permission security/tomoyo/file.c:587 [inline]
tomoyo_check_open_permission+0x488/0x9e0 security/tomoyo/file.c:777
tomoyo_file_open+0x141/0x190 security/tomoyo/tomoyo.c:319
security_file_open+0x65/0x2f0 security/security.c:1457
do_dentry_open+0x397/0x1060 fs/open.c:765
vfs_open+0x73/0x80 fs/open.c:887
do_last fs/namei.c:3416 [inline]
path_openat+0x136d/0x4400 fs/namei.c:3533
do_filp_open+0x1f7/0x430 fs/namei.c:3563
do_sys_open+0x343/0x620 fs/open.c:1070
__do_sys_open fs/open.c:1088 [inline]
__se_sys_open fs/open.c:1083 [inline]
__x64_sys_open+0x87/0x90 fs/open.c:1083
do_syscall_64+0xfe/0x140 arch/x86/entry/common.c:296
entry_SYSCALL_64_after_hwframe+0x49/0xbe
The buggy address belongs to the object at ffff8880898146c0
which belongs to the cache kmalloc-4k of size 4096
The buggy address is located 2720 bytes inside of
4096-byte region [ffff8880898146c0, ffff8880898156c0)
The buggy address belongs to the page:
page:ffffea0002260500 refcount:1 mapcount:0 mapping:ffff8880aa402000
index:0x0 compound_mapcount: 0
flags: 0x1fffc0000010200(slab|head)
raw: 01fffc0000010200 ffffea0002263b08 ffffea0002916d08 ffff8880aa402000
raw: 0000000000000000 ffff8880898146c0 0000000100000001 0000000000000000
page dumped because: kasan: bad access detected
Memory state around the buggy address:
ffff888089815000: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
ffff888089815080: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> ffff888089815100: fb fb fb fb f1 f1 f1 f1 00 f2 f2 f2 fb fb fb fb
^
ffff888089815180: fb fb fb f3 f3 f3 f3 f3 fb fb fb fb fb fb fb fb
ffff888089815200: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
==================================================================
---
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.
For information about bisection process see: https://goo.gl/tpsmEJ#bisection
syzbot can test patches for this bug, for details see:
https://goo.gl/tpsmEJ#testing-patches
^ permalink raw reply
* Re: [PATCH] net/mlx5: Replace kfree with kvfree
From: Eric Dumazet @ 2019-07-17 8:33 UTC (permalink / raw)
To: Chuhong Yuan; +Cc: Saeed Mahameed, Leon Romanovsky, David S . Miller, netdev
In-Reply-To: <20190717080322.13631-1-hslester96@gmail.com>
On 7/17/19 10:03 AM, Chuhong Yuan wrote:
> Variable allocated by kvmalloc should not be freed by kfree.
> Because it may be allocated by vmalloc.
> So replace kfree with kvfree here.
>
> Signed-off-by: Chuhong Yuan <hslester96@gmail.com>
> ---
Please add corresponding Fixes: tag, thanks !
> drivers/net/ethernet/mellanox/mlx5/core/health.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/mellanox/mlx5/core/health.c b/drivers/net/ethernet/mellanox/mlx5/core/health.c
> index 2fe6923f7ce0..9314777d99e3 100644
> --- a/drivers/net/ethernet/mellanox/mlx5/core/health.c
> +++ b/drivers/net/ethernet/mellanox/mlx5/core/health.c
> @@ -597,7 +597,7 @@ mlx5_fw_fatal_reporter_dump(struct devlink_health_reporter *reporter,
> err = devlink_fmsg_arr_pair_nest_end(fmsg);
>
> free_data:
> - kfree(cr_data);
> + kvfree(cr_data);
> return err;
> }
>
>
^ permalink raw reply
* Re: [PATCH net] be2net: Signal that the device cannot transmit during reconfiguration
From: Benjamin Poirier @ 2019-07-17 8:23 UTC (permalink / raw)
To: Firo Yang
Cc: David Miller, Ajit Khaparde, Sathya Perla, Somnath Kotur,
Sriharsha Basavapatna, Saeed Mahameed, netdev@vger.kernel.org
In-Reply-To: <CH2PR18MB31898E033896F9760D36BFF288C90@CH2PR18MB3189.namprd18.prod.outlook.com>
On 2019/07/17 13:23, Firo Yang wrote:
> I think there is a problem if dev_watchdog() is triggered before netif_carrier_off(). dev_watchdog() might call ->ndo_tx_timeout(), i.e. be_tx_timeout(), if txq timeout happens. Thus be_tx_timeout() could still be able to access the memory which is being freed by be_update_queues().
Good point. That's a separate problem which would occur in case of real
tx timeout. How about this followup change:
--- a/drivers/net/ethernet/emulex/benet/be_main.c
+++ b/drivers/net/ethernet/emulex/benet/be_main.c
@@ -4698,8 +4698,13 @@ int be_update_queues(struct be_adapter *adapter)
int status;
if (netif_running(netdev)) {
+ /* be_tx_timeout() must not run concurrently with this
+ * function, synchronize with an already-running dev_watchdog
+ */
+ netif_tx_lock_bh(netdev);
/* device cannot transmit now, avoid dev_watchdog timeouts */
netif_carrier_off(netdev);
+ netif_tx_unlock_bh(netdev);
be_close(netdev);
}
^ permalink raw reply
* Re: [PATCH 0/2] arm/arm64: Add support for function error injection
From: Leo Yan @ 2019-07-17 8:14 UTC (permalink / raw)
To: Masami Hiramatsu
Cc: Russell King, Oleg Nesterov, Catalin Marinas, Will Deacon,
Alexei Starovoitov, Daniel Borkmann, Martin KaFai Lau, Song Liu,
Yonghong Song, Arnd Bergmann, linux-arm-kernel, linux-kernel,
netdev, bpf, Justin He
In-Reply-To: <20190717165222.62e02b99ebc16e23c3b81de2@kernel.org>
On Wed, Jul 17, 2019 at 04:52:22PM +0900, Masami Hiramatsu wrote:
> On Tue, 16 Jul 2019 19:12:59 +0800
> Leo Yan <leo.yan@linaro.org> wrote:
>
> > This small patch set is to add support for function error injection;
> > this can be used to eanble more advanced debugging feature, e.g.
> > CONFIG_BPF_KPROBE_OVERRIDE.
> >
> > I only tested the first patch on arm64 platform Juno-r2 with below
> > steps; the second patch is for arm arch, but I absent the platform
> > for the testing so only pass compilation.
> >
> > - Enable kernel configuration:
> > CONFIG_BPF_KPROBE_OVERRIDE
> > CONFIG_BTRFS_FS
> > CONFIG_BPF_EVENTS=y
> > CONFIG_KPROBES=y
> > CONFIG_KPROBE_EVENTS=y
> > CONFIG_BPF_KPROBE_OVERRIDE=y
> > - Build samples/bpf on Juno-r2 board with Debian rootFS:
> > # cd $kernel
> > # make headers_install
> > # make samples/bpf/ LLC=llc-7 CLANG=clang-7
> > - Run the sample tracex7:
> > # ./tracex7 /dev/sdb1
> > [ 1975.211781] BTRFS error (device (efault)): open_ctree failed
> > mount: /mnt/linux-kernel/linux-cs-dev/samples/bpf/tmpmnt: mount(2) system call failed: Cannot allocate memory.
>
> This series looks good to me from the view point of override usage :)
>
> Reviewed-by: Masami Hiramatsu <mhiramat@kernel.org>
>
> For this series.
>
> Thank you,
Thank you for reviewing, Masami.
> >
> >
> > Leo Yan (2):
> > arm64: Add support for function error injection
> > arm: Add support for function error injection
> >
> > arch/arm/Kconfig | 1 +
> > arch/arm/include/asm/error-injection.h | 13 +++++++++++++
> > arch/arm/include/asm/ptrace.h | 5 +++++
> > arch/arm/lib/Makefile | 2 ++
> > arch/arm/lib/error-inject.c | 19 +++++++++++++++++++
> > arch/arm64/Kconfig | 1 +
> > arch/arm64/include/asm/error-injection.h | 13 +++++++++++++
> > arch/arm64/include/asm/ptrace.h | 5 +++++
> > arch/arm64/lib/Makefile | 2 ++
> > arch/arm64/lib/error-inject.c | 19 +++++++++++++++++++
> > 10 files changed, 80 insertions(+)
> > create mode 100644 arch/arm/include/asm/error-injection.h
> > create mode 100644 arch/arm/lib/error-inject.c
> > create mode 100644 arch/arm64/include/asm/error-injection.h
> > create mode 100644 arch/arm64/lib/error-inject.c
> >
> > --
> > 2.17.1
> >
>
>
> --
> Masami Hiramatsu <mhiramat@kernel.org>
^ permalink raw reply
* Re: memory leak in llc_ui_create (2)
From: syzbot @ 2019-07-17 8:09 UTC (permalink / raw)
To: davem, linux-kernel, netdev, syzkaller-bugs, xiyou.wangcong
In-Reply-To: <000000000000058a0f058bd50068@google.com>
syzbot has found a reproducer for the following crash on:
HEAD commit: 3eb51486 Merge tag 'arc-5.3-rc1' of git://git.kernel.org/p..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=15ca2548600000
kernel config: https://syzkaller.appspot.com/x/.config?x=cd93db730dc81f01
dashboard link: https://syzkaller.appspot.com/bug?extid=6bf095f9becf5efef645
compiler: gcc (GCC) 9.0.0 20181231 (experimental)
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=174254d0600000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=13bb0d84600000
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+6bf095f9becf5efef645@syzkaller.appspotmail.com
executing program
executing program
executing program
executing program
BUG: memory leak
unreferenced object 0xffff88811e6f1800 (size 2048):
comm "syz-executor273", pid 7002, jiffies 4294943426 (age 13.700s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
1a 00 07 40 00 00 00 00 00 00 00 00 00 00 00 00 ...@............
backtrace:
[<0000000014a2e1ad>] kmemleak_alloc_recursive
include/linux/kmemleak.h:43 [inline]
[<0000000014a2e1ad>] slab_post_alloc_hook mm/slab.h:522 [inline]
[<0000000014a2e1ad>] slab_alloc mm/slab.c:3319 [inline]
[<0000000014a2e1ad>] __do_kmalloc mm/slab.c:3653 [inline]
[<0000000014a2e1ad>] __kmalloc+0x169/0x300 mm/slab.c:3664
[<00000000ba2cba1e>] kmalloc include/linux/slab.h:557 [inline]
[<00000000ba2cba1e>] sk_prot_alloc+0x112/0x170 net/core/sock.c:1603
[<00000000f1d9d4df>] sk_alloc+0x35/0x2f0 net/core/sock.c:1657
[<00000000d33ee81e>] llc_sk_alloc+0x35/0x170 net/llc/llc_conn.c:950
[<00000000f9f972a8>] llc_ui_create+0x7b/0x150 net/llc/af_llc.c:173
[<00000000d9cdf850>] __sock_create+0x164/0x250 net/socket.c:1414
[<00000000ca906883>] sock_create net/socket.c:1465 [inline]
[<00000000ca906883>] __sys_socket+0x69/0x110 net/socket.c:1507
[<00000000e00ea1b3>] __do_sys_socket net/socket.c:1516 [inline]
[<00000000e00ea1b3>] __se_sys_socket net/socket.c:1514 [inline]
[<00000000e00ea1b3>] __x64_sys_socket+0x1e/0x30 net/socket.c:1514
[<00000000dfc2afaa>] do_syscall_64+0x76/0x1a0
arch/x86/entry/common.c:296
[<00000000702ee9bf>] entry_SYSCALL_64_after_hwframe+0x44/0xa9
BUG: memory leak
unreferenced object 0xffff88810acb0a00 (size 32):
comm "syz-executor273", pid 7002, jiffies 4294943426 (age 13.700s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
e1 00 00 00 03 00 00 00 0f 00 00 00 00 00 00 00 ................
backtrace:
[<000000006d098b11>] kmemleak_alloc_recursive
include/linux/kmemleak.h:43 [inline]
[<000000006d098b11>] slab_post_alloc_hook mm/slab.h:522 [inline]
[<000000006d098b11>] slab_alloc mm/slab.c:3319 [inline]
[<000000006d098b11>] kmem_cache_alloc_trace+0x145/0x2c0 mm/slab.c:3548
[<00000000f45530b8>] kmalloc include/linux/slab.h:552 [inline]
[<00000000f45530b8>] kzalloc include/linux/slab.h:748 [inline]
[<00000000f45530b8>] selinux_sk_alloc_security+0x48/0xb0
security/selinux/hooks.c:5073
[<000000003ff46bd8>] security_sk_alloc+0x49/0x70
security/security.c:2029
[<000000007c679d89>] sk_prot_alloc+0x12d/0x170 net/core/sock.c:1606
[<00000000f1d9d4df>] sk_alloc+0x35/0x2f0 net/core/sock.c:1657
[<00000000d33ee81e>] llc_sk_alloc+0x35/0x170 net/llc/llc_conn.c:950
[<00000000f9f972a8>] llc_ui_create+0x7b/0x150 net/llc/af_llc.c:173
[<00000000d9cdf850>] __sock_create+0x164/0x250 net/socket.c:1414
[<00000000ca906883>] sock_create net/socket.c:1465 [inline]
[<00000000ca906883>] __sys_socket+0x69/0x110 net/socket.c:1507
[<00000000e00ea1b3>] __do_sys_socket net/socket.c:1516 [inline]
[<00000000e00ea1b3>] __se_sys_socket net/socket.c:1514 [inline]
[<00000000e00ea1b3>] __x64_sys_socket+0x1e/0x30 net/socket.c:1514
[<00000000dfc2afaa>] do_syscall_64+0x76/0x1a0
arch/x86/entry/common.c:296
[<00000000702ee9bf>] entry_SYSCALL_64_after_hwframe+0x44/0xa9
BUG: memory leak
unreferenced object 0xffff88812ad27400 (size 224):
comm "syz-executor273", pid 7002, jiffies 4294943426 (age 13.700s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 50 a3 2a 81 88 ff ff 00 18 6f 1e 81 88 ff ff .P.*......o.....
backtrace:
[<000000003b74814c>] kmemleak_alloc_recursive
include/linux/kmemleak.h:43 [inline]
[<000000003b74814c>] slab_post_alloc_hook mm/slab.h:522 [inline]
[<000000003b74814c>] slab_alloc_node mm/slab.c:3262 [inline]
[<000000003b74814c>] kmem_cache_alloc_node+0x163/0x2f0 mm/slab.c:3574
[<000000005ec232c8>] __alloc_skb+0x6e/0x210 net/core/skbuff.c:197
[<00000000051d15bd>] alloc_skb include/linux/skbuff.h:1055 [inline]
[<00000000051d15bd>] alloc_skb_with_frags+0x5f/0x250
net/core/skbuff.c:5628
[<000000006b5faf6f>] sock_alloc_send_pskb+0x269/0x2a0
net/core/sock.c:2223
[<00000000c32ec5bd>] sock_alloc_send_skb+0x32/0x40 net/core/sock.c:2240
[<00000000068e05dd>] llc_ui_sendmsg+0x10a/0x540 net/llc/af_llc.c:933
[<00000000776b0139>] sock_sendmsg_nosec net/socket.c:633 [inline]
[<00000000776b0139>] sock_sendmsg+0x54/0x70 net/socket.c:653
[<0000000028377a2b>] ___sys_sendmsg+0x393/0x3c0 net/socket.c:2307
[<00000000f74197f6>] __sys_sendmsg+0x80/0xf0 net/socket.c:2352
[<00000000084b8970>] __do_sys_sendmsg net/socket.c:2361 [inline]
[<00000000084b8970>] __se_sys_sendmsg net/socket.c:2359 [inline]
[<00000000084b8970>] __x64_sys_sendmsg+0x23/0x30 net/socket.c:2359
[<00000000dfc2afaa>] do_syscall_64+0x76/0x1a0
arch/x86/entry/common.c:296
[<00000000702ee9bf>] entry_SYSCALL_64_after_hwframe+0x44/0xa9
BUG: memory leak
unreferenced object 0xffff8881137ed400 (size 512):
comm "syz-executor273", pid 7002, jiffies 4294943426 (age 13.700s)
hex dump (first 32 bytes):
7a 0f 00 00 00 00 00 00 2f 31 37 20 30 38 3a 30 z......./17 08:0
35 3a 32 39 00 c6 bf 81 03 00 69 6c 65 3d 30 20 5:29......ile=0
backtrace:
[<00000000f10c8cea>] kmemleak_alloc_recursive
include/linux/kmemleak.h:43 [inline]
[<00000000f10c8cea>] slab_post_alloc_hook mm/slab.h:522 [inline]
[<00000000f10c8cea>] slab_alloc_node mm/slab.c:3262 [inline]
[<00000000f10c8cea>] kmem_cache_alloc_node_trace+0x161/0x2f0
mm/slab.c:3592
[<0000000082c86374>] __do_kmalloc_node mm/slab.c:3614 [inline]
[<0000000082c86374>] __kmalloc_node_track_caller+0x38/0x50
mm/slab.c:3629
[<000000009e316c15>] __kmalloc_reserve.isra.0+0x40/0xb0
net/core/skbuff.c:141
[<00000000817024aa>] __alloc_skb+0xa0/0x210 net/core/skbuff.c:209
[<00000000051d15bd>] alloc_skb include/linux/skbuff.h:1055 [inline]
[<00000000051d15bd>] alloc_skb_with_frags+0x5f/0x250
net/core/skbuff.c:5628
[<000000006b5faf6f>] sock_alloc_send_pskb+0x269/0x2a0
net/core/sock.c:2223
[<00000000c32ec5bd>] sock_alloc_send_skb+0x32/0x40 net/core/sock.c:2240
[<00000000068e05dd>] llc_ui_sendmsg+0x10a/0x540 net/llc/af_llc.c:933
[<00000000776b0139>] sock_sendmsg_nosec net/socket.c:633 [inline]
[<00000000776b0139>] sock_sendmsg+0x54/0x70 net/socket.c:653
[<0000000028377a2b>] ___sys_sendmsg+0x393/0x3c0 net/socket.c:2307
[<00000000f74197f6>] __sys_sendmsg+0x80/0xf0 net/socket.c:2352
[<00000000084b8970>] __do_sys_sendmsg net/socket.c:2361 [inline]
[<00000000084b8970>] __se_sys_sendmsg net/socket.c:2359 [inline]
[<00000000084b8970>] __x64_sys_sendmsg+0x23/0x30 net/socket.c:2359
[<00000000dfc2afaa>] do_syscall_64+0x76/0x1a0
arch/x86/entry/common.c:296
[<00000000702ee9bf>] entry_SYSCALL_64_after_hwframe+0x44/0xa9
^ permalink raw reply
* [PATCH] net/mlx5: Replace kfree with kvfree
From: Chuhong Yuan @ 2019-07-17 8:03 UTC (permalink / raw)
Cc: Saeed Mahameed, Leon Romanovsky, David S . Miller, netdev,
linux-rdma, linux-kernel, Chuhong Yuan
Variable allocated by kvmalloc should not be freed by kfree.
Because it may be allocated by vmalloc.
So replace kfree with kvfree here.
Signed-off-by: Chuhong Yuan <hslester96@gmail.com>
---
drivers/net/ethernet/mellanox/mlx5/core/health.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/health.c b/drivers/net/ethernet/mellanox/mlx5/core/health.c
index 2fe6923f7ce0..9314777d99e3 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/health.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/health.c
@@ -597,7 +597,7 @@ mlx5_fw_fatal_reporter_dump(struct devlink_health_reporter *reporter,
err = devlink_fmsg_arr_pair_nest_end(fmsg);
free_data:
- kfree(cr_data);
+ kvfree(cr_data);
return err;
}
--
2.20.1
^ permalink raw reply related
* Re: [PATCH 0/2] arm/arm64: Add support for function error injection
From: Masami Hiramatsu @ 2019-07-17 7:52 UTC (permalink / raw)
To: Leo Yan
Cc: Russell King, Oleg Nesterov, Catalin Marinas, Will Deacon,
Alexei Starovoitov, Daniel Borkmann, Martin KaFai Lau, Song Liu,
Yonghong Song, Arnd Bergmann, linux-arm-kernel, linux-kernel,
netdev, bpf, Justin He
In-Reply-To: <20190716111301.1855-1-leo.yan@linaro.org>
On Tue, 16 Jul 2019 19:12:59 +0800
Leo Yan <leo.yan@linaro.org> wrote:
> This small patch set is to add support for function error injection;
> this can be used to eanble more advanced debugging feature, e.g.
> CONFIG_BPF_KPROBE_OVERRIDE.
>
> I only tested the first patch on arm64 platform Juno-r2 with below
> steps; the second patch is for arm arch, but I absent the platform
> for the testing so only pass compilation.
>
> - Enable kernel configuration:
> CONFIG_BPF_KPROBE_OVERRIDE
> CONFIG_BTRFS_FS
> CONFIG_BPF_EVENTS=y
> CONFIG_KPROBES=y
> CONFIG_KPROBE_EVENTS=y
> CONFIG_BPF_KPROBE_OVERRIDE=y
> - Build samples/bpf on Juno-r2 board with Debian rootFS:
> # cd $kernel
> # make headers_install
> # make samples/bpf/ LLC=llc-7 CLANG=clang-7
> - Run the sample tracex7:
> # ./tracex7 /dev/sdb1
> [ 1975.211781] BTRFS error (device (efault)): open_ctree failed
> mount: /mnt/linux-kernel/linux-cs-dev/samples/bpf/tmpmnt: mount(2) system call failed: Cannot allocate memory.
This series looks good to me from the view point of override usage :)
Reviewed-by: Masami Hiramatsu <mhiramat@kernel.org>
For this series.
Thank you,
>
>
> Leo Yan (2):
> arm64: Add support for function error injection
> arm: Add support for function error injection
>
> arch/arm/Kconfig | 1 +
> arch/arm/include/asm/error-injection.h | 13 +++++++++++++
> arch/arm/include/asm/ptrace.h | 5 +++++
> arch/arm/lib/Makefile | 2 ++
> arch/arm/lib/error-inject.c | 19 +++++++++++++++++++
> arch/arm64/Kconfig | 1 +
> arch/arm64/include/asm/error-injection.h | 13 +++++++++++++
> arch/arm64/include/asm/ptrace.h | 5 +++++
> arch/arm64/lib/Makefile | 2 ++
> arch/arm64/lib/error-inject.c | 19 +++++++++++++++++++
> 10 files changed, 80 insertions(+)
> create mode 100644 arch/arm/include/asm/error-injection.h
> create mode 100644 arch/arm/lib/error-inject.c
> create mode 100644 arch/arm64/include/asm/error-injection.h
> create mode 100644 arch/arm64/lib/error-inject.c
>
> --
> 2.17.1
>
--
Masami Hiramatsu <mhiramat@kernel.org>
^ permalink raw reply
* [PATCH v2 2/3] Bluetooth: btusb: Load firmware exclusively for Intel BT
From: Kai-Heng Feng @ 2019-07-17 7:49 UTC (permalink / raw)
To: johannes.berg, emmanuel.grumbach, luciano.coelho, marcel,
johan.hedberg
Cc: linuxwifi, linux-wireless, netdev, linux-bluetooth, linux-kernel,
Kai-Heng Feng
In-Reply-To: <20190717074920.21624-1-kai.heng.feng@canonical.com>
To avoid the firmware loading race between Bluetooth and WiFi on Intel
8260, load firmware exclusively when IWLWIFI is enabled.
BugLink: https://bugs.launchpad.net/bugs/1832988
Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
---
v2:
- Add bug report link.
- Rebase on latest wireless-next.
drivers/bluetooth/btusb.c | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
index 50aed5259c2b..ca7a5757a2ba 100644
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -2272,8 +2272,16 @@ static int btusb_setup_intel_new(struct hci_dev *hdev)
set_bit(BTUSB_DOWNLOADING, &data->flags);
+#if IS_ENABLED(CONFIG_IWLWIFI)
+ btintel_firmware_lock();
+#endif
+
/* Start firmware downloading and get boot parameter */
err = btintel_download_firmware(hdev, fw, &boot_param);
+
+#if IS_ENABLED(CONFIG_IWLWIFI)
+ btintel_firmware_unlock();
+#endif
if (err < 0)
goto done;
--
2.17.1
^ permalink raw reply related
* [PATCH v2 3/3] iwlwifi: Load firmware exclusively for Intel WiFi
From: Kai-Heng Feng @ 2019-07-17 7:49 UTC (permalink / raw)
To: johannes.berg, emmanuel.grumbach, luciano.coelho, marcel,
johan.hedberg
Cc: linuxwifi, linux-wireless, netdev, linux-bluetooth, linux-kernel,
Kai-Heng Feng
In-Reply-To: <20190717074920.21624-1-kai.heng.feng@canonical.com>
To avoid the firmware loading race between Bluetooth and WiFi on Intel
8260, load firmware exclusively when BT_INTEL is enabled.
BugLink: https://bugs.launchpad.net/bugs/1832988
Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
---
v2:
- Add bug report link.
- Rebase on latest wireless-next.
.../net/wireless/intel/iwlwifi/pcie/trans.c | 37 ++++++++++++++++++-
1 file changed, 36 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/intel/iwlwifi/pcie/trans.c b/drivers/net/wireless/intel/iwlwifi/pcie/trans.c
index 602c31b3992a..e10ff847b216 100644
--- a/drivers/net/wireless/intel/iwlwifi/pcie/trans.c
+++ b/drivers/net/wireless/intel/iwlwifi/pcie/trans.c
@@ -72,6 +72,7 @@
#include <linux/pm_runtime.h>
#include <linux/module.h>
#include <linux/wait.h>
+#include <linux/intel-wifi-bt.h>
#include "iwl-drv.h"
#include "iwl-trans.h"
@@ -1335,6 +1336,10 @@ static int iwl_trans_pcie_start_fw(struct iwl_trans *trans,
bool hw_rfkill;
int ret;
+#if IS_ENABLED(CONFIG_BT_INTEL)
+ void (*firmware_lock_func)(void);
+ void (*firmware_unlock_func)(void);
+#endif
/* This may fail if AMT took ownership of the device */
if (iwl_pcie_prepare_card_hw(trans)) {
IWL_WARN(trans, "Exit HW not ready\n");
@@ -1394,6 +1399,7 @@ static int iwl_trans_pcie_start_fw(struct iwl_trans *trans,
* RF-Kill switch is toggled, we will find out after having loaded
* the firmware and return the proper value to the caller.
*/
+
iwl_enable_fw_load_int(trans);
/* really make sure rfkill handshake bits are cleared */
@@ -1401,8 +1407,37 @@ static int iwl_trans_pcie_start_fw(struct iwl_trans *trans,
iwl_write32(trans, CSR_UCODE_DRV_GP1_CLR, CSR_UCODE_SW_BIT_RFKILL);
/* Load the given image to the HW */
- if (trans->cfg->device_family >= IWL_DEVICE_FAMILY_8000)
+ if (trans->cfg->device_family >= IWL_DEVICE_FAMILY_8000) {
+#if IS_ENABLED(CONFIG_BT_INTEL)
+ firmware_lock_func = symbol_request(btintel_firmware_lock);
+ firmware_unlock_func = symbol_request(btintel_firmware_unlock);
+ if (!firmware_lock_func || !firmware_unlock_func) {
+ if (firmware_lock_func) {
+ symbol_put(btintel_firmware_lock);
+ firmware_lock_func = NULL;
+ }
+
+ if (firmware_unlock_func) {
+ symbol_put(btintel_firmware_unlock);
+ firmware_unlock_func = NULL;
+ }
+ }
+
+ if (firmware_lock_func)
+ firmware_lock_func();
+#endif
ret = iwl_pcie_load_given_ucode_8000(trans, fw);
+
+#if IS_ENABLED(CONFIG_BT_INTEL)
+ if (firmware_unlock_func) {
+ firmware_unlock_func();
+ symbol_put(btintel_firmware_lock);
+ firmware_lock_func = NULL;
+ symbol_put(btintel_firmware_unlock);
+ firmware_unlock_func = NULL;
+ }
+#endif
+ }
else
ret = iwl_pcie_load_given_ucode(trans, fw);
--
2.17.1
^ permalink raw reply related
* [PATCH v2 1/3] Bluetooth: btintel: Add firmware lock function
From: Kai-Heng Feng @ 2019-07-17 7:49 UTC (permalink / raw)
To: johannes.berg, emmanuel.grumbach, luciano.coelho, marcel,
johan.hedberg
Cc: linuxwifi, linux-wireless, netdev, linux-bluetooth, linux-kernel,
Kai-Heng Feng
When Intel 8260 starts to load Bluetooth firmware and WiFi firmware, by
calling btintel_download_firmware() and iwl_pcie_load_given_ucode_8000()
respectively, the Bluetooth btintel_download_firmware() aborts half way:
[ 11.950216] Bluetooth: hci0: Failed to send firmware data (-38)
Let btusb and iwlwifi load firmwares exclusively can avoid the issue, so
introduce a lock to use in btusb and iwlwifi.
This issue still occurs with latest WiFi and Bluetooth firmwares.
BugLink: https://bugs.launchpad.net/bugs/1832988
Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
---
v2:
- Add bug report link.
- Rebase on latest wireless-next.
drivers/bluetooth/btintel.c | 14 ++++++++++++++
drivers/bluetooth/btintel.h | 10 ++++++++++
include/linux/intel-wifi-bt.h | 8 ++++++++
3 files changed, 32 insertions(+)
create mode 100644 include/linux/intel-wifi-bt.h
diff --git a/drivers/bluetooth/btintel.c b/drivers/bluetooth/btintel.c
index bb99c8653aab..93ab18d6ddad 100644
--- a/drivers/bluetooth/btintel.c
+++ b/drivers/bluetooth/btintel.c
@@ -20,6 +20,8 @@
#define BDADDR_INTEL (&(bdaddr_t) {{0x00, 0x8b, 0x9e, 0x19, 0x03, 0x00}})
+static DEFINE_MUTEX(firmware_lock);
+
int btintel_check_bdaddr(struct hci_dev *hdev)
{
struct hci_rp_read_bd_addr *bda;
@@ -709,6 +711,18 @@ int btintel_download_firmware(struct hci_dev *hdev, const struct firmware *fw,
}
EXPORT_SYMBOL_GPL(btintel_download_firmware);
+void btintel_firmware_lock(void)
+{
+ mutex_lock(&firmware_lock);
+}
+EXPORT_SYMBOL_GPL(btintel_firmware_lock);
+
+void btintel_firmware_unlock(void)
+{
+ mutex_unlock(&firmware_lock);
+}
+EXPORT_SYMBOL_GPL(btintel_firmware_unlock);
+
MODULE_AUTHOR("Marcel Holtmann <marcel@holtmann.org>");
MODULE_DESCRIPTION("Bluetooth support for Intel devices ver " VERSION);
MODULE_VERSION(VERSION);
diff --git a/drivers/bluetooth/btintel.h b/drivers/bluetooth/btintel.h
index 3d846190f2bf..b3682d27d2ee 100644
--- a/drivers/bluetooth/btintel.h
+++ b/drivers/bluetooth/btintel.h
@@ -87,6 +87,8 @@ int btintel_read_boot_params(struct hci_dev *hdev,
struct intel_boot_params *params);
int btintel_download_firmware(struct hci_dev *dev, const struct firmware *fw,
u32 *boot_param);
+void btintel_firmware_lock(void);
+void btintel_firmware_unlock(void);
#else
static inline int btintel_check_bdaddr(struct hci_dev *hdev)
@@ -181,4 +183,12 @@ static inline int btintel_download_firmware(struct hci_dev *dev,
{
return -EOPNOTSUPP;
}
+
+static inline void btintel_firmware_lock(void)
+{
+}
+
+static inline void btintel_firmware_unlock(void)
+{
+}
#endif
diff --git a/include/linux/intel-wifi-bt.h b/include/linux/intel-wifi-bt.h
new file mode 100644
index 000000000000..260ed628d19b
--- /dev/null
+++ b/include/linux/intel-wifi-bt.h
@@ -0,0 +1,8 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef __INTEL_WIFI_BT_H__
+#define __INTEL_WIFI_BT_H__
+
+void btintel_firmware_lock(void);
+void btintel_firmware_unlock(void);
+
+#endif
--
2.17.1
^ permalink raw reply related
* [PATCH net] bnxt_en: Fix VNIC accounting when enabling aRFS on 57500 chips.
From: Michael Chan @ 2019-07-17 7:07 UTC (permalink / raw)
To: davem; +Cc: netdev
Unlike legacy chips, 57500 chips don't need additional VNIC resources
for aRFS/ntuple. Fix the code accordingly so that we don't reserve
and allocate additional VNICs on 57500 chips. Without this patch,
the driver is failing to initialize when it tries to allocate extra
VNICs.
Fixes: ac33906c67e2 ("bnxt_en: Add support for aRFS on 57500 chips.")
Signed-off-by: Michael Chan <michael.chan@broadcom.com>
---
Please queue this for 5.2 -stable also. Thanks.
drivers/net/ethernet/broadcom/bnxt/bnxt.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/bnxt/bnxt.c b/drivers/net/ethernet/broadcom/bnxt/bnxt.c
index 1069eb0..7134d2c 100644
--- a/drivers/net/ethernet/broadcom/bnxt/bnxt.c
+++ b/drivers/net/ethernet/broadcom/bnxt/bnxt.c
@@ -3075,7 +3075,7 @@ static int bnxt_alloc_vnics(struct bnxt *bp)
int num_vnics = 1;
#ifdef CONFIG_RFS_ACCEL
- if (bp->flags & BNXT_FLAG_RFS)
+ if ((bp->flags & (BNXT_FLAG_RFS | BNXT_FLAG_CHIP_P5)) == BNXT_FLAG_RFS)
num_vnics += bp->rx_nr_rings;
#endif
@@ -7186,6 +7186,9 @@ static int bnxt_alloc_rfs_vnics(struct bnxt *bp)
#ifdef CONFIG_RFS_ACCEL
int i, rc = 0;
+ if (bp->flags & BNXT_FLAG_CHIP_P5)
+ return 0;
+
for (i = 0; i < bp->rx_nr_rings; i++) {
struct bnxt_vnic_info *vnic;
u16 vnic_id = i + 1;
@@ -9645,7 +9648,7 @@ int bnxt_check_rings(struct bnxt *bp, int tx, int rx, bool sh, int tcs,
return -ENOMEM;
vnics = 1;
- if (bp->flags & BNXT_FLAG_RFS)
+ if ((bp->flags & (BNXT_FLAG_RFS | BNXT_FLAG_CHIP_P5)) == BNXT_FLAG_RFS)
vnics += rx_rings;
if (bp->flags & BNXT_FLAG_AGG_RINGS)
--
2.5.1
^ permalink raw reply related
* Re: [RFC PATCH 0/5] PTP: add support for Intel's TGPIO controller
From: Felipe Balbi @ 2019-07-17 6:52 UTC (permalink / raw)
To: Richard Cochran
Cc: netdev, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
H . Peter Anvin, x86, linux-kernel, Christopher S . Hall
In-Reply-To: <20190716164123.GB2125@localhost>
Hi,
Richard Cochran <richardcochran@gmail.com> writes:
> On Tue, Jul 16, 2019 at 10:20:33AM +0300, Felipe Balbi wrote:
>> TGPIO is a new IP which allows for time synchronization between systems
>> without any other means of synchronization such as PTP or NTP. The
>> driver is implemented as part of the PTP framework since its features
>> covered most of what this controller can do.
>
> Can you provide some background on this new HW? Is the interface
> copper wires between chips? Or is it perhaps coax between hosts?
It's just a pin, like a GPIO. So it would be a PCB trace, flat flex,
copper wire... Anything, really.
I think most of the usecases will involve devices somehow on the same
PCB, so a trace or flat flex would be more common. Perhaps Chris has a
better idea in mind? :-)
--
balbi
^ permalink raw reply
* Re: [RFC PATCH 5/5] PTP: Add support for Intel PMC Timed GPIO Controller
From: Felipe Balbi @ 2019-07-17 6:51 UTC (permalink / raw)
To: Shannon Nelson, Richard Cochran
Cc: netdev, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
H . Peter Anvin, x86, linux-kernel, Christopher S . Hall
In-Reply-To: <33864ede-1ce1-92f2-f049-a975060b2743@pensando.io>
Hi,
Shannon Nelson <snelson@pensando.io> writes:
> On 7/16/19 12:20 AM, Felipe Balbi wrote:
>> Add a driver supporting Intel Timed GPIO controller available as part
>> of some Intel PMCs.
>>
>> Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
>
> Hi Felipe, just a couple of quick comments:
>
> There are several places where a line is continued on the next line, but
> should be indented to match the opening parenthesis on a function call
> or 'if' expression.
>
> Shouldn't there be a kthread_stop() in intel_pmc_tgpio_remove(), or did
> I miss that somewhere?
Oops :-p
I could've sworn I had added it when disabling the pin. I'll review
that, sure.
--
balbi
^ permalink raw reply
* Re: [RFC PATCH 4/5] PTP: Add flag for non-periodic output
From: Felipe Balbi @ 2019-07-17 6:49 UTC (permalink / raw)
To: Richard Cochran
Cc: netdev, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
H . Peter Anvin, x86, linux-kernel, Christopher S . Hall
In-Reply-To: <20190716163927.GA2125@localhost>
Hi Richard,
Richard Cochran <richardcochran@gmail.com> writes:
> On Tue, Jul 16, 2019 at 10:20:37AM +0300, Felipe Balbi wrote:
>> When this new flag is set, we can use single-shot output.
>>
>> Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
>> ---
>> include/uapi/linux/ptp_clock.h | 4 +++-
>> 1 file changed, 3 insertions(+), 1 deletion(-)
>>
>> diff --git a/include/uapi/linux/ptp_clock.h b/include/uapi/linux/ptp_clock.h
>> index 674db7de64f3..439cbdfc3d9b 100644
>> --- a/include/uapi/linux/ptp_clock.h
>> +++ b/include/uapi/linux/ptp_clock.h
>> @@ -67,7 +67,9 @@ struct ptp_perout_request {
>> struct ptp_clock_time start; /* Absolute start time. */
>> struct ptp_clock_time period; /* Desired period, zero means disable. */
>> unsigned int index; /* Which channel to configure. */
>> - unsigned int flags; /* Reserved for future use. */
>> +
>> +#define PTP_PEROUT_ONE_SHOT BIT(0)
>> + unsigned int flags; /* Bit 0 -> oneshot output. */
>> unsigned int rsv[4]; /* Reserved for future use. */
>
> Unfortunately, the code never checked that .flags and .rsv are zero,
> and so the de-facto ABI makes extending these fields impossible. That
> was my mistake from the beginning.
>
> In order to actually support extensions, you will first have to
> introduce a new ioctl.
No worries, I'll work on this after vacations (I'll off for 2 weeks
starting next week). I thought about adding a new IOCTL until I saw that
rsv field. Oh well :-)
--
balbi
^ permalink raw reply
* [PATCH] net: dsa: sja1105: Fix missing unlock on error in sk_buff()
From: Wei Yongjun @ 2019-07-17 6:29 UTC (permalink / raw)
To: Andrew Lunn, Vivien Didelot, Florian Fainelli, Vladimir Oltean
Cc: Wei Yongjun, netdev, kernel-janitors
Add the missing unlock before return from function sk_buff()
in the error handling case.
Fixes: f3097be21bf1 ("net: dsa: sja1105: Add a state machine for RX timestamping")
Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
---
net/dsa/tag_sja1105.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/dsa/tag_sja1105.c b/net/dsa/tag_sja1105.c
index 1d96c9d4a8e9..26363d72d25b 100644
--- a/net/dsa/tag_sja1105.c
+++ b/net/dsa/tag_sja1105.c
@@ -216,6 +216,7 @@ static struct sk_buff
if (!skb) {
dev_err_ratelimited(dp->ds->dev,
"Failed to copy stampable skb\n");
+ spin_unlock(&sp->data->meta_lock);
return NULL;
}
sja1105_transfer_meta(skb, meta);
^ permalink raw reply related
* Re: [PATCH bpf] bpf: fix narrower loads on s390
From: Y Song @ 2019-07-17 5:11 UTC (permalink / raw)
To: Ilya Leoshkevich; +Cc: bpf, netdev, gor, heiko.carstens
In-Reply-To: <CAH3MdRWGVDjW8cA9EbnFjK8ko1EqeyDyC_LoRTsxhLsYn1fZtw@mail.gmail.com>
[sorry, resend again as previous one has come text messed out due to
networking issues]
On Tue, Jul 16, 2019 at 10:08 PM Y Song <ys114321@gmail.com> wrote:
>
> On Tue, Jul 16, 2019 at 4:59 AM Ilya Leoshkevich <iii@linux.ibm.com> wrote:
> >
> > test_pkt_md_access is failing on s390, since the associated eBPF prog
> > returns TC_ACT_SHOT, which in turn happens because loading a part of a
> > struct __sk_buff field produces an incorrect result.
> >
> > The problem is that when verifier emits the code to replace partial load
> > of a field with a full load, a shift and a bitwise AND, it assumes that
> > the machine is little endian.
> >
> > Adjust shift count calculation to account for endianness.
> >
> > Fixes: 31fd85816dbe ("bpf: permits narrower load from bpf program context fields")
> > Signed-off-by: Ilya Leoshkevich <iii@linux.ibm.com>
> > ---
> > kernel/bpf/verifier.c | 8 ++++++--
> > 1 file changed, 6 insertions(+), 2 deletions(-)
> >
> > diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
> > index 5900cbb966b1..3f9353653558 100644
> > --- a/kernel/bpf/verifier.c
> > +++ b/kernel/bpf/verifier.c
> > @@ -8616,8 +8616,12 @@ static int convert_ctx_accesses(struct bpf_verifier_env *env)
> > }
> >
> > if (is_narrower_load && size < target_size) {
> > - u8 shift = (off & (size_default - 1)) * 8;
> > -
> > + u8 load_off = off & (size_default - 1);
> > +#ifdef __LITTLE_ENDIAN
> > + u8 shift = load_off * 8;
> > +#else
> > + u8 shift = (size_default - (load_off + size)) * 8;
> > +#endif
>
All the values are in register. The shifting operations should be the
same for big endian and little endian, e.g., value 64 >> 2 = 16 when
value "64" is in register. So I did not see a problem here.
Could you elaborate which field access in test_pkt_md_access
caused problem?
It would be good if you can give detailed memory layout and register values
to illustrate the problem.
>
> > if (ctx_field_size <= 4) {
> > if (shift)
> > insn_buf[cnt++] = BPF_ALU32_IMM(BPF_RSH,
> > --
> > 2.21.0
> >
^ permalink raw reply
* Re: [PATCH bpf] bpf: fix narrower loads on s390
From: Y Song @ 2019-07-17 5:08 UTC (permalink / raw)
To: Ilya Leoshkevich; +Cc: bpf, netdev, gor, heiko.carstens
In-Reply-To: <20190716115910.23093-1-iii@linux.ibm.com>
On Tue, Jul 16, 2019 at 4:59 AM Ilya Leoshkevich <iii@linux.ibm.com> wrote:
>
> test_pkt_md_access is failing on s390, since the associated eBPF prog
> returns TC_ACT_SHOT, which in turn happens because loading a part of a
> struct __sk_buff field produces an incorrect result.
>
> The problem is that when verifier emits the code to replace partial load
> of a field with a full load, a shift and a bitwise AND, it assumes that
> the machine is little endian.
>
> Adjust shift count calculation to account for endianness.
>
> Fixes: 31fd85816dbe ("bpf: permits narrower load from bpf program context fields")
> Signed-off-by: Ilya Leoshkevich <iii@linux.ibm.com>
> ---
> kernel/bpf/verifier.c | 8 ++++++--
> 1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
> index 5900cbb966b1..3f9353653558 100644
> --- a/kernel/bpf/verifier.c
> +++ b/kernel/bpf/verifier.c
> @@ -8616,8 +8616,12 @@ static int convert_ctx_accesses(struct bpf_verifier_env *env)
> }
>
> if (is_narrower_load && size < target_size) {
> - u8 shift = (off & (size_default - 1)) * 8;
> -
> + u8 load_off = off & (size_default - 1);
> +#ifdef __LITTLE_ENDIAN
> + u8 shift = load_off * 8;
> +#else
> + u8 shift = (size_default - (load_off + size)) * 8;
> +#endif
All the values are in register. The shifting operations should be the
same for big endian and little endian, e.g., value 64 >> 2 = 16 when
value "64" is in register. So I did not see a problem here.
Could you elaborate which field access in test_pkt_md_access
caused problem?
It would be good if you can give detailed memory la
> if (ctx_field_size <= 4) {
> if (shift)
> insn_buf[cnt++] = BPF_ALU32_IMM(BPF_RSH,
> --
> 2.21.0
>
^ permalink raw reply
* Re: [PATCH net] be2net: Signal that the device cannot transmit during reconfiguration
From: Firo Yang @ 2019-07-17 4:23 UTC (permalink / raw)
To: Benjamin Poirier, David Miller
Cc: Ajit Khaparde, Sathya Perla, Somnath Kotur, Sriharsha Basavapatna,
Saeed Mahameed, netdev@vger.kernel.org
In-Reply-To: <20190716081655.7676-1-bpoirier@suse.com>
I think there is a problem if dev_watchdog() is triggered before netif_carrier_off(). dev_watchdog() might call ->ndo_tx_timeout(), i.e. be_tx_timeout(), if txq timeout happens. Thus be_tx_timeout() could still be able to access the memory which is being freed by be_update_queues().
Thanks,
Firo
________________________________________
From: Benjamin Poirier
Sent: Tuesday, July 16, 2019 4:16 PM
To: David Miller
Cc: Ajit Khaparde; Sathya Perla; Somnath Kotur; Sriharsha Basavapatna; Saeed Mahameed; Firo Yang; netdev@vger.kernel.org
Subject: [PATCH net] be2net: Signal that the device cannot transmit during reconfiguration
While changing the number of interrupt channels, be2net stops adapter
operation (including netif_tx_disable()) but it doesn't signal that it
cannot transmit. This may lead dev_watchdog() to falsely trigger during
that time.
Add the missing call to netif_carrier_off(), following the pattern used in
many other drivers. netif_carrier_on() is already taken care of in
be_open().
Signed-off-by: Benjamin Poirier <bpoirier@suse.com>
---
drivers/net/ethernet/emulex/benet/be_main.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/emulex/benet/be_main.c b/drivers/net/ethernet/emulex/benet/be_main.c
index 82015c8a5ed7..b7a246b33599 100644
--- a/drivers/net/ethernet/emulex/benet/be_main.c
+++ b/drivers/net/ethernet/emulex/benet/be_main.c
@@ -4697,8 +4697,12 @@ int be_update_queues(struct be_adapter *adapter)
struct net_device *netdev = adapter->netdev;
int status;
- if (netif_running(netdev))
+ if (netif_running(netdev)) {
+ /* device cannot transmit now, avoid dev_watchdog timeouts */
+ netif_carrier_off(netdev);
+
be_close(netdev);
+ }
be_cancel_worker(adapter);
--
2.22.0
^ permalink raw reply related
* Re: [bpf PATCH v3 0/8] sockmap/tls fixes
From: Jakub Kicinski @ 2019-07-17 4:03 UTC (permalink / raw)
To: John Fastabend; +Cc: ast, daniel, netdev, edumazet, bpf
In-Reply-To: <156322373173.18678.6003379631139659856.stgit@john-XPS-13-9370>
On Mon, 15 Jul 2019 13:49:01 -0700, John Fastabend wrote:
> Resolve a series of splats discovered by syzbot and an unhash
> TLS issue noted by Eric Dumazet.
I spent most of today poking at this set, and I'll continue tomorrow.
I'm not capitulating yet, but if I can't get it to work for tls_device
soon, I'll make a version which skips the unhash for offload for now..
^ permalink raw reply
* Re: [bpf-next RFC 3/6] bpf: add bpf_tcp_gen_syncookie helper
From: Petar Penkov @ 2019-07-17 3:33 UTC (permalink / raw)
To: Alexei Starovoitov
Cc: Eric Dumazet, Networking, bpf, davem, Alexei Starovoitov,
Daniel Borkmann, Eric Dumazet, Lorenz Bauer, Stanislav Fomichev,
Petar Penkov
In-Reply-To: <20190717022635.yt7kczxa73kbi7ep@ast-mbp.dhcp.thefacebook.com>
Thank you for your feedback!
On Tue, Jul 16, 2019 at 7:26 PM Alexei Starovoitov
<alexei.starovoitov@gmail.com> wrote:
>
> On Tue, Jul 16, 2019 at 09:59:26AM +0200, Eric Dumazet wrote:
> >
> >
> > On 7/16/19 2:26 AM, Petar Penkov wrote:
> > > From: Petar Penkov <ppenkov@google.com>
> > >
> > > This helper function allows BPF programs to try to generate SYN
> > > cookies, given a reference to a listener socket. The function works
> > > from XDP and with an skb context since bpf_skc_lookup_tcp can lookup a
> > > socket in both cases.
> > >
> > ...
> > >
> > > +BPF_CALL_5(bpf_tcp_gen_syncookie, struct sock *, sk, void *, iph, u32, iph_len,
> > > + struct tcphdr *, th, u32, th_len)
> > > +{
> > > +#ifdef CONFIG_SYN_COOKIES
> > > + u32 cookie;
> > > + u16 mss;
> > > +
> > > + if (unlikely(th_len < sizeof(*th)))
> >
> >
> > You probably need to check that th_len == th->doff * 4
>
> +1
> that is surely necessary for safety.
I'll make sure to include this check in the next version.
>
> Considering the limitation of 5 args the api choice is good.
> struct bpf_syncookie approach doesn't look natural to me.
> And I couldn't come up with any better way to represent this helper.
> So let's go with
> return htonl(cookie) | ((u64)mss << 32);
> My only question is why htonl ?
I did it to mirror bpf_tcp_check_syncookie which sees a network order
cookie. That said, it is probably better for the caller to call
bpf_htonl() as they see fit, rather than to do it in the helper. Will
update, thanks.
>
> Independently of that...
> Since we've been hitting this 5 args limit too much,
> we need to start thinking how to extend BPF ISA to pass
> args 6,7,8 on stack.
>
Agreed, having an additional argument would have been helpful for this function.
^ permalink raw reply
* Re: [PATCH] skbuff: fix compilation warnings in skb_dump()
From: Joe Perches @ 2019-07-17 3:06 UTC (permalink / raw)
To: Willem de Bruijn, Qian Cai
Cc: David Miller, Willem de Bruijn, clang-built-linux,
Network Development, LKML
In-Reply-To: <CAF=yD-KW-XnDvD0i8VbzrkLGNWEY6cPoaEcHy40hbghGXTo+kA@mail.gmail.com>
On Tue, 2019-07-16 at 17:04 +0200, Willem de Bruijn wrote:
> On Tue, Jul 16, 2019 at 4:56 PM Qian Cai <cai@lca.pw> wrote:
> > Fix them by using the proper types, and also fix some checkpatch
> > warnings by using pr_info().
> >
> > WARNING: printk() should include KERN_<LEVEL> facility level
> > + printk("%ssk family=%hu type=%u proto=%u\n",
>
> Converting printk to pr_info lowers all levels to KERN_INFO.
>
> skb_dump takes an explicit parameter level to be able to log at
> KERN_ERR or KERN_WARNING
>
> I would like to avoid those checkpatch warnings, but this is not the
> right approach.
Just ignore checkpatch when it doesn't know that
the printk actually includes a KERN_<LEVEL> via
"%s...", level
^ permalink raw reply
* Re: [bpf-next RFC 3/6] bpf: add bpf_tcp_gen_syncookie helper
From: Alexei Starovoitov @ 2019-07-17 2:26 UTC (permalink / raw)
To: Eric Dumazet
Cc: Petar Penkov, netdev, bpf, davem, ast, daniel, edumazet, lmb, sdf,
Petar Penkov
In-Reply-To: <b6ef24b0-0415-c67d-5a66-21f1c2530414@gmail.com>
On Tue, Jul 16, 2019 at 09:59:26AM +0200, Eric Dumazet wrote:
>
>
> On 7/16/19 2:26 AM, Petar Penkov wrote:
> > From: Petar Penkov <ppenkov@google.com>
> >
> > This helper function allows BPF programs to try to generate SYN
> > cookies, given a reference to a listener socket. The function works
> > from XDP and with an skb context since bpf_skc_lookup_tcp can lookup a
> > socket in both cases.
> >
> ...
> >
> > +BPF_CALL_5(bpf_tcp_gen_syncookie, struct sock *, sk, void *, iph, u32, iph_len,
> > + struct tcphdr *, th, u32, th_len)
> > +{
> > +#ifdef CONFIG_SYN_COOKIES
> > + u32 cookie;
> > + u16 mss;
> > +
> > + if (unlikely(th_len < sizeof(*th)))
>
>
> You probably need to check that th_len == th->doff * 4
+1
that is surely necessary for safety.
Considering the limitation of 5 args the api choice is good.
struct bpf_syncookie approach doesn't look natural to me.
And I couldn't come up with any better way to represent this helper.
So let's go with
return htonl(cookie) | ((u64)mss << 32);
My only question is why htonl ?
Independently of that...
Since we've been hitting this 5 args limit too much,
we need to start thinking how to extend BPF ISA to pass
args 6,7,8 on stack.
^ 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