* KASAN: use-after-free Read in tcp_sk_exit
From: syzbot @ 2019-02-06 5:01 UTC (permalink / raw)
To: davem, edumazet, kuznet, linux-kernel, netdev, syzkaller-bugs,
yoshfuji
Hello,
syzbot found the following crash on:
HEAD commit: 33a0efa4baec devlink: Use DIV_ROUND_UP_ULL in DEVLINK_HEAL..
git tree: net-next
console output: https://syzkaller.appspot.com/x/log.txt?x=14e2e55f400000
kernel config: https://syzkaller.appspot.com/x/.config?x=505743eba4e4f68
dashboard link: https://syzkaller.appspot.com/bug?extid=f797267da5e5012d0920
compiler: gcc (GCC) 9.0.0 20181231 (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+f797267da5e5012d0920@syzkaller.appspotmail.com
==================================================================
BUG: KASAN: use-after-free in inet_ctl_sock_destroy
include/net/inet_common.h:56 [inline]
BUG: KASAN: use-after-free in tcp_sk_exit+0x203/0x230
net/ipv4/tcp_ipv4.c:2588
Read of size 8 at addr ffff888064de4378 by task kworker/u4:3/131
CPU: 0 PID: 131 Comm: kworker/u4:3 Not tainted 5.0.0-rc3+ #17
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Workqueue: netns cleanup_net
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x1db/0x2d0 lib/dump_stack.c:113
print_address_description.cold+0x7c/0x20d mm/kasan/report.c:187
kasan_report.cold+0x1b/0x40 mm/kasan/report.c:317
__asan_report_load8_noabort+0x14/0x20 mm/kasan/generic_report.c:135
inet_ctl_sock_destroy include/net/inet_common.h:56 [inline]
tcp_sk_exit+0x203/0x230 net/ipv4/tcp_ipv4.c:2588
ops_exit_list.isra.0+0xb0/0x160 net/core/net_namespace.c:153
cleanup_net+0x51d/0xb10 net/core/net_namespace.c:551
process_one_work+0xd0c/0x1ce0 kernel/workqueue.c:2153
worker_thread+0x143/0x14a0 kernel/workqueue.c:2296
kthread+0x357/0x430 kernel/kthread.c:246
ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:352
Allocated by task 5864:
save_stack+0x45/0xd0 mm/kasan/common.c:73
set_track mm/kasan/common.c:85 [inline]
__kasan_kmalloc mm/kasan/common.c:496 [inline]
__kasan_kmalloc.constprop.0+0xcf/0xe0 mm/kasan/common.c:469
kasan_kmalloc mm/kasan/common.c:504 [inline]
kasan_slab_alloc+0xf/0x20 mm/kasan/common.c:411
kmem_cache_alloc+0x12d/0x710 mm/slab.c:3543
getname_flags fs/namei.c:140 [inline]
getname_flags+0xd6/0x5b0 fs/namei.c:129
getname+0x1a/0x20 fs/namei.c:211
do_sys_open+0x3a5/0x7c0 fs/open.c:1057
__do_sys_open fs/open.c:1081 [inline]
__se_sys_open fs/open.c:1076 [inline]
__x64_sys_open+0x7e/0xc0 fs/open.c:1076
do_syscall_64+0x1a3/0x800 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe
Freed by task 5864:
save_stack+0x45/0xd0 mm/kasan/common.c:73
set_track mm/kasan/common.c:85 [inline]
__kasan_slab_free+0x102/0x150 mm/kasan/common.c:458
kasan_slab_free+0xe/0x10 mm/kasan/common.c:466
__cache_free mm/slab.c:3487 [inline]
kmem_cache_free+0x86/0x260 mm/slab.c:3749
putname+0xef/0x130 fs/namei.c:261
do_sys_open+0x3f4/0x7c0 fs/open.c:1072
__do_sys_open fs/open.c:1081 [inline]
__se_sys_open fs/open.c:1076 [inline]
__x64_sys_open+0x7e/0xc0 fs/open.c:1076
do_syscall_64+0x1a3/0x800 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe
The buggy address belongs to the object at ffff888064de4180
which belongs to the cache names_cache of size 4096
The buggy address is located 504 bytes inside of
4096-byte region [ffff888064de4180, ffff888064de5180)
The buggy address belongs to the page:
page:ffffea0001937900 count:1 mapcount:0 mapping:ffff88821bc45380 index:0x0
compound_mapcount: 0
flags: 0x1fffc0000010200(slab|head)
raw: 01fffc0000010200 ffffea0001931108 ffffea0001796b88 ffff88821bc45380
raw: 0000000000000000 ffff888064de4180 0000000100000001 0000000000000000
page dumped because: kasan: bad access detected
Memory state around the buggy address:
ffff888064de4200: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
ffff888064de4280: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> ffff888064de4300: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
^
ffff888064de4380: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
ffff888064de4400: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
==================================================================
---
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
* BUG: spinlock bad magic in __queue_work
From: syzbot @ 2019-02-06 5:01 UTC (permalink / raw)
To: davem, kuznet, linux-kernel, netdev, syzkaller-bugs, yoshfuji
Hello,
syzbot found the following crash on:
HEAD commit: 962c382d482a Merge tag 'mac80211-next-for-davem-2019-02-01..
git tree: net-next
console output: https://syzkaller.appspot.com/x/log.txt?x=169299f8c00000
kernel config: https://syzkaller.appspot.com/x/.config?x=33ad02b9305759c3
dashboard link: https://syzkaller.appspot.com/bug?extid=636bcaf4b481f6b7343c
compiler: gcc (GCC) 9.0.0 20181231 (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+636bcaf4b481f6b7343c@syzkaller.appspotmail.com
netlink: 8 bytes leftover after parsing attributes in process
`syz-executor5'.
BUG: spinlock bad magic on CPU#0, syz-executor0/1737
lock: 0xffff8880ae82c7e0, .magic: ffffffff, .owner: %us
workers=%d/1902867055, .owner_cpu: 0
CPU: 0 PID: 1737 Comm: syz-executor0 Not tainted 5.0.0-rc4+ #40
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+0x172/0x1f0 lib/dump_stack.c:113
spin_dump.cold+0x81/0xe6 kernel/locking/spinlock_debug.c:67
spin_bug kernel/locking/spinlock_debug.c:75 [inline]
debug_spin_lock_before kernel/locking/spinlock_debug.c:83 [inline]
do_raw_spin_lock+0x231/0x2e0 kernel/locking/spinlock_debug.c:112
__raw_spin_lock include/linux/spinlock_api_smp.h:143 [inline]
_raw_spin_lock+0x37/0x40 kernel/locking/spinlock.c:144
spin_lock include/linux/spinlock.h:329 [inline]
__queue_work+0x23d/0x1180 kernel/workqueue.c:1417
__queue_delayed_work+0x1d6/0x270 kernel/workqueue.c:1522
mod_delayed_work_on+0xd8/0x200 kernel/workqueue.c:1596
mod_delayed_work include/linux/workqueue.h:542 [inline]
addrconf_mod_dad_work+0x3f/0xa0 net/ipv6/addrconf.c:328
addrconf_dad_start+0x76/0xb0 net/ipv6/addrconf.c:4011
addrconf_add_linklocal+0x28c/0x3c0 net/ipv6/addrconf.c:3190
addrconf_addr_gen+0x34d/0x3a0 net/ipv6/addrconf.c:3313
addrconf_dev_config+0x1ea/0x2c0 net/ipv6/addrconf.c:3356
addrconf_notify+0x3c5/0x2280 net/ipv6/addrconf.c:3591
kobject: 'loop4' (00000000f520b29a): kobject_uevent_env
kobject: 'loop4' (00000000f520b29a): fill_kobj_path: path
= '/devices/virtual/block/loop4'
notifier_call_chain+0xc7/0x240 kernel/notifier.c:93
__raw_notifier_call_chain kernel/notifier.c:394 [inline]
raw_notifier_call_chain+0x2e/0x40 kernel/notifier.c:401
call_netdevice_notifiers_info+0x3f/0x90 net/core/dev.c:1739
call_netdevice_notifiers_extack net/core/dev.c:1751 [inline]
call_netdevice_notifiers net/core/dev.c:1765 [inline]
dev_open net/core/dev.c:1436 [inline]
dev_open+0x143/0x160 net/core/dev.c:1424
ipmr_new_tunnel+0x3d3/0x4d0 net/ipv4/ipmr.c:511
vif_add+0x1bd/0xed0 net/ipv4/ipmr.c:873
ip_mroute_setsockopt+0xd05/0xe10 net/ipv4/ipmr.c:1453
do_ip_setsockopt.isra.0+0x3036/0x3e00 net/ipv4/ip_sockglue.c:638
ip_setsockopt+0x49/0x100 net/ipv4/ip_sockglue.c:1246
raw_setsockopt+0xe0/0x100 net/ipv4/raw.c:860
sock_common_setsockopt+0x9a/0xe0 net/core/sock.c:3016
__sys_setsockopt+0x180/0x280 net/socket.c:1902
__do_sys_setsockopt net/socket.c:1913 [inline]
__se_sys_setsockopt net/socket.c:1910 [inline]
__x64_sys_setsockopt+0xbe/0x150 net/socket.c:1910
do_syscall_64+0x103/0x610 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x457e39
Code: ad b8 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 7b b8 fb ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:00007fbac2bcec78 EFLAGS: 00000246 ORIG_RAX: 0000000000000036
RAX: ffffffffffffffda RBX: 0000000000000005 RCX: 0000000000457e39
RDX: 00000000000000ca RSI: 0000000000000000 RDI: 0000000000000004
RBP: 000000000073bfa0 R08: 0000000000000010 R09: 0000000000000000
R10: 0000000020000000 R11: 0000000000000246 R12: 00007fbac2bcf6d4
R13: 00000000004c5c09 R14: 00000000004da070 R15: 00000000ffffffff
netlink: 8 bytes leftover after parsing attributes in process
`syz-executor5'.
---
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: [RFC 00/14] netlink/hierarchical stats
From: Jakub Kicinski @ 2019-02-06 4:45 UTC (permalink / raw)
To: Roopa Prabhu
Cc: David Miller, oss-drivers, netdev, Jiří Pírko,
Florian Fainelli, Andrew Lunn, Michal Kubecek, David Ahern,
Simon Horman, Brandeburg, Jesse, Maciek Fijałkowski,
vasundhara-v.volam, Michael Chan, shalomt, Ido Schimmel
In-Reply-To: <CAJieiUh7wEjYo1pUuPCgAFTNkWs+kvWiSScBGFzhNyOc2TibOA@mail.gmail.com>
On Sat, 2 Feb 2019 15:14:44 -0800, Roopa Prabhu wrote:
> On Thu, Jan 31, 2019 at 11:31 AM Jakub Kicinski wrote:
> > On Thu, 31 Jan 2019 08:31:51 -0800, Roopa Prabhu wrote:
> > > On Thu, Jan 31, 2019 at 8:16 AM Roopa Prabhu wrote:
> > > > On Wed, Jan 30, 2019 at 4:24 PM Jakub Kicinski wrote:
> > > > > On Wed, 30 Jan 2019 14:14:34 -0800, Roopa Prabhu wrote:
> > > > >
> > > > > My thinking was that we should leave truly custom/strange stats to
> > > > > ethtool API which works quite well for that and at the same time be
> > > > > very accepting of people adding new IDs to HSTAT (only requirement is
> > > > > basically defining the meaning very clearly).
> > > >
> > > > that sounds reasonable. But the 'defining meaning clearly' gets tricky
> > > > sometimes.
> > > > The vendor who gets their ID or meaning first wins :) and the rest
> > > > will have to live with
> > > > ethtool and explain to rest of the world that ethtool is more reliable
> > > > for their hardware :)
> >
> > Right, that's the trade off inherent to standardization. I don't see
> > any way to work around the fact that the definition may not fit all.
> >
> > What I want as a end user and what I want for my customers is the
> > ability to switch the NIC on their system and not spend two months
> > "integrating" into their automation :( If the definition of statistics
> > is not solid we're back to square one.
>
> agree. And I am with you on standardizing them.
>
> >
> > > > I am also concerned that this getting the ID into common HSTAT ID
> > > > space will slow down the process of adding new counters
> > > > for vendors. Which will lead to vendors sticking with ethtool API.
> >
> > I feel like whatever we did here will end up looking much like the
> > ethtool interface, which is why I decided to leave that part out.
> > Ethtool -S works pretty well for custom stats. Standard and structured
> > stats don't fit with it in any way, the two seem best left separate.
>
> understand the fear. My only point was getting them together in a
> single API is better so that they don't get developed separately and
> we don't end up with duplicate stats code.
>
> >
> > > > It would be great if people can get all stats in one place and not
> > > > rely on another API for 'more'.
> >
> > One place in the driver or for the user? I'm happy to add the code to
> > ethtool to also dump hstats and render them in a standard way. In fact
> > the tool I have for testing has a "simplified" output format which
> > looks exactly like ethtool -S.
> >
> > One place for the driver to report is hard, as I said I think the
> > custom stats are best left with ethtool. Adding an extra incentive to
> > standardize.
> >
> > > > > For the first stab I looked at two drivers and added all the stats that
> > > > > were common.
> > > > >
> > > > > Given this set is identifying statistics by ID - how would we make that
> > > > > extensible to drivers? Would we go back to strings or have some
> > > > > "driver specific" ID space?
> > > >
> > > > I was looking for ideas from you really, to see if you had considered
> > > > this. agree per driver ID space seems ugly.
> > > > ethtool strings are great today...if we can control the duplication.
> > > > But thinking some more..., i did see some
> > > > patches recently for vendor specific parameter (with ID) space in
> > > > devlink. maybe something like that will be
> > > > reasonable ?
> >
> > I thought about this for a year and I basically came to the conclusion
> > I can't find any perfect solution, if there is one.
> >
> > The devlink parameters are useful, but as anticipated they became the
> > laziest excuse of an ABI... Don't get me started ;)
> >
> > > > > Is there any particular type of statistic you'd expect drivers to want
> > > > > to add? For NICs I think IEEE/RMON should pretty much cover the
> > > > > silicon ones, but I don't know much about switches :)
> > > >
> > > > I will have to go through the list. But switch asics do support
> > > > flexible stats/counters that can be attached at various points.
> > > > And new chip versions come with more support. Having that flexibility
> > > > to expose/extend such stats incrementally is very valuable on a per
> > > > hardware/vendor basis.
> >
> > Yes, I'm not too familiar with those counters. Do they need to be
> > enabled to start counting?
>
> yes correct.
>
> > Do they have performance impact?
>
> I have not heard of any performance impact...but they are not enabled
> by default because of limited counter resource pool.
I see.. I'd personally see that as something that we probably either
support via perf, or new devlink perf creation. Those are perf events,
not stats to me. Devlink would probably suit fixed HW better, and
perf could feel slightly more natural to certain NICs (*ekhm* perf
traces of offloaded BPF programs).
> > Can the
> > "sample" events perf-style?
>
> I don't think so
>
> > How is the condition on which they trigger
> > defined? Is it maybe just "match a packet and increment a counter"?
>
> yes, something like that.
>
> > Would such counters benefit from hierarchical structure?
>
> hmm not sure.
>
>
> One thing though, for most of these flexible counters and their
> attachment points in hardware, we can count them on logical devices or
> other objects in software like per vlan, vni, route stats etc.
>
> >
> > I was trying to cover the long standing use cases - namely the
> > IEEE/RMON stats which all MAC have had for years and per queue stats
> > which all drivers have had for years. But if we can cater to more
> > cases I'm open.
> >
> > > Just want to clarify that I am suggesting a nested HSTATS extension
> > > infra for drivers (just like ethtool).
> > > 'Common stats' stays at the top-level.
> >
> > I got a concept of groups here. The dump generally looks like this:
> >
> > [root group A (say MAC stats)]
> > [sub group RX]
> > [sub group TX]
> > [root group B (say PCIe stats)]
> > [sub group RX]
> > [sub group TX]
> > [root group C (say per-q driver stats]
> > [sub group RX]
> > [q1 group]
> > [q2 group]
> > [q3 group]
> > [sub group TX]
> > [q1 group]
> > [q2 group]
> > [q3 group]
> >
> > Each root group representing a "point in the pipeline".
> >
> > So it's not too hard to add a root group with whatever, the questions
> > are move how would it benefit over existing ethtool if the stats are
> > custom anyway? Hm..
>
> It wouldn't. I am only saying that the netlink stats API is the new
> place to move stats.
> Ethtool stats will have to move to netlink some day and I don't see a
> need to draw a hardline on saying no to ethtool custom stats moving to
> the netlink based common stats API. And unless there is a good
> migration path for a new hardware stats API that is all inclusive,
> there is a higher chance of continued development on the older
> hardware stats API.
> I have no objections to having a standard set of stats (this is
> essentially what we have for software stats too).
>
> I don't want to block your series from going forward without HW custom
> stats extensions. And IIUC your API is extensible and does not
> preclude anyone from adding the ability to include HW custom stats
> extensions in the future with enough justification. That is good for
> me.
Would you be more interested in seeing the similarity in API on the
driver side or on the netlink side? I was hoping to leave the legacy
stats in ethtool (soon to be running over netlink as well) for the
time being. I wish we had some form of library on the iproute2 side
we could evolve together with the kernel libbpf-style :(
> To take a random example, we expose the following stats on our
> switches via ethtool. I have not used them personally but they
> correspond to respective hardware counters. Is there any room for such
> stats in the new HSTATS netlink API or they will have to stick to
> ethtool ?
> I believe people will need per-queue counters for this.
>
> HwIfOutWredDrops: 0
> HwIfOutQ0WredDrops: 0
> HwIfOutQ1WredDrops: 0
> HwIfOutQ2WredDrops: 0
> HwIfOutQ3WredDrops: 0
> HwIfOutQ4WredDrops: 0
> HwIfOutQ5WredDrops: 0
> HwIfOutQ6WredDrops: 0
> HwIfOutQ7WredDrops: 0
> HwIfOutQ8WredDrops: 0
> HwIfOutQ9WredDrops: 0
Well, yes, so these are clearly enough defined stats, and I'd be very
happy to add an ID for you for those... if those shouldn't be reported
in the tc qdisc red stats that should be used to configure WRED :(
^ permalink raw reply
* Re: [PATCH bpf-next] tools/bpf: fix a selftest test_btf failure
From: Yonghong Song @ 2019-02-06 4:26 UTC (permalink / raw)
To: Alexei Starovoitov
Cc: Andrii Nakryiko, netdev@vger.kernel.org, Alexei Starovoitov,
Daniel Borkmann, Kernel Team
In-Reply-To: <20190206023615.7w5q2y4xpk3acde4@ast-mbp>
On 2/5/19 6:36 PM, Alexei Starovoitov wrote:
> On Tue, Feb 05, 2019 at 02:28:44PM -0800, Yonghong Song wrote:
>> Commit 9c651127445c ("selftests/btf: add initial BTF dedup tests")
>> added dedup tests in test_btf.c.
>> It broke the raw test:
>> BTF raw test[71] (func proto (Bad arg name_off)):
>> btf_raw_create:2905:FAIL Error getting string #65535, strs_cnt:1
>>
>> The test itself encodes invalid func_proto parameter name
>> offset 0xffffFFFF as a negative test for the kernel.
>> The above commit changed the meaning of that offset and
>> resulted in a user space error.
>> #define NAME_NTH(N) (0xffff0000 | N)
>> #define IS_NAME_NTH(X) ((X & 0xffff0000) == 0xffff0000)
>> #define GET_NAME_NTH_IDX(X) (X & 0x0000ffff)
>>
>> Currently, the kernel permits maximum name offset 0xffff.
>> Set the test name off as 0x0fffFFFF to trigger the kernel
>> verification failure.
>>
>> Cc: Andrii Nakryiko <andriin@fb.com>
>> Fixes: 9c651127445c ("selftests/btf: add initial BTF dedup tests")
>> Signed-off-by: Yonghong Song <yhs@fb.com>
>
> Applied, Thanks
>
> Also I see the following new error in test_btf:
> BTF libbpf test[2] (test_btf_nokv.o): libbpf: map:btf_map container_name:____btf_map_btf_map cannot be found in BTF. Missing BPF_ANNOTATE_KV_PAIR?
> OK
>
> A bunch of similar errors are in test_progs as well.
> I suspect it's related to the last few btf changes.
> Andrii, Yonghong, Please investigate.
It is due to one of previous patches to refector btf__get_map_kv_tids(),
accidentally using pr_warning instead of original pr_debug.
Will submit a patch soon.
>
^ permalink raw reply
* Re: [net-next 00/14][pull request] Intel Wired LAN Driver Updates 2019-02-05
From: David Miller @ 2019-02-06 4:21 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, nhorman, sassmann
In-Reply-To: <20190206020424.12225-1-jeffrey.t.kirsher@intel.com>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Tue, 5 Feb 2019 18:04:10 -0800
> This series contains updates to igc, e1000e, ixgbe, fm10k and driver
> documentation.
>
> Kai-Heng Feng fixes an e1000e issue where the Wake-On-LAN settings where
> being set incorrectly during a system suspend.
>
> Sasha addresses community feedback on the igc driver and provides a
> number of code cleanups to remove either unreachable or unused code. In
> addition, added basic ethtool support for the igc driver.
>
> Mike Rapoport fixes the formatting of the kernel driver documentation so
> that the title is properly formatted and does not get lumped with the
> document sections in the HTML kernel documents generated.
>
> Jiri Kosina updates a hard coded RAR entries value with the existing
> define IXGBE_82599_RAR_ENTRIES.
>
> Jake fixes up whitespace in the fm10k driver.
>
> Konstantin Khlebnikov fixes an issue where in some cases, the e1000e
> driver will continually reset during a system boot because the watchdog
> task sees items in the transmit buffer but the carrier is off (trying to
> establish link) causing the device reset to flush the buffer. To
> resolve, just move this check/flush into the watchdog section for when
> the carrier is off.
>
> Todd bumps the igb driver version to reflect the recent driver changes.
Pulled, thanks Jeff.
^ permalink raw reply
* Re: [RFC bpf-next 0/7] net: flow_dissector: trigger BPF hook when called from eth_get_headlen
From: Alexei Starovoitov @ 2019-02-06 4:11 UTC (permalink / raw)
To: Stanislav Fomichev
Cc: Willem de Bruijn, Stanislav Fomichev, Network Development,
David Miller, Alexei Starovoitov, Daniel Borkmann, simon.horman,
Willem de Bruijn
In-Reply-To: <20190206035619.GG10769@mini-arch>
On Tue, Feb 05, 2019 at 07:56:19PM -0800, Stanislav Fomichev wrote:
> On 02/05, Alexei Starovoitov wrote:
> > On Tue, Feb 05, 2019 at 04:59:31PM -0800, Stanislav Fomichev wrote:
> > > On 02/05, Alexei Starovoitov wrote:
> > > > On Tue, Feb 05, 2019 at 12:40:03PM -0800, Stanislav Fomichev wrote:
> > > > > On 02/05, Willem de Bruijn wrote:
> > > > > > On Tue, Feb 5, 2019 at 12:57 PM Stanislav Fomichev <sdf@google.com> wrote:
> > > > > > >
> > > > > > > Currently, when eth_get_headlen calls flow dissector, it doesn't pass any
> > > > > > > skb. Because we use passed skb to lookup associated networking namespace
> > > > > > > to find whether we have a BPF program attached or not, we always use
> > > > > > > C-based flow dissector in this case.
> > > > > > >
> > > > > > > The goal of this patch series is to add new networking namespace argument
> > > > > > > to the eth_get_headlen and make BPF flow dissector programs be able to
> > > > > > > work in the skb-less case.
> > > > > > >
> > > > > > > The series goes like this:
> > > > > > > 1. introduce __init_skb and __init_skb_shinfo; those will be used to
> > > > > > > initialize temporary skb
> > > > > > > 2. introduce skb_net which can be used to get networking namespace
> > > > > > > associated with an skb
> > > > > > > 3. add new optional network namespace argument to __skb_flow_dissect and
> > > > > > > plumb through the callers
> > > > > > > 4. add new __flow_bpf_dissect which constructs temporary on-stack skb
> > > > > > > (using __init_skb) and calls BPF flow dissector program
> > > > > >
> > > > > > The main concern I see with this series is this cost of skb zeroing
> > > > > > for every packet in the device driver receive routine, *independent*
> > > > > > from the real skb allocation and zeroing which will likely happen
> > > > > > later.
> > > > > Yes, plus ~200 bytes on the stack for the callers.
> > > > >
> > > > > Not sure how visible this zeroing though, I can probably try to get some
> > > > > numbers from BPF_PROG_TEST_RUN (running current version vs running with
> > > > > on-stack skb).
> > > >
> > > > imo extra 256 byte memset for every packet is non starter.
> > > We can put pre-allocated/initialized skbs without data into percpu or even
> > > use pcpu_freelist_pop/pcpu_freelist_push to make sure we don't have to think
> > > about having multiple percpu for irq/softirq/process contexts.
> > > Any concerns with that approach?
> > > Any other possible concerns with the overall series?
> >
> > I'm missing why the whole thing is needed.
> > You're saying:
> > " make BPF flow dissector programs be able to work in the skb-less case".
> > What does it mean specifically?
> > The only non-skb case is XDP.
> > Are you saying you want flow_dissector prog to be run in XDP?
> eth_get_headlen that drivers call on RX path on a chunk of data to
> guesstimate the length of the headers calls flow dissector without an skb
> (__skb_flow_dissect was a weird interface where it accepts skb or
> data+len). Right now, there is no way to trigger BPF flow dissector
> for this case (we don't have an skb to get associated namespace/etc/etc).
> The patch series tries to fix that to make sure that we always trigger
> BPF program if it's attached to a device's namespace.
then why not to create flow_dissector prog type that works without skb?
Why do you need to fake an skb?
XDP progs work just fine without it.
^ permalink raw reply
* Re: Pull patches from tip/perf/core to bpf-next
From: Song Liu @ 2019-02-06 4:07 UTC (permalink / raw)
To: Alexei Starovoitov
Cc: Daniel Borkmann, Alexei Starovoitov, Kernel Team, Netdev
In-Reply-To: <20190206034729.ao2gifc4phbhrhib@ast-mbp>
> On Feb 5, 2019, at 7:47 PM, Alexei Starovoitov <alexei.starovoitov@gmail.com> wrote:
>
> On Wed, Feb 06, 2019 at 03:44:29AM +0000, Song Liu wrote:
>>
>>
>>> On Feb 5, 2019, at 7:36 PM, Alexei Starovoitov <alexei.starovoitov@gmail.com> wrote:
>>>
>>> On Tue, Feb 05, 2019 at 10:47:06PM +0000, Song Liu wrote:
>>>> Hi Alexei and Daniel,
>>>>
>>>> The following patches are required for BPF introspection in perf tools.
>>>> Please pull them to bpf-next, so that we get all the dependencies in one
>>>> tree.
>>>>
>>>> Thanks,
>>>> Song
>>>>
>>>> (from 1/10 to 10/10)
>>>> 76193a94522f perf, bpf: Introduce PERF_RECORD_KSYMBOL
>>>> d764ac646491 tools headers uapi: Sync tools/include/uapi/linux/perf_event.h
>>>> 6ee52e2a3fe4 perf, bpf: Introduce PERF_RECORD_BPF_EVENT
>>>> df063c83aa2c tools headers uapi: Sync tools/include/uapi/linux/perf_event.h
>>>> 9aa0bfa370b2 perf tools: Handle PERF_RECORD_KSYMBOL
>>>> 45178a928a4b perf tools: Handle PERF_RECORD_BPF_EVENT
>>>> 7b612e291a5a perf tools: Synthesize PERF_RECORD_* for loaded BPF programs
>>>> a40b95bcd30c perf top: Synthesize BPF events for pre-existing loaded BPF programs
>>>> 6934058d9fb6 bpf: Add module name [bpf] to ksymbols for bpf programs
>>>> 811184fb6977 perf bpf: Fix synthesized PERF_RECORD_KSYMBOL/BPF_EVENT
>>>
>>> yes. we can certainly do that.
>>> Do you have bpf specific patches that depend on that ?
>>> Since it's rc5 already. Are you planning to send them within next week?
>>
>> BPF introspection work depends on these patches. I have been hopping
>> between perf tree and bpf-next tree. I think basing the series up on
>> bpf-next plus these patches leads least conflicts.
>>
>> I do plan to send the series within next week.
>>
>> On a second thought, maybe I should send based on perf tree, and worry
>> about the conflicts later? It is really heavier on perf side.
>
> whichever way is easier.
> if bpf-next is the best use that as a base with above patches.
> Once your set gets Acks from perf folks we can push above patches
> from tip first and then apply your set.
I see. Let's wait until the patchset is acked.
Thanks,
Song
^ permalink raw reply
* [PATCH bpf-next 5/5] selftests/bpf: test reading the offloaded program
From: Jakub Kicinski @ 2019-02-06 4:03 UTC (permalink / raw)
To: alexei.starovoitov, daniel; +Cc: netdev, oss-drivers, Jakub Kicinski
In-Reply-To: <20190206040324.22109-1-jakub.kicinski@netronome.com>
Test adding the offloaded program after the other program
is already installed.
Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Reviewed-by: Quentin Monnet <quentin.monnet@netronome.com>
---
tools/testing/selftests/bpf/test_offload.py | 29 ++++++++++++++-------
1 file changed, 20 insertions(+), 9 deletions(-)
diff --git a/tools/testing/selftests/bpf/test_offload.py b/tools/testing/selftests/bpf/test_offload.py
index 13fe12d09704..84bea3985d64 100755
--- a/tools/testing/selftests/bpf/test_offload.py
+++ b/tools/testing/selftests/bpf/test_offload.py
@@ -592,6 +592,15 @@ def bpftool_prog_load(sample, file_name, maps=[], prog_type="xdp", dev=None,
return
fail(True, "Missing or incorrect message from netdevsim in verifier log")
+def check_multi_basic(two_xdps):
+ fail(two_xdps["mode"] != 4, "Bad mode reported with multiple programs")
+ fail("prog" in two_xdps, "Base program reported in multi program mode")
+ fail(len(two_xdps["attached"]) != 2,
+ "Wrong attached program count with two programs")
+ fail(two_xdps["attached"][0]["prog"]["id"] ==
+ two_xdps["attached"][1]["prog"]["id"],
+ "Offloaded and other programs have the same id")
+
def test_spurios_extack(sim, obj, skip_hw, needle):
res = sim.cls_bpf_add_filter(obj, prio=1, handle=1, skip_hw=skip_hw,
include_stderr=True)
@@ -615,17 +624,12 @@ def bpftool_prog_load(sample, file_name, maps=[], prog_type="xdp", dev=None,
sim.set_xdp(obj, modename)
two_xdps = sim.ip_link_show(xdp=True)["xdp"]
- offloaded2 = sim.dfs_read("bpf_offloaded_id")
- fail(two_xdps["mode"] != 4, "Bad mode reported with multiple programs")
- fail("prog" in two_xdps, "Base program reported in multi program mode")
fail(xdp["attached"][0] not in two_xdps["attached"],
"Offload program not reported after other activated")
- fail(len(two_xdps["attached"]) != 2,
- "Wrong attached program count with two programs")
- fail(two_xdps["attached"][0]["prog"]["id"] ==
- two_xdps["attached"][1]["prog"]["id"],
- "Offloaded and other programs have the same id")
+ check_multi_basic(two_xdps)
+
+ offloaded2 = sim.dfs_read("bpf_offloaded_id")
fail(offloaded != offloaded2,
"Offload ID changed after loading other program")
@@ -655,8 +659,15 @@ def bpftool_prog_load(sample, file_name, maps=[], prog_type="xdp", dev=None,
"Wrong attached program count with remaining programs")
fail(offloaded != "0", "Offload ID reported with only other program left")
- start_test("Test multi-attachment XDP - device remove...")
+ start_test("Test multi-attachment XDP - reattach...")
sim.set_xdp(obj, "offload")
+ two_xdps = sim.ip_link_show(xdp=True)["xdp"]
+
+ fail(xdp["attached"][0] not in two_xdps["attached"],
+ "Other program not reported after offload activated")
+ check_multi_basic(two_xdps)
+
+ start_test("Test multi-attachment XDP - device remove...")
sim.remove()
sim = NetdevSim()
--
2.19.2
^ permalink raw reply related
* [PATCH bpf-next 4/5] selftests/bpf: add test for mixing generic and offload XDP
From: Jakub Kicinski @ 2019-02-06 4:03 UTC (permalink / raw)
To: alexei.starovoitov, daniel; +Cc: netdev, oss-drivers, Jakub Kicinski
In-Reply-To: <20190206040324.22109-1-jakub.kicinski@netronome.com>
Add simple sanity check for enabling generic and offload
XDP, simply reuse the native and offload checks.
Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Reviewed-by: Quentin Monnet <quentin.monnet@netronome.com>
---
tools/testing/selftests/bpf/test_offload.py | 116 +++++++++++---------
1 file changed, 62 insertions(+), 54 deletions(-)
diff --git a/tools/testing/selftests/bpf/test_offload.py b/tools/testing/selftests/bpf/test_offload.py
index c379b36a5443..13fe12d09704 100755
--- a/tools/testing/selftests/bpf/test_offload.py
+++ b/tools/testing/selftests/bpf/test_offload.py
@@ -603,6 +603,65 @@ def bpftool_prog_load(sample, file_name, maps=[], prog_type="xdp", dev=None,
include_stderr=True)
check_no_extack(res, needle)
+def test_multi_prog(sim, obj, modename, modeid):
+ start_test("Test multi-attachment XDP - %s + offload..." %
+ (modename or "default", ))
+ sim.set_xdp(obj, "offload")
+ xdp = sim.ip_link_show(xdp=True)["xdp"]
+ offloaded = sim.dfs_read("bpf_offloaded_id")
+ fail("prog" not in xdp, "Base program not reported in single program mode")
+ fail(len(xdp["attached"]) != 1,
+ "Wrong attached program count with one program")
+
+ sim.set_xdp(obj, modename)
+ two_xdps = sim.ip_link_show(xdp=True)["xdp"]
+ offloaded2 = sim.dfs_read("bpf_offloaded_id")
+
+ fail(two_xdps["mode"] != 4, "Bad mode reported with multiple programs")
+ fail("prog" in two_xdps, "Base program reported in multi program mode")
+ fail(xdp["attached"][0] not in two_xdps["attached"],
+ "Offload program not reported after other activated")
+ fail(len(two_xdps["attached"]) != 2,
+ "Wrong attached program count with two programs")
+ fail(two_xdps["attached"][0]["prog"]["id"] ==
+ two_xdps["attached"][1]["prog"]["id"],
+ "Offloaded and other programs have the same id")
+ fail(offloaded != offloaded2,
+ "Offload ID changed after loading other program")
+
+ start_test("Test multi-attachment XDP - replace...")
+ ret, _, err = sim.set_xdp(obj, "offload", fail=False, include_stderr=True)
+ fail(ret == 0, "Replaced one of programs without -force")
+ check_extack(err, "XDP program already attached.", args)
+
+ if modename == "" or modename == "drv":
+ othermode = "" if modename == "drv" else "drv"
+ start_test("Test multi-attachment XDP - detach...")
+ ret, _, err = sim.unset_xdp(othermode, force=True,
+ fail=False, include_stderr=True)
+ fail(ret == 0, "Removed program with a bad mode")
+ check_extack(err, "program loaded with different flags.", args)
+
+ sim.unset_xdp("offload")
+ xdp = sim.ip_link_show(xdp=True)["xdp"]
+ offloaded = sim.dfs_read("bpf_offloaded_id")
+
+ fail(xdp["mode"] != modeid, "Bad mode reported after multiple programs")
+ fail("prog" not in xdp,
+ "Base program not reported after multi program mode")
+ fail(xdp["attached"][0] not in two_xdps["attached"],
+ "Offload program not reported after other activated")
+ fail(len(xdp["attached"]) != 1,
+ "Wrong attached program count with remaining programs")
+ fail(offloaded != "0", "Offload ID reported with only other program left")
+
+ start_test("Test multi-attachment XDP - device remove...")
+ sim.set_xdp(obj, "offload")
+ sim.remove()
+
+ sim = NetdevSim()
+ sim.set_ethtool_tc_offloads(True)
+ return sim
# Parse command line
parser = argparse.ArgumentParser()
@@ -936,60 +995,9 @@ netns = []
rm(pin_file)
bpftool_prog_list_wait(expected=0)
- start_test("Test multi-attachment XDP - attach...")
- sim.set_xdp(obj, "offload")
- xdp = sim.ip_link_show(xdp=True)["xdp"]
- offloaded = sim.dfs_read("bpf_offloaded_id")
- fail("prog" not in xdp, "Base program not reported in single program mode")
- fail(len(ipl["xdp"]["attached"]) != 1,
- "Wrong attached program count with one program")
-
- sim.set_xdp(obj, "")
- two_xdps = sim.ip_link_show(xdp=True)["xdp"]
- offloaded2 = sim.dfs_read("bpf_offloaded_id")
-
- fail(two_xdps["mode"] != 4, "Bad mode reported with multiple programs")
- fail("prog" in two_xdps, "Base program reported in multi program mode")
- fail(xdp["attached"][0] not in two_xdps["attached"],
- "Offload program not reported after driver activated")
- fail(len(two_xdps["attached"]) != 2,
- "Wrong attached program count with two programs")
- fail(two_xdps["attached"][0]["prog"]["id"] ==
- two_xdps["attached"][1]["prog"]["id"],
- "offloaded and drv programs have the same id")
- fail(offloaded != offloaded2,
- "offload ID changed after loading driver program")
-
- start_test("Test multi-attachment XDP - replace...")
- ret, _, err = sim.set_xdp(obj, "offload", fail=False, include_stderr=True)
- fail(ret == 0, "Replaced one of programs without -force")
- check_extack(err, "XDP program already attached.", args)
-
- start_test("Test multi-attachment XDP - detach...")
- ret, _, err = sim.unset_xdp("drv", force=True,
- fail=False, include_stderr=True)
- fail(ret == 0, "Removed program with a bad mode")
- check_extack(err, "program loaded with different flags.", args)
-
- sim.unset_xdp("offload")
- xdp = sim.ip_link_show(xdp=True)["xdp"]
- offloaded = sim.dfs_read("bpf_offloaded_id")
-
- fail(xdp["mode"] != 1, "Bad mode reported after multiple programs")
- fail("prog" not in xdp,
- "Base program not reported after multi program mode")
- fail(xdp["attached"][0] not in two_xdps["attached"],
- "Offload program not reported after driver activated")
- fail(len(ipl["xdp"]["attached"]) != 1,
- "Wrong attached program count with remaining programs")
- fail(offloaded != "0", "offload ID reported with only driver program left")
-
- start_test("Test multi-attachment XDP - device remove...")
- sim.set_xdp(obj, "offload")
- sim.remove()
-
- sim = NetdevSim()
- sim.set_ethtool_tc_offloads(True)
+ sim = test_multi_prog(sim, obj, "", 1)
+ sim = test_multi_prog(sim, obj, "drv", 1)
+ sim = test_multi_prog(sim, obj, "generic", 2)
start_test("Test mixing of TC and XDP...")
sim.tc_add_ingress()
--
2.19.2
^ permalink raw reply related
* [PATCH bpf-next 3/5] selftests/bpf: print traceback when test fails
From: Jakub Kicinski @ 2019-02-06 4:03 UTC (permalink / raw)
To: alexei.starovoitov, daniel; +Cc: netdev, oss-drivers, Jakub Kicinski
In-Reply-To: <20190206040324.22109-1-jakub.kicinski@netronome.com>
Figuring out which exact check in test_offload.py takes more
time than it should. Print the traceback (to the screen and
the logs).
Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Reviewed-by: Quentin Monnet <quentin.monnet@netronome.com>
---
tools/testing/selftests/bpf/test_offload.py | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/tools/testing/selftests/bpf/test_offload.py b/tools/testing/selftests/bpf/test_offload.py
index a564d1a5a1b8..c379b36a5443 100755
--- a/tools/testing/selftests/bpf/test_offload.py
+++ b/tools/testing/selftests/bpf/test_offload.py
@@ -23,6 +23,7 @@ import string
import struct
import subprocess
import time
+import traceback
logfile = None
log_level = 1
@@ -78,7 +79,9 @@ netns = [] # net namespaces to be removed
if not cond:
return
print("FAIL: " + msg)
- log("FAIL: " + msg, "", level=1)
+ tb = "".join(traceback.extract_stack().format())
+ print(tb)
+ log("FAIL: " + msg, tb, level=1)
os.sys.exit(1)
def start_test(msg):
--
2.19.2
^ permalink raw reply related
* [PATCH bpf-next 2/5] net: xdp: allow generic and driver XDP on one interface
From: Jakub Kicinski @ 2019-02-06 4:03 UTC (permalink / raw)
To: alexei.starovoitov, daniel; +Cc: netdev, oss-drivers, Jakub Kicinski
In-Reply-To: <20190206040324.22109-1-jakub.kicinski@netronome.com>
Since commit a25717d2b604 ("xdp: support simultaneous driver and
hw XDP attachment") users can load an XDP program for offload and
in native driver mode simultaneously. Allow a similar mix of
offload and SKB mode/generic XDP.
Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Reviewed-by: Quentin Monnet <quentin.monnet@netronome.com>
---
net/core/dev.c | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/net/core/dev.c b/net/core/dev.c
index bfa4be42afff..78c3b48392e1 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -7976,11 +7976,13 @@ int dev_change_xdp_fd(struct net_device *dev, struct netlink_ext_ack *extack,
enum bpf_netdev_command query;
struct bpf_prog *prog = NULL;
bpf_op_t bpf_op, bpf_chk;
+ bool offload;
int err;
ASSERT_RTNL();
- query = flags & XDP_FLAGS_HW_MODE ? XDP_QUERY_PROG_HW : XDP_QUERY_PROG;
+ offload = flags & XDP_FLAGS_HW_MODE;
+ query = offload ? XDP_QUERY_PROG_HW : XDP_QUERY_PROG;
bpf_op = bpf_chk = ops->ndo_bpf;
if (!bpf_op && (flags & (XDP_FLAGS_DRV_MODE | XDP_FLAGS_HW_MODE))) {
@@ -7993,8 +7995,7 @@ int dev_change_xdp_fd(struct net_device *dev, struct netlink_ext_ack *extack,
bpf_chk = generic_xdp_install;
if (fd >= 0) {
- if (__dev_xdp_query(dev, bpf_chk, XDP_QUERY_PROG) ||
- __dev_xdp_query(dev, bpf_chk, XDP_QUERY_PROG_HW)) {
+ if (!offload && __dev_xdp_query(dev, bpf_chk, XDP_QUERY_PROG)) {
NL_SET_ERR_MSG(extack, "native and generic XDP can't be active at the same time");
return -EEXIST;
}
@@ -8009,8 +8010,7 @@ int dev_change_xdp_fd(struct net_device *dev, struct netlink_ext_ack *extack,
if (IS_ERR(prog))
return PTR_ERR(prog);
- if (!(flags & XDP_FLAGS_HW_MODE) &&
- bpf_prog_is_dev_bound(prog->aux)) {
+ if (!offload && bpf_prog_is_dev_bound(prog->aux)) {
NL_SET_ERR_MSG(extack, "using device-bound program without HW_MODE flag is not supported");
bpf_prog_put(prog);
return -EINVAL;
--
2.19.2
^ permalink raw reply related
* [PATCH bpf-next 1/5] selftests/bpf: fix the expected messages
From: Jakub Kicinski @ 2019-02-06 4:03 UTC (permalink / raw)
To: alexei.starovoitov, daniel; +Cc: netdev, oss-drivers, Jakub Kicinski
In-Reply-To: <20190206040324.22109-1-jakub.kicinski@netronome.com>
Recent changes added extack to program replacement path,
expect extack instead of generic messages.
Fixes: 01dde20ce04b ("xdp: Provide extack messages when prog attachment failed")
Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
---
tools/testing/selftests/bpf/test_offload.py | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/tools/testing/selftests/bpf/test_offload.py b/tools/testing/selftests/bpf/test_offload.py
index d59642e70f56..a564d1a5a1b8 100755
--- a/tools/testing/selftests/bpf/test_offload.py
+++ b/tools/testing/selftests/bpf/test_offload.py
@@ -842,7 +842,9 @@ netns = []
ret, _, err = sim.set_xdp(obj, "generic", force=True,
fail=False, include_stderr=True)
fail(ret == 0, "Replaced XDP program with a program in different mode")
- fail(err.count("File exists") != 1, "Replaced driver XDP with generic")
+ check_extack(err,
+ "native and generic XDP can't be active at the same time.",
+ args)
ret, _, err = sim.set_xdp(obj, "", force=True,
fail=False, include_stderr=True)
fail(ret == 0, "Replaced XDP program with a program in different mode")
@@ -957,7 +959,8 @@ netns = []
start_test("Test multi-attachment XDP - replace...")
ret, _, err = sim.set_xdp(obj, "offload", fail=False, include_stderr=True)
- fail(err.count("busy") != 1, "Replaced one of programs without -force")
+ fail(ret == 0, "Replaced one of programs without -force")
+ check_extack(err, "XDP program already attached.", args)
start_test("Test multi-attachment XDP - detach...")
ret, _, err = sim.unset_xdp("drv", force=True,
--
2.19.2
^ permalink raw reply related
* [PATCH bpf-next 0/5] net: xdp: allow offload to coexist with generic
From: Jakub Kicinski @ 2019-02-06 4:03 UTC (permalink / raw)
To: alexei.starovoitov, daniel; +Cc: netdev, oss-drivers, Jakub Kicinski
Hi!
Offloaded and native/driver XDP programs can already coexist.
Allow offload and generic hook to coexist as well, there seem
to be no reason why not to do so.
Jakub Kicinski (5):
selftests/bpf: fix the expected messages
net: xdp: allow generic and driver XDP on one interface
selftests/bpf: print traceback when test fails
selftests/bpf: add test for mixing generic and offload XDP
selftests/bpf: test reading the offloaded program
net/core/dev.c | 10 +-
tools/testing/selftests/bpf/test_offload.py | 135 ++++++++++++--------
2 files changed, 85 insertions(+), 60 deletions(-)
--
2.19.2
^ permalink raw reply
* RE: [PATCH v2] arm64: dts: lx2160aqds: Add mdio mux nodes
From: Pankaj Bansal @ 2019-02-06 4:01 UTC (permalink / raw)
To: Leo Li
Cc: Shawn Guo, Andrew Lunn, Florian Fainelli, netdev@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <CADRPPNSnPoEwUFKK0=FE9RG9QfTUPKoTXkZPVEpskC13mD-R2A@mail.gmail.com>
> -----Original Message-----
> From: Li Yang [mailto:leoyang.li@nxp.com]
> Sent: Wednesday, 6 February, 2019 12:07 AM
> To: Pankaj Bansal <pankaj.bansal@nxp.com>
> Cc: Shawn Guo <shawnguo@kernel.org>; Andrew Lunn <andrew@lunn.ch>;
> Florian Fainelli <f.fainelli@gmail.com>; netdev@vger.kernel.org; linux-arm-
> kernel@lists.infradead.org
> Subject: Re: [PATCH v2] arm64: dts: lx2160aqds: Add mdio mux nodes
>
> On Mon, Feb 4, 2019 at 2:53 AM Pankaj Bansal <pankaj.bansal@nxp.com>
> wrote:
> >
> > The two external MDIO buses used to communicate with phy devices that
> > are external to SOC are muxed in LX2160AQDS board.
> >
> > These buses can be routed to any one of the eight IO slots on
> > LX2160AQDS board depending on value in fpga register 0x54.
> >
> > Additionally the external MDIO1 is used to communicate to the onboard
> > RGMII phy devices.
> >
> > The mdio1 is controlled by bits 4-7 of fpga register and mdio2 is
> > controlled by bits 0-3 of fpga register.
> >
> > Signed-off-by: Pankaj Bansal <pankaj.bansal@nxp.com>
> > ---
> >
> > Notes:
> > V2:
> > - removed unnecassary TODO statements
> > - removed device_type from mdio nodes
> > - change the case of hex number to lowercase
> > - removed board specific comments from soc file
>
> There are still some comments from V1 haven't been addressed.
>
> >
> > .../boot/dts/freescale/fsl-lx2160a-qds.dts | 115 +++++++++++++++++
> > .../boot/dts/freescale/fsl-lx2160a.dtsi | 18 +++
> > 2 files changed, 133 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/freescale/fsl-lx2160a-qds.dts
> > b/arch/arm64/boot/dts/freescale/fsl-lx2160a-qds.dts
> > index 99a22abbe725..2c3020a72d41 100644
> > --- a/arch/arm64/boot/dts/freescale/fsl-lx2160a-qds.dts
> > +++ b/arch/arm64/boot/dts/freescale/fsl-lx2160a-qds.dts
> > @@ -46,6 +46,121 @@
> > &i2c0 {
> > status = "okay";
> >
> > + fpga@66 {
> > + compatible = "fsl,lx2160aqds-fpga", "fsl,fpga-qixis-i2c";
> > + reg = <0x66>;
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + mdio-mux-1@54 {
>
> Still no compatible string defined for the node. Probably should be "mdio-mux-
> mmioreg", "mdio-mux"
it is not a specific device. MDIO mux is meant to be controlled by some registers of parent device (FPGA).
Therefore, IMO this should not be a device and there should not be any "compatible" property for it.
>
> > + mdio-parent-bus = <&emdio1>;
> > + reg = <0x54>; /* BRDCFG4 */
> > + mux-mask = <0xf8>; /* EMI1_MDIO */
> > + #address-cells=<1>;
> > + #size-cells = <0>;
> > +
> > + mdio@0 {
> > + reg = <0x00>;
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + };
> > + mdio@40 {
> > + reg = <0x40>;
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + };
> > + mdio@c0 {
> > + reg = <0xc0>;
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + };
> > + mdio@c8 {
> > + reg = <0xc8>;
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + };
> > + mdio@d0 {
> > + reg = <0xd0>;
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + };
> > + mdio@d8 {
> > + reg = <0xd8>;
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + };
> > + mdio@e0 {
> > + reg = <0xe0>;
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + };
> > + mdio@e8 {
> > + reg = <0xe8>;
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + };
> > + mdio@f0 {
> > + reg = <0xf0>;
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + };
> > + mdio@f8 {
> > + reg = <0xf8>;
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + };
> > + };
> > +
> > + mdio-mux-2@54 {
> > + mdio-parent-bus = <&emdio2>;
> > + reg = <0x54>; /* BRDCFG4 */
> > + mux-mask = <0x07>; /* EMI2_MDIO */
> > + #address-cells=<1>;
> > + #size-cells = <0>;
> > +
> > + mdio@0 {
> > + reg = <0x00>;
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + };
> > + mdio@1 {
> > + reg = <0x01>;
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + };
> > + mdio@2 {
> > + reg = <0x02>;
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + };
> > + mdio@3 {
> > + reg = <0x03>;
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + };
> > + mdio@4 {
> > + reg = <0x04>;
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + };
> > + mdio@5 {
> > + reg = <0x05>;
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + };
> > + mdio@6 {
> > + reg = <0x06>;
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + };
> > + mdio@7 {
> > + reg = <0x07>;
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + };
> > + };
> > + };
> > +
> > i2c-mux@77 {
> > compatible = "nxp,pca9547";
> > reg = <0x77>;
> > diff --git a/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi
> > b/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi
> > index a79f5c1ea56d..a74045ad22ad 100644
> > --- a/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi
> > +++ b/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi
> > @@ -762,5 +762,23 @@
> > <GIC_SPI 209 IRQ_TYPE_LEVEL_HIGH>;
> > dma-coherent;
> > };
> > +
> > + /* WRIOP0: 0x8b8_0000, E-MDIO1: 0x1_6000 */
> > + emdio1: mdio@8b96000 {
> > + compatible = "fsl,fman-memac-mdio";
> > + reg = <0x0 0x8b96000 0x0 0x1000>;
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + little-endian; /* force the driver in LE mode
> > + */
>
> Still doesn't fully align with the binding at
> "Documentation/devicetree/bindings/powerpc/fsl/fman.txt".
>
> It should either have the "interrupts" property for external MDIO or "fsl,fman-
> internal-mdio" for internal MDIO.
I see that for DPAA1 based SOCs, there was definitely an interrupt property in external MDIO node.
BUT, for DPAA2 based devices none of the SOC has this property. I am looking further into this.
>
> > + };
> > +
> > + /* WRIOP0: 0x8b8_0000, E-MDIO2: 0x1_7000 */
> > + emdio2: mdio@8b97000 {
> > + compatible = "fsl,fman-memac-mdio";
> > + reg = <0x0 0x8b97000 0x0 0x1000>;
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + little-endian; /* force the driver in LE mode */
> > + };
> > };
> > };
> > --
> > 2.17.1
> >
^ permalink raw reply
* Re: [RFC bpf-next 0/7] net: flow_dissector: trigger BPF hook when called from eth_get_headlen
From: Stanislav Fomichev @ 2019-02-06 3:56 UTC (permalink / raw)
To: Alexei Starovoitov
Cc: Willem de Bruijn, Stanislav Fomichev, Network Development,
David Miller, Alexei Starovoitov, Daniel Borkmann, simon.horman,
Willem de Bruijn
In-Reply-To: <20190206031215.qldeh7pfgqr3frg3@ast-mbp>
On 02/05, Alexei Starovoitov wrote:
> On Tue, Feb 05, 2019 at 04:59:31PM -0800, Stanislav Fomichev wrote:
> > On 02/05, Alexei Starovoitov wrote:
> > > On Tue, Feb 05, 2019 at 12:40:03PM -0800, Stanislav Fomichev wrote:
> > > > On 02/05, Willem de Bruijn wrote:
> > > > > On Tue, Feb 5, 2019 at 12:57 PM Stanislav Fomichev <sdf@google.com> wrote:
> > > > > >
> > > > > > Currently, when eth_get_headlen calls flow dissector, it doesn't pass any
> > > > > > skb. Because we use passed skb to lookup associated networking namespace
> > > > > > to find whether we have a BPF program attached or not, we always use
> > > > > > C-based flow dissector in this case.
> > > > > >
> > > > > > The goal of this patch series is to add new networking namespace argument
> > > > > > to the eth_get_headlen and make BPF flow dissector programs be able to
> > > > > > work in the skb-less case.
> > > > > >
> > > > > > The series goes like this:
> > > > > > 1. introduce __init_skb and __init_skb_shinfo; those will be used to
> > > > > > initialize temporary skb
> > > > > > 2. introduce skb_net which can be used to get networking namespace
> > > > > > associated with an skb
> > > > > > 3. add new optional network namespace argument to __skb_flow_dissect and
> > > > > > plumb through the callers
> > > > > > 4. add new __flow_bpf_dissect which constructs temporary on-stack skb
> > > > > > (using __init_skb) and calls BPF flow dissector program
> > > > >
> > > > > The main concern I see with this series is this cost of skb zeroing
> > > > > for every packet in the device driver receive routine, *independent*
> > > > > from the real skb allocation and zeroing which will likely happen
> > > > > later.
> > > > Yes, plus ~200 bytes on the stack for the callers.
> > > >
> > > > Not sure how visible this zeroing though, I can probably try to get some
> > > > numbers from BPF_PROG_TEST_RUN (running current version vs running with
> > > > on-stack skb).
> > >
> > > imo extra 256 byte memset for every packet is non starter.
> > We can put pre-allocated/initialized skbs without data into percpu or even
> > use pcpu_freelist_pop/pcpu_freelist_push to make sure we don't have to think
> > about having multiple percpu for irq/softirq/process contexts.
> > Any concerns with that approach?
> > Any other possible concerns with the overall series?
>
> I'm missing why the whole thing is needed.
> You're saying:
> " make BPF flow dissector programs be able to work in the skb-less case".
> What does it mean specifically?
> The only non-skb case is XDP.
> Are you saying you want flow_dissector prog to be run in XDP?
eth_get_headlen that drivers call on RX path on a chunk of data to
guesstimate the length of the headers calls flow dissector without an skb
(__skb_flow_dissect was a weird interface where it accepts skb or
data+len). Right now, there is no way to trigger BPF flow dissector
for this case (we don't have an skb to get associated namespace/etc/etc).
The patch series tries to fix that to make sure that we always trigger
BPF program if it's attached to a device's namespace.
Context:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=2ba38943ba190eb6a494262003e23187d1b40fb4
^ permalink raw reply
* Re: Pull patches from tip/perf/core to bpf-next
From: Alexei Starovoitov @ 2019-02-06 3:47 UTC (permalink / raw)
To: Song Liu; +Cc: Daniel Borkmann, Alexei Starovoitov, Kernel Team, Netdev
In-Reply-To: <A6EB5CAD-BF0B-4C8C-8BD8-9703DFE7E0C7@fb.com>
On Wed, Feb 06, 2019 at 03:44:29AM +0000, Song Liu wrote:
>
>
> > On Feb 5, 2019, at 7:36 PM, Alexei Starovoitov <alexei.starovoitov@gmail.com> wrote:
> >
> > On Tue, Feb 05, 2019 at 10:47:06PM +0000, Song Liu wrote:
> >> Hi Alexei and Daniel,
> >>
> >> The following patches are required for BPF introspection in perf tools.
> >> Please pull them to bpf-next, so that we get all the dependencies in one
> >> tree.
> >>
> >> Thanks,
> >> Song
> >>
> >> (from 1/10 to 10/10)
> >> 76193a94522f perf, bpf: Introduce PERF_RECORD_KSYMBOL
> >> d764ac646491 tools headers uapi: Sync tools/include/uapi/linux/perf_event.h
> >> 6ee52e2a3fe4 perf, bpf: Introduce PERF_RECORD_BPF_EVENT
> >> df063c83aa2c tools headers uapi: Sync tools/include/uapi/linux/perf_event.h
> >> 9aa0bfa370b2 perf tools: Handle PERF_RECORD_KSYMBOL
> >> 45178a928a4b perf tools: Handle PERF_RECORD_BPF_EVENT
> >> 7b612e291a5a perf tools: Synthesize PERF_RECORD_* for loaded BPF programs
> >> a40b95bcd30c perf top: Synthesize BPF events for pre-existing loaded BPF programs
> >> 6934058d9fb6 bpf: Add module name [bpf] to ksymbols for bpf programs
> >> 811184fb6977 perf bpf: Fix synthesized PERF_RECORD_KSYMBOL/BPF_EVENT
> >
> > yes. we can certainly do that.
> > Do you have bpf specific patches that depend on that ?
> > Since it's rc5 already. Are you planning to send them within next week?
>
> BPF introspection work depends on these patches. I have been hopping
> between perf tree and bpf-next tree. I think basing the series up on
> bpf-next plus these patches leads least conflicts.
>
> I do plan to send the series within next week.
>
> On a second thought, maybe I should send based on perf tree, and worry
> about the conflicts later? It is really heavier on perf side.
whichever way is easier.
if bpf-next is the best use that as a base with above patches.
Once your set gets Acks from perf folks we can push above patches
from tip first and then apply your set.
^ permalink raw reply
* Re: Pull patches from tip/perf/core to bpf-next
From: Song Liu @ 2019-02-06 3:44 UTC (permalink / raw)
To: Alexei Starovoitov
Cc: Daniel Borkmann, Alexei Starovoitov, Kernel Team, Netdev
In-Reply-To: <20190206033600.6terh4xgozy5r3hs@ast-mbp>
> On Feb 5, 2019, at 7:36 PM, Alexei Starovoitov <alexei.starovoitov@gmail.com> wrote:
>
> On Tue, Feb 05, 2019 at 10:47:06PM +0000, Song Liu wrote:
>> Hi Alexei and Daniel,
>>
>> The following patches are required for BPF introspection in perf tools.
>> Please pull them to bpf-next, so that we get all the dependencies in one
>> tree.
>>
>> Thanks,
>> Song
>>
>> (from 1/10 to 10/10)
>> 76193a94522f perf, bpf: Introduce PERF_RECORD_KSYMBOL
>> d764ac646491 tools headers uapi: Sync tools/include/uapi/linux/perf_event.h
>> 6ee52e2a3fe4 perf, bpf: Introduce PERF_RECORD_BPF_EVENT
>> df063c83aa2c tools headers uapi: Sync tools/include/uapi/linux/perf_event.h
>> 9aa0bfa370b2 perf tools: Handle PERF_RECORD_KSYMBOL
>> 45178a928a4b perf tools: Handle PERF_RECORD_BPF_EVENT
>> 7b612e291a5a perf tools: Synthesize PERF_RECORD_* for loaded BPF programs
>> a40b95bcd30c perf top: Synthesize BPF events for pre-existing loaded BPF programs
>> 6934058d9fb6 bpf: Add module name [bpf] to ksymbols for bpf programs
>> 811184fb6977 perf bpf: Fix synthesized PERF_RECORD_KSYMBOL/BPF_EVENT
>
> yes. we can certainly do that.
> Do you have bpf specific patches that depend on that ?
> Since it's rc5 already. Are you planning to send them within next week?
BPF introspection work depends on these patches. I have been hopping
between perf tree and bpf-next tree. I think basing the series up on
bpf-next plus these patches leads least conflicts.
I do plan to send the series within next week.
On a second thought, maybe I should send based on perf tree, and worry
about the conflicts later? It is really heavier on perf side.
Thanks,
Song
^ permalink raw reply
* Re: KASAN: use-after-free Read in __wake_up_common_lock
From: Eric Dumazet @ 2019-02-06 3:42 UTC (permalink / raw)
To: Dmitry Vyukov, syzbot, Eric Dumazet
Cc: Karsten Keil, LKML, netdev, syzkaller-bugs
In-Reply-To: <CACT4Y+YOTSY=ZVw882tfDDPZ6Y5ZSX6HHn2M=Q2uTxjUtjb9=w@mail.gmail.com>
On 02/05/2019 07:28 PM, Dmitry Vyukov wrote:
> On Wed, Jan 30, 2019 at 10:02 PM syzbot
> <syzbot+fb065bc06d3d4054be6f@syzkaller.appspotmail.com> wrote:
>>
>> Hello,
>>
>> syzbot found the following crash on:
>>
>> HEAD commit: 62967898789d Merge git://git.kernel.org/pub/scm/linux/kern..
>> git tree: upstream
>> console output: https://syzkaller.appspot.com/x/log.txt?x=10f0bf08c00000
>> kernel config: https://syzkaller.appspot.com/x/.config?x=4fceea9e2d99ac20
>> dashboard link: https://syzkaller.appspot.com/bug?extid=fb065bc06d3d4054be6f
>> compiler: gcc (GCC) 9.0.0 20181231 (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+fb065bc06d3d4054be6f@syzkaller.appspotmail.com
>
> I assume this is also fixed by:
>
> #syz fix: mISDN: fix a race in dev_expire_timer()
Yes this looks very probable, thanks.
^ permalink raw reply
* Request for Quotation
From: Sasha Kelley @ 2019-02-06 12:33 UTC (permalink / raw)
To: netdev
Nice day to you!
My Names Sasha Kelley from Earthlink, Inc. Moscow Russia
There is an available invitation to tender suitable for your
products and I would like to inquire if your company will be
interested to submit offer for your products in Moscow Russia.
Please confirm interest by sending product catalog/price list
for
our review.
Looking forward to hearing from you.
Best Regards,
Area Manager
Sasha Kelley
Tel: +79017731031
E-mail: earthlink@zoho.com
Earthlink, Inc (Moscow).
^ permalink raw reply
* Re: [PATCH bpf-next 2/4] bpf: fix lockdep false positive in stackmap
From: Eric Dumazet @ 2019-02-06 3:40 UTC (permalink / raw)
To: Alexei Starovoitov
Cc: Waiman Long, Peter Zijlstra, Alexei Starovoitov, davem, daniel,
edumazet, jannh, netdev, kernel-team, songliubraving
In-Reply-To: <20190206033001.bkyliw2j3tnxzc3j@ast-mbp>
On 02/05/2019 07:30 PM, Alexei Starovoitov wrote:
> Thanks for the reminder :)
>
> I've been waiting for Peter's direction on this one.
> Happy to fix it whichever way.
>
> To recap:
> Approach 1:
> s/up_read/up_read_non_owner/ from irq_work + rwsem_release as Longman proposed.
>
> Apporach 2:
> introduce down_read_trylock_non_owner and pair it with up_read_non_owner
> in both irq_work and normal.
>
> My preference is 1. I think Longman's as well.
>
Unless we envision other uses for down_read_trylock_non_owner() and up_read_non_owner(),
I agree 1) seems good enough, at least for the short term.
Thanks !
^ permalink raw reply
* Re: Pull patches from tip/perf/core to bpf-next
From: Alexei Starovoitov @ 2019-02-06 3:36 UTC (permalink / raw)
To: Song Liu; +Cc: Daniel Borkmann, Alexei Starovoitov, Kernel Team, Netdev
In-Reply-To: <545C47EB-4D9A-46A5-892B-D4DDB88AFFDD@fb.com>
On Tue, Feb 05, 2019 at 10:47:06PM +0000, Song Liu wrote:
> Hi Alexei and Daniel,
>
> The following patches are required for BPF introspection in perf tools.
> Please pull them to bpf-next, so that we get all the dependencies in one
> tree.
>
> Thanks,
> Song
>
> (from 1/10 to 10/10)
> 76193a94522f perf, bpf: Introduce PERF_RECORD_KSYMBOL
> d764ac646491 tools headers uapi: Sync tools/include/uapi/linux/perf_event.h
> 6ee52e2a3fe4 perf, bpf: Introduce PERF_RECORD_BPF_EVENT
> df063c83aa2c tools headers uapi: Sync tools/include/uapi/linux/perf_event.h
> 9aa0bfa370b2 perf tools: Handle PERF_RECORD_KSYMBOL
> 45178a928a4b perf tools: Handle PERF_RECORD_BPF_EVENT
> 7b612e291a5a perf tools: Synthesize PERF_RECORD_* for loaded BPF programs
> a40b95bcd30c perf top: Synthesize BPF events for pre-existing loaded BPF programs
> 6934058d9fb6 bpf: Add module name [bpf] to ksymbols for bpf programs
> 811184fb6977 perf bpf: Fix synthesized PERF_RECORD_KSYMBOL/BPF_EVENT
yes. we can certainly do that.
Do you have bpf specific patches that depend on that ?
Since it's rc5 already. Are you planning to send them within next week?
^ permalink raw reply
* Re: [PATCH v3 2/2] netdev/phy: add MDIO bus multiplexer driven by a regmap
From: Florian Fainelli @ 2019-02-05 5:14 UTC (permalink / raw)
To: Pankaj Bansal, Andrew Lunn; +Cc: netdev@vger.kernel.org
In-Reply-To: <20190205153014.3807-3-pankaj.bansal@nxp.com>
On 2/5/19 2:05 AM, Pankaj Bansal wrote:
> Add support for an MDIO bus multiplexer controlled by a regmap
> device, like an FPGA.
>
> Tested on a NXP LX2160AQDS board which uses the "QIXIS" FPGA
> attached to the i2c bus.
>
> Signed-off-by: Pankaj Bansal <pankaj.bansal@nxp.com>
With Andrew's comment fixed:
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
--
Florian
^ permalink raw reply
* Re: [PATCH bpf-next 2/4] bpf: fix lockdep false positive in stackmap
From: Alexei Starovoitov @ 2019-02-06 3:30 UTC (permalink / raw)
To: Eric Dumazet
Cc: Waiman Long, Peter Zijlstra, Alexei Starovoitov, davem, daniel,
edumazet, jannh, netdev, kernel-team, songliubraving
In-Reply-To: <510d3bb7-5ec0-e281-aabc-a3d379475d71@gmail.com>
On Tue, Feb 05, 2019 at 07:21:08PM -0800, Eric Dumazet wrote:
> >>>
> >>> diff --git a/kernel/bpf/stackmap.c b/kernel/bpf/stackmap.c
> >>> index d43b145..79eef9d 100644
> >>> --- a/kernel/bpf/stackmap.c
> >>> +++ b/kernel/bpf/stackmap.c
> >>> @@ -338,6 +338,13 @@ static void stack_map_get_build_id_offset(struct
> >>> bpf_stack_
> >>> } else {
> >>> work->sem = ¤t->mm->mmap_sem;
> >>> irq_work_queue(&work->irq_work);
> >>> +
> >>> + /*
> >>> + * The irq_work will release the mmap_sem with
> >>> + * up_read_non_owner(). The rwsem_release() is called
> >>> + * here to release the lock from lockdep's perspective.
> >>> + */
> >>> + rwsem_release(¤t->mm->mmap_sem.dep_map, 1, _RET_IP_);
> >> are you saying the above is enough coupled with up_read_non_owner?
> >> Looking at how amdgpu is using this api... I think they just use non_owner
> >> version when doing things from different task.
> >> So I don't think pairing non_owner with non_owner is strictly necessary.
> >> It seems fine to use down_read_trylock() with above rwsem_release() hack
> >> plus up_read_non_owner().
> >> Am I missing something?
> >>
> > The statement above is to clear the state for the lockdep so that it
> > knows that the task no longer owns the lock. Without doing that, there
> > is a possibility of some other kind of incorrect lockdep warning may be
> > produced because the code will still think the task hold a read-lock on
> > the mmap_sem. It is also possible no warning will be reported.
> >
> > The bpf code is kind of special that it acquires the mmap_sem. Later on,
> > it either releases it itself (non-NMI) or request irq_work to release it
> > (NMI). So either, you use the _non_owner versions for both acquire and
> > release or fake the release like the code segment above.
> >
> > Peter, please chime in if you have other suggestion.
> >
>
> Hi guys
>
> What are the plans to address the issue then ?
> Latest net tree exhibits this trace :
Thanks for the reminder :)
I've been waiting for Peter's direction on this one.
Happy to fix it whichever way.
To recap:
Approach 1:
s/up_read/up_read_non_owner/ from irq_work + rwsem_release as Longman proposed.
Apporach 2:
introduce down_read_trylock_non_owner and pair it with up_read_non_owner
in both irq_work and normal.
My preference is 1. I think Longman's as well.
^ permalink raw reply
* Re: KASAN: use-after-free Read in __wake_up_common_lock
From: Dmitry Vyukov @ 2019-02-06 3:28 UTC (permalink / raw)
To: syzbot, Eric Dumazet; +Cc: Karsten Keil, LKML, netdev, syzkaller-bugs
In-Reply-To: <000000000000c2e17f0580b3387c@google.com>
On Wed, Jan 30, 2019 at 10:02 PM syzbot
<syzbot+fb065bc06d3d4054be6f@syzkaller.appspotmail.com> wrote:
>
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit: 62967898789d Merge git://git.kernel.org/pub/scm/linux/kern..
> git tree: upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=10f0bf08c00000
> kernel config: https://syzkaller.appspot.com/x/.config?x=4fceea9e2d99ac20
> dashboard link: https://syzkaller.appspot.com/bug?extid=fb065bc06d3d4054be6f
> compiler: gcc (GCC) 9.0.0 20181231 (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+fb065bc06d3d4054be6f@syzkaller.appspotmail.com
I assume this is also fixed by:
#syz fix: mISDN: fix a race in dev_expire_timer()
> QAT: Invalid ioctl
> ==================================================================
> BUG: KASAN: use-after-free in debug_spin_lock_before
> kernel/locking/spinlock_debug.c:83 [inline]
> BUG: KASAN: use-after-free in do_raw_spin_lock+0x303/0x360
> kernel/locking/spinlock_debug.c:112
> Read of size 4 at addr ffff88808738e92c by task syz-executor1/8644
>
> CPU: 1 PID: 8644 Comm: syz-executor1 Not tainted 5.0.0-rc4+ #50
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> Call Trace:
> <IRQ>
> __dump_stack lib/dump_stack.c:77 [inline]
> dump_stack+0x1db/0x2d0 lib/dump_stack.c:113
> print_address_description.cold+0x7c/0x20d mm/kasan/report.c:187
> kasan_report.cold+0x1b/0x40 mm/kasan/report.c:317
> __asan_report_load4_noabort+0x14/0x20 mm/kasan/generic_report.c:134
> debug_spin_lock_before kernel/locking/spinlock_debug.c:83 [inline]
> do_raw_spin_lock+0x303/0x360 kernel/locking/spinlock_debug.c:112
> __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:117 [inline]
> _raw_spin_lock_irqsave+0x9d/0xcd kernel/locking/spinlock.c:152
> __wake_up_common_lock+0x19b/0x390 kernel/sched/wait.c:120
> __wake_up+0xe/0x10 kernel/sched/wait.c:145
> dev_expire_timer+0x14b/0x570 drivers/isdn/mISDN/timerdev.c:174
> call_timer_fn+0x254/0x900 kernel/time/timer.c:1325
> expire_timers kernel/time/timer.c:1362 [inline]
> __run_timers+0x6fc/0xd50 kernel/time/timer.c:1681
> IPVS: ftp: loaded support on port[0] = 21
> run_timer_softirq+0x52/0xb0 kernel/time/timer.c:1694
> __do_softirq+0x30b/0xb11 kernel/softirq.c:292
> invoke_softirq kernel/softirq.c:373 [inline]
> irq_exit+0x180/0x1d0 kernel/softirq.c:413
> exiting_irq arch/x86/include/asm/apic.h:536 [inline]
> smp_apic_timer_interrupt+0x1b7/0x760 arch/x86/kernel/apic/apic.c:1062
> apic_timer_interrupt+0xf/0x20 arch/x86/entry/entry_64.S:807
> </IRQ>
> RIP: 0010:arch_local_irq_restore arch/x86/include/asm/paravirt.h:766
> [inline]
> RIP: 0010:__raw_spin_unlock_irqrestore include/linux/spinlock_api_smp.h:160
> [inline]
> RIP: 0010:_raw_spin_unlock_irqrestore+0x95/0xe0
> kernel/locking/spinlock.c:184
> Code: 48 c7 c0 30 82 92 89 48 ba 00 00 00 00 00 fc ff df 48 c1 e8 03 80 3c
> 10 00 75 39 48 83 3d 12 d0 9d 01 00 74 24 48 89 df 57 9d <0f> 1f 44 00 00
> bf 01 00 00 00 e8 dc 75 63 f9 65 8b 05 95 3b 0d 78
> RSP: 0018:ffff888050a7f360 EFLAGS: 00000282 ORIG_RAX: ffffffffffffff13
> RAX: 1ffffffff1325046 RBX: 0000000000000282 RCX: 0000000000000000
> RDX: dffffc0000000000 RSI: 0000000000000001 RDI: 0000000000000282
> RBP: ffff888050a7f370 R08: ffff888088b9e000 R09: 0000000000000000
> R10: 0000000000000000 R11: 0000000000000000 R12: ffffffff8b72b128
> R13: ffff888088b9e000 R14: 00000000000d7480 R15: ffffffff8b72b128
> __debug_object_init+0x1c0/0x12d0 lib/debugobjects.c:418
> debug_object_init+0x16/0x20 lib/debugobjects.c:431
> __init_work+0x50/0x60 kernel/workqueue.c:504
> call_usermodehelper_setup+0x133/0x410 kernel/umh.c:389
> call_modprobe kernel/kmod.c:94 [inline]
> __request_module+0x4f5/0xeea kernel/kmod.c:171
> crypto_larval_lookup crypto/api.c:237 [inline]
> crypto_alg_mod_lookup+0x54e/0x6d0 crypto/api.c:280
> QAT: Invalid ioctl
> crypto_find_alg crypto/api.c:504 [inline]
> crypto_alloc_tfm+0xd9/0x2f0 crypto/api.c:537
> crypto_alloc_skcipher+0x2d/0x40 crypto/skcipher.c:945
> cryptd_alloc_skcipher+0x121/0x270 crypto/cryptd.c:1226
> IPVS: ftp: loaded support on port[0] = 21
> simd_skcipher_init+0x6c/0x1c0 crypto/simd.c:119
> crypto_skcipher_init_tfm+0x299/0x8c0 crypto/skcipher.c:862
> crypto_create_tfm+0xec/0x310 crypto/api.c:471
> crypto_alloc_tfm+0x104/0x2f0 crypto/api.c:543
> crypto_alloc_skcipher+0x2d/0x40 crypto/skcipher.c:945
> QAT: Invalid ioctl
> skcipher_bind+0x26/0x30 crypto/algif_skcipher.c:310
> alg_bind+0x25d/0x570 crypto/af_alg.c:183
> __sys_bind+0x30b/0x420 net/socket.c:1483
> __do_sys_bind net/socket.c:1494 [inline]
> __se_sys_bind net/socket.c:1492 [inline]
> __x64_sys_bind+0x73/0xb0 net/socket.c:1492
> do_syscall_64+0x1a3/0x800 arch/x86/entry/common.c:290
> entry_SYSCALL_64_after_hwframe+0x49/0xbe
> RIP: 0033:0x458089
> Code: 6d b7 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 3b b7 fb ff c3 66 2e 0f 1f 84 00 00 00 00
> RSP: 002b:00007f7508d5ac78 EFLAGS: 00000246 ORIG_RAX: 0000000000000031
> RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 0000000000458089
> RDX: 0000000000000058 RSI: 0000000020000340 RDI: 000000000000000a
> RBP: 000000000073bf00 R08: 0000000000000000 R09: 0000000000000000
> R10: 0000000000000000 R11: 0000000000000246 R12: 00007f7508d5b6d4
> R13: 00000000004be0ca R14: 00000000004ce420 R15: 00000000ffffffff
>
> Allocated by task 8647:
> save_stack+0x45/0xd0 mm/kasan/common.c:73
> set_track mm/kasan/common.c:85 [inline]
> __kasan_kmalloc mm/kasan/common.c:496 [inline]
> __kasan_kmalloc.constprop.0+0xcf/0xe0 mm/kasan/common.c:469
> kasan_kmalloc+0x9/0x10 mm/kasan/common.c:504
> kmem_cache_alloc_trace+0x151/0x760 mm/slab.c:3609
> kmalloc include/linux/slab.h:545 [inline]
> mISDN_open+0x104/0x3f0 drivers/isdn/mISDN/timerdev.c:59
> misc_open+0x398/0x4c0 drivers/char/misc.c:141
> chrdev_open+0x270/0x7c0 fs/char_dev.c:417
> do_dentry_open+0x48a/0x1210 fs/open.c:771
> vfs_open+0xa0/0xd0 fs/open.c:880
> do_last fs/namei.c:3418 [inline]
> path_openat+0x144f/0x5650 fs/namei.c:3534
> do_filp_open+0x26f/0x370 fs/namei.c:3564
> do_sys_open+0x59a/0x7c0 fs/open.c:1063
> __do_sys_openat fs/open.c:1090 [inline]
> __se_sys_openat fs/open.c:1084 [inline]
> __x64_sys_openat+0x9d/0x100 fs/open.c:1084
> do_syscall_64+0x1a3/0x800 arch/x86/entry/common.c:290
> entry_SYSCALL_64_after_hwframe+0x49/0xbe
>
> Freed by task 8649:
> save_stack+0x45/0xd0 mm/kasan/common.c:73
> set_track mm/kasan/common.c:85 [inline]
> __kasan_slab_free+0x102/0x150 mm/kasan/common.c:458
> kasan_slab_free+0xe/0x10 mm/kasan/common.c:466
> __cache_free mm/slab.c:3487 [inline]
> kfree+0xcf/0x230 mm/slab.c:3806
> mISDN_close+0x39b/0x530 drivers/isdn/mISDN/timerdev.c:97
> __fput+0x3c5/0xb10 fs/file_table.c:278
> ____fput+0x16/0x20 fs/file_table.c:309
> task_work_run+0x1f4/0x2b0 kernel/task_work.c:113
> tracehook_notify_resume include/linux/tracehook.h:188 [inline]
> exit_to_usermode_loop+0x32a/0x3b0 arch/x86/entry/common.c:166
> prepare_exit_to_usermode arch/x86/entry/common.c:197 [inline]
> syscall_return_slowpath arch/x86/entry/common.c:268 [inline]
> do_syscall_64+0x696/0x800 arch/x86/entry/common.c:293
> entry_SYSCALL_64_after_hwframe+0x49/0xbe
>
> The buggy address belongs to the object at ffff88808738e900
> which belongs to the cache kmalloc-192 of size 192
> The buggy address is located 44 bytes inside of
> 192-byte region [ffff88808738e900, ffff88808738e9c0)
> The buggy address belongs to the page:
> page:ffffea00021ce380 count:1 mapcount:0 mapping:ffff88812c3f0040 index:0x0
> flags: 0x1fffc0000000200(slab)
> raw: 01fffc0000000200 ffffea0002927088 ffffea000298ecc8 ffff88812c3f0040
> raw: 0000000000000000 ffff88808738e000 0000000100000010 0000000000000000
> page dumped because: kasan: bad access detected
>
> Memory state around the buggy address:
> ffff88808738e800: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> ffff88808738e880: 00 00 fc fc fc fc fc fc fc fc fc fc fc fc fc fc
> > ffff88808738e900: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> ^
> ffff88808738e980: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc
> ffff88808738ea00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> ==================================================================
>
>
> ---
> This bug is generated by a bot. It may contain errors.
> See https://goo.gl/tpsmEJ for more information about syzbot.
> syzbot engineers can be reached at syzkaller@googlegroups.com.
>
> syzbot will keep track of this bug report. See:
> https://goo.gl/tpsmEJ#bug-status-tracking for how to communicate with
> syzbot.
>
> --
> You received this message because you are subscribed to the Google Groups "syzkaller-bugs" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to syzkaller-bugs+unsubscribe@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/syzkaller-bugs/000000000000c2e17f0580b3387c%40google.com.
> For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply
* Re: [PATCH bpf-next 2/4] bpf: fix lockdep false positive in stackmap
From: Eric Dumazet @ 2019-02-06 3:21 UTC (permalink / raw)
To: Waiman Long, Alexei Starovoitov
Cc: Peter Zijlstra, Alexei Starovoitov, davem, daniel, edumazet,
jannh, netdev, kernel-team
In-Reply-To: <e7748be1-8b0b-6613-159f-1c45f932c617@redhat.com>
On 01/30/2019 06:48 PM, Waiman Long wrote:
> On 01/30/2019 09:01 PM, Alexei Starovoitov wrote:
>> On Wed, Jan 30, 2019 at 04:32:12PM -0500, Waiman Long wrote:
>>> On 01/30/2019 04:11 PM, Waiman Long wrote:
>>>> On 01/30/2019 03:10 PM, Alexei Starovoitov wrote:
>>>>> On Wed, Jan 30, 2019 at 02:42:23PM -0500, Waiman Long wrote:
>>>>>> On 01/30/2019 02:30 PM, Alexei Starovoitov wrote:
>>>>>>> On Wed, Jan 30, 2019 at 11:15:30AM +0100, Peter Zijlstra wrote:
>>>>>>>> On Tue, Jan 29, 2019 at 08:04:56PM -0800, Alexei Starovoitov wrote:
>>>>>>>>> Lockdep warns about false positive:
>>>>>>>> This is not a false positive, and you probably also need to use
>>>>>>>> down_read_non_owner() to match this up_read_non_owner().
>>>>>>>>
>>>>>>>> {up,down}_read() and {up,down}_read_non_owner() are not only different
>>>>>>>> in the lockdep annotation; there is also optimistic spin stuff that
>>>>>>>> relies on 'owner' tracking.
>>>>>>> Can you point out in the code the spin bit?
>>>>>>> As far as I can see sem->owner is debug only feature.
>>>>>>> All owner checks are done under CONFIG_DEBUG_RWSEMS.
>>>>>> No, sem->owner is mainly for performing optimistic spinning which is a
>>>>>> performance feature to make rwsem writer-lock performs similar to mutex.
>>>>>> The debugging part is just an add-on. It is not the reason for the
>>>>>> presence of sem->owner.
>>>>> I see. Got it.
>>>>>
>>>>>>> Also there is no down_read_trylock_non_owner() at the moment.
>>>>>>> We can argue about it for -next, but I'd rather silence lockdep
>>>>>>> with this patch today.
>>>>>>>
>>>>>> We can add down_read_trylock_non_owner() if there is a need for it. It
>>>>>> should be easy to do.
>>>>> Yes, but looking through the code it's not clear to me that it's safe
>>>>> to mix non_owner() versions with regular.
>>>>> bpf/stackmap.c does down_read_trylock + up_read.
>>>>> If we add new down_read_trylock_non_owner that set the owner to
>>>>> NULL | RWSEM_* bits is this safe with conccurent read/write
>>>>> that do regular versions?
>>>>> rwsem_can_spin_on_owner() does:
>>>>> if (owner) {
>>>>> ret = is_rwsem_owner_spinnable(owner) &&
>>>>> owner_on_cpu(owner);
>>>>> that looks correct.
>>>>> For a second I thought there could be fault here due to non_owner.
>>>>> But there could be other places where it's assumed that owner
>>>>> is never null?
>>>> The content of owner is not the cause of the lockdep warning. The
>>>> lockdep code assumes that the task that acquires the lock will release
>>>> it some time later. That is not the case when you need to acquire the
>>>> lock by one task and released by another. In this case, you have to use
>>>> the non_owner version of down/up_read which disable the lockdep
>>>> acquire/release tracking. That will be the only difference between the
>>>> two set of APIs.
>>>>
>>>> Cheers,
>>>> Longman
>>> BTW, you may want to do something like that to make sure that the lock
>>> ownership is probably tracked.
>>>
>>> -Longman
>>>
>>> diff --git a/kernel/bpf/stackmap.c b/kernel/bpf/stackmap.c
>>> index d43b145..79eef9d 100644
>>> --- a/kernel/bpf/stackmap.c
>>> +++ b/kernel/bpf/stackmap.c
>>> @@ -338,6 +338,13 @@ static void stack_map_get_build_id_offset(struct
>>> bpf_stack_
>>> } else {
>>> work->sem = ¤t->mm->mmap_sem;
>>> irq_work_queue(&work->irq_work);
>>> +
>>> + /*
>>> + * The irq_work will release the mmap_sem with
>>> + * up_read_non_owner(). The rwsem_release() is called
>>> + * here to release the lock from lockdep's perspective.
>>> + */
>>> + rwsem_release(¤t->mm->mmap_sem.dep_map, 1, _RET_IP_);
>> are you saying the above is enough coupled with up_read_non_owner?
>> Looking at how amdgpu is using this api... I think they just use non_owner
>> version when doing things from different task.
>> So I don't think pairing non_owner with non_owner is strictly necessary.
>> It seems fine to use down_read_trylock() with above rwsem_release() hack
>> plus up_read_non_owner().
>> Am I missing something?
>>
> The statement above is to clear the state for the lockdep so that it
> knows that the task no longer owns the lock. Without doing that, there
> is a possibility of some other kind of incorrect lockdep warning may be
> produced because the code will still think the task hold a read-lock on
> the mmap_sem. It is also possible no warning will be reported.
>
> The bpf code is kind of special that it acquires the mmap_sem. Later on,
> it either releases it itself (non-NMI) or request irq_work to release it
> (NMI). So either, you use the _non_owner versions for both acquire and
> release or fake the release like the code segment above.
>
> Peter, please chime in if you have other suggestion.
>
Hi guys
What are the plans to address the issue then ?
Latest net tree exhibits this trace :
Thanks
[ 546.116982] =====================================
[ 546.121688] WARNING: bad unlock balance detected!
[ 546.126393] 5.0.0-dbg-DEV #559 Not tainted
[ 546.130491] -------------------------------------
[ 546.135196] taskset/15409 is trying to release lock (&mm->mmap_sem) at:
[ 546.141844] [<ffffffffb0233246>] do_up_read+0x16/0x30
[ 546.146919] but there are no more locks to release!
[ 546.151790]
other info that might help us debug this:
[ 546.158325] 1 lock held by taskset/15409:
[ 546.162325] #0: 00000000683db857 (&sig->cred_guard_mutex){+.+.}, at: __do_execve_file.isra.38+0x13e/0xbc0
[ 546.171978]
stack backtrace:
[ 546.176327] CPU: 0 PID: 15409 Comm: taskset Not tainted 5.0.0-dbg-DEV #559
[ 546.183214] Hardware name: Intel RML,PCH/Iota_QC_19, BIOS 2.54.0 06/07/2018
[ 546.190182] Call Trace:
[ 546.192633] <IRQ>
[ 546.194672] dump_stack+0x67/0x95
[ 546.198006] ? do_up_read+0x16/0x30
[ 546.201491] print_unlock_imbalance_bug.part.33+0xd0/0xd7
[ 546.206914] ? do_up_read+0x16/0x30
[ 546.210406] lock_release+0x213/0x2d0
[ 546.214088] up_read+0x20/0xa0
[ 546.217138] do_up_read+0x16/0x30
[ 546.220457] irq_work_run_list+0x4a/0x70
[ 546.224408] irq_work_run+0x18/0x40
[ 546.227911] smp_irq_work_interrupt+0x54/0x1d0
[ 546.232362] irq_work_interrupt+0xf/0x20
[ 546.236280] </IRQ>
[ 546.238396] RIP: 0010:release_pages+0x69/0x650
[ 546.242839] Code: 01 4c 8b 2f 4c 8d 67 08 48 8d 44 f7 08 45 31 f6 48 89 04 24 eb 04 49 83 c4 08 48 8b 05 20 fe 31 01 49 39 c5 74 26 4d 8b 7d 08 <4d> 8d 47 ff 41 83 e7 01 4d 0f 44 c5 41 8b 40 34 4d 89 c7 85 c0 0f
[ 546.261615] RSP: 0018:ffffac604732bb00 EFLAGS: 00000287 ORIG_RAX: ffffffffffffff09
[ 546.269190] RAX: ffffe4c9c0ca8000 RBX: 0000000000000020 RCX: 0000000000000006
[ 546.276352] RDX: 0000000000000006 RSI: ffff8cf7facb6aa8 RDI: ffff8cf7facb6240
[ 546.283482] RBP: ffffac604732bb70 R08: ffffe4c9c0ba3d80 R09: 0000000000000000
[ 546.290613] R10: 0000000000000000 R11: 0000000000000000 R12: ffff8cf7db3292d8
[ 546.297752] R13: ffffe4c9c0ba3dc0 R14: 0000000000000000 R15: ffffe4c9c0ba3d88
[ 546.304907] free_pages_and_swap_cache+0xe6/0x100
[ 546.309618] tlb_flush_mmu_free+0x36/0x60
[ 546.313625] arch_tlb_finish_mmu+0x28/0x1e0
[ 546.317801] tlb_finish_mmu+0x23/0x30
[ 546.321459] exit_mmap+0xc9/0x1f0
[ 546.324787] ? __mutex_unlock_slowpath+0x11/0x2e0
[ 546.329502] mmput+0x62/0x130
[ 546.332481] flush_old_exec+0x60e/0x810
[ 546.336314] load_elf_binary+0x830/0x18c0
[ 546.340323] ? search_binary_handler+0x8a/0x200
[ 546.344848] search_binary_handler+0x99/0x200
[ 546.349221] __do_execve_file.isra.38+0x76d/0xbc0
[ 546.353918] __x64_sys_execve+0x39/0x50
[ 546.357757] do_syscall_64+0x5a/0x460
[ 546.361440] entry_SYSCALL_64_after_hwframe+0x49/0xbe
[ 546.366489] RIP: 0033:0x7fd599e3c067
[ 546.370069] Code: Bad RIP value.
[ 546.373306] RSP: 002b:00007ffcf7092e58 EFLAGS: 00000202 ORIG_RAX: 000000000000003b
[ 546.380880] RAX: ffffffffffffffda RBX: 00007ffcf7093058 RCX: 00007fd599e3c067
[ 546.388010] RDX: 00007ffcf7093070 RSI: 00007ffcf7093058 RDI: 00007ffcf70937c0
[ 546.395132] RBP: 00007ffcf7092ec0 R08: 00000000ffffffff R09: 0000000001b1ae40
[ 546.402265] R10: 00007ffcf7092c80 R11: 0000000000000202 R12: 00007ffcf70937c0
[ 546.409385] R13: 00007ffcf7093070 R14: 0000000000000000 R15: 00007ffcf7093048
^ 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