* Re: [PATCH][net-next] net: limit each hash list length to MAX_GRO_SKBS
From: David Miller @ 2018-07-05 1:04 UTC (permalink / raw)
To: lirongqing; +Cc: netdev
In-Reply-To: <1530693768-26845-1-git-send-email-lirongqing@baidu.com>
From: Li RongQing <lirongqing@baidu.com>
Date: Wed, 4 Jul 2018 16:42:48 +0800
> @@ -4989,10 +4988,11 @@ static int napi_gro_complete(struct sk_buff *skb)
> return netif_receive_skb_internal(skb);
> }
>
> -static void __napi_gro_flush_chain(struct napi_struct *napi, struct list_head *head,
> +static void __napi_gro_flush_chain(struct napi_struct *napi, int index,
> bool flush_old)
Hash is usually u32, so please lets make the type consistent. Make index here
a 'u32' and also make 'i' in napi_gro_flush() a 'u32' too.
> @@ -5138,6 +5122,7 @@ static enum gro_result dev_gro_receive(struct napi_struct *napi, struct sk_buff
> enum gro_result ret;
> int same_flow;
> int grow;
> + u32 hash = skb_get_hash_raw(skb) & (GRO_HASH_BUCKETS - 1);
Please preserve reverse christmas tree local variable ordering.
Otherwise this looks great.
Thank you.
^ permalink raw reply
* Re: [PATCH net-next] net: ipv4: fix drop handling in ip_list_rcv() and ip_list_rcv_finish()
From: David Miller @ 2018-07-05 2:26 UTC (permalink / raw)
To: ecree; +Cc: netdev
In-Reply-To: <7b242192-a58d-a4b7-88a6-e04840e75e10@solarflare.com>
From: Edward Cree <ecree@solarflare.com>
Date: Wed, 4 Jul 2018 19:23:50 +0100
> Since callees (ip_rcv_core() and ip_rcv_finish_core()) might free or steal
> the skb, we can't use the list_cut_before() method; we can't even do a
> list_del(&skb->list) in the drop case, because skb might have already been
> freed and reused.
> So instead, take each skb off the source list before processing, and add it
> to the sublist afterwards if it wasn't freed or stolen.
>
> Fixes: 5fa12739a53d net: ipv4: listify ip_rcv_finish
> Fixes: 17266ee93984 net: ipv4: listified version of ip_rcv
> Signed-off-by: Edward Cree <ecree@solarflare.com>
Applied, thanks Edward.
^ permalink raw reply
* Re: [iovisor-dev] [RFC PATCH 00/11] OVS eBPF datapath.
From: William Tu @ 2018-07-05 2:25 UTC (permalink / raw)
To: Alexei Starovoitov
Cc: <dev@openvswitch.org>, Tom Herbert via iovisor-dev,
Linux Kernel Network Developers
In-Reply-To: <20180703175623.fqrrtppjsjimznvv@ast-mbp.dhcp.thefacebook.com>
On Tue, Jul 3, 2018 at 10:56 AM, Alexei Starovoitov
<alexei.starovoitov@gmail.com> wrote:
> On Thu, Jun 28, 2018 at 07:19:35AM -0700, William Tu wrote:
>> Hi Alexei,
>>
>> Thanks a lot for the feedback!
>>
>> On Wed, Jun 27, 2018 at 8:00 PM, Alexei Starovoitov
>> <alexei.starovoitov@gmail.com> wrote:
>> > On Sat, Jun 23, 2018 at 05:16:32AM -0700, William Tu wrote:
>> >>
>> >> Discussion
>> >> ==========
>> >> We are still actively working on finishing the feature, currently
>> >> the basic forwarding and tunnel feature work, but still under
>> >> heavy debugging and development. The purpose of this RFC is to
>> >> get some early feedbacks and direction for finishing the complete
>> >> features in existing kernel's OVS datapath (the net/openvswitch/*).
>> >
>> > Thank you for sharing the patches.
>> >
>> >> Three major issues we are worried:
>> >> a. Megaflow support in BPF.
>> >> b. Connection Tracking support in BPF.
>> >
>> > my opinion on the above two didn't change.
>> > To recap:
>> > A. Non scalable megaflow map is no go. I'd like to see packet classification
>> > algorithm like hicuts or efficuts to be implemented instead, since it can be
>> > shared by generic bpf, bpftiler, ovs and likely others.
>>
>> We did try the decision tree approach using dpdk's acl lib. The lookup
>> speed is 6 times faster than the magaflow using tuple space.
>> However, the update/insertion requires rebuilding/re-balancing the decision
>> tree so it's way too slow. I think hicuts or efficuts suffers the same issue.
>> So decision tree algos are scalable only for lookup operation due to its
>> optimization over tree depth, but not scalable under
>> update/insert/delete operations.
>>
>> On customer's system we see megaflow update/insert rate around 10 rules/sec,
>> this makes decision tree unusable, unless we invent something to optimize the
>> update/insert time or incremental update of these decision tree algo.
>
> is this a typo? you probably meant 10K rule updates a second ?
I mean "new" rules being added at 10 rules/sec.
Update rate might be much higher.
> Last time I've dealt with these algorithms we had 100K acl updates a second.
> It was an important metric that we were optimizing for.
> I'm pretty sure '*cuts' algos do many thousands per second non optimized.
When adding a new rule, do these algorithms require rebuilding the
entire tree?
In our evaluation, updating an existing entry in the decision tree
performs OK, because it is equal to lookup and replace, and lookup
is fast, update is just atomic swap. But inserting a new rule is slow,
because it requires re-building the tree using all existing rules.
And we see new rule being added at rate 10 rules per second.
So we are constantly rebuilding the entire tree.
If the entire tree has 100k of rules, it takes around 2 seconds to rebuild,
based on the dpdk acl library. And without an incremental algorithm,
adding 1 new rule will trigger rebuilding the 100k of rules, and it is too slow.
Reading through HyperCuts and EffiCuts, I'm not sure how it supports
incrementally adding a new rule, without rebuilding the entire tree.
http://ccr.sigcomm.org/online/files/p207.pdf
http://cseweb.ucsd.edu/~susingh/papers/hyp-sigcomm03.pdf
The HyperCuts papers says
"A fast update algorithm can also be implemented; however we do not
go into the details of incremental update in this paper"
>
>> >> c. Verifier limitation.
>> >
>> > Not sure what limitations you're concerned about.
>> >
>>
>> Mostly related to stack. The flow key OVS uses (struct sw_flow_key)
>> is 464 byte. We trim a lot, now around 300 byte, but still huge, considering
>> the BPF's stack limit is 512 byte.
>
> have you tried using per-cpu array of one element with large value
> instead of stack?
yes, now we store the flow key in percpu array with 1 element.
> In the latest verifier most of the operations that can be done with the stack
> pointer can be done with pointer to map value too.
>
Once the flow key is stored in map, another eBPF program
needs to use that key to lookup flow table (another map).
So we have to store the flow key on stack first, in order to
use it as key to lookup the flow table map.
Is there a way to work around it?
Thanks
William
^ permalink raw reply
* Re: [PATCH net] net/ipv6: Revert attempt to simplify route replace and append
From: David Miller @ 2018-07-05 2:29 UTC (permalink / raw)
To: idosch; +Cc: dsahern, dsahern, netdev, sharpd, Thomas.Winter, petrm
In-Reply-To: <20180704211041.GB24525@splinter>
From: Ido Schimmel <idosch@mellanox.com>
Date: Thu, 5 Jul 2018 00:10:41 +0300
> We can have the IPv4/IPv6 code only generate a REPLACE / DELETE
> notification for routes that are actually used for forwarding and
> relieve listeners from the need to implement this logic themselves. I
> think this should work.
Whilst this could reduce the duplication, I worry that in the long
term that this might end up being error prone.
Just my $0.02
^ permalink raw reply
* Re: [PATCH net] net/ipv6: Revert attempt to simplify route replace and append
From: David Ahern @ 2018-07-05 3:01 UTC (permalink / raw)
To: David Miller, idosch; +Cc: dsahern, netdev, sharpd, Thomas.Winter, petrm
In-Reply-To: <20180705.112935.1655283984550635892.davem@davemloft.net>
On 7/4/18 8:29 PM, David Miller wrote:
> From: Ido Schimmel <idosch@mellanox.com>
> Date: Thu, 5 Jul 2018 00:10:41 +0300
>
>> We can have the IPv4/IPv6 code only generate a REPLACE / DELETE
>> notification for routes that are actually used for forwarding and
>> relieve listeners from the need to implement this logic themselves. I
>> think this should work.
>
> Whilst this could reduce the duplication, I worry that in the long
> term that this might end up being error prone.
>
Duplication of data and duplication of logic is not ideal. Especially in
this case where the duplication of both is only to handle one case -
duplicate routes where only the first is programmed. I suspect it will
have to be dealt with at some point (e.g., scaling to a million routes),
but right now there are more important factors to deal with - like the
rtnl_lock. Something to keep in mind for the future.
^ permalink raw reply
* Re: [PATCH net-next] r8169: fix runtime suspend
From: David Miller @ 2018-07-05 4:24 UTC (permalink / raw)
To: hkallweit1; +Cc: nic_swsd, netdev
In-Reply-To: <4f71964c-c777-5d3e-ed6a-1de08f01a079@gmail.com>
From: Heiner Kallweit <hkallweit1@gmail.com>
Date: Wed, 4 Jul 2018 21:11:29 +0200
> When runtime-suspending we configure WoL w/o touching saved_wolopts.
> If saved_wolopts == 0 we would power down the PHY in this case what's
> wrong. Therefore we have to check the actual chip WoL settings here.
>
> Fixes: 433f9d0ddcc6 ("r8169: improve saved_wolopts handling")
> Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH net] qed: Fix reading stale configuration information
From: David Miller @ 2018-07-05 4:27 UTC (permalink / raw)
To: denis.bolotin; +Cc: netdev, ariel.elior
In-Reply-To: <20180704140646.23495-1-denis.bolotin@cavium.com>
From: Denis Bolotin <denis.bolotin@cavium.com>
Date: Wed, 4 Jul 2018 17:06:46 +0300
> Configuration information read at driver load can become stale after it is
> updated. Mark information as not valid and re-populate when this happens.
>
> Signed-off-by: Denis Bolotin <denis.bolotin@cavium.com>
> Signed-off-by: Ariel Elior <ariel.elior@cavium.com>
Applied.
^ permalink raw reply
* KASAN: stack-out-of-bounds Read in __netif_receive_skb_core
From: syzbot @ 2018-07-05 4:59 UTC (permalink / raw)
To: davem, jasowang, linux-kernel, mst, netdev, syzkaller-bugs,
virtualization
Hello,
syzbot found the following crash on:
HEAD commit: 2bdea157b999 Merge branch 'sctp-fully-support-for-dscp-and..
git tree: bpf-next
console output: https://syzkaller.appspot.com/x/log.txt?x=178c5e68400000
kernel config: https://syzkaller.appspot.com/x/.config?x=f62553dc846b0692
dashboard link: https://syzkaller.appspot.com/bug?extid=4e955f82549d361ed655
compiler: gcc (GCC) 8.0.1 20180413 (experimental)
syzkaller repro:https://syzkaller.appspot.com/x/repro.syz?x=15038ad0400000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1465b670400000
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+4e955f82549d361ed655@syzkaller.appspotmail.com
==================================================================
BUG: KASAN: stack-out-of-bounds in __read_once_size
include/linux/compiler.h:188 [inline]
BUG: KASAN: stack-out-of-bounds in __netif_receive_skb_core+0x2e09/0x3680
net/core/dev.c:4657
Read of size 8 at addr ffff8801a852d1e8 by task swapper/0/0
CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.18.0-rc3+ #45
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Call Trace:
<IRQ>
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x1c9/0x2b4 lib/dump_stack.c:113
print_address_description+0x6c/0x20b mm/kasan/report.c:256
kasan_report_error mm/kasan/report.c:354 [inline]
kasan_report.cold.7+0x242/0x2fe mm/kasan/report.c:412
__asan_report_load8_noabort+0x14/0x20 mm/kasan/report.c:433
__read_once_size include/linux/compiler.h:188 [inline]
__netif_receive_skb_core+0x2e09/0x3680 net/core/dev.c:4657
__netif_receive_skb+0x2c/0x1e0 net/core/dev.c:4807
netif_receive_skb_internal+0x12e/0x680 net/core/dev.c:4881
napi_skb_finish net/core/dev.c:5270 [inline]
napi_gro_receive+0x465/0x5c0 net/core/dev.c:5301
receive_buf+0xc97/0x2bf0 drivers/net/virtio_net.c:996
virtnet_receive drivers/net/virtio_net.c:1252 [inline]
virtnet_poll+0x3d5/0xe3d drivers/net/virtio_net.c:1334
napi_poll net/core/dev.c:5926 [inline]
net_rx_action+0x7a5/0x1950 net/core/dev.c:5992
__do_softirq+0x2e8/0xb17 kernel/softirq.c:288
invoke_softirq kernel/softirq.c:368 [inline]
irq_exit+0x1d1/0x200 kernel/softirq.c:408
exiting_irq arch/x86/include/asm/apic.h:527 [inline]
do_IRQ+0xf1/0x190 arch/x86/kernel/irq.c:257
common_interrupt+0xf/0xf arch/x86/entry/entry_64.S:642
</IRQ>
RIP: 0010:native_safe_halt+0x6/0x10 arch/x86/include/asm/irqflags.h:54
Code: c7 48 89 45 d8 e8 7a b1 25 fa 48 8b 45 d8 e9 d2 fe ff ff 48 89 df e8
69 b1 25 fa eb 8a 90 90 90 90 90 90 90 55 48 89 e5 fb f4 <5d> c3 0f 1f 84
00 00 00 00 00 55 48 89 e5 f4 5d c3 90 90 90 90 90
RSP: 0018:ffffffff88e07bc0 EFLAGS: 00000282 ORIG_RAX: ffffffffffffffd9
RAX: dffffc0000000000 RBX: 1ffffffff11c0f7b RCX: ffffffff81667982
RDX: 1ffffffff11e3610 RSI: 0000000000000004 RDI: ffffffff88f1b080
RBP: ffffffff88e07bc0 R08: ffffed003b5c46d7 R09: ffffed003b5c46d6
R10: ffffed003b5c46d6 R11: ffff8801dae236b3 R12: 0000000000000000
R13: ffffffff88e07c78 R14: ffffffff899ebe60 R15: 0000000000000000
arch_safe_halt arch/x86/include/asm/paravirt.h:94 [inline]
default_idle+0xc7/0x450 arch/x86/kernel/process.c:500
arch_cpu_idle+0x10/0x20 arch/x86/kernel/process.c:491
default_idle_call+0x6d/0x90 kernel/sched/idle.c:93
cpuidle_idle_call kernel/sched/idle.c:153 [inline]
do_idle+0x3aa/0x570 kernel/sched/idle.c:262
cpu_startup_entry+0x10c/0x120 kernel/sched/idle.c:368
rest_init+0xe1/0xe4 init/main.c:442
start_kernel+0x90e/0x949 init/main.c:738
x86_64_start_reservations+0x29/0x2b arch/x86/kernel/head64.c:452
x86_64_start_kernel+0x76/0x79 arch/x86/kernel/head64.c:433
secondary_startup_64+0xa5/0xb0 arch/x86/kernel/head_64.S:242
Allocated by task 0:
(stack is not available)
Freed by task 0:
(stack is not available)
The buggy address belongs to the object at ffff8801a852ca80
which belongs to the cache kmalloc-2048 of size 2048
The buggy address is located 1896 bytes inside of
2048-byte region [ffff8801a852ca80, ffff8801a852d280)
The buggy address belongs to the page:
page:ffffea0006a14b00 count:1 mapcount:0 mapping:ffff8801da800c40 index:0x0
compound_mapcount: 0
flags: 0x2fffc0000008100(slab|head)
raw: 02fffc0000008100 ffffea0006c6bd08 ffffea0006c7f688 ffff8801da800c40
raw: 0000000000000000 ffff8801a852c200 0000000100000003 0000000000000000
page dumped because: kasan: bad access detected
Memory state around the buggy address:
ffff8801a852d080: f2 f2 f2 f8 f2 f2 f2 f2 f2 f2 f2 00 f2 f2 f2 00
ffff8801a852d100: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> ffff8801a852d180: 00 00 00 00 f1 f1 f1 f1 00 f2 f2 f2 f2 f2 f2 f2
^
ffff8801a852d200: 00 f2 f2 f2 f2 f2 f2 f2 00 f2 f2 f2 f2 f2 f2 f2
ffff8801a852d280: f8 f2 f2 f2 f2 f2 f2 f2 00 f2 f2 f2 00 00 00 00
==================================================================
---
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#bug-status-tracking 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
* KASAN: stack-out-of-bounds Read in __neigh_create
From: syzbot @ 2018-07-05 4:59 UTC (permalink / raw)
To: adobriyan, davem, dsa, edumazet, fw, keescook, linux-kernel,
netdev, roopa, syzkaller-bugs, w.bumiller
Hello,
syzbot found the following crash on:
HEAD commit: 2bdea157b999 Merge branch 'sctp-fully-support-for-dscp-and..
git tree: bpf-next
console output: https://syzkaller.appspot.com/x/log.txt?x=11d40858400000
kernel config: https://syzkaller.appspot.com/x/.config?x=f62553dc846b0692
dashboard link: https://syzkaller.appspot.com/bug?extid=4dcaeea39647ed97d4c1
compiler: gcc (GCC) 8.0.1 20180413 (experimental)
syzkaller repro:https://syzkaller.appspot.com/x/repro.syz?x=174aae68400000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=120a0a1c400000
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+4dcaeea39647ed97d4c1@syzkaller.appspotmail.com
IPv6: ADDRCONF(NETDEV_CHANGE): veth0: link becomes ready
IPv6: ADDRCONF(NETDEV_CHANGE): bond0: link becomes ready
IPv6: ADDRCONF(NETDEV_UP): team0: link is not ready
8021q: adding VLAN 0 to HW filter on device team0
==================================================================
BUG: KASAN: stack-out-of-bounds in __neigh_create+0x1e93/0x2080
net/core/neighbour.c:522
Read of size 8 at addr ffff8801d4832220 by task kworker/1:2/2005
CPU: 1 PID: 2005 Comm: kworker/1:2 Not tainted 4.18.0-rc3+ #45
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Workqueue: ipv6_addrconf addrconf_dad_work
Call Trace:
------------[ cut here ]------------
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x1c9/0x2b4 lib/dump_stack.c:113
do_IRQ(): syz-executor810 has overflown the kernel stack
(cur:ffff8801d6450000,sp:ffff8801ce2cbd68,irq stk
top-bottom:ffff8801dae00080-ffff8801dae08000,exception stk
top-bottom:fffffe0000007080-fffffe0000011000,ip:lock_release+0x87/0xa30)
WARNING: CPU: 0 PID: 4713 at arch/x86/kernel/irq_64.c:63
stack_overflow_check arch/x86/kernel/irq_64.c:60 [inline]
WARNING: CPU: 0 PID: 4713 at arch/x86/kernel/irq_64.c:63
handle_irq+0x1fb/0x2e7 arch/x86/kernel/irq_64.c:72
Kernel panic - not syncing: panic_on_warn set ...
print_address_description+0x6c/0x20b mm/kasan/report.c:256
kasan_report_error mm/kasan/report.c:354 [inline]
kasan_report.cold.7+0x242/0x2fe mm/kasan/report.c:412
__asan_report_load8_noabort+0x14/0x20 mm/kasan/report.c:433
__neigh_create+0x1e93/0x2080 net/core/neighbour.c:522
ip6_finish_output2+0xa5d/0x2820 net/ipv6/ip6_output.c:117
ip6_finish_output+0x5fe/0xbc0 net/ipv6/ip6_output.c:154
NF_HOOK_COND include/linux/netfilter.h:276 [inline]
ip6_output+0x234/0x9d0 net/ipv6/ip6_output.c:171
dst_output include/net/dst.h:444 [inline]
NF_HOOK include/linux/netfilter.h:287 [inline]
ndisc_send_skb+0x100d/0x1570 net/ipv6/ndisc.c:491
ndisc_send_ns+0x3c1/0x8d0 net/ipv6/ndisc.c:633
addrconf_dad_work+0xbf2/0x1310 net/ipv6/addrconf.c:4061
process_one_work+0xc73/0x1ba0 kernel/workqueue.c:2153
worker_thread+0x189/0x13c0 kernel/workqueue.c:2296
kthread+0x345/0x410 kernel/kthread.c:240
ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:412
CPU: 0 PID: 4713 Comm: syz-executor810 Not tainted 4.18.0-rc3+ #45
Allocated by task 4511:
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
save_stack+0x43/0xd0 mm/kasan/kasan.c:448
Call Trace:
set_track mm/kasan/kasan.c:460 [inline]
kasan_kmalloc+0xc4/0xe0 mm/kasan/kasan.c:553
<IRQ>
__do_kmalloc mm/slab.c:3718 [inline]
__kmalloc_track_caller+0x14a/0x760 mm/slab.c:3733
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x1c9/0x2b4 lib/dump_stack.c:113
kmemdup+0x24/0x50 mm/util.c:118
kmemdup include/linux/string.h:418 [inline]
neigh_parms_alloc+0xea/0x6b0 net/core/neighbour.c:1492
ipv6_add_dev+0x3ec/0x13b0 net/ipv6/addrconf.c:392
panic+0x238/0x4e7 kernel/panic.c:184
addrconf_notify+0x9fb/0x27f0 net/ipv6/addrconf.c:3435
notifier_call_chain+0x180/0x390 kernel/notifier.c:93
__raw_notifier_call_chain kernel/notifier.c:394 [inline]
raw_notifier_call_chain+0x2d/0x40 kernel/notifier.c:401
call_netdevice_notifiers_info+0x3f/0x90 net/core/dev.c:1735
call_netdevice_notifiers net/core/dev.c:1753 [inline]
register_netdevice+0xb9d/0x1100 net/core/dev.c:8183
veth_newlink+0x5f5/0xa70 drivers/net/veth.c:443
rtnl_newlink+0xeff/0x1d60 net/core/rtnetlink.c:3050
__warn.cold.8+0x163/0x1ba kernel/panic.c:536
rtnetlink_rcv_msg+0x46e/0xc30 net/core/rtnetlink.c:4662
netlink_rcv_skb+0x172/0x440 net/netlink/af_netlink.c:2448
rtnetlink_rcv+0x1c/0x20 net/core/rtnetlink.c:4680
report_bug+0x252/0x2d0 lib/bug.c:186
netlink_unicast_kernel net/netlink/af_netlink.c:1310 [inline]
netlink_unicast+0x5a0/0x760 net/netlink/af_netlink.c:1336
fixup_bug arch/x86/kernel/traps.c:178 [inline]
do_error_trap+0x1fc/0x4d0 arch/x86/kernel/traps.c:296
netlink_sendmsg+0xa18/0xfc0 net/netlink/af_netlink.c:1901
sock_sendmsg_nosec net/socket.c:641 [inline]
sock_sendmsg+0xd5/0x120 net/socket.c:651
___sys_sendmsg+0x7fd/0x930 net/socket.c:2125
__sys_sendmsg+0x11d/0x290 net/socket.c:2163
__do_sys_sendmsg net/socket.c:2172 [inline]
__se_sys_sendmsg net/socket.c:2170 [inline]
__x64_sys_sendmsg+0x78/0xb0 net/socket.c:2170
do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe
do_invalid_op+0x1b/0x20 arch/x86/kernel/traps.c:316
invalid_op+0x14/0x20 arch/x86/entry/entry_64.S:992
Freed by task 0:
RIP: 0010:stack_overflow_check arch/x86/kernel/irq_64.c:60 [inline]
RIP: 0010:handle_irq+0x1fb/0x2e7 arch/x86/kernel/irq_64.c:72
(stack is not available)
Code:
00
The buggy address belongs to the object at ffff8801d4832200
which belongs to the cache kmalloc-192 of size 192
00
The buggy address is located 32 bytes inside of
192-byte region [ffff8801d4832200, ffff8801d48322c0)
ff
The buggy address belongs to the page:
b6 80
page:ffffea0007520c80 count:1 mapcount:0 mapping:ffff8801da800040 index:0x0
00
00 00
flags: 0x2fffc0000000100(slab)
raw: 02fffc0000000100 ffffea00074f9d48 ffffea0007526848 ffff8801da800040
48
raw: 0000000000000000 ffff8801d4832000 0000000100000010 0000000000000000
c7 c7
page dumped because: kasan: bad access detected
40
bc
Memory state around the buggy address:
e4
ffff8801d4832100: f1 00 f2 f2 f2 f2 f2 f2 f2 00 f2 f2 f2 f2 f2 f2
87
ffff8801d4832180: f2 00 f2 f2 f2 f2 f2 f2 f2 f8 f2 f2 f2 f2 f2 f2
41
> ffff8801d4832200: f2 00 f2 f2 f2 00 00 00 00 00 00 00 00 00 00 00
54 41
^
55
ffff8801d4832280: 00 00 00 00 00 00 00 00 00 00 f1 f1 f1 f1 00 f2
65
ffff8801d4832300: f2 f2 f2 f2 f2 f2 00 f2 f2 f2 f2 f2 f2 f2 00 f2
48
==================================================================
8b 04
kasan: CONFIG_KASAN_INLINE enabled
25 40 ee 01
kasan: GPF could be caused by NULL-ptr deref or user memory access
00 48 05 68 06
general protection fault: 0000 [#1] SMP KASAN
00 00
CPU: 1 PID: 2005 Comm: kworker/1:2 Tainted: G B 4.18.0-rc3+
#45
48 89
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Workqueue: ipv6_addrconf addrconf_dad_work
c6
e8 85
RIP: 0010:__x86_indirect_thunk_r14+0x10/0x20 arch/x86/lib/retpoline.S:46
b3 1c
Code: 90
00
0f
<0f>
ae e8
0b
eb f9
48 83
4c 89
c4 18
2c 24
e9 3f
c3 0f
ff
1f
ff ff
44
48
00
89 75
00 66
e0 e8
2e 0f
a1 69
1f 84
8f 00
00 00
48 8b
00 00
00 e8
RSP: 0018:ffff8801dae07f58 EFLAGS: 00010082
07 00
00 00
RAX: 0000000000000000 RBX: ffff8801ce1a4000 RCX: 0000000000000000
RDX: 0000000000010000 RSI: ffffffff81631851 RDI: 0000000000000001
f3 90
RBP: ffff8801dae07fb0 R08: ffff8801a9c52400 R09: ffffed003b5c3ec2
R10: ffffed003b5c3ec2 R11: ffff8801dae1f617 R12: fffffe0000011000
0f ae
R13: fffffe0000007080 R14: 0000000000000027 R15: 0000000000000000
e8 eb
f9 4c
89
34 24
do_IRQ+0x78/0x190 arch/x86/kernel/irq.c:245
<c3> 0f
common_interrupt+0xf/0xf arch/x86/entry/entry_64.S:642
1f
</IRQ>
44 00 00 66 2e 0f 1f 84 00 00 00 00 00 e8 07 00 00 00 f3
RSP: 0018:ffff8801cd80ecb8 EFLAGS: 00010293
RAX: ffff8801cd8065c0 RBX: ffff8801d4832200 RCX: ffffffff81601b77
RDX: 0000000000000000 RSI: ffffffff85fb9eaf RDI: ffff8801d6419b40
RBP: ffff8801cd80ef90 R08: fffffbfff1205391 R09: fffffbfff1205390
R10: fffffbfff1205390 R11: ffffffff89029c83 R12: ffffffff8984e080
R13: ffff8801d6419b40 R14: 1ffff1003a906446 R15: ffffffff8984de00
FS: 0000000000000000(0000) GS:ffff8801daf00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007fff2099bb70 CR3: 0000000008e6a000 CR4: 00000000001406e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
ip6_finish_output2+0xa5d/0x2820 net/ipv6/ip6_output.c:117
ip6_finish_output+0x5fe/0xbc0 net/ipv6/ip6_output.c:154
NF_HOOK_COND include/linux/netfilter.h:276 [inline]
ip6_output+0x234/0x9d0 net/ipv6/ip6_output.c:171
dst_output include/net/dst.h:444 [inline]
NF_HOOK include/linux/netfilter.h:287 [inline]
ndisc_send_skb+0x100d/0x1570 net/ipv6/ndisc.c:491
ndisc_send_ns+0x3c1/0x8d0 net/ipv6/ndisc.c:633
addrconf_dad_work+0xbf2/0x1310 net/ipv6/addrconf.c:4061
process_one_work+0xc73/0x1ba0 kernel/workqueue.c:2153
worker_thread+0x189/0x13c0 kernel/workqueue.c:2296
kthread+0x345/0x410 kernel/kthread.c:240
ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:412
Modules linked in:
Dumping ftrace buffer:
(ftrace buffer empty)
Dumping ftrace buffer:
(ftrace buffer empty)
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#bug-status-tracking 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
* general protection fault in smap_list_map_remove
From: syzbot @ 2018-07-05 5:19 UTC (permalink / raw)
To: ast, daniel, linux-kernel, netdev, syzkaller-bugs
Hello,
syzbot found the following crash on:
HEAD commit: 2bdea157b999 Merge branch 'sctp-fully-support-for-dscp-and..
git tree: bpf-next
console output: https://syzkaller.appspot.com/x/log.txt?x=12192e0c400000
kernel config: https://syzkaller.appspot.com/x/.config?x=f62553dc846b0692
dashboard link: https://syzkaller.appspot.com/bug?extid=ef78105c1713053fa8bb
compiler: gcc (GCC) 8.0.1 20180413 (experimental)
syzkaller repro:https://syzkaller.appspot.com/x/repro.syz?x=16b40858400000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=112ab052400000
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+ef78105c1713053fa8bb@syzkaller.appspotmail.com
random: sshd: uninitialized urandom read (32 bytes read)
random: sshd: uninitialized urandom read (32 bytes read)
kasan: CONFIG_KASAN_INLINE enabled
kasan: GPF could be caused by NULL-ptr deref or user memory access
general protection fault: 0000 [#1] SMP KASAN
CPU: 0 PID: 4456 Comm: syz-executor610 Not tainted 4.18.0-rc3+ #45
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
RIP: 0010:do_raw_spin_lock+0x27/0x200 kernel/locking/spinlock_debug.c:111
Code: 00 00 00 48 b8 00 00 00 00 00 fc ff df 55 48 89 e5 41 56 41 55 41 54
53 48 89 fb 48 83 c7 04 48 89 fa 48 c1 ea 03 48 83 ec 08 <0f> b6 14 02 48
89 f8 83 e0 07 83 c0 03 38 d0 7c 08 84 d2 0f 85 7b
RSP: 0018:ffff8801ac2df9c0 EFLAGS: 00010286
RAX: dffffc0000000000 RBX: 0000000000000230 RCX: 0000000000000000
RDX: 0000000000000046 RSI: 0000000000000000 RDI: 0000000000000234
RBP: ffff8801ac2df9e8 R08: 0000000000000001 R09: 0000000000000000
R10: ffffed0035724fa6 R11: ffff8801ab927d33 R12: dffffc0000000000
R13: ffff8801abf962c0 R14: 0000000000000220 R15: 0000000000000000
FS: 00007fcd332e0700(0000) GS:ffff8801dae00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007fff2b4fcd5c CR3: 00000001d1f19000 CR4: 00000000001406f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
__raw_spin_lock_bh include/linux/spinlock_api_smp.h:136 [inline]
_raw_spin_lock_bh+0x39/0x40 kernel/locking/spinlock.c:168
spin_lock_bh include/linux/spinlock.h:315 [inline]
smap_list_map_remove+0x96/0x350 kernel/bpf/sockmap.c:1670
sock_map_ctx_update_elem.isra.21+0x3ab/0x570 kernel/bpf/sockmap.c:1981
sock_map_update_elem+0x1b9/0x3b0 kernel/bpf/sockmap.c:2072
map_update_elem+0x5c4/0xc90 kernel/bpf/syscall.c:765
__do_sys_bpf kernel/bpf/syscall.c:2296 [inline]
__se_sys_bpf kernel/bpf/syscall.c:2267 [inline]
__x64_sys_bpf+0x32d/0x510 kernel/bpf/syscall.c:2267
do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x445d19
Code: e8 2c b7 02 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 2b 12 fc ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:00007fcd332dfce8 EFLAGS: 00000246 ORIG_RAX: 0000000000000141
RAX: ffffffffffffffda RBX: 00000000006dac24 RCX: 0000000000445d19
RDX: 0000000000000020 RSI: 0000000020000180 RDI: 0000000000000002
RBP: 00000000006dac20 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 00007ffd667bb2bf R14: 00007fcd332e09c0 R15: 0000000000000005
Modules linked in:
Dumping ftrace buffer:
(ftrace buffer empty)
---[ end trace fbe082eee969c5a2 ]---
RIP: 0010:do_raw_spin_lock+0x27/0x200 kernel/locking/spinlock_debug.c:111
Code: 00 00 00 48 b8 00 00 00 00 00 fc ff df 55 48 89 e5 41 56 41 55 41 54
53 48 89 fb 48 83 c7 04 48 89 fa 48 c1 ea 03 48 83 ec 08 <0f> b6 14 02 48
89 f8 83 e0 07 83 c0 03 38 d0 7c 08 84 d2 0f 85 7b
RSP: 0018:ffff8801ac2df9c0 EFLAGS: 00010286
RAX: dffffc0000000000 RBX: 0000000000000230 RCX: 0000000000000000
RDX: 0000000000000046 RSI: 0000000000000000 RDI: 0000000000000234
RBP: ffff8801ac2df9e8 R08: 0000000000000001 R09: 0000000000000000
R10: ffffed0035724fa6 R11: ffff8801ab927d33 R12: dffffc0000000000
R13: ffff8801abf962c0 R14: 0000000000000220 R15: 0000000000000000
FS: 00007fcd332e0700(0000) GS:ffff8801dae00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007fff2b4fcd5c CR3: 00000001d1f19000 CR4: 00000000001406f0
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#bug-status-tracking for how to communicate with
syzbot.
syzbot can test patches for this bug, for details see:
https://goo.gl/tpsmEJ#testing-patches
^ permalink raw reply
* Re: [PATCH v2 1/4] samples/bpf: add missing <linux/if_vlan.h>
From: David Miller @ 2018-07-05 5:24 UTC (permalink / raw)
To: treeze.taeung; +Cc: ast, daniel, netdev, linux-kernel
In-Reply-To: <20180704133639.11855-2-treeze.taeung@gmail.com>
From: Taeung Song <treeze.taeung@gmail.com>
Date: Wed, 4 Jul 2018 22:36:36 +0900
> This fixes build error regarding redefinition:
>
> CLANG-bpf samples/bpf/parse_varlen.o
> samples/bpf/parse_varlen.c:111:8: error: redefinition of 'vlan_hdr'
> struct vlan_hdr {
> ^
> ./include/linux/if_vlan.h:38:8: note: previous definition is here
>
> So remove duplicate 'struct vlan_hdr' in sample code and include if_vlan.h
>
> Signed-off-by: Taeung Song <treeze.taeung@gmail.com>
Acked-by: David S. Miller <davem@davemloft.net>
^ permalink raw reply
* Re: [PATCH v2 2/4] samples/bpf: Check the result of system()
From: David Miller @ 2018-07-05 5:24 UTC (permalink / raw)
To: treeze.taeung; +Cc: ast, daniel, netdev, linux-kernel, qinteng
In-Reply-To: <20180704133639.11855-3-treeze.taeung@gmail.com>
From: Taeung Song <treeze.taeung@gmail.com>
Date: Wed, 4 Jul 2018 22:36:37 +0900
> To avoid the below build warning message,
> use new generate_load() checking the return value.
>
> ignoring return value of ‘system’, declared with attribute warn_unused_result
>
> And it also refactors the duplicate code of both
> test_perf_event_all_cpu() and test_perf_event_task()
>
> Cc: Teng Qin <qinteng@fb.com>
> Signed-off-by: Taeung Song <treeze.taeung@gmail.com>
Acked-by: David S. Miller <davem@davemloft.net>
^ permalink raw reply
* Re: [PATCH v2 3/4] samples/bpf: Check the error of write() and read()
From: David Miller @ 2018-07-05 5:24 UTC (permalink / raw)
To: treeze.taeung; +Cc: ast, daniel, netdev, linux-kernel
In-Reply-To: <20180704133639.11855-4-treeze.taeung@gmail.com>
From: Taeung Song <treeze.taeung@gmail.com>
Date: Wed, 4 Jul 2018 22:36:38 +0900
> test_task_rename() and test_urandom_read()
> can be failed during write() and read(),
> So check the result of them.
>
> Reviewed-by: David Laight <David.Laight@ACULAB.COM>
> Signed-off-by: Taeung Song <treeze.taeung@gmail.com>
Acked-by: David S. Miller <davem@davemloft.net>
^ permalink raw reply
* Re: [PATCH v2 4/4] samples/bpf: add .gitignore file
From: David Miller @ 2018-07-05 5:24 UTC (permalink / raw)
To: treeze.taeung; +Cc: ast, daniel, netdev, linux-kernel
In-Reply-To: <20180704133639.11855-5-treeze.taeung@gmail.com>
From: Taeung Song <treeze.taeung@gmail.com>
Date: Wed, 4 Jul 2018 22:36:39 +0900
> For untracked executables of samples/bpf, add this.
>
> Untracked files:
> (use "git add <file>..." to include in what will be committed)
>
> samples/bpf/cpustat
> samples/bpf/fds_example
> samples/bpf/lathist
> samples/bpf/load_sock_ops
> ...
>
> Signed-off-by: Taeung Song <treeze.taeung@gmail.com>
Acked-by: David S. Miller <davem@davemloft.net>
^ permalink raw reply
* Re: [PATCH] tipc: mark expected switch fall-throughs
From: Ying Xue @ 2018-07-05 5:57 UTC (permalink / raw)
To: Gustavo A. R. Silva, Jon Maloy, David S. Miller
Cc: netdev, tipc-discussion, linux-kernel
In-Reply-To: <20180704211359.GA9836@embeddedor.com>
On 07/05/2018 05:13 AM, Gustavo A. R. Silva wrote:
> In preparation to enabling -Wimplicit-fallthrough, mark switch cases
> where we are expecting to fall through.
>
> Warning level 2 was used: -Wimplicit-fallthrough=2
>
> Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
Acked-by: Ying Xue <ying.xue@windriver.com>
> ---
> net/tipc/bearer.c | 1 +
> net/tipc/link.c | 1 +
> 2 files changed, 2 insertions(+)
>
> diff --git a/net/tipc/bearer.c b/net/tipc/bearer.c
> index 2dfb492..fd6d8f1 100644
> --- a/net/tipc/bearer.c
> +++ b/net/tipc/bearer.c
> @@ -610,6 +610,7 @@ static int tipc_l2_device_event(struct notifier_block *nb, unsigned long evt,
> case NETDEV_CHANGE:
> if (netif_carrier_ok(dev))
> break;
> + /* else: fall through */
> case NETDEV_UP:
> test_and_set_bit_lock(0, &b->up);
> break;
> diff --git a/net/tipc/link.c b/net/tipc/link.c
> index 695acb7..6386032 100644
> --- a/net/tipc/link.c
> +++ b/net/tipc/link.c
> @@ -1063,6 +1063,7 @@ static bool tipc_data_input(struct tipc_link *l, struct sk_buff *skb,
> skb_queue_tail(mc_inputq, skb);
> return true;
> }
> + /* else: fall through */
> case CONN_MANAGER:
> skb_queue_tail(inputq, skb);
> return true;
>
^ permalink raw reply
* Re: [PATCH v2 00/14] ravb/sh_eth: fix sleep in atomic by reusing shared ethtool handlers
From: Vladimir Zapolskiy @ 2018-07-05 5:59 UTC (permalink / raw)
To: David Miller; +Cc: sergei.shtylyov, andrew, geert, netdev, linux-renesas-soc
In-Reply-To: <20180705.095631.647119741817887082.davem@davemloft.net>
Hi David,
On 07/05/2018 03:56 AM, David Miller wrote:
> From: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com>
> Date: Wed, 4 Jul 2018 11:12:38 +0300
>
>> For ages trivial changes to RAVB and SuperH ethernet links by means of
>> standard 'ethtool' trigger a 'sleeping function called from invalid
>> context' bug, to visualize it on r8a7795 ULCB:
> ...
>> The root cause is that an attempt to modify ECMR and GECMR registers
>> only when RX/TX function is disabled was too overcomplicated in its
>> original implementation, also processing of an optional Link Change
>> interrupt added even more complexity, as a result the implementation
>> was error prone.
>>
>> The new locking scheme is confirmed to be correct by dumping driver
>> specific and generic PHY framework function calls with aid of ftrace
>> while running more or less advanced tests.
>>
>> Please note that sh_eth patches from the series were built-tested only.
>>
>> On purpose I do not add Fixes tags, the reused PHY handlers were added
>> way later than the fixed problems were firstly found in the drivers.
>>
>> Changes from v1 to v2:
>> * the original patches are split to bugfixes and enhancements only,
>> both v1 and v2 series are absolutely equal in total, thus I omit
>> description of changes in individual patches,
>> * the latter implies that there should be no strict need for retesting,
>> but because formally two series are different, I have to drop the tags
>> given by Geert and Andrew, please send your tags again.
>
> These changes look fine to me but I want to see some reviews and/or
> testing before I apply them.
>
Thanks to Geert for finding time to test v1 series, the sums of changes
are word for word, https://www.spinics.net/lists/linux-renesas-soc/msg28666.html
Andrew also gave a number of Reviewed-by tags, but they are not directly
applicable to new patches, unfortunately.
In any case let's wait for scrupulous review completed by Sergei, I believe
he'd like to contribute to the review process, and Sergei may highlight more
shortcomings.
^ permalink raw reply
* Re: [PATCH v2 08/14] ravb: fix invalid context bug while calling auto-negotiation by ethtool
From: Vladimir Zapolskiy @ 2018-07-05 6:09 UTC (permalink / raw)
To: Sergei Shtylyov, David S . Miller
Cc: Andrew Lunn, Geert Uytterhoeven, netdev, linux-renesas-soc
In-Reply-To: <20180704081451.7482-4-vladimir_zapolskiy@mentor.com>
On 07/04/2018 11:14 AM, Vladimir Zapolskiy wrote:
> Since commit 35b5f6b1a82b ("PHYLIB: Locking fixes for PHY I/O
> potentially sleeping") phy_start_aneg() function utilizes a mutex
> to serialize changes to phy state, however the helper function is
> called in atomic context.
>
> The bug can be reproduced by running "ethtool -r" command, the bug
> is reported if CONFIG_DEBUG_ATOMIC_SLEEP build option is enabled.
>
> Fixes: a0d2f20650e8 ("Renesas Ethernet AVB PTP clock driver")
Here is an invalid commit specified, the proper tag is
Fixes: c156633f1353 ("Renesas Ethernet AVB driver proper")
^ permalink raw reply
* Re: [PATCH v2 09/14] ravb: fix invalid context bug while changing link options by ethtool
From: Vladimir Zapolskiy @ 2018-07-05 6:09 UTC (permalink / raw)
To: Sergei Shtylyov, David S . Miller
Cc: Andrew Lunn, Geert Uytterhoeven, netdev, linux-renesas-soc
In-Reply-To: <20180704081451.7482-5-vladimir_zapolskiy@mentor.com>
On 07/04/2018 11:14 AM, Vladimir Zapolskiy wrote:
> The change fixes sleep in atomic context bug, which is encountered
> every time when link settings are changed by ethtool.
>
> Since commit 35b5f6b1a82b ("PHYLIB: Locking fixes for PHY I/O
> potentially sleeping") phy_start_aneg() function utilizes a mutex
> to serialize changes to phy state, however that helper function is
> called in atomic context under a grabbed spinlock, because
> phy_start_aneg() is called by phy_ethtool_ksettings_set() and by
> replaced phy_ethtool_sset() helpers from phylib.
>
> Now duplex mode setting is enforced in ravb_adjust_link() only, also
> now RX/TX is disabled when link is put down or modifications to E-MAC
> registers ECMR and GECMR are expected for both cases of checked and
> ignored link status pin state from E-MAC interrupt handler.
>
> Fixes: a0d2f20650e8 ("Renesas Ethernet AVB PTP clock driver")
Here is an invalid commit specified, the proper tag is
Fixes: c156633f1353 ("Renesas Ethernet AVB driver proper")
^ permalink raw reply
* [PATCH][net-next][v2] net: limit each hash list length to MAX_GRO_SKBS
From: Li RongQing @ 2018-07-05 6:34 UTC (permalink / raw)
To: netdev
After commit 07d78363dcff ("net: Convert NAPI gro list into a small hash
table.")' there is 8 hash buckets, which allows more flows to be held for
merging. but MAX_GRO_SKBS, the total held skb for merging, is 8 skb still,
limit the hash table performance.
keep MAX_GRO_SKBS as 8 skb, but limit each hash list length to 8 skb, not
the total 8 skb
Signed-off-by: Li RongQing <lirongqing@baidu.com>
---
include/linux/netdevice.h | 7 +++++-
net/core/dev.c | 56 +++++++++++++++++++----------------------------
2 files changed, 29 insertions(+), 34 deletions(-)
diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index 8bf8d6149f79..3b60ac51ddba 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -302,6 +302,11 @@ struct netdev_boot_setup {
int __init netdev_boot_setup(char *str);
+struct gro_list {
+ struct list_head list;
+ int count;
+};
+
/*
* Structure for NAPI scheduling similar to tasklet but with weighting
*/
@@ -323,7 +328,7 @@ struct napi_struct {
int poll_owner;
#endif
struct net_device *dev;
- struct list_head gro_hash[GRO_HASH_BUCKETS];
+ struct gro_list gro_hash[GRO_HASH_BUCKETS];
struct sk_buff *skb;
struct hrtimer timer;
struct list_head dev_list;
diff --git a/net/core/dev.c b/net/core/dev.c
index 08d58e0debe5..38c58e32f5bc 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -149,7 +149,6 @@
#include "net-sysfs.h"
-/* Instead of increasing this, you should create a hash table. */
#define MAX_GRO_SKBS 8
/* This should be increased if a protocol with a bigger head is added. */
@@ -4989,9 +4988,10 @@ static int napi_gro_complete(struct sk_buff *skb)
return netif_receive_skb_internal(skb);
}
-static void __napi_gro_flush_chain(struct napi_struct *napi, struct list_head *head,
+static void __napi_gro_flush_chain(struct napi_struct *napi, u32 index,
bool flush_old)
{
+ struct list_head *head = &napi->gro_hash[index].list;
struct sk_buff *skb, *p;
list_for_each_entry_safe_reverse(skb, p, head, list) {
@@ -5000,22 +5000,20 @@ static void __napi_gro_flush_chain(struct napi_struct *napi, struct list_head *h
list_del_init(&skb->list);
napi_gro_complete(skb);
napi->gro_count--;
+ napi->gro_hash[index].count--;
}
}
-/* napi->gro_hash contains packets ordered by age.
+/* napi->gro_hash[].list contains packets ordered by age.
* youngest packets at the head of it.
* Complete skbs in reverse order to reduce latencies.
*/
void napi_gro_flush(struct napi_struct *napi, bool flush_old)
{
- int i;
-
- for (i = 0; i < GRO_HASH_BUCKETS; i++) {
- struct list_head *head = &napi->gro_hash[i];
+ u32 i;
- __napi_gro_flush_chain(napi, head, flush_old);
- }
+ for (i = 0; i < GRO_HASH_BUCKETS; i++)
+ __napi_gro_flush_chain(napi, i, flush_old);
}
EXPORT_SYMBOL(napi_gro_flush);
@@ -5027,7 +5025,7 @@ static struct list_head *gro_list_prepare(struct napi_struct *napi,
struct list_head *head;
struct sk_buff *p;
- head = &napi->gro_hash[hash & (GRO_HASH_BUCKETS - 1)];
+ head = &napi->gro_hash[hash & (GRO_HASH_BUCKETS - 1)].list;
list_for_each_entry(p, head, list) {
unsigned long diffs;
@@ -5095,27 +5093,13 @@ static void gro_pull_from_frag0(struct sk_buff *skb, int grow)
}
}
-static void gro_flush_oldest(struct napi_struct *napi)
+static void gro_flush_oldest(struct list_head *head)
{
- struct sk_buff *oldest = NULL;
- unsigned long age = jiffies;
- int i;
-
- for (i = 0; i < GRO_HASH_BUCKETS; i++) {
- struct list_head *head = &napi->gro_hash[i];
- struct sk_buff *skb;
-
- if (list_empty(head))
- continue;
+ struct sk_buff *oldest;
- skb = list_last_entry(head, struct sk_buff, list);
- if (!oldest || time_before(NAPI_GRO_CB(skb)->age, age)) {
- oldest = skb;
- age = NAPI_GRO_CB(skb)->age;
- }
- }
+ oldest = list_last_entry(head, struct sk_buff, list);
- /* We are called with napi->gro_count >= MAX_GRO_SKBS, so this is
+ /* We are called with head length >= MAX_GRO_SKBS, so this is
* impossible.
*/
if (WARN_ON_ONCE(!oldest))
@@ -5130,6 +5114,7 @@ static void gro_flush_oldest(struct napi_struct *napi)
static enum gro_result dev_gro_receive(struct napi_struct *napi, struct sk_buff *skb)
{
+ u32 hash = skb_get_hash_raw(skb) & (GRO_HASH_BUCKETS - 1);
struct list_head *head = &offload_base;
struct packet_offload *ptype;
__be16 type = skb->protocol;
@@ -5196,6 +5181,7 @@ static enum gro_result dev_gro_receive(struct napi_struct *napi, struct sk_buff
list_del_init(&pp->list);
napi_gro_complete(pp);
napi->gro_count--;
+ napi->gro_hash[hash].count--;
}
if (same_flow)
@@ -5204,10 +5190,11 @@ static enum gro_result dev_gro_receive(struct napi_struct *napi, struct sk_buff
if (NAPI_GRO_CB(skb)->flush)
goto normal;
- if (unlikely(napi->gro_count >= MAX_GRO_SKBS)) {
- gro_flush_oldest(napi);
+ if (unlikely(napi->gro_hash[hash].count >= MAX_GRO_SKBS)) {
+ gro_flush_oldest(gro_head);
} else {
napi->gro_count++;
+ napi->gro_hash[hash].count++;
}
NAPI_GRO_CB(skb)->count = 1;
NAPI_GRO_CB(skb)->age = jiffies;
@@ -5844,8 +5831,10 @@ void netif_napi_add(struct net_device *dev, struct napi_struct *napi,
hrtimer_init(&napi->timer, CLOCK_MONOTONIC, HRTIMER_MODE_REL_PINNED);
napi->timer.function = napi_watchdog;
napi->gro_count = 0;
- for (i = 0; i < GRO_HASH_BUCKETS; i++)
- INIT_LIST_HEAD(&napi->gro_hash[i]);
+ for (i = 0; i < GRO_HASH_BUCKETS; i++) {
+ INIT_LIST_HEAD(&napi->gro_hash[i].list);
+ napi->gro_hash[i].count = 0;
+ }
napi->skb = NULL;
napi->poll = poll;
if (weight > NAPI_POLL_WEIGHT)
@@ -5885,8 +5874,9 @@ static void flush_gro_hash(struct napi_struct *napi)
for (i = 0; i < GRO_HASH_BUCKETS; i++) {
struct sk_buff *skb, *n;
- list_for_each_entry_safe(skb, n, &napi->gro_hash[i], list)
+ list_for_each_entry_safe(skb, n, &napi->gro_hash[i].list, list)
kfree_skb(skb);
+ napi->gro_hash[i].count = 0;
}
}
--
2.16.2
^ permalink raw reply related
* Re: general protection fault in rds_ib_get_mr
From: Johannes Thumshirn @ 2018-07-05 7:06 UTC (permalink / raw)
To: santosh.shilimkar@oracle.com
Cc: Eric Biggers, linux-rdma, rds-devel, syzbot, davem, linux-kernel,
netdev, syzkaller-bugs
In-Reply-To: <04c882dc-332e-92d6-fe76-b1dd3bedd71c@oracle.com>
On Wed, Jul 04, 2018 at 05:32:20PM -0700, santosh.shilimkar@oracle.com wrote:
> On 7/4/18 2:35 PM, Eric Biggers wrote:
> > On Sun, May 13, 2018 at 10:46:37PM -0700, santosh.shilimkar@oracle.com wrote:
> > > On 5/13/18 2:10 PM, Eric Biggers wrote:
> > > > On Wed, Mar 21, 2018 at 09:00:01AM -0700, syzbot wrote:
> > >
> > > [...]
> > >
> > >
> > > > Still reproducible on Linus' tree (commit 66e1c94db3cd4) and linux-next
> > > > (next-20180511). Here's a simplified reproducer:
> > > >
> > > Thanks for the test case !!
> > >
>
> [...]
>
> >
> > Ping; this RDS bug is still unfixed. The same reproducer I gave earlier still
> > works, even when run as a non-root user. I tested upstream commit
> > fc36def997cfd6 (v4.18-rc3-113-gfc36def997cfd), and linux-next commit
> > bce40927669338 (next-20180704).
> >
> Yeah I haven't sent a fix for this yet. Downstream we have refactored
> MR code and I wanted to get that upstream. With that this bug will
> also get addressed. I was hoping to get that series but since some
> optimisation is still pending investigations its getting delayed.
>
> Will find out if I can fix this panic in meantime with smaller change.
> Thanks for reminder.
Oh please sent bug fixes _before_ refactoring in that area. Otherwise
it's a pain for everybody backporting the fix to a stable kernel.
Thanks,
Johannes
--
Johannes Thumshirn Storage
jthumshirn@suse.de +49 911 74053 689
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
Key fingerprint = EC38 9CAB C2C4 F25D 8600 D0D0 0393 969D 2D76 0850
^ permalink raw reply
* Re: set_memory_* (was: Re: BUG: unable to handle kernel paging request in bpf_int_jit_compile)
From: Ingo Molnar @ 2018-07-05 7:21 UTC (permalink / raw)
To: Kees Cook
Cc: Daniel Borkmann, David Miller, Thomas Gleixner,
syzbot+a4eb8c7766952a1ca872, Alexei Starovoitov, H. Peter Anvin,
Alexey Kuznetsov, LKML, Ingo Molnar, Network Development,
syzkaller-bugs, X86 ML, Hideaki YOSHIFUJI, Peter Zijlstra,
Laura Abbott, Linus Torvalds, Eric Dumazet, Rik van Riel,
Ard Biesheuvel
In-Reply-To: <CAGXu5jKndtFL7D7T00GmziYaazs7v0t4DWPp_2fdGh2tRnuuEQ@mail.gmail.com>
* Kees Cook <keescook@chromium.org> wrote:
> On Tue, Jun 26, 2018 at 3:53 PM, Daniel Borkmann <daniel@iogearbox.net> wrote:
> > In any case, for pairs like set_memory_ro() + set_memory_rw() that are also used
> > outside of bpf e.g. STRICT_MODULE_RWX and friends which are mostly default these
> > days for some archs, is the choice to not check errors from there by design or from
> > historical context that it originated from 'debugging code' in that sense (DEBUG_RODATA /
> > DEBUG_SET_MODULE_RONX) earlier? Also if no-one checks for errors (and if that would
> > infact be the recommendation it is agreed upon) should the API be changed to void,
> > or generally should actual error checking occur on these + potential rollback; but
> > then question is what about restoring part from prior set_memory_ro() via set_memory_rw()?
> > Kees/others, do you happen to have some more context on recommended use around this
> > by any chance? (Would probably also help if we add some doc around assumptions into
> > include/linux/set_memory.h for future users.)
>
> If set_memory_* can fail, I think it needs to be __must_check, and all
> the callers need to deal with it gracefully. Those markings aren't
> "advisory": they're expected to actually do what they say.
Yes - but there's probably a few exceptions like early init code where the calls
not succeeding are signs of bugs - so any error return should probably be
WARN_ON()ed about.
Thanks,
Ingo
^ permalink raw reply
* Re: [PATCH v2 00/14] ravb/sh_eth: fix sleep in atomic by reusing shared ethtool handlers
From: Geert Uytterhoeven @ 2018-07-05 7:21 UTC (permalink / raw)
To: Vladimir Zapolskiy
Cc: Sergei Shtylyov, David S. Miller, Andrew Lunn, netdev,
Linux-Renesas
In-Reply-To: <20180704081245.7395-1-vladimir_zapolskiy@mentor.com>
Hi Vladimir,
On Wed, Jul 4, 2018 at 10:13 AM Vladimir Zapolskiy
<vladimir_zapolskiy@mentor.com> wrote:
> For ages trivial changes to RAVB and SuperH ethernet links by means of
> standard 'ethtool' trigger a 'sleeping function called from invalid
> context' bug, to visualize it on r8a7795 ULCB:
>
> % ethtool -r eth0
> BUG: sleeping function called from invalid context at kernel/locking/mutex.c:747
> in_atomic(): 1, irqs_disabled(): 128, pid: 554, name: ethtool
> INFO: lockdep is turned off.
> irq event stamp: 0
> hardirqs last enabled at (0): [<0000000000000000>] (null)
> hardirqs last disabled at (0): [<ffff0000080e1d3c>] copy_process.isra.7.part.8+0x2cc/0x1918
> softirqs last enabled at (0): [<ffff0000080e1d3c>] copy_process.isra.7.part.8+0x2cc/0x1918
> softirqs last disabled at (0): [<0000000000000000>] (null)
> CPU: 5 PID: 554 Comm: ethtool Not tainted 4.17.0-rc4-arm64-renesas+ #33
> Hardware name: Renesas H3ULCB board based on r8a7795 ES2.0+ (DT)
> Call trace:
> dump_backtrace+0x0/0x198
> show_stack+0x24/0x30
> dump_stack+0xb8/0xf4
> ___might_sleep+0x1c8/0x1f8
> __might_sleep+0x58/0x90
> __mutex_lock+0x50/0x890
> mutex_lock_nested+0x3c/0x50
> phy_start_aneg_priv+0x38/0x180
> phy_start_aneg+0x24/0x30
> ravb_nway_reset+0x3c/0x68
> dev_ethtool+0x3dc/0x2338
> dev_ioctl+0x19c/0x490
> sock_do_ioctl+0xe0/0x238
> sock_ioctl+0x254/0x460
> do_vfs_ioctl+0xb0/0x918
> ksys_ioctl+0x50/0x80
> sys_ioctl+0x34/0x48
> __sys_trace_return+0x0/0x4
>
> The root cause is that an attempt to modify ECMR and GECMR registers
> only when RX/TX function is disabled was too overcomplicated in its
> original implementation, also processing of an optional Link Change
> interrupt added even more complexity, as a result the implementation
> was error prone.
>
> The new locking scheme is confirmed to be correct by dumping driver
> specific and generic PHY framework function calls with aid of ftrace
> while running more or less advanced tests.
>
> Please note that sh_eth patches from the series were built-tested only.
>
> On purpose I do not add Fixes tags, the reused PHY handlers were added
> way later than the fixed problems were firstly found in the drivers.
>
> Changes from v1 to v2:
> * the original patches are split to bugfixes and enhancements only,
> both v1 and v2 series are absolutely equal in total, thus I omit
> description of changes in individual patches,
> * the latter implies that there should be no strict need for retesting,
> but because formally two series are different, I have to drop the tags
> given by Geert and Andrew, please send your tags again.
Thank for your series!
I've retested this on both R-Car M2-W (sh_eth) and R-Car H3 ES2.0 (ravb),
and the BUG disappeared.
Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH v2 net-next] openvswitch: kernel datapath clone action
From: Pravin Shelar @ 2018-07-05 7:15 UTC (permalink / raw)
To: Yifeng Sun; +Cc: Andy Zhou, Linux Kernel Network Developers
In-Reply-To: <1530544683-15778-1-git-send-email-pkusunyifeng@gmail.com>
On Mon, Jul 2, 2018 at 8:18 AM, Yifeng Sun <pkusunyifeng@gmail.com> wrote:
> Add 'clone' action to kernel datapath by using existing functions.
> When actions within clone don't modify the current flow, the flow
> key is not cloned before executing clone actions.
>
> This is a follow up patch for this incomplete work:
> https://patchwork.ozlabs.org/patch/722096/
>
> v1 -> v2:
> Refactor as advised by reviewer.
>
> Signed-off-by: Yifeng Sun <pkusunyifeng@gmail.com>
> Signed-off-by: Andy Zhou <azhou@ovn.org>
Acked-by: Pravin B Shelar <pshelar@ovn.org>
Thanks.
^ permalink raw reply
* Re: [offlist] Re: Crash in netlink/sk_filter_trim_cap on ARMv7 on 4.18rc1
From: Russell King - ARM Linux @ 2018-07-05 7:31 UTC (permalink / raw)
To: Peter Robinson
Cc: netdev, labbott, linux-arm-kernel, Daniel Borkmann, Eric Dumazet
In-Reply-To: <20180704234154.GT17271@n2100.armlinux.org.uk>
On Thu, Jul 05, 2018 at 12:41:54AM +0100, Russell King - ARM Linux wrote:
> Subject says offlist, but this isn't...
>
> On Wed, Jul 04, 2018 at 08:33:20AM +0100, Peter Robinson wrote:
> > Sorry for the delay on this from my end. I noticed there was some bpf
> > bits land in the last net fixes pull request landed Monday so I built
> > a kernel with the JIT reenabled. It seems it's improved in that the
> > completely dead no output boot has gone but the original problem that
> > arrived in the merge window still persists:
> >
> > [ 17.564142] note: systemd-udevd[194] exited with preempt_count 1
> > [ 17.592739] Unable to handle kernel NULL pointer dereference at
> > virtual address 0000000c
> > [ 17.601002] pgd = (ptrval)
> > [ 17.603819] [0000000c] *pgd=00000000
> > [ 17.607487] Internal error: Oops: 805 [#10] SMP ARM
> > [ 17.612396] Modules linked in:
> > [ 17.615484] CPU: 0 PID: 195 Comm: systemd-udevd Tainted: G D
> > 4.18.0-0.rc3.git1.1.bpf1.fc29.armv7hl #1
> > [ 17.626056] Hardware name: Generic AM33XX (Flattened Device Tree)
> > [ 17.632198] PC is at sk_filter_trim_cap+0x218/0x2fc
> > [ 17.637102] LR is at (null)
> > [ 17.640086] pc : [<c0ab03b4>] lr : [<00000000>] psr: 60000013
> > [ 17.646384] sp : cfe1dd48 ip : 00000000 fp : 00000000
> > [ 17.651635] r10: d837e000 r9 : d833be00 r8 : 00000000
> > [ 17.656887] r7 : 00000001 r6 : e003d000 r5 : 00000000 r4 : 00000000
> > [ 17.663447] r3 : 00000007 r2 : 00000000 r1 : 00000000 r0 : 00000000
> > [ 17.670009] Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none
> > [ 17.677180] Control: 10c5387d Table: 8fe20019 DAC: 00000051
> > [ 17.682956] Process systemd-udevd (pid: 195, stack limit = 0x(ptrval))
> > [ 17.689518] Stack: (0xcfe1dd48 to 0xcfe1e000)
>
> Can you provide a full disassembly of sk_filter_trim_cap from vmlinux
> (iow, annotated with its linked address) for the above dump please -
> alternatively a new dump with matching disassembly. Thanks.
Also probably a good idea to have bpf_jit_enable set to 2 to get a
dump of the bpf program being run, which I think for your problem,
you'll have to hack the kernel source to do that.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 13.8Mbps down 630kbps up
According to speedtest.net: 13Mbps down 490kbps up
^ permalink raw reply
* Re: [offlist] Re: Crash in netlink/sk_filter_trim_cap on ARMv7 on 4.18rc1
From: Daniel Borkmann @ 2018-07-05 7:46 UTC (permalink / raw)
To: Russell King - ARM Linux, Peter Robinson
Cc: netdev, labbott, linux-arm-kernel, Eric Dumazet
In-Reply-To: <20180705073120.GU17271@n2100.armlinux.org.uk>
On 07/05/2018 09:31 AM, Russell King - ARM Linux wrote:
> On Thu, Jul 05, 2018 at 12:41:54AM +0100, Russell King - ARM Linux wrote:
>> Subject says offlist, but this isn't...
>>
>> On Wed, Jul 04, 2018 at 08:33:20AM +0100, Peter Robinson wrote:
>>> Sorry for the delay on this from my end. I noticed there was some bpf
>>> bits land in the last net fixes pull request landed Monday so I built
>>> a kernel with the JIT reenabled. It seems it's improved in that the
>>> completely dead no output boot has gone but the original problem that
>>> arrived in the merge window still persists:
>>>
>>> [ 17.564142] note: systemd-udevd[194] exited with preempt_count 1
>>> [ 17.592739] Unable to handle kernel NULL pointer dereference at
>>> virtual address 0000000c
>>> [ 17.601002] pgd = (ptrval)
>>> [ 17.603819] [0000000c] *pgd=00000000
>>> [ 17.607487] Internal error: Oops: 805 [#10] SMP ARM
>>> [ 17.612396] Modules linked in:
>>> [ 17.615484] CPU: 0 PID: 195 Comm: systemd-udevd Tainted: G D
>>> 4.18.0-0.rc3.git1.1.bpf1.fc29.armv7hl #1
>>> [ 17.626056] Hardware name: Generic AM33XX (Flattened Device Tree)
>>> [ 17.632198] PC is at sk_filter_trim_cap+0x218/0x2fc
>>> [ 17.637102] LR is at (null)
>>> [ 17.640086] pc : [<c0ab03b4>] lr : [<00000000>] psr: 60000013
>>> [ 17.646384] sp : cfe1dd48 ip : 00000000 fp : 00000000
>>> [ 17.651635] r10: d837e000 r9 : d833be00 r8 : 00000000
>>> [ 17.656887] r7 : 00000001 r6 : e003d000 r5 : 00000000 r4 : 00000000
>>> [ 17.663447] r3 : 00000007 r2 : 00000000 r1 : 00000000 r0 : 00000000
>>> [ 17.670009] Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none
>>> [ 17.677180] Control: 10c5387d Table: 8fe20019 DAC: 00000051
>>> [ 17.682956] Process systemd-udevd (pid: 195, stack limit = 0x(ptrval))
>>> [ 17.689518] Stack: (0xcfe1dd48 to 0xcfe1e000)
>>
>> Can you provide a full disassembly of sk_filter_trim_cap from vmlinux
>> (iow, annotated with its linked address) for the above dump please -
>> alternatively a new dump with matching disassembly. Thanks.
>
> Also probably a good idea to have bpf_jit_enable set to 2 to get a
> dump of the bpf program being run, which I think for your problem,
> you'll have to hack the kernel source to do that.
Agree, that would be good as well. You could use something like the below
to bail out to interpreter after JIT did the dump.
Dump will then land in kernel log which you could paste here.
diff --git a/arch/arm/net/bpf_jit_32.c b/arch/arm/net/bpf_jit_32.c
index f6a62ae..d6a7dfd 100644
--- a/arch/arm/net/bpf_jit_32.c
+++ b/arch/arm/net/bpf_jit_32.c
@@ -1844,6 +1844,13 @@ struct bpf_prog *bpf_int_jit_compile(struct bpf_prog *prog)
/* there are 2 passes here */
bpf_jit_dump(prog->len, image_size, 2, ctx.target);
+ /* Defer to interpreter after dump. */
+ if (1) {
+ bpf_jit_binary_free(header);
+ prog = orig_prog;
+ goto out_imms;
+ }
+
bpf_jit_binary_lock_ro(header);
prog->bpf_func = (void *)ctx.target;
prog->jited = 1;
^ permalink raw reply related
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