* Re: [PATCH] drivers: net: phy: mdio-mux: Add support for Generic Mux controls
From: Andrew Lunn @ 2019-02-21 15:17 UTC (permalink / raw)
To: Pankaj Bansal
Cc: Leo Li, Peter Rosin, Florian Fainelli, Heiner Kallweit,
netdev@vger.kernel.org
In-Reply-To: <VI1PR0401MB2496D9119F5639278CB14965F17E0@VI1PR0401MB2496.eurprd04.prod.outlook.com>
> > > config MDIO_BUS_MUX
> > > tristate
> > > depends on OF_MDIO
> > > + select MULTIPLEXER
> > > help
> > > This module provides a driver framework for MDIO bus
> > > multiplexers which connect one of several child MDIO busses
> >
> > Hi Pankaj
> >
> > Please add a MDIO_BUS_MUX_MULTIPLEXER and put all the code into mdio-
> > mux-multiplexer.c
>
> Isn't MUX short for MULTIPLEXER ? wouldn't this be more confusing ?
Look at the pattern:
config MDIO_BUS_MUX
config MDIO_BUS_MUX_BCM_IPROC
config MDIO_BUS_MUX_GPIO
config MDIO_BUS_MUX_MMIOREG
You are adding another sort of MUX, A Mux that uses a kernel
Multiplexer. Hence the name should be MDIO_BUS_MUX_MULTIPLEXER.
You can try to avoid confusion by using good help text:
help This module provides a driver for MDIO bus multiplexer
that is controlled via the kernel multiplexer subsystem. The
bus multiplexer connects one of several child MDIO busses to
a parent bus. Child bus selection is under the control of
the kernel multiplexer subsystem.
This test basically follows the other MDIO multiplexers.
Andrew
^ permalink raw reply
* Re: [PATCH RFC 4/5] sched/topology: Annonate RCU pointers properly
From: Joel Fernandes @ 2019-02-21 15:10 UTC (permalink / raw)
To: Peter Zijlstra
Cc: linux-kernel, Alexei Starovoitov, Christian Brauner,
Daniel Borkmann, David Ahern, David S. Miller, Ido Schimmel,
Ingo Molnar, moderated list:INTEL ETHERNET DRIVERS,
Jakub Kicinski, Jeff Kirsher, Jesper Dangaard Brouer,
John Fastabend, Josh Triplett, keescook, Lai Jiangshan,
Martin KaFai Lau, Mathieu Desnoyers, netdev, Paul E. McKenney,
rcu, Song Liu, Steven Rostedt, xdp-newbies, Yonghong Song
In-Reply-To: <20190221091944.GY32477@hirez.programming.kicks-ass.net>
Hi Peter,
Thanks for taking a look.
On Thu, Feb 21, 2019 at 10:19:44AM +0100, Peter Zijlstra wrote:
> On Thu, Feb 21, 2019 at 12:49:41AM -0500, Joel Fernandes (Google) wrote:
>
> > Also replace rcu_assign_pointer call on rq->sd with WRITE_ONCE. This
> > should be sufficient for the rq->sd initialization.
>
> > @@ -668,7 +668,7 @@ cpu_attach_domain(struct sched_domain *sd, struct root_domain *rd, int cpu)
> >
> > rq_attach_root(rq, rd);
> > tmp = rq->sd;
> > - rcu_assign_pointer(rq->sd, sd);
> > + WRITE_ONCE(rq->sd, sd);
> > dirty_sched_domain_sysctl(cpu);
> > destroy_sched_domains(tmp);
>
> Where did the RELEASE barrier go?
>
> That was a publish operation, now it is not.
Funny thing is, initially I had written this patch with smp_store_release()
instead of WRITE_ONCE, but checkpatch complaints with that since it needs a
comment on top of it, and I wasn't sure if RELEASE barrier was the intent of
using rcu_assign_pointer (all the more reason to replace it with something
more explicit).
I will replace it with the following and resubmit it then:
/* Release barrier */
smp_store_release(&rq->sd, sd);
Or do we want to just drop the "Release barrier" comment and live with the
checkpatch warning?
(my same response applies to patch 5/5).
thanks,
- Joel
^ permalink raw reply
* Re: [PATCH net v2] ipv6: route: purge exception on removal
From: David Ahern @ 2019-02-21 15:10 UTC (permalink / raw)
To: Paolo Abeni, netdev; +Cc: David S. Miller
In-Reply-To: <1cf1aef01dd9294347df6e339d2f8f042172fb54.1550679150.git.pabeni@redhat.com>
On 2/20/19 12:18 PM, Paolo Abeni wrote:
> When a netdevice is unregistered, we flush the relevant exception
> via rt6_sync_down_dev() -> fib6_ifdown() -> fib6_del() -> fib6_del_route().
>
> Finally, we end-up calling rt6_remove_exception(), where we release
> the relevant dst, while we keep the references to the related fib6_info and
> dev. Such references should be released later when the dst will be
> destroyed.
>
> There are a number of caches that can keep the exception around for an
> unlimited amount of time - namely dst_cache, possibly even socket cache.
> As a result device registration may hang, as demonstrated by this script:
>
> ip netns add cl
> ip netns add rt
> ip netns add srv
> ip netns exec rt sysctl -w net.ipv6.conf.all.forwarding=1
>
> ip link add name cl_veth type veth peer name cl_rt_veth
> ip link set dev cl_veth netns cl
> ip -n cl link set dev cl_veth up
> ip -n cl addr add dev cl_veth 2001::2/64
> ip -n cl route add default via 2001::1
>
> ip -n cl link add tunv6 type ip6tnl mode ip6ip6 local 2001::2 remote 2002::1 hoplimit 64 dev cl_veth
> ip -n cl link set tunv6 up
> ip -n cl addr add 2013::2/64 dev tunv6
>
> ip link set dev cl_rt_veth netns rt
> ip -n rt link set dev cl_rt_veth up
> ip -n rt addr add dev cl_rt_veth 2001::1/64
>
> ip link add name rt_srv_veth type veth peer name srv_veth
> ip link set dev srv_veth netns srv
> ip -n srv link set dev srv_veth up
> ip -n srv addr add dev srv_veth 2002::1/64
> ip -n srv route add default via 2002::2
>
> ip -n srv link add tunv6 type ip6tnl mode ip6ip6 local 2002::1 remote 2001::2 hoplimit 64 dev srv_veth
> ip -n srv link set tunv6 up
> ip -n srv addr add 2013::1/64 dev tunv6
>
> ip link set dev rt_srv_veth netns rt
> ip -n rt link set dev rt_srv_veth up
> ip -n rt addr add dev rt_srv_veth 2002::2/64
>
> ip netns exec srv netserver & sleep 0.1
> ip netns exec cl ping6 -c 4 2013::1
> ip netns exec cl netperf -H 2013::1 -t TCP_STREAM -l 3 & sleep 1
> ip -n rt link set dev rt_srv_veth mtu 1400
> wait %2
>
> ip -n cl link del cl_veth
>
> This commit addresses the issue purging all the references held by the
> exception at time, as we currently do for e.g. ipv6 pcpu dst entries.
>
> v1 -> v2:
> - re-order the code to avoid accessing dst and net after dst_dev_put()
>
> Fixes: 93531c674315 ("net/ipv6: separate handling of FIB entries from dst based routes")
> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
> ---
> net/ipv6/route.c | 13 ++++++++++++-
> 1 file changed, 12 insertions(+), 1 deletion(-)
>
I am surprised this was not found by the existing pmtu script which
creates exceptions. Please add this test case to selftests to capture
this specific set of events.
Reviewed-by: David Ahern <dsahern@gmail.com>
Thanks for the resolving.
^ permalink raw reply
* [PATCH iproute2 1/1] man: Document COLORFGBG environment variable
From: Petr Vorel @ 2019-02-21 15:04 UTC (permalink / raw)
To: netdev; +Cc: Petr Vorel, Stephen Hemminger
Default colors are not contrast enough on dark backround
and this functionality, which uses more suitable colors
is hidden in the code.
Signed-off-by: Petr Vorel <pvorel@suse.cz>
---
man/man8/ip.8 | 17 +++++++++++++++++
1 file changed, 17 insertions(+)
diff --git a/man/man8/ip.8 b/man/man8/ip.8
index 84ade110..133d40d5 100644
--- a/man/man8/ip.8
+++ b/man/man8/ip.8
@@ -189,6 +189,12 @@ precedence. This flag is ignored if
.B \-json
is also given.
+Used color palette can be influenced by
+.BR COLORFGBG
+environment variable
+(see
+.BR ENVIRONMENT ).
+
.TP
.BR "\-t" , " \-timestamp"
display current time when using monitor option.
@@ -330,6 +336,17 @@ Usually it is
or, if the objects of this class cannot be listed,
.BR "help" .
+.SH ENVIRONMENT
+.TP
+.B COLORFGBG
+If set, it's value is used for detection whether background is dark or light and use contrast colors for it.
+
+COLORFGBG environment variable usually contains either two or three
+values separated by semicolons; we want the last value in either case.
+If this value is 0-6 or 8, chose colors suitable for dark background:
+
+COLORFGBG=";0" ip -c a
+
.SH EXIT STATUS
Exit status is 0 if command was successful, and 1 if there is a syntax error.
If an error was reported by the kernel exit status is 2.
--
2.12.3
^ permalink raw reply related
* Re: [PATCH net v2 2/2] ipv6: route: enforce RCU protection in ip6_route_check_nh_onlink()
From: David Ahern @ 2019-02-21 14:57 UTC (permalink / raw)
To: Paolo Abeni, netdev; +Cc: David S. Miller
In-Reply-To: <0bf24707358ef15ab42b44037da4dc46e3e63acb.1550684182.git.pabeni@redhat.com>
On 2/21/19 5:19 AM, Paolo Abeni wrote:
> We need a RCU critical section around rt6_info->from deference, and
> proper annotation.
>
> Fixes: 4ed591c8ab44 ("net/ipv6: Allow onlink routes to have a device mismatch if it is the default route")
> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
> ---
> net/ipv6/route.c | 6 +++++-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
Reviewed-by: David Ahern <dsahern@gmail.com>
Thanks for the fixing.
^ permalink raw reply
* Re: [PATCH net v2 1/2] ipv6: route: enforce RCU protection in rt6_update_exception_stamp_rt()
From: David Ahern @ 2019-02-21 14:57 UTC (permalink / raw)
To: Paolo Abeni, netdev; +Cc: David S. Miller
In-Reply-To: <fe784e447b956d111d61d8dbc3386d7bb95a8d89.1550684182.git.pabeni@redhat.com>
On 2/21/19 5:19 AM, Paolo Abeni wrote:
> We must access rt6_info->from under RCU read lock: move the
> dereference under such lock, with proper annotation.
>
> v1 -> v2:
> - avoid using multiple, racy, fetch operations for rt->from
>
> Fixes: a68886a69180 ("net/ipv6: Make from in rt6_info rcu protected")
> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
> ---
> net/ipv6/route.c | 11 ++++++-----
> 1 file changed, 6 insertions(+), 5 deletions(-)
>
Reviewed-by: David Ahern <dsahern@gmail.com>
Thanks for fixing.
^ permalink raw reply
* Re: [PATCH v2 iproute2-next 07/11] devlink: Add devlink health diagnose command
From: Jiri Pirko @ 2019-02-21 14:28 UTC (permalink / raw)
To: Aya Levin; +Cc: David Ahern, netdev, Jiri Pirko, Moshe Shemesh, Eran Ben Elisha
In-Reply-To: <1550756567-18227-8-git-send-email-ayal@mellanox.com>
Thu, Feb 21, 2019 at 02:42:43PM CET, ayal@mellanox.com wrote:
>Add devlink health diagnose command: enabling retrieval of diagnostics data
>by the user on a reporter on a device. The command's output is a
>free text defined by the reporter.
>
>This patch also introduces an infra structure for flexible format
>output. This allow the command to display different data fields
>according to the reporter.
>Example:
>$ devlink health diagnose pci/0000:00:0a.0 reporter tx
>SQs:
> sqn: 4403 HW state: 1 stopped: false
> sqn: 4408 HW state: 1 stopped: false
> sqn: 4413 HW state: 1 stopped: false
> sqn: 4418 HW state: 1 stopped: false
> sqn: 4423 HW state: 1 stopped: false
>
>$ devlink health diagnose pci/0000:00:0a.0 reporter tx -jp
>{
> "SQs":[
> {
> "sqn":4403,
> "HW state":1,
> "stopped":false
> },
> {
> "sqn":4408,
> "HW state":1,
> "stopped":false
> },
> {
> "sqn":4413,
> "HW state":1,
> "stopped":false
> },
> {
> "sqn":4418,
> "HW state":1,
> "stopped":false
> },
> {
> "sqn":4423,
> "HW state":1,
> "stopped":false
> }
> ]
>}
>
>Signed-off-by: Aya Levin <ayal@mellanox.com>
>Reviewed-by: Moshe Shemesh <moshe@mellanox.com>
Acked-by: Jiri Pirko <jiri@mellanox.com>
^ permalink raw reply
* Re: [RFC] coallocating struct socket and struct socket_wq
From: Al Viro @ 2019-02-21 14:38 UTC (permalink / raw)
To: netdev
In-Reply-To: <20190221081523.GZ2217@ZenIV.linux.org.uk>
On Thu, Feb 21, 2019 at 08:15:23AM +0000, Al Viro wrote:
> All instances of struct socket are embedded into some
> bigger structure - most into struct socket_alloc (with struct inode
> following struct socket), some into struct tun_file or struct
> tap_queue.
>
> In the last two cases the corresponding struct socket_wq
> (the one whose address goes into socket->wq) is in the same
> containing structure, right after struct socket.
>
> In case of struct socket_alloc, we allocate struct
> socket_wq separately and set socket->wq before anyone sees
> either (in sock_alloc_inode()). In sock_destroy_inode()
> they are both freed (struct sock_alloc immediately,
> struct socket_wq - RCU-delayed).
>
> AFAICS, nothing ever reassigns socket->wq. Could we
> simply embed struct socket_wq into struct socket? RCU delay
> is not an issue - net/socket.c is non-modular, so call_rcu()-based
> variant freeing both together is not horrible. sock_alloc_inode()
> would be simplified, tun/tap uses would simply lose the separate
> socket_wq members.
>
> The only problem I see here is ____cacheline_aligned_in_smp
> we have on struct socket_wq. Could we simply make it the first
> field in struct socket? Without lockdep they are reasonably small -
> on amd64 socket_wq is 64 bytes, while the rest of struct socket is
> 48 (and pointer to wq would obviously disappear).
>
> Or is there something subtle I'm missing here?
Put it another way, what was the reason for "net: sock_def_readable()
and friends RCU conversion" not to put RCU delay into freeing of
struct socket itself? Separating the write-often fields from
mostly read-only ones? I hadn't been able to find in archives
the discussion from back in 2010, unfortunately ;-/
^ permalink raw reply
* KASAN: slab-out-of-bounds Read in ip6_hold_safe
From: syzbot @ 2019-02-21 14:47 UTC (permalink / raw)
To: davem, kuznet, linux-kernel, netdev, syzkaller-bugs, yoshfuji
Hello,
syzbot found the following crash on:
HEAD commit: b71acb0e3721 Merge branch 'linus' of git://git.kernel.org/..
git tree: net-next
console output: https://syzkaller.appspot.com/x/log.txt?x=1672a39b400000
kernel config: https://syzkaller.appspot.com/x/.config?x=b03c5892bb940c76
dashboard link: https://syzkaller.appspot.com/bug?extid=ec03ae3a032901d10434
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+ec03ae3a032901d10434@syzkaller.appspotmail.com
kernel msg: ebtables bug: please report to author: EBT_ENTRY_OR_ENTRIES
shouldn't be set in distinguisher
==================================================================
BUG: KASAN: slab-out-of-bounds in atomic_read
include/asm-generic/atomic-instrumented.h:21 [inline]
BUG: KASAN: slab-out-of-bounds in atomic_fetch_add_unless
include/linux/atomic.h:575 [inline]
BUG: KASAN: slab-out-of-bounds in atomic_add_unless
include/linux/atomic.h:597 [inline]
BUG: KASAN: slab-out-of-bounds in dst_hold_safe include/net/dst.h:308
[inline]
BUG: KASAN: slab-out-of-bounds in ip6_hold_safe+0xca/0x620
net/ipv6/route.c:1021
Read of size 4 at addr ffff88806b399ccc by task ksoftirqd/1/16
CPU: 1 PID: 16 Comm: ksoftirqd/1 Not tainted 4.20.0+ #3
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+0x1db/0x2d0 lib/dump_stack.c:113
print_address_description.cold+0x7c/0x20d mm/kasan/report.c:256
kasan_report_error mm/kasan/report.c:354 [inline]
kasan_report mm/kasan/report.c:412 [inline]
kasan_report.cold+0x8c/0x2ba mm/kasan/report.c:396
check_memory_region_inline mm/kasan/kasan.c:260 [inline]
check_memory_region+0x123/0x190 mm/kasan/kasan.c:267
kasan_check_read+0x11/0x20 mm/kasan/kasan.c:272
atomic_read include/asm-generic/atomic-instrumented.h:21 [inline]
atomic_fetch_add_unless include/linux/atomic.h:575 [inline]
atomic_add_unless include/linux/atomic.h:597 [inline]
dst_hold_safe include/net/dst.h:308 [inline]
ip6_hold_safe+0xca/0x620 net/ipv6/route.c:1021
rt6_get_pcpu_route net/ipv6/route.c:1241 [inline]
ip6_pol_route+0x3a3/0x1490 net/ipv6/route.c:1890
ip6_pol_route_input+0x65/0x80 net/ipv6/route.c:1909
fib6_rule_lookup+0x12f/0x870 net/ipv6/fib6_rules.c:118
ip6_route_input_lookup+0xb7/0xd0 net/ipv6/route.c:1921
ip6_route_input+0x79b/0xe00 net/ipv6/route.c:2056
ip6_rcv_finish_core.isra.0+0x204/0x720 net/ipv6/ip6_input.c:63
ip6_rcv_finish+0x109/0x330 net/ipv6/ip6_input.c:74
NF_HOOK include/linux/netfilter.h:289 [inline]
NF_HOOK include/linux/netfilter.h:283 [inline]
ipv6_rcv+0x113/0x650 net/ipv6/ip6_input.c:272
__netif_receive_skb_one_core+0x160/0x210 net/core/dev.c:4973
__netif_receive_skb+0x2c/0x1c0 net/core/dev.c:5083
process_backlog+0x206/0x750 net/core/dev.c:5923
napi_poll net/core/dev.c:6346 [inline]
net_rx_action+0x76d/0x1930 net/core/dev.c:6412
__do_softirq+0x30b/0xb11 kernel/softirq.c:292
run_ksoftirqd kernel/softirq.c:654 [inline]
run_ksoftirqd+0x8e/0x110 kernel/softirq.c:646
smpboot_thread_fn+0x6ab/0xa10 kernel/smpboot.c:164
kthread+0x357/0x430 kernel/kthread.c:246
ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:352
Allocated by task 3862:
save_stack+0x45/0xd0 mm/kasan/kasan.c:448
set_track mm/kasan/kasan.c:460 [inline]
kasan_kmalloc mm/kasan/kasan.c:553 [inline]
kasan_kmalloc+0xce/0xf0 mm/kasan/kasan.c:531
kasan_slab_alloc+0xf/0x20 mm/kasan/kasan.c:490
kmem_cache_alloc+0x12e/0x700 mm/slab.c:3554
getname_flags fs/namei.c:140 [inline]
getname_flags+0xd6/0x5b0 fs/namei.c:129
user_path_at_empty+0x2f/0x50 fs/namei.c:2608
do_readlinkat+0x141/0x400 fs/stat.c:397
__do_sys_readlink fs/stat.c:430 [inline]
__se_sys_readlink fs/stat.c:427 [inline]
__x64_sys_readlink+0x78/0xb0 fs/stat.c:427
do_syscall_64+0x1a3/0x800 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe
Freed by task 3862:
save_stack+0x45/0xd0 mm/kasan/kasan.c:448
set_track mm/kasan/kasan.c:460 [inline]
__kasan_slab_free+0x102/0x150 mm/kasan/kasan.c:521
kasan_slab_free+0xe/0x10 mm/kasan/kasan.c:528
__cache_free mm/slab.c:3498 [inline]
kmem_cache_free+0x86/0x260 mm/slab.c:3760
putname+0xef/0x130 fs/namei.c:261
filename_lookup+0x359/0x530 fs/namei.c:2357
user_path_at_empty+0x43/0x50 fs/namei.c:2608
do_readlinkat+0x141/0x400 fs/stat.c:397
__do_sys_readlink fs/stat.c:430 [inline]
__se_sys_readlink fs/stat.c:427 [inline]
__x64_sys_readlink+0x78/0xb0 fs/stat.c:427
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 ffff88806b398440
which belongs to the cache names_cache of size 4096
The buggy address is located 2188 bytes to the right of
4096-byte region [ffff88806b398440, ffff88806b399440)
The buggy address belongs to the page:
page:ffffea0001ace600 count:1 mapcount:0 mapping:ffff88812c2bec40 index:0x0
compound_mapcount: 0
flags: 0x1fffc0000010200(slab|head)
raw: 01fffc0000010200 ffffea0002310008 ffffea0002a06988 ffff88812c2bec40
raw: 0000000000000000 ffff88806b398440 0000000100000001 0000000000000000
page dumped because: kasan: bad access detected
Memory state around the buggy address:
ffff88806b399b80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
ffff88806b399c00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
> ffff88806b399c80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
^
ffff88806b399d00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
ffff88806b399d80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
==================================================================
---
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
* general protection fault in dev_get_by_index_rcu
From: syzbot @ 2019-02-21 14:46 UTC (permalink / raw)
To: davem, kuznet, linux-kernel, netdev, syzkaller-bugs, yoshfuji
Hello,
syzbot found the following crash on:
HEAD commit: c433570458e4 ax25: fix a use-after-free in ax25_fillin_cb()
git tree: net
console output: https://syzkaller.appspot.com/x/log.txt?x=1352f84b400000
kernel config: https://syzkaller.appspot.com/x/.config?x=4b137b8ba637eb77
dashboard link: https://syzkaller.appspot.com/bug?extid=48127bec5a5cd81411e3
compiler: gcc (GCC) 8.0.1 20180413 (experimental)
Unfortunately, I don't have any reproducer for this crash yet.
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+48127bec5a5cd81411e3@syzkaller.appspotmail.com
kasan: CONFIG_KASAN_INLINE enabled
kasan: GPF could be caused by NULL-ptr deref or user memory access
general protection fault: 0000 [#1] PREEMPT SMP KASAN
CPU: 1 PID: 3229 Comm: syz-executor0 Not tainted 4.20.0+ #255
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
RIP: 0010:dev_get_by_index_rcu+0x9a/0x360 net/core/dev.c:840
Code: f2 c7 40 0c 00 f2 f2 f2 65 48 8b 04 25 28 00 00 00 48 89 45 d0 31 c0
e8 64 82 5f fb 48 8d bb c0 01 00 00 48 89 f8 48 c1 e8 03 <42> 80 3c 20 00
0f 85 7e 02 00 00 0f b6 85 34 ff ff ff 48 8b 93 c0
RSP: 0018:ffff8880ae706c50 EFLAGS: 00010207
RAX: 001ffffffffbd5e1 RBX: 00ffffffffdead4e RCX: ffffffff8697b590
RDX: 0000000000000100 RSI: ffffffff8622238c RDI: 00ffffffffdeaf0e
RBP: ffff8880ae706d30 R08: ffff888060b26340 R09: ffffed1015ce5b8f
R10: ffffed1015ce5b8f R11: ffff8880ae72dc7b R12: dffffc0000000000
R13: 0000000000000000 R14: ffff88806556b6f0 R15: ffff88808e08b95d
FS: 00007eff2e401700(0000) GS:ffff8880ae700000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000001b2fb2c000 CR3: 000000008a036000 CR4: 00000000001406e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
<IRQ>
netif_index_is_l3_master include/net/l3mdev.h:138 [inline]
ip_send_unicast_reply+0x10fd/0x1740 net/ipv4/ip_output.c:1588
tcp_v4_send_reset+0x14be/0x2ae0 net/ipv4/tcp_ipv4.c:775
tcp_v4_rcv+0x1dfa/0x3b10 net/ipv4/tcp_ipv4.c:1936
ip_protocol_deliver_rcu+0xb6/0xa20 net/ipv4/ip_input.c:208
ip_local_deliver_finish+0x234/0x380 net/ipv4/ip_input.c:234
NF_HOOK include/linux/netfilter.h:289 [inline]
ip_local_deliver+0x1e9/0x750 net/ipv4/ip_input.c:255
dst_input include/net/dst.h:450 [inline]
ip_rcv_finish+0x1f9/0x300 net/ipv4/ip_input.c:414
NF_HOOK include/linux/netfilter.h:289 [inline]
ip_rcv+0xed/0x600 net/ipv4/ip_input.c:523
__netif_receive_skb_one_core+0x14d/0x200 net/core/dev.c:4973
__netif_receive_skb+0x2c/0x1e0 net/core/dev.c:5083
process_backlog+0x217/0x760 net/core/dev.c:5923
napi_poll net/core/dev.c:6346 [inline]
net_rx_action+0x7c5/0x1950 net/core/dev.c:6412
__do_softirq+0x30c/0xb2e kernel/softirq.c:292
do_softirq_own_stack+0x2a/0x40 arch/x86/entry/entry_64.S:1027
</IRQ>
do_softirq.part.13+0x126/0x160 kernel/softirq.c:337
do_softirq kernel/softirq.c:329 [inline]
__local_bh_enable_ip+0x21d/0x260 kernel/softirq.c:189
local_bh_enable include/linux/bottom_half.h:32 [inline]
rcu_read_unlock_bh include/linux/rcupdate.h:696 [inline]
ip_finish_output2+0xabc/0x1a20 net/ipv4/ip_output.c:231
ip_finish_output+0x7f7/0xf90 net/ipv4/ip_output.c:317
NF_HOOK_COND include/linux/netfilter.h:278 [inline]
ip_output+0x217/0x8d0 net/ipv4/ip_output.c:405
dst_output include/net/dst.h:444 [inline]
ip_local_out+0xc5/0x1b0 net/ipv4/ip_output.c:124
__ip_queue_xmit+0x9af/0x1f40 net/ipv4/ip_output.c:505
ip_queue_xmit+0x56/0x70 include/net/ip.h:198
__tcp_transmit_skb+0x1b9f/0x3b90 net/ipv4/tcp_output.c:1160
tcp_transmit_skb net/ipv4/tcp_output.c:1176 [inline]
tcp_send_syn_data net/ipv4/tcp_output.c:3495 [inline]
tcp_connect+0x2271/0x4690 net/ipv4/tcp_output.c:3534
tcp_v4_connect+0x19bb/0x1df0 net/ipv4/tcp_ipv4.c:315
__inet_stream_connect+0x992/0x1150 net/ipv4/af_inet.c:655
tcp_sendmsg_fastopen net/ipv4/tcp.c:1161 [inline]
tcp_sendmsg_locked+0x2890/0x3f30 net/ipv4/tcp.c:1208
tcp_sendmsg+0x2f/0x50 net/ipv4/tcp.c:1443
inet_sendmsg+0x1a1/0x690 net/ipv4/af_inet.c:798
sock_sendmsg_nosec net/socket.c:621 [inline]
sock_sendmsg+0xd5/0x120 net/socket.c:631
__sys_sendto+0x3d7/0x670 net/socket.c:1788
__do_sys_sendto net/socket.c:1800 [inline]
__se_sys_sendto net/socket.c:1796 [inline]
__x64_sys_sendto+0xe1/0x1a0 net/socket.c:1796
do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x457ec9
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:00007eff2e400c78 EFLAGS: 00000246 ORIG_RAX: 000000000000002c
RAX: ffffffffffffffda RBX: 0000000000000006 RCX: 0000000000457ec9
RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000004
RBP: 000000000073bf00 R08: 00000000200002c0 R09: 0000000000000010
R10: 00000400200007fe R11: 0000000000000246 R12: 00007eff2e4016d4
R13: 00000000004c5278 R14: 00000000004d8b90 R15: 00000000ffffffff
Modules linked in:
---[ end trace 67e073c62a96b1a3 ]---
RIP: 0010:dev_get_by_index_rcu+0x9a/0x360 net/core/dev.c:840
Code: f2 c7 40 0c 00 f2 f2 f2 65 48 8b 04 25 28 00 00 00 48 89 45 d0 31 c0
e8 64 82 5f fb 48 8d bb c0 01 00 00 48 89 f8 48 c1 e8 03 <42> 80 3c 20 00
0f 85 7e 02 00 00 0f b6 85 34 ff ff ff 48 8b 93 c0
RSP: 0018:ffff8880ae706c50 EFLAGS: 00010207
RAX: 001ffffffffbd5e1 RBX: 00ffffffffdead4e RCX: ffffffff8697b590
RDX: 0000000000000100 RSI: ffffffff8622238c RDI: 00ffffffffdeaf0e
RBP: ffff8880ae706d30 R08: ffff888060b26340 R09: ffffed1015ce5b8f
R10: ffffed1015ce5b8f R11: ffff8880ae72dc7b R12: dffffc0000000000
R13: 0000000000000000 R14: ffff88806556b6f0 R15: ffff88808e08b95d
FS: 00007eff2e401700(0000) GS:ffff8880ae700000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000001b2fb2c000 CR3: 000000008a036000 CR4: 00000000001406e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
---
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
* [PATCH] mdio_bus: Fix use-after-free on device_register fails
From: Yue Haibing @ 2019-02-21 14:42 UTC (permalink / raw)
To: andrew, f.fainelli, hkallweit1, davem; +Cc: linux-kernel, netdev, YueHaibing
From: YueHaibing <yuehaibing@huawei.com>
KASAN has found use-after-free in fixed_mdio_bus_init,
commit 0c692d07842a ("drivers/net/phy/mdio_bus.c: call
put_device on device_register() failure") call put_device()
while device_register() fails,give up the last reference
to the device and allow mdiobus_release to be executed
,kfreeing the bus. However in most drives, mdiobus_free
be called to free the bus while mdiobus_register fails.
use-after-free occurs when access bus again, this patch
revert it to let mdiobus_free free the bus.
KASAN report details as below:
BUG: KASAN: use-after-free in mdiobus_free+0x85/0x90 drivers/net/phy/mdio_bus.c:482
Read of size 4 at addr ffff8881dc824d78 by task syz-executor.0/3524
CPU: 1 PID: 3524 Comm: syz-executor.0 Not tainted 5.0.0-rc7+ #45
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1 04/01/2014
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0xfa/0x1ce lib/dump_stack.c:113
print_address_description+0x65/0x270 mm/kasan/report.c:187
kasan_report+0x149/0x18d mm/kasan/report.c:317
mdiobus_free+0x85/0x90 drivers/net/phy/mdio_bus.c:482
fixed_mdio_bus_init+0x283/0x1000 [fixed_phy]
? 0xffffffffc0e40000
? 0xffffffffc0e40000
? 0xffffffffc0e40000
do_one_initcall+0xfa/0x5ca init/main.c:887
do_init_module+0x204/0x5f6 kernel/module.c:3460
load_module+0x66b2/0x8570 kernel/module.c:3808
__do_sys_finit_module+0x238/0x2a0 kernel/module.c:3902
do_syscall_64+0x147/0x600 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x462e99
Code: f7 d8 64 89 02 b8 ff ff ff ff c3 66 0f 1f 44 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 73 01 c3 48 c7 c1 bc ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007f6215c19c58 EFLAGS: 00000246 ORIG_RAX: 0000000000000139
RAX: ffffffffffffffda RBX: 000000000073bf00 RCX: 0000000000462e99
RDX: 0000000000000000 RSI: 0000000020000080 RDI: 0000000000000003
RBP: 00007f6215c19c70 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 00007f6215c1a6bc
R13: 00000000004bcefb R14: 00000000006f7030 R15: 0000000000000004
Allocated by task 3524:
set_track mm/kasan/common.c:85 [inline]
__kasan_kmalloc.constprop.3+0xa0/0xd0 mm/kasan/common.c:496
kmalloc include/linux/slab.h:545 [inline]
kzalloc include/linux/slab.h:740 [inline]
mdiobus_alloc_size+0x54/0x1b0 drivers/net/phy/mdio_bus.c:143
fixed_mdio_bus_init+0x163/0x1000 [fixed_phy]
do_one_initcall+0xfa/0x5ca init/main.c:887
do_init_module+0x204/0x5f6 kernel/module.c:3460
load_module+0x66b2/0x8570 kernel/module.c:3808
__do_sys_finit_module+0x238/0x2a0 kernel/module.c:3902
do_syscall_64+0x147/0x600 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe
Freed by task 3524:
set_track mm/kasan/common.c:85 [inline]
__kasan_slab_free+0x130/0x180 mm/kasan/common.c:458
slab_free_hook mm/slub.c:1409 [inline]
slab_free_freelist_hook mm/slub.c:1436 [inline]
slab_free mm/slub.c:2986 [inline]
kfree+0xe1/0x270 mm/slub.c:3938
device_release+0x78/0x200 drivers/base/core.c:919
kobject_cleanup lib/kobject.c:662 [inline]
kobject_release lib/kobject.c:691 [inline]
kref_put include/linux/kref.h:67 [inline]
kobject_put+0x146/0x240 lib/kobject.c:708
put_device+0x1c/0x30 drivers/base/core.c:2060
__mdiobus_register+0x483/0x560 drivers/net/phy/mdio_bus.c:382
fixed_mdio_bus_init+0x26b/0x1000 [fixed_phy]
do_one_initcall+0xfa/0x5ca init/main.c:887
do_init_module+0x204/0x5f6 kernel/module.c:3460
load_module+0x66b2/0x8570 kernel/module.c:3808
__do_sys_finit_module+0x238/0x2a0 kernel/module.c:3902
do_syscall_64+0x147/0x600 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe
The buggy address belongs to the object at ffff8881dc824c80
which belongs to the cache kmalloc-2k of size 2048
The buggy address is located 248 bytes inside of
2048-byte region [ffff8881dc824c80, ffff8881dc825480)
The buggy address belongs to the page:
page:ffffea0007720800 count:1 mapcount:0 mapping:ffff8881f6c02800 index:0x0 compound_mapcount: 0
flags: 0x2fffc0000010200(slab|head)
raw: 02fffc0000010200 0000000000000000 0000000500000001 ffff8881f6c02800
raw: 0000000000000000 00000000800f000f 00000001ffffffff 0000000000000000
page dumped because: kasan: bad access detected
Memory state around the buggy address:
ffff8881dc824c00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
ffff8881dc824c80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
>ffff8881dc824d00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
^
ffff8881dc824d80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
ffff8881dc824e00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
Fixes: 0c692d07842a ("drivers/net/phy/mdio_bus.c: call put_device on device_register() failure")
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
---
drivers/net/phy/mdio_bus.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/net/phy/mdio_bus.c b/drivers/net/phy/mdio_bus.c
index debc74c..4be4cc0 100644
--- a/drivers/net/phy/mdio_bus.c
+++ b/drivers/net/phy/mdio_bus.c
@@ -373,7 +373,6 @@ int __mdiobus_register(struct mii_bus *bus, struct module *owner)
err = device_register(&bus->dev);
if (err) {
pr_err("mii_bus %s failed to register\n", bus->id);
- put_device(&bus->dev);
return -EINVAL;
}
--
2.7.4
^ permalink raw reply related
* Re: [PATCH] bpfilter: remove extra header search paths for bpfilter_umh
From: Guenter Roeck @ 2019-02-21 14:42 UTC (permalink / raw)
To: Masahiro Yamada
Cc: David S. Miller, Alexei Starovoitov, Daniel Borkmann, netdev,
linux-kernel
On Thu, Jan 31, 2019 at 12:15:35PM +0900, Masahiro Yamada wrote:
> Currently, the header search paths -Itools/include and
> -Itools/include/uapi are not used. Let's drop the unused code.
>
> We can remove -I. too by fixing up one C file.
>
This patch reintroduces the problem last fixed with commit ae40832e53c3
("bpfilter: fix a build err"). Seen (at least) with gcc 7.4.0, 8.2.0.
binutils version is 2.31.1. Reverting this patch fixes the problem.
Guenter
> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
> Signed-off-by: David S. Miller <davem@davemloft.net>
> ---
> net/bpfilter/Makefile | 1 -
> net/bpfilter/main.c | 2 +-
> 2 files changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/net/bpfilter/Makefile b/net/bpfilter/Makefile
> index 0947ee7f70d5..5d6c7760142d 100644
> --- a/net/bpfilter/Makefile
> +++ b/net/bpfilter/Makefile
> @@ -5,7 +5,6 @@
>
> hostprogs-y := bpfilter_umh
> bpfilter_umh-objs := main.o
> -KBUILD_HOSTCFLAGS += -I. -Itools/include/ -Itools/include/uapi
> HOSTCC := $(CC)
>
> ifeq ($(CONFIG_BPFILTER_UMH), y)
> diff --git a/net/bpfilter/main.c b/net/bpfilter/main.c
> index 1317f108df8a..61ce8454a88e 100644
> --- a/net/bpfilter/main.c
> +++ b/net/bpfilter/main.c
> @@ -6,7 +6,7 @@
> #include <sys/socket.h>
> #include <fcntl.h>
> #include <unistd.h>
> -#include "include/uapi/linux/bpf.h"
> +#include "../../include/uapi/linux/bpf.h"
> #include <asm/unistd.h>
> #include "msgfmt.h"
>
> --
> 2.7.4
^ permalink raw reply
* Re: [PATCH v2 1/2] Provide in-kernel headers for making it easy to extend the kernel
From: Masahiro Yamada @ 2019-02-21 14:34 UTC (permalink / raw)
To: Joel Fernandes
Cc: Alexei Starovoitov, Networking, Linux Kernel Mailing List,
Andrew Morton, Alexei Starovoitov, atish patra, Daniel Colascione,
Dan Williams, Greg Kroah-Hartman, Jonathan Corbet, Karim Yaghmour,
Kees Cook, kernel-team, open list:DOCUMENTATION,
open list:KERNEL SELFTEST FRAMEWORK, Manoj Rao, Paul McKenney,
Peter Zijlstra (Intel), Randy Dunlap, Steven Rostedt, Shuah Khan,
Thomas Gleixner, Yonghong Song
In-Reply-To: <20190219151652.GA110907@google.com>
On Wed, Feb 20, 2019 at 12:17 AM Joel Fernandes <joel@joelfernandes.org> wrote:
>
> Firstly, I want to apologize for not testing this and other corner cases you
> brought up. I should have known better. Since my build was working, I assumed
> that the feature is working. For that, I am very sorry.
You do not need to apologize. 0day bot usually catches build errors.
I guess 0day bot performs compile-tests only incrementally
and that is why we did not get any report.
> Secondly, it turns out Module.symvers circularly dependency problem also
> exists with another use case.
> If one does 'make modules_prepare' in a base kernel tree and then tries to
> build modules with that tree, a warning like this is printed but the module
> still gets built:
>
> WARNING: Symbol version dump ./Module.symvers
> is missing; modules will have no dependencies and modversions.
>
> CC [M] /tmp/testmod/test.o
> Building modules, stage 2.
> MODPOST 1 modules
> CC /tmp/testmod/test.mod.o
> LD [M] /tmp/testmod/test.ko
>
> So, I am thinking that at least for first pass I will just drop the inclusion
> of Module.symvers in the archive and allow any modules built using
> /proc/kheaders.tar.xz to not use it.
>
> Kbuild will print a warning anyway when anyone tries to build using
> /proc/kheaders.tar.xz, so if the user really wants module symbol versioning
> then they should probably use a full kernel source tree with Module.symvers
> available. For our usecase, kernel symbol versioning is a bit useless when
> using /proc/kheaders.tar.gz because the proc file is generated with the same
> kernel that the module is being built against, and subsequently loaded into
> the kernel. So it is not likely that the CRC of a kernel symbol will be
> different from what the module expects.
Without Module.symver, modpost cannot check whether references are
resolvable or not.
You will see "WARNING ... undefined" for every symbol referenced from
the module.
I am not an Android developer.
So, I will leave this judge to other people.
One more request if you have a chance to submit the next version.
Please do not hide error messages.
I wondered why you redirected stdout/stderr from the script.
I applied the following patch, and I tested. Then I see why.
Please fix your code instead of hiding underlying problems.
diff --git a/kernel/Makefile b/kernel/Makefile
index 1d13a7a..a76ccbd 100644
--- a/kernel/Makefile
+++ b/kernel/Makefile
@@ -148,7 +148,7 @@ $(obj)/kheaders.o: $(obj)/kheaders_data.h
targets += kheaders_data.txz
quiet_cmd_genikh = GEN $(obj)/kheaders_data.txz
-cmd_genikh = $(srctree)/scripts/gen_ikh_data.sh $@ $^ >/dev/null 2>&1
+cmd_genikh = $(srctree)/scripts/gen_ikh_data.sh $@ $^
$(obj)/kheaders_data.txz: $(ikh_file_list) FORCE
$(call cmd,genikh)
masahiro@grover:~/workspace/linux-yamada$ make
CALL scripts/checksyscalls.sh
DESCEND objtool
CHK include/generated/compile.h
GEN kernel/kheaders_data.txz
find: ‘FORCE’: No such file or directory
70106 blocks
Can't do inplace edit: kernel/kheaders_data.txz.tmp is not a regular file.
Can't do inplace edit: kernel/kheaders_data.txz.tmp/arch is not a regular file.
Can't do inplace edit: kernel/kheaders_data.txz.tmp/arch/x86 is not a
regular file.
Can't do inplace edit: kernel/kheaders_data.txz.tmp/arch/x86/include
is not a regular file.
Can't do inplace edit:
kernel/kheaders_data.txz.tmp/arch/x86/include/uapi is not a regular
file.
Can't do inplace edit:
kernel/kheaders_data.txz.tmp/arch/x86/include/uapi/asm is not a
regular file.
Can't do inplace edit:
kernel/kheaders_data.txz.tmp/arch/x86/include/generated is not a
regular file.
Can't do inplace edit:
kernel/kheaders_data.txz.tmp/arch/x86/include/generated/uapi is not a
regular file.
Can't do inplace edit:
kernel/kheaders_data.txz.tmp/arch/x86/include/generated/uapi/asm is
not a regular file.
Can't do inplace edit:
kernel/kheaders_data.txz.tmp/arch/x86/include/generated/asm is not a
regular file.
Can't do inplace edit:
kernel/kheaders_data.txz.tmp/arch/x86/include/asm is not a regular
file.
Can't do inplace edit:
kernel/kheaders_data.txz.tmp/arch/x86/include/asm/xen is not a regular
file.
Can't do inplace edit:
kernel/kheaders_data.txz.tmp/arch/x86/include/asm/uv is not a regular
file.
Can't do inplace edit:
kernel/kheaders_data.txz.tmp/arch/x86/include/asm/numachip is not a
regular file.
Can't do inplace edit:
kernel/kheaders_data.txz.tmp/arch/x86/include/asm/e820 is not a
regular file.
Can't do inplace edit:
kernel/kheaders_data.txz.tmp/arch/x86/include/asm/fpu is not a regular
file.
Can't do inplace edit:
kernel/kheaders_data.txz.tmp/arch/x86/include/asm/crypto is not a
regular file.
Can't do inplace edit:
kernel/kheaders_data.txz.tmp/arch/x86/include/asm/trace is not a
regular file.
Can't do inplace edit: kernel/kheaders_data.txz.tmp/scripts is not a
regular file.
Can't do inplace edit: kernel/kheaders_data.txz.tmp/scripts/genksyms
is not a regular file.
Can't do inplace edit: kernel/kheaders_data.txz.tmp/scripts/ksymoops
is not a regular file.
Can't do inplace edit: kernel/kheaders_data.txz.tmp/scripts/gdb is not
a regular file.
Can't do inplace edit: kernel/kheaders_data.txz.tmp/scripts/gdb/linux
is not a regular file.
Can't do inplace edit: kernel/kheaders_data.txz.tmp/scripts/basic is
not a regular file.
Can't do inplace edit: kernel/kheaders_data.txz.tmp/scripts/dtc is not
a regular file.
Can't do inplace edit: kernel/kheaders_data.txz.tmp/scripts/dtc/libfdt
is not a regular file.
Can't do inplace edit:
kernel/kheaders_data.txz.tmp/scripts/dtc/include-prefixes is not a
regular file.
Can't open kernel/kheaders_data.txz.tmp/scripts/dtc/include-prefixes/arm64:
No such file or directory.
Can't open kernel/kheaders_data.txz.tmp/scripts/dtc/include-prefixes/xtensa:
No such file or directory.
Can't open kernel/kheaders_data.txz.tmp/scripts/dtc/include-prefixes/openrisc:
No such file or directory.
Can't open kernel/kheaders_data.txz.tmp/scripts/dtc/include-prefixes/nios2:
No such file or directory.
Can't open kernel/kheaders_data.txz.tmp/scripts/dtc/include-prefixes/mips:
No such file or directory.
Can't open kernel/kheaders_data.txz.tmp/scripts/dtc/include-prefixes/arm:
No such file or directory.
Can't open kernel/kheaders_data.txz.tmp/scripts/dtc/include-prefixes/microblaze:
No such file or directory.
Can't open kernel/kheaders_data.txz.tmp/scripts/dtc/include-prefixes/arc:
No such file or directory.
Can't open kernel/kheaders_data.txz.tmp/scripts/dtc/include-prefixes/sh:
No such file or directory.
Can't open kernel/kheaders_data.txz.tmp/scripts/dtc/include-prefixes/powerpc:
No such file or directory.
Can't do inplace edit:
kernel/kheaders_data.txz.tmp/scripts/dtc/include-prefixes/dt-bindings
is not a regular file.
[ massive amount of error messages continues ]
> I can't think any other ways at the moment to break the circular dependency
> so I'm thinking this is good enough for now especially since Kbuild will
> print a proper warning. Let me know what you think?
>
> thanks,
>
> - Joel
>
--
Best Regards
Masahiro Yamada
^ permalink raw reply related
* Re: [PATCH v2 iproute2-next 05/11] devlink: Add devlink health show command
From: Jiri Pirko @ 2019-02-21 14:25 UTC (permalink / raw)
To: Aya Levin; +Cc: David Ahern, netdev, Jiri Pirko, Moshe Shemesh, Eran Ben Elisha
In-Reply-To: <1550756567-18227-6-git-send-email-ayal@mellanox.com>
Thu, Feb 21, 2019 at 02:42:41PM CET, ayal@mellanox.com wrote:
>Add devlink health show command which displays status and configuration
>info on a specific reporter on a device or dump the info on all
>reporters on all devices. The patch also contains helper functions to
What "patch"? Please format the description as you would command the
codebase what to do.
>display status and dump's time stamp.
[...]
>+static void pr_out_health(struct dl *dl, struct nlattr **tb_health)
>+{
>+ struct nlattr *tb[DEVLINK_ATTR_MAX + 1] = {};
>+ enum devlink_health_reporter_state state;
>+ const struct nlattr *attr;
>+ uint64_t time_ms;
>+ int err;
>+
>+ state = DEVLINK_HEALTH_REPORTER_STATE_HEALTHY;
Pointless assignment.
>+
>+ err = mnl_attr_parse_nested(tb_health[DEVLINK_ATTR_HEALTH_REPORTER],
>+ attr_cb, tb);
>+ if (err != MNL_CB_OK)
>+ return;
>+
>+ if (!tb[DEVLINK_ATTR_HEALTH_REPORTER_NAME] ||
>+ !tb[DEVLINK_ATTR_HEALTH_REPORTER_ERR_COUNT] ||
>+ !tb[DEVLINK_ATTR_HEALTH_REPORTER_RECOVER_COUNT] ||
>+ !tb[DEVLINK_ATTR_HEALTH_REPORTER_STATE])
>+ return;
>+
>+ pr_out_handle_start_arr(dl, tb_health);
>+
>+ pr_out_str(dl, "name",
>+ mnl_attr_get_str(tb[DEVLINK_ATTR_HEALTH_REPORTER_NAME]));
>+ if (!dl->json_output) {
>+ __pr_out_newline();
>+ __pr_out_indent_inc();
>+ }
>+ state = mnl_attr_get_u8(tb[DEVLINK_ATTR_HEALTH_REPORTER_STATE]);
>+ pr_out_str(dl, "state", health_state_name(state));
>+ pr_out_u64(dl, "error",
>+ mnl_attr_get_u64(tb[DEVLINK_ATTR_HEALTH_REPORTER_ERR_COUNT]));
>+ pr_out_u64(dl, "recover",
>+ mnl_attr_get_u64(tb[DEVLINK_ATTR_HEALTH_REPORTER_RECOVER_COUNT]));
>+ if (tb[DEVLINK_ATTR_HEALTH_REPORTER_DUMP_TS]) {
>+ char dump_date[HEALTH_REPORTER_TIMESTAMP_FMT_LEN];
>+ char dump_time[HEALTH_REPORTER_TIMESTAMP_FMT_LEN];
Newline here please.
>+ attr = tb[DEVLINK_ATTR_HEALTH_REPORTER_DUMP_TS];
>+ time_ms = mnl_attr_get_u64(attr);
>+ format_logtime(time_ms, dump_date, dump_time);
>+
>+ pr_out_str(dl, "last_dump_date", dump_date);
>+ pr_out_str(dl, "last_dump_time", dump_time);
>+ }
[...]
>@@ -5776,7 +5958,11 @@ static int dl_cmd(struct dl *dl, int argc, char **argv)
> } else if (dl_argv_match(dl, "region")) {
> dl_arg_inc(dl);
> return cmd_region(dl);
>+ } else if (dl_argv_match(dl, "health")) {
>+ dl_arg_inc(dl);
>+ return cmd_health(dl);
> }
>+
Please avoid newlines like this. Unrelated to the patch.
> pr_err("Object \"%s\" not found\n", dl_argv(dl));
> return -ENOENT;
> }
>--
>2.14.1
>
^ permalink raw reply
* Re: stmmac / meson8b-dwmac
From: Jerome Brunet @ 2019-02-21 14:21 UTC (permalink / raw)
To: Simon Huelck, Jose Abreu, Martin Blumenstingl
Cc: linux-amlogic, netdev, alexandre.torgue, Emiliano Ingrassia,
Gpeppe.cavallaro
In-Reply-To: <244d7c74-e0ca-a9c7-f4b0-3de7bec4024b@gmx.de>
On Tue, 2019-02-19 at 20:41 +0100, Simon Huelck wrote:
> Am 19.02.2019 um 09:47 schrieb Jose Abreu:
> > Hi Simon,
> >
> > On 2/18/2019 6:05 PM, Simon Huelck wrote:
> > > disabling EEE doesnt help ( did it via the entry in the .dtb / .dts ),
> > > the results are the same. I can confirm the LPI counters are zero or one
> > > only after the test.....
> > It's interesting to see that you have a lot of RX packets but few
> > RX interrupts. This can either be due to mis-configuration of
> > interrupt flags or RX Watchdog.
> >
> > 1. For interrupt flags you should be using LEVEL triggered IRQ.
> > 2. For RX Watchdog you can try disabling it by adding the
> > following in your platform wrapper driver (which will be
> > "dwmac-meson8b.c", at probe):
> > "plat_data->force_sf_dma_mode = 1;" and
> > "plat_data->riwt_off = 1;"
> >
> > Thanks,
> > Jose Miguel Abreu
>
> Hi,
>
>
> are you aware that odroid c2 dts is using level irq ?
The odroid-c2 (meson-gxl) is using level triggered irq, indeed.
For a reason that still eludes me, The odroid-c1 (meson8b) isn't.
This is confusing since both boards have been mentionned in this thread.
>
> at which numbers do you estimage that RX irqs are low in numbers ?
>
>
> regards,
>
> Simon
>
>
> _______________________________________________
> linux-amlogic mailing list
> linux-amlogic@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-amlogic
^ permalink raw reply
* Re: [PATCH v2 iproute2-next 04/11] devlink: Add helper functions for name and value separately
From: Jiri Pirko @ 2019-02-21 14:08 UTC (permalink / raw)
To: Aya Levin; +Cc: David Ahern, netdev, Jiri Pirko, Moshe Shemesh, Eran Ben Elisha
In-Reply-To: <1550756567-18227-5-git-send-email-ayal@mellanox.com>
Thu, Feb 21, 2019 at 02:42:40PM CET, ayal@mellanox.com wrote:
>Add a new helper functions which outputs only values (without name
>label) for different types: boolean, uint, uint64, string and binary.
>In addition add a helper function which prints only the name label.
>
>Signed-off-by: Aya Levin <ayal@mellanox.com>
>Reviewed-by: Moshe Shemesh <moshe@mellanox.com>
>---
> devlink/devlink.c | 66 ++++++++++++++++++++++++++++++++++++++++++++++++++++++-
> 1 file changed, 65 insertions(+), 1 deletion(-)
>
>diff --git a/devlink/devlink.c b/devlink/devlink.c
>index b073ae020d52..5d69c4f24f29 100644
>--- a/devlink/devlink.c
>+++ b/devlink/devlink.c
>@@ -1588,7 +1588,6 @@ static void pr_out_port_handle_end(struct dl *dl)
> pr_out("\n");
> }
>
>-
Please avoid changes like this.
[...]
^ permalink raw reply
* RE: [PATCH] drivers: net: phy: mdio-mux: Add support for Generic Mux controls
From: Pankaj Bansal @ 2019-02-21 14:15 UTC (permalink / raw)
To: Andrew Lunn
Cc: Leo Li, Peter Rosin, Florian Fainelli, Heiner Kallweit,
netdev@vger.kernel.org
In-Reply-To: <20190221134213.GD5653@lunn.ch>
> -----Original Message-----
> From: Andrew Lunn [mailto:andrew@lunn.ch]
> Sent: Thursday, 21 February, 2019 07:12 PM
> To: Pankaj Bansal <pankaj.bansal@nxp.com>
> Cc: Leo Li <leoyang.li@nxp.com>; Peter Rosin <peda@axentia.se>; Florian
> Fainelli <f.fainelli@gmail.com>; Heiner Kallweit <hkallweit1@gmail.com>;
> netdev@vger.kernel.org
> Subject: Re: [PATCH] drivers: net: phy: mdio-mux: Add support for Generic Mux
> controls
>
> On Thu, Feb 21, 2019 at 01:00:44PM +0000, Pankaj Bansal wrote:
> > Add support for Generic Mux controls, when Mdio mux node is a consumer
> > of mux produced by some other device.
> >
> > Signed-off-by: Pankaj Bansal <pankaj.bansal@nxp.com>
> > ---
> > drivers/net/phy/Kconfig | 1 +
> > drivers/net/phy/mdio-mux.c | 81 ++++++++++++++++++++++++++++++++++++
> > 2 files changed, 82 insertions(+)
> >
> > diff --git a/drivers/net/phy/Kconfig b/drivers/net/phy/Kconfig index
> > 3d187cd50eb0..e0e6b2b33d6d 100644
> > --- a/drivers/net/phy/Kconfig
> > +++ b/drivers/net/phy/Kconfig
> > @@ -47,6 +47,7 @@ config MDIO_BITBANG
> > config MDIO_BUS_MUX
> > tristate
> > depends on OF_MDIO
> > + select MULTIPLEXER
> > help
> > This module provides a driver framework for MDIO bus
> > multiplexers which connect one of several child MDIO busses
>
> Hi Pankaj
>
> Please add a MDIO_BUS_MUX_MULTIPLEXER and put all the code into mdio-
> mux-multiplexer.c
Isn't MUX short for MULTIPLEXER ? wouldn't this be more confusing ?
I have kept the mux APIs code unchanged, so as to not disturb the existing drivers that use these APIs.
>
> > +static const struct of_device_id mdio_mux_match[] = {
> > + { .compatible = "mdio-mux", },
>
> mdio-mux-multiplexer
Again, isn't mux short for multiplexer? wouldn't this be more confusing ?
>
> Thanks
> Andrew
^ permalink raw reply
* RE: [PATCH] dt-bindings: Add bindings for mdio mux consumers
From: Pankaj Bansal @ 2019-02-21 14:10 UTC (permalink / raw)
To: Andrew Lunn
Cc: Leo Li, Peter Rosin, Florian Fainelli, Heiner Kallweit,
Rob Herring, Mark Rutland, devicetree@vger.kernel.org,
netdev@vger.kernel.org
In-Reply-To: <20190221134504.GE5653@lunn.ch>
> -----Original Message-----
> From: Andrew Lunn [mailto:andrew@lunn.ch]
> Sent: Thursday, 21 February, 2019 07:15 PM
> To: Pankaj Bansal <pankaj.bansal@nxp.com>
> Cc: Leo Li <leoyang.li@nxp.com>; Peter Rosin <peda@axentia.se>; Florian
> Fainelli <f.fainelli@gmail.com>; Heiner Kallweit <hkallweit1@gmail.com>; Rob
> Herring <robh+dt@kernel.org>; Mark Rutland <mark.rutland@arm.com>;
> devicetree@vger.kernel.org; netdev@vger.kernel.org
> Subject: Re: [PATCH] dt-bindings: Add bindings for mdio mux consumers
>
> On Thu, Feb 21, 2019 at 12:59:19PM +0000, Pankaj Bansal wrote:
> > When we use the bindings defined in
> > Documentation/devicetree/bindings/mux
> > to define mdio mux in producer and consumer terms, it results in two
> > devices. one is mux producer and other is mux consumer.
> >
> > Add the bindings needed for Mdio mux consumer devices.
>
> Hi Pankaj
>
> Please thread this binding patch with the code which implements the binding.
> The two should be reviewed together.
OK. If you have any comments about this patch, then please let me know.
I will incorporate these when I send both patches together.
>
> Thanks
> Andrew
^ permalink raw reply
* [PATCH net-next 1/1] qed: Read device port count from the shmem
From: Sudarsana Reddy Kalluru @ 2019-02-21 14:03 UTC (permalink / raw)
To: davem; +Cc: netdev, aelior, mkalderon
Read port count from the shared memory instead of driver deriving this
value. This change simplifies the driver implementation and also avoids
any dependencies for finding the port-count.
Signed-off-by: Sudarsana Reddy Kalluru <skalluru@marvell.com>
Signed-off-by: Michal Kalderon <mkalderon@marvell.com>
---
drivers/net/ethernet/qlogic/qed/qed.h | 6 +-
drivers/net/ethernet/qlogic/qed/qed_dev.c | 95 ++++++++++++-------------------
drivers/net/ethernet/qlogic/qed/qed_l2.c | 4 +-
drivers/net/ethernet/qlogic/qed/qed_mcp.h | 4 --
drivers/net/ethernet/qlogic/qed/qed_ptp.c | 2 +-
5 files changed, 44 insertions(+), 67 deletions(-)
diff --git a/drivers/net/ethernet/qlogic/qed/qed.h b/drivers/net/ethernet/qlogic/qed/qed.h
index 2d21c94..43a57ec 100644
--- a/drivers/net/ethernet/qlogic/qed/qed.h
+++ b/drivers/net/ethernet/qlogic/qed/qed.h
@@ -753,6 +753,7 @@ struct qed_dev {
#define CHIP_BOND_ID_SHIFT 0
u8 num_engines;
+ u8 num_ports;
u8 num_ports_in_engine;
u8 num_funcs_in_port;
@@ -892,7 +893,6 @@ void qed_configure_vp_wfq_on_link_change(struct qed_dev *cdev,
void qed_clean_wfq_db(struct qed_hwfn *p_hwfn, struct qed_ptt *p_ptt);
int qed_device_num_engines(struct qed_dev *cdev);
-int qed_device_get_port_id(struct qed_dev *cdev);
void qed_set_fw_mac_addr(__le16 *fw_msb,
__le16 *fw_mid, __le16 *fw_lsb, u8 *mac);
@@ -939,6 +939,10 @@ void qed_db_recovery_execute(struct qed_hwfn *p_hwfn,
writel((u32)val, (void __iomem *)((u8 __iomem *)\
(cdev->doorbells) + (db_addr)))
+#define MFW_PORT(_p_hwfn) ((_p_hwfn)->abs_pf_id % \
+ qed_device_num_ports((_p_hwfn)->cdev))
+int qed_device_num_ports(struct qed_dev *cdev);
+
/* Prototypes */
int qed_fill_dev_info(struct qed_dev *cdev,
struct qed_dev_info *dev_info);
diff --git a/drivers/net/ethernet/qlogic/qed/qed_dev.c b/drivers/net/ethernet/qlogic/qed/qed_dev.c
index e2cbd77..9df8c4b 100644
--- a/drivers/net/ethernet/qlogic/qed/qed_dev.c
+++ b/drivers/net/ethernet/qlogic/qed/qed_dev.c
@@ -3269,55 +3269,43 @@ static void qed_get_num_funcs(struct qed_hwfn *p_hwfn, struct qed_ptt *p_ptt)
p_hwfn->enabled_func_idx, p_hwfn->num_funcs_on_engine);
}
-static void qed_hw_info_port_num_bb(struct qed_hwfn *p_hwfn,
- struct qed_ptt *p_ptt)
-{
- u32 port_mode;
-
- port_mode = qed_rd(p_hwfn, p_ptt, CNIG_REG_NW_PORT_MODE_BB);
-
- if (port_mode < 3) {
- p_hwfn->cdev->num_ports_in_engine = 1;
- } else if (port_mode <= 5) {
- p_hwfn->cdev->num_ports_in_engine = 2;
- } else {
- DP_NOTICE(p_hwfn, "PORT MODE: %d not supported\n",
- p_hwfn->cdev->num_ports_in_engine);
-
- /* Default num_ports_in_engine to something */
- p_hwfn->cdev->num_ports_in_engine = 1;
- }
-}
-
-static void qed_hw_info_port_num_ah(struct qed_hwfn *p_hwfn,
- struct qed_ptt *p_ptt)
+static void qed_hw_info_port_num(struct qed_hwfn *p_hwfn, struct qed_ptt *p_ptt)
{
- u32 port;
- int i;
-
- p_hwfn->cdev->num_ports_in_engine = 0;
+ u32 addr, global_offsize, global_addr, port_mode;
+ struct qed_dev *cdev = p_hwfn->cdev;
- for (i = 0; i < MAX_NUM_PORTS_K2; i++) {
- port = qed_rd(p_hwfn, p_ptt,
- CNIG_REG_NIG_PORT0_CONF_K2 + (i * 4));
- if (port & 1)
- p_hwfn->cdev->num_ports_in_engine++;
+ /* In CMT there is always only one port */
+ if (cdev->num_hwfns > 1) {
+ cdev->num_ports_in_engine = 1;
+ cdev->num_ports = 1;
+ return;
}
- if (!p_hwfn->cdev->num_ports_in_engine) {
- DP_NOTICE(p_hwfn, "All NIG ports are inactive\n");
-
- /* Default num_ports_in_engine to something */
- p_hwfn->cdev->num_ports_in_engine = 1;
+ /* Determine the number of ports per engine */
+ port_mode = qed_rd(p_hwfn, p_ptt, MISC_REG_PORT_MODE);
+ switch (port_mode) {
+ case 0x0:
+ cdev->num_ports_in_engine = 1;
+ break;
+ case 0x1:
+ cdev->num_ports_in_engine = 2;
+ break;
+ case 0x2:
+ cdev->num_ports_in_engine = 4;
+ break;
+ default:
+ DP_NOTICE(p_hwfn, "Unknown port mode 0x%08x\n", port_mode);
+ cdev->num_ports_in_engine = 1; /* Default to something */
+ break;
}
-}
-static void qed_hw_info_port_num(struct qed_hwfn *p_hwfn, struct qed_ptt *p_ptt)
-{
- if (QED_IS_BB(p_hwfn->cdev))
- qed_hw_info_port_num_bb(p_hwfn, p_ptt);
- else
- qed_hw_info_port_num_ah(p_hwfn, p_ptt);
+ /* Get the total number of ports of the device */
+ addr = SECTION_OFFSIZE_ADDR(p_hwfn->mcp_info->public_base,
+ PUBLIC_GLOBAL);
+ global_offsize = qed_rd(p_hwfn, p_ptt, addr);
+ global_addr = SECTION_ADDR(global_offsize, 0);
+ addr = global_addr + offsetof(struct public_global, max_ports);
+ cdev->num_ports = (u8)qed_rd(p_hwfn, p_ptt, addr);
}
static void qed_get_eee_caps(struct qed_hwfn *p_hwfn, struct qed_ptt *p_ptt)
@@ -3355,7 +3343,8 @@ static void qed_get_eee_caps(struct qed_hwfn *p_hwfn, struct qed_ptt *p_ptt)
return rc;
}
- qed_hw_info_port_num(p_hwfn, p_ptt);
+ if (IS_LEAD_HWFN(p_hwfn))
+ qed_hw_info_port_num(p_hwfn, p_ptt);
qed_mcp_get_capabilities(p_hwfn, p_ptt);
@@ -4760,23 +4749,9 @@ void qed_clean_wfq_db(struct qed_hwfn *p_hwfn, struct qed_ptt *p_ptt)
sizeof(*p_hwfn->qm_info.wfq_data) * p_hwfn->qm_info.num_vports);
}
-int qed_device_num_engines(struct qed_dev *cdev)
-{
- return QED_IS_BB(cdev) ? 2 : 1;
-}
-
-static int qed_device_num_ports(struct qed_dev *cdev)
-{
- /* in CMT always only one port */
- if (cdev->num_hwfns > 1)
- return 1;
-
- return cdev->num_ports_in_engine * qed_device_num_engines(cdev);
-}
-
-int qed_device_get_port_id(struct qed_dev *cdev)
+int qed_device_num_ports(struct qed_dev *cdev)
{
- return (QED_LEADING_HWFN(cdev)->abs_pf_id) % qed_device_num_ports(cdev);
+ return cdev->num_ports;
}
void qed_set_fw_mac_addr(__le16 *fw_msb,
diff --git a/drivers/net/ethernet/qlogic/qed/qed_l2.c b/drivers/net/ethernet/qlogic/qed/qed_l2.c
index 58be1c4..5764172 100644
--- a/drivers/net/ethernet/qlogic/qed/qed_l2.c
+++ b/drivers/net/ethernet/qlogic/qed/qed_l2.c
@@ -1898,6 +1898,7 @@ static void _qed_get_vport_stats(struct qed_dev *cdev,
struct qed_hwfn *p_hwfn = &cdev->hwfns[i];
struct qed_ptt *p_ptt = IS_PF(cdev) ? qed_ptt_acquire(p_hwfn)
: NULL;
+ bool b_get_port_stats;
if (IS_PF(cdev)) {
/* The main vport index is relative first */
@@ -1912,8 +1913,9 @@ static void _qed_get_vport_stats(struct qed_dev *cdev,
continue;
}
+ b_get_port_stats = IS_PF(cdev) && IS_LEAD_HWFN(p_hwfn);
__qed_get_vport_stats(p_hwfn, p_ptt, stats, fw_vport,
- IS_PF(cdev) ? true : false);
+ b_get_port_stats);
out:
if (IS_PF(cdev) && p_ptt)
diff --git a/drivers/net/ethernet/qlogic/qed/qed_mcp.h b/drivers/net/ethernet/qlogic/qed/qed_mcp.h
index 2799e67..261c1a3 100644
--- a/drivers/net/ethernet/qlogic/qed/qed_mcp.h
+++ b/drivers/net/ethernet/qlogic/qed/qed_mcp.h
@@ -691,10 +691,6 @@ int qed_mcp_bist_nvm_get_image_att(struct qed_hwfn *p_hwfn,
rel_pfid)
#define MCP_PF_ID(p_hwfn) MCP_PF_ID_BY_REL(p_hwfn, (p_hwfn)->rel_pf_id)
-#define MFW_PORT(_p_hwfn) ((_p_hwfn)->abs_pf_id % \
- ((_p_hwfn)->cdev->num_ports_in_engine * \
- qed_device_num_engines((_p_hwfn)->cdev)))
-
struct qed_mcp_info {
/* List for mailbox commands which were sent and wait for a response */
struct list_head cmd_list;
diff --git a/drivers/net/ethernet/qlogic/qed/qed_ptp.c b/drivers/net/ethernet/qlogic/qed/qed_ptp.c
index 5a90d69..1302b30 100644
--- a/drivers/net/ethernet/qlogic/qed/qed_ptp.c
+++ b/drivers/net/ethernet/qlogic/qed/qed_ptp.c
@@ -47,7 +47,7 @@
static enum qed_resc_lock qed_ptcdev_to_resc(struct qed_hwfn *p_hwfn)
{
- switch (qed_device_get_port_id(p_hwfn->cdev)) {
+ switch (MFW_PORT(p_hwfn)) {
case 0:
return QED_RESC_LOCK_PTP_PORT0;
case 1:
--
1.8.3.1
^ permalink raw reply related
* Re: Handling an Extra Signal at PHY Reset
From: Andrew Lunn @ 2019-02-21 14:04 UTC (permalink / raw)
To: Paul Kocialkowski
Cc: Florian Fainelli, Heiner Kallweit, netdev, Thomas Petazzoni,
Mylène Josserand
In-Reply-To: <efd27592a4f4e76fb5016d1ba1314d4e29003db3.camel@bootlin.com>
> I can also confirm that it does not prevent contacting the PHY on the
> MDIO bus, contrary to what I have stated previously.
O.K, so wrong voltage does not matter, you can still probe the PHY.
Ignore the switch. Use a pin hog to set the GPIO to the disabled
state. And set the voltage using the PHY register during probe().
Andrew
^ permalink raw reply
* Re: [bonding] 86838ad7bd: BUG:sleeping_function_called_from_invalid_context_at_kernel/locking/mutex.c
From: Kefeng Wang @ 2019-02-21 13:54 UTC (permalink / raw)
To: kernel test robot
Cc: netdev, Willem de Bruijn, David S . Miller, Jay Vosburgh,
Veaceslav Falico, Eric Dumazet, weiyongjun1, lkp
In-Reply-To: <20190221133259.74etmwq7gadltqew@inn2.lkp.intel.com>
Please ignore this patch, this is unacceptable, thanks.
On 2019/2/21 21:32, kernel test robot wrote:
> FYI, we noticed the following commit (built with gcc-8):
>
> commit: 86838ad7bde0d7741b272670d94d535580173d95 ("[RFC PATCH] bonding: use mutex lock in bond_get_stats()")
> url: https://github.com/0day-ci/linux/commits/Kefeng-Wang/bonding-use-mutex-lock-in-bond_get_stats/20190216-030058
>
>
> in testcase: rcutorture
> with following parameters:
>
> runtime: 300s
> test: cpuhotplug
> torture_type: srcu
>
> test-description: rcutorture is rcutorture kernel module load/unload test.
> test-url: https://www.kernel.org/doc/Documentation/RCU/torture.txt
>
>
> on test machine: qemu-system-x86_64 -enable-kvm -cpu SandyBridge -smp 2 -m 1G
>
> caused below changes (please refer to attached dmesg/kmsg for entire log/backtrace):
>
>
> +-----------------------------------------------------------------------------+------------+------------+
> | | f9bcc9f3ee | 86838ad7bd |
> +-----------------------------------------------------------------------------+------------+------------+
> | boot_successes | 50 | 24 |
> | boot_failures | 10 | 41 |
> | invoked_oom-killer:gfp_mask=0x | 1 | |
> | Mem-Info | 1 | |
> | Out_of_memory:Kill_process | 1 | |
> | BUG:kernel_in_stage | 6 | 8 |
> | BUG:kernel_reboot-without-warning_in_early-boot_stage | 2 | |
> | BUG:kernel_hang_in_test_stage | 1 | 1 |
> | BUG:sleeping_function_called_from_invalid_context_at_kernel/locking/mutex.c | 0 | 32 |
> +-----------------------------------------------------------------------------+------------+------------+
>
>
>
> [ 17.153431] BUG: sleeping function called from invalid context at kernel/locking/mutex.c:908
> [ 17.157556] in_atomic(): 0, irqs_disabled(): 0, pid: 599, name: dropbearkey
> [ 17.159141] 2 locks held by dropbearkey/599:
> [ 17.159779] #0: (____ptrval____) (&p->lock){+.+.}, at: seq_read+0x41/0x3f0
> [ 17.160802] #1: (____ptrval____) (rcu_read_lock){....}, at: dev_seq_start+0x5/0x110
> [ 17.161928] Preemption disabled at:
> [ 17.161935] [<ffffffff818eafe0>] __mutex_lock+0x50/0x980
> [ 17.163150] CPU: 1 PID: 599 Comm: dropbearkey Not tainted 5.0.0-rc5-00320-g86838ad #1
> [ 17.164213] Call Trace:
> [ 17.164571] dump_stack+0x67/0x90
> [ 17.165051] ___might_sleep.cold.14+0xf0/0x106
> [ 17.165675] ? bond_get_stats+0x3b/0x260
> [ 17.166232] __mutex_lock+0x46/0x980
> [ 17.166743] ? kvm_clock_read+0x14/0x30
> [ 17.167288] ? validate_chain+0xb5/0xad0
> [ 17.167936] ? number+0x2fc/0x340
> [ 17.168416] ? bond_get_stats+0x3b/0x260
> [ 17.168966] bond_get_stats+0x3b/0x260
> [ 17.169500] ? seq_vprintf+0x30/0x50
> [ 17.170007] ? seq_printf+0x43/0x50
> [ 17.170498] ? validate_chain+0xb5/0xad0
> [ 17.171136] ? dev_seq_printf_stats+0x9a/0xb0
> [ 17.171736] dev_get_stats+0x55/0xb0
> [ 17.172221] dev_seq_printf_stats+0x1f/0xb0
> [ 17.172817] dev_seq_show+0x10/0x30
> [ 17.173289] seq_read+0x2cd/0x3f0
> [ 17.173777] proc_reg_read+0x36/0x60
> [ 17.174288] __vfs_read+0x23/0x160
> [ 17.174779] ? _copy_to_user+0x5e/0x70
> [ 17.175312] ? entry_INT80_compat+0x7c/0x90
> [ 17.175903] vfs_read+0xa6/0x140
> [ 17.176366] ksys_read+0x42/0xa0
> [ 17.176834] do_int80_syscall_32+0x4f/0x150
> [ 17.177418] entry_INT80_compat+0x84/0x90
> LKP: HOSTNAME vm-snb-openwrt-ia32-524, MAC , kernel 5.0.0-rc5-00320-g86838ad 1, serial console /dev/ttyS0
> [ 18.404764] Kernel tests: Boot OK!
> [ 18.404764] LKP: waiting for network...
> [ 19.256982] e1000: eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX
> [ 19.271235] _warn_unseeded_randomness: 1329 callbacks suppressed
> [ 19.271244] random: get_random_u64 called from arch_pick_mmap_layout+0x65/0x170 with crng_init=0
> [ 19.273507] random: get_random_u64 called from arch_pick_mmap_layout+0x10e/0x170 with crng_init=0
> [ 19.274790] random: get_random_u64 called from load_elf_binary+0x87d/0x1120 with crng_init=0
> [ 20.407748] /lkp/lkp/src/bin/run-lkp
> [ 20.407748] RESULT_ROOT=/result/rcutorture/300s-cpuhotplug-srcu/vm-snb-openwrt-ia32/openwrt-i386-2016-03-16.cgz/x86_64-randconfig-s4-02200400/gcc-8/86838ad7bde0d7741b272670d94d535580173d95/3
> [ 20.407748] job=/lkp/jobs/scheduled/vm-snb-openwrt-ia32-524/rcutorture-300s-cpuhotplug-srcu-openwrt-i386-2016-03-16.cgz-20190220-89648-gjivxf-3.yaml
> [ 20.407748] run-job /lkp/jobs/scheduled/vm-snb-openwrt-ia32-524/rcutorture-300s-cpuhotplug-srcu-openwrt-i386-2016-03-16.cgz-20190220-89648-gjivxf-3.yaml
> [ 20.407748] /bin/busybox wget -q http://inn:80/~lkp/cgi-bin/lkp-jobfile-append-var?job_file=/lkp/jobs/scheduled/vm-snb-openwrt-ia32-524/rcutorture-300s-cpuhotplug-srcu-openwrt-i386-2016-03-16.cgz-20190220-89648-gjivxf-3.yaml&job_state=running -O /dev/null
> [ 20.407748] target ucode:
> [ 20.416008] wget: can't connect to remote host (192.168.1.1): Network is unreachable
> [ 20.416008] /lkp/lkp/src/monitors/heartbeat: line 9: vmstat: not found
> [ 20.416008] /lkp/lkp/src/monitors/heartbeat: exec: line 23: vmstat: not found
> [ 20.678602] _warn_unseeded_randomness: 431 callbacks suppressed
> [ 20.678610] random: get_random_u64 called from arch_pick_mmap_layout+0x65/0x170 with crng_init=0
> [ 20.681816] random: get_random_u64 called from arch_pick_mmap_layout+0x10e/0x170 with crng_init=0
> [ 20.683622] random: get_random_u64 called from load_elf_binary+0x87d/0x1120 with crng_init=0
> [ 21.418765] BusyBox v1.23.2 (2016-01-02 14:31:17 CET) multi-call binary.
> [ 21.418765]
> [ 21.418765] Usage: time [-v] PROG ARGS
> [ 21.418765]
> [ 21.418765] Run PROG, display resource usage when it exits
> [ 21.418765]
> [ 21.418765] -v Verbose
> [ 21.418765]
> [ 21.418765] failed to load rcutorture module, try to enable CONFIG_RCU_TORTURE_TEST and build rcutorture.ko
> [ 21.418765] wget: can't connect to remote host (192.168.1.1): Network is unreachable
> [ 21.423344] 2019-02-20 06:29:25 modprobe rcutorture onoff_interval=3 onoff_holdoff=30 torture_type=srcu
> [ 21.423344] /bin/busybox wget -q http://inn:80/~lkp/cgi-bin/lkp-jobfile-append-var?job_file=/lkp/jobs/scheduled/vm-snb-openwrt-ia32-524/rcutorture-300s-cpuhotplug-srcu-openwrt-i386-2016-03-16.cgz-20190220-89648-gjivxf-3.yaml&job_state=post_run -O /dev/null
> [ 21.818029] _warn_unseeded_randomness: 210 callbacks suppressed
> [ 21.818037] random: get_random_u64 called from arch_pick_mmap_layout+0x65/0x170 with crng_init=0
> [ 21.821714] random: get_random_u64 called from arch_pick_mmap_layout+0x10e/0x170 with crng_init=0
> [ 21.823918] random: get_random_u64 called from load_elf_binary+0x87d/0x1120 with crng_init=0
> [ 22.190264] e1000: eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX
> [ 22.444763] kill 804 cat /proc/kmsg
> [ 22.444763] wait for background processes: 812 810 oom-killer meminfo
>
> Elapsed time: 20
>
> qemu-img create -f qcow2 disk-vm-snb-openwrt-ia32-524-0 256G
> qemu-img create -f qcow2 disk-vm-snb-openwrt-ia32-524-1 256G
>
> kvm=(
> qemu-system-x86_64
> -enable-kvm
> -cpu SandyBridge
> -kernel $kernel
> -initrd initrd-vm-snb-openwrt-ia32-524
> -m 1024
> -smp 2
> -device e1000,netdev=net0
> -netdev user,id=net0
> -boot order=nc
> -no-reboot
> -watchdog i6300esb
> -watchdog-action debug
> -rtc base=localtime
> -drive file=disk-vm-snb-openwrt-ia32-524-0,media=disk,if=virtio
> -drive file=disk-vm-snb-openwrt-ia32-524-1,media=disk,if=virtio
> -serial stdio
> -display none
> -monitor null
> )
>
>
> To reproduce:
>
> git clone https://github.com/intel/lkp-tests.git
> cd lkp-tests
> bin/lkp qemu -k <bzImage> job-script # job-script is attached in this email
>
>
>
> Thanks,
> Rong Chen
^ permalink raw reply
* Re: [PATCH] dt-bindings: Add bindings for mdio mux consumers
From: Andrew Lunn @ 2019-02-21 13:45 UTC (permalink / raw)
To: Pankaj Bansal
Cc: Leo Li, Peter Rosin, Florian Fainelli, Heiner Kallweit,
Rob Herring, Mark Rutland, devicetree@vger.kernel.org,
netdev@vger.kernel.org
In-Reply-To: <20190221182349.4057-1-pankaj.bansal@nxp.com>
On Thu, Feb 21, 2019 at 12:59:19PM +0000, Pankaj Bansal wrote:
> When we use the bindings defined in Documentation/devicetree/bindings/mux
> to define mdio mux in producer and consumer terms, it results in two
> devices. one is mux producer and other is mux consumer.
>
> Add the bindings needed for Mdio mux consumer devices.
Hi Pankaj
Please thread this binding patch with the code which implements the
binding. The two should be reviewed together.
Thanks
Andrew
^ permalink raw reply
* [PATCH v2 iproute2-next 01/11] devlink: Refactor validation of finding required arguments
From: Aya Levin @ 2019-02-21 13:42 UTC (permalink / raw)
To: David Ahern; +Cc: netdev, Jiri Pirko, Moshe Shemesh, Eran Ben Elisha, Aya Levin
In-Reply-To: <1550756567-18227-1-git-send-email-ayal@mellanox.com>
Introducing argument's metadata structure matching a bitmap flag per
required argument and an error message if missing. Using this static
array to refactor validation of finding required arguments in devlink
command line and to ease further maintenance.
Signed-off-by: Aya Levin <ayal@mellanox.com>
Reviewed-by: Moshe Shemesh <moshe@mellanox.com>
Acked-by: Jiri Pirko <jiri@mellanox.com>
---
devlink/devlink.c | 153 ++++++++++++++++--------------------------------------
1 file changed, 45 insertions(+), 108 deletions(-)
diff --git a/devlink/devlink.c b/devlink/devlink.c
index d823512a4030..fbaf9c9fabda 100644
--- a/devlink/devlink.c
+++ b/devlink/devlink.c
@@ -39,6 +39,7 @@
#define PARAM_CMODE_RUNTIME_STR "runtime"
#define PARAM_CMODE_DRIVERINIT_STR "driverinit"
#define PARAM_CMODE_PERMANENT_STR "permanent"
+#define DL_ARGS_REQUIRED_MAX_ERR_LEN 80
static int g_new_line_count;
@@ -950,6 +951,49 @@ static int param_cmode_get(const char *cmodestr,
return 0;
}
+struct dl_args_metadata {
+ uint32_t o_flag;
+ char err_msg[DL_ARGS_REQUIRED_MAX_ERR_LEN];
+};
+
+static const struct dl_args_metadata dl_args_required[] = {
+ {DL_OPT_PORT_TYPE, "Port type not set."},
+ {DL_OPT_PORT_COUNT, "Port split count option expected."},
+ {DL_OPT_SB_POOL, "Pool index option expected."},
+ {DL_OPT_SB_SIZE, "Pool size option expected."},
+ {DL_OPT_SB_TYPE, "Pool type option expected."},
+ {DL_OPT_SB_THTYPE, "Pool threshold type option expected."},
+ {DL_OPT_SB_TH, "Threshold option expected."},
+ {DL_OPT_SB_TC, "TC index option expected."},
+ {DL_OPT_ESWITCH_MODE, "E-Switch mode option expected."},
+ {DL_OPT_ESWITCH_INLINE_MODE, "E-Switch inline-mode option expected."},
+ {DL_OPT_DPIPE_TABLE_NAME, "Dpipe table name expected."},
+ {DL_OPT_DPIPE_TABLE_COUNTERS, "Dpipe table counter state expected."},
+ {DL_OPT_ESWITCH_ENCAP_MODE, "E-Switch encapsulation option expected."},
+ {DL_OPT_PARAM_NAME, "Parameter name expected."},
+ {DL_OPT_PARAM_VALUE, "Value to set expected."},
+ {DL_OPT_PARAM_CMODE, "Configuration mode expected."},
+ {DL_OPT_REGION_SNAPSHOT_ID, "Region snapshot id expected."},
+ {DL_OPT_REGION_ADDRESS, "Region address value expected."},
+ {DL_OPT_REGION_LENGTH, "Region length value expected."},
+};
+
+static int dl_args_finding_required_validate(uint32_t o_required,
+ uint32_t o_found)
+{
+ uint32_t o_flag;
+ int i;
+
+ for (i = 0; i < ARRAY_SIZE(dl_args_required); i++) {
+ o_flag = dl_args_required[i].o_flag;
+ if ((o_required & o_flag) && !(o_found & o_flag)) {
+ pr_err("%s\n", dl_args_required[i].err_msg);
+ return -EINVAL;
+ }
+ }
+ return 0;
+}
+
static int dl_argv_parse(struct dl *dl, uint32_t o_required,
uint32_t o_optional)
{
@@ -1198,114 +1242,7 @@ static int dl_argv_parse(struct dl *dl, uint32_t o_required,
opts->present |= DL_OPT_SB;
}
- if ((o_required & DL_OPT_PORT_TYPE) && !(o_found & DL_OPT_PORT_TYPE)) {
- pr_err("Port type option expected.\n");
- return -EINVAL;
- }
-
- if ((o_required & DL_OPT_PORT_COUNT) &&
- !(o_found & DL_OPT_PORT_COUNT)) {
- pr_err("Port split count option expected.\n");
- return -EINVAL;
- }
-
- if ((o_required & DL_OPT_SB_POOL) && !(o_found & DL_OPT_SB_POOL)) {
- pr_err("Pool index option expected.\n");
- return -EINVAL;
- }
-
- if ((o_required & DL_OPT_SB_SIZE) && !(o_found & DL_OPT_SB_SIZE)) {
- pr_err("Pool size option expected.\n");
- return -EINVAL;
- }
-
- if ((o_required & DL_OPT_SB_TYPE) && !(o_found & DL_OPT_SB_TYPE)) {
- pr_err("Pool type option expected.\n");
- return -EINVAL;
- }
-
- if ((o_required & DL_OPT_SB_THTYPE) && !(o_found & DL_OPT_SB_THTYPE)) {
- pr_err("Pool threshold type option expected.\n");
- return -EINVAL;
- }
-
- if ((o_required & DL_OPT_SB_TH) && !(o_found & DL_OPT_SB_TH)) {
- pr_err("Threshold option expected.\n");
- return -EINVAL;
- }
-
- if ((o_required & DL_OPT_SB_TC) && !(o_found & DL_OPT_SB_TC)) {
- pr_err("TC index option expected.\n");
- return -EINVAL;
- }
-
- if ((o_required & DL_OPT_ESWITCH_MODE) &&
- !(o_found & DL_OPT_ESWITCH_MODE)) {
- pr_err("E-Switch mode option expected.\n");
- return -EINVAL;
- }
-
- if ((o_required & DL_OPT_ESWITCH_INLINE_MODE) &&
- !(o_found & DL_OPT_ESWITCH_INLINE_MODE)) {
- pr_err("E-Switch inline-mode option expected.\n");
- return -EINVAL;
- }
-
- if ((o_required & DL_OPT_DPIPE_TABLE_NAME) &&
- !(o_found & DL_OPT_DPIPE_TABLE_NAME)) {
- pr_err("Dpipe table name expected\n");
- return -EINVAL;
- }
-
- if ((o_required & DL_OPT_DPIPE_TABLE_COUNTERS) &&
- !(o_found & DL_OPT_DPIPE_TABLE_COUNTERS)) {
- pr_err("Dpipe table counter state expected\n");
- return -EINVAL;
- }
-
- if ((o_required & DL_OPT_ESWITCH_ENCAP_MODE) &&
- !(o_found & DL_OPT_ESWITCH_ENCAP_MODE)) {
- pr_err("E-Switch encapsulation option expected.\n");
- return -EINVAL;
- }
-
- if ((o_required & DL_OPT_PARAM_NAME) &&
- !(o_found & DL_OPT_PARAM_NAME)) {
- pr_err("Parameter name expected.\n");
- return -EINVAL;
- }
-
- if ((o_required & DL_OPT_PARAM_VALUE) &&
- !(o_found & DL_OPT_PARAM_VALUE)) {
- pr_err("Value to set expected.\n");
- return -EINVAL;
- }
-
- if ((o_required & DL_OPT_PARAM_CMODE) &&
- !(o_found & DL_OPT_PARAM_CMODE)) {
- pr_err("Configuration mode expected.\n");
- return -EINVAL;
- }
-
- if ((o_required & DL_OPT_REGION_SNAPSHOT_ID) &&
- !(o_found & DL_OPT_REGION_SNAPSHOT_ID)) {
- pr_err("Region snapshot id expected.\n");
- return -EINVAL;
- }
-
- if ((o_required & DL_OPT_REGION_ADDRESS) &&
- !(o_found & DL_OPT_REGION_ADDRESS)) {
- pr_err("Region address value expected.\n");
- return -EINVAL;
- }
-
- if ((o_required & DL_OPT_REGION_LENGTH) &&
- !(o_found & DL_OPT_REGION_LENGTH)) {
- pr_err("Region length value expected.\n");
- return -EINVAL;
- }
-
- return 0;
+ return dl_args_finding_required_validate(o_required, o_found);
}
static void dl_opts_put(struct nlmsghdr *nlh, struct dl *dl)
--
2.14.1
^ permalink raw reply related
* [PATCH v2 iproute2-next 02/11] devlink: Fix print of uint64_t
From: Aya Levin @ 2019-02-21 13:42 UTC (permalink / raw)
To: David Ahern; +Cc: netdev, Jiri Pirko, Moshe Shemesh, Eran Ben Elisha, Aya Levin
In-Reply-To: <1550756567-18227-1-git-send-email-ayal@mellanox.com>
This patch prints uint64_t with its corresponding format and avoid implicit
cast to uint32_t.
Signed-off-by: Aya Levin <ayal@mellanox.com>
Reviewed-by: Moshe Shemesh <moshe@mellanox.com>
Acked-by: Jiri Pirko <jiri@mellanox.com>
---
devlink/devlink.c | 9 ++++++++-
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/devlink/devlink.c b/devlink/devlink.c
index fbaf9c9fabda..2c921f3811fc 100644
--- a/devlink/devlink.c
+++ b/devlink/devlink.c
@@ -1626,7 +1626,14 @@ static void pr_out_u64(struct dl *dl, const char *name, uint64_t val)
if (val == (uint64_t) -1)
return pr_out_str(dl, name, "unlimited");
- return pr_out_uint(dl, name, val);
+ if (dl->json_output) {
+ jsonw_u64_field(dl->jw, name, val);
+ } else {
+ if (g_indent_newline)
+ pr_out("%s %lu", name, val);
+ else
+ pr_out(" %s %lu", name, val);
+ }
}
static void pr_out_region_chunk_start(struct dl *dl, uint64_t addr)
--
2.14.1
^ permalink raw reply related
* [PATCH v2 iproute2-next 07/11] devlink: Add devlink health diagnose command
From: Aya Levin @ 2019-02-21 13:42 UTC (permalink / raw)
To: David Ahern; +Cc: netdev, Jiri Pirko, Moshe Shemesh, Eran Ben Elisha, Aya Levin
In-Reply-To: <1550756567-18227-1-git-send-email-ayal@mellanox.com>
Add devlink health diagnose command: enabling retrieval of diagnostics data
by the user on a reporter on a device. The command's output is a
free text defined by the reporter.
This patch also introduces an infra structure for flexible format
output. This allow the command to display different data fields
according to the reporter.
Example:
$ devlink health diagnose pci/0000:00:0a.0 reporter tx
SQs:
sqn: 4403 HW state: 1 stopped: false
sqn: 4408 HW state: 1 stopped: false
sqn: 4413 HW state: 1 stopped: false
sqn: 4418 HW state: 1 stopped: false
sqn: 4423 HW state: 1 stopped: false
$ devlink health diagnose pci/0000:00:0a.0 reporter tx -jp
{
"SQs":[
{
"sqn":4403,
"HW state":1,
"stopped":false
},
{
"sqn":4408,
"HW state":1,
"stopped":false
},
{
"sqn":4413,
"HW state":1,
"stopped":false
},
{
"sqn":4418,
"HW state":1,
"stopped":false
},
{
"sqn":4423,
"HW state":1,
"stopped":false
}
]
}
Signed-off-by: Aya Levin <ayal@mellanox.com>
Reviewed-by: Moshe Shemesh <moshe@mellanox.com>
---
devlink/devlink.c | 187 ++++++++++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 187 insertions(+)
diff --git a/devlink/devlink.c b/devlink/devlink.c
index 3ec0ef4b95b2..ef6a72f0b04e 100644
--- a/devlink/devlink.c
+++ b/devlink/devlink.c
@@ -23,6 +23,7 @@
#include <libmnl/libmnl.h>
#include <netinet/ether.h>
#include <sys/sysinfo.h>
+#include <sys/queue.h>
#include "SNAPSHOT.h"
#include "list.h"
@@ -5764,6 +5765,188 @@ static int cmd_region(struct dl *dl)
return -ENOENT;
}
+static int fmsg_value_show(struct dl *dl, int type, struct nlattr *nl_data)
+{
+ uint8_t *data;
+ uint32_t len;
+
+ switch (type) {
+ case MNL_TYPE_FLAG:
+ pr_out_bool_value(dl, mnl_attr_get_u8(nl_data));
+ break;
+ case MNL_TYPE_U8:
+ pr_out_uint_value(dl, mnl_attr_get_u8(nl_data));
+ break;
+ case MNL_TYPE_U16:
+ pr_out_uint_value(dl, mnl_attr_get_u16(nl_data));
+ break;
+ case MNL_TYPE_U32:
+ pr_out_uint_value(dl, mnl_attr_get_u32(nl_data));
+ break;
+ case MNL_TYPE_U64:
+ pr_out_uint64_value(dl, mnl_attr_get_u64(nl_data));
+ break;
+ case MNL_TYPE_NUL_STRING:
+ pr_out_str_value(dl, mnl_attr_get_str(nl_data));
+ break;
+ case MNL_TYPE_BINARY:
+ len = mnl_attr_get_payload_len(nl_data);
+ data = mnl_attr_get_payload(nl_data);
+ pr_out_binary_value(dl, data, len);
+ break;
+ default:
+ return -EINVAL;
+ }
+ return MNL_CB_OK;
+}
+
+struct nest_qentry {
+ int attr_type;
+ TAILQ_ENTRY(nest_qentry) nest_entries;
+};
+
+struct fmsg_cb_data {
+ struct dl *dl;
+ uint8_t value_type;
+ TAILQ_HEAD(, nest_qentry) qhead;
+};
+
+static int cmd_fmsg_nest_queue(struct fmsg_cb_data *fmsg_data,
+ uint8_t *attr_value, bool insert)
+{
+ struct nest_qentry *entry = NULL;
+
+ if (insert) {
+ entry = malloc(sizeof(struct nest_qentry));
+ if (!entry)
+ return -ENOMEM;
+
+ entry->attr_type = *attr_value;
+ TAILQ_INSERT_HEAD(&fmsg_data->qhead, entry, nest_entries);
+ } else {
+ if (TAILQ_EMPTY(&fmsg_data->qhead))
+ return MNL_CB_ERROR;
+ entry = TAILQ_FIRST(&fmsg_data->qhead);
+ *attr_value = entry->attr_type;
+ TAILQ_REMOVE(&fmsg_data->qhead, entry, nest_entries);
+ free(entry);
+ }
+ return MNL_CB_OK;
+}
+
+static int cmd_fmsg_nest(struct fmsg_cb_data *fmsg_data, uint8_t nest_value,
+ bool start)
+{
+ struct dl *dl = fmsg_data->dl;
+ uint8_t value = nest_value;
+ int err;
+
+ err = cmd_fmsg_nest_queue(fmsg_data, &value, start);
+ if (err != MNL_CB_OK)
+ return err;
+
+ switch (value) {
+ case DEVLINK_ATTR_FMSG_OBJ_NEST_START:
+ if (start)
+ pr_out_entry_start(dl);
+ else
+ pr_out_entry_end(dl);
+ break;
+ case DEVLINK_ATTR_FMSG_PAIR_NEST_START:
+ break;
+ case DEVLINK_ATTR_FMSG_ARR_NEST_START:
+ if (dl->json_output) {
+ if (start)
+ jsonw_start_array(dl->jw);
+ else
+ jsonw_end_array(dl->jw);
+ } else {
+ if (start) {
+ __pr_out_newline();
+ __pr_out_indent_inc();
+ } else {
+ __pr_out_indent_dec();
+ }
+ }
+ break;
+ default:
+ return -EINVAL;
+ }
+ return MNL_CB_OK;
+}
+
+static int cmd_fmsg_object_cb(const struct nlmsghdr *nlh, void *data)
+{
+ struct genlmsghdr *genl = mnl_nlmsg_get_payload(nlh);
+ struct nlattr *tb[DEVLINK_ATTR_MAX + 1] = {};
+ struct fmsg_cb_data *fmsg_data = data;
+ struct dl *dl = fmsg_data->dl;
+ struct nlattr *nla_object;
+ int attr_type;
+ int err;
+
+ mnl_attr_parse(nlh, sizeof(*genl), attr_cb, tb);
+ if (!tb[DEVLINK_ATTR_FMSG])
+ return MNL_CB_ERROR;
+
+ mnl_attr_for_each_nested(nla_object, tb[DEVLINK_ATTR_FMSG]) {
+ attr_type = mnl_attr_get_type(nla_object);
+ switch (attr_type) {
+ case DEVLINK_ATTR_FMSG_OBJ_NEST_START:
+ case DEVLINK_ATTR_FMSG_PAIR_NEST_START:
+ case DEVLINK_ATTR_FMSG_ARR_NEST_START:
+ err = cmd_fmsg_nest(fmsg_data, attr_type, true);
+ if (err != MNL_CB_OK)
+ return err;
+ break;
+ case DEVLINK_ATTR_FMSG_NEST_END:
+ err = cmd_fmsg_nest(fmsg_data, attr_type, false);
+ if (err != MNL_CB_OK)
+ return err;
+ break;
+ case DEVLINK_ATTR_FMSG_OBJ_NAME:
+ pr_out_name(dl, mnl_attr_get_str(nla_object));
+ break;
+ case DEVLINK_ATTR_FMSG_OBJ_VALUE_TYPE:
+ fmsg_data->value_type = mnl_attr_get_u8(nla_object);
+ break;
+ case DEVLINK_ATTR_FMSG_OBJ_VALUE_DATA:
+ err = fmsg_value_show(dl, fmsg_data->value_type,
+ nla_object);
+ if (err != MNL_CB_OK)
+ return err;
+ break;
+ default:
+ return -EINVAL;
+ }
+ }
+ return MNL_CB_OK;
+}
+
+static int cmd_health_object_common(struct dl *dl, uint8_t cmd)
+{
+ struct fmsg_cb_data data;
+ struct nlmsghdr *nlh;
+ int err;
+
+ nlh = mnlg_msg_prepare(dl->nlg, cmd, NLM_F_REQUEST | NLM_F_ACK);
+
+ err = dl_argv_parse_put(nlh, dl,
+ DL_OPT_HANDLE | DL_OPT_HEALTH_REPORTER_NAME, 0);
+ if (err)
+ return err;
+
+ data.dl = dl;
+ TAILQ_INIT(&data.qhead);
+ err = _mnlg_socket_sndrcv(dl->nlg, nlh, cmd_fmsg_object_cb, &data);
+ return err;
+}
+
+static int cmd_health_diagnose(struct dl *dl)
+{
+ return cmd_health_object_common(dl, DEVLINK_CMD_HEALTH_REPORTER_DIAGNOSE);
+}
+
static int cmd_health_recover(struct dl *dl)
{
struct nlmsghdr *nlh;
@@ -5922,6 +6105,7 @@ static void cmd_health_help(void)
{
pr_err("Usage: devlink health show [ dev DEV reporter REPORTER_NAME ]\n");
pr_err(" devlink health recover DEV reporter REPORTER_NAME\n");
+ pr_err(" devlink health diagnose DEV reporter REPORTER_NAME\n");
}
static int cmd_health(struct dl *dl)
@@ -5936,6 +6120,9 @@ static int cmd_health(struct dl *dl)
} else if (dl_argv_match(dl, "recover")) {
dl_arg_inc(dl);
return cmd_health_recover(dl);
+ } else if (dl_argv_match(dl, "diagnose")) {
+ dl_arg_inc(dl);
+ return cmd_health_diagnose(dl);
}
pr_err("Command \"%s\" not found\n", dl_argv(dl));
--
2.14.1
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox