* 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: 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: 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: 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: [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: [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: 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: 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
* 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: [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
* 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
* [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: 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
* [CLOSED] LPC Plumbers Networking Track
From: David Miller @ 2018-07-12 7:13 UTC (permalink / raw)
To: netdev
The submission window for the networking track of this years's Linux
Plumbers Conference is now officially closed.
We are simply overwhelmed by the amount of submissions and the overall
quality of the content!
Please do not submit any new submissions from this point forward, it
will not be considered, sorry.
The technical committee will now review all of the pending submissions
and notify authors by the specified deadline of August 15th.
Thanks!
^ permalink raw reply
* Re: [PATCH net-next v2 0/8] be2net: small structures clean-up
From: David Miller @ 2018-07-12 7:03 UTC (permalink / raw)
To: cera; +Cc: netdev, sathya.perla, sriharsha.basavapatna
In-Reply-To: <20180710205948.10574-1-cera@cera.cz>
From: Ivan Vecera <cera@cera.cz>
Date: Tue, 10 Jul 2018 22:59:40 +0200
> The series:
> - removes unused / unneccessary fields in several be2net structures
> - re-order fields in some structures to eliminate holes, cache-lines
> crosses
> - as result reduces size of main struct be_adapter by 4kB
Series applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next] selftests: forwarding: mirror_gre_nh: Unset rp_filter on host VRF
From: David Miller @ 2018-07-12 6:59 UTC (permalink / raw)
To: petrm; +Cc: netdev, linux-kselftest, shuah, idosch
In-Reply-To: <a1d9001969381681ce4c3891ef8404b74aef177f.1531226547.git.petrm@mellanox.com>
From: Petr Machata <petrm@mellanox.com>
Date: Tue, 10 Jul 2018 14:44:26 +0200
> The mirrored packets arrive at $h3 encapsulated in GRE/IPv4, with IP
> address from 192.0.2.128/28 network. However the interface is configured
> as a member of 192.0.2.160/28 and there's no route directing traffic
> from the former network through that interface. Correspondingly, the RP
> filter on the VRF rejects it.
>
> Therefore turn off the VRF's RP filter.
>
> Signed-off-by: Petr Machata <petrm@mellanox.com>
Applied.
^ permalink raw reply
* Re: [PATCH] qed: fix spelling mistake "successffuly" -> "successfully"
From: David Miller @ 2018-07-12 7:02 UTC (permalink / raw)
To: emilne; +Cc: netdev, linux-kernel
In-Reply-To: <1531232844-23004-1-git-send-email-emilne@redhat.com>
From: "Ewan D. Milne" <emilne@redhat.com>
Date: Tue, 10 Jul 2018 10:27:24 -0400
> From: "Ewan D. Milne" <emilne@redhat.com>
>
> Trivial fix to spelling mistake in qed_probe message.
>
> Signed-off-by: Ewan D. Milne <emilne@redhat.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] net: ethernet: ti: cpts: break cycle once late ts is matched
From: David Miller @ 2018-07-12 7:00 UTC (permalink / raw)
To: ivan.khoronzhuk; +Cc: grygorii.strashko, netdev, linux-kernel
In-Reply-To: <20180710130404.3437-1-ivan.khoronzhuk@linaro.org>
From: Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org>
Date: Tue, 10 Jul 2018 16:04:04 +0300
> The late ts queue can contain a bunch of skbs while hi rate testing,
> no need to check all of them if timestamp is already matched.
>
> Signed-off-by: Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org>
> ---
>
> Based on net-next/master
Applied.
^ permalink raw reply
* Re: [PATCH net-next v2 00/11] devlink: Add support for region access
From: Alex Vesker @ 2018-07-12 6:21 UTC (permalink / raw)
To: Jakub Kicinski
Cc: netdev, jiri, dsahern, andrew, rahul.lakkireddy, linux-wireless,
Johannes Berg
In-Reply-To: <20180711114821.1d50ba63@cakuba.lan>
On 7/11/2018 9:48 PM, Jakub Kicinski wrote:
> CC: linux-wireless, wifi chips used to have similar problem
>
> On Wed, 11 Jul 2018 13:42:57 +0300, Alex Vesker wrote:
>> This is a proposal which will allow access to driver defined address
>> regions using devlink. Each device can create its supported address
>> regions and register them. A device which exposes a region will allow
>> access to it using devlink.
>>
>> The suggested implementation will allow exposing regions to the user,
>> reading and dumping snapshots taken from different regions.
>> A snapshot represents a memory image of a region taken by the driver.
>>
>> If a device collects a snapshot of an address region it can be later
>> exposed using devlink region read or dump commands.
>> This functionality allows for future analyses on the snapshots to be
>> done.
>>
>> The major benefit of this support is not only to provide access to
>> internal address regions which were inaccessible to the user but also
>> to provide an additional way to debug complex error states using the
>> region snapshots.
>>
>> Implemented commands:
>> $ devlink region help
>> $ devlink region show [ DEV/REGION ]
>> $ devlink region del DEV/REGION snapshot SNAPSHOT_ID
>> $ devlink region dump DEV/REGION [ snapshot SNAPSHOT_ID ]
>> $ devlink region read DEV/REGION [ snapshot SNAPSHOT_ID ]
>> address ADDRESS length length
> You got me excited with the read without snapshot but then you say below
> that it's future work :)
>
>> Show all of the exposed regions with region sizes:
>> $ devlink region show
>> pci/0000:00:05.0/cr-space: size 1048576 snapshot [1 2]
>> pci/0000:00:05.0/fw-health: size 64 snapshot [1 2]
>>
>> Delete a snapshot using:
>> $ devlink region del pci/0000:00:05.0/cr-space snapshot 1
>>
>> Dump a snapshot:
>> $ devlink region dump pci/0000:00:05.0/fw-health snapshot 1
>> 0000000000000000 0014 95dc 0014 9514 0035 1670 0034 db30
>> 0000000000000010 0000 0000 ffff ff04 0029 8c00 0028 8cc8
>> 0000000000000020 0016 0bb8 0016 1720 0000 0000 c00f 3ffc
>> 0000000000000030 bada cce5 bada cce5 bada cce5 bada cce5
>>
>> Read a specific part of a snapshot:
>> $ devlink region read pci/0000:00:05.0/fw-health snapshot 1 address 0
>> length 16
>> 0000000000000000 0014 95dc 0014 9514 0035 1670 0034 db30
>>
>> For more information you can check devlink-region.8 man page
>>
>> Future:
>> There is a plan to extend the support to include a write command
>> as well as performing read and dump live region
> Reading live region would be very interesting and alleviate the need
> for complicated ethtool dump marshalling a number of drivers started
> doing (incl. nfp). Any plans on that?
Yes I plan to also support read of live regions.
Unlike ethtool which works per netdevice this will allow access per PCI
device,
this allows reading region/dump on IPoIB ULP for example, which
cannot implement a vendor specific dump using ethtool.
> Write support I'm less excited about :)
^ permalink raw reply
* Re: [PATCH net 2/2] sfp: fix module initialisation with netdev already up
From: David Miller @ 2018-07-12 6:12 UTC (permalink / raw)
To: rmk+kernel; +Cc: andrew, f.fainelli, netdev
In-Reply-To: <E1fcqSe-0004W1-8A@rmk-PC.armlinux.org.uk>
From: Russell King <rmk+kernel@armlinux.org.uk>
Date: Tue, 10 Jul 2018 12:05:36 +0100
> It was been observed that with a particular order of initialisation,
> the netdev can be up, but the SFP module still has its TX_DISABLE
> signal asserted. This occurs when the network device brought up before
> the SFP kernel module has been inserted by userspace.
>
> This occurs because sfp-bus layer does not hear about the change in
> network device state, and so assumes that it is still down. Set
> netdev->sfp when the upstream is registered to work around this problem.
>
> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Applied.
^ permalink raw reply
* Re: [PATCH net 1/2] sfp: ensure we clean up properly on bus registration failure
From: David Miller @ 2018-07-12 6:11 UTC (permalink / raw)
To: rmk+kernel; +Cc: andrew, f.fainelli, netdev
In-Reply-To: <E1fcqSZ-0004Vu-3X@rmk-PC.armlinux.org.uk>
From: Russell King <rmk+kernel@armlinux.org.uk>
Date: Tue, 10 Jul 2018 12:05:31 +0100
> We fail to correctly clean up after a bus registration failure, which
> can lead to an incorrect assumption about the registration state of
> the upstream or sfp cage.
>
> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Applied.
^ permalink raw reply
* Re: [PATCH net-next 0/3] mlxsw: ERSPAN: Take LACP state into consideration
From: David Miller @ 2018-07-12 6:10 UTC (permalink / raw)
To: idosch; +Cc: netdev, petrm, jiri, mlxsw
In-Reply-To: <20180710070259.24753-1-idosch@mellanox.com>
From: Ido Schimmel <idosch@mellanox.com>
Date: Tue, 10 Jul 2018 10:02:56 +0300
> Petr says:
>
> When offloading mirror-to-gretap, mlxsw needs to preroute the path that
> the encapsulated packet will take. That path may include a LAG device
> above a front panel port. So far, mlxsw resolved the path to the first
> up front panel slave of the LAG interface, but that only reflects
> administrative state of the port. It neglects to consider whether the
> port actually has a carrier, and what the LACP state is. This patch set
> aims to address these problems.
>
> Patch #1 publishes team_port_get_rcu().
>
> Then in patch #2, a new function is introduced,
> mlxsw_sp_port_dev_check(). That returns, for a given netdevice that is a
> slave of a LAG device, whether that device is "txable", i.e. whether the
> LAG master would send traffic through it. Since there's no good place to
> put LAG-wide helpers, introduce a new header include/net/lag.h.
>
> Finally in patch #3, fix the slave selection logic to take into
> consideration whether a given slave has a carrier and whether it is
> txable.
Series applied, thank you.
^ permalink raw reply
* Re: [PATCH net-next] macvlan: Change status when lower device goes down
From: David Miller @ 2018-07-12 6:07 UTC (permalink / raw)
To: travisb; +Cc: netdev, skrishnan
In-Reply-To: <20180710003501.13971-1-travisb@arista.com>
From: Travis Brown <travisb@arista.com>
Date: Tue, 10 Jul 2018 00:35:01 +0000
> Today macvlan ignores the notification when a lower device goes
> administratively down, preventing the lack of connectivity from
> bubbling up.
>
> Processing NETDEV_DOWN results in a macvlan state of LOWERLAYERDOWN
> with NO-CARRIER which should be easy to interpret in userspace.
>
> 2: lower: <BROADCAST,MULTICAST> mtu 1500 qdisc mq state DOWN mode DEFAULT group default qlen 1000
> 3: macvlan@lower: <NO-CARRIER,BROADCAST,MULTICAST,UP,M-DOWN> mtu 1500 qdisc noqueue state LOWERLAYERDOWN mode DEFAULT group default qlen 1000
>
> Signed-off-by: Suresh Krishnan <skrishnan@arista.com>
> Signed-off-by: Travis Brown <travisb@arista.com>
Seems reasonable, applied, thanks.
^ permalink raw reply
* Re: [net-next 0/2] tipc: make link protocol more resilient
From: David Miller @ 2018-07-12 6:06 UTC (permalink / raw)
To: jon.maloy
Cc: netdev, gordan.mihaljevic, tung.q.nguyen, hoang.h.le, canh.d.luu,
ying.xue, tipc-discussion
In-Reply-To: <1531177656-31721-1-git-send-email-jon.maloy@ericsson.com>
From: Jon Maloy <jon.maloy@ericsson.com>
Date: Tue, 10 Jul 2018 01:07:34 +0200
> These two commits make the link ptotocol more resilient to
> infrastructures with frequent packet duplication and long delays.
Series applied, thanks Jon.
^ permalink raw reply
* Re: [net-next 0/7][pull request] L2 Fwd Offload & 10GbE Intel Driver Updates 2018-07-09
From: David Miller @ 2018-07-12 6:05 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, nhorman, sassmann, jogreene
In-Reply-To: <20180709222042.24724-1-jeffrey.t.kirsher@intel.com>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Mon, 9 Jul 2018 15:20:35 -0700
> This patch series is meant to allow support for the L2 forward offload, aka
> MACVLAN offload without the need for using ndo_select_queue.
>
> The existing solution currently requires that we use ndo_select_queue in
> the transmit path if we want to associate specific Tx queues with a given
> MACVLAN interface. In order to get away from this we need to repurpose the
> tc_to_txq array and XPS pointer for the MACVLAN interface and use those as
> a means of accessing the queues on the lower device. As a result we cannot
> offload a device that is configured as multiqueue, however it doesn't
> really make sense to configure a macvlan interfaced as being multiqueue
> anyway since it doesn't really have a qdisc of its own in the first place.
>
> The big changes in this set are:
> Allow lower device to update tc_to_txq and XPS map of offloaded MACVLAN
> Disable XPS for single queue devices
> Replace accel_priv with sb_dev in ndo_select_queue
> Add sb_dev parameter to fallback function for ndo_select_queue
> Consolidated ndo_select_queue functions that appeared to be duplicates
>
> The following are changes since commit c47078d6a33fd78d882200cdaacbcfcd63318234:
> tcp: remove redundant SOCK_DONE checks
> and are available in the git repository at:
> git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/next-queue 10GbE
Pulled, thanks Jeff.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox