* Re: [PATCH v4 06/11] net: dsa: microchip: ksz8795: change drivers prefix to be generic
From: Jakub Kicinski @ 2020-08-03 15:42 UTC (permalink / raw)
To: Michael Grzeschik; +Cc: andrew, netdev, f.fainelli, davem, kernel
In-Reply-To: <20200803054442.20089-7-m.grzeschik@pengutronix.de>
On Mon, 3 Aug 2020 07:44:37 +0200 Michael Grzeschik wrote:
> The driver can be used on other chips of this type. To reflect
> this we rename the drivers prefix from ksz8795 to ksz8.
>
> Signed-off-by: Michael Grzeschik <m.grzeschik@pengutronix.de>
allmodconfig:
../drivers/net/dsa/microchip/ksz8795.c:415:41: error: using member 'shifts' in incomplete struct ksz8
../drivers/net/dsa/microchip/ksz8795.c:802:46: warning: incorrect type in argument 3 (different type sizes)
../drivers/net/dsa/microchip/ksz8795.c:802:46: expected unsigned int [usertype] *vlan
../drivers/net/dsa/microchip/ksz8795.c:802:46: got unsigned short *
../drivers/net/dsa/microchip/ksz8795.c:843:46: warning: incorrect type in argument 3 (different type sizes)
../drivers/net/dsa/microchip/ksz8795.c:843:46: expected unsigned int [usertype] *vlan
../drivers/net/dsa/microchip/ksz8795.c:843:46: got unsigned short *
../drivers/net/dsa/microchip/ksz8795.c: In function ‘ksz8_r_vlan_entries’:
../drivers/net/dsa/microchip/ksz8795.c:415:34: error: invalid use of undefined type ‘struct ksz8’
415 | struct ksz_shifts *shifts = ksz8->shifts;
| ^~
../drivers/net/dsa/microchip/ksz8795.c:415:21: warning: unused variable ‘shifts’ [-Wunused-variable]
415 | struct ksz_shifts *shifts = ksz8->shifts;
| ^~~~~~
../drivers/net/dsa/microchip/ksz8795.c: In function ‘ksz8_port_vlan_add’:
../drivers/net/dsa/microchip/ksz8795.c:802:31: error: passing argument 3 of ‘ksz8_r_vlan_table’ from incompatible pointer type [-Werror=incompatible-pointer-types]
802 | ksz8_r_vlan_table(dev, vid, &data);
| ^~~~~
| |
| u16 * {aka short unsigned int *}
../drivers/net/dsa/microchip/ksz8795.c:427:69: note: expected ‘u32 *’ {aka ‘unsigned int *’} but argument is of type ‘u16 *’ {aka ‘short unsigned int *’}
427 | static void ksz8_r_vlan_table(struct ksz_device *dev, u16 vid, u32 *vlan)
| ~~~~~^~~~
../drivers/net/dsa/microchip/ksz8795.c: In function ‘ksz8_port_vlan_del’:
../drivers/net/dsa/microchip/ksz8795.c:843:31: error: passing argument 3 of ‘ksz8_r_vlan_table’ from incompatible pointer type [-Werror=incompatible-pointer-types]
843 | ksz8_r_vlan_table(dev, vid, &data);
| ^~~~~
| |
| u16 * {aka short unsigned int *}
../drivers/net/dsa/microchip/ksz8795.c:427:69: note: expected ‘u32 *’ {aka ‘unsigned int *’} but argument is of type ‘u16 *’ {aka ‘short unsigned int *’}
427 | static void ksz8_r_vlan_table(struct ksz_device *dev, u16 vid, u32 *vlan)
| ~~~~~^~~~
cc1: some warnings being treated as errors
make[5]: *** [../scripts/Makefile.build:281: drivers/net/dsa/microchip/ksz8795.o] Error 1
make[5]: *** Waiting for unfinished jobs....
make[4]: *** [../scripts/Makefile.build:497: drivers/net/dsa/microchip] Error 2
make[3]: *** [../scripts/Makefile.build:497: drivers/net/dsa] Error 2
make[3]: *** Waiting for unfinished jobs....
make[2]: *** [../scripts/Makefile.build:497: drivers/net] Error 2
make[2]: *** Waiting for unfinished jobs....
make[1]: *** [/netdev/net-next/Makefile:1771: drivers] Error 2
^ permalink raw reply
* Re: [PATCH net-next] net/mlx5: remove erroneous fallthrough
From: Gustavo A. R. Silva @ 2020-08-03 15:48 UTC (permalink / raw)
To: Dan Carpenter
Cc: Saeed Mahameed, Leon Romanovsky, David S. Miller, Jakub Kicinski,
netdev, linux-rdma, kernel-janitors
In-Reply-To: <20200803143448.GA346925@mwanda>
On Mon, Aug 03, 2020 at 05:34:48PM +0300, Dan Carpenter wrote:
> This isn't a fall through because it was after a return statement. The
> fall through annotation leads to a Smatch warning:
>
> drivers/net/ethernet/mellanox/mlx5/core/en_ethtool.c:246
> mlx5e_ethtool_get_sset_count() warn: ignoring unreachable code.
>
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: Gustavo A. R. Silva <gustavoars@kernel.org>
Thanks
--
Gustavo
> ---
> drivers/net/ethernet/mellanox/mlx5/core/en_ethtool.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_ethtool.c b/drivers/net/ethernet/mellanox/mlx5/core/en_ethtool.c
> index 08270987c506..48397a577fcd 100644
> --- a/drivers/net/ethernet/mellanox/mlx5/core/en_ethtool.c
> +++ b/drivers/net/ethernet/mellanox/mlx5/core/en_ethtool.c
> @@ -243,7 +243,6 @@ int mlx5e_ethtool_get_sset_count(struct mlx5e_priv *priv, int sset)
> return MLX5E_NUM_PFLAGS;
> case ETH_SS_TEST:
> return mlx5e_self_test_num(priv);
> - fallthrough;
> default:
> return -EOPNOTSUPP;
> }
> --
> 2.27.0
>
^ permalink raw reply
* Re: [PATCH] gve: Fix the size used in a 'dma_free_coherent()' call
From: Jakub Kicinski @ 2020-08-03 15:41 UTC (permalink / raw)
To: Christophe JAILLET
Cc: csully, sagis, jonolson, davem, lrizzo, netdev, linux-kernel,
kernel-janitors
In-Reply-To: <20200802141523.691565-1-christophe.jaillet@wanadoo.fr>
On Sun, 2 Aug 2020 16:15:23 +0200 Christophe JAILLET wrote:
> Update the size used in 'dma_free_coherent()' in order to match the one
> used in the corresponding 'dma_alloc_coherent()'.
>
> Fixes: 893ce44df5 ("gve: Add basic driver framework for Compute Engine Virtual NIC")
> Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Fixes tag: Fixes: 893ce44df5 ("gve: Add basic driver framework for Compute Engine Virtual NIC")
Has these problem(s):
- SHA1 should be at least 12 digits long
Can be fixed by setting core.abbrev to 12 (or more) or (for git v2.11
or later) just making sure it is not set (or set to "auto").
^ permalink raw reply
* Re: [net-next v2 2/5] devlink: introduce flash update overwrite mask
From: Jiri Pirko @ 2020-08-03 15:38 UTC (permalink / raw)
To: Jacob Keller; +Cc: netdev
In-Reply-To: <20200801002159.3300425-3-jacob.e.keller@intel.com>
Sat, Aug 01, 2020 at 02:21:56AM CEST, jacob.e.keller@intel.com wrote:
[...]
>+ nla_mask = info->attrs[DEVLINK_ATTR_FLASH_UPDATE_OVERWRITE_MASK];
>+ if (nla_mask) {
>+ if (!(supported_params & DEVLINK_SUPPORT_FLASH_UPDATE_OVERWRITE_MASK)) {
>+ NL_SET_ERR_MSG_ATTR(info->extack, nla_mask,
>+ "overwrite is not supported");
>+ return -EOPNOTSUPP;
>+ }
>+ params.overwrite_mask = nla_get_u32(nla_mask);
It's a bitfield, should be NL_ATTR_TYPE_BITFIELD32.
^ permalink raw reply
* Re: PMTUD broken inside network namespace with multipath routing
From: David Ahern @ 2020-08-03 15:38 UTC (permalink / raw)
To: mastertheknife; +Cc: netdev
In-Reply-To: <CANXY5y+gfZuGvv+pjzDOLS8Jp8ZUFpAmNw7k53O6cDuyB1PCnw@mail.gmail.com>
On 8/3/20 8:24 AM, mastertheknife wrote:
> Hi David,
>
> In this case, both paths are in the same layer2 network, there is no
> symmetric multi-path routing.
> If original message takes path 1, ICMP response will come from path 1
> If original message takes path 2, ICMP response will come from path 2
> Also, It works fine outside of LXC.
>
>
I'll take a look when I get some time; most likely end of the week.
^ permalink raw reply
* Re: [PATCH v3 iproute2-next] devlink: Add board.serial_number to info subcommand.
From: David Ahern @ 2020-08-03 15:37 UTC (permalink / raw)
To: Vasundhara Volam, netdev
Cc: dsahern, stephen, davem, jiri, kuba, michael.chan
In-Reply-To: <20200731104643.35726-1-vasundhara-v.volam@broadcom.com>
On 7/31/20 4:46 AM, Vasundhara Volam wrote:
> Add support for reading board serial_number to devlink info
> subcommand. Example:
>
> $ devlink dev info pci/0000:af:00.0 -jp
> {
> "info": {
> "pci/0000:af:00.0": {
> "driver": "bnxt_en",
> "serial_number": "00-10-18-FF-FE-AD-1A-00",
> "board.serial_number": "433551F+172300000",
> "versions": {
> "fixed": {
> "board.id": "7339763 Rev 0.",
> "asic.id": "16D7",
> "asic.rev": "1"
> },
> "running": {
> "fw": "216.1.216.0",
> "fw.psid": "0.0.0",
> "fw.mgmt": "216.1.192.0",
> "fw.mgmt.api": "1.10.1",
> "fw.ncsi": "0.0.0.0",
> "fw.roce": "216.1.16.0"
> }
> }
> }
> }
> }
>
> Signed-off-by: Vasundhara Volam <vasundhara-v.volam@broadcom.com>
> ---
> v2: Rebase. Resending the patch as I see this patch didn't make it to
> mailing list.
> v3: Rebase the patch and remove the line from commit message
> "This patch has dependency on updated include/uapi/linux/devlink.h file."
> as the headers are updated.
> ---
> devlink/devlink.c | 12 ++++++++++++
> 1 file changed, 12 insertions(+)
applied to iproute2-next
^ permalink raw reply
* Re: KASAN: use-after-free Read in tipc_bcast_get_mode
From: Eric Dumazet @ 2020-08-03 15:36 UTC (permalink / raw)
To: syzbot, davem, jmaloy, kuba, linux-kernel, netdev, syzkaller-bugs,
tipc-discussion, ying.xue
In-Reply-To: <000000000000f1e88005abfab762@google.com>
On 8/3/20 8:23 AM, syzbot wrote:
> Hello,
>
> syzbot found the following issue on:
>
> HEAD commit: bd0b33b2 Merge git://git.kernel.org/pub/scm/linux/kernel/g..
> git tree: net-next
> console output: https://syzkaller.appspot.com/x/log.txt?x=13f236a4900000
> kernel config: https://syzkaller.appspot.com/x/.config?x=91a13b78c7dc258d
> dashboard link: https://syzkaller.appspot.com/bug?extid=6ea1f7a8df64596ef4d7
> compiler: gcc (GCC) 10.1.0-syz 20200507
>
> Unfortunately, I don't have any reproducer for this issue yet.
>
> IMPORTANT: if you fix the issue, please add the following tag to the commit:
> Reported-by: syzbot+6ea1f7a8df64596ef4d7@syzkaller.appspotmail.com
>
> tipc: 32-bit node address hash set to fcff1eac
> ==================================================================
> BUG: KASAN: use-after-free in tipc_bcast_get_mode+0x3ab/0x400 net/tipc/bcast.c:759
> Read of size 1 at addr ffff88805e6b3571 by task kworker/0:6/3850
>
> CPU: 0 PID: 3850 Comm: kworker/0:6 Not tainted 5.8.0-rc7-syzkaller #0
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
> Workqueue: events tipc_net_finalize_work
> Call Trace:
> __dump_stack lib/dump_stack.c:77 [inline]
> dump_stack+0x18f/0x20d lib/dump_stack.c:118
> print_address_description.constprop.0.cold+0xae/0x436 mm/kasan/report.c:383
> __kasan_report mm/kasan/report.c:513 [inline]
> kasan_report.cold+0x1f/0x37 mm/kasan/report.c:530
> tipc_bcast_get_mode+0x3ab/0x400 net/tipc/bcast.c:759
> tipc_node_broadcast+0x9e/0xcc0 net/tipc/node.c:1744
> tipc_nametbl_publish+0x60b/0x970 net/tipc/name_table.c:752
> tipc_net_finalize net/tipc/net.c:141 [inline]
> tipc_net_finalize+0x1fa/0x310 net/tipc/net.c:131
> tipc_net_finalize_work+0x55/0x80 net/tipc/net.c:150
> process_one_work+0x94c/0x1670 kernel/workqueue.c:2269
> worker_thread+0x64c/0x1120 kernel/workqueue.c:2415
> kthread+0x3b5/0x4a0 kernel/kthread.c:291
> ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:293
>
> Allocated by task 8062:
> save_stack+0x1b/0x40 mm/kasan/common.c:48
> set_track mm/kasan/common.c:56 [inline]
> __kasan_kmalloc.constprop.0+0xc2/0xd0 mm/kasan/common.c:494
> kmem_cache_alloc_trace+0x14f/0x2d0 mm/slab.c:3551
> kmalloc include/linux/slab.h:555 [inline]
> kzalloc include/linux/slab.h:669 [inline]
> tipc_bcast_init+0x21e/0x7b0 net/tipc/bcast.c:689
> tipc_init_net+0x4f6/0x5c0 net/tipc/core.c:85
> ops_init+0xaf/0x470 net/core/net_namespace.c:151
> setup_net+0x2d8/0x850 net/core/net_namespace.c:341
> copy_net_ns+0x2cf/0x5e0 net/core/net_namespace.c:482
> create_new_namespaces+0x3f6/0xb10 kernel/nsproxy.c:110
> unshare_nsproxy_namespaces+0xbd/0x1f0 kernel/nsproxy.c:231
> ksys_unshare+0x36c/0x9a0 kernel/fork.c:2979
> __do_sys_unshare kernel/fork.c:3047 [inline]
> __se_sys_unshare kernel/fork.c:3045 [inline]
> __x64_sys_unshare+0x2d/0x40 kernel/fork.c:3045
> do_syscall_64+0x60/0xe0 arch/x86/entry/common.c:384
> entry_SYSCALL_64_after_hwframe+0x44/0xa9
>
> Freed by task 8843:
> save_stack+0x1b/0x40 mm/kasan/common.c:48
> set_track mm/kasan/common.c:56 [inline]
> kasan_set_free_info mm/kasan/common.c:316 [inline]
> __kasan_slab_free+0xf5/0x140 mm/kasan/common.c:455
> __cache_free mm/slab.c:3426 [inline]
> kfree+0x103/0x2c0 mm/slab.c:3757
> tipc_bcast_stop+0x1b0/0x2f0 net/tipc/bcast.c:721
> tipc_exit_net+0x24/0x270 net/tipc/core.c:112
> ops_exit_list+0xb0/0x160 net/core/net_namespace.c:186
> cleanup_net+0x4ea/0xa00 net/core/net_namespace.c:603
> process_one_work+0x94c/0x1670 kernel/workqueue.c:2269
> worker_thread+0x64c/0x1120 kernel/workqueue.c:2415
> kthread+0x3b5/0x4a0 kernel/kthread.c:291
> ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:293
>
> The buggy address belongs to the object at ffff88805e6b3500
> which belongs to the cache kmalloc-128 of size 128
> The buggy address is located 113 bytes inside of
> 128-byte region [ffff88805e6b3500, ffff88805e6b3580)
> The buggy address belongs to the page:
> page:ffffea000179acc0 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0
> flags: 0xfffe0000000200(slab)
> raw: 00fffe0000000200 ffffea0002375c48 ffff8880aa001550 ffff8880aa000700
> raw: 0000000000000000 ffff88805e6b3000 0000000100000010 0000000000000000
> page dumped because: kasan: bad access detected
>
> Memory state around the buggy address:
> ffff88805e6b3400: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> ffff88805e6b3480: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
>> ffff88805e6b3500: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> ^
> ffff88805e6b3580: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
> ffff88805e6b3600: 00 00 00 00 00 00 00 00 00 00 00 00 00 fc fc fc
> ==================================================================
>
>
> ---
> This report 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 issue. See:
> https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
>
Probably caused by commit adba75be0d23cca92a028749d92c60c8909bbdb3 tipc: fix lockdep warning when reinitilaizing sockets
^ permalink raw reply
* Re: [PATCH net] net/bpfilter: initialize pos in __bpfilter_process_sockopt
From: Rodrigo Madera @ 2020-08-03 15:36 UTC (permalink / raw)
To: Daniel Borkmann
Cc: Alexei Starovoitov, Christian Brauner, Christoph Hellwig, davem,
kuba, ast, netdev, bpf
In-Reply-To: <c166831a-d506-3a4e-80ed-f0474079770d@iogearbox.net>
On Mon, Aug 03, 2020 at 04:56:35PM +0200, Daniel Borkmann wrote:
> On 8/1/20 9:48 PM, Alexei Starovoitov wrote:
>
> Several folks reported that with v5.8-rc kernels their console is spammed with
> 'bpfilter: write fail' messages [0]. Given this affected the 5.8 release and
> the fix was a one-line change, it felt appropriate to route it there. Why was
> a4fa458950b4 not pushed into bpf tree given it was affected there too? Either
> way, we can undo the double pos assignment upon tree sync..
Just as a side note, please note it was more than spamming on the console.
It prevented the subsystem from working at all.
Best regards,
Madera
^ permalink raw reply
* [PATCH net 2/2] tipc: set ub->ifindex for local ipv6 address
From: Xin Long @ 2020-08-03 15:34 UTC (permalink / raw)
To: network dev
Cc: davem, Jon Maloy, Ying Xue, tipc-discussion, Alexey Kuznetsov,
Hideaki YOSHIFUJI
In-Reply-To: <cover.1596468610.git.lucien.xin@gmail.com>
Without ub->ifindex set for ipv6 address in tipc_udp_enable(),
ipv6_sock_mc_join() may make the wrong dev join the multicast
address in enable_mcast(). This causes that tipc links would
never be created.
So fix it by getting the right netdev and setting ub->ifindex,
as it does for ipv4 address.
Reported-by: Shuang Li <shuali@redhat.com>
Signed-off-by: Xin Long <lucien.xin@gmail.com>
---
net/tipc/udp_media.c | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/net/tipc/udp_media.c b/net/tipc/udp_media.c
index 28a283f..9dec596 100644
--- a/net/tipc/udp_media.c
+++ b/net/tipc/udp_media.c
@@ -738,6 +738,13 @@ static int tipc_udp_enable(struct net *net, struct tipc_bearer *b,
b->mtu = b->media->mtu;
#if IS_ENABLED(CONFIG_IPV6)
} else if (local.proto == htons(ETH_P_IPV6)) {
+ struct net_device *dev;
+
+ dev = ipv6_dev_find(net, &local.ipv6);
+ if (!dev) {
+ err = -ENODEV;
+ goto err;
+ }
udp_conf.family = AF_INET6;
udp_conf.use_udp6_tx_checksums = true;
udp_conf.use_udp6_rx_checksums = true;
@@ -745,6 +752,7 @@ static int tipc_udp_enable(struct net *net, struct tipc_bearer *b,
udp_conf.local_ip6 = in6addr_any;
else
udp_conf.local_ip6 = local.ipv6;
+ ub->ifindex = dev->ifindex;
b->mtu = 1280;
#endif
} else {
--
2.1.0
^ permalink raw reply related
* Re: [PATCH bpf-next v3 00/29] bpf: switch to memcg-based memory accounting
From: Roman Gushchin @ 2020-08-03 15:34 UTC (permalink / raw)
To: Daniel Borkmann
Cc: bpf, netdev, Alexei Starovoitov, kernel-team, linux-kernel
In-Reply-To: <6b1777ac-cae1-fa1f-db53-f6061d9ae675@iogearbox.net>
On Mon, Aug 03, 2020 at 02:05:29PM +0200, Daniel Borkmann wrote:
> On 7/30/20 11:22 PM, Roman Gushchin wrote:
> > Currently bpf is using the memlock rlimit for the memory accounting.
> > This approach has its downsides and over time has created a significant
> > amount of problems:
> >
> > 1) The limit is per-user, but because most bpf operations are performed
> > as root, the limit has a little value.
> >
> > 2) It's hard to come up with a specific maximum value. Especially because
> > the counter is shared with non-bpf users (e.g. memlock() users).
> > Any specific value is either too low and creates false failures
> > or too high and useless.
> >
> > 3) Charging is not connected to the actual memory allocation. Bpf code
> > should manually calculate the estimated cost and precharge the counter,
> > and then take care of uncharging, including all fail paths.
> > It adds to the code complexity and makes it easy to leak a charge.
> >
> > 4) There is no simple way of getting the current value of the counter.
> > We've used drgn for it, but it's far from being convenient.
> >
> > 5) Cryptic -EPERM is returned on exceeding the limit. Libbpf even had
> > a function to "explain" this case for users.
> >
> > In order to overcome these problems let's switch to the memcg-based
> > memory accounting of bpf objects. With the recent addition of the percpu
> > memory accounting, now it's possible to provide a comprehensive accounting
> > of memory used by bpf programs and maps.
> >
> > This approach has the following advantages:
> > 1) The limit is per-cgroup and hierarchical. It's way more flexible and allows
> > a better control over memory usage by different workloads.
> >
> > 2) The actual memory consumption is taken into account. It happens automatically
> > on the allocation time if __GFP_ACCOUNT flags is passed. Uncharging is also
> > performed automatically on releasing the memory. So the code on the bpf side
> > becomes simpler and safer.
> >
> > 3) There is a simple way to get the current value and statistics.
> >
> > The patchset consists of the following parts:
> > 1) memcg-based accounting for various bpf objects: progs and maps
> > 2) removal of the rlimit-based accounting
> > 3) removal of rlimit adjustments in userspace samples
Hi Daniel,
>
> The diff stat looks nice & agree that rlimit sucks, but I'm missing how this is set
> is supposed to work reliably, at least I currently fail to see it. Elaborating on this
> in more depth especially for the case of unprivileged users should be a /fundamental/
> part of the commit message.
>
> Lets take an example: unprivileged user adds a max sized hashtable to one of its
> programs, and configures the map that it will perform runtime allocation. The load
> succeeds as it doesn't surpass the limits set for the current memcg. Kernel then
> processes packets from softirq. Given the runtime allocations, we end up mischarging
> to whoever ended up triggering __do_softirq(). If, for example, ksoftirq thread, then
> it's probably reasonable to assume that this might not be accounted e.g. limits are
> not imposed on the root cgroup. If so we would probably need to drag the context of
> /where/ this must be charged to __memcg_kmem_charge_page() to do it reliably. Otherwise
> how do you protect unprivileged users to OOM the machine?
this is a valid concern, thank you for bringing it in. It can be resolved by
associating a map with a memory cgroup on creation, so that we can charge
this memory cgroup later, even from a soft-irq context. The question here is
whether we want to do it for all maps, or just for dynamic hashtables
(or any similar cases, if there are any)? I think the second option
is better. With the first option we have to annotate all memory allocations
in bpf maps code with memalloc_use_memcg()/memalloc_unuse_memcg(),
so it's easy to mess it up in the future.
What do you think?
>
> Similarly, what happens to unprivileged users if kmemcg was not configured into the
> kernel or has been disabled?
Well, I don't think we can address it. Memcg-based memory accounting requires
enabled memory cgroups, a properly configured cgroup tree and also the kernel
memory accounting turned on to function properly.
Because we at Facebook are using cgroup for the memory accounting and control
everywhere, I might be biased. If there are real !memcg systems which are
actively using non-privileged bpf, we should keep the old system in place
and make it optional, so everyone can choose between having both accounting
systems or just the new one. Or we can disable the rlimit-based accounting
for root. But eliminating it completely looks so much nicer to me.
Thanks!
^ permalink raw reply
* [PATCH net 1/2] ipv6: add ipv6_dev_find()
From: Xin Long @ 2020-08-03 15:34 UTC (permalink / raw)
To: network dev
Cc: davem, Jon Maloy, Ying Xue, tipc-discussion, Alexey Kuznetsov,
Hideaki YOSHIFUJI
In-Reply-To: <cover.1596468610.git.lucien.xin@gmail.com>
This is to add an ip_dev_find like function for ipv6, used to find
the dev by saddr.
It will be used by TIPC protocol. So also export it.
Signed-off-by: Xin Long <lucien.xin@gmail.com>
---
include/net/addrconf.h | 2 ++
net/ipv6/addrconf.c | 39 +++++++++++++++++++++++++++++++++++++++
2 files changed, 41 insertions(+)
diff --git a/include/net/addrconf.h b/include/net/addrconf.h
index 8418b7d..ba3f6c15 100644
--- a/include/net/addrconf.h
+++ b/include/net/addrconf.h
@@ -97,6 +97,8 @@ bool ipv6_chk_custom_prefix(const struct in6_addr *addr,
int ipv6_chk_prefix(const struct in6_addr *addr, struct net_device *dev);
+struct net_device *ipv6_dev_find(struct net *net, const struct in6_addr *addr);
+
struct inet6_ifaddr *ipv6_get_ifaddr(struct net *net,
const struct in6_addr *addr,
struct net_device *dev, int strict);
diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
index 840bfdb..857d6f9 100644
--- a/net/ipv6/addrconf.c
+++ b/net/ipv6/addrconf.c
@@ -1983,6 +1983,45 @@ int ipv6_chk_prefix(const struct in6_addr *addr, struct net_device *dev)
}
EXPORT_SYMBOL(ipv6_chk_prefix);
+/**
+ * ipv6_dev_find - find the first device with a given source address.
+ * @net: the net namespace
+ * @addr: the source address
+ *
+ * The caller should be protected by RCU, or RTNL.
+ */
+struct net_device *ipv6_dev_find(struct net *net, const struct in6_addr *addr)
+{
+ unsigned int hash = inet6_addr_hash(net, addr);
+ struct inet6_ifaddr *ifp, *result = NULL;
+ struct net_device *dev = NULL;
+
+ rcu_read_lock();
+ hlist_for_each_entry_rcu(ifp, &inet6_addr_lst[hash], addr_lst) {
+ if (net_eq(dev_net(ifp->idev->dev), net) &&
+ ipv6_addr_equal(&ifp->addr, addr)) {
+ result = ifp;
+ break;
+ }
+ }
+
+ if (!result) {
+ struct rt6_info *rt;
+
+ rt = rt6_lookup(net, addr, NULL, 0, NULL, 0);
+ if (rt) {
+ dev = rt->dst.dev;
+ ip6_rt_put(rt);
+ }
+ } else {
+ dev = result->idev->dev;
+ }
+ rcu_read_unlock();
+
+ return dev;
+}
+EXPORT_SYMBOL(ipv6_dev_find);
+
struct inet6_ifaddr *ipv6_get_ifaddr(struct net *net, const struct in6_addr *addr,
struct net_device *dev, int strict)
{
--
2.1.0
^ permalink raw reply related
* [PATCH net 0/2] net: fix a mcast issue for tipc udp media
From: Xin Long @ 2020-08-03 15:34 UTC (permalink / raw)
To: network dev
Cc: davem, Jon Maloy, Ying Xue, tipc-discussion, Alexey Kuznetsov,
Hideaki YOSHIFUJI
Patch 1 is to add a function to get the dev by source address,
whcih will be used by Patch 2.
Xin Long (2):
ipv6: add ipv6_dev_find()
tipc: set ub->ifindex for local ipv6 address
include/net/addrconf.h | 2 ++
net/ipv6/addrconf.c | 39 +++++++++++++++++++++++++++++++++++++++
net/tipc/udp_media.c | 8 ++++++++
3 files changed, 49 insertions(+)
--
2.1.0
^ permalink raw reply
* Re: [net-next v2 0/5] devlink flash update overwrite mask
From: Jiri Pirko @ 2020-08-03 15:28 UTC (permalink / raw)
To: Jacob Keller
Cc: netdev, Jiri Pirko, Jakub Kicinski, Jonathan Corbet, Michael Chan,
Bin Luo, Saeed Mahameed, Leon Romanovsky, Ido Schimmel,
Danielle Ratson
In-Reply-To: <20200801002159.3300425-1-jacob.e.keller@intel.com>
Sat, Aug 01, 2020 at 02:21:54AM CEST, jacob.e.keller@intel.com wrote:
>This series introduces support for a new attribute to the flash update
>command: DEVLINK_ATTR_FLASH_UPDATE_OVERWRITE_MASK. This attribute is a u32
>value that represents a bitmask of which subsections of flash to
>request/allow overwriting when performing a flash update.
>
>The intent is to support the ability to control overwriting options of the
>ice hardware flash update. Specifically, the ice flash components combine
>settings and identifiers within the firmware flash section. This series
>introduces the two subsections, "identifiers" and "settings". With the new
>attribute, users can request to overwrite these subsections when performing
>a flash update. By existing convention, it is assumed that flash program
>binaries are always updated (and thus overwritten), and no mask bit is
>provided to control this.
>
>First, the .flash_update command is modified to take a parameter structure.
>A new supported_flash_update_params field is also provided to allow drivers
>to opt-in to the parameters they support rather than opting out. This is
>similar to the recently added supported_coalesc_params field in ethtool.
>
>Following this, the new overwrite mask parameter is added, along with the
>associated supported bit. The netdevsim driver is updated to support this
>parameter, along with a few self tests to help verify the interface is
>working as expected.
>
>Finally, the ice driver is modified to support the parameter, converting it
>into the firmware preservation level request.
>
>Patches to enable support for specifying the overwrite sections are also
>provided for iproute2-next. This is done primarily in order to enable the
>tests for netdevsim. As discussed previously on the list, the primary
>motivations for the overwrite mode are two-fold.
>
>First, supporting update with a customized image that has pre-configured
>settings and identifiers, used with overwrite of both settings and
>identifiers. This enables an initial update to overwrite default values and
>customize the adapter with a new serial ID and fresh settings. Second, it
>may sometimes be useful to allow overwriting of settings when updating in
>order to guarantee that the settings in the flash section are "known good".
I'm missing examples in the cover letter. It is much easier to
understand the nature of the patchset with examples. Could you please
repost with them?
Thanks!
>
>Changes since v1
>* Added supported_flash_update_params field, removing some boilerplate in
> each driver. This also makes it easier to add new parameters in the future
> without fear of accidentally breaking an existing driver, due to opt-in
> behavior instead of forcing drivers to opt-out.
>* Split the ice changes to a separate patch.
>
>Cc: Jiri Pirko <jiri@mellanox.com>
>Cc: Jakub Kicinski <kuba@kernel.org>
>Cc: Jonathan Corbet <corbet@lwn.net>
>Cc: Michael Chan <michael.chan@broadcom.com>
>Cc: Bin Luo <luobin9@huawei.com>
>Cc: Saeed Mahameed <saeedm@mellanox.com>
>Cc: Leon Romanovsky <leon@kernel.org>
>Cc: Ido Schimmel <idosch@mellanox.com>
>Cc: Danielle Ratson <danieller@mellanox.com>
>
>Jacob Keller (3):
> devlink: convert flash_update to use params structure
> devlink: introduce flash update overwrite mask
> ice: add support for flash update overwrite mask
>
> .../networking/devlink/devlink-flash.rst | 29 ++++++++++++++
> Documentation/networking/devlink/ice.rst | 31 +++++++++++++++
> .../net/ethernet/broadcom/bnxt/bnxt_devlink.c | 19 ++++-----
> .../net/ethernet/huawei/hinic/hinic_devlink.c | 8 +---
> drivers/net/ethernet/intel/ice/ice_devlink.c | 33 +++++++++++-----
> .../net/ethernet/intel/ice/ice_fw_update.c | 16 +++++++-
> .../net/ethernet/intel/ice/ice_fw_update.h | 2 +-
> .../net/ethernet/mellanox/mlx5/core/devlink.c | 8 +---
> drivers/net/ethernet/mellanox/mlxsw/core.c | 6 +--
> drivers/net/ethernet/mellanox/mlxsw/core.h | 2 +-
> .../net/ethernet/mellanox/mlxsw/spectrum.c | 7 +---
> .../net/ethernet/netronome/nfp/nfp_devlink.c | 9 ++---
> drivers/net/netdevsim/dev.c | 21 +++++++---
> drivers/net/netdevsim/netdevsim.h | 1 +
> include/net/devlink.h | 35 ++++++++++++++++-
> include/uapi/linux/devlink.h | 24 ++++++++++++
> net/core/devlink.c | 39 +++++++++++++++----
> .../drivers/net/netdevsim/devlink.sh | 21 ++++++++++
> 18 files changed, 244 insertions(+), 67 deletions(-)
>
>Jacob Keller (2):
> Update devlink header for overwrite mask attribute
> devlink: support setting the overwrite mask
>
> devlink/devlink.c | 37 ++++++++++++++++++++++++++++++++++--
> include/uapi/linux/devlink.h | 24 +++++++++++++++++++++++
> 2 files changed, 59 insertions(+), 2 deletions(-)
>
>base-commit: bd69058f50d5ffa659423bcfa6fe6280ce9c760a
>--
>2.28.0.163.g6104cc2f0b60
>
^ permalink raw reply
* KASAN: use-after-free Read in tipc_bcast_get_mode
From: syzbot @ 2020-08-03 15:23 UTC (permalink / raw)
To: davem, jmaloy, kuba, linux-kernel, netdev, syzkaller-bugs,
tipc-discussion, ying.xue
Hello,
syzbot found the following issue on:
HEAD commit: bd0b33b2 Merge git://git.kernel.org/pub/scm/linux/kernel/g..
git tree: net-next
console output: https://syzkaller.appspot.com/x/log.txt?x=13f236a4900000
kernel config: https://syzkaller.appspot.com/x/.config?x=91a13b78c7dc258d
dashboard link: https://syzkaller.appspot.com/bug?extid=6ea1f7a8df64596ef4d7
compiler: gcc (GCC) 10.1.0-syz 20200507
Unfortunately, I don't have any reproducer for this issue yet.
IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+6ea1f7a8df64596ef4d7@syzkaller.appspotmail.com
tipc: 32-bit node address hash set to fcff1eac
==================================================================
BUG: KASAN: use-after-free in tipc_bcast_get_mode+0x3ab/0x400 net/tipc/bcast.c:759
Read of size 1 at addr ffff88805e6b3571 by task kworker/0:6/3850
CPU: 0 PID: 3850 Comm: kworker/0:6 Not tainted 5.8.0-rc7-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
Workqueue: events tipc_net_finalize_work
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x18f/0x20d lib/dump_stack.c:118
print_address_description.constprop.0.cold+0xae/0x436 mm/kasan/report.c:383
__kasan_report mm/kasan/report.c:513 [inline]
kasan_report.cold+0x1f/0x37 mm/kasan/report.c:530
tipc_bcast_get_mode+0x3ab/0x400 net/tipc/bcast.c:759
tipc_node_broadcast+0x9e/0xcc0 net/tipc/node.c:1744
tipc_nametbl_publish+0x60b/0x970 net/tipc/name_table.c:752
tipc_net_finalize net/tipc/net.c:141 [inline]
tipc_net_finalize+0x1fa/0x310 net/tipc/net.c:131
tipc_net_finalize_work+0x55/0x80 net/tipc/net.c:150
process_one_work+0x94c/0x1670 kernel/workqueue.c:2269
worker_thread+0x64c/0x1120 kernel/workqueue.c:2415
kthread+0x3b5/0x4a0 kernel/kthread.c:291
ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:293
Allocated by task 8062:
save_stack+0x1b/0x40 mm/kasan/common.c:48
set_track mm/kasan/common.c:56 [inline]
__kasan_kmalloc.constprop.0+0xc2/0xd0 mm/kasan/common.c:494
kmem_cache_alloc_trace+0x14f/0x2d0 mm/slab.c:3551
kmalloc include/linux/slab.h:555 [inline]
kzalloc include/linux/slab.h:669 [inline]
tipc_bcast_init+0x21e/0x7b0 net/tipc/bcast.c:689
tipc_init_net+0x4f6/0x5c0 net/tipc/core.c:85
ops_init+0xaf/0x470 net/core/net_namespace.c:151
setup_net+0x2d8/0x850 net/core/net_namespace.c:341
copy_net_ns+0x2cf/0x5e0 net/core/net_namespace.c:482
create_new_namespaces+0x3f6/0xb10 kernel/nsproxy.c:110
unshare_nsproxy_namespaces+0xbd/0x1f0 kernel/nsproxy.c:231
ksys_unshare+0x36c/0x9a0 kernel/fork.c:2979
__do_sys_unshare kernel/fork.c:3047 [inline]
__se_sys_unshare kernel/fork.c:3045 [inline]
__x64_sys_unshare+0x2d/0x40 kernel/fork.c:3045
do_syscall_64+0x60/0xe0 arch/x86/entry/common.c:384
entry_SYSCALL_64_after_hwframe+0x44/0xa9
Freed by task 8843:
save_stack+0x1b/0x40 mm/kasan/common.c:48
set_track mm/kasan/common.c:56 [inline]
kasan_set_free_info mm/kasan/common.c:316 [inline]
__kasan_slab_free+0xf5/0x140 mm/kasan/common.c:455
__cache_free mm/slab.c:3426 [inline]
kfree+0x103/0x2c0 mm/slab.c:3757
tipc_bcast_stop+0x1b0/0x2f0 net/tipc/bcast.c:721
tipc_exit_net+0x24/0x270 net/tipc/core.c:112
ops_exit_list+0xb0/0x160 net/core/net_namespace.c:186
cleanup_net+0x4ea/0xa00 net/core/net_namespace.c:603
process_one_work+0x94c/0x1670 kernel/workqueue.c:2269
worker_thread+0x64c/0x1120 kernel/workqueue.c:2415
kthread+0x3b5/0x4a0 kernel/kthread.c:291
ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:293
The buggy address belongs to the object at ffff88805e6b3500
which belongs to the cache kmalloc-128 of size 128
The buggy address is located 113 bytes inside of
128-byte region [ffff88805e6b3500, ffff88805e6b3580)
The buggy address belongs to the page:
page:ffffea000179acc0 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0
flags: 0xfffe0000000200(slab)
raw: 00fffe0000000200 ffffea0002375c48 ffff8880aa001550 ffff8880aa000700
raw: 0000000000000000 ffff88805e6b3000 0000000100000010 0000000000000000
page dumped because: kasan: bad access detected
Memory state around the buggy address:
ffff88805e6b3400: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ffff88805e6b3480: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
>ffff88805e6b3500: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
^
ffff88805e6b3580: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
ffff88805e6b3600: 00 00 00 00 00 00 00 00 00 00 00 00 00 fc fc fc
==================================================================
---
This report 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 issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
^ permalink raw reply
* KASAN: slab-out-of-bounds Read in hci_le_meta_evt
From: syzbot @ 2020-08-03 15:05 UTC (permalink / raw)
To: davem, johan.hedberg, kuba, linux-bluetooth, linux-kernel, linux,
marcel, netdev, syzkaller-bugs
Hello,
syzbot found the following issue on:
HEAD commit: 5a30a789 Merge tag 'x86-urgent-2020-08-02' of git://git.ke..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=11cd21cc900000
kernel config: https://syzkaller.appspot.com/x/.config?x=c0cfcf935bcc94d2
dashboard link: https://syzkaller.appspot.com/bug?extid=24ebd650e20bd263ca01
compiler: gcc (GCC) 10.1.0-syz 20200507
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=10fd4504900000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=14aa36a4900000
IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+24ebd650e20bd263ca01@syzkaller.appspotmail.com
Bluetooth: hci0: unknown advertising packet type: 0x2b
==================================================================
BUG: KASAN: slab-out-of-bounds in hci_le_direct_adv_report_evt net/bluetooth/hci_event.c:5850 [inline]
BUG: KASAN: slab-out-of-bounds in hci_le_meta_evt+0x380c/0x3eb0 net/bluetooth/hci_event.c:5914
Read of size 1 at addr ffff8880a727de0c by task kworker/u5:0/1535
CPU: 1 PID: 1535 Comm: kworker/u5:0 Not tainted 5.8.0-rc7-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
Workqueue: hci0 hci_rx_work
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x18f/0x20d lib/dump_stack.c:118
print_address_description.constprop.0.cold+0xae/0x436 mm/kasan/report.c:383
__kasan_report mm/kasan/report.c:513 [inline]
kasan_report.cold+0x1f/0x37 mm/kasan/report.c:530
hci_le_direct_adv_report_evt net/bluetooth/hci_event.c:5850 [inline]
hci_le_meta_evt+0x380c/0x3eb0 net/bluetooth/hci_event.c:5914
hci_event_packet+0x245a/0x86f5 net/bluetooth/hci_event.c:6167
hci_rx_work+0x22e/0xb10 net/bluetooth/hci_core.c:4705
process_one_work+0x94c/0x1670 kernel/workqueue.c:2269
worker_thread+0x64c/0x1120 kernel/workqueue.c:2415
kthread+0x3b5/0x4a0 kernel/kthread.c:291
ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:293
Allocated by task 6834:
save_stack+0x1b/0x40 mm/kasan/common.c:48
set_track mm/kasan/common.c:56 [inline]
__kasan_kmalloc.constprop.0+0xc2/0xd0 mm/kasan/common.c:494
__kmalloc_reserve net/core/skbuff.c:142 [inline]
__alloc_skb+0xae/0x550 net/core/skbuff.c:210
alloc_skb include/linux/skbuff.h:1083 [inline]
bt_skb_alloc include/net/bluetooth/bluetooth.h:377 [inline]
vhci_get_user drivers/bluetooth/hci_vhci.c:165 [inline]
vhci_write+0xbd/0x450 drivers/bluetooth/hci_vhci.c:285
call_write_iter include/linux/fs.h:1908 [inline]
new_sync_write+0x422/0x650 fs/read_write.c:503
vfs_write+0x59d/0x6b0 fs/read_write.c:578
ksys_write+0x12d/0x250 fs/read_write.c:631
do_syscall_64+0x60/0xe0 arch/x86/entry/common.c:384
entry_SYSCALL_64_after_hwframe+0x44/0xa9
Freed by task 6627:
save_stack+0x1b/0x40 mm/kasan/common.c:48
set_track mm/kasan/common.c:56 [inline]
kasan_set_free_info mm/kasan/common.c:316 [inline]
__kasan_slab_free+0xf5/0x140 mm/kasan/common.c:455
__cache_free mm/slab.c:3426 [inline]
kfree+0x103/0x2c0 mm/slab.c:3757
tomoyo_find_next_domain+0x81d/0x1f77 security/tomoyo/domain.c:885
tomoyo_bprm_check_security security/tomoyo/tomoyo.c:101 [inline]
tomoyo_bprm_check_security+0x121/0x1a0 security/tomoyo/tomoyo.c:91
security_bprm_check+0x45/0xa0 security/security.c:840
search_binary_handler fs/exec.c:1737 [inline]
exec_binprm fs/exec.c:1790 [inline]
__do_execve_file+0x1577/0x2ee0 fs/exec.c:1926
do_execveat_common fs/exec.c:1980 [inline]
do_execve+0x35/0x50 fs/exec.c:1997
__do_sys_execve fs/exec.c:2073 [inline]
__se_sys_execve fs/exec.c:2068 [inline]
__x64_sys_execve+0x7c/0xa0 fs/exec.c:2068
do_syscall_64+0x60/0xe0 arch/x86/entry/common.c:384
entry_SYSCALL_64_after_hwframe+0x44/0xa9
The buggy address belongs to the object at ffff8880a727dc00
which belongs to the cache kmalloc-512 of size 512
The buggy address is located 12 bytes to the right of
512-byte region [ffff8880a727dc00, ffff8880a727de00)
The buggy address belongs to the page:
page:ffffea00029c9f40 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0
flags: 0xfffe0000000200(slab)
raw: 00fffe0000000200 ffffea00029e3848 ffffea0002731b88 ffff8880aa000a80
raw: 0000000000000000 ffff8880a727d000 0000000100000004 0000000000000000
page dumped because: kasan: bad access detected
Memory state around the buggy address:
ffff8880a727dd00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ffff8880a727dd80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>ffff8880a727de00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
^
ffff8880a727de80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
ffff8880a727df00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
==================================================================
---
This report 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 issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
syzbot can test patches for this issue, for details see:
https://goo.gl/tpsmEJ#testing-patches
^ permalink raw reply
* Re: [PATCH 2/2] net: phy: Associate device node with fixed PHY
From: Andrew Lunn @ 2020-08-03 15:00 UTC (permalink / raw)
To: Madalin Bucur (OSS)
Cc: Russell King - ARM Linux admin, Vikas Singh, f.fainelli@gmail.com,
hkallweit1@gmail.com, netdev@vger.kernel.org,
Calvin Johnson (OSS), kuldip dwivedi, Vikas Singh
In-Reply-To: <AM6PR04MB3976D3E9BA05AB5D4EBB6AA6EC4D0@AM6PR04MB3976.eurprd04.prod.outlook.com>
On Mon, Aug 03, 2020 at 02:33:56PM +0000, Madalin Bucur (OSS) wrote:
> > -----Original Message-----
> > From: Andrew Lunn <andrew@lunn.ch>
> > Sent: 03 August 2020 15:58
> > To: Madalin Bucur (OSS) <madalin.bucur@oss.nxp.com>
> > Cc: Russell King - ARM Linux admin <linux@armlinux.org.uk>; Vikas Singh
> > <vikas.singh@puresoftware.com>; f.fainelli@gmail.com; hkallweit1@gmail.com;
> > netdev@vger.kernel.org; Calvin Johnson (OSS) <calvin.johnson@oss.nxp.com>;
> > kuldip dwivedi <kuldip.dwivedi@puresoftware.com>; Vikas Singh
> > <vikas.singh@nxp.com>
> > Subject: Re: [PATCH 2/2] net: phy: Associate device node with fixed PHY
> >
> > > I see you agree that there were and there will be many changes for a
> > while,
> > > It's not a complaint, I know hot it works, it's just a decision based on
> > > required effort vs features offered vs user requirements. Lately it's
> > been
> > > time consuming to try to fix things in this area.
> >
> > So the conclusion to all this that you are unwilling to use the
> > correct API for this, which would be phylink, and the SFP code. So:
> >
> > NACK
> >
> > Andrew
>
> You've rejected a generic change - ACPI support for fixed link.
> The discussion above is just an example of how it could have been (mis-)used.
> Are you rejecting the general case or just the particular one?
So far, nobody has corrected me that the MAC is not connected to an
SFP socket. So i see two sorts of abuse going on here:
1) Using a fixed link with a hack to allow 10G. phylink allows 10G
fixed links without an hacks.
2) Using a fixed link when not even appropriate since phylink should
be used to control the SFP.
Now, you can do whatever you want in your Vendor Crap tree. But there
is no reason mainline should help you support your vendor crap tree.
To make progress here, you need to add an in tree user of this generic
change. And since that means an ACPI user, you need to follow what has
been set out in the other thread. You need an ACPI maintainer to ACK
it. And to get an ACPI maintainer to ACK it, you need a specification,
and proof it is being used. And to get my ACK, it needs to be valid
use of it as well.
Andrew
^ permalink raw reply
* Re: [PATCH iproute2-next] ip-xfrm: add support for oseq-may-wrap extra flag
From: David Ahern @ 2020-08-03 14:58 UTC (permalink / raw)
To: Petr Vaněk, netdev; +Cc: David Ahern
In-Reply-To: <20200731071259.GA3192@atlantis>
On 7/31/20 1:12 AM, Petr Vaněk wrote:
> This flag allows to create SA where sequence number can cycle in
> outbound packets if set.
>
> Signed-off-by: Petr Vaněk <pv@excello.cz>
> ---
> include/uapi/linux/xfrm.h | 1 +
> ip/ipxfrm.c | 3 +++
> ip/xfrm_state.c | 4 +++-
> man/man8/ip-xfrm.8 | 2 +-
> 4 files changed, 8 insertions(+), 2 deletions(-)
>
applied to iproute2-next
^ permalink raw reply
* Re: [PATCH net] net/bpfilter: initialize pos in __bpfilter_process_sockopt
From: Daniel Borkmann @ 2020-08-03 14:56 UTC (permalink / raw)
To: Alexei Starovoitov
Cc: Christian Brauner, Christoph Hellwig, davem, kuba, ast, netdev,
bpf, Rodrigo Madera
In-Reply-To: <20200801194846.dxmvg5fmg67nuhwy@ast-mbp.dhcp.thefacebook.com>
On 8/1/20 9:48 PM, Alexei Starovoitov wrote:
> On Fri, Jul 31, 2020 at 02:07:42AM +0200, Daniel Borkmann wrote:
>> On 7/30/20 6:13 PM, Christian Brauner wrote:
>>> On Thu, Jul 30, 2020 at 06:09:00PM +0200, Christoph Hellwig wrote:
>>>> __bpfilter_process_sockopt never initialized the pos variable passed to
>>>> the pipe write. This has been mostly harmless in the past as pipes
>>>> ignore the offset, but the switch to kernel_write no verified the
>>>
>>> s/no/now/
>>>
>>>> position, which can lead to a failure depending on the exact stack
>>>> initialization patter. Initialize the variable to zero to make
>>>
>>> s/patter/pattern/
>>>
>>>> rw_verify_area happy.
>>>>
>>>> Fixes: 6955a76fbcd5 ("bpfilter: switch to kernel_write")
>>>> Reported-by: Christian Brauner <christian.brauner@ubuntu.com>
>>>> Reported-by: Rodrigo Madera <rodrigo.madera@gmail.com>
>>>> Signed-off-by: Christoph Hellwig <hch@lst.de>
>>>> Tested-by: Rodrigo Madera <rodrigo.madera@gmail.com>
>>>> ---
>>>
>>> Thanks for tracking this down, Christoph! This fixes the logging issue
>>> for me.
>>> Tested-by: Christian Brauner <christian.brauner@ubuntu.com>
>>> Reviewed-by: Christian Brauner <christian.brauner@ubuntu.com>
>>
>> Applied to bpf & fixed up the typos in the commit msg, thanks everyone!
>
> Daniel,
> why is it necessary in bpf tree?
>
> I fixed it already in bpf-next in commit a4fa458950b4 ("bpfilter: Initialize pos variable")
> two weeks ago...
Several folks reported that with v5.8-rc kernels their console is spammed with
'bpfilter: write fail' messages [0]. Given this affected the 5.8 release and
the fix was a one-line change, it felt appropriate to route it there. Why was
a4fa458950b4 not pushed into bpf tree given it was affected there too? Either
way, we can undo the double pos assignment upon tree sync..
[0] https://lore.kernel.org/lkml/20200727104636.nuz3u4xb7ba7ue5a@wittgenstein/
^ permalink raw reply
* Re: [PATCH] kprobes: fix NULL pointer dereference at kprobe_ftrace_handler
From: Masami Hiramatsu @ 2020-08-03 14:50 UTC (permalink / raw)
To: Muchun Song, Steven Rostedt
Cc: naveen.n.rao, anil.s.keshavamurthy, davem, ast, daniel, kafai,
songliubraving, yhs, andriin, john.fastabend, kpsingh, LKML,
netdev, bpf, Chengming Zhou
In-Reply-To: <CAMZfGtUDmQgDySu7OSBNYv5y2_QJfzDcVeYG2eY6-1xYq+t1Uw@mail.gmail.com>
On Mon, 3 Aug 2020 13:46:25 +0800
Muchun Song <songmuchun@bytedance.com> wrote:
> Ping guys. Any comments or suggestions?
>
> On Tue, Jul 28, 2020 at 2:45 PM Muchun Song <songmuchun@bytedance.com> wrote:
> >
> > We found a case of kernel panic on our server. The stack trace is as
> > follows(omit some irrelevant information):
> >
> > BUG: kernel NULL pointer dereference, address: 0000000000000080
> > RIP: 0010:kprobe_ftrace_handler+0x5e/0xe0
> > RSP: 0018:ffffb512c6550998 EFLAGS: 00010282
> > RAX: 0000000000000000 RBX: ffff8e9d16eea018 RCX: 0000000000000000
> > RDX: ffffffffbe1179c0 RSI: ffffffffc0535564 RDI: ffffffffc0534ec0
> > RBP: ffffffffc0534ec1 R08: ffff8e9d1bbb0f00 R09: 0000000000000004
> > R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000
> > R13: ffff8e9d1f797060 R14: 000000000000bacc R15: ffff8e9ce13eca00
> > CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> > CR2: 0000000000000080 CR3: 00000008453d0005 CR4: 00000000003606e0
> > DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> > DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
> > Call Trace:
> > <IRQ>
> > ftrace_ops_assist_func+0x56/0xe0
> > ftrace_call+0x5/0x34
> > tcpa_statistic_send+0x5/0x130 [ttcp_engine]
> >
> > The tcpa_statistic_send is the function being kprobed. After analysis,
> > the root cause is that the fourth parameter regs of kprobe_ftrace_handler
> > is NULL. Why regs is NULL? We use the crash tool to analyze the kdump.
> >
> > crash> dis tcpa_statistic_send -r
> > <tcpa_statistic_send>: callq 0xffffffffbd8018c0 <ftrace_caller>
> >
> > The tcpa_statistic_send calls ftrace_caller instead of ftrace_regs_caller.
> > So it is reasonable that the fourth parameter regs of kprobe_ftrace_handler
> > is NULL. In theory, we should call the ftrace_regs_caller instead of the
> > ftrace_caller. After in-depth analysis, we found a reproducible path.
> >
> > Writing a simple kernel module which starts a periodic timer. The
> > timer's handler is named 'kprobe_test_timer_handler'. The module
> > name is kprobe_test.ko.
> >
> > 1) insmod kprobe_test.ko
> > 2) bpftrace -e 'kretprobe:kprobe_test_timer_handler {}'
> > 3) echo 0 > /proc/sys/kernel/ftrace_enabled
> > 4) rmmod kprobe_test
> > 5) stop step 2) kprobe
> > 6) insmod kprobe_test.ko
> > 7) bpftrace -e 'kretprobe:kprobe_test_timer_handler {}'
> >
> > We mark the kprobe as GONE but not disarm the kprobe in the step 4).
> > The step 5) also do not disarm the kprobe when unregister kprobe. So
> > we do not remove the ip from the filter. In this case, when the module
> > loads again in the step 6), we will replace the code to ftrace_caller
> > via the ftrace_module_enable(). When we register kprobe again, we will
> > not replace ftrace_caller to ftrace_regs_caller because the ftrace is
> > disabled in the step 3). So the step 7) will trigger kernel panic. Fix
> > this problem by disarming the kprobe when the module is going away.
> >
Nice catch!
Acked-by: Masami Hiramatsu <mhiramat@kernel.org>
Fixes: ae6aa16fdc16 ("kprobes: introduce ftrace based optimization")
Cc: stable@vger.kernel.org
Thank you!
> > Signed-off-by: Muchun Song <songmuchun@bytedance.com>
> > Co-developed-by: Chengming Zhou <zhouchengming@bytedance.com>
> > Signed-off-by: Chengming Zhou <zhouchengming@bytedance.com>
> > ---
> > kernel/kprobes.c | 7 +++++++
> > 1 file changed, 7 insertions(+)
> >
> > diff --git a/kernel/kprobes.c b/kernel/kprobes.c
> > index 146c648eb943..503add629599 100644
> > --- a/kernel/kprobes.c
> > +++ b/kernel/kprobes.c
> > @@ -2148,6 +2148,13 @@ static void kill_kprobe(struct kprobe *p)
> > * the original probed function (which will be freed soon) any more.
> > */
> > arch_remove_kprobe(p);
> > +
> > + /*
> > + * The module is going away. We should disarm the kprobe which
> > + * is using ftrace.
> > + */
> > + if (kprobe_ftrace(p))
> > + disarm_kprobe_ftrace(p);
> > }
> >
> > /* Disable one kprobe */
> > --
> > 2.11.0
> >
>
>
> --
> Yours,
> Muchun
--
Masami Hiramatsu <mhiramat@kernel.org>
^ permalink raw reply
* RE: [PATCH 2/2] net: phy: Associate device node with fixed PHY
From: Madalin Bucur (OSS) @ 2020-08-03 14:47 UTC (permalink / raw)
To: Russell King - ARM Linux admin, Madalin Bucur (OSS)
Cc: Andrew Lunn, Vikas Singh, f.fainelli@gmail.com,
hkallweit1@gmail.com, netdev@vger.kernel.org,
Calvin Johnson (OSS), kuldip dwivedi, Vikas Singh
In-Reply-To: <20200803141017.GM1551@shell.armlinux.org.uk>
> -----Original Message-----
> From: Russell King - ARM Linux admin <linux@armlinux.org.uk>
> Sent: 03 August 2020 17:10
> To: Madalin Bucur (OSS) <madalin.bucur@oss.nxp.com>
> Cc: Andrew Lunn <andrew@lunn.ch>; Vikas Singh
> <vikas.singh@puresoftware.com>; f.fainelli@gmail.com; hkallweit1@gmail.com;
> netdev@vger.kernel.org; Calvin Johnson (OSS) <calvin.johnson@oss.nxp.com>;
> kuldip dwivedi <kuldip.dwivedi@puresoftware.com>; Vikas Singh
> <vikas.singh@nxp.com>
> Subject: Re: [PATCH 2/2] net: phy: Associate device node with fixed PHY
>
> On Mon, Aug 03, 2020 at 11:45:55AM +0000, Madalin Bucur (OSS) wrote:
> > > -----Original Message-----
> > > From: Russell King - ARM Linux admin <linux@armlinux.org.uk>
> > > Sent: 03 August 2020 12:07
> > > To: Madalin Bucur (OSS) <madalin.bucur@oss.nxp.com>
> > > Cc: Andrew Lunn <andrew@lunn.ch>; Vikas Singh
> > > <vikas.singh@puresoftware.com>; f.fainelli@gmail.com;
> hkallweit1@gmail.com;
> > > netdev@vger.kernel.org; Calvin Johnson (OSS)
> <calvin.johnson@oss.nxp.com>;
> > > kuldip dwivedi <kuldip.dwivedi@puresoftware.com>; Vikas Singh
> > > <vikas.singh@nxp.com>
> > > Subject: Re: [PATCH 2/2] net: phy: Associate device node with fixed
> PHY
> > >
> > > On Mon, Aug 03, 2020 at 08:33:19AM +0000, Madalin Bucur (OSS) wrote:
> > > > > -----Original Message-----
> > > > > From: netdev-owner@vger.kernel.org <netdev-owner@vger.kernel.org>
> On
> > > > > Behalf Of Andrew Lunn
> > > > > Sent: 01 August 2020 18:11
> > > > > To: Russell King - ARM Linux admin <linux@armlinux.org.uk>
> > > > > Cc: Vikas Singh <vikas.singh@puresoftware.com>;
> f.fainelli@gmail.com;
> > > > > hkallweit1@gmail.com; netdev@vger.kernel.org; Calvin Johnson (OSS)
> > > > > <calvin.johnson@oss.nxp.com>; kuldip dwivedi
> > > > > <kuldip.dwivedi@puresoftware.com>; Madalin Bucur (OSS)
> > > > > <madalin.bucur@oss.nxp.com>; Vikas Singh <vikas.singh@nxp.com>
> > > > > Subject: Re: [PATCH 2/2] net: phy: Associate device node with
> fixed
> > > PHY
> > > > >
> > > > > On Sat, Aug 01, 2020 at 10:41:32AM +0100, Russell King - ARM Linux
> > > admin
> > > > > wrote:
> > > > > > On Sat, Aug 01, 2020 at 09:52:52AM +0530, Vikas Singh wrote:
> > > > > > > Hi Andrew,
> > > > > > >
> > > > > > > Please refer to the "fman" node under
> > > > > > > linux/arch/arm64/boot/dts/freescale/fsl-ls1046a-rdb.dts
> > > > > > > I have two 10G ethernet interfaces out of which one is of
> fixed-
> > > link.
> > > > > >
> > > > > > Please do not top post.
> > > > > >
> > > > > > How does XGMII (which is a 10G only interface) work at 1G speed?
> Is
> > > > > > what is in DT itself a hack because fixed-phy doesn't support
> 10G
> > > > > > modes?
> > > > >
> > > > > My gut feeling is there is some hack going on here, which is why
> i'm
> > > > > being persistent at trying to understand what is actually going on
> > > > > here.
> > > >
> > > > Hi Andrew,
> > > >
> > > > That platform used 1G fixed link there since there was no support
> for
> > > > 10G fixed link at the time. PHYlib could have tolerated 10G speed
> there
> > > > With a one-liner.
> > >
> > > That statement is false. It is not a "one liner". fixed-phy exposes
> > > the settings to userspace as a Clause 22 PHY register set, and the
> > > Clause 22 register set does not support 10G. So, a "one liner" would
> > > just be yet another hack. Adding Clause 45 PHY emulation support
> > > would be a huge task.
> > >
> > > > I understand that PHYLink is working to describe this
> > > > Better, but it was not there at that time. Adding the dependency on
> > > > PHYLink was not desirable as most of the users for the DPAA 1
> platforms
> > > > were targeting kernels before the PHYLink introduction (and last
> I've
> > > > looked, it's still under development, with unstable APIs so we'll
> > > > take a look at this later, when it settles).
> > >
> > > I think you need to read Documentation/process/stable-api-nonsense.rst
> > > particularly the section "Stable Kernel Source Interfaces".
> > >
> > > phylink is going to be under development for quite some time to come
> > > as requirements evolve. For example, when support for QSFP interfaces
> > > is eventually worked out, I suspect there will need to be some further
> > > changes to the driver interface. This is completely normal.
> > >
> > > Now, as to the stability of the phylink API to drivers, it has in fact
> > > been very stable - it has only changed over the course of this year to
> > > support split PCS, a necessary step for DPAA2 and a few others. It
> has
> > > been around in mainline for two years, and has been around much longer
> > > than that, and during that time it has been in mainline, the MAC
> facing
> > > interface has not changed until recently.
> > >
> > > So, I find your claim to be quite unreasonable.
> >
> > I see you agree that there were and there will be many changes for a
> while,
> > It's not a complaint, I know hot it works, it's just a decision based on
> > required effort vs features offered vs user requirements. Lately it's
> been
> > time consuming to try to fix things in this area.
>
> No, it hasn't been time consuming. The only API changes as far as
> drivers are concerned have been:
>
> 1. the change to the mac_link_up() prototype to move the setup of the
> final link parameters out of mac_config() - and almost all of the
> updates to users were done by me.
>
> 2. the addition of split PCS support, introducing new interfaces, has
> had minimal impact on those drivers that updated in step (1).
>
> There have been no other changes as far as users are concerned.
>
> Some of the difficulty with (1) has been that users of phylink appeared
> initially with no proper review, and consequently they got quite a lot
> wrong. The most common error has been using state->speed, state->duplex
> in mac_config() methods irrespective of the AN mode, which has _always_
> since before phylink was merged into mainline, been totally unreliable.
>
> That leads me on to the other visible "changes" for users are concerned,
> which may be interpreted as interface changes, but are not; they have
> all been clarifications to the documentation, to strengthen things such
> as "do not use state->speed and state->duplex in mac_config() for
> various specific AN modes". Nothing has actually changed with any of
> those clarifications.
>
> For example, if in in-band mode, and mac_config() uses state->speed
> and state->duplex, then it doesn't matter which version of phylink
> you're using, if someone issues ethtool -s ethN ..., then state->speed
> and state->duplex will be their respective UNKNOWN values, and if you're
> using these in that situation, you will mis-program the MAC.
>
> Again, that is not something that has changed. Ever. But the
> documentation has because people just don't seem to get it, and I seemed
> to be constantly repeating myself in review after review on the same
> points.
>
> So, your assertion that the phylink API is not stable is false. It
> has been remarkably stable over the two years that it has been around.
> It is only natural that as the technology that a piece of code supports
> evolves, so the code evolves with it. That is exactly what has happened
> this year with the two changes I mention above.
>
> Now, if you've found it time consuming to "fix things" (unspecified what
> "things" are) then I assert that what has needed to be fixed are things
> that NXP have got wrong. Such as the rtnl cockups. Such as abusing
> state->speed and state->duplex. None of that is because the interface
> is unstable - they are down to buggy implementation on NXPs part.
>
> Essentially, what I'm saying is that your attempt to paint phylink as
> being painful on the basis of interface changes is totally and utterly
> wrong and is just an excuse to justify abusing the fixed-link code and
> specifying things that are clearly incorrect via DT.
Thank you for the distilled phylink history, it may be easier to comprehend
with these details. I was not referring to phylink, but PHY related issues
on the DPAA 1 platforms.
> I will accept that the interface that had existed up until the
> mac_link_up() change was confusing - it clearly was due to the number
> of people getting mac_config() implementations wrong. That is actually
> another of the reasons why the mac_link_up() change was made. These
> problems are _only_ found by people making use of it. If people don't
> use stuff, then problems aren't found, and nothing changes.
>
> So, I think you can expect a NAK for the patch at the top of this
> thread on the basis that it is perpetuating an abuse not only the
> legacy fixed-link code, but also DT. However, I will leave Andrew to
> make that call.
>
> --
> RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
> FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!
^ permalink raw reply
* Re: [PATCH bpf-next 0/3] Add generic and raw BTF parsing APIs to libbpf
From: Daniel Borkmann @ 2020-08-03 14:45 UTC (permalink / raw)
To: Andrii Nakryiko, bpf, netdev, ast; +Cc: andrii.nakryiko, kernel-team
In-Reply-To: <20200802013219.864880-1-andriin@fb.com>
On 8/2/20 3:32 AM, Andrii Nakryiko wrote:
> It's pretty common for applications to want to parse raw (binary) BTF data
> from file, as opposed to parsing it from ELF sections. It's also pretty common
> for tools to not care whether given file is ELF or raw BTF format. This patch
> series exposes internal raw BTF parsing API and adds generic variant of BTF
> parsing, which will efficiently determine the format of a given fail and will
> parse BTF appropriately.
>
> Patches #2 and #3 removes re-implementations of such APIs from bpftool and
> resolve_btfids tools.
>
> Andrii Nakryiko (3):
> libbpf: add btf__parse_raw() and generic btf__parse() APIs
> tools/bpftool: use libbpf's btf__parse() API for parsing BTF from file
> tools/resolve_btfids: use libbpf's btf__parse() API
>
> tools/bpf/bpftool/btf.c | 54 +------------
> tools/bpf/resolve_btfids/.gitignore | 4 +
> tools/bpf/resolve_btfids/main.c | 58 +-------------
> tools/lib/bpf/btf.c | 114 +++++++++++++++++++---------
> tools/lib/bpf/btf.h | 5 +-
> tools/lib/bpf/libbpf.map | 2 +
> 6 files changed, 89 insertions(+), 148 deletions(-)
> create mode 100644 tools/bpf/resolve_btfids/.gitignore
>
Applied, thanks!
^ permalink raw reply
* Re: [PATCH iproute2-next v2 0/2] Expose port attributes
From: David Ahern @ 2020-08-03 14:38 UTC (permalink / raw)
To: Danielle Ratson, netdev; +Cc: stephen, mlxsw
In-Reply-To: <20200730143318.1203-1-danieller@mellanox.com>
On 7/30/20 8:33 AM, Danielle Ratson wrote:
> Add two new devlink port attributes:
> - Lanes: indicates the number of port lanes.
> - Splittable: indicates the port split ability.
>
> Patch 1: Update kernel headers
> Patch 2: Expose number of lanes
>
> v2: *Update 'devlink_policy' with the new attributes
>
> Danielle Ratson (2):
> devlink: Expose number of port lanes
> devlink: Expose port split ability
>
> devlink/devlink.c | 9 +++++++++
> 1 file changed, 9 insertions(+)
>
applied to iproute2-next. Thanks,
^ permalink raw reply
* Re: [PATCH v2 net-next 04/11] sfc_ef100: TX path for EF100 NICs
From: Edward Cree @ 2020-08-03 14:36 UTC (permalink / raw)
To: Jakub Kicinski; +Cc: linux-net-drivers, davem, netdev
In-Reply-To: <20200731123936.38680a53@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com>
On 31/07/2020 20:39, Jakub Kicinski wrote:
> On Fri, 31 Jul 2020 13:59:04 +0100 Edward Cree wrote:
>> +static inline efx_oword_t *ef100_tx_desc(struct efx_tx_queue *tx_queue,
>> + unsigned int index)
> Does this static inline make any difference?
>
> You know the general policy...
Damn, I didn't spot that one.
Why doesn't checkpatch catch those? Is it just not smart enough
to remember whether it's in a .c file or not? Or do I need to
pass it some --strict --fascist --annoy-me-harder flags?
Will remove 'inline' in v3, thanks.
-ed
^ permalink raw reply
* [PATCH net-next] net/mlx5: remove erroneous fallthrough
From: Dan Carpenter @ 2020-08-03 14:34 UTC (permalink / raw)
To: Saeed Mahameed, Gustavo A. R. Silva
Cc: Leon Romanovsky, David S. Miller, Jakub Kicinski, netdev,
linux-rdma, kernel-janitors
This isn't a fall through because it was after a return statement. The
fall through annotation leads to a Smatch warning:
drivers/net/ethernet/mellanox/mlx5/core/en_ethtool.c:246
mlx5e_ethtool_get_sset_count() warn: ignoring unreachable code.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
---
drivers/net/ethernet/mellanox/mlx5/core/en_ethtool.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_ethtool.c b/drivers/net/ethernet/mellanox/mlx5/core/en_ethtool.c
index 08270987c506..48397a577fcd 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/en_ethtool.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en_ethtool.c
@@ -243,7 +243,6 @@ int mlx5e_ethtool_get_sset_count(struct mlx5e_priv *priv, int sset)
return MLX5E_NUM_PFLAGS;
case ETH_SS_TEST:
return mlx5e_self_test_num(priv);
- fallthrough;
default:
return -EOPNOTSUPP;
}
--
2.27.0
^ permalink raw reply related
* RE: [PATCH 2/2] net: phy: Associate device node with fixed PHY
From: Madalin Bucur (OSS) @ 2020-08-03 14:33 UTC (permalink / raw)
To: Andrew Lunn, Madalin Bucur (OSS)
Cc: Russell King - ARM Linux admin, Vikas Singh, f.fainelli@gmail.com,
hkallweit1@gmail.com, netdev@vger.kernel.org,
Calvin Johnson (OSS), kuldip dwivedi, Vikas Singh
In-Reply-To: <20200803125742.GK1862409@lunn.ch>
> -----Original Message-----
> From: Andrew Lunn <andrew@lunn.ch>
> Sent: 03 August 2020 15:58
> To: Madalin Bucur (OSS) <madalin.bucur@oss.nxp.com>
> Cc: Russell King - ARM Linux admin <linux@armlinux.org.uk>; Vikas Singh
> <vikas.singh@puresoftware.com>; f.fainelli@gmail.com; hkallweit1@gmail.com;
> netdev@vger.kernel.org; Calvin Johnson (OSS) <calvin.johnson@oss.nxp.com>;
> kuldip dwivedi <kuldip.dwivedi@puresoftware.com>; Vikas Singh
> <vikas.singh@nxp.com>
> Subject: Re: [PATCH 2/2] net: phy: Associate device node with fixed PHY
>
> > I see you agree that there were and there will be many changes for a
> while,
> > It's not a complaint, I know hot it works, it's just a decision based on
> > required effort vs features offered vs user requirements. Lately it's
> been
> > time consuming to try to fix things in this area.
>
> So the conclusion to all this that you are unwilling to use the
> correct API for this, which would be phylink, and the SFP code. So:
>
> NACK
>
> Andrew
You've rejected a generic change - ACPI support for fixed link.
The discussion above is just an example of how it could have been (mis-)used.
Are you rejecting the general case or just the particular one?
Madalin
^ 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