* Re: [PATCH net] af_packet: Block execution of tasks waiting for transmit to complete in AF_PACKET
From: Willem de Bruijn @ 2019-06-20 13:41 UTC (permalink / raw)
To: Neil Horman; +Cc: Network Development, Matteo Croce, David S. Miller
In-Reply-To: <20190619202533.4856-1-nhorman@tuxdriver.com>
On Wed, Jun 19, 2019 at 4:26 PM Neil Horman <nhorman@tuxdriver.com> wrote:
>
> When an application is run that:
> a) Sets its scheduler to be SCHED_FIFO
> and
> b) Opens a memory mapped AF_PACKET socket, and sends frames with the
> MSG_DONTWAIT flag cleared, its possible for the application to hang
> forever in the kernel. This occurs because when waiting, the code in
> tpacket_snd calls schedule, which under normal circumstances allows
> other tasks to run, including ksoftirqd, which in some cases is
> responsible for freeing the transmitted skb (which in AF_PACKET calls a
> destructor that flips the status bit of the transmitted frame back to
> available, allowing the transmitting task to complete).
>
> However, when the calling application is SCHED_FIFO, its priority is
> such that the schedule call immediately places the task back on the cpu,
> preventing ksoftirqd from freeing the skb, which in turn prevents the
> transmitting task from detecting that the transmission is complete.
>
> We can fix this by converting the schedule call to a completion
> mechanism. By using a completion queue, we force the calling task, when
> it detects there are no more frames to send, to schedule itself off the
> cpu until such time as the last transmitted skb is freed, allowing
> forward progress to be made.
>
> Tested by myself and the reporter, with good results
>
> Appies to the net tree
>
> Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
> Reported-by: Matteo Croce <mcroce@redhat.com>
> CC: "David S. Miller" <davem@davemloft.net>
> ---
This is a complex change for a narrow configuration. Isn't a
SCHED_FIFO process preempting ksoftirqd a potential problem for other
networking workloads as well? And the right configuration to always
increase ksoftirqd priority when increasing another process's
priority? Also, even when ksoftirqd kicks in, isn't some progress
still made on the local_bh_enable reached from schedule()?
^ permalink raw reply
* Re: [EXT] Re: [PATCH net-next 4/4] qed: Add devlink support for configuration attributes.
From: Jiri Pirko @ 2019-06-20 13:37 UTC (permalink / raw)
To: Sudarsana Reddy Kalluru
Cc: Jakub Kicinski, davem@davemloft.net, netdev@vger.kernel.org,
Michal Kalderon, Ariel Elior
In-Reply-To: <MN2PR18MB25289FE6D99432939990C979D3E40@MN2PR18MB2528.namprd18.prod.outlook.com>
Thu, Jun 20, 2019 at 02:09:29PM CEST, skalluru@marvell.com wrote:
>> -----Original Message-----
>> From: Jakub Kicinski <jakub.kicinski@netronome.com>
>> Sent: Tuesday, June 18, 2019 4:24 AM
>> To: Sudarsana Reddy Kalluru <skalluru@marvell.com>
>> Cc: davem@davemloft.net; netdev@vger.kernel.org; Michal Kalderon
>> <mkalderon@marvell.com>; Ariel Elior <aelior@marvell.com>; Jiri Pirko
>> <jiri@resnulli.us>
>> Subject: [EXT] Re: [PATCH net-next 4/4] qed: Add devlink support for
>> configuration attributes.
>>
>> External Email
>>
>> ----------------------------------------------------------------------
>> On Mon, 17 Jun 2019 04:45:28 -0700, Sudarsana Reddy Kalluru wrote:
>> > This patch adds implementation for devlink callbacks for reading/
>> > configuring the device attributes.
>> >
>> > Signed-off-by: Sudarsana Reddy Kalluru <skalluru@marvell.com>
>> > Signed-off-by: Ariel Elior <aelior@marvell.com>
>>
>> You need to provide documentation for your parameters, plus some of them
>> look like they should potentially be port params, not device params.
>
>Thanks a lot for your review. Will add the required documentation. In case of Marvell adapter, any of the device/adapter/port parameters can be read/configurable via any PF (ethdev) on the port. Hence adding the commands at device level. Hope this is fine.
No it is not. Port param should be port param.
Also please be careful not to add any generic param as driver specific.
Thanks!
^ permalink raw reply
* Re: [PATCH net-next v6 04/11] ipv4: Dump route exceptions if requested
From: David Ahern @ 2019-06-20 13:31 UTC (permalink / raw)
To: Stefano Brivio, David Miller
Cc: Jianlin Shi, Wei Wang, Martin KaFai Lau, Eric Dumazet,
Matti Vaittinen, netdev
In-Reply-To: <b5aacd9a3a3f4b256dfd091cdd8771d0f6a1aea2.1560987611.git.sbrivio@redhat.com>
On 6/19/19 5:59 PM, Stefano Brivio wrote:
> diff --git a/include/net/route.h b/include/net/route.h
> index 065b47754f05..e7f65388a6d4 100644
> --- a/include/net/route.h
> +++ b/include/net/route.h
> @@ -44,6 +44,7 @@
> #define RT_CONN_FLAGS_TOS(sk,tos) (RT_TOS(tos) | sock_flag(sk, SOCK_LOCALROUTE))
>
> struct fib_nh;
> +struct fib_alias;
> struct fib_info;
> struct uncached_list;
> struct rtable {
we should not expose fib_alias to route.c.
> @@ -230,6 +231,9 @@ void fib_modify_prefix_metric(struct in_ifaddr *ifa, u32 new_metric);
> void rt_add_uncached_list(struct rtable *rt);
> void rt_del_uncached_list(struct rtable *rt);
>
> +int fnhe_dump_buckets(struct fib_alias *fa, int nhsel, struct sk_buff *skb,
> + struct netlink_callback *cb, int *fa_index, int fa_start);
> +
> static inline void ip_rt_put(struct rtable *rt)
> {
> /* dst_release() accepts a NULL parameter.
> diff --git a/net/ipv4/fib_trie.c b/net/ipv4/fib_trie.c
> index 94e5d83db4db..03f51e5192e5 100644
> --- a/net/ipv4/fib_trie.c
> +++ b/net/ipv4/fib_trie.c
> @@ -2078,28 +2078,51 @@ void fib_free_table(struct fib_table *tb)
> call_rcu(&tb->rcu, __trie_free_rcu);
> }
>
> +static int fib_dump_fnhe_from_leaf(struct fib_alias *fa, struct sk_buff *skb,
> + struct netlink_callback *cb,
> + int *fa_index, int fa_start)
> +{
> + struct fib_info *fi = fa->fa_info;
> + int nhsel;
> +
> + if (!fi || fi->fib_flags & RTNH_F_DEAD)
> + return 0;
> +
> + for (nhsel = 0; nhsel < fib_info_num_path(fi); nhsel++) {
> + int err;
> +
> + err = fnhe_dump_buckets(fa, nhsel, skb, cb, fa_index, fa_start);
> + if (err)
> + return err;
> + }
> +
> + return 0;
> +}
fib_info would be the better argument to pass in to the fnhe dump, and
I think the loop over where the bucket is should be in route.c as well.
So how about fib_info_dump_fnhe() as the helper exposed from route.c,
and it does the loop over nexthops and calls fnhe_dump_buckets.
As for the loop, you could fill an skb without finishing a bucket inside
of a nexthop so you need top track which nexthop is current as well.
^ permalink raw reply
* [PATCH][net-next] hinic: fix dereference of pointer hwdev before it is null checked
From: Colin King @ 2019-06-20 13:27 UTC (permalink / raw)
To: Xue Chaojing, Aviad Krawczyk, David S . Miller, netdev
Cc: kernel-janitors, linux-kernel
From: Colin Ian King <colin.king@canonical.com>
Currently pointer hwdev is dereferenced when assigning hwif before
hwdev is null checked. Fix this by only derefencing hwdev after the
null check.
Addresses-Coverity: ("Dereference before null check")
Fixes: 4fdc51bb4e92 ("hinic: add support for rss parameters with ethtool")
Signed-off-by: Colin Ian King <colin.king@canonical.com>
---
.../net/ethernet/huawei/hinic/hinic_port.c | 21 +++++++++++++------
1 file changed, 15 insertions(+), 6 deletions(-)
diff --git a/drivers/net/ethernet/huawei/hinic/hinic_port.c b/drivers/net/ethernet/huawei/hinic/hinic_port.c
index 6b933962de46..1c3b3c0d6298 100644
--- a/drivers/net/ethernet/huawei/hinic/hinic_port.c
+++ b/drivers/net/ethernet/huawei/hinic/hinic_port.c
@@ -711,14 +711,17 @@ int hinic_get_rss_type(struct hinic_dev *nic_dev, u32 tmpl_idx,
{
struct hinic_rss_context_table ctx_tbl = { 0 };
struct hinic_hwdev *hwdev = nic_dev->hwdev;
- struct hinic_hwif *hwif = hwdev->hwif;
- struct pci_dev *pdev = hwif->pdev;
+ struct hinic_hwif *hwif;
+ struct pci_dev *pdev;
u16 out_size = sizeof(ctx_tbl);
int err;
if (!hwdev || !rss_type)
return -EINVAL;
+ hwif = hwdev->hwif;
+ pdev = hwif->pdev;
+
ctx_tbl.func_id = HINIC_HWIF_FUNC_IDX(hwif);
ctx_tbl.template_id = tmpl_idx;
@@ -776,14 +779,17 @@ int hinic_rss_get_template_tbl(struct hinic_dev *nic_dev, u32 tmpl_idx,
{
struct hinic_rss_template_key temp_key = { 0 };
struct hinic_hwdev *hwdev = nic_dev->hwdev;
- struct hinic_hwif *hwif = hwdev->hwif;
- struct pci_dev *pdev = hwif->pdev;
+ struct hinic_hwif *hwif;
+ struct pci_dev *pdev;
u16 out_size = sizeof(temp_key);
int err;
if (!hwdev || !temp)
return -EINVAL;
+ hwif = hwdev->hwif;
+ pdev = hwif->pdev;
+
temp_key.func_id = HINIC_HWIF_FUNC_IDX(hwif);
temp_key.template_id = tmpl_idx;
@@ -832,14 +838,17 @@ int hinic_rss_get_hash_engine(struct hinic_dev *nic_dev, u8 tmpl_idx, u8 *type)
{
struct hinic_rss_engine_type hash_type = { 0 };
struct hinic_hwdev *hwdev = nic_dev->hwdev;
- struct hinic_hwif *hwif = hwdev->hwif;
- struct pci_dev *pdev = hwif->pdev;
+ struct hinic_hwif *hwif;
+ struct pci_dev *pdev;
u16 out_size = sizeof(hash_type);
int err;
if (!hwdev || !type)
return -EINVAL;
+ hwif = hwdev->hwif;
+ pdev = hwif->pdev;
+
hash_type.func_id = HINIC_HWIF_FUNC_IDX(hwif);
hash_type.template_id = tmpl_idx;
--
2.20.1
^ permalink raw reply related
* WARNING in add_event_to_ctx
From: syzbot @ 2019-06-20 13:17 UTC (permalink / raw)
To: acme, alexander.shishkin, ast, bpf, daniel, jolsa, kafai,
linux-kernel, mingo, namhyung, netdev, peterz, songliubraving,
syzkaller-bugs, yhs
Hello,
syzbot found the following crash on:
HEAD commit: abf02e29 Merge tag 'pm-5.2-rc6' of git://git.kernel.org/pu..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=129072e6a00000
kernel config: https://syzkaller.appspot.com/x/.config?x=28ec3437a5394ee0
dashboard link: https://syzkaller.appspot.com/bug?extid=704bfe2c7d156640ad7a
compiler: clang version 9.0.0 (/home/glider/llvm/clang
80fee25776c2fb61e74c1ecb1a523375c2500b69)
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=16d8b732a00000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=17f7a5e6a00000
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+704bfe2c7d156640ad7a@syzkaller.appspotmail.com
WARNING: CPU: 0 PID: 8131 at kernel/events/core.c:1835 perf_group_attach
kernel/events/core.c:1835 [inline]
WARNING: CPU: 0 PID: 8131 at kernel/events/core.c:1835
add_event_to_ctx+0x1351/0x1630 kernel/events/core.c:2393
Kernel panic - not syncing: panic_on_warn set ...
CPU: 0 PID: 8131 Comm: syz-executor982 Not tainted 5.2.0-rc5+ #4
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
panic+0x28a/0x7c9 kernel/panic.c:219
__warn+0x216/0x220 kernel/panic.c:576
report_bug+0x190/0x290 lib/bug.c:186
fixup_bug arch/x86/kernel/traps.c:179 [inline]
do_error_trap+0xd7/0x450 arch/x86/kernel/traps.c:272
do_invalid_op+0x36/0x40 arch/x86/kernel/traps.c:291
invalid_op+0x14/0x20 arch/x86/entry/entry_64.S:986
RIP: 0010:perf_group_attach kernel/events/core.c:1835 [inline]
RIP: 0010:add_event_to_ctx+0x1351/0x1630 kernel/events/core.c:2393
Code: ff e8 d3 19 e6 ff 0f 0b e9 88 ed ff ff e8 c7 19 e6 ff 0f 0b e9 42 ed
ff ff e8 bb 19 e6 ff 0f 0b e9 4f f8 ff ff e8 af 19 e6 ff <0f> 0b e9 d5 f8
ff ff 48 c7 c1 a0 31 dd 88 80 e1 07 80 c1 03 38 c1
RSP: 0018:ffff888094cdf900 EFLAGS: 00010093
RAX: ffffffff818f9841 RBX: ffff888085d7c418 RCX: ffff888099a064c0
RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000
RBP: ffff888094cdf988 R08: ffffffff818f90aa R09: ffffed101299bf21
R10: ffffed101299bf20 R11: 1ffff1101299bf20 R12: dffffc0000000000
R13: ffff888085d7c200 R14: ffffe8ffffc15758 R15: ffff888085d7ca80
__perf_install_in_context+0x54a/0x7e0 kernel/events/core.c:2544
remote_function+0xeb/0x170 kernel/events/core.c:86
generic_exec_single+0x114/0x420 kernel/smp.c:154
smp_call_function_single+0x1a5/0x410 kernel/smp.c:300
cpu_function_call kernel/events/core.c:140 [inline]
perf_install_in_context+0x26b/0x5a0 kernel/events/core.c:2580
__do_sys_perf_event_open kernel/events/core.c:11110 [inline]
__se_sys_perf_event_open+0x224a/0x3270 kernel/events/core.c:10739
__x64_sys_perf_event_open+0xbf/0xd0 kernel/events/core.c:10739
do_syscall_64+0xfe/0x140 arch/x86/entry/common.c:301
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x446b69
Code: e8 8c 19 03 00 48 83 c4 18 c3 0f 1f 80 00 00 00 00 48 89 f8 48 89 f7
48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff
ff 0f 83 7b 0c fc ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:00007f2b0c7bddb8 EFLAGS: 00000246 ORIG_RAX: 000000000000012a
RAX: ffffffffffffffda RBX: 00000000006dcc28 RCX: 0000000000446b69
RDX: 0000000000000000 RSI: 00000000ffffffff RDI: 0000000020000000
RBP: 00000000006dcc20 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000003 R11: 0000000000000246 R12: 00000000006dcc2c
R13: 00007fff27b1f69f R14: 00007f2b0c7be9c0 R15: 0000000000000000
Kernel Offset: disabled
Rebooting in 86400 seconds..
---
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
* WARNING in debug_check_no_obj_freed
From: syzbot @ 2019-06-20 13:17 UTC (permalink / raw)
To: davem, kgraul, linux-kernel, linux-s390, netdev, syzkaller-bugs,
ubraun
Hello,
syzbot found the following crash on:
HEAD commit: bed3c0d8 Merge tag 'for-5.2-rc5-tag' of git://git.kernel.o..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=13cc2c3aa00000
kernel config: https://syzkaller.appspot.com/x/.config?x=28ec3437a5394ee0
dashboard link: https://syzkaller.appspot.com/bug?extid=b972214bb803a343f4fe
compiler: clang version 9.0.0 (/home/glider/llvm/clang
80fee25776c2fb61e74c1ecb1a523375c2500b69)
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=12fcf0b2a00000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=17a22ad6a00000
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+b972214bb803a343f4fe@syzkaller.appspotmail.com
------------[ cut here ]------------
ODEBUG: free active (active state 0) object type: work_struct hint:
smc_tx_work+0x0/0x260 net/smc/smc_tx.c:264
WARNING: CPU: 0 PID: 8158 at lib/debugobjects.c:328 debug_print_object
lib/debugobjects.c:325 [inline]
WARNING: CPU: 0 PID: 8158 at lib/debugobjects.c:328
__debug_check_no_obj_freed lib/debugobjects.c:785 [inline]
WARNING: CPU: 0 PID: 8158 at lib/debugobjects.c:328
debug_check_no_obj_freed+0x5c0/0x740 lib/debugobjects.c:817
Kernel panic - not syncing: panic_on_warn set ...
CPU: 0 PID: 8158 Comm: syz-executor878 Not tainted 5.2.0-rc5+ #3
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
panic+0x28a/0x7c9 kernel/panic.c:219
__warn+0x216/0x220 kernel/panic.c:576
report_bug+0x190/0x290 lib/bug.c:186
fixup_bug arch/x86/kernel/traps.c:179 [inline]
do_error_trap+0xd7/0x450 arch/x86/kernel/traps.c:272
do_invalid_op+0x36/0x40 arch/x86/kernel/traps.c:291
invalid_op+0x14/0x20 arch/x86/entry/entry_64.S:986
RIP: 0010:debug_print_object lib/debugobjects.c:325 [inline]
RIP: 0010:__debug_check_no_obj_freed lib/debugobjects.c:785 [inline]
RIP: 0010:debug_check_no_obj_freed+0x5c0/0x740 lib/debugobjects.c:817
Code: 96 5c 4e fe 4c 89 fa 48 8b 4d b8 4c 8b 01 48 c7 c7 9c 55 66 88 48 c7
c6 ec 63 7e 88 44 89 e1 4c 8b 4d b0 31 c0 e8 30 05 e7 fd <0f> 0b 48 8b 4d
d0 48 8b 55 c8 ff 05 e8 b2 7c 05 48 b8 00 00 00 00
RSP: 0018:ffff888084ba7b60 EFLAGS: 00010046
RAX: ff4ab4ef149ca600 RBX: 1ffff110152b3acd RCX: ffff88808a330040
RDX: 0000000000000000 RSI: 0000000080000001 RDI: 0000000000000000
RBP: ffff888084ba7c00 R08: ffffffff815e87e4 R09: ffffed1015d440c2
R10: ffffed1015d440c2 R11: 1ffff11015d440c1 R12: 0000000000000000
R13: 1ffff110152b3acf R14: ffff888085381798 R15: dffffc0000000000
kmem_cache_free+0xb9/0x170 mm/slab.c:3697
sk_prot_free net/core/sock.c:1637 [inline]
__sk_destruct+0x558/0x660 net/core/sock.c:1725
sk_destruct net/core/sock.c:1733 [inline]
__sk_free+0x307/0x3d0 net/core/sock.c:1744
sk_free+0x2a/0x40 net/core/sock.c:1755
sock_put include/net/sock.h:1725 [inline]
smc_release+0x4b3/0x620 net/smc/af_smc.c:182
__sock_release net/socket.c:601 [inline]
sock_close+0xdb/0x280 net/socket.c:1273
__fput+0x2e4/0x740 fs/file_table.c:280
____fput+0x15/0x20 fs/file_table.c:313
task_work_run+0x17e/0x1b0 kernel/task_work.c:113
tracehook_notify_resume include/linux/tracehook.h:185 [inline]
exit_to_usermode_loop arch/x86/entry/common.c:168 [inline]
prepare_exit_to_usermode+0x402/0x4f0 arch/x86/entry/common.c:199
syscall_return_slowpath+0x110/0x440 arch/x86/entry/common.c:279
do_syscall_64+0x126/0x140 arch/x86/entry/common.c:304
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x402720
Code: 01 f0 ff ff 0f 83 40 0d 00 00 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f
44 00 00 83 3d 0d 94 2d 00 00 75 14 b8 03 00 00 00 0f 05 <48> 3d 01 f0 ff
ff 0f 83 14 0d 00 00 c3 48 83 ec 08 e8 7a 02 00 00
RSP: 002b:00007ffda70c1198 EFLAGS: 00000246 ORIG_RAX: 0000000000000003
RAX: 0000000000000000 RBX: 0000000000000004 RCX: 0000000000402720
RDX: 0000000000000001 RSI: 0000000000000006 RDI: 0000000000000003
RBP: 0000000000000000 R08: 0000000000000028 R09: 00000000004aa1df
R10: 0000000020000000 R11: 0000000000000246 R12: 0000000000000001
R13: 0000000000403950 R14: 0000000000000000 R15: 0000000000000000
======================================================
---
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: corrupted stack end in corrupted
From: syzbot @ 2019-06-20 13:17 UTC (permalink / raw)
To: ast, daniel, john.fastabend, linux-kernel, netdev, syzkaller-bugs
Hello,
syzbot found the following crash on:
HEAD commit: 29f785ff Merge branch 'fixes' of git://git.kernel.org/pub/..
git tree: net
console output: https://syzkaller.appspot.com/x/log.txt?x=1158d411a00000
kernel config: https://syzkaller.appspot.com/x/.config?x=e5c77f8090a3b96b
dashboard link: https://syzkaller.appspot.com/bug?extid=b764c7ca388222ddfb17
compiler: gcc (GCC) 9.0.0 20181231 (experimental)
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=100ca932a00000
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=135e8a3aa00000
final crash: https://syzkaller.appspot.com/x/report.txt?x=10de8a3aa00000
console output: https://syzkaller.appspot.com/x/log.txt?x=175e8a3aa00000
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+b764c7ca388222ddfb17@syzkaller.appspotmail.com
Fixes: e9db4ef6bf4c ("bpf: sockhash fix omitted bucket lock in sock_close")
Kernel panic - not syncing: corrupted stack end detected inside scheduler
CPU: 0 PID: 8770 Comm: syz-executor.4 Not tainted 5.2.0-rc5+ #57
Hardware name: Google GooglSeaBIOS (version 1.8.2-20190503_170316-google)
---
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-next v6 03/11] ipv4/route: Allow NULL flowinfo in rt_fill_info()
From: David Ahern @ 2019-06-20 13:15 UTC (permalink / raw)
To: Stefano Brivio, David Miller
Cc: Jianlin Shi, Wei Wang, Martin KaFai Lau, Eric Dumazet,
Matti Vaittinen, netdev
In-Reply-To: <5ba00822d7e86cdcb9231b39fda3cc4a04e2836f.1560987611.git.sbrivio@redhat.com>
On 6/19/19 5:59 PM, Stefano Brivio wrote:
> In the next patch, we're going to use rt_fill_info() to dump exception
> routes upon RTM_GETROUTE with NLM_F_ROOT, meaning userspace is requesting
> a dump and not a specific route selection, which in turn implies the input
> interface is not relevant. Update rt_fill_info() to handle a NULL
> flowinfo.
>
> Suggested-by: David Ahern <dsahern@gmail.com>
> Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
> ---
> v6: New patch
>
> net/ipv4/route.c | 57 ++++++++++++++++++++++++++----------------------
> 1 file changed, 31 insertions(+), 26 deletions(-)
>
> diff --git a/net/ipv4/route.c b/net/ipv4/route.c
> index 66cbe8a7a168..052a80373b1d 100644
> --- a/net/ipv4/route.c
> +++ b/net/ipv4/route.c
> @@ -2699,7 +2699,8 @@ static int rt_fill_info(struct net *net, __be32 dst, __be32 src,
> r->rtm_family = AF_INET;
> r->rtm_dst_len = 32;
> r->rtm_src_len = 0;
> - r->rtm_tos = fl4->flowi4_tos;
> + if (fl4)
> + r->rtm_tos = fl4->flowi4_tos;
tracing back to the alloc_skb it does not appear to be initialized to 0,
so this should be:
r->rtm_tos = fl4 ? fl4->flowi4_tos : 0;
other than that it looks fine to me.
Reviewed-by: David Ahern <dsahern@gmail.com>
^ permalink raw reply
* Re: [PATCH nfnext v4] netfilter: add support for matching IPv4 options
From: Pablo Neira Ayuso @ 2019-06-20 13:15 UTC (permalink / raw)
To: Stephen Suryaputra; +Cc: netfilter-devel, netdev
In-Reply-To: <20190620115140.3518-1-ssuryaextr@gmail.com>
On Thu, Jun 20, 2019 at 07:51:40AM -0400, Stephen Suryaputra wrote:
[...]
> diff --git a/net/netfilter/nft_exthdr.c b/net/netfilter/nft_exthdr.c
> index a940c9fd9045..703269359dba 100644
> --- a/net/netfilter/nft_exthdr.c
> +++ b/net/netfilter/nft_exthdr.c
> @@ -62,6 +62,103 @@ static void nft_exthdr_ipv6_eval(const struct nft_expr *expr,
> regs->verdict.code = NFT_BREAK;
> }
>
> +/* find the offset to specified option.
> + *
> + * If target header is found, its offset is set in *offset and return option
> + * number. Otherwise, return negative error.
> + *
> + * If the first fragment doesn't contain the End of Options it is considered
> + * invalid.
> + */
> +static int ipv4_find_option(struct net *net, struct sk_buff *skb,
> + unsigned int *offset, int target)
> +{
> + unsigned char optbuf[sizeof(struct ip_options) + 40];
> + struct ip_options *opt = (struct ip_options *)optbuf;
> + struct iphdr *iph, _iph;
> + unsigned int start;
> + bool found = false;
> + __be32 info;
> + int optlen;
> +
> + iph = skb_header_pointer(skb, 0, sizeof(_iph), &_iph);
> + if (!iph || iph->version != 4)
Nitpick: I think you can remove this check for iph->version != 4, if
skb->protocol already points to ETH_P_IP, then this already has a
valid IP version 4 header.
> + return -EBADMSG;
> + start = sizeof(struct iphdr);
> +
> + optlen = iph->ihl * 4 - (int)sizeof(struct iphdr);
> + if (optlen <= 0)
> + return -ENOENT;
> +
> + memset(opt, 0, sizeof(struct ip_options));
> + /* Copy the options since __ip_options_compile() modifies
> + * the options.
> + */
> + if (skb_copy_bits(skb, start, opt->__data, optlen))
> + return -EBADMSG;
> + opt->optlen = optlen;
> +
> + if (__ip_options_compile(net, opt, NULL, &info))
> + return -EBADMSG;
> +
> + switch (target) {
> + case IPOPT_SSRR:
> + case IPOPT_LSRR:
> + if (!opt->srr)
> + break;
> + found = target == IPOPT_SSRR ? opt->is_strictroute :
> + !opt->is_strictroute;
> + if (found)
> + *offset = opt->srr + start;
> + break;
> + case IPOPT_RR:
> + if (!opt->rr)
> + break;
> + *offset = opt->rr + start;
> + found = true;
> + break;
> + case IPOPT_RA:
> + if (!opt->router_alert)
> + break;
> + *offset = opt->router_alert + start;
> + found = true;
> + break;
> + default:
> + return -EOPNOTSUPP;
> + }
> + return found ? target : -ENOENT;
> +}
> +
> +static void nft_exthdr_ipv4_eval(const struct nft_expr *expr,
> + struct nft_regs *regs,
> + const struct nft_pktinfo *pkt)
> +{
> + struct nft_exthdr *priv = nft_expr_priv(expr);
> + u32 *dest = ®s->data[priv->dreg];
> + struct sk_buff *skb = pkt->skb;
> + unsigned int offset;
> + int err;
> +
> + if (skb->protocol != htons(ETH_P_IP))
> + goto err;
> +
> + err = ipv4_find_option(nft_net(pkt), skb, &offset, priv->type);
> + if (priv->flags & NFT_EXTHDR_F_PRESENT) {
> + *dest = (err >= 0);
> + return;
> + } else if (err < 0) {
> + goto err;
> + }
> + offset += priv->offset;
> +
> + dest[priv->len / NFT_REG32_SIZE] = 0;
> + if (skb_copy_bits(pkt->skb, offset, dest, priv->len) < 0)
> + goto err;
> + return;
> +err:
> + regs->verdict.code = NFT_BREAK;
> +}
> +
> static void *
> nft_tcp_header_pointer(const struct nft_pktinfo *pkt,
> unsigned int len, void *buffer, unsigned int *tcphdr_len)
> @@ -360,6 +457,14 @@ static const struct nft_expr_ops nft_exthdr_ipv6_ops = {
> .dump = nft_exthdr_dump,
> };
>
> +static const struct nft_expr_ops nft_exthdr_ipv4_ops = {
> + .type = &nft_exthdr_type,
> + .size = NFT_EXPR_SIZE(sizeof(struct nft_exthdr)),
> + .eval = nft_exthdr_ipv4_eval,
> + .init = nft_exthdr_init,
Sorry, I just realized this one. Could you add a new
nft_exthdr_ipv4_init() function?
The idea is if priv->type different from:
IPOPT_SSRR
IPOPT_LSRR
IPOPT_RR
IPOPT_RA
are rejected with -EOPNOTSUPP.
If anyone extends this to support for more options, old kernels with
new nft binaries will result in EOPNOTSUPP for options that are not
supported.
The existing TCP options extension does not need this, since it
matches any type. This IPv4 option extension is special, since we
require the option parser to match on options.
I can see you return -EOPNOTSUPP from _eval() path, but that is too
late. It would be good to validate this from the control plane path.
Thanks for your patience.
^ permalink raw reply
* Re: [PATCH v2 net-next 0/2] net: mediatek: Add MT7621 TRGMII mode support
From: Frank Wunderlich @ 2019-06-20 13:02 UTC (permalink / raw)
To: René van Dorst, sean.wang, f.fainelli, davem, matthias.bgg,
andrew, vivien.didelot
Cc: netdev, john, linux-mediatek, linux-mips
In-Reply-To: <20190620122155.32078-1-opensource@vdorst.com>
Tested on Bananapi R2 (mt7623)
Tested-by: "Frank Wunderlich" <frank-w@public-files.de>
Am 20. Juni 2019 14:21:53 MESZ schrieb "René van Dorst" <opensource@vdorst.com>:
>Like many other mediatek SOCs, the MT7621 SOC and the internal MT7530
>switch both supports TRGMII mode. MT7621 TRGMII speed is fix 1200MBit.
>
>v1->v2:
> - Fix breakage on non MT7621 SOC
> - Support 25MHz and 40MHz XTAL as MT7530 clocksource
>
>René van Dorst (2):
> net: ethernet: mediatek: Add MT7621 TRGMII mode support
> net: dsa: mt7530: Add MT7621 TRGMII mode support
>
> drivers/net/dsa/mt7530.c | 46 ++++++++++++++++-----
> drivers/net/dsa/mt7530.h | 4 ++
> drivers/net/ethernet/mediatek/mtk_eth_soc.c | 38 +++++++++++++++--
> drivers/net/ethernet/mediatek/mtk_eth_soc.h | 11 +++++
> 4 files changed, 85 insertions(+), 14 deletions(-)
^ permalink raw reply
* Re: [PATCH net-next v2] ipv6: Error when route does not have any valid nexthops
From: David Ahern @ 2019-06-20 12:57 UTC (permalink / raw)
To: Ido Schimmel, netdev; +Cc: davem, mlxsw, Ido Schimmel
In-Reply-To: <20190620091021.18210-1-idosch@idosch.org>
On 6/20/19 3:10 AM, Ido Schimmel wrote:
> From: Ido Schimmel <idosch@mellanox.com>
>
> When user space sends invalid information in RTA_MULTIPATH, the nexthop
> list in ip6_route_multipath_add() is empty and 'rt_notif' is set to
> NULL.
>
> The code that emits the in-kernel notifications does not check for this
> condition, which results in a NULL pointer dereference [1].
>
> Fix this by bailing earlier in the function if the parsed nexthop list
> is empty. This is consistent with the corresponding IPv4 code.
>
> v2:
> * Check if parsed nexthop list is empty and bail with extack set
>
...
>
> Reported-by: syzbot+382566d339d52cd1a204@syzkaller.appspotmail.com
> Fixes: ebee3cad835f ("ipv6: Add IPv6 multipath notifications for add / replace")
> Signed-off-by: Ido Schimmel <idosch@mellanox.com>
> ---
> net/ipv6/route.c | 6 ++++++
> 1 file changed, 6 insertions(+)
Reviewed-by: David Ahern <dsahern@gmail.com>
^ permalink raw reply
* RE: [PATCH net] tipc: change to use register_pernet_device
From: Jon Maloy @ 2019-06-20 12:53 UTC (permalink / raw)
To: Xin Long, network dev
Cc: davem@davemloft.net, Ying Xue,
tipc-discussion@lists.sourceforge.net
In-Reply-To: <1a8f3ada3e0a65b6e9250c4580a7c420b4ddddac.1561027168.git.lucien.xin@gmail.com>
Acked-by: Jon Maloy <jon.maloy@ericsson.com>
> -----Original Message-----
> From: netdev-owner@vger.kernel.org <netdev-owner@vger.kernel.org> On
> Behalf Of Xin Long
> Sent: 20-Jun-19 06:39
> To: network dev <netdev@vger.kernel.org>
> Cc: davem@davemloft.net; Jon Maloy <jon.maloy@ericsson.com>; Ying Xue
> <ying.xue@windriver.com>; tipc-discussion@lists.sourceforge.net
> Subject: [PATCH net] tipc: change to use register_pernet_device
>
> This patch is to fix a dst defcnt leak, which can be reproduced by doing:.ericsson.com>
>
> # ip net a c; ip net a s; modprobe tipc
> # ip net e s ip l a n eth1 type veth peer n eth1 netns c
> # ip net e c ip l s lo up; ip net e c ip l s eth1 up
> # ip net e s ip l s lo up; ip net e s ip l s eth1 up
> # ip net e c ip a a 1.1.1.2/8 dev eth1
> # ip net e s ip a a 1.1.1.1/8 dev eth1
> # ip net e c tipc b e m udp n u1 localip 1.1.1.2
> # ip net e s tipc b e m udp n u1 localip 1.1.1.1
> # ip net d c; ip net d s; rmmod tipc
>
> and it will get stuck and keep logging the error:
>
> unregister_netdevice: waiting for lo to become free. Usage count = 1
>
> The cause is that a dst is held by the udp sock's sk_rx_dst set on udp rx path
> with udp_early_demux == 1, and this dst (eventually holding lo dev) can't be
> released as bearer's removal in tipc pernet .exit happens after lo dev's
> removal, default_device pernet .exit.
>
> "There are two distinct types of pernet_operations recognized: subsys and
> device. At creation all subsys init functions are called before device
> init functions, and at destruction all device exit functions are called
> before subsys exit function."
>
> So by calling register_pernet_device instead to register tipc_net_ops, the
> pernet .exit() will be invoked earlier than loopback dev's removal when a
> netns is being destroyed, as fou/gue does.
>
> Note that vxlan and geneve udp tunnels don't have this issue, as the udp sock
> is released in their device ndo_stop().
>
> This fix is also necessary for tipc dst_cache, which will hold dsts on tx path and
> I will introduce in my next patch.
>
> Reported-by: Li Shuang <shuali@redhat.com>
> Signed-off-by: Xin Long <lucien.xin@gmail.com>
> ---
> net/tipc/core.c | 12 ++++++------
> 1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/net/tipc/core.c b/net/tipc/core.c index ed536c0..c837072 100644
> --- a/net/tipc/core.c
> +++ b/net/tipc/core.c
> @@ -134,7 +134,7 @@ static int __init tipc_init(void)
> if (err)
> goto out_sysctl;
>
> - err = register_pernet_subsys(&tipc_net_ops);
> + err = register_pernet_device(&tipc_net_ops);
> if (err)
> goto out_pernet;
>
> @@ -142,7 +142,7 @@ static int __init tipc_init(void)
> if (err)
> goto out_socket;
>
> - err = register_pernet_subsys(&tipc_topsrv_net_ops);
> + err = register_pernet_device(&tipc_topsrv_net_ops);
> if (err)
> goto out_pernet_topsrv;
>
> @@ -153,11 +153,11 @@ static int __init tipc_init(void)
> pr_info("Started in single node mode\n");
> return 0;
> out_bearer:
> - unregister_pernet_subsys(&tipc_topsrv_net_ops);
> + unregister_pernet_device(&tipc_topsrv_net_ops);
> out_pernet_topsrv:
> tipc_socket_stop();
> out_socket:
> - unregister_pernet_subsys(&tipc_net_ops);
> + unregister_pernet_device(&tipc_net_ops);
> out_pernet:
> tipc_unregister_sysctl();
> out_sysctl:
> @@ -172,9 +172,9 @@ static int __init tipc_init(void) static void __exit
> tipc_exit(void) {
> tipc_bearer_cleanup();
> - unregister_pernet_subsys(&tipc_topsrv_net_ops);
> + unregister_pernet_device(&tipc_topsrv_net_ops);
> tipc_socket_stop();
> - unregister_pernet_subsys(&tipc_net_ops);
> + unregister_pernet_device(&tipc_net_ops);
> tipc_netlink_stop();
> tipc_netlink_compat_stop();
> tipc_unregister_sysctl();
> --
> 2.1.0
^ permalink raw reply
* RE: [PATCH net] tipc: add dst_cache support for udp media
From: Jon Maloy @ 2019-06-20 12:53 UTC (permalink / raw)
To: Xin Long, network dev
Cc: davem@davemloft.net, Ying Xue,
tipc-discussion@lists.sourceforge.net, Paolo Abeni
In-Reply-To: <0ea2e8519f14d5c9e7bb7ba82a5be371bd4cb9ab.1561028621.git.lucien.xin@gmail.com>
Acked-by: Jon Maloy <jon.maloy@ericsson.com>
> -----Original Message-----
> From: netdev-owner@vger.kernel.org <netdev-owner@vger.kernel.org> On
> Behalf Of Xin Long
> Sent: 20-Jun-19 07:04
> To: network dev <netdev@vger.kernel.org>
> Cc: davem@davemloft.net; Jon Maloy <jon.maloy@ericsson.com>; Ying Xue
> <ying.xue@windriver.com>; tipc-discussion@lists.sourceforge.net; Paolo
> Abeni <pabeni@redhat.com>
> Subject: [PATCH net] tipc: add dst_cache support for udp media
>
> As other udp/ip tunnels do, tipc udp media should also have a lockless
> dst_cache supported on its tx path.
>
> Here we add dst_cache into udp_replicast to support dst cache for both
> rmcast and rcast, and rmcast uses ub->rcast and each rcast uses its own node
> in ub->rcast.list.
>
> Signed-off-by: Xin Long <lucien.xin@gmail.com>
> ---
> net/tipc/udp_media.c | 72 ++++++++++++++++++++++++++++++++++-------
> -----------
> 1 file changed, 47 insertions(+), 25 deletions(-)
>
> diff --git a/net/tipc/udp_media.c b/net/tipc/udp_media.c index
> 1405ccc..b8962df 100644
> --- a/net/tipc/udp_media.c
> +++ b/net/tipc/udp_media.c
> @@ -76,6 +76,7 @@ struct udp_media_addr {
> /* struct udp_replicast - container for UDP remote addresses */ struct
> udp_replicast {
> struct udp_media_addr addr;
> + struct dst_cache dst_cache;
> struct rcu_head rcu;
> struct list_head list;
> };
> @@ -158,22 +159,27 @@ static int tipc_udp_addr2msg(char *msg, struct
> tipc_media_addr *a)
> /* tipc_send_msg - enqueue a send request */ static int tipc_udp_xmit(struct
> net *net, struct sk_buff *skb,
> struct udp_bearer *ub, struct udp_media_addr *src,
> - struct udp_media_addr *dst)
> + struct udp_media_addr *dst, struct dst_cache *cache)
> {
> + struct dst_entry *ndst = dst_cache_get(cache);
> int ttl, err = 0;
> - struct rtable *rt;
>
> if (dst->proto == htons(ETH_P_IP)) {
> - struct flowi4 fl = {
> - .daddr = dst->ipv4.s_addr,
> - .saddr = src->ipv4.s_addr,
> - .flowi4_mark = skb->mark,
> - .flowi4_proto = IPPROTO_UDP
> - };
> - rt = ip_route_output_key(net, &fl);
> - if (IS_ERR(rt)) {
> - err = PTR_ERR(rt);
> - goto tx_error;
> + struct rtable *rt = (struct rtable *)ndst;
> +
> + if (!rt) {
> + struct flowi4 fl = {
> + .daddr = dst->ipv4.s_addr,
> + .saddr = src->ipv4.s_addr,
> + .flowi4_mark = skb->mark,
> + .flowi4_proto = IPPROTO_UDP
> + };
> + rt = ip_route_output_key(net, &fl);
> + if (IS_ERR(rt)) {
> + err = PTR_ERR(rt);
> + goto tx_error;
> + }
> + dst_cache_set_ip4(cache, &rt->dst, fl.saddr);
> }
>
> ttl = ip4_dst_hoplimit(&rt->dst);
> @@ -182,17 +188,19 @@ static int tipc_udp_xmit(struct net *net, struct
> sk_buff *skb,
> dst->port, false, true);
> #if IS_ENABLED(CONFIG_IPV6)
> } else {
> - struct dst_entry *ndst;
> - struct flowi6 fl6 = {
> - .flowi6_oif = ub->ifindex,
> - .daddr = dst->ipv6,
> - .saddr = src->ipv6,
> - .flowi6_proto = IPPROTO_UDP
> - };
> - err = ipv6_stub->ipv6_dst_lookup(net, ub->ubsock->sk, &ndst,
> - &fl6);
> - if (err)
> - goto tx_error;
> + if (!ndst) {
> + struct flowi6 fl6 = {
> + .flowi6_oif = ub->ifindex,
> + .daddr = dst->ipv6,
> + .saddr = src->ipv6,
> + .flowi6_proto = IPPROTO_UDP
> + };
> + err = ipv6_stub->ipv6_dst_lookup(net, ub->ubsock->sk,
> + &ndst, &fl6);
> + if (err)
> + goto tx_error;
> + dst_cache_set_ip6(cache, ndst, &fl6.saddr);
> + }
> ttl = ip6_dst_hoplimit(ndst);
> err = udp_tunnel6_xmit_skb(ndst, ub->ubsock->sk, skb, NULL,
> &src->ipv6, &dst->ipv6, 0, ttl, 0, @@ -230,7
> +238,8 @@ static int tipc_udp_send_msg(struct net *net, struct sk_buff *skb,
> }
>
> if (addr->broadcast != TIPC_REPLICAST_SUPPORT)
> - return tipc_udp_xmit(net, skb, ub, src, dst);
> + return tipc_udp_xmit(net, skb, ub, src, dst,
> + &ub->rcast.dst_cache);
>
> /* Replicast, send an skb to each configured IP address */
> list_for_each_entry_rcu(rcast, &ub->rcast.list, list) { @@ -242,7 +251,8
> @@ static int tipc_udp_send_msg(struct net *net, struct sk_buff *skb,
> goto out;
> }
>
> - err = tipc_udp_xmit(net, _skb, ub, src, &rcast->addr);
> + err = tipc_udp_xmit(net, _skb, ub, src, &rcast->addr,
> + &rcast->dst_cache);
> if (err)
> goto out;
> }
> @@ -286,6 +296,11 @@ static int tipc_udp_rcast_add(struct tipc_bearer *b,
> if (!rcast)
> return -ENOMEM;
>
> + if (dst_cache_init(&rcast->dst_cache, GFP_ATOMIC)) {
> + kfree(rcast);
> + return -ENOMEM;
> + }
> +
> memcpy(&rcast->addr, addr, sizeof(struct udp_media_addr));
>
> if (ntohs(addr->proto) == ETH_P_IP)
> @@ -742,6 +757,10 @@ static int tipc_udp_enable(struct net *net, struct
> tipc_bearer *b,
> tuncfg.encap_destroy = NULL;
> setup_udp_tunnel_sock(net, ub->ubsock, &tuncfg);
>
> + err = dst_cache_init(&ub->rcast.dst_cache, GFP_ATOMIC);
> + if (err)
> + goto err;
> +
> /**
> * The bcast media address port is used for all peers and the ip
> * is used if it's a multicast address.
> @@ -756,6 +775,7 @@ static int tipc_udp_enable(struct net *net, struct
> tipc_bearer *b,
>
> return 0;
> err:
> + dst_cache_destroy(&ub->rcast.dst_cache);
> if (ub->ubsock)
> udp_tunnel_sock_release(ub->ubsock);
> kfree(ub);
> @@ -769,10 +789,12 @@ static void cleanup_bearer(struct work_struct
> *work)
> struct udp_replicast *rcast, *tmp;
>
> list_for_each_entry_safe(rcast, tmp, &ub->rcast.list, list) {
> + dst_cache_destroy(&rcast->dst_cache);
> list_del_rcu(&rcast->list);
> kfree_rcu(rcast, rcu);
> }
>
> + dst_cache_destroy(&ub->rcast.dst_cache);
> if (ub->ubsock)
> udp_tunnel_sock_release(ub->ubsock);
> synchronize_net();
> --
> 2.1.0
^ permalink raw reply
* Re: [PATCH net] net/sched: flower: fix infinite loop in fl_walk()
From: Davide Caratti @ 2019-06-20 12:52 UTC (permalink / raw)
To: Cong Wang
Cc: Vlad Buslov, David S. Miller, Linux Kernel Network Developers,
Lucas Bates
In-Reply-To: <CAM_iQpUVJ9sG9ETE0zZ_azbDgWp_oi320nWy_g-uh2YJWYDOXw@mail.gmail.com>
hello Cong, thanks for reading.
On Wed, 2019-06-19 at 15:04 -0700, Cong Wang wrote:
> On Wed, Jun 19, 2019 at 2:10 PM Davide Caratti <dcaratti@redhat.com> wrote:
> > on some CPUs (e.g. i686), tcf_walker.cookie has the same size as the IDR.
> > In this situation, the following script:
> >
> > # tc filter add dev eth0 ingress handle 0xffffffff flower action ok
> > # tc filter show dev eth0 ingress
> >
> > results in an infinite loop. It happened also on other CPUs (e.g x86_64),
> > before commit 061775583e35 ("net: sched: flower: introduce reference
> > counting for filters"), because 'handle' + 1 made the u32 overflow before
> > it was assigned to 'cookie'; but that commit replaced the assignment with
> > a self-increment of 'cookie', so the problem was indirectly fixed.
>
> Interesting... Is this really specific to cls_flower? To me it looks like
> a bug of idr_*_ul() API's, especially for idr_for_each_entry_ul().
good question, I have to investigate this better (idr_for_each_entry_ul()
expands in a iteration of idr_get_next_ul()). It surely got in cls_flower
when it was converted to use IDRs, but it's true that there might be other
points in TC where IDR are used and the same pattern is present (see
below).
> Can you test if the following command has the same problem on i386?
>
> tc actions add action ok index 4294967295
the action is added, but then reading it back results in an infinite loop.
And again, the infinite loop happens on i686 and not on x86_64. I will try
to see where's the problem also here.
--
davide
^ permalink raw reply
* [PATCH v2 2/3] kernel/notifier.c: remove notifier_chain_cond_register()
From: Xiaoming Ni @ 2019-06-20 12:48 UTC (permalink / raw)
To: trond.myklebust, anna.schumaker, bfields, jlayton, davem,
semen.protsenko, akpm, gregkh, vvs, tglx
Cc: nixiaoming, dylix.dailei, alex.huangjianhui, adobriyan, mingo,
viresh.kumar, luto, arjan, Nadia.Derbey, torvalds, stern, paulmck,
linux-kernel, linux-nfs, netdev, stable
In-Reply-To: <1561034914-106990-1-git-send-email-nixiaoming@huawei.com>
The only difference between notifier_chain_cond_register() and
notifier_chain_register() is the lack of warning hints for duplicate
registrations.
Consider using notifier_chain_register() instead of
notifier_chain_cond_register() to avoid duplicate code
Signed-off-by: Xiaoming Ni <nixiaoming@huawei.com>
---
kernel/notifier.c | 17 +----------------
1 file changed, 1 insertion(+), 16 deletions(-)
diff --git a/kernel/notifier.c b/kernel/notifier.c
index 30bedb8..e3d221f 100644
--- a/kernel/notifier.c
+++ b/kernel/notifier.c
@@ -36,21 +36,6 @@ static int notifier_chain_register(struct notifier_block **nl,
return 0;
}
-static int notifier_chain_cond_register(struct notifier_block **nl,
- struct notifier_block *n)
-{
- while ((*nl) != NULL) {
- if ((*nl) == n)
- return 0;
- if (n->priority > (*nl)->priority)
- break;
- nl = &((*nl)->next);
- }
- n->next = *nl;
- rcu_assign_pointer(*nl, n);
- return 0;
-}
-
static int notifier_chain_unregister(struct notifier_block **nl,
struct notifier_block *n)
{
@@ -252,7 +237,7 @@ int blocking_notifier_chain_cond_register(struct blocking_notifier_head *nh,
int ret;
down_write(&nh->rwsem);
- ret = notifier_chain_cond_register(&nh->head, n);
+ ret = notifier_chain_register(&nh->head, n);
up_write(&nh->rwsem);
return ret;
}
--
1.8.5.6
^ permalink raw reply related
* [PATCH v2 1/3] kernel/notifier.c: avoid duplicate registration
From: Xiaoming Ni @ 2019-06-20 12:48 UTC (permalink / raw)
To: trond.myklebust, anna.schumaker, bfields, jlayton, davem,
semen.protsenko, akpm, gregkh, vvs, tglx
Cc: nixiaoming, dylix.dailei, alex.huangjianhui, adobriyan, mingo,
viresh.kumar, luto, arjan, Nadia.Derbey, torvalds, stern, paulmck,
linux-kernel, linux-nfs, netdev, stable
Registering the same notifier to a hook repeatedly can cause the hook
list to form a ring or lose other members of the list.
case1: An infinite loop in notifier_chain_register() can cause soft lockup
atomic_notifier_chain_register(&test_notifier_list, &test1);
atomic_notifier_chain_register(&test_notifier_list, &test1);
atomic_notifier_chain_register(&test_notifier_list, &test2);
case2: An infinite loop in notifier_chain_register() can cause soft lockup
atomic_notifier_chain_register(&test_notifier_list, &test1);
atomic_notifier_chain_register(&test_notifier_list, &test1);
atomic_notifier_call_chain(&test_notifier_list, 0, NULL);
case3: lose other hook test2
atomic_notifier_chain_register(&test_notifier_list, &test1);
atomic_notifier_chain_register(&test_notifier_list, &test2);
atomic_notifier_chain_register(&test_notifier_list, &test1);
case4: Unregister returns 0, but the hook is still in the linked list,
and it is not really registered. If you call notifier_call_chain
after ko is unloaded, it will trigger oops.
If the system is configured with softlockup_panic and the same
hook is repeatedly registered on the panic_notifier_list, it
will cause a loop panic.
Add a check in notifier_chain_register() to avoid duplicate registration
Signed-off-by: Xiaoming Ni <nixiaoming@huawei.com>
---
kernel/notifier.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/kernel/notifier.c b/kernel/notifier.c
index d9f5081..30bedb8 100644
--- a/kernel/notifier.c
+++ b/kernel/notifier.c
@@ -23,7 +23,10 @@ static int notifier_chain_register(struct notifier_block **nl,
struct notifier_block *n)
{
while ((*nl) != NULL) {
- WARN_ONCE(((*nl) == n), "double register detected");
+ if (unlikely((*nl) == n)) {
+ WARN(1, "double register detected");
+ return 0;
+ }
if (n->priority > (*nl)->priority)
break;
nl = &((*nl)->next);
--
1.8.5.6
^ permalink raw reply related
* [PATCH v2 3/3] kernel/notifier.c: remove blocking_notifier_chain_cond_register()
From: Xiaoming Ni @ 2019-06-20 12:48 UTC (permalink / raw)
To: trond.myklebust, anna.schumaker, bfields, jlayton, davem,
semen.protsenko, akpm, gregkh, vvs, tglx
Cc: nixiaoming, dylix.dailei, alex.huangjianhui, adobriyan, mingo,
viresh.kumar, luto, arjan, Nadia.Derbey, torvalds, stern, paulmck,
linux-kernel, linux-nfs, netdev, stable
In-Reply-To: <1561034914-106990-1-git-send-email-nixiaoming@huawei.com>
blocking_notifier_chain_cond_register() does not consider
system_booting state, which is the only difference between this
function and blocking_notifier_cain_register(). This can be a bug
and is a piece of duplicate code.
Delete blocking_notifier_chain_cond_register()
Signed-off-by: Xiaoming Ni <nixiaoming@huawei.com>
---
include/linux/notifier.h | 4 ----
kernel/notifier.c | 23 -----------------------
net/sunrpc/rpc_pipe.c | 2 +-
3 files changed, 1 insertion(+), 28 deletions(-)
diff --git a/include/linux/notifier.h b/include/linux/notifier.h
index 0096a05..0189476 100644
--- a/include/linux/notifier.h
+++ b/include/linux/notifier.h
@@ -150,10 +150,6 @@ extern int raw_notifier_chain_register(struct raw_notifier_head *nh,
extern int srcu_notifier_chain_register(struct srcu_notifier_head *nh,
struct notifier_block *nb);
-extern int blocking_notifier_chain_cond_register(
- struct blocking_notifier_head *nh,
- struct notifier_block *nb);
-
extern int atomic_notifier_chain_unregister(struct atomic_notifier_head *nh,
struct notifier_block *nb);
extern int blocking_notifier_chain_unregister(struct blocking_notifier_head *nh,
diff --git a/kernel/notifier.c b/kernel/notifier.c
index e3d221f..63d7501 100644
--- a/kernel/notifier.c
+++ b/kernel/notifier.c
@@ -221,29 +221,6 @@ int blocking_notifier_chain_register(struct blocking_notifier_head *nh,
EXPORT_SYMBOL_GPL(blocking_notifier_chain_register);
/**
- * blocking_notifier_chain_cond_register - Cond add notifier to a blocking notifier chain
- * @nh: Pointer to head of the blocking notifier chain
- * @n: New entry in notifier chain
- *
- * Adds a notifier to a blocking notifier chain, only if not already
- * present in the chain.
- * Must be called in process context.
- *
- * Currently always returns zero.
- */
-int blocking_notifier_chain_cond_register(struct blocking_notifier_head *nh,
- struct notifier_block *n)
-{
- int ret;
-
- down_write(&nh->rwsem);
- ret = notifier_chain_register(&nh->head, n);
- up_write(&nh->rwsem);
- return ret;
-}
-EXPORT_SYMBOL_GPL(blocking_notifier_chain_cond_register);
-
-/**
* blocking_notifier_chain_unregister - Remove notifier from a blocking notifier chain
* @nh: Pointer to head of the blocking notifier chain
* @n: Entry to remove from notifier chain
diff --git a/net/sunrpc/rpc_pipe.c b/net/sunrpc/rpc_pipe.c
index 126d314..1287f80 100644
--- a/net/sunrpc/rpc_pipe.c
+++ b/net/sunrpc/rpc_pipe.c
@@ -50,7 +50,7 @@
int rpc_pipefs_notifier_register(struct notifier_block *nb)
{
- return blocking_notifier_chain_cond_register(&rpc_pipefs_notifier_list, nb);
+ return blocking_notifier_chain_register(&rpc_pipefs_notifier_list, nb);
}
EXPORT_SYMBOL_GPL(rpc_pipefs_notifier_register);
--
1.8.5.6
^ permalink raw reply related
* Re: [PATCH RFC] proc/meminfo: add NetBuffers counter for socket buffers
From: Konstantin Khlebnikov @ 2019-06-20 12:40 UTC (permalink / raw)
To: Vlastimil Babka, linux-mm, linux-kernel, netdev
In-Reply-To: <9f611f72-c883-45e9-cb2a-824ba27356d9@suse.cz>
On 20.06.2019 15:03, Vlastimil Babka wrote:
> On 5/15/19 1:55 PM, Konstantin Khlebnikov wrote:
>> Socket buffers always were dark-matter that lives by its own rules.
>
> Is the information even exported somewhere e.g. in sysfs or via netlink yet?
in /proc/self/net/protocols
protocol size sockets memory press maxhdr slab module cl co di ac io in de sh ss gs se re sp bi br ha uh gp em
PACKET 1408 0 -1 NI 0 no kernel n n n n n n n n n n n n n n n n n n n
PINGv6 1088 0 -1 NI 0 yes kernel y y y n n y n n y y y y n y y y y y n
RAWv6 1088 0 -1 NI 0 yes kernel y y y n y y y n y y y y n y y y y n n
UDPLITEv6 1080 0 -1 NI 0 yes kernel y y y n y y y n y y y y n n y y y y n
UDPv6 1080 21 111 NI 0 yes kernel y y y n y n y n y y y y n n y y y y n
TCPv6 2048 49297 442697 no 304 yes kernel y y y y y y y y y y y y y n y y y y y
UNIX 1024 158 -1 NI 0 yes kernel n n n n n n n n n n n n n n n n n n n
UDP-Lite 920 0 -1 NI 0 yes kernel y y y n y y y n y y y y y n y y y y n
PING 880 0 -1 NI 0 yes kernel y y y n n y n n y y y y n y y y y y n
RAW 888 0 -1 NI 0 yes kernel y y y n y y y n y y y y n y y y y n n
UDP 920 0 111 NI 0 yes kernel y y y n y n y n y y y y y n y y y y n
TCP 1888 0 442697 no 304 yes kernel y y y y y y y y y y y y y n y y y y y
NETLINK 1040 1 -1 NI 0 no kernel n n n n n n n n n n n n n n n n n n n
column 'sockets' is virtualized, while 'memory' is not
>
>> This patch adds line NetBuffers that exposes most common kinds of them.
>
> Did you encounter a situation where the number was significant and this
> would help finding out why memory is occupied?
Might be. In example above tcp buffers are 1,7G.
This is real server, with 0.5T ram though.
>
>> TCP and UDP are most important species.
>> SCTP is added as example of modular protocol.
>> UNIX have no memory counter for now, should be easy to add.
>>
>> Signed-off-by: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>
>
> Right now it's a sum of a few values, which should be fine wrt
> /proc/meminfo overhead. But I guess netdev guys should have a say in
> this. Also you should update the corresponding Documentation/ file.
Later I send another proposal: even bigger sum - "MemKernel".
https://lore.kernel.org/linux-mm/155853600919.381.8172097084053782598.stgit@buzz/
Which gives estimation for all kinds of 'kernel' memory. It seems more useful for me.
>
> Thanks,
> Vlastimil
>
>> ---
>> fs/proc/meminfo.c | 5 ++++-
>> include/linux/mm.h | 6 ++++++
>> mm/page_alloc.c | 3 ++-
>> net/core/sock.c | 20 ++++++++++++++++++++
>> net/sctp/socket.c | 2 +-
>> 5 files changed, 33 insertions(+), 3 deletions(-)
>>
>> diff --git a/fs/proc/meminfo.c b/fs/proc/meminfo.c
>> index 7bc14716fc5d..0ee2300a916d 100644
>> --- a/fs/proc/meminfo.c
>> +++ b/fs/proc/meminfo.c
>> @@ -41,6 +41,7 @@ static int meminfo_proc_show(struct seq_file *m, void *v)
>> unsigned long sreclaimable, sunreclaim, misc_reclaimable;
>> unsigned long kernel_stack_kb, page_tables, percpu_pages;
>> unsigned long anon_pages, file_pages, swap_cached;
>> + unsigned long net_buffers;
>> long kernel_misc;
>> int lru;
>>
>> @@ -66,12 +67,13 @@ static int meminfo_proc_show(struct seq_file *m, void *v)
>> kernel_stack_kb = global_zone_page_state(NR_KERNEL_STACK_KB);
>> page_tables = global_zone_page_state(NR_PAGETABLE);
>> percpu_pages = pcpu_nr_pages();
>> + net_buffers = total_netbuffer_pages();
>>
>> /* all other kinds of kernel memory allocations */
>> kernel_misc = i.totalram - i.freeram - anon_pages - file_pages
>> - sreclaimable - sunreclaim - misc_reclaimable
>> - (kernel_stack_kb >> (PAGE_SHIFT - 10))
>> - - page_tables - percpu_pages;
>> + - page_tables - percpu_pages - net_buffers;
>> if (kernel_misc < 0)
>> kernel_misc = 0;
>>
>> @@ -137,6 +139,7 @@ static int meminfo_proc_show(struct seq_file *m, void *v)
>> show_val_kb(m, "VmallocUsed: ", 0ul);
>> show_val_kb(m, "VmallocChunk: ", 0ul);
>> show_val_kb(m, "Percpu: ", percpu_pages);
>> + show_val_kb(m, "NetBuffers: ", net_buffers);
>> show_val_kb(m, "KernelMisc: ", kernel_misc);
>>
>> #ifdef CONFIG_MEMORY_FAILURE
>> diff --git a/include/linux/mm.h b/include/linux/mm.h
>> index 0e8834ac32b7..d0a58355bfb7 100644
>> --- a/include/linux/mm.h
>> +++ b/include/linux/mm.h
>> @@ -2254,6 +2254,12 @@ extern void si_meminfo_node(struct sysinfo *val, int nid);
>> extern unsigned long arch_reserved_kernel_pages(void);
>> #endif
>>
>> +#ifdef CONFIG_NET
>> +extern unsigned long total_netbuffer_pages(void);
>> +#else
>> +static inline unsigned long total_netbuffer_pages(void) { return 0; }
>> +#endif
>> +
>> extern __printf(3, 4)
>> void warn_alloc(gfp_t gfp_mask, nodemask_t *nodemask, const char *fmt, ...);
>>
>> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
>> index 3b13d3914176..fcdd7c6e72b9 100644
>> --- a/mm/page_alloc.c
>> +++ b/mm/page_alloc.c
>> @@ -5166,7 +5166,7 @@ void show_free_areas(unsigned int filter, nodemask_t *nodemask)
>> " active_file:%lu inactive_file:%lu isolated_file:%lu\n"
>> " unevictable:%lu dirty:%lu writeback:%lu unstable:%lu\n"
>> " slab_reclaimable:%lu slab_unreclaimable:%lu\n"
>> - " mapped:%lu shmem:%lu pagetables:%lu bounce:%lu\n"
>> + " mapped:%lu shmem:%lu pagetables:%lu bounce:%lu net_buffers:%lu\n"
>> " free:%lu free_pcp:%lu free_cma:%lu\n",
>> global_node_page_state(NR_ACTIVE_ANON),
>> global_node_page_state(NR_INACTIVE_ANON),
>> @@ -5184,6 +5184,7 @@ void show_free_areas(unsigned int filter, nodemask_t *nodemask)
>> global_node_page_state(NR_SHMEM),
>> global_zone_page_state(NR_PAGETABLE),
>> global_zone_page_state(NR_BOUNCE),
>> + total_netbuffer_pages(),
>> global_zone_page_state(NR_FREE_PAGES),
>> free_pcp,
>> global_zone_page_state(NR_FREE_CMA_PAGES));
>> diff --git a/net/core/sock.c b/net/core/sock.c
>> index 75b1c950b49f..dfca4e024b74 100644
>> --- a/net/core/sock.c
>> +++ b/net/core/sock.c
>> @@ -142,6 +142,7 @@
>> #include <trace/events/sock.h>
>>
>> #include <net/tcp.h>
>> +#include <net/udp.h>
>> #include <net/busy_poll.h>
>>
>> static DEFINE_MUTEX(proto_list_mutex);
>> @@ -3573,3 +3574,22 @@ bool sk_busy_loop_end(void *p, unsigned long start_time)
>> }
>> EXPORT_SYMBOL(sk_busy_loop_end);
>> #endif /* CONFIG_NET_RX_BUSY_POLL */
>> +
>> +#if IS_ENABLED(CONFIG_IP_SCTP)
>> +atomic_long_t sctp_memory_allocated;
>> +EXPORT_SYMBOL_GPL(sctp_memory_allocated);
>> +#endif
>> +
>> +unsigned long total_netbuffer_pages(void)
>> +{
>> + unsigned long ret = 0;
>> +
>> +#if IS_ENABLED(CONFIG_IP_SCTP)
>> + ret += atomic_long_read(&sctp_memory_allocated);
>> +#endif
>> +#ifdef CONFIG_INET
>> + ret += atomic_long_read(&tcp_memory_allocated);
>> + ret += atomic_long_read(&udp_memory_allocated);
>> +#endif
>> + return ret;
>> +}
>> diff --git a/net/sctp/socket.c b/net/sctp/socket.c
>> index e4e892cc5644..9d11afdeeae4 100644
>> --- a/net/sctp/socket.c
>> +++ b/net/sctp/socket.c
>> @@ -107,7 +107,7 @@ static int sctp_sock_migrate(struct sock *oldsk, struct sock *newsk,
>> enum sctp_socket_type type);
>>
>> static unsigned long sctp_memory_pressure;
>> -static atomic_long_t sctp_memory_allocated;
>> +extern atomic_long_t sctp_memory_allocated;
>> struct percpu_counter sctp_sockets_allocated;
>>
>> static void sctp_enter_memory_pressure(struct sock *sk)
>>
>
^ permalink raw reply
* kernel BUG at ./include/linux/scatterlist.h:LINE!
From: syzbot @ 2019-06-20 12:47 UTC (permalink / raw)
To: ast, aviadye, borisp, bpf, daniel, davejwatson, davem,
john.fastabend, kafai, linux-kernel, netdev, songliubraving,
syzkaller-bugs, vakul.garg, yhs
Hello,
syzbot found the following crash on:
HEAD commit: bed3c0d8 Merge tag 'for-5.2-rc5-tag' of git://git.kernel.o..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=138d485ea00000
kernel config: https://syzkaller.appspot.com/x/.config?x=28ec3437a5394ee0
dashboard link: https://syzkaller.appspot.com/bug?extid=ef0daa6ce95facb233c1
compiler: clang version 9.0.0 (/home/glider/llvm/clang
80fee25776c2fb61e74c1ecb1a523375c2500b69)
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=13175731a00000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=126947faa00000
The bug was bisected to:
commit f295b3ae9f5927e084bd5decdff82390e3471801
Author: Vakul Garg <vakul.garg@nxp.com>
Date: Wed Mar 20 02:03:36 2019 +0000
net/tls: Add support of AES128-CCM based ciphers
bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=1738b732a00000
final crash: https://syzkaller.appspot.com/x/report.txt?x=14b8b732a00000
console output: https://syzkaller.appspot.com/x/log.txt?x=10b8b732a00000
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+ef0daa6ce95facb233c1@syzkaller.appspotmail.com
Fixes: f295b3ae9f59 ("net/tls: Add support of AES128-CCM based ciphers")
RAX: ffffffffffffffda RBX: 00007ffd6d3365b0 RCX: 0000000000441ba9
RDX: 0000000000000004 RSI: 0000000000000000 RDI: 0000000000000003
RBP: 0000000000000000 R08: 0000000100000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: ffffffffffffffff
R13: 0000000000000005 R14: 0000000000000000 R15: 0000000000000000
------------[ cut here ]------------
kernel BUG at ./include/linux/scatterlist.h:97!
invalid opcode: 0000 [#1] PREEMPT SMP KASAN
CPU: 1 PID: 8023 Comm: syz-executor694 Not tainted 5.2.0-rc5+ #3
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
RIP: 0010:sg_assign_page include/linux/scatterlist.h:97 [inline]
RIP: 0010:sg_set_page include/linux/scatterlist.h:119 [inline]
RIP: 0010:sk_msg_page_add include/linux/skmsg.h:246 [inline]
RIP: 0010:tls_sw_do_sendpage net/tls/tls_sw.c:1170 [inline]
RIP: 0010:tls_sw_sendpage+0x11b5/0x11e0 net/tls/tls_sw.c:1229
Code: c1 38 c1 0f 8c 12 fe ff ff 4c 89 f7 e8 14 bb 27 fb e9 05 fe ff ff e8
0a 92 ee fa 44 8b 7c 24 18 e9 b2 fe ff ff e8 fb 91 ee fa <0f> 0b e8 f4 91
ee fa 0f 0b e8 ed 91 ee fa 4c 89 f7 48 c7 c6 87 e5
RSP: 0018:ffff888094adf7c0 EFLAGS: 00010293
RAX: ffffffff86871ff5 RBX: 0000000000000001 RCX: ffff888095bfc300
RDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000000
RBP: ffff888094adf998 R08: ffffffff8687170c R09: fffff9400045851f
R10: fffff9400045851f R11: 1ffffd400045851e R12: 0000000000000000
R13: 0000000000000080 R14: ffffea00022c28c0 R15: 1ffff110124d0d01
FS: 0000555556a2f880(0000) GS:ffff8880aeb00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007ffc5c9d1f18 CR3: 00000000a8a2c000 CR4: 00000000001406e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
inet_sendpage+0x16d/0x340 net/ipv4/af_inet.c:815
kernel_sendpage net/socket.c:3642 [inline]
sock_sendpage+0xd3/0x120 net/socket.c:940
pipe_to_sendpage+0x23e/0x310 fs/splice.c:449
splice_from_pipe_feed fs/splice.c:500 [inline]
__splice_from_pipe+0x2f7/0x8a0 fs/splice.c:624
splice_from_pipe fs/splice.c:659 [inline]
generic_splice_sendpage+0x172/0x200 fs/splice.c:829
do_splice_from fs/splice.c:848 [inline]
do_splice fs/splice.c:1155 [inline]
__do_sys_splice fs/splice.c:1425 [inline]
__se_sys_splice+0x12ec/0x1db0 fs/splice.c:1405
__x64_sys_splice+0xe5/0x100 fs/splice.c:1405
do_syscall_64+0xfe/0x140 arch/x86/entry/common.c:301
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x441ba9
Code: 18 89 d0 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 48 89 f8 48 89 f7
48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff
ff 0f 83 bb 10 fc ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:00007ffd6d336548 EFLAGS: 00000246 ORIG_RAX: 0000000000000113
RAX: ffffffffffffffda RBX: 00007ffd6d3365b0 RCX: 0000000000441ba9
RDX: 0000000000000004 RSI: 0000000000000000 RDI: 0000000000000003
RBP: 0000000000000000 R08: 0000000100000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: ffffffffffffffff
R13: 0000000000000005 R14: 0000000000000000 R15: 0000000000000000
Modules linked in:
---[ end trace 3b5328faabff785c ]---
RIP: 0010:sg_assign_page include/linux/scatterlist.h:97 [inline]
RIP: 0010:sg_set_page include/linux/scatterlist.h:119 [inline]
RIP: 0010:sk_msg_page_add include/linux/skmsg.h:246 [inline]
RIP: 0010:tls_sw_do_sendpage net/tls/tls_sw.c:1170 [inline]
RIP: 0010:tls_sw_sendpage+0x11b5/0x11e0 net/tls/tls_sw.c:1229
Code: c1 38 c1 0f 8c 12 fe ff ff 4c 89 f7 e8 14 bb 27 fb e9 05 fe ff ff e8
0a 92 ee fa 44 8b 7c 24 18 e9 b2 fe ff ff e8 fb 91 ee fa <0f> 0b e8 f4 91
ee fa 0f 0b e8 ed 91 ee fa 4c 89 f7 48 c7 c6 87 e5
RSP: 0018:ffff888094adf7c0 EFLAGS: 00010293
RAX: ffffffff86871ff5 RBX: 0000000000000001 RCX: ffff888095bfc300
RDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000000
RBP: ffff888094adf998 R08: ffffffff8687170c R09: fffff9400045851f
R10: fffff9400045851f R11: 1ffffd400045851e R12: 0000000000000000
R13: 0000000000000080 R14: ffffea00022c28c0 R15: 1ffff110124d0d01
FS: 0000555556a2f880(0000) GS:ffff8880aeb00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007ffc5c9d1f18 CR3: 00000000a8a2c000 CR4: 00000000001406e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
---
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
* [PATCH net] ipv6: fix neighbour resolution with raw socket
From: Nicolas Dichtel @ 2019-06-20 12:34 UTC (permalink / raw)
To: davem; +Cc: netdev, Nicolas Dichtel
The scenario is the following: the user uses a raw socket to send an ipv6
packet, destinated to a not-connected network, and specify a connected nh.
Here is the corresponding python script to reproduce this scenario:
import socket
IPPROTO_RAW = 255
send_s = socket.socket(socket.AF_INET6, socket.SOCK_RAW, IPPROTO_RAW)
# scapy
# p = IPv6(src='fd00:100::1', dst='fd00:200::fa')/ICMPv6EchoRequest()
# str(p)
req = b'`\x00\x00\x00\x00\x08:@\xfd\x00\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x01\xfd\x00\x02\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\xfa\x80\x00\x81\xc0\x00\x00\x00\x00'
send_s.sendto(req, ('fd00:175::2', 0, 0, 0))
fd00:175::/64 is a connected route and fd00:200::fa is not a connected
host.
With this scenario, the kernel starts by sending a NS to resolve
fd00:175::2. When it receives the NA, it flushes its queue and try to send
the initial packet. But instead of sending it, it sends another NS to
resolve fd00:200::fa, which obvioulsy fails, thus the packet is dropped. If
the user sends again the packet, it now uses the right nh (fd00:175::2).
The problem is that ip6_dst_lookup_neigh() uses the rt6i_gateway, which is
:: because the associated route is a connected route, thus it uses the dst
addr of the packet. Let's use rt6_nexthop() to choose the right nh.
Note that rt and in6addr_any are const in ip6_dst_lookup_neigh(), thus
let's constify rt6_nexthop() to avoid ugly cast.
Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
---
include/net/ip6_route.h | 4 ++--
net/ipv6/ip6_output.c | 2 +-
net/ipv6/route.c | 3 ++-
3 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/include/net/ip6_route.h b/include/net/ip6_route.h
index 4790beaa86e0..ee7405e759ba 100644
--- a/include/net/ip6_route.h
+++ b/include/net/ip6_route.h
@@ -262,8 +262,8 @@ static inline bool ip6_sk_ignore_df(const struct sock *sk)
inet6_sk(sk)->pmtudisc == IPV6_PMTUDISC_OMIT;
}
-static inline struct in6_addr *rt6_nexthop(struct rt6_info *rt,
- struct in6_addr *daddr)
+static inline const struct in6_addr *rt6_nexthop(const struct rt6_info *rt,
+ const struct in6_addr *daddr)
{
if (rt->rt6i_flags & RTF_GATEWAY)
return &rt->rt6i_gateway;
diff --git a/net/ipv6/ip6_output.c b/net/ipv6/ip6_output.c
index 834475717110..21efcd02f337 100644
--- a/net/ipv6/ip6_output.c
+++ b/net/ipv6/ip6_output.c
@@ -59,8 +59,8 @@ static int ip6_finish_output2(struct net *net, struct sock *sk, struct sk_buff *
{
struct dst_entry *dst = skb_dst(skb);
struct net_device *dev = dst->dev;
+ const struct in6_addr *nexthop;
struct neighbour *neigh;
- struct in6_addr *nexthop;
int ret;
if (ipv6_addr_is_multicast(&ipv6_hdr(skb)->daddr)) {
diff --git a/net/ipv6/route.c b/net/ipv6/route.c
index 11ad62effd56..b6449bc03f11 100644
--- a/net/ipv6/route.c
+++ b/net/ipv6/route.c
@@ -218,7 +218,8 @@ static struct neighbour *ip6_dst_neigh_lookup(const struct dst_entry *dst,
{
const struct rt6_info *rt = container_of(dst, struct rt6_info, dst);
- return ip6_neigh_lookup(&rt->rt6i_gateway, dst->dev, skb, daddr);
+ return ip6_neigh_lookup(rt6_nexthop(rt, &in6addr_any),
+ dst->dev, skb, daddr);
}
static void ip6_confirm_neigh(const struct dst_entry *dst, const void *daddr)
--
2.21.0
^ permalink raw reply related
* [PATCH v2 net-next 2/2] net: dsa: mt7530: Add MT7621 TRGMII mode support
From: René van Dorst @ 2019-06-20 12:21 UTC (permalink / raw)
To: frank-w, sean.wang, f.fainelli, davem, matthias.bgg, andrew,
vivien.didelot
Cc: netdev, john, linux-mediatek, linux-mips, René van Dorst
In-Reply-To: <20190620122155.32078-1-opensource@vdorst.com>
This patch add support TRGMII mode for MT7621 internal MT7530 switch.
MT7621 TRGMII has only one fix speed mode of 1200MBit.
Also adding support for mt7530 25MHz and 40MHz crystal clocksource.
Values are based on Banana Pi R2 bsp [1].
Don't change MT7623 registers on a MT7621 device.
[1] https://github.com/BPI-SINOVOIP/BPI-R2-bsp/blob/master/linux-mt/drivers/net/ethernet/mediatek/gsw_mt7623.c#L769
Signed-off-by: René van Dorst <opensource@vdorst.com>
---
drivers/net/dsa/mt7530.c | 46 +++++++++++++++++++++++++++++++---------
drivers/net/dsa/mt7530.h | 4 ++++
2 files changed, 40 insertions(+), 10 deletions(-)
diff --git a/drivers/net/dsa/mt7530.c b/drivers/net/dsa/mt7530.c
index c7d352da5448..3181e95586d6 100644
--- a/drivers/net/dsa/mt7530.c
+++ b/drivers/net/dsa/mt7530.c
@@ -428,24 +428,48 @@ static int
mt7530_pad_clk_setup(struct dsa_switch *ds, int mode)
{
struct mt7530_priv *priv = ds->priv;
- u32 ncpo1, ssc_delta, trgint, i;
+ u32 ncpo1, ssc_delta, trgint, i, xtal;
+
+ xtal = mt7530_read(priv, MT7530_MHWTRAP) & HWTRAP_XTAL_MASK;
+
+ if (xtal == HWTRAP_XTAL_20MHZ) {
+ dev_err(priv->dev,
+ "%s: MT7530 with a 20MHz XTAL is not supported!\n",
+ __func__);
+ return -EINVAL;
+ }
switch (mode) {
case PHY_INTERFACE_MODE_RGMII:
trgint = 0;
+ /* PLL frequency: 125MHz */
ncpo1 = 0x0c80;
- ssc_delta = 0x87;
break;
case PHY_INTERFACE_MODE_TRGMII:
trgint = 1;
- ncpo1 = 0x1400;
- ssc_delta = 0x57;
+ if (priv->id == ID_MT7621) {
+ /* PLL frequency: 150MHz: 1.2GBit */
+ if (xtal == HWTRAP_XTAL_40MHZ)
+ ncpo1 = 0x0780;
+ if (xtal == HWTRAP_XTAL_25MHZ)
+ ncpo1 = 0x0a00;
+ } else { /* PLL frequency: 250MHz: 2.0Gbit */
+ if (xtal == HWTRAP_XTAL_40MHZ)
+ ncpo1 = 0x0c80;
+ if (xtal == HWTRAP_XTAL_25MHZ)
+ ncpo1 = 0x1400;
+ }
break;
default:
dev_err(priv->dev, "xMII mode %d not supported\n", mode);
return -EINVAL;
}
+ if (xtal == HWTRAP_XTAL_25MHZ)
+ ssc_delta = 0x57;
+ else
+ ssc_delta = 0x87;
+
mt7530_rmw(priv, MT7530_P6ECR, P6_INTF_MODE_MASK,
P6_INTF_MODE(trgint));
@@ -507,7 +531,9 @@ mt7530_pad_clk_setup(struct dsa_switch *ds, int mode)
mt7530_rmw(priv, MT7530_TRGMII_RD(i),
RD_TAP_MASK, RD_TAP(16));
else
- mt7623_trgmii_set(priv, GSW_INTF_MODE, INTF_MODE_TRGMII);
+ if (priv->id != ID_MT7621)
+ mt7623_trgmii_set(priv, GSW_INTF_MODE,
+ INTF_MODE_TRGMII);
return 0;
}
@@ -613,13 +639,13 @@ static void mt7530_adjust_link(struct dsa_switch *ds, int port,
struct mt7530_priv *priv = ds->priv;
if (phy_is_pseudo_fixed_link(phydev)) {
- if (priv->id == ID_MT7530) {
- dev_dbg(priv->dev, "phy-mode for master device = %x\n",
- phydev->interface);
+ dev_dbg(priv->dev, "phy-mode for master device = %x\n",
+ phydev->interface);
- /* Setup TX circuit incluing relevant PAD and driving */
- mt7530_pad_clk_setup(ds, phydev->interface);
+ /* Setup TX circuit incluing relevant PAD and driving */
+ mt7530_pad_clk_setup(ds, phydev->interface);
+ if (priv->id == ID_MT7530) {
/* Setup RX circuit, relevant PAD and driving on the
* host which must be placed after the setup on the
* device side is all finished.
diff --git a/drivers/net/dsa/mt7530.h b/drivers/net/dsa/mt7530.h
index 4331429969fa..bfac90f48102 100644
--- a/drivers/net/dsa/mt7530.h
+++ b/drivers/net/dsa/mt7530.h
@@ -244,6 +244,10 @@ enum mt7530_vlan_port_attr {
/* Register for hw trap status */
#define MT7530_HWTRAP 0x7800
+#define HWTRAP_XTAL_MASK (BIT(10) | BIT(9))
+#define HWTRAP_XTAL_25MHZ (BIT(10) | BIT(9))
+#define HWTRAP_XTAL_40MHZ (BIT(10))
+#define HWTRAP_XTAL_20MHZ (BIT(9))
/* Register for hw trap modification */
#define MT7530_MHWTRAP 0x7804
--
2.20.1
^ permalink raw reply related
* [PATCH v2 net-next 1/2] net: ethernet: mediatek: Add MT7621 TRGMII mode support
From: René van Dorst @ 2019-06-20 12:21 UTC (permalink / raw)
To: frank-w, sean.wang, f.fainelli, davem, matthias.bgg, andrew,
vivien.didelot
Cc: netdev, john, linux-mediatek, linux-mips, René van Dorst
In-Reply-To: <20190620122155.32078-1-opensource@vdorst.com>
MT7621 SOC also supports TRGMII.
TRGMII speed is 1200MBit.
Signed-off-by: René van Dorst <opensource@vdorst.com>
---
drivers/net/ethernet/mediatek/mtk_eth_soc.c | 38 ++++++++++++++++++---
drivers/net/ethernet/mediatek/mtk_eth_soc.h | 11 ++++++
2 files changed, 45 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.c b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
index f27efe4110cc..066712f2e985 100644
--- a/drivers/net/ethernet/mediatek/mtk_eth_soc.c
+++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
@@ -134,6 +134,28 @@ static int mtk_mdio_read(struct mii_bus *bus, int phy_addr, int phy_reg)
return _mtk_mdio_read(eth, phy_addr, phy_reg);
}
+static int mt7621_gmac0_rgmii_adjust(struct mtk_eth *eth,
+ phy_interface_t interface)
+{
+ u32 val;
+
+ /* Check DDR memory type. Currently DDR2 is not supported. */
+ regmap_read(eth->ethsys, ETHSYS_SYSCFG, &val);
+ if (val & SYSCFG_DRAM_TYPE_DDR2) {
+ dev_err(eth->dev,
+ "TRGMII mode with DDR2 memory is not supported!\n");
+ return -EOPNOTSUPP;
+ }
+
+ val = (interface == PHY_INTERFACE_MODE_TRGMII) ?
+ ETHSYS_TRGMII_MT7621_DDR_PLL : 0;
+
+ regmap_update_bits(eth->ethsys, ETHSYS_CLKCFG0,
+ ETHSYS_TRGMII_MT7621_MASK, val);
+
+ return 0;
+}
+
static void mtk_gmac0_rgmii_adjust(struct mtk_eth *eth, int speed)
{
u32 val;
@@ -183,9 +205,17 @@ static void mtk_phy_link_adjust(struct net_device *dev)
break;
}
- if (MTK_HAS_CAPS(mac->hw->soc->caps, MTK_GMAC1_TRGMII) &&
- !mac->id && !mac->trgmii)
- mtk_gmac0_rgmii_adjust(mac->hw, dev->phydev->speed);
+ if (MTK_HAS_CAPS(mac->hw->soc->caps, MTK_GMAC1_TRGMII) && !mac->id) {
+ if (MTK_HAS_CAPS(mac->hw->soc->caps, MTK_TRGMII_MT7621_CLK)) {
+ if (mt7621_gmac0_rgmii_adjust(mac->hw,
+ dev->phydev->interface))
+ return;
+ } else {
+ if (!mac->trgmii)
+ mtk_gmac0_rgmii_adjust(mac->hw,
+ dev->phydev->speed);
+ }
+ }
if (dev->phydev->link)
mcr |= MAC_MCR_FORCE_LINK;
@@ -2607,7 +2637,7 @@ static const struct mtk_soc_data mt2701_data = {
};
static const struct mtk_soc_data mt7621_data = {
- .caps = MTK_SHARED_INT,
+ .caps = MT7621_CAPS,
.required_clks = MT7621_CLKS_BITMAP,
.required_pctl = false,
};
diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.h b/drivers/net/ethernet/mediatek/mtk_eth_soc.h
index 85e3144f1af5..876ce6798709 100644
--- a/drivers/net/ethernet/mediatek/mtk_eth_soc.h
+++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.h
@@ -363,6 +363,10 @@
#define MT7622_ETH 7622
#define MT7621_ETH 7621
+/* ethernet system control register */
+#define ETHSYS_SYSCFG 0x10
+#define SYSCFG_DRAM_TYPE_DDR2 BIT(4)
+
/* ethernet subsystem config register */
#define ETHSYS_SYSCFG0 0x14
#define SYSCFG0_GE_MASK 0x3
@@ -377,6 +381,9 @@
/* ethernet subsystem clock register */
#define ETHSYS_CLKCFG0 0x2c
#define ETHSYS_TRGMII_CLK_SEL362_5 BIT(11)
+#define ETHSYS_TRGMII_MT7621_MASK (BIT(5) | BIT(6))
+#define ETHSYS_TRGMII_MT7621_APLL BIT(6)
+#define ETHSYS_TRGMII_MT7621_DDR_PLL BIT(5)
/* ethernet reset control register */
#define ETHSYS_RSTCTRL 0x34
@@ -616,6 +623,7 @@ enum mtk_eth_path {
#define MTK_SHARED_SGMII BIT(7)
#define MTK_HWLRO BIT(8)
#define MTK_SHARED_INT BIT(9)
+#define MTK_TRGMII_MT7621_CLK BIT(10)
/* Supported path present on SoCs */
#define MTK_PATH_BIT(x) BIT((x) + 10)
@@ -667,6 +675,9 @@ enum mtk_eth_path {
#define MTK_HAS_CAPS(caps, _x) (((caps) & (_x)) == (_x))
+#define MT7621_CAPS (MTK_GMAC1_RGMII | MTK_GMAC1_TRGMII | \
+ MTK_GMAC2_RGMII | MTK_SHARED_INT | MTK_TRGMII_MT7621_CLK)
+
#define MT7622_CAPS (MTK_GMAC1_RGMII | MTK_GMAC1_SGMII | MTK_GMAC2_RGMII | \
MTK_GMAC2_SGMII | MTK_GDM1_ESW | \
MTK_MUX_GDM1_TO_GMAC1_ESW | \
--
2.20.1
^ permalink raw reply related
* [PATCH v2 net-next 0/2] net: mediatek: Add MT7621 TRGMII mode support
From: René van Dorst @ 2019-06-20 12:21 UTC (permalink / raw)
To: frank-w, sean.wang, f.fainelli, davem, matthias.bgg, andrew,
vivien.didelot
Cc: netdev, john, linux-mediatek, linux-mips, René van Dorst
Like many other mediatek SOCs, the MT7621 SOC and the internal MT7530
switch both supports TRGMII mode. MT7621 TRGMII speed is fix 1200MBit.
v1->v2:
- Fix breakage on non MT7621 SOC
- Support 25MHz and 40MHz XTAL as MT7530 clocksource
René van Dorst (2):
net: ethernet: mediatek: Add MT7621 TRGMII mode support
net: dsa: mt7530: Add MT7621 TRGMII mode support
drivers/net/dsa/mt7530.c | 46 ++++++++++++++++-----
drivers/net/dsa/mt7530.h | 4 ++
drivers/net/ethernet/mediatek/mtk_eth_soc.c | 38 +++++++++++++++--
drivers/net/ethernet/mediatek/mtk_eth_soc.h | 11 +++++
4 files changed, 85 insertions(+), 14 deletions(-)
--
2.20.1
^ permalink raw reply
* RE: [EXT] Re: [PATCH net-next 4/4] qed: Add devlink support for configuration attributes.
From: Sudarsana Reddy Kalluru @ 2019-06-20 12:09 UTC (permalink / raw)
To: Jakub Kicinski
Cc: davem@davemloft.net, netdev@vger.kernel.org, Michal Kalderon,
Ariel Elior, Jiri Pirko
In-Reply-To: <20190617155411.53cf07cf@cakuba.netronome.com>
> -----Original Message-----
> From: Jakub Kicinski <jakub.kicinski@netronome.com>
> Sent: Tuesday, June 18, 2019 4:24 AM
> To: Sudarsana Reddy Kalluru <skalluru@marvell.com>
> Cc: davem@davemloft.net; netdev@vger.kernel.org; Michal Kalderon
> <mkalderon@marvell.com>; Ariel Elior <aelior@marvell.com>; Jiri Pirko
> <jiri@resnulli.us>
> Subject: [EXT] Re: [PATCH net-next 4/4] qed: Add devlink support for
> configuration attributes.
>
> External Email
>
> ----------------------------------------------------------------------
> On Mon, 17 Jun 2019 04:45:28 -0700, Sudarsana Reddy Kalluru wrote:
> > This patch adds implementation for devlink callbacks for reading/
> > configuring the device attributes.
> >
> > Signed-off-by: Sudarsana Reddy Kalluru <skalluru@marvell.com>
> > Signed-off-by: Ariel Elior <aelior@marvell.com>
>
> You need to provide documentation for your parameters, plus some of them
> look like they should potentially be port params, not device params.
Thanks a lot for your review. Will add the required documentation. In case of Marvell adapter, any of the device/adapter/port parameters can be read/configurable via any PF (ethdev) on the port. Hence adding the commands at device level. Hope this is fine.
^ permalink raw reply
* Re: [PATCH bpf] samples/bpf: xdp_redirect, correctly get dummy program id
From: Toke Høiland-Jørgensen @ 2019-06-20 11:57 UTC (permalink / raw)
To: Prashant Bhole, Alexei Starovoitov, Daniel Borkmann
Cc: Prashant Bhole, netdev, bpf
In-Reply-To: <20190620065815.7698-1-prashantbhole.linux@gmail.com>
Prashant Bhole <prashantbhole.linux@gmail.com> writes:
> When we terminate xdp_redirect, it ends up with following message:
> "Program on iface OUT changed, not removing"
> This results in dummy prog still attached to OUT interface.
> It is because signal handler checks if the programs are the same that
> we had attached. But while fetching dummy_prog_id, current code uses
> prog_fd instead of dummy_prog_fd. This patch passes the correct fd.
>
> Fixes: 3b7a8ec2dec3 ("samples/bpf: Check the prog id before exiting")
> Signed-off-by: Prashant Bhole <prashantbhole.linux@gmail.com>
Huh, I seem to recall fixing this for the other example program, but
guess I missed this one.
Acked-by: Toke Høiland-Jørgensen <toke@redhat.com>
^ 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