* Re: [PATCH] tools: bpftool: add feature check for zlib
From: Daniel Borkmann @ 2019-08-13 14:24 UTC (permalink / raw)
To: Peter Wu, Jakub Kicinski
Cc: Stanislav Fomichev, Alexei Starovoitov, netdev, Quentin Monnet
In-Reply-To: <20190813003833.22042-2-peter@lekensteyn.nl>
On 8/13/19 2:38 AM, Peter Wu wrote:
> bpftool requires libelf, and zlib for decompressing /proc/config.gz.
> zlib is a transitive dependency via libelf, and became mandatory since
> elfutils 0.165 (Jan 2016). The feature check of libelf is already done
> in the elfdep target of tools/lib/bpf/Makefile, pulled in by bpftool via
> a dependency on libbpf.a. Add a similar feature check for zlib.
>
> Suggested-by: Jakub Kicinski <jakub.kicinski@netronome.com>
> Signed-off-by: Peter Wu <peter@lekensteyn.nl>
Applied, thanks!
^ permalink raw reply
* Re: kernel BUG at net/rxrpc/local_object.c:LINE!
From: David Howells @ 2019-08-13 14:23 UTC (permalink / raw)
To: Dmitry Vyukov
Cc: dhowells, syzbot, Eric Biggers, David Miller, linux-afs, LKML,
netdev, syzkaller-bugs
In-Reply-To: <CACT4Y+bjLBwVK_6fz2H8fXm0baAVX+vRJ4UbVWG_7yNUO-SOUg@mail.gmail.com>
Dmitry Vyukov <dvyukov@google.com> wrote:
> > > Please send a patch for testing that enables this tracing
> > > unconditionally. This should have the same effect. There is no way to
> > > hook into a middle of the automated process and arbitrary tune things.
> >
> > I don't know how to do that off hand. Do you have an example?
>
> Few messages above I asked it to test:
> https://groups.google.com/d/msg/syzkaller-bugs/gEnZkmEWf1s/r2_X_KVQAQAJ
>
> Basically, git repo + branch + patch. Here are the docs:
> https://github.com/google/syzkaller/blob/master/docs/syzbot.md#testing-patches
I meant that I don't know how to turn a tracepoint on from inside the kernel.
David
^ permalink raw reply
* Re: KMSAN: uninit-value in nh_valid_get_del_req
From: Eric Dumazet @ 2019-08-13 14:20 UTC (permalink / raw)
To: syzbot, davem, dsahern, glider, kuznet, linux-kernel, netdev,
syzkaller-bugs, yoshfuji
In-Reply-To: <000000000000d7edc0058fffe31a@google.com>
On 8/13/19 3:48 PM, syzbot wrote:
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit: 61ccdad1 Revert "drm/bochs: Use shadow buffer for bochs fr..
> git tree: https://github.com/google/kmsan.git master
> console output: https://syzkaller.appspot.com/x/log.txt?x=14c120e2600000
> kernel config: https://syzkaller.appspot.com/x/.config?x=27abc558ecb16a3b
> dashboard link: https://syzkaller.appspot.com/bug?extid=86ec9d8c02c07571873c
> compiler: clang version 9.0.0 (/home/glider/llvm/clang 80fee25776c2fb61e74c1ecb1a523375c2500b69)
> syz repro: https://syzkaller.appspot.com/x/repro.syz?x=15ed6c4a600000
> C reproducer: https://syzkaller.appspot.com/x/repro.c?x=11de024a600000
>
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+86ec9d8c02c07571873c@syzkaller.appspotmail.com
>
> ==================================================================
> BUG: KMSAN: uninit-value in nh_valid_get_del_req+0x6f1/0x8c0 net/ipv4/nexthop.c:1510
> CPU: 0 PID: 11812 Comm: syz-executor444 Not tainted 5.3.0-rc3+ #17
> 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+0x191/0x1f0 lib/dump_stack.c:113
> kmsan_report+0x162/0x2d0 mm/kmsan/kmsan_report.c:109
> __msan_warning+0x75/0xe0 mm/kmsan/kmsan_instr.c:294
> nh_valid_get_del_req+0x6f1/0x8c0 net/ipv4/nexthop.c:1510
> rtm_del_nexthop+0x1b1/0x610 net/ipv4/nexthop.c:1543
> rtnetlink_rcv_msg+0x115a/0x1580 net/core/rtnetlink.c:5223
> netlink_rcv_skb+0x431/0x620 net/netlink/af_netlink.c:2477
> rtnetlink_rcv+0x50/0x60 net/core/rtnetlink.c:5241
> netlink_unicast_kernel net/netlink/af_netlink.c:1302 [inline]
> netlink_unicast+0xf6c/0x1050 net/netlink/af_netlink.c:1328
> netlink_sendmsg+0x110f/0x1330 net/netlink/af_netlink.c:1917
> sock_sendmsg_nosec net/socket.c:637 [inline]
> sock_sendmsg net/socket.c:657 [inline]
> ___sys_sendmsg+0x14ff/0x1590 net/socket.c:2311
> __sys_sendmmsg+0x53a/0xae0 net/socket.c:2413
> __do_sys_sendmmsg net/socket.c:2442 [inline]
> __se_sys_sendmmsg+0xbd/0xe0 net/socket.c:2439
> __x64_sys_sendmmsg+0x56/0x70 net/socket.c:2439
> do_syscall_64+0xbc/0xf0 arch/x86/entry/common.c:297
> entry_SYSCALL_64_after_hwframe+0x63/0xe7
> RIP: 0033:0x440259
> Code: 18 89 d0 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 fb 13 fc ff c3 66 2e 0f 1f 84 00 00 00 00
> RSP: 002b:00007fff15f10d08 EFLAGS: 00000246 ORIG_RAX: 0000000000000133
> RAX: ffffffffffffffda RBX: 00000000004002c8 RCX: 0000000000440259
> RDX: 0492492492492805 RSI: 0000000020000140 RDI: 0000000000000003
> RBP: 00000000006ca018 R08: 0000000000000000 R09: 00000000004002c8
> R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000401ae0
> R13: 0000000000401b70 R14: 0000000000000000 R15: 0000000000000000
>
> Uninit was created at:
> kmsan_save_stack_with_flags mm/kmsan/kmsan.c:187 [inline]
> kmsan_internal_poison_shadow+0x53/0xa0 mm/kmsan/kmsan.c:146
> kmsan_slab_alloc+0xaa/0x120 mm/kmsan/kmsan_hooks.c:175
> slab_alloc_node mm/slub.c:2790 [inline]
> __kmalloc_node_track_caller+0xb55/0x1320 mm/slub.c:4388
> __kmalloc_reserve net/core/skbuff.c:141 [inline]
> __alloc_skb+0x306/0xa10 net/core/skbuff.c:209
> alloc_skb include/linux/skbuff.h:1056 [inline]
> netlink_alloc_large_skb net/netlink/af_netlink.c:1174 [inline]
> netlink_sendmsg+0x783/0x1330 net/netlink/af_netlink.c:1892
> sock_sendmsg_nosec net/socket.c:637 [inline]
> sock_sendmsg net/socket.c:657 [inline]
> ___sys_sendmsg+0x14ff/0x1590 net/socket.c:2311
> __sys_sendmmsg+0x53a/0xae0 net/socket.c:2413
> __do_sys_sendmmsg net/socket.c:2442 [inline]
> __se_sys_sendmmsg+0xbd/0xe0 net/socket.c:2439
> __x64_sys_sendmmsg+0x56/0x70 net/socket.c:2439
> do_syscall_64+0xbc/0xf0 arch/x86/entry/common.c:297
> entry_SYSCALL_64_after_hwframe+0x63/0xe7
> ==================================================================
>
>
> ---
> This bug is generated by a bot. It may contain errors.
> See https://goo.gl/tpsmEJ for more information about syzbot.
> syzbot engineers can be reached at syzkaller@googlegroups.com.
>
> syzbot will keep track of this bug report. See:
> https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
> syzbot can test patches for this bug, for details see:
> https://goo.gl/tpsmEJ#testing-patches
Fix is under review
https://patchwork.ozlabs.org/patch/1145879/
^ permalink raw reply
* Re: [RESEND][PATCH v3 bpf-next] btf: expose BTF info through sysfs
From: Daniel Borkmann @ 2019-08-13 14:20 UTC (permalink / raw)
To: Andrii Nakryiko, bpf, netdev, ast; +Cc: andrii.nakryiko, kernel-team
In-Reply-To: <20190812183947.130889-1-andriin@fb.com>
On 8/12/19 8:39 PM, Andrii Nakryiko wrote:
> Make .BTF section allocated and expose its contents through sysfs.
>
> /sys/kernel/btf directory is created to contain all the BTFs present
> inside kernel. Currently there is only kernel's main BTF, represented as
> /sys/kernel/btf/kernel file. Once kernel modules' BTFs are supported,
> each module will expose its BTF as /sys/kernel/btf/<module-name> file.
>
> Current approach relies on a few pieces coming together:
> 1. pahole is used to take almost final vmlinux image (modulo .BTF and
> kallsyms) and generate .BTF section by converting DWARF info into
> BTF. This section is not allocated and not mapped to any segment,
> though, so is not yet accessible from inside kernel at runtime.
> 2. objcopy dumps .BTF contents into binary file and subsequently
> convert binary file into linkable object file with automatically
> generated symbols _binary__btf_kernel_bin_start and
> _binary__btf_kernel_bin_end, pointing to start and end, respectively,
> of BTF raw data.
> 3. final vmlinux image is generated by linking this object file (and
> kallsyms, if necessary). sysfs_btf.c then creates
> /sys/kernel/btf/kernel file and exposes embedded BTF contents through
> it. This allows, e.g., libbpf and bpftool access BTF info at
> well-known location, without resorting to searching for vmlinux image
> on disk (location of which is not standardized and vmlinux image
> might not be even available in some scenarios, e.g., inside qemu
> during testing).
Small question: given modules will be covered later, would it not be more
obvious to name it /sys/kernel/btf/vmlinux instead?
> Alternative approach using .incbin assembler directive to embed BTF
> contents directly was attempted but didn't work, because sysfs_proc.o is
> not re-compiled during link-vmlinux.sh stage. This is required, though,
> to update embedded BTF data (initially empty data is embedded, then
> pahole generates BTF info and we need to regenerate sysfs_btf.o with
> updated contents, but it's too late at that point).
>
> If BTF couldn't be generated due to missing or too old pahole,
> sysfs_btf.c handles that gracefully by detecting that
> _binary__btf_kernel_bin_start (weak symbol) is 0 and not creating
> /sys/kernel/btf at all.
>
> v2->v3:
> - added Documentation/ABI/testing/sysfs-kernel-btf (Greg K-H);
> - created proper kobject (btf_kobj) for btf directory (Greg K-H);
> - undo v2 change of reusing vmlinux, as it causes extra kallsyms pass
> due to initially missing __binary__btf_kernel_bin_{start/end} symbols;
>
> v1->v2:
> - allow kallsyms stage to re-use vmlinux generated by gen_btf();
>
> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Signed-off-by: Andrii Nakryiko <andriin@fb.com>
In any case, this is great progress, applied thanks!
^ permalink raw reply
* Re: libbpf distro packaging
From: Daniel Borkmann @ 2019-08-13 14:11 UTC (permalink / raw)
To: Jiri Olsa, Julia Kartseva
Cc: labbott@redhat.com, acme@kernel.org,
debian-kernel@lists.debian.org, netdev@vger.kernel.org,
Andrii Nakryiko, Andrey Ignatov, Alexei Starovoitov,
Yonghong Song, jolsa@kernel.org
In-Reply-To: <20190813122420.GB9349@krava>
On 8/13/19 2:24 PM, Jiri Olsa wrote:
> On Mon, Aug 12, 2019 at 07:04:12PM +0000, Julia Kartseva wrote:
>> I would like to bring up libbpf publishing discussion started at [1].
>> The present state of things is that libbpf is built from kernel tree, e.g. [2]
>> For Debian and [3] for Fedora whereas the better way would be having a
>> package built from github mirror. The advantages of the latter:
>> - Consistent, ABI matching versioning across distros
>> - The mirror has integration tests
>> - No need in kernel tree to build a package
>> - Changes can be merged directly to github w/o waiting them to be merged
>> through bpf-next -> net-next -> main
>> There is a PR introducing a libbpf.spec which can be used as a starting point: [4]
>> Any comments regarding the spec itself can be posted there.
>> In the future it may be used as a source of truth.
>> Please consider switching libbpf packaging to the github mirror instead
>> of the kernel tree.
>> Thanks
>>
>> [1] https://lists.iovisor.org/g/iovisor-dev/message/1521
>> [2] https://packages.debian.org/sid/libbpf4.19
>> [3] http://rpmfind.net/linux/RPM/fedora/devel/rawhide/x86_64/l/libbpf-5.3.0-0.rc2.git0.1.fc31.x86_64.html
>> [4] https://github.com/libbpf/libbpf/pull/64
>
> hi,
> Fedora has libbpf as kernel-tools subpackage, so I think
> we'd need to create new package and deprecate the current
>
> but I like the ABI stability by using github .. how's actually
> the sync (in both directions) with kernel sources going on?
The upstream kernel's tools/lib/bpf/ is always source of truth. Meaning, changes need
to make it upstream first and they are later synced into the GH stand-alone repo.
Thanks,
Daniel
^ permalink raw reply
* Re: tun: mark small packets as owned by the tap sock
From: Dave Jones @ 2019-08-13 14:00 UTC (permalink / raw)
To: Jason Wang; +Cc: Alexis Bauvin, netdev
In-Reply-To: <6b16739e-ab96-9c93-9636-5b80b81c2b20@redhat.com>
On Tue, Aug 13, 2019 at 04:33:59PM +0800, Jason Wang wrote:
>
> On 2019/8/13 上午6:19, Dave Jones wrote:
> > On Wed, Aug 07, 2019 at 12:30:07AM +0000, Linux Kernel wrote:
> > > Commit: 4b663366246be1d1d4b1b8b01245b2e88ad9e706
> > > Parent: 16b2084a8afa1432d14ba72b7c97d7908e178178
> > > Web: https://git.kernel.org/torvalds/c/4b663366246be1d1d4b1b8b01245b2e88ad9e706
> > > Author: Alexis Bauvin <abauvin@scaleway.com>
> > > AuthorDate: Tue Jul 23 16:23:01 2019 +0200
> > >
> > > tun: mark small packets as owned by the tap sock
> > >
> > > - v1 -> v2: Move skb_set_owner_w to __tun_build_skb to reduce patch size
> >
> > This commit breaks ipv6 routing when I deployed on it a linode.
> > It seems to work briefly after boot, and then silently all packets get
> > dropped. (Presumably, it's dropping RA or ND packets)
> >
> > With this reverted, everything works as it did in rc3.
> >
> Two questions:
>
> - Are you using XDP for TUN?
not knowingly.
$ grep XDP .config
# CONFIG_XDP_SOCKETS is not set
What's configured on the hypervisor side I have no idea.
> - Does it work before 66ccbc9c87c2?
that's been around since 4.14-rc1, and at one point it ran whatever was
in debian9 (4.9). I don't recall it ever not working, so I'd say yes.
I can build a 4.13 if it'll prove something, but it'll take me a while.
(This is my primary MX, so it's dropping email while it's on the broken
kernel, so I need to plan some time to be around to babysit it)
> If yes, could you show us the result of net_dropmonitor?
where do I get that? It doesn't seem packaged for debian.
Dave
^ permalink raw reply
* [PATCH] sctp: fix memleak in sctp_send_reset_streams
From: zhengbin @ 2019-08-13 14:05 UTC (permalink / raw)
To: vyasevich, nhorman, marcelo.leitner, davem, linux-sctp, netdev
Cc: yi.zhang, zhengbin13
If the stream outq is not empty, need to kfree nstr_list.
Fixes: d570a59c5b5f ("sctp: only allow the out stream reset when the stream outq is empty")
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: zhengbin <zhengbin13@huawei.com>
---
net/sctp/stream.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/sctp/stream.c b/net/sctp/stream.c
index 2594660..e83cdaa 100644
--- a/net/sctp/stream.c
+++ b/net/sctp/stream.c
@@ -316,6 +316,7 @@ int sctp_send_reset_streams(struct sctp_association *asoc,
nstr_list[i] = htons(str_list[i]);
if (out && !sctp_stream_outq_is_empty(stream, str_nums, nstr_list)) {
+ kfree(nstr_list);
retval = -EAGAIN;
goto out;
}
--
2.7.4
^ permalink raw reply related
* Re: [EXT] INFO: trying to register non-static key in del_timer_sync (2)
From: Kalle Valo @ 2019-08-13 13:58 UTC (permalink / raw)
To: Andrey Konovalov
Cc: Ganapathi Bhat, Dmitry Vyukov, syzbot, amitkarwar@gmail.com,
davem@davemloft.net, huxinming820@gmail.com,
linux-kernel@vger.kernel.org, linux-usb@vger.kernel.org,
linux-wireless@vger.kernel.org, netdev@vger.kernel.org,
nishants@marvell.com, syzkaller-bugs@googlegroups.com
In-Reply-To: <CAAeHK+z8MBNikw_x50Crf8ZhOhcF=uvPHakvBx44K77xHRUNfg@mail.gmail.com>
Andrey Konovalov <andreyknvl@google.com> writes:
> On Wed, Jun 12, 2019 at 6:03 PM Ganapathi Bhat <gbhat@marvell.com> wrote:
>>
>> Hi Dmitry,
>>
>> We have a patch to fix this: https://patchwork.kernel.org/patch/10990275/
>
> Hi Ganapathi,
>
> Has this patch been accepted anywhere? This bug is still open on syzbot.
The patch is in "Changes Requested" state which means that the author is
supposed to send a new version based on the review comments.
--
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* [PATCH net] ipv6/addrconf: allow adding multicast addr if IFA_F_MCAUTOJOIN is set
From: Hangbin Liu @ 2019-08-13 13:52 UTC (permalink / raw)
To: netdev
Cc: Madhu Challa, David Ahern, David S . Miller, Jianlin Shi,
Hangbin Liu
The ip address autojoin is not working for IPv6 as ipv6_add_addr()
will return -EADDRNOTAVAIL when adding a multicast address.
Reported-by: Jianlin Shi <jishi@redhat.com>
Fixes: 93a714d6b53d ("multicast: Extend ip address command to enable multicast group join/leave on")
Signed-off-by: Hangbin Liu <liuhangbin@gmail.com>
---
net/ipv6/addrconf.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
index dc73888c7859..ced995f3fec4 100644
--- a/net/ipv6/addrconf.c
+++ b/net/ipv6/addrconf.c
@@ -1045,7 +1045,8 @@ ipv6_add_addr(struct inet6_dev *idev, struct ifa6_config *cfg,
int err = 0;
if (addr_type == IPV6_ADDR_ANY ||
- addr_type & IPV6_ADDR_MULTICAST ||
+ (addr_type & IPV6_ADDR_MULTICAST &&
+ !(cfg->ifa_flags & IFA_F_MCAUTOJOIN)) ||
(!(idev->dev->flags & IFF_LOOPBACK) &&
!netif_is_l3_master(idev->dev) &&
addr_type & IPV6_ADDR_LOOPBACK))
--
2.19.2
^ permalink raw reply related
* KMSAN: uninit-value in nh_valid_get_del_req
From: syzbot @ 2019-08-13 13:48 UTC (permalink / raw)
To: davem, dsahern, glider, kuznet, linux-kernel, netdev,
syzkaller-bugs, yoshfuji
Hello,
syzbot found the following crash on:
HEAD commit: 61ccdad1 Revert "drm/bochs: Use shadow buffer for bochs fr..
git tree: https://github.com/google/kmsan.git master
console output: https://syzkaller.appspot.com/x/log.txt?x=14c120e2600000
kernel config: https://syzkaller.appspot.com/x/.config?x=27abc558ecb16a3b
dashboard link: https://syzkaller.appspot.com/bug?extid=86ec9d8c02c07571873c
compiler: clang version 9.0.0 (/home/glider/llvm/clang
80fee25776c2fb61e74c1ecb1a523375c2500b69)
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=15ed6c4a600000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=11de024a600000
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+86ec9d8c02c07571873c@syzkaller.appspotmail.com
==================================================================
BUG: KMSAN: uninit-value in nh_valid_get_del_req+0x6f1/0x8c0
net/ipv4/nexthop.c:1510
CPU: 0 PID: 11812 Comm: syz-executor444 Not tainted 5.3.0-rc3+ #17
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+0x191/0x1f0 lib/dump_stack.c:113
kmsan_report+0x162/0x2d0 mm/kmsan/kmsan_report.c:109
__msan_warning+0x75/0xe0 mm/kmsan/kmsan_instr.c:294
nh_valid_get_del_req+0x6f1/0x8c0 net/ipv4/nexthop.c:1510
rtm_del_nexthop+0x1b1/0x610 net/ipv4/nexthop.c:1543
rtnetlink_rcv_msg+0x115a/0x1580 net/core/rtnetlink.c:5223
netlink_rcv_skb+0x431/0x620 net/netlink/af_netlink.c:2477
rtnetlink_rcv+0x50/0x60 net/core/rtnetlink.c:5241
netlink_unicast_kernel net/netlink/af_netlink.c:1302 [inline]
netlink_unicast+0xf6c/0x1050 net/netlink/af_netlink.c:1328
netlink_sendmsg+0x110f/0x1330 net/netlink/af_netlink.c:1917
sock_sendmsg_nosec net/socket.c:637 [inline]
sock_sendmsg net/socket.c:657 [inline]
___sys_sendmsg+0x14ff/0x1590 net/socket.c:2311
__sys_sendmmsg+0x53a/0xae0 net/socket.c:2413
__do_sys_sendmmsg net/socket.c:2442 [inline]
__se_sys_sendmmsg+0xbd/0xe0 net/socket.c:2439
__x64_sys_sendmmsg+0x56/0x70 net/socket.c:2439
do_syscall_64+0xbc/0xf0 arch/x86/entry/common.c:297
entry_SYSCALL_64_after_hwframe+0x63/0xe7
RIP: 0033:0x440259
Code: 18 89 d0 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 48 89 f8 48 89 f7
48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff
ff 0f 83 fb 13 fc ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:00007fff15f10d08 EFLAGS: 00000246 ORIG_RAX: 0000000000000133
RAX: ffffffffffffffda RBX: 00000000004002c8 RCX: 0000000000440259
RDX: 0492492492492805 RSI: 0000000020000140 RDI: 0000000000000003
RBP: 00000000006ca018 R08: 0000000000000000 R09: 00000000004002c8
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000401ae0
R13: 0000000000401b70 R14: 0000000000000000 R15: 0000000000000000
Uninit was created at:
kmsan_save_stack_with_flags mm/kmsan/kmsan.c:187 [inline]
kmsan_internal_poison_shadow+0x53/0xa0 mm/kmsan/kmsan.c:146
kmsan_slab_alloc+0xaa/0x120 mm/kmsan/kmsan_hooks.c:175
slab_alloc_node mm/slub.c:2790 [inline]
__kmalloc_node_track_caller+0xb55/0x1320 mm/slub.c:4388
__kmalloc_reserve net/core/skbuff.c:141 [inline]
__alloc_skb+0x306/0xa10 net/core/skbuff.c:209
alloc_skb include/linux/skbuff.h:1056 [inline]
netlink_alloc_large_skb net/netlink/af_netlink.c:1174 [inline]
netlink_sendmsg+0x783/0x1330 net/netlink/af_netlink.c:1892
sock_sendmsg_nosec net/socket.c:637 [inline]
sock_sendmsg net/socket.c:657 [inline]
___sys_sendmsg+0x14ff/0x1590 net/socket.c:2311
__sys_sendmmsg+0x53a/0xae0 net/socket.c:2413
__do_sys_sendmmsg net/socket.c:2442 [inline]
__se_sys_sendmmsg+0xbd/0xe0 net/socket.c:2439
__x64_sys_sendmmsg+0x56/0x70 net/socket.c:2439
do_syscall_64+0xbc/0xf0 arch/x86/entry/common.c:297
entry_SYSCALL_64_after_hwframe+0x63/0xe7
==================================================================
---
This bug is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.
syzbot will keep track of this bug report. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
syzbot can test patches for this bug, for details see:
https://goo.gl/tpsmEJ#testing-patches
^ permalink raw reply
* Re: [PATCH 3/3] ocelot_ace: fix action of trap
From: Andrew Lunn @ 2019-08-13 13:42 UTC (permalink / raw)
To: Y.b. Lu
Cc: Allan W. Nielsen, netdev@vger.kernel.org, David S . Miller,
Alexandre Belloni, Microchip Linux Driver Support
In-Reply-To: <VI1PR0401MB223773EB5884D65890BD68C0F8D20@VI1PR0401MB2237.eurprd04.prod.outlook.com>
On Tue, Aug 13, 2019 at 02:12:47AM +0000, Y.b. Lu wrote:
> Hi Allan,
>
> > -----Original Message-----
> > From: Allan W. Nielsen <allan.nielsen@microchip.com>
> > Sent: Monday, August 12, 2019 8:32 PM
> > To: Y.b. Lu <yangbo.lu@nxp.com>
> > Cc: netdev@vger.kernel.org; David S . Miller <davem@davemloft.net>;
> > Alexandre Belloni <alexandre.belloni@bootlin.com>; Microchip Linux Driver
> > Support <UNGLinuxDriver@microchip.com>
> > Subject: Re: [PATCH 3/3] ocelot_ace: fix action of trap
> >
> > The 08/12/2019 18:48, Yangbo Lu wrote:
> > > The trap action should be copying the frame to CPU and dropping it for
> > > forwarding, but current setting was just copying frame to CPU.
> >
> > Are there any actions which do a "copy-to-cpu" and still forward the frame in
> > HW?
>
> [Y.b. Lu] We're using Felix switch whose code hadn't been accepted by upstream.
> https://patchwork.ozlabs.org/project/netdev/list/?series=115399&state=*
>
> I'd like to trap all IEEE 1588 PTP Ethernet frames to CPU through etype 0x88f7.
Is this the correct way to handle PTP for this switch? For other
switches we don't need such traps. The switch itself identifies PTP
frames and forwards them to the CPU so it can process them.
I'm just wondering if your general approach is wrong?
Andrew
^ permalink raw reply
* Re: [EXT] INFO: trying to register non-static key in del_timer_sync (2)
From: Andrey Konovalov @ 2019-08-13 13:36 UTC (permalink / raw)
To: Ganapathi Bhat
Cc: Dmitry Vyukov, syzbot, amitkarwar@gmail.com, davem@davemloft.net,
huxinming820@gmail.com, kvalo@codeaurora.org,
linux-kernel@vger.kernel.org, linux-usb@vger.kernel.org,
linux-wireless@vger.kernel.org, netdev@vger.kernel.org,
nishants@marvell.com, syzkaller-bugs@googlegroups.com
In-Reply-To: <MN2PR18MB263710E8F1F8FFA06B2EDB3CA0EC0@MN2PR18MB2637.namprd18.prod.outlook.com>
On Wed, Jun 12, 2019 at 6:03 PM Ganapathi Bhat <gbhat@marvell.com> wrote:
>
> Hi Dmitry,
>
> We have a patch to fix this: https://patchwork.kernel.org/patch/10990275/
Hi Ganapathi,
Has this patch been accepted anywhere? This bug is still open on syzbot.
Thanks!
^ permalink raw reply
* Re: KASAN: slab-out-of-bounds Read in p54u_load_firmware_cb
From: Andrey Konovalov @ 2019-08-13 13:27 UTC (permalink / raw)
Cc: syzbot, Christian Lamparter, David S. Miller, Kalle Valo,
Kernel development list, USB list, linux-wireless, netdev,
syzkaller-bugs, Alan Stern
In-Reply-To: <Pine.LNX.4.44L0.1906201544001.1346-100000@iolanthe.rowland.org>
On Thu, Jun 20, 2019 at 9:46 PM Alan Stern <stern@rowland.harvard.edu> wrote:
>
> On Wed, 19 Jun 2019, syzbot wrote:
>
> > syzbot has found a reproducer for the following crash on:
> >
> > HEAD commit: 9939f56e usb-fuzzer: main usb gadget fuzzer driver
> > git tree: https://github.com/google/kasan.git usb-fuzzer
> > console output: https://syzkaller.appspot.com/x/log.txt?x=135e29faa00000
> > kernel config: https://syzkaller.appspot.com/x/.config?x=df134eda130bb43a
> > dashboard link: https://syzkaller.appspot.com/bug?extid=6d237e74cdc13f036473
> > compiler: gcc (GCC) 9.0.0 20181231 (experimental)
> > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=175d946ea00000
> >
> > IMPORTANT: if you fix the bug, please add the following tag to the commit:
> > Reported-by: syzbot+6d237e74cdc13f036473@syzkaller.appspotmail.com
> >
> > usb 3-1: Direct firmware load for isl3887usb failed with error -2
> > usb 3-1: Firmware not found.
> > ==================================================================
> > BUG: KASAN: slab-out-of-bounds in p54u_load_firmware_cb.cold+0x97/0x13d
> > drivers/net/wireless/intersil/p54/p54usb.c:936
> > Read of size 8 at addr ffff8881c9cf7588 by task kworker/1:5/2759
> >
> > CPU: 1 PID: 2759 Comm: kworker/1:5 Not tainted 5.2.0-rc5+ #11
> > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> > Google 01/01/2011
> > Workqueue: events request_firmware_work_func
> > Call Trace:
> > __dump_stack lib/dump_stack.c:77 [inline]
> > dump_stack+0xca/0x13e lib/dump_stack.c:113
> > print_address_description+0x67/0x231 mm/kasan/report.c:188
> > __kasan_report.cold+0x1a/0x32 mm/kasan/report.c:317
> > kasan_report+0xe/0x20 mm/kasan/common.c:614
> > p54u_load_firmware_cb.cold+0x97/0x13d
> > drivers/net/wireless/intersil/p54/p54usb.c:936
> > request_firmware_work_func+0x126/0x242
> > drivers/base/firmware_loader/main.c:785
> > process_one_work+0x905/0x1570 kernel/workqueue.c:2269
> > worker_thread+0x96/0xe20 kernel/workqueue.c:2415
> > kthread+0x30b/0x410 kernel/kthread.c:255
> > ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:352
> >
> > Allocated by task 1612:
> > save_stack+0x1b/0x80 mm/kasan/common.c:71
> > set_track mm/kasan/common.c:79 [inline]
> > __kasan_kmalloc mm/kasan/common.c:489 [inline]
> > __kasan_kmalloc.constprop.0+0xbf/0xd0 mm/kasan/common.c:462
> > kmalloc include/linux/slab.h:547 [inline]
> > syslog_print kernel/printk/printk.c:1346 [inline]
> > do_syslog kernel/printk/printk.c:1519 [inline]
> > do_syslog+0x4f4/0x12e0 kernel/printk/printk.c:1493
> > kmsg_read+0x8a/0xb0 fs/proc/kmsg.c:40
> > proc_reg_read+0x1c1/0x280 fs/proc/inode.c:221
> > __vfs_read+0x76/0x100 fs/read_write.c:425
> > vfs_read+0x18e/0x3d0 fs/read_write.c:461
> > ksys_read+0x127/0x250 fs/read_write.c:587
> > do_syscall_64+0xb7/0x560 arch/x86/entry/common.c:301
> > entry_SYSCALL_64_after_hwframe+0x49/0xbe
> >
> > Freed by task 1612:
> > save_stack+0x1b/0x80 mm/kasan/common.c:71
> > set_track mm/kasan/common.c:79 [inline]
> > __kasan_slab_free+0x130/0x180 mm/kasan/common.c:451
> > slab_free_hook mm/slub.c:1421 [inline]
> > slab_free_freelist_hook mm/slub.c:1448 [inline]
> > slab_free mm/slub.c:2994 [inline]
> > kfree+0xd7/0x280 mm/slub.c:3949
> > syslog_print kernel/printk/printk.c:1405 [inline]
> > do_syslog kernel/printk/printk.c:1519 [inline]
> > do_syslog+0xff3/0x12e0 kernel/printk/printk.c:1493
> > kmsg_read+0x8a/0xb0 fs/proc/kmsg.c:40
> > proc_reg_read+0x1c1/0x280 fs/proc/inode.c:221
> > __vfs_read+0x76/0x100 fs/read_write.c:425
> > vfs_read+0x18e/0x3d0 fs/read_write.c:461
> > ksys_read+0x127/0x250 fs/read_write.c:587
> > do_syscall_64+0xb7/0x560 arch/x86/entry/common.c:301
> > entry_SYSCALL_64_after_hwframe+0x49/0xbe
> >
> > The buggy address belongs to the object at ffff8881c9cf7180
> > which belongs to the cache kmalloc-1k of size 1024
> > The buggy address is located 8 bytes to the right of
> > 1024-byte region [ffff8881c9cf7180, ffff8881c9cf7580)
> > The buggy address belongs to the page:
> > page:ffffea0007273d00 refcount:1 mapcount:0 mapping:ffff8881dac02a00
> > index:0x0 compound_mapcount: 0
> > flags: 0x200000000010200(slab|head)
> > raw: 0200000000010200 dead000000000100 dead000000000200 ffff8881dac02a00
> > raw: 0000000000000000 00000000000e000e 00000001ffffffff 0000000000000000
> > page dumped because: kasan: bad access detected
> >
> > Memory state around the buggy address:
> > ffff8881c9cf7480: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> > ffff8881c9cf7500: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> > > ffff8881c9cf7580: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
> > ^
> > ffff8881c9cf7600: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> > ffff8881c9cf7680: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> > ==================================================================
>
> Isn't this the same as syzkaller bug 200d4bb11b23d929335f ? Doesn't
> the same patch fix it?
#syz dup: KASAN: use-after-free Read in p54u_load_firmware_cb
^ permalink raw reply
* Re: [PATCH 2/2] net: gmii2rgmii: Switch priv field in mdio device structure
From: Andrew Lunn @ 2019-08-13 13:23 UTC (permalink / raw)
To: Harini Katakam
Cc: Harini Katakam, Florian Fainelli, Heiner Kallweit, David Miller,
Michal Simek, netdev, linux-arm-kernel, linux-kernel,
radhey.shyam.pandey
In-Reply-To: <CAFcVEC+DyVhLzbMdSDsadivbnZJxSEg-0kUF5_Q+mtSbBnmhSA@mail.gmail.com>
On Tue, Aug 13, 2019 at 04:46:40PM +0530, Harini Katakam wrote:
> Hi Andrew,
>
> On Thu, Aug 1, 2019 at 9:36 AM Andrew Lunn <andrew@lunn.ch> wrote:
> >
> > On Wed, Jul 31, 2019 at 03:06:19PM +0530, Harini Katakam wrote:
> > > Use the priv field in mdio device structure instead of the one in
> > > phy device structure. The phy device priv field may be used by the
> > > external phy driver and should not be overwritten.
> >
> > Hi Harini
> >
> > I _think_ you could use dev_set_drvdata(&mdiodev->dev) in xgmiitorgmii_probe() and
> > dev_get_drvdata(&phydev->mdiomdio.dev) in _read_status()
>
> Thanks for the review. This works if I do:
> dev_set_drvdata(&priv->phy_dev->mdio.dev->dev) in probe
> and then
> dev_get_drvdata(&phydev->mdio.dev) in _read_status()
>
> i.e mdiodev in gmii2rgmii probe and priv->phy_dev->mdio are not the same.
>
> If this is acceptable, I can send a v2.
Hi Harini
I think this is better, making use of the central driver
infrastructure, rather than inventing something new.
The kernel does have a few helper, spi_get_drvdata, pci_get_drvdata,
hci_get_drvdata. So maybe had add phydev_get_drvdata(struct phy_device
*phydev)?
Thanks
Andrew
^ permalink raw reply
* Re: [PATCH net-next v2 6/9] net: macsec: hardware offloading infrastructure
From: Andrew Lunn @ 2019-08-13 13:17 UTC (permalink / raw)
To: Antoine Tenart
Cc: Igor Russkikh, davem@davemloft.net, sd@queasysnail.net,
f.fainelli@gmail.com, hkallweit1@gmail.com,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
thomas.petazzoni@bootlin.com, alexandre.belloni@bootlin.com,
allan.nielsen@microchip.com, camelia.groza@nxp.com,
Simon Edelhaus, Pavel Belous
In-Reply-To: <20190813085817.GA3200@kwain>
On Tue, Aug 13, 2019 at 10:58:17AM +0200, Antoine Tenart wrote:
> I think this question is linked to the use of a MACsec virtual interface
> when using h/w offloading. The starting point for me was that I wanted
> to reuse the data structures and the API exposed to the userspace by the
> s/w implementation of MACsec. I then had two choices: keeping the exact
> same interface for the user (having a virtual MACsec interface), or
> registering the MACsec genl ops onto the real net devices (and making
> the s/w implementation a virtual net dev and a provider of the MACsec
> "offloading" ops).
>
> The advantages of the first option were that nearly all the logic of the
> s/w implementation could be kept and especially that it would be
> transparent for the user to use both implementations of MACsec.
Hi Antoine
We have always talked about offloading operations to the hardware,
accelerating what the linux stack can do by making use of hardware
accelerators. The basic user API should not change because of
acceleration. Those are the general guidelines.
It would however be interesting to get comments from those who did the
software implementation and what they think of this architecture. I've
no personal experience with MACSec, so it is hard for me to say if the
current architecture makes sense when using accelerators.
Andrew
^ permalink raw reply
* [RFC bpf-next 3/3] tools: bpftool: add "bpftool map count" to count entries in map
From: Quentin Monnet @ 2019-08-13 13:09 UTC (permalink / raw)
To: Alexei Starovoitov, Daniel Borkmann
Cc: bpf, netdev, oss-drivers, Quentin Monnet
In-Reply-To: <20190813130921.10704-1-quentin.monnet@netronome.com>
Add a "map count" subcommand for counting the number of entries in a
map.
Because of the variety of BPF map types, it is not entirely clear what
counts as an "entry" to dump. We could count all entries for which we
have keys; but then for all array derivatives, it would simply come down
to printing the maximum number of entries (already accessible through
"bpftool map show").
Several map types set errno to ENOENT when they consider there is no
value associated to a key, so we could maybe use that... But then there
are also some map types that simply reject lookup attempts with
EONOTSUPP (xskmap, sock_map, sock_hash): Not being able to lookup a
value in such maps does not mean they have no values.
Instead of trying to enforce a definition for a "map entry", the
selected approach in this patch consists in dumping several counter, and
letting the user decide how to interpret them. Values printed are:
- Max number of entries
- Number of key found
- Number of successful lookups
- Number of failed lookups, broken down into the most frequent values
for errno (ENOENT, EOPNOTSUPP, EINVAL, EPERM).
Not all possible values for errno are included (e.g. ENOMEM or EFAULT,
for example), they can be added in the future if necessary.
Below are some sample output with different types of maps.
Array map:
# bpftool map count id 11
max entries: 2
keys found: 2
successful lookups: 2
Empty prog_array map:
# bpftool map count id 13
max entries: 5
keys found: 5
successful lookups: 0
failed lookups: 5, of which:
- errno set to ENOENT: 5
Empty xskmap:
# bpftool map count id 14
max entries: 5
keys found: 5
successful lookups: 0
failed lookups: 5, of which:
- errno set to EOPNOTSUPP: 5
JSON for the array map:
# bpftool map count id 11
{
"max_entries": 2,
"n_keys": 2,
"n_lookup_success": 2,
"lookup_failures": {
"enoent": 0,
"eopnotsupp": 0,
"einval": 0,
"eperm": 0,
}
}
Queue map containing 3 items:
# bpftool map count id 12
failed to get next key, interrupting count: Invalid argument
max entries: 5
keys found: 0
successful lookups: 0
Note that counting entries for queue and stack maps is not supported
(beyond max_entries), as these types do not support cycling over the
keys.
This commit also adds relevant documentation and bash completion.
Signed-off-by: Quentin Monnet <quentin.monnet@netronome.com>
Reviewed-by: Jakub Kicinski <jakub.kicinski@netronome.com>
---
.../bpf/bpftool/Documentation/bpftool-map.rst | 15 +++
tools/bpf/bpftool/bash-completion/bpftool | 4 +-
tools/bpf/bpftool/map.c | 97 ++++++++++++++++++-
3 files changed, 113 insertions(+), 3 deletions(-)
diff --git a/tools/bpf/bpftool/Documentation/bpftool-map.rst b/tools/bpf/bpftool/Documentation/bpftool-map.rst
index 61d1d270eb5e..ccc19bdd2ca3 100644
--- a/tools/bpf/bpftool/Documentation/bpftool-map.rst
+++ b/tools/bpf/bpftool/Documentation/bpftool-map.rst
@@ -25,6 +25,7 @@ MAP COMMANDS
| **bpftool** **map create** *FILE* **type** *TYPE* **key** *KEY_SIZE* **value** *VALUE_SIZE* \
| **entries** *MAX_ENTRIES* **name** *NAME* [**flags** *FLAGS*] [**dev** *NAME*]
| **bpftool** **map dump** *MAP*
+| **bpftool** **map count** *MAP*
| **bpftool** **map update** *MAP* [**key** *DATA*] [**value** *VALUE*] [*UPDATE_FLAGS*]
| **bpftool** **map lookup** *MAP* [**key** *DATA*]
| **bpftool** **map getnext** *MAP* [**key** *DATA*]
@@ -67,6 +68,20 @@ DESCRIPTION
**bpftool map dump** *MAP*
Dump all entries in a given *MAP*.
+ **bpftool map count** *MAP*
+ Count the number of entries in a given *MAP*. Several values
+ are printed: the maximum number of entries, the number of
+ keys found, the number of successful lookups with those keys.
+ The report for failed lookups is broken down to give values
+ for the most frequent **errno** values.
+
+ Note that the counters may not be accurate if the map is
+ being modified (for example by a running BPF program). For
+ example, if an element gets removed while being dumped, and
+ then passed in as the "previous key" while cycling over map
+ keys, the dump will restart and bpftool will count the
+ entries multiple times.
+
**bpftool map update** *MAP* [**key** *DATA*] [**value** *VALUE*] [*UPDATE_FLAGS*]
Update map entry for a given *KEY*.
diff --git a/tools/bpf/bpftool/bash-completion/bpftool b/tools/bpf/bpftool/bash-completion/bpftool
index df16c5415444..764c88bfe9da 100644
--- a/tools/bpf/bpftool/bash-completion/bpftool
+++ b/tools/bpf/bpftool/bash-completion/bpftool
@@ -449,7 +449,7 @@ _bpftool()
map)
local MAP_TYPE='id pinned'
case $command in
- show|list|dump|peek|pop|dequeue)
+ show|list|dump|count|peek|pop|dequeue)
case $prev in
$command)
COMPREPLY=( $( compgen -W "$MAP_TYPE" -- "$cur" ) )
@@ -642,7 +642,7 @@ _bpftool()
[[ $prev == $object ]] && \
COMPREPLY=( $( compgen -W 'delete dump getnext help \
lookup pin event_pipe show list update create \
- peek push enqueue pop dequeue' -- \
+ peek push enqueue pop dequeue count' -- \
"$cur" ) )
;;
esac
diff --git a/tools/bpf/bpftool/map.c b/tools/bpf/bpftool/map.c
index cead639b3ab1..918d08d1676e 100644
--- a/tools/bpf/bpftool/map.c
+++ b/tools/bpf/bpftool/map.c
@@ -822,6 +822,98 @@ static int do_dump(int argc, char **argv)
return err;
}
+static int do_count(int argc, char **argv)
+{
+ unsigned int num_keys = 0, num_lookups = 0;
+ unsigned int err_cnts[1024] = {};
+ struct bpf_map_info info = {};
+ void *key, *value, *prev_key;
+ __u32 len = sizeof(info);
+ int err, fd;
+
+ if (!REQ_ARGS(2))
+ return -1;
+
+ fd = map_parse_fd_and_info(&argc, &argv, &info, &len);
+ if (fd < 0)
+ return -1;
+
+ key = malloc(info.key_size);
+ value = alloc_value(&info);
+ if (!key || !value) {
+ p_err("mem alloc failed");
+ err = -1;
+ goto exit_free;
+ }
+
+ prev_key = NULL;
+ while (true) {
+ int res;
+
+ err = bpf_map_get_next_key(fd, prev_key, key);
+ if (err) {
+ if (errno == ENOENT)
+ err = 0;
+ else
+ p_info("failed to get next key, interrupting count: %s",
+ strerror(errno));
+ break;
+ }
+
+ num_keys++;
+ res = bpf_map_lookup_elem(fd, key, value);
+ if (res) {
+ if (errno < (int)ARRAY_SIZE(err_cnts))
+ err_cnts[errno]++;
+ } else {
+ num_lookups++;
+ }
+ prev_key = key;
+ }
+
+ if (json_output) {
+ jsonw_start_object(json_wtr); /* root */
+ jsonw_uint_field(json_wtr, "max_entries", info.max_entries);
+ jsonw_uint_field(json_wtr, "n_keys", num_keys);
+ jsonw_uint_field(json_wtr, "n_lookup_success", num_lookups);
+ jsonw_name(json_wtr, "lookup_failures");
+ jsonw_start_object(json_wtr); /* lookup_failures */
+ jsonw_uint_field(json_wtr, "enoent", err_cnts[ENOENT]);
+ jsonw_uint_field(json_wtr, "eopnotsupp", err_cnts[EOPNOTSUPP]);
+ jsonw_uint_field(json_wtr, "einval", err_cnts[EINVAL]);
+ jsonw_uint_field(json_wtr, "eperm", err_cnts[EPERM]);
+ jsonw_end_object(json_wtr); /* lookup_failures */
+ jsonw_end_object(json_wtr); /* root */
+ } else {
+ printf("max entries:\t\t%u\n", info.max_entries);
+ printf("keys found:\t\t%u\n", num_keys);
+ printf("successful lookups:\t%u\n", num_lookups);
+ if (num_lookups != num_keys) {
+ printf("failed lookups:\t%u, of which:\n",
+ num_keys - num_lookups);
+ if (err_cnts[ENOENT])
+ printf(" - errno set to ENOENT:\t%u\n",
+ err_cnts[ENOENT]);
+ if (err_cnts[EOPNOTSUPP])
+ printf(" - errno set to EOPNOTSUPP:\t%u\n",
+ err_cnts[EOPNOTSUPP]);
+ if (err_cnts[EINVAL])
+ printf(" - errno set to EINVAL:\t%u\n",
+ err_cnts[EINVAL]);
+ if (err_cnts[EPERM])
+ printf(" - errno set to EPERM:\t\t%u\n",
+ err_cnts[EPERM]);
+ }
+ }
+
+exit_free:
+ free(key);
+ free(value);
+ close(fd);
+
+ return err;
+}
+
static int alloc_key_value(struct bpf_map_info *info, void **key, void **value)
{
*key = NULL;
@@ -1250,6 +1342,7 @@ static int do_help(int argc, char **argv)
" entries MAX_ENTRIES name NAME [flags FLAGS] \\\n"
" [dev NAME]\n"
" %s %s dump MAP\n"
+ " %s %s count MAP\n"
" %s %s update MAP [key DATA] [value VALUE] [UPDATE_FLAGS]\n"
" %s %s lookup MAP [key DATA]\n"
" %s %s getnext MAP [key DATA]\n"
@@ -1279,7 +1372,8 @@ static int do_help(int argc, char **argv)
bin_name, argv[-2], bin_name, argv[-2], bin_name, argv[-2],
bin_name, argv[-2], bin_name, argv[-2], bin_name, argv[-2],
bin_name, argv[-2], bin_name, argv[-2], bin_name, argv[-2],
- bin_name, argv[-2], bin_name, argv[-2], bin_name, argv[-2]);
+ bin_name, argv[-2], bin_name, argv[-2], bin_name, argv[-2],
+ bin_name, argv[-2]);
return 0;
}
@@ -1301,6 +1395,7 @@ static const struct cmd cmds[] = {
{ "enqueue", do_update },
{ "pop", do_pop_dequeue },
{ "dequeue", do_pop_dequeue },
+ { "count", do_count },
{ 0 }
};
--
2.17.1
^ permalink raw reply related
* [RFC bpf-next 1/3] tools: bpftool: clean up dump_map_elem() return value
From: Quentin Monnet @ 2019-08-13 13:09 UTC (permalink / raw)
To: Alexei Starovoitov, Daniel Borkmann
Cc: bpf, netdev, oss-drivers, Quentin Monnet
In-Reply-To: <20190813130921.10704-1-quentin.monnet@netronome.com>
The code for dumping a map entry (as part of a full map dump) was moved
to a specific function dump_map_elem() in commit 18a781daa93e
("tools/bpf: bpftool, split the function do_dump()"). The "num_elems"
variable was moved in that function, incremented on success, and
returned to be immediately added to the counter in do_dump().
Returning the count of elements dumped, which is either 0 or 1, is not
really consistent with the rest of the function, especially because
"dump_map_elem()" name is not explicit about returning a counter.
Furthermore, the counter is not incremented when the entry is dumped in
JSON. This has no visible effect, because the number of elements
successfully dumped is not printed for JSON output.
Still, let's remove "num_elems" from the function and make it return 0
or -1 in case of success or failure, respectively. This is more correct,
and more consistent with the rest of the code.
It is unclear if an error value should indeed be returned for maps of
maps or maps of progs, but this has no effect on the output either, so
we just leave the current behaviour unchanged.
Signed-off-by: Quentin Monnet <quentin.monnet@netronome.com>
Reviewed-by: Jakub Kicinski <jakub.kicinski@netronome.com>
---
tools/bpf/bpftool/map.c | 11 +++++------
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/tools/bpf/bpftool/map.c b/tools/bpf/bpftool/map.c
index bfbbc6b4cb83..206ee46189d9 100644
--- a/tools/bpf/bpftool/map.c
+++ b/tools/bpf/bpftool/map.c
@@ -686,7 +686,6 @@ static int dump_map_elem(int fd, void *key, void *value,
struct bpf_map_info *map_info, struct btf *btf,
json_writer_t *btf_wtr)
{
- int num_elems = 0;
int lookup_errno;
if (!bpf_map_lookup_elem(fd, key, value)) {
@@ -704,9 +703,8 @@ static int dump_map_elem(int fd, void *key, void *value,
} else {
print_entry_plain(map_info, key, value);
}
- num_elems++;
}
- return num_elems;
+ return 0;
}
/* lookup error handling */
@@ -714,7 +712,7 @@ static int dump_map_elem(int fd, void *key, void *value,
if (map_is_map_of_maps(map_info->type) ||
map_is_map_of_progs(map_info->type))
- return 0;
+ return -1;
if (json_output) {
jsonw_start_object(json_wtr);
@@ -738,7 +736,7 @@ static int dump_map_elem(int fd, void *key, void *value,
msg ? : strerror(lookup_errno));
}
- return 0;
+ return -1;
}
static int do_dump(int argc, char **argv)
@@ -800,7 +798,8 @@ static int do_dump(int argc, char **argv)
err = 0;
break;
}
- num_elems += dump_map_elem(fd, key, value, &info, btf, btf_wtr);
+ if (!dump_map_elem(fd, key, value, &info, btf, btf_wtr))
+ num_elems++;
prev_key = key;
}
--
2.17.1
^ permalink raw reply related
* [RFC bpf-next 2/3] tools: bpftool: make comment more explicit for count of dumped entries
From: Quentin Monnet @ 2019-08-13 13:09 UTC (permalink / raw)
To: Alexei Starovoitov, Daniel Borkmann
Cc: bpf, netdev, oss-drivers, Quentin Monnet
In-Reply-To: <20190813130921.10704-1-quentin.monnet@netronome.com>
The counter printed at the end of plain map dump does not reflect the
exact number of entries in the map, but the number of entries bpftool
managed to dump (some of them could not be read, or made no sense to
dump (map-in-map...)).
Edit slightly the message to make this more explicit.
Signed-off-by: Quentin Monnet <quentin.monnet@netronome.com>
Reviewed-by: Jakub Kicinski <jakub.kicinski@netronome.com>
---
tools/bpf/bpftool/map.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/bpf/bpftool/map.c b/tools/bpf/bpftool/map.c
index 206ee46189d9..cead639b3ab1 100644
--- a/tools/bpf/bpftool/map.c
+++ b/tools/bpf/bpftool/map.c
@@ -809,7 +809,7 @@ static int do_dump(int argc, char **argv)
jsonw_end_array(btf_wtr);
jsonw_destroy(&btf_wtr);
} else {
- printf("Found %u element%s\n", num_elems,
+ printf("Found %u element%s to dump\n", num_elems,
num_elems != 1 ? "s" : "");
}
--
2.17.1
^ permalink raw reply related
* [RFC bpf-next 0/3] tools: bpftool: add subcommand to count map entries
From: Quentin Monnet @ 2019-08-13 13:09 UTC (permalink / raw)
To: Alexei Starovoitov, Daniel Borkmann
Cc: bpf, netdev, oss-drivers, Quentin Monnet
This series adds a "bpftool map count" subcommand to count the number of
entries present in a BPF map. This results from a customer request for a
tool to count the number of entries in BPF maps used in production (for
example, to know how many free entries are left in a given map).
The first two commits actually contain some clean-up in preparation for the
new subcommand.
The third commit adds the new subcommand. Because what data should count as
an entry is not entirely clear for all map types, we actually dump several
counters, and leave it to the users to interpret the values.
Sending as a RFC because I'm looking for feedback on the approach. Is
printing several values the good thing to do? Also, note that some map
types such as queue/stack maps do not support any type of counting, this
would need to be implemented in the kernel I believe.
More generally, we have a use case where (hash) maps are under pressure
(many additions/deletions from the BPF program), and counting the entries
by iterating other the different keys is not at all reliable. Would that
make sense to add a new bpf() subcommand to count the entries on the kernel
side instead of cycling over the entries in bpftool? If so, we would need
to agree on what makes an entry for each kind of map.
Note that we are also facing similar issues for purging map from their
entries (deleting all entries at once). We can iterate on the keys and
delete elements one by one, but this is very inefficient when entries are
being added/removed in parallel from the BPF program, and having another
dedicated command accessible from the bpf() system call might help here as
well.
Quentin Monnet (3):
tools: bpftool: clean up dump_map_elem() return value
tools: bpftool: make comment more explicit for count of dumped entries
tools: bpftool: add "bpftool map count" to count entries in map
.../bpf/bpftool/Documentation/bpftool-map.rst | 15 +++
tools/bpf/bpftool/bash-completion/bpftool | 4 +-
tools/bpf/bpftool/map.c | 110 ++++++++++++++++--
3 files changed, 119 insertions(+), 10 deletions(-)
--
2.17.1
^ permalink raw reply
* Re: [PATCH] net: ethernet: mediatek: Add MT7628/88 SoC support
From: Stefan Roese @ 2019-08-13 13:09 UTC (permalink / raw)
To: Daniel Golle
Cc: netdev, René van Dorst, Felix Fietkau, Sean Wang,
linux-mediatek, John Crispin
In-Reply-To: <20190717121506.GD18996@makrotopia.org>
On 17.07.19 14:15, Daniel Golle wrote:
> On Wed, Jul 17, 2019 at 01:02:43PM +0200, Stefan Roese wrote:
>> This patch adds support for the MediaTek MT7628/88 SoCs to the common
>> MediaTek ethernet driver. Some minor changes are needed for this and
>> a bigger change, as the MT7628 does not support QDMA (only PDMA).
>
> The Ethernet core found in MT7628/88 is identical to that found in
> Ralink Rt5350F SoC. Wouldn't it hence make sense to indicate that
> in the compatible string of this driver as well? In OpenWrt we are
> using "ralink,rt5350-eth".
Okay. I'll use this ralink compatible instead in the next version.
Thanks,
Stefan
^ permalink raw reply
* [patch net-next] selftests: netdevsim: add devlink params tests
From: Jiri Pirko @ 2019-08-13 13:04 UTC (permalink / raw)
To: netdev; +Cc: davem, jakub.kicinski, mlxsw
From: Jiri Pirko <jiri@mellanox.com>
Test recently added netdevsim devlink param implementation.
Signed-off-by: Jiri Pirko <jiri@mellanox.com>
---
.../drivers/net/netdevsim/devlink.sh | 62 ++++++++++++++++++-
1 file changed, 61 insertions(+), 1 deletion(-)
diff --git a/tools/testing/selftests/drivers/net/netdevsim/devlink.sh b/tools/testing/selftests/drivers/net/netdevsim/devlink.sh
index 9d8baf5d14b3..858ebdc8d8a3 100755
--- a/tools/testing/selftests/drivers/net/netdevsim/devlink.sh
+++ b/tools/testing/selftests/drivers/net/netdevsim/devlink.sh
@@ -3,7 +3,7 @@
lib_dir=$(dirname $0)/../../../net/forwarding
-ALL_TESTS="fw_flash_test"
+ALL_TESTS="fw_flash_test params_test"
NUM_NETIFS=0
source $lib_dir/lib.sh
@@ -30,6 +30,66 @@ fw_flash_test()
log_test "fw flash test"
}
+param_get()
+{
+ local name=$1
+
+ devlink dev param show $DL_HANDLE name $name -j | \
+ jq -e -r '.[][][].values[] | select(.cmode == "driverinit").value'
+}
+
+param_set()
+{
+ local name=$1
+ local value=$2
+
+ devlink dev param set $DL_HANDLE name $name cmode driverinit value $value
+}
+
+check_value()
+{
+ local name=$1
+ local phase_name=$2
+ local expected_param_value=$3
+ local expected_debugfs_value=$4
+ local value
+
+ value=$(param_get $name)
+ check_err $? "Failed to get $name param value"
+ [ "$value" == "$expected_param_value" ]
+ check_err $? "Unexpected $phase_name $name param value"
+ value=$(<$DEBUGFS_DIR/$name)
+ check_err $? "Failed to get $name debugfs value"
+ [ "$value" == "$expected_debugfs_value" ]
+ check_err $? "Unexpected $phase_name $name debugfs value"
+}
+
+params_test()
+{
+ RET=0
+
+ local max_macs
+ local test1
+
+ check_value max_macs initial 32 32
+ check_value test1 initial true Y
+
+ param_set max_macs 16
+ check_err $? "Failed to set max_macs param value"
+ param_set test1 false
+ check_err $? "Failed to set test1 param value"
+
+ check_value max_macs post-set 16 32
+ check_value test1 post-set false Y
+
+ devlink dev reload $DL_HANDLE
+
+ check_value max_macs post-reload 16 16
+ check_value test1 post-reload false N
+
+ log_test "params test"
+}
+
setup_prepare()
{
modprobe netdevsim
--
2.21.0
^ permalink raw reply related
* Re: [PATCH net-next] net: can: Fix compiling warning
From: Dan Carpenter @ 2019-08-13 12:48 UTC (permalink / raw)
To: Kees Cook, Nicolai Stange
Cc: Oliver Hartkopp, Patrick Bellasi, linux-sparse, Mao Wenan, davem,
netdev, linux-kernel, kernel-janitors, Ingo Molnar
In-Reply-To: <201908121001.0AC0A90@keescook>
On Mon, Aug 12, 2019 at 10:19:27AM -0700, Kees Cook wrote:
> On Wed, Aug 07, 2019 at 01:50:42PM +0300, Dan Carpenter wrote:
> > On Tue, Aug 06, 2019 at 06:41:44PM +0200, Oliver Hartkopp wrote:
> > > I compiled the code (the original version), but I do not get that "Should it
> > > be static?" warning:
> > >
> > > user@box:~/net-next$ make C=1
> > > CALL scripts/checksyscalls.sh
> > > CALL scripts/atomic/check-atomics.sh
> > > DESCEND objtool
> > > CHK include/generated/compile.h
> > > CHECK net/can/af_can.c
> > > ./include/linux/sched.h:609:43: error: bad integer constant expression
> > > ./include/linux/sched.h:609:73: error: invalid named zero-width bitfield
> > > `value'
> > > ./include/linux/sched.h:610:43: error: bad integer constant expression
> > > ./include/linux/sched.h:610:67: error: invalid named zero-width bitfield
> > > `bucket_id'
> > > CC [M] net/can/af_can.o
> >
> > The sched.h errors suppress Sparse warnings so it's broken/useless now.
> > The code looks like this:
> >
> > include/linux/sched.h
> > 613 struct uclamp_se {
> > 614 unsigned int value : bits_per(SCHED_CAPACITY_SCALE);
> > 615 unsigned int bucket_id : bits_per(UCLAMP_BUCKETS);
> > 616 unsigned int active : 1;
> > 617 unsigned int user_defined : 1;
> > 618 };
> >
> > bits_per() is zero and Sparse doesn't like zero sized bitfields.
>
> I just noticed these sparse warnings too -- what's happening here? Are
> they _supposed_ to be 0-width fields? It doesn't look like it to me:
I'm sorr, I don't even know what code I was looking at before. I think
my cscope database was stale? You're right. Sparse doesn't think it's
zero, it knows that it is 11 and 3.
What's happening is that it's failing the test in in
bad_integer_constant_expression():
if (!(expr->flags & CEF_ICE))
The ICE in CEF_ICE stands for Integer Constant Expression. The rule
here is that enums are not constant expressions in c99. See the
explanation in commit 274c154704db ("constexpr: introduce additional
expression constness tracking flags").
I don't think the CEF_ICE is set properly in evaluate_conditional_expression().
If conditional is constant and it's true and the ->cond_true expression
is constant then the result should be constant as well. It shouldn't
matter if the cond_false is constant. But instead it is ANDing all
three sub expressions:
expr->flags = (expr->conditional->flags & (*true)->flags &
expr->cond_false->flags & ~CEF_CONST_MASK);
Or actually in this case it's doing:
if (expr->conditional->flags & (CEF_ACE | CEF_ADDR))
expr->flags = (*true)->flags & expr->cond_false->flags & ~CEF_CONST_MASK;
But it's the same problem because it's should ignore cond_false.
regards,
dan carpenter
^ permalink raw reply
* Re: KMSAN: uninit-value in smsc75xx_bind
From: Oliver Neukum @ 2019-08-13 12:43 UTC (permalink / raw)
To: syzbot, davem, glider, syzkaller-bugs, steve.glendinning,
linux-kernel, linux-usb, netdev
In-Reply-To: <0000000000009f4316058fab3bd7@google.com>
Am Freitag, den 09.08.2019, 01:48 -0700 schrieb syzbot:
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit: beaab8a3 fix KASAN build
> git tree: kmsan
[..]
> Call Trace:
> __dump_stack lib/dump_stack.c:77 [inline]
> dump_stack+0x191/0x1f0 lib/dump_stack.c:113
> kmsan_report+0x162/0x2d0 mm/kmsan/kmsan_report.c:109
> __msan_warning+0x75/0xe0 mm/kmsan/kmsan_instr.c:294
> smsc75xx_wait_ready drivers/net/usb/smsc75xx.c:976 [inline]
> smsc75xx_bind+0x541/0x12d0 drivers/net/usb/smsc75xx.c:1483
>
> Local variable description: ----buf.i93@smsc75xx_bind
> Variable was created at:
> __smsc75xx_read_reg drivers/net/usb/smsc75xx.c:83 [inline]
> smsc75xx_wait_ready drivers/net/usb/smsc75xx.c:969 [inline]
> smsc75xx_bind+0x44c/0x12d0 drivers/net/usb/smsc75xx.c:1483
> usbnet_probe+0x10d3/0x3950 drivers/net/usb/usbnet.c:1722
Hi,
this looks like a false positive to me.
The offending code is likely this:
if (size) {
buf = kmalloc(size, GFP_KERNEL);
if (!buf)
goto out;
}
err = usb_control_msg(dev->udev, usb_rcvctrlpipe(dev->udev, 0),
cmd, reqtype, value, index, buf, size,
USB_CTRL_GET_TIMEOUT);
which uses 'buf' uninitialized. But it is used for input.
What is happening here?
Regards
Oliver
^ permalink raw reply
* Re: [PATCH 12/16] arm64: prefer __section from compiler_attributes.h
From: Miguel Ojeda @ 2019-08-13 12:36 UTC (permalink / raw)
To: Will Deacon
Cc: Nick Desaulniers, Andrew Morton, Sedat Dilek, Josh Poimboeuf, yhs,
clang-built-linux, Catalin Marinas, Alexei Starovoitov,
Daniel Borkmann, Martin KaFai Lau, Song Liu, Andrey Konovalov,
Greg Kroah-Hartman, Enrico Weigelt, Suzuki K Poulose,
Thomas Gleixner, Masayoshi Mizuma, Shaokun Zhang, Alexios Zavras,
Allison Randal, Linux ARM, linux-kernel, Network Development, bpf
In-Reply-To: <20190813082744.xmzmm4j675rqiz47@willie-the-truck>
On Tue, Aug 13, 2019 at 10:27 AM Will Deacon <will@kernel.org> wrote:
>
> Hi Nick,
>
> On Mon, Aug 12, 2019 at 02:50:45PM -0700, Nick Desaulniers wrote:
> > GCC unescapes escaped string section names while Clang does not. Because
> > __section uses the `#` stringification operator for the section name, it
> > doesn't need to be escaped.
> >
> > This antipattern was found with:
> > $ grep -e __section\(\" -e __section__\(\" -r
> >
> > Reported-by: Sedat Dilek <sedat.dilek@gmail.com>
> > Suggested-by: Josh Poimboeuf <jpoimboe@redhat.com>
> > Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
> > ---
> > arch/arm64/include/asm/cache.h | 2 +-
> > arch/arm64/kernel/smp_spin_table.c | 2 +-
> > 2 files changed, 2 insertions(+), 2 deletions(-)
>
> Does this fix a build issue, or is it just cosmetic or do we end up with
> duplicate sections or something else?
This should be cosmetic -- basically we are trying to move all users
of current available __attribute__s in compiler_attributes.h to the
__attr forms. I am also adding (slowly) new attributes that are
already used but we don't have them yet in __attr form.
> Happy to route it via arm64, just having trouble working out whether it's
> 5.3 material!
As you prefer! Those that are not taken by a maintainer I will pick up
and send via compiler-attributes.
I would go for 5.4, since there is no particular rush anyway.
Cheers,
Miguel
^ permalink raw reply
* Re: libbpf distro packaging
From: Jiri Olsa @ 2019-08-13 12:24 UTC (permalink / raw)
To: Julia Kartseva
Cc: labbott@redhat.com, acme@kernel.org,
debian-kernel@lists.debian.org, netdev@vger.kernel.org,
Andrii Nakryiko, Andrey Ignatov, Alexei Starovoitov,
Yonghong Song, jolsa@kernel.org
In-Reply-To: <3FBEC3F8-5C3C-40F9-AF6E-C355D8F62722@fb.com>
On Mon, Aug 12, 2019 at 07:04:12PM +0000, Julia Kartseva wrote:
> I would like to bring up libbpf publishing discussion started at [1].
> The present state of things is that libbpf is built from kernel tree, e.g. [2]
> For Debian and [3] for Fedora whereas the better way would be having a
> package built from github mirror. The advantages of the latter:
> - Consistent, ABI matching versioning across distros
> - The mirror has integration tests
> - No need in kernel tree to build a package
> - Changes can be merged directly to github w/o waiting them to be merged
> through bpf-next -> net-next -> main
> There is a PR introducing a libbpf.spec which can be used as a starting point: [4]
> Any comments regarding the spec itself can be posted there.
> In the future it may be used as a source of truth.
> Please consider switching libbpf packaging to the github mirror instead
> of the kernel tree.
> Thanks
>
> [1] https://lists.iovisor.org/g/iovisor-dev/message/1521
> [2] https://packages.debian.org/sid/libbpf4.19
> [3] http://rpmfind.net/linux/RPM/fedora/devel/rawhide/x86_64/l/libbpf-5.3.0-0.rc2.git0.1.fc31.x86_64.html
> [4] https://github.com/libbpf/libbpf/pull/64
hi,
Fedora has libbpf as kernel-tools subpackage, so I think
we'd need to create new package and deprecate the current
but I like the ABI stability by using github .. how's actually
the sync (in both directions) with kernel sources going on?
thanks,
jirka
^ 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