* Re: [PATCH net-next v4 2/2] r8169: Reinstate ASPM Support
From: David Miller @ 2018-06-22 5:08 UTC (permalink / raw)
To: kai.heng.feng
Cc: ryankao, hayeswang, hau, hkallweit1, romieu, bhelgaas, acelan.kao,
netdev, linux-pci, linux-kernel
In-Reply-To: <20180621083039.22545-2-kai.heng.feng@canonical.com>
From: Kai-Heng Feng <kai.heng.feng@canonical.com>
Date: Thu, 21 Jun 2018 16:30:39 +0800
> On Intel platforms (Skylake and newer), ASPM support in r8169 is the
> last missing puzzle to let CPU's Package C-State reaches PC8. Without
> ASPM support, the CPU cannot reach beyond PC3. PC8 can save additional
> ~3W in comparison with PC3 on a Coffee Lake platform, Dell G3 3779.
>
> This is based on the work from Chunhao Lin <hau@realtek.com>.
>
> Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
Also applied.
Thank you for being so persistent.
^ permalink raw reply
* Re: KMSAN: uninit-value in ip_vs_lblc_check_expire
From: syzbot @ 2018-06-22 5:52 UTC (permalink / raw)
To: coreteam, davem, fw, horms, ja, kadlec, linux-kernel, lvs-devel,
netdev, netfilter-devel, pablo, syzkaller-bugs, wensong
In-Reply-To: <000000000000c66d94056a84011d@google.com>
syzbot has found a reproducer for the following crash on:
HEAD commit: 123906095e30 kmsan: introduce kmsan_interrupt_enter()/kmsa..
git tree: https://github.com/google/kmsan.git/master
console output: https://syzkaller.appspot.com/x/log.txt?x=134ad890400000
kernel config: https://syzkaller.appspot.com/x/.config?x=848e40757852af3e
dashboard link: https://syzkaller.appspot.com/bug?extid=3e9695f147fb529aa9bc
compiler: clang version 7.0.0 (trunk 334104)
syzkaller repro:https://syzkaller.appspot.com/x/repro.syz?x=11505218400000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1168a490400000
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+3e9695f147fb529aa9bc@syzkaller.appspotmail.com
==================================================================
BUG: KMSAN: uninit-value in ip_vs_lblc_check_expire+0xe62/0xf10
net/netfilter/ipvs/ip_vs_lblc.c:315
CPU: 1 PID: 0 Comm: swapper/1 Not tainted 4.17.0+ #9
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+0x185/0x1d0 lib/dump_stack.c:113
kmsan_report+0x188/0x2a0 mm/kmsan/kmsan.c:1125
__msan_warning_32+0x70/0xc0 mm/kmsan/kmsan_instr.c:620
ip_vs_lblc_check_expire+0xe62/0xf10 net/netfilter/ipvs/ip_vs_lblc.c:315
call_timer_fn+0x280/0x5d0 kernel/time/timer.c:1326
expire_timers kernel/time/timer.c:1363 [inline]
__run_timers+0xd96/0x11b0 kernel/time/timer.c:1666
run_timer_softirq+0x43/0x70 kernel/time/timer.c:1692
__do_softirq+0x592/0x979 kernel/softirq.c:285
invoke_softirq kernel/softirq.c:365 [inline]
irq_exit+0x202/0x240 kernel/softirq.c:405
exiting_irq+0xe/0x10 arch/x86/include/asm/apic.h:525
smp_apic_timer_interrupt+0x64/0x90 arch/x86/kernel/apic/apic.c:1055
apic_timer_interrupt+0xf/0x20 arch/x86/entry/entry_64.S:866
</IRQ>
RIP: 0010:native_safe_halt arch/x86/include/asm/irqflags.h:55 [inline]
RIP: 0010:arch_safe_halt arch/x86/include/asm/irqflags.h:97 [inline]
RIP: 0010:default_idle+0x20b/0x3e0 arch/x86/kernel/process.c:500
RSP: 0018:ffff8801d8e5fdf0 EFLAGS: 00000246 ORIG_RAX: ffffffffffffff13
RAX: ffff8801fd432f18 RBX: 0000000000000000 RCX: ffff880000000000
RDX: ffff8801fd032f18 RSI: aaaaaaaaaaaab000 RDI: ffffea0000000000
RBP: ffff8801d8e5fe28 R08: 0000000001080020 R09: 0000000000000002
R10: 00000030de3d75c0 R11: ffffffff89fef830 R12: ffff8801d8e5fe8f
R13: ffff8801d8da57c0 R14: ffff8801d8e5fe8c R15: ffff8801d8da6098
arch_cpu_idle+0x26/0x30 arch/x86/kernel/process.c:491
default_idle_call kernel/sched/idle.c:93 [inline]
cpuidle_idle_call kernel/sched/idle.c:153 [inline]
do_idle+0x36d/0x830 kernel/sched/idle.c:262
cpu_startup_entry+0x45/0x50 kernel/sched/idle.c:368
start_secondary+0x3c6/0x490 arch/x86/kernel/smpboot.c:272
secondary_startup_64+0xa5/0xb0 arch/x86/kernel/head_64.S:242
Uninit was created at:
kmsan_save_stack_with_flags mm/kmsan/kmsan.c:282 [inline]
kmsan_alloc_meta_for_pages+0x161/0x3a0 mm/kmsan/kmsan.c:819
kmsan_alloc_page+0x82/0xe0 mm/kmsan/kmsan.c:889
__alloc_pages_nodemask+0xf7b/0x5cc0 mm/page_alloc.c:4402
alloc_pages_current+0x6b1/0x970 mm/mempolicy.c:2093
alloc_pages include/linux/gfp.h:494 [inline]
kmalloc_order mm/slab_common.c:1148 [inline]
kmalloc_order_trace+0xbb/0x390 mm/slab_common.c:1159
kmalloc_large include/linux/slab.h:446 [inline]
__kmalloc+0x335/0x350 mm/slub.c:3805
kmalloc include/linux/slab.h:517 [inline]
ip_vs_lblc_init_svc+0x57/0x310 net/netfilter/ipvs/ip_vs_lblc.c:355
ip_vs_bind_scheduler+0xa9/0x1f0 net/netfilter/ipvs/ip_vs_sched.c:51
ip_vs_add_service+0xa9d/0x1d90 net/netfilter/ipvs/ip_vs_ctl.c:1265
do_ip_vs_set_ctl+0x2aa9/0x2cd0 net/netfilter/ipvs/ip_vs_ctl.c:2462
nf_sockopt net/netfilter/nf_sockopt.c:106 [inline]
nf_setsockopt+0x47c/0x4e0 net/netfilter/nf_sockopt.c:115
ip_setsockopt+0x24b/0x2b0 net/ipv4/ip_sockglue.c:1251
udp_setsockopt+0x108/0x1b0 net/ipv4/udp.c:2416
ipv6_setsockopt+0x311/0x350 net/ipv6/ipv6_sockglue.c:917
tcp_setsockopt+0x1c0/0x1f0 net/ipv4/tcp.c:2891
sock_common_setsockopt+0x13b/0x170 net/core/sock.c:3039
__sys_setsockopt+0x496/0x540 net/socket.c:1903
__do_sys_setsockopt net/socket.c:1914 [inline]
__se_sys_setsockopt net/socket.c:1911 [inline]
__x64_sys_setsockopt+0x15c/0x1c0 net/socket.c:1911
do_syscall_64+0x15b/0x230 arch/x86/entry/common.c:287
entry_SYSCALL_64_after_hwframe+0x44/0xa9
==================================================================
^ permalink raw reply
* Re: [PATCH net-next 0/2] fixes for ipsec selftests
From: Shannon Nelson @ 2018-06-22 6:50 UTC (permalink / raw)
To: David Miller; +Cc: netdev, anders.roxell
In-Reply-To: <20180622.134913.2049651808540037401.davem@davemloft.net>
On 6/21/2018 9:49 PM, David Miller wrote:
> From: Shannon Nelson <shannon.nelson@oracle.com>
> Date: Tue, 19 Jun 2018 22:42:41 -0700
>
>> A couple of bad behaviors in the ipsec selftest were pointed out
>> by Anders Roxell <anders.roxell@linaro.org> and are addressed here.
>>
>> Shannon Nelson (2):
>> selftests: rtnetlink: hide complaint from terminated monitor
>> selftests: rtnetlink: use a local IP address for IPsec tests
>
> Series applied, but I wonder about patch #2.
>
> The idea is that we don't make modifications to the actual system
> networking configuration and therefore make changes that can't
> possibly disrupt connectivity for the system under test.
>
> Using a configured local IP address seems to subvert that.
Yeah, I'm not so thrilled with it either. I've got a couple more
changes coming Real Soon Now that extend netdevsim and add a couple of
tests for ipsec-hw-offload, so while I finish those up I can change this
again and make use of netdevsim to leave existing devices alone.
For that matter, if you want to cut down on patch thrash, just drop patch 2.
sln
^ permalink raw reply
* Re: [PATCH v2] net: ethernet: stmmac: dwmac-rk: Add GMAC support for PX30
From: David Wu @ 2018-06-22 7:22 UTC (permalink / raw)
To: Heiko Stübner
Cc: davem, robh+dt, mark.rutland, huangtao, netdev, linux-arm-kernel,
linux-rockchip, linux-kernel
In-Reply-To: <2582999.2hZx6CH9S6@diego>
Hi Heiko,
在 2018年06月14日 16:30, Heiko Stübner 写道:
> And someone could convert the driver to use the new clk-bulk APIs [0],
> so the large number of clk_prepare_enable calls would be a bit
> trimmed down.
Some clocks need special treatment at special cases, may not know which
index is we need at clk_bulk_data struct.
1. At rmii mode, need to use mac_ref, mac_refout; but at rgmii, they are
not needed.
2. At rgmii mode, rx is coming in from external source, there is no
gate, and it is coming from mac_ref_clk at rmii mode, there is gate.
3. clk_mac needs to be configured rate 50M or 125M.
4. mac_clk_speed needs to be configured at PX30 Soc and next Socs.
It looks like use the clk-bulk, will not be more flexible, and we still
keep the present. What do you think?
^ permalink raw reply
* Re: [PATCH net-next 0/2] fixes for ipsec selftests
From: David Miller @ 2018-06-22 7:27 UTC (permalink / raw)
To: shannon.nelson; +Cc: netdev, anders.roxell
In-Reply-To: <20059528-5d1d-cb7c-26f8-f9055bd807c2@oracle.com>
From: Shannon Nelson <shannon.nelson@oracle.com>
Date: Thu, 21 Jun 2018 23:50:36 -0700
> For that matter, if you want to cut down on patch thrash, just drop
> patch 2.
Too late, already in my tree :)
Don't worry about it for now.
^ permalink raw reply
* Re: [PATCH v2] net: ethernet: stmmac: dwmac-rk: Add GMAC support for PX30
From: Heiko Stuebner @ 2018-06-22 7:28 UTC (permalink / raw)
To: David Wu
Cc: davem, robh+dt, mark.rutland, huangtao, netdev, linux-arm-kernel,
linux-rockchip, linux-kernel
In-Reply-To: <7173b45f-17d3-2356-fede-28bdd5c658f2@rock-chips.com>
Hi David,
Am Freitag, 22. Juni 2018, 09:22:35 CEST schrieb David Wu:
> 在 2018年06月14日 16:30, Heiko Stübner 写道:
> > And someone could convert the driver to use the new clk-bulk APIs [0],
> > so the large number of clk_prepare_enable calls would be a bit
> > trimmed down.
>
> Some clocks need special treatment at special cases, may not know which
> index is we need at clk_bulk_data struct.
> 1. At rmii mode, need to use mac_ref, mac_refout; but at rgmii, they are
> not needed.
> 2. At rgmii mode, rx is coming in from external source, there is no
> gate, and it is coming from mac_ref_clk at rmii mode, there is gate.
> 3. clk_mac needs to be configured rate 50M or 125M.
> 4. mac_clk_speed needs to be configured at PX30 Soc and next Socs.
>
> It looks like use the clk-bulk, will not be more flexible, and we still
> keep the present. What do you think?
yeah, you're probably right. I just saw all these clk_prepare_enable calls
and didn't think enough about the config side ;-) .
Heiko
^ permalink raw reply
* Re: [PATCH] optoe: driver to read/write SFP/QSFP EEPROMs
From: Andrew Lunn @ 2018-06-22 7:28 UTC (permalink / raw)
To: Don Bollinger; +Cc: netdev, Florian Fainelli
In-Reply-To: <20180621202809.enukvcdzahdon3lx@thebollingers.org>
> Got it. I'm targeting a different market, with a different
> architecture. In this architecture it makes more sense to separate the
> EEPROM access from the IO pins control.
The fact you are targeting a different architecture is why you are
getting no traction. The closer you stick to the kernel architecture,
the more acceptable your changes are going to be.
> > have a network interface per port. So they cannot use ethtool
> > --module-info, which IS the defined API to get access to SFP
> > data. Adding another API is probably not going to get accepted.
>
> Got it. I don't think I'm adding another API. Note that Cumulus is
> using the same architecture as optoe, and providing all the expected
> linux services, including ethtool --module-info.
Please point me to the in kernel code.
Cumulus has a lot of code out of mainline, which does not follow the
mainline way of doing things. Cumulus is between a rock and a hard
place. There are some switch vendors who simply won't do things the
netdev way. So they have to make use of the vendor SDKs. But they also
work with vendors like Mellonex which fully do things netdev way. So
you cannot use Cumulus as a reference, without pointing to actual in
kernel code.
> I'm offering an improvement to sfp.c. The improvement is access to more
> pages of SFP EEPROM, and access to QSFP EEPROMs. It comes in the form of
> a specialized EEPROM driver custom built for {Q}SFP devices. I'm also
> offering to help integrate that driver into sfp.c. I can modify optoe
> to accomodate sfp.c, I can recommend how to instantiate and call it. I am
> not going to be able to spend the time and money required to modify and
> test sfp.c. I'm pretty sure you can do it MUCH faster, and MUCH better
> than I can.
You are however going the wrong way. We want ethtool --module-info to
show QSFP contents, and that is the only API the kernel needs to the
raw data. The core of optoe for accessing the EEPROM could be merged
into the SFP code, but the way optoe it exposes it via /sysfs is
unlikely to be accepted.
> > the SFP code. It has been on my TODO list to add HWMON support for the
> > temperature sensors, etc.
>
> Huh. Just read Documentation/hwmon/sysfs-interface. Looks like a good
> way to deliver that EEPROM data. Wish I'd found that two years ago when
> there were a few more dimes available.
Well, it is not all the EEPROM data. Just sensors. But that is the
kernel way of exporting sensors.
Andrew
^ permalink raw reply
* Re: [PATCH v2] net: ethernet: stmmac: dwmac-rk: Add GMAC support for PX30
From: Heiko Stuebner @ 2018-06-22 7:30 UTC (permalink / raw)
To: David Wu
Cc: davem, robh+dt, mark.rutland, huangtao, netdev, linux-arm-kernel,
linux-rockchip, linux-kernel, 张晴
In-Reply-To: <157ecfc9-d0e6-7782-1cbc-d0fb76c81edb@rock-chips.com>
Hi David,
Am Mittwoch, 20. Juni 2018, 04:40:35 CEST schrieb David Wu:
> 在 2018年06月14日 16:30, Heiko Stübner 写道:
> > Am Donnerstag, 14. Juni 2018, 10:14:31 CEST schrieb David Wu:
> >> Hi Heiko,
> >>
> >> 在 2018年06月14日 15:54, Heiko Stübner 写道:
> >>> I don't see that new clock documented in the dt-binding.
> >>> Also, which clock from the clock-controller does this connect to?
> >>
> >> The clock is the "SCLK_GMAC_RMII" at the clock-controller, which could
> >> be set rate by the link speed.
> >
> > Hmm, while these huge number of clocks are somewhat strange,
> > shouldn't it be named something with _rmii instead of _speed then?
>
> Okay, it is better to be named _speed.
>
> >
> > Also, I don't see any clk_enable action for that new clock, so you could
> > end up with being off?
>
> The new speed is the parent of the clk_tx_rx, to enable/disable
> clk_tx_rx, the new clock would be also enabled/disabled.
Still it is nicer to really enable it, so that the clock-framework can keep
track of usage counts.
Because also no-one hinders the chip-designer from putting a gate in
between in one of the next socs ;-)
Heiko
^ permalink raw reply
* Re: WARNING: refcount bug in smap_release_sock
From: syzbot @ 2018-06-22 7:35 UTC (permalink / raw)
To: ast, daniel, linux-kernel, netdev, syzkaller-bugs
In-Reply-To: <0000000000004f02b3056e895cce@google.com>
syzbot has found a reproducer for the following crash on:
HEAD commit: f0dc7f9c6dd9 Merge git://git.kernel.org/pub/scm/linux/kern..
git tree: bpf-next
console output: https://syzkaller.appspot.com/x/log.txt?x=1609ed08400000
kernel config: https://syzkaller.appspot.com/x/.config?x=fa9c20c48788d1c1
dashboard link: https://syzkaller.appspot.com/bug?extid=d464d2c20c717ef5a6a8
compiler: gcc (GCC) 8.0.1 20180413 (experimental)
syzkaller repro:https://syzkaller.appspot.com/x/repro.syz?x=10a53fbf800000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=11d27aa0400000
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+d464d2c20c717ef5a6a8@syzkaller.appspotmail.com
random: sshd: uninitialized urandom read (32 bytes read)
random: sshd: uninitialized urandom read (32 bytes read)
device lo entered promiscuous mode
------------[ cut here ]------------
refcount_t: underflow; use-after-free.
WARNING: CPU: 0 PID: 4505 at lib/refcount.c:187
refcount_sub_and_test+0x2d3/0x330 lib/refcount.c:187
Kernel panic - not syncing: panic_on_warn set ...
CPU: 0 PID: 4505 Comm: syz-executor540 Not tainted 4.17.0+ #39
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+0x1b9/0x294 lib/dump_stack.c:113
panic+0x22f/0x4de kernel/panic.c:184
__warn.cold.8+0x163/0x1b3 kernel/panic.c:536
report_bug+0x252/0x2d0 lib/bug.c:186
fixup_bug arch/x86/kernel/traps.c:178 [inline]
do_error_trap+0x1fc/0x4d0 arch/x86/kernel/traps.c:296
do_invalid_op+0x1b/0x20 arch/x86/kernel/traps.c:316
invalid_op+0x14/0x20 arch/x86/entry/entry_64.S:992
RIP: 0010:refcount_sub_and_test+0x2d3/0x330 lib/refcount.c:187
Code: 89 de e8 40 7e 21 fe 84 db 74 07 31 db e9 52 ff ff ff e8 60 7d 21 fe
48 c7 c7 20 4b 1a 88 c6 05 78 64 40 06 01 e8 8d 97 ed fd <0f> 0b 31 db e9
31 ff ff ff 48 8b bd 28 ff ff ff 89 85 34 ff ff ff
RSP: 0018:ffff8801b18b7800 EFLAGS: 00010282
RAX: 0000000000000026 RBX: 0000000000000000 RCX: ffffffff8161907a
RDX: 0000000000000000 RSI: ffffffff8161f371 RDI: ffff8801b18b74d8
RBP: ffff8801b18b78e8 R08: ffff8801b24923c0 R09: 0000000000000006
R10: 0000000000000000 R11: 0000000000000000 R12: 00000000ffffffff
R13: ffff8801b18b78c0 R14: 0000000000000001 R15: ffff8801b318f040
refcount_dec_and_test+0x1a/0x20 lib/refcount.c:212
smap_release_sock+0x6e/0x2f0 kernel/bpf/sockmap.c:1358
sock_hash_ctx_update_elem.isra.24+0x896/0x1560 kernel/bpf/sockmap.c:2281
sock_hash_update_elem+0x14f/0x2d0 kernel/bpf/sockmap.c:2303
map_update_elem+0x5c4/0xc90 kernel/bpf/syscall.c:765
__do_sys_bpf kernel/bpf/syscall.c:2357 [inline]
__se_sys_bpf kernel/bpf/syscall.c:2328 [inline]
__x64_sys_bpf+0x32d/0x510 kernel/bpf/syscall.c:2328
do_syscall_64+0x1b1/0x800 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x445a69
Code: e8 3c b6 02 00 48 83 c4 18 c3 0f 1f 80 00 00 00 00 48 89 f8 48 89 f7
48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff
ff 0f 83 db 51 00 00 c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:00007f90f7ac8db8 EFLAGS: 00000293 ORIG_RAX: 0000000000000141
RAX: ffffffffffffffda RBX: 00000000006dac94 RCX: 0000000000445a69
RDX: 0000000000000020 RSI: 0000000020000180 RDI: 0000000000000002
RBP: 00000000006dac90 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000293 R12: 0000000000000000
R13: 00007ffc108bd18f R14: 00007f90f7ac99c0 R15: 0000000000000001
Dumping ftrace buffer:
(ftrace buffer empty)
Kernel Offset: disabled
Rebooting in 86400 seconds..
^ permalink raw reply
* Re: [RFC v2, net-next, PATCH 4/4] net/cpsw_switchdev: add switchdev mode of operation on cpsw driver
From: Ilias Apalodimas @ 2018-06-22 7:45 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Ivan Vecera, Florian Fainelli, Andrew Lunn, Networking,
Grygorii Strashko, ivan.khoronzhuk, Sekhar Nori,
Jiří Pírko, Francois Ozog, yogeshs, spatton,
Jose.Abreu
In-Reply-To: <CAK8P3a0wAE+8kvyuF-y3oaz+3Req3Jrv3jr-x2c0LWZ39ztVXg@mail.gmail.com>
On Thu, Jun 21, 2018 at 05:31:31PM +0200, Arnd Bergmann wrote:
> On Thu, Jun 21, 2018 at 2:45 PM, Ilias Apalodimas
> <ilias.apalodimas@linaro.org> wrote:
> > On Thu, Jun 21, 2018 at 02:19:55PM +0200, Ivan Vecera wrote:
>
> > The driver is currently widely used and that's the reason we tried to avoid
> > rewriting it. The current driver uses a DTS option to distinguish between two
> > existing modes. This patch just adds a third one. So to my understanding we
> > have the following options:
> > 1. The driver already uses DTS to configure the hardware mode. Although this is
> > techincally wrong, we can add a third mode on DTS called 'switchdev;', get rid
> > of the .config option and keep the configuration method common (although not
> > optimal).
> > 2. Keep the .config option which overrides the 2 existing modes.
> > 3. Introduce a devlink option. If this is applied for all 3 modes, it will break
> > backwards compatibility, so it's not an option. If it's introduced for
> > configuring 'switchdev' mode only, we fall into the same pitfall as option 2),
> > we have something that overrides our current config, slightly better though
> > since it's not a compile time option.
> > 4. rewrite the driver
>
> As I understand it, the switchdev support can also be added without
> becoming incompatible with the existing behavior, this is how I would
> suggest it gets added in a way that keeps the existing DT binding and
> user view while adding switchdev:
>
> * In non-"dual-emac" mode, show only one network device that is
> configured as a transparent switch as today. Any users that today
> add TI's third-party ioctl interface with a non-upstreamable patch
> can keep using this mode and try to forward-port that patch.
Correct
> * In "dual-emac" mode (as selected through DT), the hardware is
> configured to be viewed as two separate network devices as before,
> regardless of kernel configuration. Users can add the two device
> to a bridge device as before, and enabling switchdev support in
> the kernel configuration (based on your patch series) would change
> nothing else than using hardware support in the background to
> reconfigure the HW VLAN settings.
>
> This does not require using devlink, adding a third mode, or changing
> the DT binding or the user-visible behavior when switchdev is enabled,
> but should get all the features you want.
>
Correct again. This is doable and the changes on the current patchset are
somewhat trivial (detecting a bridge and making the configuration changes
on the fly).
> > If it was a brand new driver, i'd definitely pick 4. Since it's a pre-existing
> > driver though i can't rule out the rest of the options.
>
> I think the suggestion was to have a new driver with a new binding
> so that the DT could choose between the two drivers, one with
> somewhat obscure behavior and the other with proper behavior.
>
> However, from what I can tell, the only requirement to get a somewhat
> reasonable behavior is that you enable "dual-emac" mode in DT
> to get switchdev support. It would be trivial to add a new compatible
> value that only allows that mode along with supporting switchdev,
> but I don't think that's necessary here.
>
> Writing a new driver might also be a good idea (depending on the
> quality of the existing one, I haven't looked in detail), but again
> I would see no reason for the new driver to be incompatible with
> the existing binding, so a gradual cleanup seems like a better
> approach.
Agree
>
> Arnd
If people like this idea, i can send a V3 with these changes.
Thanks
Ilias
^ permalink raw reply
* Re: [PATCH 3/6] arcnet: com20020: Add com20020 io mapped version
From: kbuild test robot @ 2018-06-22 8:11 UTC (permalink / raw)
To: Andrea Greco
Cc: kbuild-all, davem, tobin, Andrea Greco, Michael Grzeschik,
linux-kernel, netdev
In-Reply-To: <20180611142635.20712-1-andrea.greco.gapmilano@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 992 bytes --]
Hi Andrea,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on net-next/master]
[also build test ERROR on v4.18-rc1 next-20180622]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Andrea-Greco/arcnet-leds-Removed-leds-dependecy/20180611-222941
config: x86_64-randconfig-s4-06220549 (attached as .config)
compiler: gcc-7 (Debian 7.3.0-16) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
All errors (new ones prefixed by >>):
>> ERROR: "com20020_found" [drivers/net/arcnet/com20020-io.ko] undefined!
>> ERROR: "com20020_check" [drivers/net/arcnet/com20020-io.ko] undefined!
>> ERROR: "com20020_netdev_ops" [drivers/net/arcnet/com20020-io.ko] undefined!
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 32221 bytes --]
^ permalink raw reply
* Re: [PATCH v2] net: ethernet: stmmac: dwmac-rk: Add GMAC support for PX30
From: David Wu @ 2018-06-22 8:13 UTC (permalink / raw)
To: Heiko Stuebner
Cc: davem, robh+dt, mark.rutland, huangtao, netdev, linux-arm-kernel,
linux-rockchip, linux-kernel, 张晴
In-Reply-To: <18221590.FEDROxemCD@phil>
Hi Heiko,
在 2018年06月22日 15:30, Heiko Stuebner 写道:
> Hi David,
>
> Am Mittwoch, 20. Juni 2018, 04:40:35 CEST schrieb David Wu:
>> 在 2018年06月14日 16:30, Heiko Stübner 写道:
>>> Am Donnerstag, 14. Juni 2018, 10:14:31 CEST schrieb David Wu:
>>>> Hi Heiko,
>>>>
>>>> 在 2018年06月14日 15:54, Heiko Stübner 写道:
>>>>> I don't see that new clock documented in the dt-binding.
>>>>> Also, which clock from the clock-controller does this connect to?
>>>>
>>>> The clock is the "SCLK_GMAC_RMII" at the clock-controller, which could
>>>> be set rate by the link speed.
>>>
>>> Hmm, while these huge number of clocks are somewhat strange,
>>> shouldn't it be named something with _rmii instead of _speed then?
>>
>> Okay, it is better to be named _speed.
>>
>>>
>>> Also, I don't see any clk_enable action for that new clock, so you could
>>> end up with being off?
>>
>> The new speed is the parent of the clk_tx_rx, to enable/disable
>> clk_tx_rx, the new clock would be also enabled/disabled.
>
> Still it is nicer to really enable it, so that the clock-framework can keep
> track of usage counts.
>
> Because also no-one hinders the chip-designer from putting a gate in
> between in one of the next socs ;-)
>
Okay, i will add the enable/disable for clk_mac_speed.
;-)
>
> Heiko
>
>
>
>
>
^ permalink raw reply
* [PATCH net] net: mvneta: fix the Rx desc DMA address in the Rx path
From: Antoine Tenart @ 2018-06-22 8:15 UTC (permalink / raw)
To: davem, gregory.clement, mw
Cc: Antoine Tenart, netdev, linux-kernel, thomas.petazzoni,
maxime.chevallier, miquel.raynal, nadavh, stefanc, ymarkman
When using s/w buffer management, buffers are allocated and DMA mapped.
When doing so on an arm64 platform, an offset correction is applied on
the DMA address, before storing it in an Rx descriptor. The issue is
this DMA address is then used later in the Rx path without removing the
offset correction. Thus the DMA address is wrong, which can led to
various issues.
This patch fixes this by removing the offset correction from the DMA
address retrieved from the Rx descriptor before using it in the Rx path.
Fixes: 8d5047cf9ca2 ("net: mvneta: Convert to be 64 bits compatible")
Signed-off-by: Antoine Tenart <antoine.tenart@bootlin.com>
---
drivers/net/ethernet/marvell/mvneta.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/marvell/mvneta.c b/drivers/net/ethernet/marvell/mvneta.c
index 17a904cc6a5e..0ad2f3f7da85 100644
--- a/drivers/net/ethernet/marvell/mvneta.c
+++ b/drivers/net/ethernet/marvell/mvneta.c
@@ -1932,7 +1932,7 @@ static int mvneta_rx_swbm(struct mvneta_port *pp, int rx_todo,
rx_bytes = rx_desc->data_size - (ETH_FCS_LEN + MVNETA_MH_SIZE);
index = rx_desc - rxq->descs;
data = rxq->buf_virt_addr[index];
- phys_addr = rx_desc->buf_phys_addr;
+ phys_addr = rx_desc->buf_phys_addr - pp->rx_offset_correction;
if (!mvneta_rxq_desc_is_first_last(rx_status) ||
(rx_status & MVNETA_RXD_ERR_SUMMARY)) {
--
2.17.1
^ permalink raw reply related
* Re: [PATCH] net: Fix device name resolving crash in default_device_exit()
From: Kirill Tkhai @ 2018-06-22 8:36 UTC (permalink / raw)
To: David Ahern, netdev
Cc: davem, daniel, jakub.kicinski, ast, linux, john.fastabend, brouer
In-Reply-To: <5e4b9ecd-e7f5-87e4-2b45-2aaaca125442@gmail.com>
On 21.06.2018 18:28, David Ahern wrote:
> On 6/21/18 4:03 AM, Kirill Tkhai wrote:
>>> This patch does not remove the BUG, so does not really solve the
>>> problem. ie., it is fairly trivial to write a script (32k dev%d named
>>> devices in init_net) that triggers it again, so your commit subject and
>>> commit log are not correct with the references to 'fixing the problem'.
>>
>> 1)I'm not agree with you and I don't think removing the BUG() is a good idea.
>> This function is called from the place, where it must not fail. But it can
>> fail, and the problem with name is not the only reason of this happens.
>> We can't continue further pernet_operations in case of a problem happened
>> in default_device_exit(), and we can't remove the BUG() before this function
>> becomes of void type. But we are not going to make it of void type. So
>> we can't remove the BUG().
>
> You missed my point: that the function can still fail means you are not
> "fixing" the problem, only delaying it.
Till the function is of int type and it can fail, we can't remove the BUG().
And this does not connected with name resolution.
>>
>> 2)In case of the script is trivial, can't you just post it here to show
>> what type of devices you mean? Is there real problem or this is
>> a theoretical thinking?
>
> Current code:
>
> # ip li sh dev eth2
> 4: eth2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP
> mode DEFAULT group default qlen 1000
> link/ether 02:e0:f9:46:64:80 brd ff:ff:ff:ff:ff:ff
> # ip netns add fubar
> # ip li set eth2 netns fubar
> # ip li add eth2 type dummy
> # ip li add dev4 type dummy
> # ip netns del fubar
> --> BUG
> kernel:[78079.127748] default_device_exit: failed to move eth2 to
> init_net: -17
>
>
> With your patch:
>
> # ip li sh dev eth2
> 4: eth2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP
> mode DEFAULT group default qlen 1000
> link/ether 02:e0:f9:46:64:80 brd ff:ff:ff:ff:ff:ff
> # ip netns add fubar
> # ip li set eth2 netns fubar
> # ip li add eth2 type dummy
> # for n in $(seq 0 $((32*1024))); do
> echo "li add dev${n} type dummy"
> done > ip.batch
> # ip -batch ip.batch
> # ip netns del fubar
> --> BUG
> kernel:[ 25.800024] default_device_exit: failed to move eth2 to
> init_net: -17
Yeah, this has a sense.
>>
>> All virtual devices I see have rtnl_link_ops, so that they just destroyed
>> in default_device_exit_batch(). According to physical devices, it's difficult
>> to imagine a node with 32k physical devices, and if someone tried to deploy
>> them it may meet problems not only in this place.
>
> Nothing says it has to be a physical device. It is only checking for a name.
>
>>
>>> The change does provide more variability in naming and reduces the
>>> likelihood of not being able to push a device back to init_net.
>>
>> No, it provides. With the patch one may move real device to a container,
>> and allow to do with the device anything including changing of device
>> index. Then, the destruction of the container does not resilt a kernel
>> panic just because of two devices have the same index.
^ permalink raw reply
* RE: [PATCH v0 03/12] mlxsw: core: Add core environment module for port temperature reading
From: Vadim Pasternak @ 2018-06-22 9:00 UTC (permalink / raw)
To: Guenter Roeck, Andrew Lunn
Cc: davem@davemloft.net, netdev@vger.kernel.org, jiri@resnulli.us
In-Reply-To: <20180621220644.GA7002@roeck-us.net>
> -----Original Message-----
> From: Guenter Roeck [mailto:linux@roeck-us.net]
> Sent: Friday, June 22, 2018 1:07 AM
> To: Andrew Lunn <andrew@lunn.ch>
> Cc: Vadim Pasternak <vadimp@mellanox.com>; davem@davemloft.net;
> netdev@vger.kernel.org; jiri@resnulli.us
> Subject: Re: [PATCH v0 03/12] mlxsw: core: Add core environment module for
> port temperature reading
>
> On Thu, Jun 21, 2018 at 08:34:40PM +0200, Andrew Lunn wrote:
> > > Hi Andrew,
> >
> > Adding Guenter Roeck, the HWMON maintainer.
Hi Guenter,
Thank you for reply.
We are going to re-post this patchset and add more people
for review, as Andrew suggested.
> >
> > > The temperature of each individual module can be obtained through
> > > ethtool.
> >
> > You mean via --module-info?
> >
> > FYI: I plan to add hwmon support to the kernel SFP code. So if you
> > ever decide to swap to the kernel SFP code, not your own, the raw
> > temperatures will be exported.
> >
> As should be. Unless adjustments are made by the hardware (eg a thermal diode
> temperature offset register), all adjustments should be made in userspace.
>
>From hardware we read all module temperature in one request.
The summary of temperature is going to thermal module.
> > > The worst temperature is necessary for the system cooling control
> > > decision.
> >
> > I would expect the system cooling would understand that.
> >
> > > Up to 64 SFP/QSFP modules could be connected to the system.
> > > Some of them could cooper modules, which doesn't provide temperature
> > > measurement.
> >
> > SFP modules are hot-plugable. So i would also expect the hwmon devices
> > to hotplug. If there is no sensor, then there is no hwmon device... If
> > there is no hwmon device, it plays no part in the thermal control
> > loop.
> >
> One hardware monitoring device per SFP, and I would assume that the hwmon
> device for an SFP is only instantiated if a thermal sensor is present.
>
> > > Some of them could be optical modules, providing untrusted
> > > temperature measurement, which could impact thermal control of the
> > > system.
> >
> > Why would you not trust it? Are you saying some modules simply have
> > broken temperature sensors? Do you have a whitelist/blacklist of
> > modules?
> >
> > > Also optical modules could be from the different vendors, and this
> > > is real situation, when, f.e. one module has the warning and
> > > critical thresholds 75C and 85C, while another 70C and 80C.
> >
> > But hwmon exports both the actual temperature and the alarm
> > temperatures. I would expect the thermal control code to use all this
> > information when making its decisions, not just the current
> > temperature.
> >
> The respective information would either be provided by hardware and reported
> to userspace, or userspace needs to determine the limits and write them into the
> hardware. Either case, that is only relevant if the hardware has limit registers.
> Otherwise all limits can and should be handled in the thermal subsystem.
>
This is the case. Limits, modules temperatures and thresholds are handled in
the thermal subsystem.
> > > So, nominal temperature is not the case here, we should know the
> > > "worst" value for the thermal control decision.
> >
> > What it sounds like to me is you are working around problems in the
> > thermal control by fudging the raw temperatures. That is the wrong
> > thing to do. hwmon should export the raw data, and you should fix the
> > thermal control code to use it correctly.
> >
> Agreed. From the context it sounds like there should be some kind of
> temperature aggregator which would probably reside in the thermal subsystem
> (definitely not in hwmon).
Exactly this is the kind of temperature aggregation, provided to the thermal
subsystem as the thermal zone temperature.
>
> I have not seen any hwmon specific patches. For new drivers, please use
> [devm_]hwmon_device_register_with_info().
We already have hwmon object. This is the reason I didn't use this
interface. This existing object has been extend with a few new
attributes for FANs.
Also I added aggregated FAULT status of the modules. In case even
one module is considered as "untrusted" (this is getting from HW),
this attribute is set to true.
This indication could be used by the user.
In our systems such fault will impact the allowed PWM minimum,
which could be assigned to thermal zone cooling device.
For example, if in normal situation for some particular system
minimum could be set to 20%, then in case any untrusted module
is found, this minimum should be increased to 40% (these percent
are depend on system type).
It doesn't matter how many untrusted modules are inserted. If there
is even one, it could have very bad impact on system thermal flow.
Thanks,
Vadim.
>
> Guenter
^ permalink raw reply
* [PATCH net] net: mscc: make sparse happy
From: Antoine Tenart @ 2018-06-22 9:50 UTC (permalink / raw)
To: davem
Cc: Antoine Tenart, f.fainelli, andrew, netdev, linux-kernel,
thomas.petazzoni, alexandre.belloni, quentin.schulz,
allan.nielsen
This patch fixes a sparse warning about using an incorrect type in
argument 2 of ocelot_write_rix(), as an u32 was expected but a __be32
was given. The conversion to u32 is forced, which is safe as the value
will be written as-is in the hardware without any modification.
Fixes: 08d02364b12f ("net: mscc: fix the injection header")
Signed-off-by: Antoine Tenart <antoine.tenart@bootlin.com>
---
drivers/net/ethernet/mscc/ocelot.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/mscc/ocelot.c b/drivers/net/ethernet/mscc/ocelot.c
index 52c57e0ff617..776a8a9be8e3 100644
--- a/drivers/net/ethernet/mscc/ocelot.c
+++ b/drivers/net/ethernet/mscc/ocelot.c
@@ -374,7 +374,8 @@ static int ocelot_port_xmit(struct sk_buff *skb, struct net_device *dev)
ocelot_gen_ifh(ifh, &info);
for (i = 0; i < IFH_LEN; i++)
- ocelot_write_rix(ocelot, cpu_to_be32(ifh[i]), QS_INJ_WR, grp);
+ ocelot_write_rix(ocelot, (__force u32)cpu_to_be32(ifh[i]),
+ QS_INJ_WR, grp);
count = (skb->len + 3) / 4;
last = skb->len % 4;
--
2.17.1
^ permalink raw reply related
* [PATCH v4] MAINTAINERS: Add file patterns for dsa device tree bindings
From: Geert Uytterhoeven @ 2018-06-22 10:08 UTC (permalink / raw)
To: Andrew Lunn, Vivien Didelot, Florian Fainelli, David S . Miller
Cc: Rob Herring, Mark Rutland, netdev, devicetree, linux-kernel,
Geert Uytterhoeven
Submitters of device tree binding documentation may forget to CC
the subsystem maintainer if this is missing.
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
---
v3:
- Update for next-20180622,
v2.1:
- Moved pattern to "NETWORKING [DSA]",
v2:
- Rebased on top of commit 0d3cd4b6b49865e8 ("net: dsa: mv88e6xxx:
move driver in its own folder").
Impact on "scripts/get_maintainer.pl -f Documentation/devicetree/bindings/net/dsa/":
-"David S. Miller" <davem@davemloft.net> (odd fixer:NETWORKING DRIVERS,commit_signer:6/8=75%)
-Rob Herring <robh+dt@kernel.org> (maintainer:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,commit_signer:3/8=38%,authored:1/8=12%)
+Andrew Lunn <andrew@lunn.ch> (maintainer:NETWORKING [DSA])
+Vivien Didelot <vivien.didelot@savoirfairelinux.com> (maintainer:NETWORKING [DSA])
+Florian Fainelli <f.fainelli@gmail.com> (maintainer:NETWORKING [DSA])
+"David S. Miller" <davem@davemloft.net> (odd fixer:NETWORKING DRIVERS)
+Rob Herring <robh+dt@kernel.org> (maintainer:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS)
Mark Rutland <mark.rutland@arm.com> (maintainer:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS)
-Andrew Lunn <andrew@lunn.ch> (commit_signer:3/8=38%)
-Florian Fainelli <f.fainelli@gmail.com> (commit_signer:3/8=38%)
-Brandon Streiff <brandon.streiff@ni.com> (commit_signer:1/8=12%)
-Egil Hjelmeland <privat@egil-hjelmeland.no> (authored:1/8=12%)
-Fabio Estevam <fabio.estevam@nxp.com> (authored:1/8=12%)
-"Damien Thébault" <damien.thebault@vitec.com> (authored:1/8=12%)
-"Michal Vokáč" <vokac.m@gmail.com> (authored:1/8=12%)
netdev@vger.kernel.org (open list:NETWORKING DRIVERS)
devicetree@vger.kernel.org (open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS)
linux-kernel@vger.kernel.org (open list)
---
MAINTAINERS | 1 +
1 file changed, 1 insertion(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index e5db502df5afdd8b..07a4927b1e7aada4 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -9884,6 +9884,7 @@ M: Andrew Lunn <andrew@lunn.ch>
M: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
M: Florian Fainelli <f.fainelli@gmail.com>
S: Maintained
+F: Documentation/devicetree/bindings/net/dsa/
F: net/dsa/
F: include/net/dsa.h
F: include/linux/dsa/
--
2.17.1
^ permalink raw reply related
* RE: bnx2x: kernel panic in the bnx2x driver
From: Kalluru, Sudarsana @ 2018-06-22 10:20 UTC (permalink / raw)
To: Vishwanath Pai, Elior, Ariel, Dept-Eng Everest Linux L2
Cc: davem@davemloft.net, netdev@vger.kernel.org, dbanerje@akamai.com,
pai.vishwain@gmail.com
In-Reply-To: <20180622050706.GA24578@akamai.com>
Hi Vishwanath,
Thanks for your mail, and the analysis.
The fix would be to invoke bnx2x_rss() only when the device is opened,
if (bp->state == BNX2X_STATE_OPEN)
return bnx2x_rss(bp, &bp->rss_conf_obj, false, true);
else
return 0;
Ariel,
Could you please review the path (bnx2x_set_rss_flags()--> bnx2x_rss()) and confirm/correct on the above.
Thanks,
Sudarsana
-----Original Message-----
From: Vishwanath Pai [mailto:vpai@akamai.com]
Sent: 22 June 2018 10:37
To: Elior, Ariel <Ariel.Elior@cavium.com>; Dept-Eng Everest Linux L2 <Dept-EngEverestLinuxL2@cavium.com>
Cc: davem@davemloft.net; netdev@vger.kernel.org; dbanerje@akamai.com; pai.vishwain@gmail.com
Subject: bnx2x: kernel panic in the bnx2x driver
External Email
Hi,
We recently noticed a kernel panic in the bnx2x driver when trying to set rx-flow-hash parameters via ethtool during if-pre-up.d. I am running kernel
v4.17.2 from ubuntu-mainline-ppa. I have added the stack trace below:
[ 18.280209] BUG: unable to handle kernel NULL pointer dereference at 0000000000000000
[ 18.280212] PGD 8000000407a79067 P4D 8000000407a79067 PUD 40ce8a067 PMD 0
[ 18.280214] Oops: 0010 [#1] SMP PTI
[ 18.280215] Modules linked in: intel_rapl x86_pkg_temp_thermal intel_powerclamp kvm_intel joydev input_led kvm irqbypass crct10dif_pclmul crc32_pclmul ghash_clmulni_intel pcbc hid_eneric aesni_intel gpio_ich aes_x86_64 usbhid lpc_ich crpto_simd ie31200_edac cryptd glue_helper intel_cstate mac_hid intel_rapl_perf bnx2x mdio tcp_bbr netconsole ipmi_devintf ipmi_msghandler i2c_i801 coretemp autofs4 raid10 raid456 libcrc32c async_raid6_recov async_memcpy async_pq async_xor xor async_tx raid6_pq raid1 raid0 multipath linear sha26_mb mcryptd sha256_ssse3 hid ast i2c_algo_bit ttm drm_kms_helper syscopyarea sysfillrect sysimgblt mpt3sas fb_sys_fops drm raid_class scsi_transport_sas ahci libahci shpchp video
[ 18.280241] CPU: 6 PID: 1081 Comm: ethtool Not tainted 4.17.2-041702-generic #201806160433
[ 18.280242] Hardware name: Foxconn CangJie/CangJie, BIOS CC1F108D 02/26/2014
[ 18.280243] RIP: 0010: (null)
[ 18.280243] RSP: 0018:ffffb84bc260b9c0 EFLAGS: 00010246
[ 18.280244] RAX: 0000000000000000 RBX: ffff92f987f020f0 RCX: 0000000000000000
[ 18.280245] RDX: 0000000000000000 RSI: ffffb84bc260b9f8 RDI: ffff92f987f020f0
[ 18.280245] RBP: ffffb8bc260b9e8 R08: 0000000000000001 R09: 0000000000000000
[ 18.280246] R10: ffffb84bc260bd20 R11: 0000000000000000 R12: ffffb84bc260b9f8
[ 18.280246] R13: ffff92f987f008c0 R14: 00007ffdb75bec40 R15: 0000000000000000
[ 18.280247] FS: 00007fc0e8798700(0000) GS:ffff92f99fd80000(0000) knlGS:0000000000000000
[ 18.280248] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 18.280249] CR2: 0000000000000000 CR3: 0000000409b4c003 CR4: 00000000001606e0
[ 18.280249] Call Trace:
[ 18.280263] ? bnx2x_config_rss+0x2f/0xd0 [bnx2x]
[ 18.280270] bnx2x_rss+0x1d9/0x210 [bnx2x]
[ 18.280276] bnx2x_set_rxnfc+0x17d/0x380 [bnx2x]
[ 18.280279] ethtool_set_rxnfc+0x9b/0x110
[ 18.280281] ? __do_page_cache_readahead+0x1da/0x2c0
[ 18.280283] ? security_capable+0x3c/0x60
[ 18.280284] dev_ethtool+0350/0x2610
[ 18.280286] ? page_cache_async_readahead+0x71/0x80
[ 18.280288] ? page_add_file_rmap+0x5d/0x220
[ 18.280290] ? inet_ioctl+0x182/0x1a0
[ 18.280291] dev_ioctl+0x203/0x3f0
[ 18.280293] ? dev_ioctl+0x203/0x3f0
[ 18.280294] sock_do_ioctl+0xae/0x150
[ 18.280296] sock_ioctl+0x1e2/0x330
[ 18.280296] ? sock_ioctl+0x1e2/0x330
[ 18.280299] do_vfs_ioctl+0xa8/0x620
[ 18.280300] ? dlci_ioctl_set+0x30/0x30
[ 18.280301] ? do_vfs_ioctl+0xa8/0x620
[ 18.280302] ? handle_mm_fault+0xe3/0x220
[ 18.280304] ksys_ioctl+0x75/0x80
[ 18.280305] __x64_sys_ioctl+0x1a/0x20
[ 18.280307] do_syscall_64+0x5a/0x120
[ 18.280309] entry_SYSCALL_64_aftr_hwframe+0x44/0xa9
[ 18.280310] RIP: 0033:0x7fc0e7fba107
[ 18.280311] RSP: 002b:00007ffdb75beb78 EFLAGS: 00000206 ORIG_RAX: 0000000000000010
[ 18.280312] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007fc0e7fba107
[ 18.280312] RDX: 00007ffdb75bed60 RSI: 0000000000008946 RDI: 0000000000000003
[ 18.280313] RBP: 00007ffdb75bed50 R08: 00007ffdb75bed60 R09: 0000000000000001
[ 18.280313] R10: 0000000000000541 R11: 0000000000000206 R12: 00007ffdb75beed0
[ 18.280314] R13: 0000000000421020 R14: 000000000041fe28 R15: 0000000000000003
[ 18.280315] Code: Bad RIP value.
[ 18.280317] RIP: (null) RSP: ffffb84bc260b9c0
[ 18.280318] CR2: 0000000000000000
[ 18.280319] ---[ end trace 5f361db3fb9059f1 ]---
To reproduce this I created a bash script in "/etc/network/if-pre-up.d/" with these two lines:
ethtool -N $IFACE rx-flow-hash udp4 "sdfn"
ethtool -N $IFACE rx-flow-hash udp6 "sdfn"
The problem here is that rss_obj in bnx2x struct for the device hasn't been initialized yet, which causes an exception in bnx2x_config_rss() when calling "r->set_pending(r)" because r->set_pending is NULL. It looks like a lot many things haven't been initialized at this point, most of that happens in this
function: "bnx2x_init_bp_objs()" which isn't called until ifup. Any thoughts on how this can be fixed? Would it be possible to safely move bnx2x_init_bp_objs() to maybe bnx2x_init_one() which runs much before ifup?
Thanks,
Vishwanath
^ permalink raw reply
* Re: [PATCH bpf-next 2/3] bpf: btf: add btf json print functionality
From: Okash Khawaja @ 2018-06-22 10:24 UTC (permalink / raw)
To: Quentin Monnet
Cc: Daniel Borkmann, Martin KaFai Lau, Alexei Starovoitov,
Yonghong Song, Jakub Kicinski, David S. Miller, netdev,
kernel-team, linux-kernel
In-Reply-To: <3db6047a-101a-2ed1-9ca3-9e90b45ea00f@netronome.com>
On Thu, Jun 21, 2018 at 11:42:59AM +0100, Quentin Monnet wrote:
> Hi Okash,
hi and sorry about delay in responding. the email got routed to
incorrect folder.
>
> 2018-06-20 13:30 UTC-0700 ~ Okash Khawaja <osk@fb.com>
> > This consumes functionality exported in the previous patch. It does the
> > main job of printing with BTF data. This is used in the following patch
> > to provide a more readable output of a map's dump. It relies on
> > json_writer to do json printing. Below is sample output where map keys
> > are ints and values are of type struct A:
> >
> > typedef int int_type;
> > enum E {
> > E0,
> > E1,
> > };
> >
> > struct B {
> > int x;
> > int y;
> > };
> >
> > struct A {
> > int m;
> > unsigned long long n;
> > char o;
> > int p[8];
> > int q[4][8];
> > enum E r;
> > void *s;
> > struct B t;
> > const int u;
> > int_type v;
> > unsigned int w1: 3;
> > unsigned int w2: 3;
> > };
> >
> > $ sudo bpftool map dump -p id 14
> > [{
> > "key": 0
> > },{
> > "value": {
> > "m": 1,
> > "n": 2,
> > "o": "c",
> > "p": [15,16,17,18,15,16,17,18
> > ],
> > "q": [[25,26,27,28,25,26,27,28
> > ],[35,36,37,38,35,36,37,38
> > ],[45,46,47,48,45,46,47,48
> > ],[55,56,57,58,55,56,57,58
> > ]
> > ],
> > "r": 1,
> > "s": 0x7ffff6f70568,
>
> Hexadecimal values, without quotes, are not valid JSON. Please stick to
> decimal values.
ah sorry, i used a buggy json validator. this should be a quick fix.
which would be better: pointers be output hex strings or integers?
>
> > "t": {
> > "x": 5,
> > "y": 10
> > },
> > "u": 100,
> > "v": 20,
> > "w1": 0x7,
> > "w2": 0x3
> > }
> > }
> > ]
> >
> > This patch uses json's {} and [] to imply struct/union and array. More
> > explicit information can be added later. For example, a command line
> > option can be introduced to print whether a key or value is struct
> > or union, name of a struct etc. This will however come at the expense
> > of duplicating info when, for example, printing an array of structs.
> > enums are printed as ints without their names.
> >
> > Signed-off-by: Okash Khawaja <osk@fb.com>
> > Acked-by: Martin KaFai Lau <kafai@fb.com>
> >
> > ---
> > tools/bpf/bpftool/btf_dumper.c | 247 +++++++++++++++++++++++++++++++++++++++++
> > tools/bpf/bpftool/btf_dumper.h | 18 ++
> > 2 files changed, 265 insertions(+)
> >
> > --- /dev/null
> > +++ b/tools/bpf/bpftool/btf_dumper.c
> > @@ -0,0 +1,247 @@
> > +/* SPDX-License-Identifier: GPL-2.0 */
> > +/* Copyright (c) 2018 Facebook */
> > +
> > +#include <linux/btf.h>
> > +#include <linux/err.h>
> > +#include <stdio.h> /* for (FILE *) used by json_writer */
> > +#include <linux/bitops.h>
> > +#include <string.h>
> > +#include <ctype.h>
> > +
> > +#include "btf.h"
> > +#include "json_writer.h"
> > +
> > +#define BITS_PER_BYTE_MASK (BITS_PER_BYTE - 1)
> > +#define BITS_PER_BYTE_MASKED(bits) ((bits) & BITS_PER_BYTE_MASK)
> > +#define BITS_ROUNDDOWN_BYTES(bits) ((bits) >> 3)
> > +#define BITS_ROUNDUP_BYTES(bits) \
> > + (BITS_ROUNDDOWN_BYTES(bits) + !!BITS_PER_BYTE_MASKED(bits))
> > +
> > +static int btf_dumper_do_type(const struct btf *btf, uint32_t type_id,
> > + uint8_t bit_offset, const void *data, json_writer_t *jw);
> > +
> > +static void btf_dumper_ptr(const void *data, json_writer_t *jw)
> > +{
> > + jsonw_printf(jw, "%p", *((uintptr_t *)data));
> > +}
> > +
> > +static int btf_dumper_modifier(const struct btf *btf, uint32_t type_id,
> > + const void *data, json_writer_t *jw)
> > +{
> > + int32_t actual_type_id = btf__resolve_type(btf, type_id);
> > + int ret;
> > +
> > + if (actual_type_id < 0)
> > + return actual_type_id;
> > +
> > + ret = btf_dumper_do_type(btf, actual_type_id, 0, data, jw);
> > +
> > + return ret;
> > +}
> > +
> > +static void btf_dumper_enum(const void *data, json_writer_t *jw)
> > +{
> > + jsonw_printf(jw, "%d", *((int32_t *)data));
> > +}
> > +
> > +static int btf_dumper_array(const struct btf *btf, uint32_t type_id,
> > + const void *data, json_writer_t *jw)
> > +{
> > + const struct btf_type *t = btf__type_by_id(btf, type_id);
> > + struct btf_array *arr = (struct btf_array *)(t + 1);
> > + int64_t elem_size;
> > + uint32_t i;
> > + int ret;
> > +
> > + elem_size = btf__resolve_size(btf, arr->type);
> > + if (elem_size < 0)
> > + return elem_size;
> > +
> > + jsonw_start_array(jw);
> > + for (i = 0; i < arr->nelems; i++) {
> > + ret = btf_dumper_do_type(btf, arr->type, 0,
> > + data + (i * elem_size), jw);
> > + if (ret)
> > + return ret;
> > + }
> > +
> > + jsonw_end_array(jw);
> > +
> > + return 0;
> > +}
> > +
> > +static void btf_dumper_int_bits(uint32_t int_type, uint8_t bit_offset,
> > + const void *data, json_writer_t *jw)
> > +{
> > + uint16_t total_bits_offset;
> > + uint32_t bits = BTF_INT_BITS(int_type);
>
> Nit: Please use reverse-Christmas-tree here.
>
> As for patch 3 you also have a number of continuation lines not aligned
> on the opening parenthesis from the first line, throughout the patch
> (please consider running checkpatch in "--strict" mode for the list).
i didn't use "--strict". that would explain style mismatch. will fix
that in v2.
>
> > + uint16_t bytes_to_copy;
> > + uint16_t bits_to_copy;
> > + uint8_t upper_bits;
> > + union {
> > + uint64_t u64_num;
> > + uint8_t u8_nums[8];
> > + } print_num;
> > +
> > + total_bits_offset = bit_offset + BTF_INT_OFFSET(int_type);
> > + data += BITS_ROUNDDOWN_BYTES(total_bits_offset);
> > + bit_offset = BITS_PER_BYTE_MASKED(total_bits_offset);
> > + bits_to_copy = bits + bit_offset;
> > + bytes_to_copy = BITS_ROUNDUP_BYTES(bits_to_copy);
> > +
> > + print_num.u64_num = 0;
> > + memcpy(&print_num.u64_num, data, bytes_to_copy);
> > +
> > + upper_bits = BITS_PER_BYTE_MASKED(bits_to_copy);
> > + if (upper_bits) {
> > + uint8_t mask = (1 << upper_bits) - 1;
> > +
> > + print_num.u8_nums[bytes_to_copy - 1] &= mask;
> > + }
> > +
> > + print_num.u64_num >>= bit_offset;
> > +
> > + jsonw_printf(jw, "0x%llx", print_num.u64_num);
> > +}
> > +
> > +static int btf_dumper_int(const struct btf_type *t, uint8_t bit_offset,
> > + const void *data, json_writer_t *jw)
> > +{
> > + uint32_t *int_type = (uint32_t *)(t + 1);
> > + uint32_t bits = BTF_INT_BITS(*int_type);
> > + int ret = 0;
> > +
> > + /* if this is bit field */
> > + if (bit_offset || BTF_INT_OFFSET(*int_type) ||
> > + BITS_PER_BYTE_MASKED(bits)) {
> > + btf_dumper_int_bits(*int_type, bit_offset, data, jw);
> > + return ret;
> > + }
> > +
> > + switch (BTF_INT_ENCODING(*int_type)) {
> > + case 0:
> > + if (BTF_INT_BITS(*int_type) == 64)
> > + jsonw_printf(jw, "%lu", *((uint64_t *)data));
> > + else if (BTF_INT_BITS(*int_type) == 32)
> > + jsonw_printf(jw, "%u", *((uint32_t *)data));
> > + else if (BTF_INT_BITS(*int_type) == 16)
> > + jsonw_printf(jw, "%hu", *((uint16_t *)data));
> > + else if (BTF_INT_BITS(*int_type) == 8)
> > + jsonw_printf(jw, "%hhu", *((uint8_t *)data));
> > + else
> > + btf_dumper_int_bits(*int_type, bit_offset, data, jw);
> > + break;
> > + case BTF_INT_SIGNED:
> > + if (BTF_INT_BITS(*int_type) == 64)
> > + jsonw_printf(jw, "%ld", *((int64_t *)data));
> > + else if (BTF_INT_BITS(*int_type) == 32)
> > + jsonw_printf(jw, "%d", *((int32_t *)data));
> > + else if (BTF_INT_BITS(*int_type) == 16)
> > + jsonw_printf(jw, "%hd", *((int16_t *)data));
> > + else if (BTF_INT_BITS(*int_type) == 8)
> > + jsonw_printf(jw, "%hhd", *((int8_t *)data));
> > + else
> > + btf_dumper_int_bits(*int_type, bit_offset, data, jw);
> > + break;
> > + case BTF_INT_CHAR:
> > + if (*((char *)data) == '\0')
> > + jsonw_null(jw);
> > + else if (isprint(*((char *)data)))
> > + jsonw_printf(jw, "\"%c\"", *((char *)data));
> > + else
> > + jsonw_printf(jw, "%hhx", *((char *)data));
> > + break;
> > + case BTF_INT_BOOL:
> > + jsonw_bool(jw, *((int *)data));
> > + break;
> > + default:
> > + /* shouldn't happen */
> > + ret = -EINVAL;
> > + break;
> > + }
> > +
> > + return ret;
> > +}
> > +
> > +static int btf_dumper_struct(const struct btf *btf, uint32_t type_id,
> > + const void *data, json_writer_t *jw)
> > +{
> > + const struct btf_type *t = btf__type_by_id(btf, type_id);
> > + struct btf_member *m;
> > + int ret = 0;
> > + int i, vlen;
> > +
> > + if (t == NULL)
> > + return -EINVAL;
> > +
> > + vlen = BTF_INFO_VLEN(t->info);
> > + jsonw_start_object(jw);
> > + m = (struct btf_member *)(t + 1);
> > +
> > + for (i = 0; i < vlen; i++) {
> > + jsonw_name(jw, btf__name_by_offset(btf, m[i].name_off));
> > + ret = btf_dumper_do_type(btf, m[i].type,
> > + BITS_PER_BYTE_MASKED(m[i].offset),
> > + data + BITS_ROUNDDOWN_BYTES(m[i].offset), jw);
> > + if (ret)
> > + return ret;
> > + }
> > +
> > + jsonw_end_object(jw);
> > +
> > + return 0;
> > +}
> > +
> > +static int btf_dumper_do_type(const struct btf *btf, uint32_t type_id,
> > + uint8_t bit_offset, const void *data, json_writer_t *jw)
> > +{
> > + const struct btf_type *t = btf__type_by_id(btf, type_id);
> > + int ret = 0;
> > +
> > + switch (BTF_INFO_KIND(t->info)) {
> > + case BTF_KIND_INT:
> > + ret = btf_dumper_int(t, bit_offset, data, jw);
> > + break;
> > + case BTF_KIND_STRUCT:
> > + case BTF_KIND_UNION:
> > + ret = btf_dumper_struct(btf, type_id, data, jw);
> > + break;
> > + case BTF_KIND_ARRAY:
> > + ret = btf_dumper_array(btf, type_id, data, jw);
> > + break;
> > + case BTF_KIND_ENUM:
> > + btf_dumper_enum(data, jw);
> > + break;
> > + case BTF_KIND_PTR:
> > + btf_dumper_ptr(data, jw);
> > + break;
> > + case BTF_KIND_UNKN:
> > + jsonw_printf(jw, "(unknown)");
> > + break;
> > + case BTF_KIND_FWD:
> > + /* map key or value can't be forward */
> > + ret = -EINVAL;
> > + break;
> > + case BTF_KIND_TYPEDEF:
> > + case BTF_KIND_VOLATILE:
> > + case BTF_KIND_CONST:
> > + case BTF_KIND_RESTRICT:
> > + ret = btf_dumper_modifier(btf, type_id, data, jw);
> > + break;
> > + default:
> > + jsonw_printf(jw, "(unsupported-kind");
> > + ret = -EINVAL;
> > + break;
> > + }
> > +
> > + return ret;
> > +}
> > +
> > +int32_t btf_dumper_type(const struct btf *btf, json_writer_t *jw,
> > + uint32_t type_id, const void *data)
> > +{
> > + if (!jw)
> > + return -EINVAL;
> > +
> > + return btf_dumper_do_type(btf, type_id, 0, data, jw);
> > +}
> > --- /dev/null
> > +++ b/tools/bpf/bpftool/btf_dumper.h
> > @@ -0,0 +1,18 @@
> > +/* SPDX-License-Identifier: GPL-2.0 */
>
> I believe SPDX tag in header files should use C++ style comments (//)?
okay i will verify and fix that.
>
> > +/* Copyright (c) 2018 Facebook */
> > +
> > +#ifndef BTF_DUMPER_H
> > +#define BTF_DUMPER_H
> > +
> > +/* btf_dumper_type - json print data along with type information
> > + * @btf: btf instance initialised via btf__new()
> > + * @jw: json writer used for printing
> > + * @type_id: index in btf->types array. this points to the type to be dumped
> > + * @data: pointer the actual data, i.e. the values to be printed
> > + *
> > + * Returns zero on success and negative error code otherwise
> > + */
> > +int32_t btf_dumper_type(const struct btf *btf, json_writer_t *jw,
> > + uint32_t type_id, void *data);
> > +
> > +#endif
> >
>
> Thanks,
> Quentin
^ permalink raw reply
* Re: [PATCH bpf-next 2/3] bpf: btf: add btf json print functionality
From: Quentin Monnet @ 2018-06-22 10:39 UTC (permalink / raw)
To: Okash Khawaja
Cc: Daniel Borkmann, Martin KaFai Lau, Alexei Starovoitov,
Yonghong Song, Jakub Kicinski, David S. Miller, netdev,
kernel-team, linux-kernel
In-Reply-To: <20180622102428.GA3050@w1t1fb>
2018-06-22 11:24 UTC+0100 ~ Okash Khawaja <osk@fb.com>
> On Thu, Jun 21, 2018 at 11:42:59AM +0100, Quentin Monnet wrote:
>> Hi Okash,
> hi and sorry about delay in responding. the email got routed to
> incorrect folder.
>>
>> 2018-06-20 13:30 UTC-0700 ~ Okash Khawaja <osk@fb.com>
>>> This consumes functionality exported in the previous patch. It does the
>>> main job of printing with BTF data. This is used in the following patch
>>> to provide a more readable output of a map's dump. It relies on
>>> json_writer to do json printing. Below is sample output where map keys
>>> are ints and values are of type struct A:
>>>
>>> typedef int int_type;
>>> enum E {
>>> E0,
>>> E1,
>>> };
>>>
>>> struct B {
>>> int x;
>>> int y;
>>> };
>>>
>>> struct A {
>>> int m;
>>> unsigned long long n;
>>> char o;
>>> int p[8];
>>> int q[4][8];
>>> enum E r;
>>> void *s;
>>> struct B t;
>>> const int u;
>>> int_type v;
>>> unsigned int w1: 3;
>>> unsigned int w2: 3;
>>> };
>>>
>>> $ sudo bpftool map dump -p id 14
>>> [{
>>> "key": 0
>>> },{
>>> "value": {
>>> "m": 1,
>>> "n": 2,
>>> "o": "c",
>>> "p": [15,16,17,18,15,16,17,18
>>> ],
>>> "q": [[25,26,27,28,25,26,27,28
>>> ],[35,36,37,38,35,36,37,38
>>> ],[45,46,47,48,45,46,47,48
>>> ],[55,56,57,58,55,56,57,58
>>> ]
>>> ],
>>> "r": 1,
>>> "s": 0x7ffff6f70568,
>>
>> Hexadecimal values, without quotes, are not valid JSON. Please stick to
>> decimal values.
> ah sorry, i used a buggy json validator. this should be a quick fix.
> which would be better: pointers be output hex strings or integers?
I would go for integers. Although this is harder to read for humans, it
is easier to process for machines, which remain the primary targets for
JSON output.
Quentin
^ permalink raw reply
* Re: WARNING: CPU: 3 PID: 0 at net/sched/sch_hfsc.c:1388 hfsc_dequeue+0x319/0x350 [sch_hfsc]
From: Marco Berizzi @ 2018-06-22 11:05 UTC (permalink / raw)
To: Cong Wang; +Cc: Linux Kernel Network Developers
In-Reply-To: <CAM_iQpVEZFL==0BuQh26Wh-TEJ-hmz7NwGry2g7EZiK-FCjKAQ@mail.gmail.com>
> Il 21 giugno 2018 alle 1.00 Cong Wang <xiyou.wangcong@gmail.com> ha scritto:
> Please also test HFSC_RSC ("rt") if possible.
Hi Cong,
sorry for the delayed response.
I have tested this hfsc rt setup:
tc class add dev eth2 parent 1:2 classid 1:16 hfsc rt m2 500kbit
and
tc class add dev eth2 parent 1:2 classid 1:16 hfsc rt m2 5000kbit
and
tc class add dev eth2 parent 1:2 classid 1:16 hfsc rt m2 20000kbit
and I was getting the expected throughput specified by the m2
parameter.
> If you can confirm nothing breaks, I will send it out formally.
after 52 hours uptime I don't see the previous error anymore.
> Thanks for testing!
and thanks for the patch.
^ permalink raw reply
* [PATCH v4] net: Remove depends on HAS_DMA in case of platform dependency
From: Geert Uytterhoeven @ 2018-06-22 11:08 UTC (permalink / raw)
To: David S . Miller, Yisen Zhuang, Sergey Matyukevich, Salil Mehta,
Kalle Valo, Igor Mitsyanko, Avinash Patil
Cc: Wright Feng, Sergei Shtylyov, Quan Nguyen, Keyur Chudgar,
Jiri Pirko, Iyappan Subramanian, Ido Schimmel, Hante Meuleman,
Franky Lin, Chi-Hsien Lin, Arend van Spriel, netdev, linux-kernel,
Geert Uytterhoeven
Remove dependencies on HAS_DMA where a Kconfig symbol depends on another
symbol that implies HAS_DMA, and, optionally, on "|| COMPILE_TEST".
In most cases this other symbol is an architecture or platform specific
symbol, or PCI.
Generic symbols and drivers without platform dependencies keep their
dependencies on HAS_DMA, to prevent compiling subsystems or drivers that
cannot work anyway.
This simplifies the dependencies, and allows to improve compile-testing.
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Reviewed-by: Mark Brown <broonie@kernel.org>
Acked-by: Robin Murphy <robin.murphy@arm.com>
---
v4:
- Rebase to v4.18-rc1 (applies to next-20180622, too),
v3:
- Rebase to v4.17-rc1,
- Drop obsolete note about FSL_FMAN,
v2:
- Add Reviewed-by, Acked-by,
- Drop RFC state,
- Split per subsystem.
---
drivers/net/ethernet/amd/Kconfig | 2 +-
drivers/net/ethernet/apm/xgene-v2/Kconfig | 1 -
drivers/net/ethernet/apm/xgene/Kconfig | 1 -
drivers/net/ethernet/arc/Kconfig | 6 ++++--
drivers/net/ethernet/broadcom/Kconfig | 2 --
drivers/net/ethernet/calxeda/Kconfig | 2 +-
drivers/net/ethernet/hisilicon/Kconfig | 2 +-
drivers/net/ethernet/marvell/Kconfig | 8 +++-----
drivers/net/ethernet/mellanox/mlxsw/Kconfig | 2 +-
drivers/net/ethernet/renesas/Kconfig | 2 --
drivers/net/wireless/broadcom/brcm80211/Kconfig | 1 -
drivers/net/wireless/quantenna/qtnfmac/Kconfig | 2 +-
12 files changed, 12 insertions(+), 19 deletions(-)
diff --git a/drivers/net/ethernet/amd/Kconfig b/drivers/net/ethernet/amd/Kconfig
index d5c15e8bb3de706b..f273af136fc7c995 100644
--- a/drivers/net/ethernet/amd/Kconfig
+++ b/drivers/net/ethernet/amd/Kconfig
@@ -173,7 +173,7 @@ config SUNLANCE
config AMD_XGBE
tristate "AMD 10GbE Ethernet driver"
- depends on ((OF_NET && OF_ADDRESS) || ACPI || PCI) && HAS_IOMEM && HAS_DMA
+ depends on ((OF_NET && OF_ADDRESS) || ACPI || PCI) && HAS_IOMEM
depends on X86 || ARM64 || COMPILE_TEST
select BITREVERSE
select CRC32
diff --git a/drivers/net/ethernet/apm/xgene-v2/Kconfig b/drivers/net/ethernet/apm/xgene-v2/Kconfig
index 1205861b631896a0..eedd3f3dd22e2201 100644
--- a/drivers/net/ethernet/apm/xgene-v2/Kconfig
+++ b/drivers/net/ethernet/apm/xgene-v2/Kconfig
@@ -1,6 +1,5 @@
config NET_XGENE_V2
tristate "APM X-Gene SoC Ethernet-v2 Driver"
- depends on HAS_DMA
depends on ARCH_XGENE || COMPILE_TEST
help
This is the Ethernet driver for the on-chip ethernet interface
diff --git a/drivers/net/ethernet/apm/xgene/Kconfig b/drivers/net/ethernet/apm/xgene/Kconfig
index afccb033177b3923..e4e33c900b577161 100644
--- a/drivers/net/ethernet/apm/xgene/Kconfig
+++ b/drivers/net/ethernet/apm/xgene/Kconfig
@@ -1,6 +1,5 @@
config NET_XGENE
tristate "APM X-Gene SoC Ethernet Driver"
- depends on HAS_DMA
depends on ARCH_XGENE || COMPILE_TEST
select PHYLIB
select MDIO_XGENE
diff --git a/drivers/net/ethernet/arc/Kconfig b/drivers/net/ethernet/arc/Kconfig
index e743ddf46343302f..5d0ab8e74b680cc6 100644
--- a/drivers/net/ethernet/arc/Kconfig
+++ b/drivers/net/ethernet/arc/Kconfig
@@ -24,7 +24,8 @@ config ARC_EMAC_CORE
config ARC_EMAC
tristate "ARC EMAC support"
select ARC_EMAC_CORE
- depends on OF_IRQ && OF_NET && HAS_DMA && (ARC || COMPILE_TEST)
+ depends on OF_IRQ && OF_NET
+ depends on ARC || COMPILE_TEST
---help---
On some legacy ARC (Synopsys) FPGA boards such as ARCAngel4/ML50x
non-standard on-chip ethernet device ARC EMAC 10/100 is used.
@@ -33,7 +34,8 @@ config ARC_EMAC
config EMAC_ROCKCHIP
tristate "Rockchip EMAC support"
select ARC_EMAC_CORE
- depends on OF_IRQ && OF_NET && REGULATOR && HAS_DMA && (ARCH_ROCKCHIP || COMPILE_TEST)
+ depends on OF_IRQ && OF_NET && REGULATOR
+ depends on ARCH_ROCKCHIP || COMPILE_TEST
---help---
Support for Rockchip RK3036/RK3066/RK3188 EMAC ethernet controllers.
This selects Rockchip SoC glue layer support for the
diff --git a/drivers/net/ethernet/broadcom/Kconfig b/drivers/net/ethernet/broadcom/Kconfig
index af75156919edfead..4c3bfde6e8de00f2 100644
--- a/drivers/net/ethernet/broadcom/Kconfig
+++ b/drivers/net/ethernet/broadcom/Kconfig
@@ -157,7 +157,6 @@ config BGMAC
config BGMAC_BCMA
tristate "Broadcom iProc GBit BCMA support"
depends on BCMA && BCMA_HOST_SOC
- depends on HAS_DMA
depends on BCM47XX || ARCH_BCM_5301X || COMPILE_TEST
select BGMAC
select PHYLIB
@@ -170,7 +169,6 @@ config BGMAC_BCMA
config BGMAC_PLATFORM
tristate "Broadcom iProc GBit platform support"
- depends on HAS_DMA
depends on ARCH_BCM_IPROC || COMPILE_TEST
depends on OF
select BGMAC
diff --git a/drivers/net/ethernet/calxeda/Kconfig b/drivers/net/ethernet/calxeda/Kconfig
index 07d2201530d26c85..9fdd496b90ff47cb 100644
--- a/drivers/net/ethernet/calxeda/Kconfig
+++ b/drivers/net/ethernet/calxeda/Kconfig
@@ -1,6 +1,6 @@
config NET_CALXEDA_XGMAC
tristate "Calxeda 1G/10G XGMAC Ethernet driver"
- depends on HAS_IOMEM && HAS_DMA
+ depends on HAS_IOMEM
depends on ARCH_HIGHBANK || COMPILE_TEST
select CRC32
help
diff --git a/drivers/net/ethernet/hisilicon/Kconfig b/drivers/net/ethernet/hisilicon/Kconfig
index 8bcf470ff5f38a4e..fb1a7251f45d3369 100644
--- a/drivers/net/ethernet/hisilicon/Kconfig
+++ b/drivers/net/ethernet/hisilicon/Kconfig
@@ -5,7 +5,7 @@
config NET_VENDOR_HISILICON
bool "Hisilicon devices"
default y
- depends on (OF || ACPI) && HAS_DMA
+ depends on OF || ACPI
depends on ARM || ARM64 || COMPILE_TEST
---help---
If you have a network (Ethernet) card belonging to this class, say Y.
diff --git a/drivers/net/ethernet/marvell/Kconfig b/drivers/net/ethernet/marvell/Kconfig
index cc2f7701e71e1b03..f33fd22b351c856a 100644
--- a/drivers/net/ethernet/marvell/Kconfig
+++ b/drivers/net/ethernet/marvell/Kconfig
@@ -18,8 +18,8 @@ if NET_VENDOR_MARVELL
config MV643XX_ETH
tristate "Marvell Discovery (643XX) and Orion ethernet support"
- depends on (MV64X60 || PPC32 || PLAT_ORION || COMPILE_TEST) && INET
- depends on HAS_DMA
+ depends on MV64X60 || PPC32 || PLAT_ORION || COMPILE_TEST
+ depends on INET
select PHYLIB
select MVMDIO
---help---
@@ -58,7 +58,6 @@ config MVNETA_BM_ENABLE
config MVNETA
tristate "Marvell Armada 370/38x/XP/37xx network interface support"
depends on ARCH_MVEBU || COMPILE_TEST
- depends on HAS_DMA
select MVMDIO
select PHYLINK
---help---
@@ -84,7 +83,6 @@ config MVNETA_BM
config MVPP2
tristate "Marvell Armada 375/7K/8K network interface support"
depends on ARCH_MVEBU || COMPILE_TEST
- depends on HAS_DMA
select MVMDIO
select PHYLINK
---help---
@@ -93,7 +91,7 @@ config MVPP2
config PXA168_ETH
tristate "Marvell pxa168 ethernet support"
- depends on HAS_IOMEM && HAS_DMA
+ depends on HAS_IOMEM
depends on CPU_PXA168 || ARCH_BERLIN || COMPILE_TEST
select PHYLIB
---help---
diff --git a/drivers/net/ethernet/mellanox/mlxsw/Kconfig b/drivers/net/ethernet/mellanox/mlxsw/Kconfig
index f4d9c9975ac3d857..82827a8d3d67cac7 100644
--- a/drivers/net/ethernet/mellanox/mlxsw/Kconfig
+++ b/drivers/net/ethernet/mellanox/mlxsw/Kconfig
@@ -30,7 +30,7 @@ config MLXSW_CORE_THERMAL
config MLXSW_PCI
tristate "PCI bus implementation for Mellanox Technologies Switch ASICs"
- depends on PCI && HAS_DMA && HAS_IOMEM && MLXSW_CORE
+ depends on PCI && HAS_IOMEM && MLXSW_CORE
default m
---help---
This is PCI bus implementation for Mellanox Technologies Switch ASICs.
diff --git a/drivers/net/ethernet/renesas/Kconfig b/drivers/net/ethernet/renesas/Kconfig
index 27be51f0a421b43e..f3f7477043ce1061 100644
--- a/drivers/net/ethernet/renesas/Kconfig
+++ b/drivers/net/ethernet/renesas/Kconfig
@@ -17,7 +17,6 @@ if NET_VENDOR_RENESAS
config SH_ETH
tristate "Renesas SuperH Ethernet support"
- depends on HAS_DMA
depends on ARCH_RENESAS || SUPERH || COMPILE_TEST
select CRC32
select MII
@@ -31,7 +30,6 @@ config SH_ETH
config RAVB
tristate "Renesas Ethernet AVB support"
- depends on HAS_DMA
depends on ARCH_RENESAS || COMPILE_TEST
select CRC32
select MII
diff --git a/drivers/net/wireless/broadcom/brcm80211/Kconfig b/drivers/net/wireless/broadcom/brcm80211/Kconfig
index 9d99eb42d9176f0f..6acba67bca07abd7 100644
--- a/drivers/net/wireless/broadcom/brcm80211/Kconfig
+++ b/drivers/net/wireless/broadcom/brcm80211/Kconfig
@@ -60,7 +60,6 @@ config BRCMFMAC_PCIE
bool "PCIE bus interface support for FullMAC driver"
depends on BRCMFMAC
depends on PCI
- depends on HAS_DMA
select BRCMFMAC_PROTO_MSGBUF
select FW_LOADER
---help---
diff --git a/drivers/net/wireless/quantenna/qtnfmac/Kconfig b/drivers/net/wireless/quantenna/qtnfmac/Kconfig
index 025fa6018550895a..8d1492a90bd135c0 100644
--- a/drivers/net/wireless/quantenna/qtnfmac/Kconfig
+++ b/drivers/net/wireless/quantenna/qtnfmac/Kconfig
@@ -7,7 +7,7 @@ config QTNFMAC
config QTNFMAC_PEARL_PCIE
tristate "Quantenna QSR10g PCIe support"
default n
- depends on HAS_DMA && PCI && CFG80211
+ depends on PCI && CFG80211
select QTNFMAC
select FW_LOADER
select CRC32
--
2.17.1
^ permalink raw reply related
* Re: [PATCH bpf-next 2/3] bpf: btf: add btf json print functionality
From: Okash Khawaja @ 2018-06-22 11:17 UTC (permalink / raw)
To: Martin KaFai Lau
Cc: Jakub Kicinski, Daniel Borkmann, Alexei Starovoitov,
Yonghong Song, Quentin Monnet, David S. Miller, netdev,
kernel-team, linux-kernel
In-Reply-To: <20180622012052.htkvholi674x6i4f@kafai-mbp.dhcp.thefacebook.com>
On Thu, Jun 21, 2018 at 06:20:52PM -0700, Martin KaFai Lau wrote:
> On Thu, Jun 21, 2018 at 05:25:23PM -0700, Jakub Kicinski wrote:
> > On Thu, 21 Jun 2018 16:58:15 -0700, Martin KaFai Lau wrote:
> > > On Thu, Jun 21, 2018 at 04:07:19PM -0700, Jakub Kicinski wrote:
> > > > On Thu, 21 Jun 2018 15:51:17 -0700, Martin KaFai Lau wrote:
> > > > > On Thu, Jun 21, 2018 at 02:59:35PM -0700, Jakub Kicinski wrote:
> > > > > > On Wed, 20 Jun 2018 13:30:53 -0700, Okash Khawaja wrote:
> > > > > > > $ sudo bpftool map dump -p id 14
> > > > > > > [{
> > > > > > > "key": 0
> > > > > > > },{
> > > > > > > "value": {
> > > > > > > "m": 1,
> > > > > > > "n": 2,
> > > > > > > "o": "c",
> > > > > > > "p": [15,16,17,18,15,16,17,18
> > > > > > > ],
> > > > > > > "q": [[25,26,27,28,25,26,27,28
> > > > > > > ],[35,36,37,38,35,36,37,38
> > > > > > > ],[45,46,47,48,45,46,47,48
> > > > > > > ],[55,56,57,58,55,56,57,58
> > > > > > > ]
> > > > > > > ],
> > > > > > > "r": 1,
> > > > > > > "s": 0x7ffff6f70568,
> > > > > > > "t": {
> > > > > > > "x": 5,
> > > > > > > "y": 10
> > > > > > > },
> > > > > > > "u": 100,
> > > > > > > "v": 20,
> > > > > > > "w1": 0x7,
> > > > > > > "w2": 0x3
> > > > > > > }
> > > > > > > }
> > > > > > > ]
> > > > > >
> > > > > > I don't think this format is okay, JSON output is an API you shouldn't
> > > > > > break. You can change the non-JSON output whatever way you like, but
> > > > > > JSON must remain backwards compatible.
> > > > > >
> > > > > > The dump today has object per entry, e.g.:
> > > > > >
> > > > > > {
> > > > > > "key":["0x00","0x00","0x00","0x00",
> > > > > > ],
> > > > > > "value": ["0x02","0x00","0x00","0x00","0x00","0x00","0x00","0x00"
> > > > > > ]
> > > > > > }
> > > > > >
> > > > > > This format must remain, you may only augment it with new fields. E.g.:
> > > > > >
> > > > > > {
> > > > > > "key":["0x00","0x00","0x00","0x00",
> > > > > > ],
> > > > > > "key_struct":{
> > > > > > "index":0
> > > > > > },
> Got a few questions.
>
> When we support hashtab later, the key could be int
> but reusing the name as "index" is weird.
> The key could also be a struct (e.g. a struct to describe ip:port).
> Can you suggest how the "key_struct" will look like?
>
> > > > > > "value": ["0x02","0x00","0x00","0x00","0x00","0x00","0x00","0x00"
> > > > > > ],
> > > > > > "value_struct":{
> > > > > > "src_ip":2,
> If for the same map the user changes the "src_ip" to an array of int[4]
> later (e.g. to support ipv6), it will become "src_ip": [1, 2, 3, 4].
> Is it breaking backward compat?
> i.e.
> struct five_tuples {
> - int src_ip;
> + int src_ip[4];
> /* ... */
> };
>
> > > > > > "dst_ip:0
> > > > > > }
> > > > > > }
> > > > > I am not sure how useful to have both "key|value" and "(key|value)_struct"
> > > > > while most people would prefer "key_struct"/"value_struct" if it is
> > > > > available.
> > > >
> > > > Agreed, it's not that useful, especially with the string-hex debacle :(
> > > > It's just about the backwards compat.
> > > >
> > > > > How about introducing a new option, like "-b", to print the
> > > > > map with BTF (if available) such that it won't break the existing
> > > > > one (-j or -p) while the "-b" output can keep using the "key"
> > > > > and "value".
> > > > >
> > > > > The existing json can be kept as is.
> > > >
> > > > That was my knee jerk reaction too, but on reflection it doesn't sound
> > > > that great. We expect people with new-enough bpftool to use btf, so it
> > > > should be available in the default output, without hiding it behind a
> > > > switch. We could add a switch to hide the old output, but that doesn't
> > > > give us back the names... What about Key and Value or k and v? Or
> > > > key_fields and value_fields?
> > > I thought the current default output is "plain" ;)
> > > Having said that, yes, the btf is currently printed in json.
> > >
> > > Ideally, the default json output should do what most people want:
> > > print btf and btf only (if it is available).
> > > but I don't see a way out without new option if we need to
> > > be backward compat :(
> > >
> > > Agree that showing the btf in the existing json output will be useful (e.g.
> > > to hint people that BTF is available). If btf is showing in old json,
> > > also agree that the names should be the same with the new json.
> > > key_fields and value_fields may hint it has >1 fields though.
> > > May be "formatted_key" and "formatted_value"?
> >
> > SGTM! Or even maybe as a "formatted" object?:
> >
> > {
> > "key":["0x00","0x00","0x00","0x00",
> > ],
> > "value": ["0x02","0x00","0x00","0x00","0x00","0x00","0x00","0x00"
> > ],
> > "formatted":{
> > "key":{
> > "index":0
> > },
> > "value":{
> > "src_ip":2,
> > "dst_ip:0
> > }
> > }
> hmm... that is an extra indentation (keep in mind that the "value" could
> already have a few nested structs which itself consumes a few indentations)
> but I guess adding another one may be ok-ish.
>
> > }
> >
> > > > > > The name XYZ_struct may not be the best, perhaps you can come up with a
> > > > > > better one?
> > > > > >
> > > > > > Does that make sense? Am I missing what you're doing here?
> > > > > >
> > > > > > One process note - please make sure you run checkpatch.pl --strict on
> > > > > > bpftool patches before posting.
> > > > > >
> > > > > > Thanks for working on this!
> >
Hi,
While I agree on the point of backward compatibility, I think printing
two overlapping pieces of information side-by-side will make the
interface less clear. Having separate outputs for the two will keep the
interface clear and readable.
Is there a major downside to adding a new flag for BTF output?
Thanks,
Okash
^ permalink raw reply
* Crash in netlink/sk_filter_trim_cap on ARMv7 on 4.18rc1
From: Peter Robinson @ 2018-06-22 11:19 UTC (permalink / raw)
To: netdev, linux-arm-kernel; +Cc: labbott
Hi All,
I'm seeing this netlink/sk_filter_trim_cap crash on ARMv7 across quite
a few ARMv7 platforms on Fedora with 4.18rc1. I've tested RPi2/RPi3
(doesn't happen on aarch64), AllWinner H3, BeagleBone and a few
others, both LPAE/normal kernels.
I'm a bit out of my depth in this part of the kernel but I'm wondering
if it's known, I couldn't find anything that looked obvious on a few
mailing lists.
Peter
[ 9.955543] Modules linked in:
[ 9.955562] CPU: 1 PID: 213 Comm: systemd-udevd Tainted: G D
4.18.0-0.rc1.git0.1.fc29.armv7hl #1
[ 9.955566] Hardware name: BCM2835
[ 9.955584] PC is at sk_filter_trim_cap+0x15c/0x1b8
[ 9.955590] LR is at (null)
[ 9.955597] pc : [<c09d4d58>] lr : [<00000000>] psr: 60000013
[ 9.955602] sp : c2cf9d58 ip : 00000000 fp : 00000000
[ 9.955608] r10: ef2c3c00 r9 : c13093c0 r8 : 00000000
[ 9.955615] r7 : 00000000 r6 : 00000001 r5 : f0f6a000 r4 : 00000000
[ 9.955621] r3 : 00000007 r2 : 00000000 r1 : 00000000 r0 : 00000000
[ 9.955629] Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none
[ 9.955640] Control: 10c5387d Table: 02e6406a DAC: 00000051
[ 9.963334] Unable to handle kernel NULL pointer dereference at
virtual address 0000000c
[ 9.964631] Process systemd-udevd (pid: 213, stack limit = 0x(ptrval))
[ 9.964640] Stack: (0xc2cf9d58 to 0xc2cfa000)
[ 9.964649] 9d40:
00000000 c2c90540
[ 9.964663] 9d60: 006000c0 00000000 00000000 c09a233c c2c90b40
c2c90b40 c2c90540 00000000
[ 9.964678] 9d80: 00000000 00000000 c13093c0 c09fa2bc 006000c0
00000001 ee7f1800 00000000
[ 9.964691] 9da0: 00000002 00000000 00000001 ef2c3c64 c2cf9f70
00000002 c2c90540 00000000
[ 9.964706] 9dc0: c2cf9f68 00000083 ee7f1800 00000008 00000000
c09fa3b8 006000c0 00000000
[ 9.964724] 9de0: 00000000 00000002 00000002 c09fc704 006000c0
00000000 ee7c7c00 00000000
[ 9.976159] pgd = (ptrval)
[ 9.979536] 9e00: 000000d5 00000000 00000000 00000000 c126a314
c2cf9f68 eec77880 c2cf9e50
[ 9.979550] 9e20: 00000040 00000000 eec77880 00000000 00000000
c099a624 c2cf9f68 00000000
[ 9.979565] 9e40: c2cf9e50 c099ae48 00000100 00000000 00000080
c04ab918 ee78e8c0 7fff0000
[ 9.979580] 9e60: c2cf9e90 c2cf9eec ffff0000 000000a0 bed817e4
00000028 01a040a8 0000005b
[ 9.979594] 9e80: 00000000 00000000 00000000 01a0ef00 00000128
40000028 b6cd9548 00000000
[ 9.979607] 9ea0: 0000000d 00000000 bed817b8 00000000 00000010
00000000 00000002 00000000
[ 9.985866] [0000000c] *pgd=00000000
[ 9.988810] 9ec0: 00000000 00000000 01a0ef00 00000000 c2cf9fb0
00000128 bed817b8 00000000
[ 9.988825] 9ee0: 00000000 c0407f18 00000000 00000000 c120bbec
b6e2ba00 c2cf9fb0 10c5387d
[ 9.988841] 9f00: 01a0efb8 bed81720 bed81728 c03165fc 00005010
00001000 3e600000 c04ced24
[ 9.988855] 9f20: ee4b5010 00000ff0 ee4b5000 00000000 ee4b6000
eec77880 bed817b8 00000000
[ 9.988875] 9f40: 00000128 c0301204 c2cf8000 00000128 00000000
c099bc5c 00000000 00000000
[ 10.000948] 9f60: 00000000 fffffff7 c2cf9eb0 0000000c 00000001
00000000 00000000 c2cf9e80
[ 10.000961] 9f80: 00000000 c030ac08 00000000 00000000 00000040
00000000 00000000 01a0ef00
[ 10.000976] 9fa0: bed817b8 c03011d4 00000000 01a0ef00 0000000d
bed817b8 00000000 00000000
[ 10.000995] 9fc0: 00000000 01a0ef00 bed817b8 00000128 0000005b
01a0af00 01a0f620 00000000
[ 10.228876] 9fe0: b6f9fad4 bed81780 b6de4780 b6cd9548 60000010
0000000d 00000000 00000000
[ 10.237081] [<c09d4d58>] (sk_filter_trim_cap) from [<c09fa2bc>]
(netlink_broadcast_filtered+0x304/0x3dc)
[ 10.246575] [<c09fa2bc>] (netlink_broadcast_filtered) from
[<c09fa3b8>] (netlink_broadcast+0x24/0x2c)
[ 10.255806] [<c09fa3b8>] (netlink_broadcast) from [<c09fc704>]
(netlink_sendmsg+0x30c/0x340)
[ 10.264258] [<c09fc704>] (netlink_sendmsg) from [<c099a624>]
(sock_sendmsg+0x3c/0x4c)
[ 10.272100] [<c099a624>] (sock_sendmsg) from [<c099ae48>]
(___sys_sendmsg+0x1d8/0x218)
[ 10.280030] [<c099ae48>] (___sys_sendmsg) from [<c099bc5c>]
(__sys_sendmsg+0x48/0x6c)
[ 10.287872] [<c099bc5c>] (__sys_sendmsg) from [<c03011d4>]
(__sys_trace_return+0x0/0x10)
[ 10.295962] Exception stack(0xc2cf9fa8 to 0xc2cf9ff0)
[ 10.301018] 9fa0: 00000000 01a0ef00 0000000d
bed817b8 00000000 00000000
[ 10.309202] 9fc0: 00000000 01a0ef00 bed817b8 00000128 0000005b
01a0af00 01a0f620 00000000
[ 10.317381] 9fe0: b6f9fad4 bed81780 b6de4780 b6cd9548
[ 10.322442] Code: 1afffff7 e59c0000 e5830000 e3520000 (e584800c)
[ 10.328557] Internal error: Oops: 805 [#8] SMP ARM
[ 10.328768] ---[ end trace 2cb865e83300a747 ]---
[ 10.333357] Modules linked in:
[ 10.333374] CPU: 2 PID: 212 Comm: systemd-udevd Tainted: G D
4.18.0-0.rc1.git0.1.fc29.armv7hl #1
[ 10.333378] Hardware name: BCM2835
[ 10.333396] PC is at sk_filter_trim_cap+0x15c/0x1b8
[ 10.333409] LR is at (null)
[ 10.341840] Unable to handle kernel NULL pointer dereference at
virtual address 0000000c
[ 10.351172] pc : [<c09d4d58>] lr : [<00000000>] psr: 60000013
[ 10.351179] sp : c2e5dd58 ip : 00000000 fp : 00000000
[ 10.351185] r10: ef2c3c00 r9 : c13093c0 r8 : 00000000
[ 10.351192] r7 : 00000000 r6 : 00000001 r5 : f0f6a000 r4 : 00000000
[ 10.351198] r3 : 00000007 r2 : 00000000 r1 : 00000000 r0 : 00000000
[ 10.351207] Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none
[ 10.351215] Control: 10c5387d Table: 02e6006a DAC: 00000051
[ 10.351231] Process systemd-udevd (pid: 212, stack limit = 0x(ptrval))
[ 10.354654] pgd = (ptrval)
[ 10.359496] Stack: (0xc2e5dd58 to 0xc2e5e000)
[ 10.359505] dd40:
00000000 ef3c0540
[ 10.359520] dd60: 006000c0 00000000 00000000 c09a233c ef3c0b40
ef3c0b40 ef3c0540 00000000
[ 10.359534] dd80: 00000000 00000000 c13093c0 c09fa2bc 006000c0
00000001 ee7f2000 00000000
[ 10.359548] dda0: 00000002 00000000 00000001 ef2c3c64 c2e5df70
00000002 ef3c0540 00000000
[ 10.359563] ddc0: c2e5df68 00000084 ee7f2000 00000008 00000000
c09fa3b8 006000c0 00000000
[ 10.359585] dde0: 00000000 00000002 00000002 c09fc704 006000c0
00000000 c2c68d00 00000000
[ 10.362574] [0000000c] *pgd=00000000
[ 10.382706] de00: 000000d4 00000000 00000000 00000000 c126a314
c2e5df68 eec76c40 c2e5de50
[ 10.382721] de20: 00000040 00000000 eec76c40 00000000 00000000
c099a624 c2e5df68 00000000
[ 10.382735] de40: c2e5de50 c099ae48 00000100 00000000 00000080
c04ab918 ee78e8c0 7fff0000
[ 10.382750] de60: c2e5de90 c2e5deec ffff0000 000000a0 bed817e4
00000028 01a040a8 0000005c
[ 10.382764] de80: 00000000 00000000 00000000 01a0e0f0 00000128
40000028 b6cd9548 00000000
[ 10.382780] dea0: 0000000d 00000000 bed817b8 00000000 00000010
00000000 00000002 00000000
[ 10.397129] dec0: 00000000 00000000 01a0e0f0 00000000 c2e5dfb0
00000128 bed817b8 00000000
[ 10.397144] dee0: 00000000 c0407f18 00000000 00000000 c120bbec
b6e2ba00 c2e5dfb0 10c5387d
[ 10.397159] df00: 01a0e1a8 bed81720 bed81728 c03165fc 00006010
00001000 3e600000 c04ced24
[ 10.397174] df20: ef216010 00000ff0 ef216000 00000000 ef217000
eec76c40 bed817b8 00000000
[ 10.397189] df40: 00000128 c0301204 c2e5c000 00000128 00000000
c099bc5c 00000000 00000000
[ 10.589571] df60: 00000000 fffffff7 c2e5deb0 0000000c 00000001
00000000 00000000 c2e5de80
[ 10.589596] df80: 00000000 c030ac08 00000000 00000000 00000040
00000000 00000000 01a0e0f0
[ 10.605946] dfa0: bed817b8 c03011d4 00000000 01a0e0f0 0000000d
bed817b8 00000000 00000000
[ 10.614131] dfc0: 00000000 01a0e0f0 bed817b8 00000128 0000005c
01a0af00 01a0e920 00000000
[ 10.622316] dfe0: b6f9fad4 bed81780 b6de4780 b6cd9548 60000010
0000000d 00000000 00000000
[ 10.630594] [<c09d4d58>] (sk_filter_trim_cap) from [<c09fa2bc>]
(netlink_broadcast_filtered+0x304/0x3dc)
[ 10.640088] [<c09fa2bc>] (netlink_broadcast_filtered) from
[<c09fa3b8>] (netlink_broadcast+0x24/0x2c)
[ 10.650447] [<c09fa3b8>] (netlink_broadcast) from [<c09fc704>]
(netlink_sendmsg+0x30c/0x340)
[ 10.658899] [<c09fc704>] (netlink_sendmsg) from [<c099a624>]
(sock_sendmsg+0x3c/0x4c)
[ 10.666742] [<c099a624>] (sock_sendmsg) from [<c099ae48>]
(___sys_sendmsg+0x1d8/0x218)
[ 10.674673] [<c099ae48>] (___sys_sendmsg) from [<c099bc5c>]
(__sys_sendmsg+0x48/0x6c)
[ 10.682515] [<c099bc5c>] (__sys_sendmsg) from [<c03011d4>]
(__sys_trace_return+0x0/0x10)
[ 10.690604] Exception stack(0xc2e5dfa8 to 0xc2e5dff0)
[ 10.695660] dfa0: 00000000 01a0e0f0 0000000d
bed817b8 00000000 00000000
[ 10.703845] dfc0: 00000000 01a0e0f0 bed817b8 00000128 0000005c
01a0af00 01a0e920 00000000
[ 10.712025] dfe0: b6f9fad4 bed81780 b6de4780 b6cd9548
[ 10.717086] Code: 1afffff7 e59c0000 e5830000 e3520000 (e584800c)
[ 10.723199] Internal error: Oops: 805 [#9] SMP ARM
[ 10.723343] ---[ end trace 2cb865e83300a748 ]---
^ permalink raw reply
* Re: Crash in netlink/sk_filter_trim_cap on ARMv7 on 4.18rc1
From: Eric Dumazet @ 2018-06-22 12:55 UTC (permalink / raw)
To: Peter Robinson, netdev, linux-arm-kernel; +Cc: labbott
In-Reply-To: <CALeDE9PP__kPHX_aW24kwzGf9BgA0gQOQJSY+Qw0yFMOLn4Pcw@mail.gmail.com>
On 06/22/2018 04:19 AM, Peter Robinson wrote:
> Hi All,
>
> I'm seeing this netlink/sk_filter_trim_cap crash on ARMv7 across quite
> a few ARMv7 platforms on Fedora with 4.18rc1. I've tested RPi2/RPi3
> (doesn't happen on aarch64), AllWinner H3, BeagleBone and a few
> others, both LPAE/normal kernels.
>
> I'm a bit out of my depth in this part of the kernel but I'm wondering
> if it's known, I couldn't find anything that looked obvious on a few
> mailing lists.
>
> Peter
Hi Peter
Could you provide symbolic information ?
Thanks !
^ 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