* Re: pull-request: ieee802154 for net 2018-07-11
From: David Miller @ 2018-07-12 7:19 UTC (permalink / raw)
To: stefan; +Cc: linux-wpan, alex.aring, netdev
In-Reply-To: <20180711152653.28579-1-stefan@datenfreihafen.org>
From: Stefan Schmidt <stefan@datenfreihafen.org>
Date: Wed, 11 Jul 2018 11:26:53 -0400
> An update from ieee802154 for your *net* tree.
>
> Build system fix for a missing include from Arnd Bergmann.
> Setting the IFLA_LINK for the lowpan parent from Lubomir Rintel.
> Fixes for some RX corner cases in adf7242 driver by Michael Hennerich.
> And some small patches to cleanup our BUG_ON vs WARN_ON usage.
Pulled, thanks.
^ permalink raw reply
* [PATCH net-next] net: gro: properly remove skb from list
From: Prashant Bhole @ 2018-07-12 7:24 UTC (permalink / raw)
To: David S . Miller
Cc: Prashant Bhole, Jesper Dangaard Brouer, Tyler Hicks, netdev
Following crash occurs in validate_xmit_skb_list() when same skb is
iterated multiple times in the loop and consume_skb() is called.
The root cause is calling list_del_init(&skb->list) and not clearing
skb->next in d4546c2509b1. list_del_init(&skb->list) sets skb->next
to point to skb itself. skb->next needs to be cleared because other
parts of network stack uses another kind of SKB lists.
validate_xmit_skb_list() uses such list.
A similar type of bugfix was reported by Jesper Dangaard Brouer.
https://patchwork.ozlabs.org/patch/942541/
This patch clears skb->next and changes list_del_init() to list_del()
so that list->prev will maintain the list poison.
[ 148.185511] ==================================================================
[ 148.187865] BUG: KASAN: use-after-free in validate_xmit_skb_list+0x4b/0xa0
[ 148.190158] Read of size 8 at addr ffff8801e52eefc0 by task swapper/1/0
[ 148.192940]
[ 148.193642] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 4.18.0-rc3+ #25
[ 148.195423] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS ?-20180531_142017-buildhw-08.phx2.fedoraproject.org-1.fc28 04/01/2014
[ 148.199129] Call Trace:
[ 148.200565] <IRQ>
[ 148.201911] dump_stack+0xc6/0x14c
[ 148.203572] ? dump_stack_print_info.cold.1+0x2f/0x2f
[ 148.205083] ? kmsg_dump_rewind_nolock+0x59/0x59
[ 148.206307] ? validate_xmit_skb+0x2c6/0x560
[ 148.207432] ? debug_show_held_locks+0x30/0x30
[ 148.208571] ? validate_xmit_skb_list+0x4b/0xa0
[ 148.211144] print_address_description+0x6c/0x23c
[ 148.212601] ? validate_xmit_skb_list+0x4b/0xa0
[ 148.213782] kasan_report.cold.6+0x241/0x2fd
[ 148.214958] validate_xmit_skb_list+0x4b/0xa0
[ 148.216494] sch_direct_xmit+0x1b0/0x680
[ 148.217601] ? dev_watchdog+0x4e0/0x4e0
[ 148.218675] ? do_raw_spin_trylock+0x10/0x120
[ 148.219818] ? do_raw_spin_lock+0xe0/0xe0
[ 148.221032] __dev_queue_xmit+0x1167/0x1810
[ 148.222155] ? sched_clock+0x5/0x10
[...]
[ 148.474257] Allocated by task 0:
[ 148.475363] kasan_kmalloc+0xbf/0xe0
[ 148.476503] kmem_cache_alloc+0xb4/0x1b0
[ 148.477654] __build_skb+0x91/0x250
[ 148.478677] build_skb+0x67/0x180
[ 148.479657] e1000_clean_rx_irq+0x542/0x8a0
[ 148.480757] e1000_clean+0x652/0xd10
[ 148.481772] net_rx_action+0x4ea/0xc20
[ 148.482808] __do_softirq+0x1f9/0x574
[ 148.483831]
[ 148.484575] Freed by task 0:
[ 148.485504] __kasan_slab_free+0x12e/0x180
[ 148.486589] kmem_cache_free+0xb4/0x240
[ 148.487634] kfree_skbmem+0xed/0x150
[ 148.488648] consume_skb+0x146/0x250
[ 148.489665] validate_xmit_skb+0x2b7/0x560
[ 148.490754] validate_xmit_skb_list+0x70/0xa0
[ 148.491897] sch_direct_xmit+0x1b0/0x680
[ 148.493949] __dev_queue_xmit+0x1167/0x1810
[ 148.495103] br_dev_queue_push_xmit+0xce/0x250
[ 148.496196] br_forward_finish+0x276/0x280
[ 148.497234] __br_forward+0x44f/0x520
[ 148.498260] br_forward+0x19f/0x1b0
[ 148.499264] br_handle_frame_finish+0x65e/0x980
[ 148.500398] NF_HOOK.constprop.10+0x290/0x2a0
[ 148.501522] br_handle_frame+0x417/0x640
[ 148.502582] __netif_receive_skb_core+0xaac/0x18f0
[ 148.503753] __netif_receive_skb_one_core+0x98/0x120
[ 148.504958] netif_receive_skb_internal+0xe3/0x330
[ 148.506154] napi_gro_complete+0x190/0x2a0
[ 148.507243] dev_gro_receive+0x9f7/0x1100
[ 148.508316] napi_gro_receive+0xcb/0x260
[ 148.509387] e1000_clean_rx_irq+0x2fc/0x8a0
[ 148.510501] e1000_clean+0x652/0xd10
[ 148.511523] net_rx_action+0x4ea/0xc20
[ 148.512566] __do_softirq+0x1f9/0x574
[ 148.513598]
[ 148.514346] The buggy address belongs to the object at ffff8801e52eefc0
[ 148.514346] which belongs to the cache skbuff_head_cache of size 232
[ 148.517047] The buggy address is located 0 bytes inside of
[ 148.517047] 232-byte region [ffff8801e52eefc0, ffff8801e52ef0a8)
[ 148.519549] The buggy address belongs to the page:
[ 148.520726] page:ffffea000794bb00 count:1 mapcount:0 mapping:ffff880106f4dfc0 index:0xffff8801e52ee840 compound_mapcount: 0
[ 148.524325] flags: 0x17ffffc0008100(slab|head)
[ 148.525481] raw: 0017ffffc0008100 ffff880106b938d0 ffff880106b938d0 ffff880106f4dfc0
[ 148.527503] raw: ffff8801e52ee840 0000000000190011 00000001ffffffff 0000000000000000
[ 148.529547] page dumped because: kasan: bad access detected
Fixes: d4546c2509b1 ("net: Convert GRO SKB handling to list_head.")
Signed-off-by: Prashant Bhole <bhole_prashant_q7@lab.ntt.co.jp>
Reported-by: Tyler Hicks <tyhicks@canonical.com>
---
net/core/dev.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/net/core/dev.c b/net/core/dev.c
index d13cddcac41f..08c41941f912 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -5169,7 +5169,8 @@ static void __napi_gro_flush_chain(struct napi_struct *napi, u32 index,
list_for_each_entry_safe_reverse(skb, p, head, list) {
if (flush_old && NAPI_GRO_CB(skb)->age == jiffies)
return;
- list_del_init(&skb->list);
+ list_del(&skb->list);
+ skb->next = NULL;
napi_gro_complete(skb);
napi->gro_count--;
napi->gro_hash[index].count--;
@@ -5350,7 +5351,8 @@ static enum gro_result dev_gro_receive(struct napi_struct *napi, struct sk_buff
ret = NAPI_GRO_CB(skb)->free ? GRO_MERGED_FREE : GRO_MERGED;
if (pp) {
- list_del_init(&pp->list);
+ list_del(&pp->list);
+ pp->next = NULL;
napi_gro_complete(pp);
napi->gro_count--;
napi->gro_hash[hash].count--;
--
2.17.1
^ permalink raw reply related
* Re: [PATCH net] nsh: set mac len based on inner packet
From: Jiri Benc @ 2018-07-12 7:28 UTC (permalink / raw)
To: Willem de Bruijn; +Cc: netdev, davem, Willem de Bruijn
In-Reply-To: <20180711160046.198091-1-willemdebruijn.kernel@gmail.com>
On Wed, 11 Jul 2018 12:00:44 -0400, Willem de Bruijn wrote:
> From: Willem de Bruijn <willemb@google.com>
>
> When pulling the NSH header in nsh_gso_segment, set the mac length
> based on the encapsulated packet type.
>
> skb_reset_mac_len computes an offset to the network header, which
> here still points to the outer packet:
>
> > skb_reset_network_header(skb);
> > [...]
> > __skb_pull(skb, nsh_len);
> > skb_reset_mac_header(skb); // now mac hdr starts nsh_len == 8B after net hdr
> > skb_reset_mac_len(skb); // mac len = net hdr - mac hdr == (u16) -8 == 65528
> > [..]
> > skb_mac_gso_segment(skb, ..)
>
> Link: http://lkml.kernel.org/r/CAF=yD-KeAcTSOn4AxirAxL8m7QAS8GBBe1w09eziYwvPbbUeYA@mail.gmail.com
> Reported-by: syzbot+7b9ed9872dab8c32305d@syzkaller.appspotmail.com
> Fixes: c411ed854584 ("nsh: add GSO support")
> Signed-off-by: Willem de Bruijn <willemb@google.com>
Acked-by: Jiri Benc <jbenc@redhat.com>
^ permalink raw reply
* Re: [BUG net-next] BUG triggered with GRO SKB list_head changes
From: Prashant Bhole @ 2018-07-12 7:29 UTC (permalink / raw)
To: Tyler Hicks, David Miller; +Cc: netdev
In-Reply-To: <20180711223907.GA24943@sec>
On 7/12/2018 7:39 AM, Tyler Hicks wrote:
> Starting with the following net-next commit, I see a BUG when starting a
> LXD container inside of a KVM guest using virtio-net:
>
> d4546c2509b1 net: Convert GRO SKB handling to list_head.
Recently I encountered KASAN:use-after-free BUG and git bisect pointed
to above commit. Looks like this is the same issue without KASAN
enabled. I have submitted a bugfix for this BUG with Tyler Hicks in
Reported-by tag.
-Prashant
>
> Here's what the kernel spits out:
>
> kernel BUG at /var/scm/kernel/linux/include/linux/skbuff.h:2080!
> invalid opcode: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC PTI
> CPU: 0 PID: 1362 Comm: libvirtd Not tainted 4.18.0-rc2+ #69
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Ubuntu-1.8.2-1ubuntu1 04/01/2014
> RIP: 0010:skb_pull+0x36/0x40
> Code: c6 77 24 29 f0 3b 87 84 00 00 00 89 87 80 00 00 00 72 17 89 f6 48 89 f0 48 03 87 d8 00 00 00 48 89 87 d8 00 00 00 c3 31 c0 c3 <0f> 0b 0f 1f 84 00 00 00
> 00 00 0f 1f 44 00 00 39 b7 80 00 00 00 76
> RSP: 0000:ffff96737f6039f0 EFLAGS: 00010297
> RAX: 000000009c66e2f2 RBX: 0000000000000000 RCX: 0000000000000501
> RDX: 0000000000000001 RSI: 000000000000000e RDI: ffff96737f7e3938
> RBP: ffff967379f40020 R08: 0000000000000000 R09: 0000000000000000
> R10: ffff96737f603988 R11: ffffffffc0461335 R12: ffff967379f409e0
> R13: ffff96737f7e3938 R14: 0000000000000000 R15: ffff967379e96ac0
> FS: 00007fc96087e640(0000) GS:ffff96737f600000(0000) knlGS:0000000000000000
> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 00007fc913608aa0 CR3: 000000005dacc001 CR4: 00000000001606f0
> Call Trace:
> <IRQ>
> br_dev_xmit+0xe1/0x3d0 [bridge]
> dev_hard_start_xmit+0xbc/0x3b0
> __dev_queue_xmit+0xb98/0xc30
> ip_finish_output2+0x3e5/0x670
> ? ip_output+0x7f/0x250
> ip_output+0x7f/0x250
> ? ip_fragment.constprop.5+0x80/0x80
> ip_forward+0x3e2/0x650
> ? ipv4_frags_init_net+0x130/0x130
> ip_rcv+0x2be/0x500
> ? ip_local_deliver_finish+0x3b0/0x3b0
> __netif_receive_skb_core+0x6a8/0xb30
> ? lock_acquire+0xab/0x200
> ? netif_receive_skb_internal+0x2a/0x380
> netif_receive_skb_internal+0x73/0x380
> ? napi_gro_complete+0xcf/0x1b0
> dev_gro_receive+0x374/0x730
> napi_gro_receive+0x4f/0x1d0
> receive_buf+0x4b6/0x1930 [virtio_net]
> ? detach_buf+0x69/0x120 [virtio_ring]
> virtnet_poll+0x122/0x2e0 [virtio_net]
> net_rx_action+0x207/0x450
> __do_softirq+0x149/0x4ea
> irq_exit+0xbf/0xd0
> do_IRQ+0x6c/0x130
> common_interrupt+0xf/0xf
> </IRQ>
> RIP: 0010:__radix_tree_lookup+0x28/0xe0
> Code: 00 00 53 49 89 ca 41 bb 40 00 00 00 4c 8b 47 50 4c 89 c0 83 e0 03 48 83 f8 01 0f 85 a8 00 00 00 4c 89 c0 48 83 e0 fe 0f b6 08 <4c> 89 d8 48 d3 e0 48 83
> e8 01 48 39 c6 76 11 e9 9f 00 00 00 4c 89
> RSP: 0000:ffffae150048fcc0 EFLAGS: 00000282 ORIG_RAX: ffffffffffffffd9
> RAX: ffff96735d2ef908 RBX: 000000000000001f RCX: 0000000000000006
> RDX: 0000000000000000 RSI: 00000000000002e2 RDI: ffff96735d10b788
> RBP: 00000000000002e2 R08: ffff96735d2ef909 R09: 0000000000000000
> R10: 0000000000000000 R11: 0000000000000040 R12: 000000000000001f
> R13: ffffec01c15f3a80 R14: 000000000000001f R15: ffffae150048fd18
> __do_page_cache_readahead+0x11f/0x2e0
> filemap_fault+0x408/0x660
> ext4_filemap_fault+0x2f/0x40
> __do_fault+0x1f/0xd0
> __handle_mm_fault+0x915/0xfa0
> handle_mm_fault+0x1c2/0x390
> __do_page_fault+0x2f6/0x580
> ? async_page_fault+0x5/0x20
> async_page_fault+0x1b/0x20
> RIP: 0033:0x7fc913608aa0
> Code: Bad RIP value.
> RSP: 002b:00007ffcfa9c7f08 EFLAGS: 00010206
> RAX: 0000000000000000 RBX: 0000000000000003 RCX: 0000000000000080
> RDX: 0000000000000006 RSI: 00007fc913a74bf8 RDI: 00007fc913df9720
> RBP: 0000000000000001 R08: 000055df45795700 R09: 0000000000000000
> R10: 000055df4574c010 R11: 0000000000000001 R12: 00007ffcfa9c8c38
> R13: 00007ffcfa9c8c48 R14: 00007fc913dc3d70 R15: 000055df4578ab30
> Modules linked in: veth ebtable_filter ebtables ipt_MASQUERADE xt_CHECKSUM xt_comment xt_tcpudp iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack libcrc32c iptable_mangle iptable_filter bpfilter bridge stp llc fuse kvm_intel kvm irqbypass 9pnet_virtio 9pnet virtio_balloon ib_iser rdma_cm configfs iw_cm ib_cm ib_core iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi ip_tables x_tables virtio_net net_failover virtio_blk failover crc32_pclmul crc32c_intel pcbc aesni_intel aes_x86_64 crypto_simd cryptd glue_helper virtio_pci psmouse virtio_ring virtio
>
> I'm not very familiar with the GRO or IP fragmentation code but I was
> able to identify that this change "fixes" the issue:
>
> diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
> index 7ccc601b55d9..a5cea572a7f1 100644
> --- a/include/linux/skbuff.h
> +++ b/include/linux/skbuff.h
> @@ -666,6 +666,7 @@ struct sk_buff {
> /* These two members must be first. */
> struct sk_buff *next;
> struct sk_buff *prev;
> + struct list_head list;
>
> union {
> struct net_device *dev;
> @@ -678,7 +679,6 @@ struct sk_buff {
> };
> };
> struct rb_node rbnode; /* used in netem & tcp stack */
> - struct list_head list;
> };
> struct sock *sk;
>
>
> That's not the correct fix, as we wouldn't want to waste space with two
> list implementations always being around, but I think it shows that
> perhaps there is something in the call stack attempting to use both the
> list_head list and the ip_defrag_offset at the same time and
> unintentionally trouncing over the other member in the union.
>
> I wish I had a proper fix but I suspect that someone more familiar with
> this code will spot the issue quickly. I didn't see anything incorrect
> in the list manipulations in the offending commit so some deeper
> knowledge of the network stack is needed.
>
> Tyler
>
^ permalink raw reply
* WARNING in bpf_check
From: syzbot @ 2018-07-12 7:41 UTC (permalink / raw)
To: ast, daniel, linux-kernel, netdev, syzkaller-bugs
Hello,
syzbot found the following crash on:
HEAD commit: 671dffa7de7b Merge branch 'bpf-bpftool-improved-prog-load'
git tree: bpf-next
console output: https://syzkaller.appspot.com/x/log.txt?x=1550b562400000
kernel config: https://syzkaller.appspot.com/x/.config?x=a501a01deaf0fe9
dashboard link: https://syzkaller.appspot.com/bug?extid=7d427828b2ea6e592804
compiler: gcc (GCC) 8.0.1 20180413 (experimental)
Unfortunately, I don't have any reproducer for this crash yet.
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+7d427828b2ea6e592804@syzkaller.appspotmail.com
RBP: 000000000072bea0 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000013
R13: 00000000004bbbc2 R14: 00000000004c8e28 R15: 0000000000000037
------------[ cut here ]------------
verifier bug. No program starts at insn 3
WARNING: CPU: 0 PID: 12586 at kernel/bpf/verifier.c:1613
get_callee_stack_depth kernel/bpf/verifier.c:1612 [inline]
WARNING: CPU: 0 PID: 12586 at kernel/bpf/verifier.c:1613 fixup_call_args
kernel/bpf/verifier.c:5587 [inline]
WARNING: CPU: 0 PID: 12586 at kernel/bpf/verifier.c:1613
bpf_check+0x5239/0x5e60 kernel/bpf/verifier.c:5952
Kernel panic - not syncing: panic_on_warn set ...
CPU: 0 PID: 12586 Comm: syz-executor0 Not tainted 4.18.0-rc3+ #49
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+0x1c9/0x2b4 lib/dump_stack.c:113
panic+0x238/0x4e7 kernel/panic.c:184
__warn.cold.8+0x163/0x1ba kernel/panic.c:536
report_bug+0x252/0x2d0 lib/bug.c:186
fixup_bug arch/x86/kernel/traps.c:178 [inline]
do_error_trap+0x1fc/0x4d0 arch/x86/kernel/traps.c:296
do_invalid_op+0x1b/0x20 arch/x86/kernel/traps.c:316
invalid_op+0x14/0x20 arch/x86/entry/entry_64.S:992
RIP: 0010:get_callee_stack_depth kernel/bpf/verifier.c:1612 [inline]
RIP: 0010:fixup_call_args kernel/bpf/verifier.c:5587 [inline]
RIP: 0010:bpf_check+0x5239/0x5e60 kernel/bpf/verifier.c:5952
Code: ff 48 89 df e8 28 08 2e 00 e9 d8 d7 ff ff e8 6e 2f f0 ff 8b 74 24 58
48 c7 c7 20 8d ef 87 c6 05 d5 f1 0d 08 01 e8 37 52 bb ff <0f> 0b 48 8b 54
24 08 b8 ff ff 37 00 48 c1 e0 2a 48 c1 ea 03 0f b6
RSP: 0018:ffff88019745f980 EFLAGS: 00010286
RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffc90003eec000
RDX: 0000000000040000 RSI: ffffffff81631851 RDI: ffff88019745f658
RBP: ffff88019745fb30 R08: ffff880197666100 R09: fffffbfff11f1220
R10: fffffbfff11f1220 R11: ffffffff88f89103 R12: dffffc0000000000
R13: ffffc90001ace040 R14: 00000000fffffffe R15: ffff8801b0b7e800
bpf_prog_load+0x1141/0x1c90 kernel/bpf/syscall.c:1352
__do_sys_bpf kernel/bpf/syscall.c:2305 [inline]
__se_sys_bpf kernel/bpf/syscall.c:2267 [inline]
__x64_sys_bpf+0x36c/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:0x455e29
Code: 1d ba fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 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 eb b9 fb ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:00007f28af3e8c68 EFLAGS: 00000246 ORIG_RAX: 0000000000000141
RAX: ffffffffffffffda RBX: 00007f28af3e96d4 RCX: 0000000000455e29
RDX: 0000000000000048 RSI: 0000000020000000 RDI: 0000000000000005
RBP: 000000000072bea0 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000013
R13: 00000000004bbbc2 R14: 00000000004c8e28 R15: 0000000000000037
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.
^ permalink raw reply
* Re: WARNING in bpf_check
From: Daniel Borkmann @ 2018-07-12 7:54 UTC (permalink / raw)
To: Dmitry Vyukov, syzbot; +Cc: Alexei Starovoitov, LKML, netdev, syzkaller-bugs
In-Reply-To: <CACT4Y+aDK2yFb=8GGMEL8+Tfq6VVJhU-jrhMrQj9KywmMBNHNg@mail.gmail.com>
On 07/12/2018 09:51 AM, Dmitry Vyukov wrote:
> On Thu, Jul 12, 2018 at 9:41 AM, syzbot
[...]
> Reproducer is below. It seems to be related to the kmalloc failure in
> jit_subprogs():
Thanks a lot Dmitry! Already looking into it.
^ permalink raw reply
* Re: WARNING in bpf_check
From: Dmitry Vyukov @ 2018-07-12 7:51 UTC (permalink / raw)
To: syzbot; +Cc: Alexei Starovoitov, Daniel Borkmann, LKML, netdev, syzkaller-bugs
In-Reply-To: <00000000000025f8880570c87c51@google.com>
On Thu, Jul 12, 2018 at 9:41 AM, syzbot
<syzbot+7d427828b2ea6e592804@syzkaller.appspotmail.com> wrote:
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit: 671dffa7de7b Merge branch 'bpf-bpftool-improved-prog-load'
> git tree: bpf-next
> console output: https://syzkaller.appspot.com/x/log.txt?x=1550b562400000
> kernel config: https://syzkaller.appspot.com/x/.config?x=a501a01deaf0fe9
> dashboard link: https://syzkaller.appspot.com/bug?extid=7d427828b2ea6e592804
> compiler: gcc (GCC) 8.0.1 20180413 (experimental)
>
> Unfortunately, I don't have any reproducer for this crash yet.
>
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+7d427828b2ea6e592804@syzkaller.appspotmail.com
>
> RBP: 000000000072bea0 R08: 0000000000000000 R09: 0000000000000000
> R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000013
> R13: 00000000004bbbc2 R14: 00000000004c8e28 R15: 0000000000000037
> ------------[ cut here ]------------
> verifier bug. No program starts at insn 3
> WARNING: CPU: 0 PID: 12586 at kernel/bpf/verifier.c:1613
> get_callee_stack_depth kernel/bpf/verifier.c:1612 [inline]
> WARNING: CPU: 0 PID: 12586 at kernel/bpf/verifier.c:1613 fixup_call_args
> kernel/bpf/verifier.c:5587 [inline]
> WARNING: CPU: 0 PID: 12586 at kernel/bpf/verifier.c:1613
> bpf_check+0x5239/0x5e60 kernel/bpf/verifier.c:5952
> Kernel panic - not syncing: panic_on_warn set ...
>
> CPU: 0 PID: 12586 Comm: syz-executor0 Not tainted 4.18.0-rc3+ #49
> 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+0x1c9/0x2b4 lib/dump_stack.c:113
> panic+0x238/0x4e7 kernel/panic.c:184
> __warn.cold.8+0x163/0x1ba kernel/panic.c:536
> report_bug+0x252/0x2d0 lib/bug.c:186
> fixup_bug arch/x86/kernel/traps.c:178 [inline]
> do_error_trap+0x1fc/0x4d0 arch/x86/kernel/traps.c:296
> do_invalid_op+0x1b/0x20 arch/x86/kernel/traps.c:316
> invalid_op+0x14/0x20 arch/x86/entry/entry_64.S:992
> RIP: 0010:get_callee_stack_depth kernel/bpf/verifier.c:1612 [inline]
> RIP: 0010:fixup_call_args kernel/bpf/verifier.c:5587 [inline]
> RIP: 0010:bpf_check+0x5239/0x5e60 kernel/bpf/verifier.c:5952
> Code: ff 48 89 df e8 28 08 2e 00 e9 d8 d7 ff ff e8 6e 2f f0 ff 8b 74 24 58
> 48 c7 c7 20 8d ef 87 c6 05 d5 f1 0d 08 01 e8 37 52 bb ff <0f> 0b 48 8b 54 24
> 08 b8 ff ff 37 00 48 c1 e0 2a 48 c1 ea 03 0f b6
> RSP: 0018:ffff88019745f980 EFLAGS: 00010286
> RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffc90003eec000
> RDX: 0000000000040000 RSI: ffffffff81631851 RDI: ffff88019745f658
> RBP: ffff88019745fb30 R08: ffff880197666100 R09: fffffbfff11f1220
> R10: fffffbfff11f1220 R11: ffffffff88f89103 R12: dffffc0000000000
> R13: ffffc90001ace040 R14: 00000000fffffffe R15: ffff8801b0b7e800
> bpf_prog_load+0x1141/0x1c90 kernel/bpf/syscall.c:1352
> __do_sys_bpf kernel/bpf/syscall.c:2305 [inline]
> __se_sys_bpf kernel/bpf/syscall.c:2267 [inline]
> __x64_sys_bpf+0x36c/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:0x455e29
> Code: 1d ba fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 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 eb b9 fb ff c3 66 2e 0f 1f 84 00 00 00 00
> RSP: 002b:00007f28af3e8c68 EFLAGS: 00000246 ORIG_RAX: 0000000000000141
> RAX: ffffffffffffffda RBX: 00007f28af3e96d4 RCX: 0000000000455e29
> RDX: 0000000000000048 RSI: 0000000020000000 RDI: 0000000000000005
> RBP: 000000000072bea0 R08: 0000000000000000 R09: 0000000000000000
> R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000013
> R13: 00000000004bbbc2 R14: 00000000004c8e28 R15: 0000000000000037
> Dumping ftrace buffer:
> (ftrace buffer empty)
> Kernel Offset: disabled
> Rebooting in 86400 seconds..
Reproducer is below. It seems to be related to the kmalloc failure in
jit_subprogs():
[ 140.990644] FAULT_INJECTION: forcing a failure.
[ 140.990644] name failslab, interval 1, probability 0, space 0, times 0
[ 140.994740] CPU: 3 PID: 4072 Comm: a.out Not tainted 4.18.0-rc4+ #51
[ 140.997070] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),
BIOS 1.10.2-1 04/01/2014
[ 141.000046] Call Trace:
[ 141.001025] __dump_stack lib/dump_stack.c:77 [inline]
[ 141.001025] dump_stack+0x1c9/0x2b4 lib/dump_stack.c:113
[ 141.001714] ? dump_stack_print_info.cold.2+0x52/0x52 lib/dump_stack.c:60
[ 141.002637] ? kernel_text_address+0x79/0xf0 kernel/extable.c:152
[ 141.003423] fail_dump lib/fault-inject.c:51 [inline]
[ 141.003423] should_fail.cold.4+0xa/0x1a lib/fault-inject.c:149
[ 141.004145] ? fault_create_debugfs_attr+0x1f0/0x1f0 lib/fault-inject.c:249
[ 141.005056] ? save_stack+0xa9/0xd0 mm/kasan/kasan.c:454
[ 141.005694] ? save_stack+0x43/0xd0 mm/kasan/kasan.c:448
[ 141.006352] ? graph_lock+0x170/0x170 arch/x86/include/asm/paravirt.h:674
[ 141.007021] ? lock_downgrade+0x8f0/0x8f0 kernel/locking/lockdep.c:3658
[ 141.007736] ? __lock_is_held+0xb5/0x140 kernel/locking/lockdep.c:3744
[ 141.008441] ? trace_hardirqs_off+0xd/0x10 kernel/locking/lockdep.c:2932
[ 141.009190] ? rcu_note_context_switch+0x730/0x730
include/linux/compiler.h:188
[ 141.010052] __should_failslab+0x124/0x180 mm/failslab.c:32
[ 141.010789] should_failslab+0x9/0x14 mm/slab_common.c:1557
[ 141.011450] slab_pre_alloc_hook mm/slab.h:423 [inline]
[ 141.011450] slab_alloc mm/slab.c:3378 [inline]
[ 141.011450] __do_kmalloc mm/slab.c:3716 [inline]
[ 141.011450] __kmalloc+0x2c8/0x760 mm/slab.c:3727
[ 141.012070] ? find_subprog+0xbb/0x100 kernel/bpf/verifier.c:778
[ 141.012773] ? find_good_pkt_pointers+0x630/0x630 kernel/bpf/verifier.c:3422
[ 141.013632] ? kmalloc_array include/linux/slab.h:635 [inline]
[ 141.013632] ? kcalloc include/linux/slab.h:646 [inline]
[ 141.013632] ? jit_subprogs kernel/bpf/verifier.c:5451 [inline]
[ 141.013632] ? fixup_call_args kernel/bpf/verifier.c:5578 [inline]
[ 141.013632] ? bpf_check+0x3947/0x5e60 kernel/bpf/verifier.c:5952
[ 141.014309] ? trace_hardirqs_on+0xd/0x10 kernel/locking/lockdep.c:2894
[ 141.015019] kmalloc_array include/linux/slab.h:635 [inline]
[ 141.015019] kcalloc include/linux/slab.h:646 [inline]
[ 141.015019] jit_subprogs kernel/bpf/verifier.c:5451 [inline]
[ 141.015019] fixup_call_args kernel/bpf/verifier.c:5578 [inline]
[ 141.015019] bpf_check+0x3947/0x5e60 kernel/bpf/verifier.c:5952
[ 141.015668] ? pvclock_read_flags+0x160/0x160
arch/x86/include/asm/pvclock.h:35
[ 141.016453] ? fixup_bpf_calls+0x1fb0/0x1fb0 kernel/bpf/verifier.c:5677
[ 141.017224] ? ktime_get_with_offset+0x32e/0x4b0
kernel/time/timekeeping.c:788
[ 141.018046] ? ktime_get+0x440/0x440 kernel/time/timekeeping.c:751
[ 141.018693] ? memset+0x31/0x40 mm/kasan/kasan.c:287
[ 141.019264] ? __sanitizer_cov_trace_const_cmp1+0x1a/0x20 kernel/kcov.c:174
[ 141.020180] ? bpf_obj_name_cpy+0x17c/0x1c0 kernel/bpf/syscall.c:427
[ 141.020890] bpf_prog_load+0x1141/0x1c90 kernel/bpf/syscall.c:1352
[ 141.021555] ? bpf_prog_new_fd+0x60/0x60 kernel/bpf/syscall.c:1099
[ 141.022220] ? lock_downgrade+0x8f0/0x8f0 kernel/locking/lockdep.c:3658
[ 141.022903] ? __sanitizer_cov_trace_const_cmp8+0x18/0x20 kernel/kcov.c:195
[ 141.023842] __do_sys_bpf kernel/bpf/syscall.c:2305 [inline]
[ 141.023842] __se_sys_bpf kernel/bpf/syscall.c:2267 [inline]
[ 141.023842] __x64_sys_bpf+0x36c/0x510 kernel/bpf/syscall.c:2267
[ 141.024529] ? bpf_prog_get+0x20/0x20 kernel/bpf/syscall.c:1197
[ 141.025214] ? do_syscall_64+0x9a/0x820 arch/x86/entry/common.c:277
[ 141.025905] do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
[ 141.026583] ? syscall_return_slowpath+0x5e0/0x5e0
arch/x86/entry/common.c:255
[ 141.027435] ? prepare_exit_to_usermode arch/x86/entry/common.c:211 [inline]
[ 141.027435] ? syscall_return_slowpath+0x31d/0x5e0
arch/x86/entry/common.c:268
[ 141.028293] ? entry_SYSCALL_64_after_hwframe+0x59/0xbe
[ 141.029237] ? trace_hardirqs_off_thunk+0x1a/0x1c
[ 141.030089] entry_SYSCALL_64_after_hwframe+0x49/0xbe
[ 141.030998] RIP: 0033:0x44a949
[ 141.031559] Code: e8 2c aa 01 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 0b 0c fc ff c3 66 2e 0f 1f 84 00 00
00 00
[ 141.035037] RSP: 002b:00007fe7874b0d88 EFLAGS: 00000206 ORIG_RAX:
0000000000000141
[ 141.036347] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 000000000044a949
[ 141.037590] RDX: 0000000000000048 RSI: 0000000020000000 RDI: 0000000000000005
[ 141.038813] RBP: 00007fe7874b0da0 R08: 0000000000000002 R09: 0000000000000000
[ 141.040069] R10: 0000000000000001 R11: 0000000000000206 R12: 0000000000000000
[ 141.041302] R13: 00007ffe20cc628f R14: 00007fe7874b1700 R15: 0000000000000000
[ 141.042804] ------------[ cut here ]------------
[ 141.043668] verifier bug. No program starts at insn 3
[ 141.044648] ARNING: CPU: 3 PID: 4072 at kernel/bpf/verifier.c:1613
get_callee_stack_depth kernel/bpf/verifier.c:1612 [inline]
[ 141.044648] ARNING: CPU: 3 PID: 4072 at kernel/bpf/verifier.c:1613
fixup_call_args kernel/bpf/verifier.c:5587 [inline]
[ 141.044648] ARNING: CPU: 3 PID: 4072 at kernel/bpf/verifier.c:1613
bpf_check+0x525e/0x5e60 kernel/bpf/verifier.c:5952
[ 141.046103]
[ 141.047355] CPU: 3 PID: 4072 Comm: a.out Not tainted 4.18.0-rc4+ #51
[ 141.048446] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),
BIOS 1.10.2-1 04/01/2014
[ 141.049877] Call Trace:
[ 141.050324] __dump_stack lib/dump_stack.c:77 [inline]
[ 141.050324] dump_stack+0x1c9/0x2b4 lib/dump_stack.c:113
[ 141.050950] ? dump_stack_print_info.cold.2+0x52/0x52 lib/dump_stack.c:60
[ 141.051837] panic+0x238/0x4e7 kernel/panic.c:184
[ 141.052386] ? add_taint.cold.5+0x16/0x16 kernel/panic.c:385
[ 141.053101] ? __warn.cold.8+0x148/0x1ba kernel/panic.c:537
[ 141.053814] ? __warn.cold.8+0x117/0x1ba kernel/panic.c:530
[ 141.054506] ? get_callee_stack_depth kernel/bpf/verifier.c:1612 [inline]
[ 141.054506] ? fixup_call_args kernel/bpf/verifier.c:5587 [inline]
[ 141.054506] ? bpf_check+0x525e/0x5e60 kernel/bpf/verifier.c:5952
[ 141.055163] __warn.cold.8+0x163/0x1ba kernel/panic.c:538
[ 141.055820] ? get_callee_stack_depth kernel/bpf/verifier.c:1612 [inline]
[ 141.055820] ? fixup_call_args kernel/bpf/verifier.c:5587 [inline]
[ 141.055820] ? bpf_check+0x525e/0x5e60 kernel/bpf/verifier.c:5952
[ 141.056478] report_bug+0x252/0x2d0 lib/bug.c:186
[ 141.057106] fixup_bug arch/x86/kernel/traps.c:178 [inline]
[ 141.057106] do_error_trap+0x1fc/0x4d0 arch/x86/kernel/traps.c:296
[ 141.057764] ? graph_lock+0x170/0x170 arch/x86/include/asm/paravirt.h:674
[ 141.058402] ? math_error+0x3e0/0x3e0 arch/x86/kernel/traps.c:844
[ 141.059058] ? vprintk_default+0x28/0x30 kernel/printk/printk.c:1991
[ 141.059748] ? vprintk_func+0x81/0xe7 kernel/printk/printk_safe.c:383
[ 141.060395] ? printk+0xa7/0xcf kernel/printk/printk.c:2024
[ 141.060975] ? trace_hardirqs_off_thunk+0x1a/0x1c
[ 141.061800] do_invalid_op+0x1b/0x20 arch/x86/kernel/traps.c:316
[ 141.062434] invalid_op+0x14/0x20 arch/x86/entry/entry_64.S:992
[ 141.063026] RIP: 0010:get_callee_stack_depth
kernel/bpf/verifier.c:1612 [inline]
[ 141.063026] RIP: 0010:fixup_call_args kernel/bpf/verifier.c:5587 [inline]
[ 141.063026] RIP: 0010:bpf_check+0x525e/0x5e60 kernel/bpf/verifier.c:5952
[ 141.063795] Code: ff 48 89 df e8 a3 0e 2e 00 e9 7a f2 ff ff e8 b9
30 f0 ff 8b 74 24 58 48 c7 c7 a0 6b b0 87 c6 05 db c9 f3 07 01 e8 a2
41 bb ff <0f> 0b 48 8b 54 24 08 b8 ff ff 37 00 48 c1 e0 2a 48 c1 ea 03
0f b6
[ 141.067166] RSP: 0018:ffff880067b5f980 EFLAGS: 00010286
[ 141.068060] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000
[ 141.069281] RDX: 0000000000000000 RSI: ffffffff81633d81 RDI: 0000000000000001
[ 141.070478] RBP: ffff880067b5fb30 R08: ffff880062faa340 R09: ffffed000d8f4fc0
[ 141.071687] R10: ffffed000d8f4fc0 R11: ffff88006c7a7e07 R12: dffffc0000000000
[ 141.072912] R13: ffffc90000b68040 R14: 00000000fffffffe R15: ffff8800602e2280
[ 141.074135] ? vprintk_func+0x81/0xe7 kernel/printk/printk_safe.c:383
[ 141.074745] ? pvclock_read_flags+0x160/0x160
arch/x86/include/asm/pvclock.h:35
[ 141.075466] ? fixup_bpf_calls+0x1fb0/0x1fb0 kernel/bpf/verifier.c:5677
[ 141.076167] ? ktime_get_with_offset+0x32e/0x4b0
kernel/time/timekeeping.c:788
[ 141.076928] ? ktime_get+0x440/0x440 kernel/time/timekeeping.c:751
[ 141.077531] ? memset+0x31/0x40 mm/kasan/kasan.c:287
[ 141.078063] ? __sanitizer_cov_trace_const_cmp1+0x1a/0x20 kernel/kcov.c:174
[ 141.078945] ? bpf_obj_name_cpy+0x17c/0x1c0 kernel/bpf/syscall.c:427
[ 141.079695] bpf_prog_load+0x1141/0x1c90 kernel/bpf/syscall.c:1352
[ 141.080358] ? bpf_prog_new_fd+0x60/0x60 kernel/bpf/syscall.c:1099
[ 141.081018] ? lock_downgrade+0x8f0/0x8f0 kernel/locking/lockdep.c:3658
[ 141.081688] ? __sanitizer_cov_trace_const_cmp8+0x18/0x20 kernel/kcov.c:195
[ 141.082576] __do_sys_bpf kernel/bpf/syscall.c:2305 [inline]
[ 141.082576] __se_sys_bpf kernel/bpf/syscall.c:2267 [inline]
[ 141.082576] __x64_sys_bpf+0x36c/0x510 kernel/bpf/syscall.c:2267
[ 141.083217] ? bpf_prog_get+0x20/0x20 kernel/bpf/syscall.c:1197
[ 141.083829] ? do_syscall_64+0x9a/0x820 arch/x86/entry/common.c:277
[ 141.084466] do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
[ 141.085125] ? syscall_return_slowpath+0x5e0/0x5e0
arch/x86/entry/common.c:255
[ 141.085945] ? prepare_exit_to_usermode arch/x86/entry/common.c:211 [inline]
[ 141.085945] ? syscall_return_slowpath+0x31d/0x5e0
arch/x86/entry/common.c:268
[ 141.086764] ? entry_SYSCALL_64_after_hwframe+0x59/0xbe
[ 141.087653] ? trace_hardirqs_off_thunk+0x1a/0x1c
[ 141.088462] entry_SYSCALL_64_after_hwframe+0x49/0xbe
[ 141.089331] RIP: 0033:0x44a949
[ 141.089858] Code: e8 2c aa 01 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 0b 0c fc ff c3 66 2e 0f 1f 84 00 00
00 00
[ 141.093216] RSP: 002b:00007fe7874b0d88 EFLAGS: 00000206 ORIG_RAX:
0000000000000141
[ 141.094510] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 000000000044a949
[ 141.095712] RDX: 0000000000000048 RSI: 0000000020000000 RDI: 0000000000000005
[ 141.096924] RBP: 00007fe7874b0da0 R08: 0000000000000002 R09: 0000000000000000
[ 141.098124] R10: 0000000000000001 R11: 0000000000000206 R12: 0000000000000000
[ 141.099314] R13: 00007ffe20cc628f R14: 00007fe7874b1700 R15: 0000000000000000
[ 141.100989] Kernel Offset: disabled
[ 141.101637] Rebooting in 86400 seconds..
// autogenerated by syzkaller (http://github.com/google/syzkaller)
#define _GNU_SOURCE
#include <endian.h>
#include <errno.h>
#include <fcntl.h>
#include <linux/futex.h>
#include <pthread.h>
#include <stdarg.h>
#include <stdbool.h>
#include <stdio.h>
#include <stdlib.h>
#include <sys/stat.h>
#include <sys/syscall.h>
#include <sys/types.h>
#include <unistd.h>
__attribute__((noreturn)) static void doexit(int status)
{
volatile unsigned i;
syscall(__NR_exit_group, status);
for (i = 0;; i++) {
}
}
#include <errno.h>
#include <stdarg.h>
#include <stdint.h>
#include <stdio.h>
#include <string.h>
const int kFailStatus = 67;
const int kRetryStatus = 69;
static void exitf(const char* msg, ...)
{
int e = errno;
va_list args;
va_start(args, msg);
vfprintf(stderr, msg, args);
va_end(args);
fprintf(stderr, " (errno %d)\n", e);
doexit(kRetryStatus);
}
static bool write_file(const char* file, const char* what, ...)
{
char buf[1024];
va_list args;
va_start(args, what);
vsnprintf(buf, sizeof(buf), what, args);
va_end(args);
buf[sizeof(buf) - 1] = 0;
int len = strlen(buf);
int fd = open(file, O_WRONLY | O_CLOEXEC);
if (fd == -1)
return false;
if (write(fd, buf, len) != len) {
int err = errno;
close(fd);
errno = err;
return false;
}
close(fd);
return true;
}
static int inject_fault(int nth)
{
int fd;
char buf[16];
fd = open("/proc/thread-self/fail-nth", O_RDWR);
if (fd == -1)
exitf("failed to open /proc/thread-self/fail-nth");
sprintf(buf, "%d", nth + 1);
if (write(fd, buf, strlen(buf)) != (ssize_t)strlen(buf))
exitf("failed to write /proc/thread-self/fail-nth");
return fd;
}
struct thread_t {
int created, running, call;
pthread_t th;
};
static struct thread_t threads[16];
static void execute_call(int call);
static int running;
static void* thr(void* arg)
{
struct thread_t* th = (struct thread_t*)arg;
for (;;) {
while (!__atomic_load_n(&th->running, __ATOMIC_ACQUIRE))
syscall(SYS_futex, &th->running, FUTEX_WAIT, 0, 0);
execute_call(th->call);
__atomic_fetch_sub(&running, 1, __ATOMIC_RELAXED);
__atomic_store_n(&th->running, 0, __ATOMIC_RELEASE);
syscall(SYS_futex, &th->running, FUTEX_WAKE);
}
return 0;
}
static void execute(int num_calls)
{
int call, thread;
running = 0;
for (call = 0; call < num_calls; call++) {
for (thread = 0; thread < sizeof(threads) / sizeof(threads[0]); thread++) {
struct thread_t* th = &threads[thread];
if (!th->created) {
th->created = 1;
pthread_attr_t attr;
pthread_attr_init(&attr);
pthread_attr_setstacksize(&attr, 128 << 10);
pthread_create(&th->th, &attr, thr, th);
}
if (!__atomic_load_n(&th->running, __ATOMIC_ACQUIRE)) {
th->call = call;
__atomic_fetch_add(&running, 1, __ATOMIC_RELAXED);
__atomic_store_n(&th->running, 1, __ATOMIC_RELEASE);
syscall(SYS_futex, &th->running, FUTEX_WAKE);
struct timespec ts;
ts.tv_sec = 0;
ts.tv_nsec = 20 * 1000 * 1000;
syscall(SYS_futex, &th->running, FUTEX_WAIT, 1, &ts);
if (__atomic_load_n(&running, __ATOMIC_RELAXED))
usleep((call == num_calls - 1) ? 10000 : 1000);
break;
}
}
}
}
#ifndef __NR_bpf
#define __NR_bpf 321
#endif
void execute_call(int call)
{
switch (call) {
case 0:
*(uint32_t*)0x20000000 = 1;
*(uint32_t*)0x20000004 = 0xa;
*(uint64_t*)0x20000008 = 0x20001000;
memcpy((void*)0x20001000,
"\xbf\x16\x00\x00\x00\x00\x00\x00\x85\x10\x00\x00\x05\x00\x00\x00"
"\x54\x00\x00\x00\x00\x00\x00\x00\xbf\x61\x00\x00\x00\x00\x00\x00"
"\x85\x10\x00\x00\x02\x00\x00\x00\xbf\x01\x00\x00\x00\x00\x00\x00"
"\x95\x00\x00\x00\x00\x00\x00\x00\x15\x01\x00\x00\x00\x00\x00\x00"
"\xb7\x00\x00\x00\x00\x00\x00\x00\x95\x00\x00\x00\x00\x00\x00\x00",
80);
*(uint64_t*)0x20000010 = 0x20000100;
memcpy((void*)0x20000100, "GPL", 4);
*(uint32_t*)0x20000018 = 0;
*(uint32_t*)0x2000001c = 0;
*(uint64_t*)0x20000020 = 0;
*(uint32_t*)0x20000028 = 0;
*(uint32_t*)0x2000002c = 0;
*(uint8_t*)0x20000030 = 0;
*(uint8_t*)0x20000031 = 0;
*(uint8_t*)0x20000032 = 0;
*(uint8_t*)0x20000033 = 0;
*(uint8_t*)0x20000034 = 0;
*(uint8_t*)0x20000035 = 0;
*(uint8_t*)0x20000036 = 0;
*(uint8_t*)0x20000037 = 0;
*(uint8_t*)0x20000038 = 0;
*(uint8_t*)0x20000039 = 0;
*(uint8_t*)0x2000003a = 0;
*(uint8_t*)0x2000003b = 0;
*(uint8_t*)0x2000003c = 0;
*(uint8_t*)0x2000003d = 0;
*(uint8_t*)0x2000003e = 0;
*(uint8_t*)0x2000003f = 0;
*(uint32_t*)0x20000040 = 0;
*(uint32_t*)0x20000044 = 0;
write_file("/sys/kernel/debug/failslab/ignore-gfp-wait", "N");
write_file("/sys/kernel/debug/fail_futex/ignore-private", "N");
inject_fault(55);
syscall(__NR_bpf, 5, 0x20000000, 0x48);
break;
}
}
void loop()
{
execute(1);
}
int main()
{
write_file("/sys/kernel/debug/failslab/ignore-gfp-wait", "N");
write_file("/sys/kernel/debug/fail_futex/ignore-private", "N");
inject_fault(55);
syscall(__NR_mmap, 0x20000000, 0x1000000, 3, 0x32, -1, 0);
loop();
return 0;
}
^ permalink raw reply
* Re: [PATCH v3 6/7] timex: use __kernel_timex internally
From: Christoph Hellwig @ 2018-07-12 8:27 UTC (permalink / raw)
To: Deepa Dinamani; +Cc: tglx, linux-kernel, arnd, y2038, linux-alpha, netdev
In-Reply-To: <20180707054247.19802-7-deepa.kernel@gmail.com>
On Fri, Jul 06, 2018 at 10:42:46PM -0700, Deepa Dinamani wrote:
> struct timex is not y2038 safe.
> Replace all uses of timex with y2038 safe __kernel_timex.
>
> Note that struct __kernel_timex is an ABI interface definition.
If it actually is an ABI interface it should probably have a different
name.
^ permalink raw reply
* Re: [PATCH net] netfilter: nf_conntrack: prevent uninit-value in gc_worker
From: Florian Westphal @ 2018-07-12 9:00 UTC (permalink / raw)
To: Eric Dumazet
Cc: Pablo Neira Ayuso, Jozsef Kadlecsik, Florian Westphal,
netfilter-devel, netdev, Eric Dumazet
In-Reply-To: <20180712004037.197064-1-edumazet@google.com>
Eric Dumazet <edumazet@google.com> wrote:
> KMSAN reported use of uninit-value in gc_worker [1]
>
> We need to clear ct->timeout in __nf_conntrack_alloc()
> otherwise __nf_conntrack_confirm() might propagate garbage when
> adding nfct_time_stamp to ct->timeout :
>
> ct->timeout += nfct_time_stamp;
>
> [1]
> BUG: KMSAN: uninit-value in gc_worker+0x89e/0x1530 net/netfilter/nf_conntrack_core.c:1028
> CPU: 1 PID: 19 Comm: kworker/1:0 Not tainted 4.18.0-rc4+ #24
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
> Workqueue: events_power_efficient gc_worker
> Call Trace:
> __dump_stack lib/dump_stack.c:77 [inline]
> dump_stack+0x185/0x1e0 lib/dump_stack.c:113
> kmsan_report+0x195/0x2c0 mm/kmsan/kmsan.c:1092
> __msan_warning_32+0x7d/0xe0 mm/kmsan/kmsan_instr.c:640
> gc_worker+0x89e/0x1530 net/netfilter/nf_conntrack_core.c:1028
I wonder how this can happen.
All trackers are supposed to set ->timeout to the correct value,
otherwise (assuming init-to-0), we add a ct entry to global hash that
is expired.
For instance, tcp calls
nf_ct_refresh_acct() at end of its ->packet() callback to set
a timeout based on the connection state.
That being said, I don't see any harm in initing to 0 of course.
^ permalink raw reply
* Re: KMSAN: uninit-value in p9_client_rpc
From: syzbot @ 2018-07-12 9:24 UTC (permalink / raw)
To: davem, ericvh, linux-kernel, lucho, netdev, rminnich,
syzkaller-bugs, v9fs-developer
In-Reply-To: <000000000000c541110570a978a4@google.com>
syzbot has found a reproducer for the following crash on:
HEAD commit: b64f7ec04e12 kmsan: implement kmsan_memmove_shadow() and k..
git tree: https://github.com/google/kmsan.git/master
console output: https://syzkaller.appspot.com/x/log.txt?x=12f6791c400000
kernel config: https://syzkaller.appspot.com/x/.config?x=93d57043084eee38
dashboard link: https://syzkaller.appspot.com/bug?extid=4de40388f584432bf004
compiler: clang version 7.0.0 (trunk 334104)
syzkaller repro:https://syzkaller.appspot.com/x/repro.syz?x=147c36dc400000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=14e87044400000
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+4de40388f584432bf004@syzkaller.appspotmail.com
FS-Cache: O-key=[10] '34323934373135343132'
FS-Cache: N-cookie c=(____ptrval____) [p=(____ptrval____) fl=2 nc=0 na=1]
FS-Cache: N-cookie d=(____ptrval____) n=(____ptrval____)
FS-Cache: N-key=[10] '34323934373135343132'
==================================================================
BUG: KMSAN: uninit-value in p9_client_rpc+0x194c/0x1dc0 net/9p/client.c:818
CPU: 1 PID: 4620 Comm: syz-executor262 Not tainted 4.18.0-rc4+ #24
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+0x185/0x1e0 lib/dump_stack.c:113
kmsan_report+0x195/0x2c0 mm/kmsan/kmsan.c:1092
__msan_warning_32+0x7d/0xe0 mm/kmsan/kmsan_instr.c:640
p9_client_rpc+0x194c/0x1dc0 net/9p/client.c:818
p9_client_attach+0x35b/0xc30 net/9p/client.c:1147
v9fs_session_init+0x24b9/0x2970 fs/9p/v9fs.c:449
v9fs_mount+0x107/0x11b0 fs/9p/vfs_super.c:135
mount_fs+0x29b/0x780 fs/super.c:1277
vfs_kern_mount+0x222/0x990 fs/namespace.c:1037
do_new_mount fs/namespace.c:2518 [inline]
do_mount+0xd30/0x5310 fs/namespace.c:2848
ksys_mount+0x32e/0x3d0 fs/namespace.c:3064
__do_sys_mount fs/namespace.c:3078 [inline]
__se_sys_mount fs/namespace.c:3075 [inline]
__x64_sys_mount+0x157/0x1c0 fs/namespace.c:3075
do_syscall_64+0x15b/0x230 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x63/0xe7
RIP: 0033:0x445f79
Code: e8 cc e6 ff ff 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 3b 0d fc ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:00007ffb83104da8 EFLAGS: 00000202 ORIG_RAX: 00000000000000a5
RAX: ffffffffffffffda RBX: 00000000006dbc3c RCX: 0000000000445f79
RDX: 0000000020000180 RSI: 00000000200000c0 RDI: 0000000000000000
RBP: 00000000006dbc38 R08: 00000000200001c0 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000202 R12: 0030656c69662f2e
R13: 64663d736e617274 R14: 7974697275636573 R15: 0000000000000001
Local variable description: ----ecode.i@p9_client_rpc
Variable was created at:
p9_client_rpc+0x183/0x1dc0 net/9p/client.c:750
p9_client_attach+0x35b/0xc30 net/9p/client.c:1147
==================================================================
^ permalink raw reply
* Re: Re: [Qemu-devel] [PATCH v3 0/3] Use of unique identifier for pairing virtio and passthrough devices...
From: Siwei Liu @ 2018-07-12 9:37 UTC (permalink / raw)
To: Cornelia Huck
Cc: Michael S. Tsirkin, si-wei liu, Roman Kagan, Venu Busireddy,
Marcel Apfelbaum, virtio-dev, qemu-devel, Samudrala, Sridhar,
Alexander Duyck, Netdev
In-Reply-To: <20180711115344.633eba9e.cohuck@redhat.com>
On Wed, Jul 11, 2018 at 2:53 AM, Cornelia Huck <cohuck@redhat.com> wrote:
> On Tue, 10 Jul 2018 17:07:37 -0700
> Siwei Liu <loseweigh@gmail.com> wrote:
>
>> On Mon, Jul 9, 2018 at 6:54 PM, Michael S. Tsirkin <mst@redhat.com> wrote:
>> > On Mon, Jul 09, 2018 at 06:11:53PM -0700, si-wei liu wrote:
>> >> The plan is to enable group ID based matching in the first place rather than
>> >> match by MAC, the latter of which is fragile and problematic.
>> >
>> > It isn't all that fragile - hyperv used same for a while, so if someone
>> > posts working patches with QEMU support but before this grouping stuff,
>> > I'll happily apply them.
>>
>> I wouldn't box the solution to very limited scenario just because of
>> matching by MAC, the benefit of having generic group ID in the first
>> place is that we save the effort of maintaining legacy MAC based
>> pairing that just adds complexity anyway. Currently the VF's MAC
>> address cannot be changed by either PF or by the guest user is a
>> severe limitation due to this. The other use case is that PT device
>> than VF would generally have different MAC than the standby virtio. We
>> shouldn't limit itself to VF specific scenario from the very
>> beginning.
>
> So, this brings me to a different concern: the semantics of
> VIRTIO_NET_F_STANDBY.
>
> * The currently sole user seems to be the virtio-net Linux driver.
> * The commit messages, code comments and Documentation/ all talk about
> matching by MAC.
> * I could not find any proposed update to the virtio spec. (If there
> had been an older proposal with a different feature name, it is not
> discoverable.)
No, there was no such spec patch at all when the Linux patch was
submitted, hence match by MAC is the only means to pair device due to
lack of QEMU support.
Q: Does it work?
A: Well, it works for some.
Q: Does it work well to support all scenarios?
A: No, not as it claims to.
Q: Can it do better job to support all scenarios?
A: Yes, do pairing with the failover group ID instead.
Q: Does pairing still need to be MAC based if using failover group ID?
A: It depends, it's up to the implementation to verify MAC address
depending on the need (e.g. VF failover versus PT device replacement),
though MAC matching is no longer positioned as a requirement for
pairing or grouping.
There's no such stickiness for matching by MAC defined anywhere. The
semantics of VIRTIO_NET_F_STANDBY feature are mostly a failover
concept that the standby device should be used when the primary is not
present. We now have added the group ID on QEMU. I don't see why
bothering to get rid of the limitation: it's never been exposed. No
existing users. No API/ABI defined at all.
>
> VIRTIO_NET_F_STANDBY is a host <-> guest interface. As there's no
> official spec, you can only go by the Linux implementation, and by that
> its semantics seem to be 'match by MAC', not 'match by other criteria'.
>
> How is this supposed to work in the long run?
That group ID thing should work for all OS. Not just Linux.
I will change all the references to MAC matching in my upcoming patch.
Thank you for the note.
-Siwei
^ permalink raw reply
* Re: [PATCH] net: convert gro_count to bitmask
From: Stefano Brivio @ 2018-07-12 9:48 UTC (permalink / raw)
To: Li,Rongqing; +Cc: netdev@vger.kernel.org, Eric Dumazet
In-Reply-To: <2AD939572F25A448A3AE3CAEA61328C23784EC2E@BC-MAIL-M28.internal.baidu.com>
On Thu, 12 Jul 2018 02:31:10 +0000
"Li,Rongqing" <lirongqing@baidu.com> wrote:
> > -----邮件原件-----
> > 发件人: Stefano Brivio [mailto:sbrivio@redhat.com]
> > 发送时间: 2018年7月11日 18:52
> > 收件人: Li,Rongqing <lirongqing@baidu.com>
> > 抄送: netdev@vger.kernel.org; Eric Dumazet <edumazet@google.com>
> > 主题: Re: [PATCH] net: convert gro_count to bitmask
> >
> > On Wed, 11 Jul 2018 17:15:53 +0800
> > Li RongQing <lirongqing@baidu.com> wrote:
> >
> > > @@ -5380,6 +5382,12 @@ static enum gro_result dev_gro_receive(struct
> > napi_struct *napi, struct sk_buff
> > > if (grow > 0)
> > > gro_pull_from_frag0(skb, grow);
> > > ok:
> > > + if (napi->gro_hash[hash].count)
> > > + if (!test_bit(hash, &napi->gro_bitmask))
> > > + set_bit(hash, &napi->gro_bitmask);
> > > + else if (test_bit(hash, &napi->gro_bitmask))
> > > + clear_bit(hash, &napi->gro_bitmask);
> >
> > This might not do what you want.
> >
> > --
>
> could you show detail ?
$ cat if1.c; gcc -o if1 if1.c
#include <stdio.h>
int main()
{
if (1)
if (0)
;
else if (2)
printf("whoops\n");
return 0;
}
$ ./if1
whoops
$ cat if2.c; gcc -o if2 if2.c
#include <stdio.h>
int main()
{
if (1) {
if (0)
;
} else if (2) {
printf("whoops\n");
}
return 0;
}
$ ./if2
--
Stefano
^ permalink raw reply
* Re: KASAN: use-after-free Write in tls_push_record (2)
From: Boris Pismenny @ 2018-07-12 10:44 UTC (permalink / raw)
To: syzbot, aviadye, davejwatson, davem, linux-kernel, netdev,
syzkaller-bugs
In-Reply-To: <000000000000ae783b0570c2ba09@google.com>
It seems to me that the crash here is due to write_space being called
after the close system call. Maybe the correct solution is to move the
TX software state to be released in sk_destruct. As we already do for
the device state (see tls_device.c).
Is anyone looking into this one?
On 7/11/2018 8:49 PM, syzbot wrote:
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit: 1e09177acae3 Merge tag 'mips_fixes_4.18_3' of
> git://git.ke..
> git tree: upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=128903b2400000
> kernel config: https://syzkaller.appspot.com/x/.config?x=25856fac4e580aa7
> dashboard link:
> https://syzkaller.appspot.com/bug?extid=6c4e6ecbf9a2797be67c
> compiler: gcc (GCC) 8.0.1 20180413 (experimental)
> syzkaller repro:https://syzkaller.appspot.com/x/repro.syz?x=12312678400000
> C reproducer: https://syzkaller.appspot.com/x/repro.c?x=13ef76c2400000
>
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+6c4e6ecbf9a2797be67c@syzkaller.appspotmail.com
>
> RDX: 00000000fffffdef RSI: 00000000200005c0 RDI: 0000000000000003
> RBP: 00000000006cb018 R08: 0000000020000000 R09: 000000000000001c
> R10: 0000000000000040 R11: 0000000000000212 R12: 0000000000000005
> R13: ffffffffffffffff R14: 0000000000000000 R15: 0000000000000000
> ==================================================================
> BUG: KASAN: use-after-free in tls_fill_prepend include/net/tls.h:339
> [inline]
> BUG: KASAN: use-after-free in tls_push_record+0x1091/0x1400
> net/tls/tls_sw.c:239
> Write of size 1 at addr ffff8801ae430000 by task syz-executor589/4567
>
> CPU: 0 PID: 4567 Comm: syz-executor589 Not tainted 4.18.0-rc4+ #141
> 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+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_store1_noabort+0x17/0x20 mm/kasan/report.c:435
> tls_fill_prepend include/net/tls.h:339 [inline]
> tls_push_record+0x1091/0x1400 net/tls/tls_sw.c:239
> tls_sw_push_pending_record+0x22/0x30 net/tls/tls_sw.c:276
> tls_handle_open_record net/tls/tls_main.c:164 [inline]
> tls_sk_proto_close+0x74c/0xae0 net/tls/tls_main.c:264
> inet_release+0x104/0x1f0 net/ipv4/af_inet.c:427
> inet6_release+0x50/0x70 net/ipv6/af_inet6.c:459
> __sock_release+0xd7/0x260 net/socket.c:599
> sock_close+0x19/0x20 net/socket.c:1150
> __fput+0x355/0x8b0 fs/file_table.c:209
> ____fput+0x15/0x20 fs/file_table.c:243
> task_work_run+0x1ec/0x2a0 kernel/task_work.c:113
> exit_task_work include/linux/task_work.h:22 [inline]
> do_exit+0x1b08/0x2750 kernel/exit.c:865
> do_group_exit+0x177/0x440 kernel/exit.c:968
> __do_sys_exit_group kernel/exit.c:979 [inline]
> __se_sys_exit_group kernel/exit.c:977 [inline]
> __x64_sys_exit_group+0x3e/0x50 kernel/exit.c:977
> do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
> entry_SYSCALL_64_after_hwframe+0x49/0xbe
> RIP: 0033:0x43f358
> Code: Bad RIP value.
> RSP: 002b:00007fff51750198 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7
> RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 000000000043f358
> RDX: 0000000000000000 RSI: 000000000000003c RDI: 0000000000000000
> RBP: 00000000004bf448 R08: 00000000000000e7 R09: ffffffffffffffd0
> R10: 0000000000000040 R11: 0000000000000246 R12: 0000000000000001
> R13: 00000000006d1180 R14: 0000000000000000 R15: 0000000000000000
>
> The buggy address belongs to the page:
> page:ffffea0006b90c00 count:0 mapcount:-128 mapping:0000000000000000
> index:0x0
> flags: 0x2fffc0000000000()
> raw: 02fffc0000000000 ffffea0006b96408 ffff88021fffac18 0000000000000000
> raw: 0000000000000000 0000000000000003 00000000ffffff7f 0000000000000000
> page dumped because: kasan: bad access detected
>
> Memory state around the buggy address:
> ffff8801ae42ff00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
> ffff8801ae42ff80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
>> ffff8801ae430000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> ^
> ffff8801ae430080: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> ffff8801ae430100: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> ==================================================================
>
>
> ---
> 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 net-next] net/tls: Removed redundant variable from 'struct tls_sw_context_rx'
From: Boris Pismenny @ 2018-07-12 10:41 UTC (permalink / raw)
To: Vakul Garg, davem, davejwatson, netdev; +Cc: aviadye
In-Reply-To: <20180712110350.25011-1-vakul.garg@nxp.com>
Hi Vakul,
On 7/12/2018 7:03 AM, Vakul Garg wrote:
> The variable 'decrypted' in 'struct tls_sw_context_rx' is redundant and
> is being set/unset without purpose. Simplified the code by removing it.
>
AFAIU, this variable has an important use here. It keeps the state
whether the current record has been decrypted between invocations of the
recv/splice system calls. Otherwise, some records would be decrypted
more than once if the entire record was not read.
> Signed-off-by: Vakul Garg <vakul.garg@nxp.com>
> ---
> include/net/tls.h | 1 -
> net/tls/tls_sw.c | 87 ++++++++++++++++++++++++-------------------------------
> 2 files changed, 38 insertions(+), 50 deletions(-)
>
> diff --git a/include/net/tls.h b/include/net/tls.h
> index 70c273777fe9..528d0c2d6cc2 100644
> --- a/include/net/tls.h
> +++ b/include/net/tls.h
> @@ -113,7 +113,6 @@ struct tls_sw_context_rx {
> struct poll_table_struct *wait);
> struct sk_buff *recv_pkt;
> u8 control;
> - bool decrypted;
>
> char rx_aad_ciphertext[TLS_AAD_SPACE_SIZE];
> char rx_aad_plaintext[TLS_AAD_SPACE_SIZE];
> diff --git a/net/tls/tls_sw.c b/net/tls/tls_sw.c
> index 0d670c8adf18..e5f2de2c3fd6 100644
> --- a/net/tls/tls_sw.c
> +++ b/net/tls/tls_sw.c
> @@ -81,8 +81,6 @@ static int tls_do_decryption(struct sock *sk,
> rxm->full_len -= tls_ctx->rx.overhead_size;
> tls_advance_record_sn(sk, &tls_ctx->rx);
>
> - ctx->decrypted = true;
> -
> ctx->saved_data_ready(sk);
>
> out:
> @@ -756,6 +754,9 @@ int tls_sw_recvmsg(struct sock *sk,
> bool cmsg = false;
> int target, err = 0;
> long timeo;
> + int page_count;
> + int to_copy;
> +
>
> flags |= nonblock;
>
> @@ -792,46 +793,38 @@ int tls_sw_recvmsg(struct sock *sk,
> goto recv_end;
> }
>
> - if (!ctx->decrypted) {
> - int page_count;
> - int to_copy;
> -
> - page_count = iov_iter_npages(&msg->msg_iter,
> - MAX_SKB_FRAGS);
> - to_copy = rxm->full_len - tls_ctx->rx.overhead_size;
> - if (to_copy <= len && page_count < MAX_SKB_FRAGS &&
> - likely(!(flags & MSG_PEEK))) {
> - struct scatterlist sgin[MAX_SKB_FRAGS + 1];
> - int pages = 0;
> -
> - zc = true;
> - sg_init_table(sgin, MAX_SKB_FRAGS + 1);
> - sg_set_buf(&sgin[0], ctx->rx_aad_plaintext,
> - TLS_AAD_SPACE_SIZE);
> -
> - err = zerocopy_from_iter(sk, &msg->msg_iter,
> - to_copy, &pages,
> - &chunk, &sgin[1],
> - MAX_SKB_FRAGS, false);
> - if (err < 0)
> - goto fallback_to_reg_recv;
> -
> - err = decrypt_skb(sk, skb, sgin);
> - for (; pages > 0; pages--)
> - put_page(sg_page(&sgin[pages]));
> - if (err < 0) {
> - tls_err_abort(sk, EBADMSG);
> - goto recv_end;
> - }
> - } else {
> + page_count = iov_iter_npages(&msg->msg_iter, MAX_SKB_FRAGS);
> + to_copy = rxm->full_len - tls_ctx->rx.overhead_size;
> +
> + if (to_copy <= len && page_count < MAX_SKB_FRAGS &&
> + likely(!(flags & MSG_PEEK))) {
> + struct scatterlist sgin[MAX_SKB_FRAGS + 1];
> + int pages = 0;
> +
> + zc = true;
> + sg_init_table(sgin, MAX_SKB_FRAGS + 1);
> + sg_set_buf(&sgin[0], ctx->rx_aad_plaintext,
> + TLS_AAD_SPACE_SIZE);
> + err = zerocopy_from_iter(sk, &msg->msg_iter, to_copy,
> + &pages, &chunk, &sgin[1],
> + MAX_SKB_FRAGS, false);
> + if (err < 0)
> + goto fallback_to_reg_recv;
> +
> + err = decrypt_skb(sk, skb, sgin);
> + for (; pages > 0; pages--)
> + put_page(sg_page(&sgin[pages]));
> + if (err < 0) {
> + tls_err_abort(sk, EBADMSG);
> + goto recv_end;
> + }
> + } else {
> fallback_to_reg_recv:
> - err = decrypt_skb(sk, skb, NULL);
> - if (err < 0) {
> - tls_err_abort(sk, EBADMSG);
> - goto recv_end;
> - }
> + err = decrypt_skb(sk, skb, NULL);
> + if (err < 0) {
> + tls_err_abort(sk, EBADMSG);
> + goto recv_end;
> }
> - ctx->decrypted = true;
> }
>
> if (!zc) {
> @@ -895,15 +888,13 @@ ssize_t tls_sw_splice_read(struct socket *sock, loff_t *ppos,
> goto splice_read_end;
> }
>
> - if (!ctx->decrypted) {
> - err = decrypt_skb(sk, skb, NULL);
> + err = decrypt_skb(sk, skb, NULL);
>
> - if (err < 0) {
> - tls_err_abort(sk, EBADMSG);
> - goto splice_read_end;
> - }
> - ctx->decrypted = true;
> + if (err < 0) {
> + tls_err_abort(sk, EBADMSG);
> + goto splice_read_end;
> }
> +
> rxm = strp_msg(skb);
>
> chunk = min_t(unsigned int, rxm->full_len, len);
> @@ -998,8 +989,6 @@ static void tls_queue(struct strparser *strp, struct sk_buff *skb)
> struct tls_context *tls_ctx = tls_get_ctx(strp->sk);
> struct tls_sw_context_rx *ctx = tls_sw_ctx_rx(tls_ctx);
>
> - ctx->decrypted = false;
> -
> ctx->recv_pkt = skb;
> strp_pause(strp);
>
>
^ permalink raw reply
* [V9fs-developer] [PATCH] p9_parse_header() validate PDU length
From: Tomas Bortoli @ 2018-07-12 11:02 UTC (permalink / raw)
To: ericvh, rminnich, lucho
Cc: asmadeus, viro, davem, v9fs-developer, netdev, linux-kernel,
syzkaller, Tomas Bortoli
This patch adds checks to the p9_parse_header() function to
verify that the length found within the header coincides with the actual
length of the PDU. Furthermore, it checks that the length stays within the
acceptable range. To do this the patch brings the actual length of the PDU
from the different transport layers (rdma and virtio). For TCP (trans_fd.c)
the length is not know before, so we get it from the header but we check it
anyway that it's within the valid range.
Signed-off-by: Tomas Bortoli <tomasbortoli@gmail.com>
Reported-by: syzbot+65c6b72f284a39d416b4@syzkaller.appspotmail.com
---
net/9p/client.c | 26 ++++++++++++++++----------
net/9p/trans_fd.c | 17 ++++++-----------
net/9p/trans_rdma.c | 2 +-
net/9p/trans_virtio.c | 6 ++++--
4 files changed, 27 insertions(+), 24 deletions(-)
diff --git a/net/9p/client.c b/net/9p/client.c
index 18c5271910dc..119de44f49e9 100644
--- a/net/9p/client.c
+++ b/net/9p/client.c
@@ -477,20 +477,11 @@ p9_parse_header(struct p9_fcall *pdu, int32_t *size, int8_t *type, int16_t *tag,
int err;
pdu->offset = 0;
- if (pdu->size == 0)
- pdu->size = 7;
err = p9pdu_readf(pdu, 0, "dbw", &r_size, &r_type, &r_tag);
if (err)
goto rewind_and_exit;
- pdu->size = r_size;
- pdu->id = r_type;
- pdu->tag = r_tag;
-
- p9_debug(P9_DEBUG_9P, "<<< size=%d type: %d tag: %d\n",
- pdu->size, pdu->id, pdu->tag);
-
if (type)
*type = r_type;
if (tag)
@@ -498,6 +489,21 @@ p9_parse_header(struct p9_fcall *pdu, int32_t *size, int8_t *type, int16_t *tag,
if (size)
*size = r_size;
+ if (pdu->size != r_size) {
+ err = -EINVAL;
+ goto rewind_and_exit;
+ }
+ if (pdu->size >= pdu->capacity || pdu->size < 7) {
+ p9_debug(P9_DEBUG_ERROR,
+ "requested packet size too big or too small: %d\n",
+ pdu->size);
+ return -EIO;
+ }
+ pdu->id = r_type;
+ pdu->tag = r_tag;
+
+ p9_debug(P9_DEBUG_9P, "<<< size=%d type: %d tag: %d\n",
+ pdu->size, pdu->id, pdu->tag);
rewind_and_exit:
if (rewind)
@@ -1575,7 +1581,7 @@ p9_client_read(struct p9_fid *fid, u64 offset, struct iov_iter *to, int *err)
int count = iov_iter_count(to);
int rsize, non_zc = 0;
char *dataptr;
-
+
rsize = fid->iounit;
if (!rsize || rsize > clnt->msize-P9_IOHDRSZ)
rsize = clnt->msize - P9_IOHDRSZ;
diff --git a/net/9p/trans_fd.c b/net/9p/trans_fd.c
index 588bf88c3305..bf459ee0feab 100644
--- a/net/9p/trans_fd.c
+++ b/net/9p/trans_fd.c
@@ -323,22 +323,16 @@ static void p9_read_work(struct work_struct *work)
/* header read in */
if ((!m->req) && (m->rc.offset == m->rc.capacity)) {
p9_debug(P9_DEBUG_TRANS, "got new header\n");
-
- err = p9_parse_header(&m->rc, NULL, NULL, NULL, 0);
+ /* Header size */
+ m->rc.size = 7;
+ m->rc.capacity = m->client->msize;
+ err = p9_parse_header(&m->rc, &m->rc.size, NULL, NULL, 0);
if (err) {
p9_debug(P9_DEBUG_ERROR,
"error parsing header: %d\n", err);
goto error;
}
- if (m->rc.size >= m->client->msize) {
- p9_debug(P9_DEBUG_ERROR,
- "requested packet size too big: %d\n",
- m->rc.size);
- err = -EIO;
- goto error;
- }
-
p9_debug(P9_DEBUG_TRANS,
"mux %p pkt: size: %d bytes tag: %d\n",
m, m->rc.size, m->rc.tag);
@@ -360,7 +354,7 @@ static void p9_read_work(struct work_struct *work)
goto error;
}
m->rc.sdata = (char *)m->req->rc + sizeof(struct p9_fcall);
- memcpy(m->rc.sdata, m->tmp_buf, m->rc.capacity);
+ memcpy(m->rc.sdata, m->tmp_buf, 7);
m->rc.capacity = m->rc.size;
}
@@ -369,6 +363,7 @@ static void p9_read_work(struct work_struct *work)
*/
if ((m->req) && (m->rc.offset == m->rc.capacity)) {
p9_debug(P9_DEBUG_TRANS, "got new packet\n");
+ m->req->rc->size = m->rc.offset;
spin_lock(&m->client->lock);
if (m->req->status != REQ_STATUS_ERROR)
status = REQ_STATUS_RCVD;
diff --git a/net/9p/trans_rdma.c b/net/9p/trans_rdma.c
index 3d414acb7015..002badbcc9c0 100644
--- a/net/9p/trans_rdma.c
+++ b/net/9p/trans_rdma.c
@@ -319,7 +319,7 @@ recv_done(struct ib_cq *cq, struct ib_wc *wc)
if (wc->status != IB_WC_SUCCESS)
goto err_out;
-
+ c->rc->size = wc->byte_len;
err = p9_parse_header(c->rc, NULL, NULL, &tag, 1);
if (err)
goto err_out;
diff --git a/net/9p/trans_virtio.c b/net/9p/trans_virtio.c
index 05006cbb3361..6d515f7ebfaf 100644
--- a/net/9p/trans_virtio.c
+++ b/net/9p/trans_virtio.c
@@ -159,8 +159,10 @@ static void req_done(struct virtqueue *vq)
spin_unlock_irqrestore(&chan->lock, flags);
/* Wakeup if anyone waiting for VirtIO ring space. */
wake_up(chan->vc_wq);
- if (len)
+ if (len) {
+ req->rc->size = len;
p9_client_cb(chan->client, req, REQ_STATUS_RCVD);
+ }
}
}
@@ -446,7 +448,7 @@ p9_virtio_zc_request(struct p9_client *client, struct p9_req_t *req,
out += pack_sg_list_p(chan->sg, out, VIRTQUEUE_NUM,
out_pages, out_nr_pages, offs, outlen);
}
-
+
/*
* Take care of in data
* For example TREAD have 11.
--
2.11.0
^ permalink raw reply related
* RE: [PATCH net-next] net/tls: Removed redundant variable from 'struct tls_sw_context_rx'
From: Vakul Garg @ 2018-07-12 11:14 UTC (permalink / raw)
To: Boris Pismenny, davem@davemloft.net, davejwatson@fb.com,
netdev@vger.kernel.org
Cc: aviadye@mellanox.com
In-Reply-To: <3e1dfaea-8895-69fc-476f-b80124713652@mellanox.com>
Hi Boris
Thanks for explaining.
Few questions/observations.
1. Isn't ' ctx->decrypted = true' a redundant statement in tls_do_decryption()?
The same has been repeated in tls_recvmsg() after calling decrypt_skb()?
2. Similarly, ctx->saved_data_ready(sk) seems not required in tls_do_decryption().
This is because tls_do_decryption() is already triggered from tls_recvmsg() i.e. from user space app context.
3. In tls_queue(), I think strp->sk->sk_state_change() needs to be replaced with ctx->saved_data_ready().
Regards
Vakul
> -----Original Message-----
> From: Boris Pismenny [mailto:borisp@mellanox.com]
> Sent: Thursday, July 12, 2018 4:11 PM
> To: Vakul Garg <vakul.garg@nxp.com>; davem@davemloft.net;
> davejwatson@fb.com; netdev@vger.kernel.org
> Cc: aviadye@mellanox.com
> Subject: Re: [PATCH net-next] net/tls: Removed redundant variable from
> 'struct tls_sw_context_rx'
>
> Hi Vakul,
>
> On 7/12/2018 7:03 AM, Vakul Garg wrote:
> > The variable 'decrypted' in 'struct tls_sw_context_rx' is redundant
> > and is being set/unset without purpose. Simplified the code by removing it.
> >
>
> AFAIU, this variable has an important use here. It keeps the state whether
> the current record has been decrypted between invocations of the
> recv/splice system calls. Otherwise, some records would be decrypted more
> than once if the entire record was not read.
>
> > Signed-off-by: Vakul Garg <vakul.garg@nxp.com>
> > ---
> > include/net/tls.h | 1 -
> > net/tls/tls_sw.c | 87 ++++++++++++++++++++++++----------------------------
> ---
> > 2 files changed, 38 insertions(+), 50 deletions(-)
> >
> > diff --git a/include/net/tls.h b/include/net/tls.h index
> > 70c273777fe9..528d0c2d6cc2 100644
> > --- a/include/net/tls.h
> > +++ b/include/net/tls.h
> > @@ -113,7 +113,6 @@ struct tls_sw_context_rx {
> > struct poll_table_struct *wait);
> > struct sk_buff *recv_pkt;
> > u8 control;
> > - bool decrypted;
> >
> > char rx_aad_ciphertext[TLS_AAD_SPACE_SIZE];
> > char rx_aad_plaintext[TLS_AAD_SPACE_SIZE];
> > diff --git a/net/tls/tls_sw.c b/net/tls/tls_sw.c index
> > 0d670c8adf18..e5f2de2c3fd6 100644
> > --- a/net/tls/tls_sw.c
> > +++ b/net/tls/tls_sw.c
> > @@ -81,8 +81,6 @@ static int tls_do_decryption(struct sock *sk,
> > rxm->full_len -= tls_ctx->rx.overhead_size;
> > tls_advance_record_sn(sk, &tls_ctx->rx);
> >
> > - ctx->decrypted = true;
> > -
> > ctx->saved_data_ready(sk);
> >
> > out:
> > @@ -756,6 +754,9 @@ int tls_sw_recvmsg(struct sock *sk,
> > bool cmsg = false;
> > int target, err = 0;
> > long timeo;
> > + int page_count;
> > + int to_copy;
> > +
> >
> > flags |= nonblock;
> >
> > @@ -792,46 +793,38 @@ int tls_sw_recvmsg(struct sock *sk,
> > goto recv_end;
> > }
> >
> > - if (!ctx->decrypted) {
> > - int page_count;
> > - int to_copy;
> > -
> > - page_count = iov_iter_npages(&msg->msg_iter,
> > - MAX_SKB_FRAGS);
> > - to_copy = rxm->full_len - tls_ctx->rx.overhead_size;
> > - if (to_copy <= len && page_count < MAX_SKB_FRAGS
> &&
> > - likely(!(flags & MSG_PEEK))) {
> > - struct scatterlist sgin[MAX_SKB_FRAGS + 1];
> > - int pages = 0;
> > -
> > - zc = true;
> > - sg_init_table(sgin, MAX_SKB_FRAGS + 1);
> > - sg_set_buf(&sgin[0], ctx->rx_aad_plaintext,
> > - TLS_AAD_SPACE_SIZE);
> > -
> > - err = zerocopy_from_iter(sk, &msg-
> >msg_iter,
> > - to_copy, &pages,
> > - &chunk, &sgin[1],
> > - MAX_SKB_FRAGS,
> false);
> > - if (err < 0)
> > - goto fallback_to_reg_recv;
> > -
> > - err = decrypt_skb(sk, skb, sgin);
> > - for (; pages > 0; pages--)
> > - put_page(sg_page(&sgin[pages]));
> > - if (err < 0) {
> > - tls_err_abort(sk, EBADMSG);
> > - goto recv_end;
> > - }
> > - } else {
> > + page_count = iov_iter_npages(&msg->msg_iter,
> MAX_SKB_FRAGS);
> > + to_copy = rxm->full_len - tls_ctx->rx.overhead_size;
> > +
> > + if (to_copy <= len && page_count < MAX_SKB_FRAGS &&
> > + likely(!(flags & MSG_PEEK))) {
> > + struct scatterlist sgin[MAX_SKB_FRAGS + 1];
> > + int pages = 0;
> > +
> > + zc = true;
> > + sg_init_table(sgin, MAX_SKB_FRAGS + 1);
> > + sg_set_buf(&sgin[0], ctx->rx_aad_plaintext,
> > + TLS_AAD_SPACE_SIZE);
> > + err = zerocopy_from_iter(sk, &msg->msg_iter,
> to_copy,
> > + &pages, &chunk, &sgin[1],
> > + MAX_SKB_FRAGS, false);
> > + if (err < 0)
> > + goto fallback_to_reg_recv;
> > +
> > + err = decrypt_skb(sk, skb, sgin);
> > + for (; pages > 0; pages--)
> > + put_page(sg_page(&sgin[pages]));
> > + if (err < 0) {
> > + tls_err_abort(sk, EBADMSG);
> > + goto recv_end;
> > + }
> > + } else {
> > fallback_to_reg_recv:
> > - err = decrypt_skb(sk, skb, NULL);
> > - if (err < 0) {
> > - tls_err_abort(sk, EBADMSG);
> > - goto recv_end;
> > - }
> > + err = decrypt_skb(sk, skb, NULL);
> > + if (err < 0) {
> > + tls_err_abort(sk, EBADMSG);
> > + goto recv_end;
> > }
> > - ctx->decrypted = true;
> > }
> >
> > if (!zc) {
> > @@ -895,15 +888,13 @@ ssize_t tls_sw_splice_read(struct socket *sock,
> loff_t *ppos,
> > goto splice_read_end;
> > }
> >
> > - if (!ctx->decrypted) {
> > - err = decrypt_skb(sk, skb, NULL);
> > + err = decrypt_skb(sk, skb, NULL);
> >
> > - if (err < 0) {
> > - tls_err_abort(sk, EBADMSG);
> > - goto splice_read_end;
> > - }
> > - ctx->decrypted = true;
> > + if (err < 0) {
> > + tls_err_abort(sk, EBADMSG);
> > + goto splice_read_end;
> > }
> > +
> > rxm = strp_msg(skb);
> >
> > chunk = min_t(unsigned int, rxm->full_len, len); @@ -998,8 +989,6
> > @@ static void tls_queue(struct strparser *strp, struct sk_buff *skb)
> > struct tls_context *tls_ctx = tls_get_ctx(strp->sk);
> > struct tls_sw_context_rx *ctx = tls_sw_ctx_rx(tls_ctx);
> >
> > - ctx->decrypted = false;
> > -
> > ctx->recv_pkt = skb;
> > strp_pause(strp);
> >
> >
^ permalink raw reply
* Re: Re: [Qemu-devel] [PATCH v3 0/3] Use of unique identifier for pairing virtio and passthrough devices...
From: Cornelia Huck @ 2018-07-12 11:31 UTC (permalink / raw)
To: Siwei Liu
Cc: Michael S. Tsirkin, si-wei liu, Roman Kagan, Venu Busireddy,
Marcel Apfelbaum, virtio-dev, qemu-devel, Samudrala, Sridhar,
Alexander Duyck, Netdev
In-Reply-To: <CADGSJ20A=sbwQQ-_YQEVwoCXwTvosCEnD2iKa0kS6ZGvbgy4rg@mail.gmail.com>
On Thu, 12 Jul 2018 02:37:03 -0700
Siwei Liu <loseweigh@gmail.com> wrote:
> On Wed, Jul 11, 2018 at 2:53 AM, Cornelia Huck <cohuck@redhat.com> wrote:
> > On Tue, 10 Jul 2018 17:07:37 -0700
> > Siwei Liu <loseweigh@gmail.com> wrote:
> >
> >> On Mon, Jul 9, 2018 at 6:54 PM, Michael S. Tsirkin <mst@redhat.com> wrote:
> >> > On Mon, Jul 09, 2018 at 06:11:53PM -0700, si-wei liu wrote:
> >> >> The plan is to enable group ID based matching in the first place rather than
> >> >> match by MAC, the latter of which is fragile and problematic.
> >> >
> >> > It isn't all that fragile - hyperv used same for a while, so if someone
> >> > posts working patches with QEMU support but before this grouping stuff,
> >> > I'll happily apply them.
> >>
> >> I wouldn't box the solution to very limited scenario just because of
> >> matching by MAC, the benefit of having generic group ID in the first
> >> place is that we save the effort of maintaining legacy MAC based
> >> pairing that just adds complexity anyway. Currently the VF's MAC
> >> address cannot be changed by either PF or by the guest user is a
> >> severe limitation due to this. The other use case is that PT device
> >> than VF would generally have different MAC than the standby virtio. We
> >> shouldn't limit itself to VF specific scenario from the very
> >> beginning.
> >
> > So, this brings me to a different concern: the semantics of
> > VIRTIO_NET_F_STANDBY.
> >
> > * The currently sole user seems to be the virtio-net Linux driver.
> > * The commit messages, code comments and Documentation/ all talk about
> > matching by MAC.
> > * I could not find any proposed update to the virtio spec. (If there
> > had been an older proposal with a different feature name, it is not
> > discoverable.)
>
> No, there was no such spec patch at all when the Linux patch was
> submitted, hence match by MAC is the only means to pair device due to
> lack of QEMU support.
We need to know what the device offers if it offers the feature bit,
and what it is supposed to do when the driver negotiates it. Currently,
we can only go by what the Linux driver does and what it expects. IOW,
we need a spec update proposal. Obviously, this should be discussed in
conjunction with the rest.
>
> Q: Does it work?
> A: Well, it works for some.
> Q: Does it work well to support all scenarios?
> A: No, not as it claims to.
> Q: Can it do better job to support all scenarios?
> A: Yes, do pairing with the failover group ID instead.
> Q: Does pairing still need to be MAC based if using failover group ID?
> A: It depends, it's up to the implementation to verify MAC address
> depending on the need (e.g. VF failover versus PT device replacement),
> though MAC matching is no longer positioned as a requirement for
> pairing or grouping.
Whether matching by MAC is good or sufficient is a different
discussion. It is, however, what the code currently *does*, and in
absence of a spec update, it is the only reference for this feature.
>
> There's no such stickiness for matching by MAC defined anywhere. The
> semantics of VIRTIO_NET_F_STANDBY feature are mostly a failover
> concept that the standby device should be used when the primary is not
> present. We now have added the group ID on QEMU. I don't see why
> bothering to get rid of the limitation: it's never been exposed. No
> existing users. No API/ABI defined at all.
This is scheduled to be released with the next Linux version, which is
right now in the -rc phase. It *is* API (a guest <-> host API).
No corresponding code is present in QEMU 3.0, which is in freeze right
now. Anything that goes into QEMU 3.1 or later needs to accommodate
Linux 4.18 as a guest.
>
> >
> > VIRTIO_NET_F_STANDBY is a host <-> guest interface. As there's no
> > official spec, you can only go by the Linux implementation, and by that
> > its semantics seem to be 'match by MAC', not 'match by other criteria'.
> >
> > How is this supposed to work in the long run?
>
> That group ID thing should work for all OS. Not just Linux.
That's exactly my point: We need to care about not-Linux. And about
not-QEMU as well. A virtio feature bit should not be defined by what
Linux and QEMU do, but needs a real spec.
So, currently we have a Linux driver implementation that matches by
MAC. If a Linux version with this is released, every device that offers
VIRTIO_NET_F_STANDBY needs to support matching by MAC so that this
Linux driver will not break. Adding further matching methods should be
fine, but might need additional features (needs to be discussed).
^ permalink raw reply
* Re: [V9fs-developer] [PATCH] p9_parse_header() validate PDU length
From: Dominique Martinet @ 2018-07-12 11:43 UTC (permalink / raw)
To: Tomas Bortoli
Cc: ericvh, rminnich, lucho, viro, davem, v9fs-developer, netdev,
linux-kernel, syzkaller
In-Reply-To: <20180712110211.25535-1-tomasbortoli@gmail.com>
Tomas Bortoli wrote on Thu, Jul 12, 2018:
> This patch adds checks to the p9_parse_header() function to
> verify that the length found within the header coincides with the actual
> length of the PDU. Furthermore, it checks that the length stays within the
> acceptable range. To do this the patch brings the actual length of the PDU
> from the different transport layers (rdma and virtio). For TCP (trans_fd.c)
> the length is not know before, so we get it from the header but we check it
> anyway that it's within the valid range.
Just a note on transports here, I totally had forgotten about trans_xen
when we discussed this earlier as it is fairly new, but it looks like it
sets the length in the fcall properly so it should work without any
change.
I however cannot test trans=xen, so if someone could either point me to
how to set that up (I couldn't find any decent documentation) or do some
very basic tests that would be great.
> Signed-off-by: Tomas Bortoli <tomasbortoli@gmail.com>
> Reported-by: syzbot+65c6b72f284a39d416b4@syzkaller.appspotmail.com
Looks good to me, as the rdma/virtio part come from my suggestion:
Signed-off-by: Dominique Martinet <dominique.martinet@cea.fr>
> diff --git a/net/9p/trans_rdma.c b/net/9p/trans_rdma.c
> index 3d414acb7015..002badbcc9c0 100644
> --- a/net/9p/trans_rdma.c
> +++ b/net/9p/trans_rdma.c
> @@ -319,7 +319,7 @@ recv_done(struct ib_cq *cq, struct ib_wc *wc)
>
> if (wc->status != IB_WC_SUCCESS)
> goto err_out;
> -
> + c->rc->size = wc->byte_len;
(nitpick, I'd keep the empty line here. If you don't mind I'll add it
back in my tree; this doesn't warrant a v2)
--
Dominique Martinet
^ permalink raw reply
* [PATCH net-next 00/18] net: mvpp2: add RSS support
From: Maxime Chevallier @ 2018-07-12 11:54 UTC (permalink / raw)
To: davem
Cc: Maxime Chevallier, netdev, linux-kernel, Antoine Tenart,
thomas.petazzoni, gregory.clement, miquel.raynal, nadavh, stefanc,
ymarkman, mw
This series adds support for RSS on PPv2. There already was some code to
handle the RSS tables, but the driver was missing all the classification
steps required to actually use these tables.
RSS is used through the classifier, using at least 2 lookups :
- One using the C2 engine, a TCAM engine that match the packet based on
some header extracted fields, assigns the default rx queue for that
packet and tag it for RSS
- One using the C3Hx engine, which computes the hash that's used to perform
the lookup in the RSS table.
Since RSS spreads the load across CPUs, we need to make sure that packets
from the same flow are always assigned the same rx queue, to prevent
re-ordering.
This series therefore adds a classification step based on the Header Parser,
that separate ingress traffic into 52 flows, based on some L2, L3 and L4
parameters.
Patches 1 and 2 fix some header issues, from the driver splitting
Patches 3 to 7 make sure the correct receive queue setup is used for RSS
Patches 8 to 14 deal with the way we handle the RSS tables
Patch 15 implement basic classifier configuration, by using it to assign the
default receive queue
Patch 16 implement the ingress traffic splitting into multiple flows
Patch 17 adds RSS support, by using the needed classification steps
Patch 18 adds the required ethtool ops to configure the flow hash parameters
This was tested on MacchiatoBin, giving some nice performance improvements
using ip forwarding (going from 5Gbps to 9.6Gbps total throughput).
RSS is disabled by default.
Antoine Tenart (3):
net: mvpp2: fix a typo in the RSS code
net: mvpp2: RSS indirection table support
net: mvpp2: improve the distribution of packets on CPUs when using RSS
Maxime Chevallier (14):
net: mvpp2: fix include guards in mvpp2_prs.h
net: mvpp2: define the number of RSS entries per table in mvpp2.h
net: mvpp2: make sure we use single queue mode on PPv2.1
net: mvpp2: make multi queue mode the default mode
net: mvpp2: fix hardcoded number of rx queues
net: mvpp2: use only one rx queue per port per CPU
net: mvpp2: fix RSS register definitions
net: mvpp2: use one RSS table per port
net: mvpp2: make sure we don't spread load on disabled CPUs
net: mvpp2: rename per-port RSS init function
net: mvpp2: use classifier to assign default rx queue
net: mvpp2: split ingress traffic into multiple flows
net: mvpp2: add an RSS classification step for each flow
net: mvpp2: allow setting RSS flow hash parameters with ethtool
Yan Markman (1):
net: mvpp2: use RSS only when using multi-queue mode
drivers/net/ethernet/marvell/mvpp2/mvpp2.h | 52 +-
drivers/net/ethernet/marvell/mvpp2/mvpp2_cls.c | 929 +++++++++++++++++++++++-
drivers/net/ethernet/marvell/mvpp2/mvpp2_cls.h | 177 ++++-
drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c | 127 +++-
drivers/net/ethernet/marvell/mvpp2/mvpp2_prs.c | 35 +
drivers/net/ethernet/marvell/mvpp2/mvpp2_prs.h | 18 +-
6 files changed, 1307 insertions(+), 31 deletions(-)
--
2.11.0
^ permalink raw reply
* [PATCH net-next 01/18] net: mvpp2: fix include guards in mvpp2_prs.h
From: Maxime Chevallier @ 2018-07-12 11:54 UTC (permalink / raw)
To: davem
Cc: Maxime Chevallier, netdev, linux-kernel, Antoine Tenart,
thomas.petazzoni, gregory.clement, miquel.raynal, nadavh, stefanc,
ymarkman, mw
In-Reply-To: <20180712115427.27375-1-maxime.chevallier@bootlin.com>
Include guards should be put before #includes. This doesn't fix any bug,
but prevent future compilation issues when adding new files in the mvpp2
driver
The Header Parser init function needs the platform_device definition,
and with the fixed include guards we need to add the missing include.
Signed-off-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
---
drivers/net/ethernet/marvell/mvpp2/mvpp2_prs.h | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/marvell/mvpp2/mvpp2_prs.h b/drivers/net/ethernet/marvell/mvpp2/mvpp2_prs.h
index a7c8d0818432..64a64666257c 100644
--- a/drivers/net/ethernet/marvell/mvpp2/mvpp2_prs.h
+++ b/drivers/net/ethernet/marvell/mvpp2/mvpp2_prs.h
@@ -9,14 +9,15 @@
* License version 2. This program is licensed "as is" without any
* warranty of any kind, whether express or implied.
*/
+#ifndef _MVPP2_PRS_H_
+#define _MVPP2_PRS_H_
+
#include <linux/kernel.h>
#include <linux/netdevice.h>
+#include <linux/platform_device.h>
#include "mvpp2.h"
-#ifndef _MVPP2_PRS_H_
-#define _MVPP2_PRS_H_
-
/* Parser constants */
#define MVPP2_PRS_TCAM_SRAM_SIZE 256
#define MVPP2_PRS_TCAM_WORDS 6
--
2.11.0
^ permalink raw reply related
* [PATCH net-next 02/18] net: mvpp2: define the number of RSS entries per table in mvpp2.h
From: Maxime Chevallier @ 2018-07-12 11:54 UTC (permalink / raw)
To: davem
Cc: Maxime Chevallier, netdev, linux-kernel, Antoine Tenart,
thomas.petazzoni, gregory.clement, miquel.raynal, nadavh, stefanc,
ymarkman, mw
In-Reply-To: <20180712115427.27375-1-maxime.chevallier@bootlin.com>
The size of the the RSS indirection tables should be defined in mvpp2.h,
so that we can use it in all files of the PPv2 driver.
This commit moves the define in mvpp2.h, and adds the missing #include
in mvpp2_cls.h.
Signed-off-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
---
drivers/net/ethernet/marvell/mvpp2/mvpp2.h | 3 +++
drivers/net/ethernet/marvell/mvpp2/mvpp2_cls.h | 5 ++---
2 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/marvell/mvpp2/mvpp2.h b/drivers/net/ethernet/marvell/mvpp2/mvpp2.h
index 18834619bb3a..5ef5b99a1935 100644
--- a/drivers/net/ethernet/marvell/mvpp2/mvpp2.h
+++ b/drivers/net/ethernet/marvell/mvpp2/mvpp2.h
@@ -557,6 +557,9 @@
#define MVPP2_BIT_TO_WORD(bit) ((bit) / 32)
#define MVPP2_BIT_IN_WORD(bit) ((bit) % 32)
+/* RSS constants */
+#define MVPP22_RSS_TABLE_ENTRIES 32
+
/* IPv6 max L3 address size */
#define MVPP2_MAX_L3_ADDR_SIZE 16
diff --git a/drivers/net/ethernet/marvell/mvpp2/mvpp2_cls.h b/drivers/net/ethernet/marvell/mvpp2/mvpp2_cls.h
index 8e1d7f9ffa0b..e571238a83cc 100644
--- a/drivers/net/ethernet/marvell/mvpp2/mvpp2_cls.h
+++ b/drivers/net/ethernet/marvell/mvpp2/mvpp2_cls.h
@@ -13,15 +13,14 @@
#ifndef _MVPP2_CLS_H_
#define _MVPP2_CLS_H_
+#include "mvpp2.h"
+
/* Classifier constants */
#define MVPP2_CLS_FLOWS_TBL_SIZE 512
#define MVPP2_CLS_FLOWS_TBL_DATA_WORDS 3
#define MVPP2_CLS_LKP_TBL_SIZE 64
#define MVPP2_CLS_RX_QUEUES 256
-/* RSS constants */
-#define MVPP22_RSS_TABLE_ENTRIES 32
-
struct mvpp2_cls_flow_entry {
u32 index;
u32 data[MVPP2_CLS_FLOWS_TBL_DATA_WORDS];
--
2.11.0
^ permalink raw reply related
* [PATCH net-next 03/18] net: mvpp2: make sure we use single queue mode on PPv2.1
From: Maxime Chevallier @ 2018-07-12 11:54 UTC (permalink / raw)
To: davem
Cc: Maxime Chevallier, netdev, linux-kernel, Antoine Tenart,
thomas.petazzoni, gregory.clement, miquel.raynal, nadavh, stefanc,
ymarkman, mw
In-Reply-To: <20180712115427.27375-1-maxime.chevallier@bootlin.com>
The PPv2 driver defines 2 "queue_modes" :
- QDIST_SINGLE_MODE, where we each port share one rx queue vector
between all CPUs
- QDIST_MULTI_MODE, where each port has one rx queue vector per CPU.
Multi queue mode isn't available on PPv2.1, make sure we fallback to
single mode when running on this revision.
Signed-off-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
---
drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
index 88f3da184d76..0d2dde336ea2 100644
--- a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
+++ b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
@@ -5014,6 +5014,12 @@ static int mvpp2_probe(struct platform_device *pdev)
(unsigned long)of_device_get_match_data(&pdev->dev);
}
+ /* multi queue mode isn't supported on PPV2.1, fallback to single
+ * mode
+ */
+ if (priv->hw_version == MVPP21)
+ queue_mode = MVPP2_QDIST_SINGLE_MODE;
+
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
base = devm_ioremap_resource(&pdev->dev, res);
if (IS_ERR(base))
--
2.11.0
^ permalink raw reply related
* [PATCH net-next 04/18] net: mvpp2: make multi queue mode the default mode
From: Maxime Chevallier @ 2018-07-12 11:54 UTC (permalink / raw)
To: davem
Cc: Maxime Chevallier, netdev, linux-kernel, Antoine Tenart,
thomas.petazzoni, gregory.clement, miquel.raynal, nadavh, stefanc,
ymarkman, mw
In-Reply-To: <20180712115427.27375-1-maxime.chevallier@bootlin.com>
The multi queue mode is needed to have RSS available, and offers some
nice advantages, being able to have one rx queue vector per CPU.
This mode has been usable through the use of a module parameter, this
commit makes it the default value.
Signed-off-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
---
drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
index 0d2dde336ea2..b1d812b12421 100644
--- a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
+++ b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
@@ -66,7 +66,7 @@ static void mvpp2_mac_config(struct net_device *dev, unsigned int mode,
#define MVPP2_QDIST_SINGLE_MODE 0
#define MVPP2_QDIST_MULTI_MODE 1
-static int queue_mode = MVPP2_QDIST_SINGLE_MODE;
+static int queue_mode = MVPP2_QDIST_MULTI_MODE;
module_param(queue_mode, int, 0444);
MODULE_PARM_DESC(queue_mode, "Set queue_mode (single=0, multi=1)");
--
2.11.0
^ permalink raw reply related
* [PATCH net-next 05/18] net: mvpp2: use RSS only when using multi-queue mode
From: Maxime Chevallier @ 2018-07-12 11:54 UTC (permalink / raw)
To: davem
Cc: Yan Markman, netdev, linux-kernel, Antoine Tenart,
thomas.petazzoni, gregory.clement, miquel.raynal, nadavh, stefanc,
mw, Maxime Chevallier
In-Reply-To: <20180712115427.27375-1-maxime.chevallier@bootlin.com>
From: Yan Markman <ymarkman@marvell.com>
Since RSS only applies when we have per-cpu rx queues, it should only
be enabled when the driver is configured to make use of multi-queue
mode.
Signed-off-by: Yan Markman <ymarkman@marvell.com>
[Maxime: Commit message]
Signed-off-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
---
drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
index b1d812b12421..75aa0dece8ae 100644
--- a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
+++ b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
@@ -3276,6 +3276,11 @@ static void mvpp2_irqs_deinit(struct mvpp2_port *port)
}
}
+static bool mvpp22_rss_is_supported(void)
+{
+ return queue_mode == MVPP2_QDIST_MULTI_MODE;
+}
+
static int mvpp2_open(struct net_device *dev)
{
struct mvpp2_port *port = netdev_priv(dev);
@@ -3368,7 +3373,7 @@ static int mvpp2_open(struct net_device *dev)
mvpp2_start_dev(port);
- if (priv->hw_version == MVPP22)
+ if (mvpp22_rss_is_supported())
mvpp22_init_rss(port);
/* Start hardware statistics gathering */
--
2.11.0
^ permalink raw reply related
* [PATCH net-next 06/18] net: mvpp2: fix hardcoded number of rx queues
From: Maxime Chevallier @ 2018-07-12 11:54 UTC (permalink / raw)
To: davem
Cc: Maxime Chevallier, netdev, linux-kernel, Antoine Tenart,
thomas.petazzoni, gregory.clement, miquel.raynal, nadavh, stefanc,
ymarkman, mw
In-Reply-To: <20180712115427.27375-1-maxime.chevallier@bootlin.com>
There's a dedicated #define that indicates the number of rx queues per
port per cpu, this commit removes a harcoded use of that value
This doesn't fix any runtime bugs since the harcoded value matches the
expected value.
Signed-off-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
---
drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
index 75aa0dece8ae..4bc0b893b026 100644
--- a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
+++ b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
@@ -3993,8 +3993,8 @@ static int mvpp2_port_init(struct mvpp2_port *port)
MVPP2_MAX_PORTS * priv->max_port_rxqs)
return -EINVAL;
- if (port->nrxqs % 4 || (port->nrxqs > priv->max_port_rxqs) ||
- (port->ntxqs > MVPP2_MAX_TXQ))
+ if (port->nrxqs % MVPP2_DEFAULT_RXQ ||
+ port->nrxqs > priv->max_port_rxqs || port->ntxqs > MVPP2_MAX_TXQ)
return -EINVAL;
/* Disable port */
--
2.11.0
^ 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