Taehee Yoo [Sat, 1 Aug 2020 07:07:50 +0000 (07:07 +0000)]
vxlan: fix memleak of fdb
When vxlan interface is deleted, all fdbs are deleted by vxlan_flush().
vxlan_flush() flushes fdbs but it doesn't delete fdb, which contains
all-zeros-mac because it is deleted by vxlan_uninit().
But vxlan_uninit() deletes only the fdb, which contains both all-zeros-mac
and default vni.
So, the fdb, which contains both all-zeros-mac and non-default vni
will not be deleted.
Test commands:
ip link add vxlan0 type vxlan dstport 4789 external
ip link set vxlan0 up
bridge fdb add to 00:00:00:00:00:00 dst 172.0.0.1 dev vxlan0 via lo \
src_vni 10000 self permanent
ip link del vxlan0
kmemleak reports as follows:
unreferenced object 0xffff9486b25ced88 (size 96):
comm "bridge", pid 2151, jiffies
4294701712 (age 35506.901s)
hex dump (first 32 bytes):
02 00 00 00 ac 00 00 01 40 00 09 b1 86 94 ff ff ........@.......
46 02 00 00 00 00 00 00 a7 03 00 00 12 b5 6a 6b F.............jk
backtrace:
[<
00000000c10cf651>] vxlan_fdb_append.part.51+0x3c/0xf0 [vxlan]
[<
000000006b31a8d9>] vxlan_fdb_create+0x184/0x1a0 [vxlan]
[<
0000000049399045>] vxlan_fdb_update+0x12f/0x220 [vxlan]
[<
0000000090b1ef00>] vxlan_fdb_add+0x12a/0x1b0 [vxlan]
[<
0000000056633c2c>] rtnl_fdb_add+0x187/0x270
[<
00000000dd5dfb6b>] rtnetlink_rcv_msg+0x264/0x490
[<
00000000fc44dd54>] netlink_rcv_skb+0x4a/0x110
[<
00000000dff433e7>] netlink_unicast+0x18e/0x250
[<
00000000b87fb421>] netlink_sendmsg+0x2e9/0x400
[<
000000002ed55153>] ____sys_sendmsg+0x237/0x260
[<
00000000faa51c66>] ___sys_sendmsg+0x88/0xd0
[<
000000006c3982f1>] __sys_sendmsg+0x4e/0x80
[<
00000000a8f875d2>] do_syscall_64+0x56/0xe0
[<
000000003610eefa>] entry_SYSCALL_64_after_hwframe+0x44/0xa9
unreferenced object 0xffff9486b1c40080 (size 128):
comm "bridge", pid 2157, jiffies
4294701754 (age 35506.866s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 f8 dc 42 b2 86 94 ff ff ..........B.....
6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
backtrace:
[<
00000000a2981b60>] vxlan_fdb_create+0x67/0x1a0 [vxlan]
[<
0000000049399045>] vxlan_fdb_update+0x12f/0x220 [vxlan]
[<
0000000090b1ef00>] vxlan_fdb_add+0x12a/0x1b0 [vxlan]
[<
0000000056633c2c>] rtnl_fdb_add+0x187/0x270
[<
00000000dd5dfb6b>] rtnetlink_rcv_msg+0x264/0x490
[<
00000000fc44dd54>] netlink_rcv_skb+0x4a/0x110
[<
00000000dff433e7>] netlink_unicast+0x18e/0x250
[<
00000000b87fb421>] netlink_sendmsg+0x2e9/0x400
[<
000000002ed55153>] ____sys_sendmsg+0x237/0x260
[<
00000000faa51c66>] ___sys_sendmsg+0x88/0xd0
[<
000000006c3982f1>] __sys_sendmsg+0x4e/0x80
[<
00000000a8f875d2>] do_syscall_64+0x56/0xe0
[<
000000003610eefa>] entry_SYSCALL_64_after_hwframe+0x44/0xa9
Fixes:
3ad7a4b141eb ("vxlan: support fdb and learning in COLLECT_METADATA mode")
Signed-off-by: Taehee Yoo <ap420073@gmail.com>
Acked-by: Roopa Prabhu <roopa@cumulusnetworks.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
David S. Miller [Sat, 1 Aug 2020 00:19:47 +0000 (17:19 -0700)]
Merge git://git./pub/scm/linux/kernel/git/bpf/bpf
Daniel Borkmann says:
====================
pull-request: bpf 2020-07-31
The following pull-request contains BPF updates for your *net* tree.
We've added 5 non-merge commits during the last 21 day(s) which contain
a total of 5 files changed, 126 insertions(+), 18 deletions(-).
The main changes are:
1) Fix a map element leak in HASH_OF_MAPS map type, from Andrii Nakryiko.
2) Fix a NULL pointer dereference in __btf_resolve_helper_id() when no
btf_vmlinux is available, from Peilin Ye.
3) Init pos variable in __bpfilter_process_sockopt(), from Christoph Hellwig.
4) Fix a cgroup sockopt verifier test by specifying expected attach type,
from Jean-Philippe Brucker.
Note that when net gets merged into net-next later on, there is a small
merge conflict in kernel/bpf/btf.c between commit
5b801dfb7feb ("bpf: Fix
NULL pointer dereference in __btf_resolve_helper_id()") from the bpf tree
and commit
138b9a0511c7 ("bpf: Remove btf_id helpers resolving") from the
net-next tree.
Resolve as follows: remove the old hunk with the __btf_resolve_helper_id()
function. Change the btf_resolve_helper_id() so it actually tests for a
NULL btf_vmlinux and bails out:
int btf_resolve_helper_id(struct bpf_verifier_log *log,
const struct bpf_func_proto *fn, int arg)
{
int id;
if (fn->arg_type[arg] != ARG_PTR_TO_BTF_ID || !btf_vmlinux)
return -EINVAL;
id = fn->btf_id[arg];
if (!id || id > btf_vmlinux->nr_types)
return -EINVAL;
return id;
}
Let me know if you run into any others issues (CC'ing Jiri Olsa so he's in
the loop with regards to merge conflict resolution).
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
David S. Miller [Sat, 1 Aug 2020 00:10:53 +0000 (17:10 -0700)]
Merge branch 'master' of git://git./linux/kernel/git/klassert/ipsec
Steffen Klassert says:
====================
pull request (net): ipsec 2020-07-31
1) Fix policy matching with mark and mask on userspace interfaces.
From Xin Long.
2) Several fixes for the new ESP in TCP encapsulation.
From Sabrina Dubroca.
3) Fix crash when the hold queue is used. The assumption that
xdst->path and dst->child are not a NULL pointer only if dst->xfrm
is not a NULL pointer is true with the exception of using the
hold queue. Fix this by checking for hold queue usage before
dereferencing xdst->path or dst->child.
4) Validate pfkey_dump parameter before sending them.
From Mark Salyzyn.
5) Fix the location of the transport header with ESP in UDPv6
encapsulation. From Sabrina Dubroca.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
David S. Miller [Sat, 1 Aug 2020 00:05:54 +0000 (17:05 -0700)]
Merge tag 'mlx5-fixes-2020-07-30' of git://git./linux/kernel/git/saeed/linux
Saeed Mahameed says:
====================
Mellanox, mlx5 fixes 2020-07-30
This small patchset introduces some fixes to mlx5 driver.
Please pull and let me know if there is any problem.
For -stable v4.18:
('net/mlx5e: fix bpf_prog reference count leaks in mlx5e_alloc_rq')
For -stable v5.7:
('net/mlx5e: E-Switch, Add misc bit when misc fields changed for mirroring')
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
Peilin Ye [Thu, 30 Jul 2020 19:20:26 +0000 (15:20 -0400)]
rds: Prevent kernel-infoleak in rds_notify_queue_get()
rds_notify_queue_get() is potentially copying uninitialized kernel stack
memory to userspace since the compiler may leave a 4-byte hole at the end
of `cmsg`.
In 2016 we tried to fix this issue by doing `= { 0 };` on `cmsg`, which
unfortunately does not always initialize that 4-byte hole. Fix it by using
memset() instead.
Cc: stable@vger.kernel.org
Fixes:
f037590fff30 ("rds: fix a leak of kernel memory")
Fixes:
bdbe6fbc6a2f ("RDS: recv.c")
Suggested-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Peilin Ye <yepeilin.cs@gmail.com>
Acked-by: Santosh Shilimkar <santosh.shilimkar@oracle.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
David S. Miller [Fri, 31 Jul 2020 23:51:58 +0000 (16:51 -0700)]
Merge branch '1GbE' of git://git./linux/kernel/git/jkirsher/net-queue
Tony Nguyen says:
====================
Intel Wired LAN Driver Updates 2020-07-30
This series contains updates to the e1000e and igb drivers.
Aaron Ma allows PHY initialization to continue if ULP disable failed for
e1000e.
Francesco Ruggeri fixes race conditions in igb reset that could cause panics.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
liujian [Thu, 30 Jul 2020 08:14:28 +0000 (16:14 +0800)]
net/sched: The error lable position is corrected in ct_init_module
Exchange the positions of the err_tbl_init and err_register labels in
ct_init_module function.
Fixes:
c34b961a2492 ("net/sched: act_ct: Create nf flow table per zone")
Signed-off-by: liujian <liujian56@huawei.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Xin Xiong [Thu, 30 Jul 2020 10:29:41 +0000 (18:29 +0800)]
net/mlx5e: fix bpf_prog reference count leaks in mlx5e_alloc_rq
The function invokes bpf_prog_inc(), which increases the reference
count of a bpf_prog object "rq->xdp_prog" if the object isn't NULL.
The refcount leak issues take place in two error handling paths. When
either mlx5_wq_ll_create() or mlx5_wq_cyc_create() fails, the function
simply returns the error code and forgets to drop the reference count
increased earlier, causing a reference count leak of "rq->xdp_prog".
Fix this issue by jumping to the error handling path err_rq_wq_destroy
while either function fails.
Fixes:
422d4c401edd ("net/mlx5e: RX, Split WQ objects for different RQ types")
Signed-off-by: Xin Xiong <xiongx18@fudan.edu.cn>
Signed-off-by: Xiyu Yang <xiyuyang19@fudan.edu.cn>
Signed-off-by: Xin Tan <tanxin.ctf@gmail.com>
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
Jianbo Liu [Fri, 3 Jul 2020 02:34:23 +0000 (02:34 +0000)]
net/mlx5e: E-Switch, Specify flow_source for rule with no in_port
The flow_source must be specified, even for rule without matching
source vport, because some actions are only allowed in uplink.
Otherwise, rule can't be offloaded and firmware syndrome happens.
Fixes:
6fb0701a9cfa ("net/mlx5: E-Switch, Add support for offloading rules with no in_port")
Signed-off-by: Jianbo Liu <jianbol@mellanox.com>
Reviewed-by: Chris Mi <chrism@mellanox.com>
Reviewed-by: Roi Dayan <roid@mellanox.com>
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
Jianbo Liu [Thu, 2 Jul 2020 01:06:37 +0000 (01:06 +0000)]
net/mlx5e: E-Switch, Add misc bit when misc fields changed for mirroring
The modified flow_context fields in FTE must be indicated in
modify_enable bitmask. Previously, the misc bit in modify_enable is
always set as source vport must be set for each rule. So, when parsing
vxlan/gre/geneve/qinq rules, this bit is not set because those are all
from the same misc fileds that source vport fields are located at, and
we don't need to set the indicator twice.
After adding per vport tables for mirroring, misc bit is not set, then
firmware syndrome happens. To fix it, set the bit wherever misc fileds
are changed. This also makes it unnecessary to check misc fields and set
the misc bit accordingly in metadata matching, so here remove it.
Besides, flow_source must be specified for uplink because firmware
will check it and some actions are only allowed for packets received
from uplink.
Fixes:
96e326878fa5 ("net/mlx5e: Eswitch, Use per vport tables for mirroring")
Signed-off-by: Jianbo Liu <jianbol@mellanox.com>
Reviewed-by: Chris Mi <chrism@mellanox.com>
Reviewed-by: Roi Dayan <roid@mellanox.com>
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
Jianbo Liu [Mon, 20 Jul 2020 01:36:45 +0000 (01:36 +0000)]
net/mlx5e: CT: Support restore ipv6 tunnel
Currently the driver restores only IPv4 tunnel headers.
Add support for restoring IPv6 tunnel header.
Fixes:
b8ce90370977 ("net/mlx5e: Restore tunnel metadata on miss")
Signed-off-by: Jianbo Liu <jianbol@mellanox.com>
Reviewed-by: Roi Dayan <roid@mellanox.com>
Reviewed-by: Oz Shlomo <ozsh@mellanox.com>
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
David S. Miller [Fri, 31 Jul 2020 00:47:34 +0000 (17:47 -0700)]
Merge tag 'mac80211-for-davem-2020-07-30' of git://git./linux/kernel/git/jberg/mac80211
Johannes Berg says:
====================
A couple of more changes:
* remove a warning that can trigger in certain races
* check a function pointer before using it
* check before adding 6 GHz to avoid a warning in mesh
* fix two memory leaks in mesh
* fix a TX status bug leading to a memory leak
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
Wang Hai [Thu, 30 Jul 2020 07:30:00 +0000 (15:30 +0800)]
net: gemini: Fix missing clk_disable_unprepare() in error path of gemini_ethernet_port_probe()
Fix the missing clk_disable_unprepare() before return
from gemini_ethernet_port_probe() in the error handling case.
Fixes:
4d5ae32f5e1e ("net: ethernet: Add a driver for Gemini gigabit ethernet")
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: Wang Hai <wanghai38@huawei.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Shannon Nelson [Wed, 29 Jul 2020 17:52:17 +0000 (10:52 -0700)]
ionic: unlock queue mutex in error path
On an error return, jump to the unlock at the end to be sure
to unlock the queue_lock mutex.
Fixes:
0925e9db4dc8 ("ionic: use mutex to protect queue operations")
Reported-by: kernel test robot <lkp@intel.com>
Reported-by: Julia Lawall <julia.lawall@lip6.fr>
Signed-off-by: Shannon Nelson <snelson@pensando.io>
Signed-off-by: David S. Miller <davem@davemloft.net>
Xin Xiong [Wed, 29 Jul 2020 13:06:59 +0000 (21:06 +0800)]
atm: fix atm_dev refcnt leaks in atmtcp_remove_persistent
atmtcp_remove_persistent() invokes atm_dev_lookup(), which returns a
reference of atm_dev with increased refcount or NULL if fails.
The refcount leaks issues occur in two error handling paths. If
dev_data->persist is zero or PRIV(dev)->vcc isn't NULL, the function
returns 0 without decreasing the refcount kept by a local variable,
resulting in refcount leaks.
Fix the issue by adding atm_dev_put() before returning 0 both when
dev_data->persist is zero or PRIV(dev)->vcc isn't NULL.
Signed-off-by: Xin Xiong <xiongx18@fudan.edu.cn>
Signed-off-by: Xiyu Yang <xiyuyang19@fudan.edu.cn>
Signed-off-by: Xin Tan <tanxin.ctf@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Landen Chao [Wed, 29 Jul 2020 08:15:17 +0000 (10:15 +0200)]
net: ethernet: mtk_eth_soc: fix MTU warnings
in recent kernel versions there are warnings about incorrect MTU size
like these:
eth0: mtu greater than device maximum
mtk_soc_eth
1b100000.ethernet eth0: error -22 setting MTU to include DSA overhead
Fixes:
bfcb813203e6 ("net: dsa: configure the MTU for switch ports")
Fixes:
72579e14a1d3 ("net: dsa: don't fail to probe if we couldn't set the MTU")
Fixes:
7a4c53bee332 ("net: report invalid mtu value via netlink extack")
Signed-off-by: Landen Chao <landen.chao@mediatek.com>
Signed-off-by: Frank Wunderlich <frank-w@public-files.de>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
Lu Wei [Wed, 29 Jul 2020 03:50:05 +0000 (11:50 +0800)]
net: nixge: fix potential memory leak in nixge_probe()
If some processes in nixge_probe() fail, free_netdev(dev)
needs to be called to aviod a memory leak.
Fixes:
87ab207981ec ("net: nixge: Separate ctrl and dma resources")
Fixes:
abcd3d6fc640 ("net: nixge: Fix error path for obtaining mac address")
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: Lu Wei <luwei32@huawei.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Jakub Kicinski [Tue, 28 Jul 2020 23:15:07 +0000 (16:15 -0700)]
devlink: ignore -EOPNOTSUPP errors on dumpit
Number of .dumpit functions try to ignore -EOPNOTSUPP errors.
Recent change missed that, and started reporting all errors
but -EMSGSIZE back from dumps. This leads to situation like
this:
$ devlink dev info
devlink answers: Operation not supported
Dump should not report an error just because the last device
to be queried could not provide an answer.
To fix this and avoid similar confusion make sure we clear
err properly, and not leave it set to an error if we don't
terminate the iteration.
Fixes:
c62c2cfb801b ("net: devlink: don't ignore errors during dumpit")
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Reviewed-by: Jiri Pirko <jiri@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
David Howells [Tue, 28 Jul 2020 23:03:56 +0000 (00:03 +0100)]
rxrpc: Fix race between recvmsg and sendmsg on immediate call failure
There's a race between rxrpc_sendmsg setting up a call, but then failing to
send anything on it due to an error, and recvmsg() seeing the call
completion occur and trying to return the state to the user.
An assertion fails in rxrpc_recvmsg() because the call has already been
released from the socket and is about to be released again as recvmsg deals
with it. (The recvmsg_q queue on the socket holds a ref, so there's no
problem with use-after-free.)
We also have to be careful not to end up reporting an error twice, in such
a way that both returns indicate to userspace that the user ID supplied
with the call is no longer in use - which could cause the client to
malfunction if it recycles the user ID fast enough.
Fix this by the following means:
(1) When sendmsg() creates a call after the point that the call has been
successfully added to the socket, don't return any errors through
sendmsg(), but rather complete the call and let recvmsg() retrieve
them. Make sendmsg() return 0 at this point. Further calls to
sendmsg() for that call will fail with ESHUTDOWN.
Note that at this point, we haven't send any packets yet, so the
server doesn't yet know about the call.
(2) If sendmsg() returns an error when it was expected to create a new
call, it means that the user ID wasn't used.
(3) Mark the call disconnected before marking it completed to prevent an
oops in rxrpc_release_call().
(4) recvmsg() will then retrieve the error and set MSG_EOR to indicate
that the user ID is no longer known by the kernel.
An oops like the following is produced:
kernel BUG at net/rxrpc/recvmsg.c:605!
...
RIP: 0010:rxrpc_recvmsg+0x256/0x5ae
...
Call Trace:
? __init_waitqueue_head+0x2f/0x2f
____sys_recvmsg+0x8a/0x148
? import_iovec+0x69/0x9c
? copy_msghdr_from_user+0x5c/0x86
___sys_recvmsg+0x72/0xaa
? __fget_files+0x22/0x57
? __fget_light+0x46/0x51
? fdget+0x9/0x1b
do_recvmmsg+0x15e/0x232
? _raw_spin_unlock+0xa/0xb
? vtime_delta+0xf/0x25
__x64_sys_recvmmsg+0x2c/0x2f
do_syscall_64+0x4c/0x78
entry_SYSCALL_64_after_hwframe+0x44/0xa9
Fixes:
357f5ef64628 ("rxrpc: Call rxrpc_release_call() on error in rxrpc_new_client_call()")
Reported-by: syzbot+b54969381df354936d96@syzkaller.appspotmail.com
Signed-off-by: David Howells <dhowells@redhat.com>
Reviewed-by: Marc Dionne <marc.dionne@auristor.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Joyce Ooi [Mon, 27 Jul 2020 09:46:41 +0000 (17:46 +0800)]
MAINTAINERS: Replace Thor Thayer as Altera Triple Speed Ethernet maintainer
This patch is to replace Thor Thayer as Altera Triple Speed Ethernet
maintainer as he is moving to a different role.
Signed-off-by: Joyce Ooi <joyce.ooi@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Hangbin Liu [Mon, 27 Jul 2020 11:04:55 +0000 (19:04 +0800)]
selftests/bpf: fix netdevsim trap_flow_action_cookie read
When read netdevsim trap_flow_action_cookie, we need to init it first,
or we will get "Invalid argument" error.
Fixes:
d3cbb907ae57 ("netdevsim: add ACL trap reporting cookie as a metadata")
Signed-off-by: Hangbin Liu <liuhangbin@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Cong Wang [Sat, 25 Jul 2020 22:40:53 +0000 (15:40 -0700)]
ipv6: fix memory leaks on IPV6_ADDRFORM path
IPV6_ADDRFORM causes resource leaks when converting an IPv6 socket
to IPv4, particularly struct ipv6_ac_socklist. Similar to
struct ipv6_mc_socklist, we should just close it on this path.
This bug can be easily reproduced with the following C program:
#include <stdio.h>
#include <string.h>
#include <sys/types.h>
#include <sys/socket.h>
#include <arpa/inet.h>
int main()
{
int s, value;
struct sockaddr_in6 addr;
struct ipv6_mreq m6;
s = socket(AF_INET6, SOCK_DGRAM, 0);
addr.sin6_family = AF_INET6;
addr.sin6_port = htons(5000);
inet_pton(AF_INET6, "::ffff:192.168.122.194", &addr.sin6_addr);
connect(s, (struct sockaddr *)&addr, sizeof(addr));
inet_pton(AF_INET6, "fe80::AAAA", &m6.ipv6mr_multiaddr);
m6.ipv6mr_interface = 5;
setsockopt(s, SOL_IPV6, IPV6_JOIN_ANYCAST, &m6, sizeof(m6));
value = AF_INET;
setsockopt(s, SOL_IPV6, IPV6_ADDRFORM, &value, sizeof(value));
close(s);
return 0;
}
Reported-by: ch3332xr@gmail.com
Fixes:
1da177e4c3f4 ("Linux-2.6.12-rc2")
Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Christoph Hellwig [Thu, 30 Jul 2020 16:09:00 +0000 (18:09 +0200)]
net/bpfilter: Initialize pos in __bpfilter_process_sockopt
__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 now verified the
position, which can lead to a failure depending on the exact stack
initialization pattern. Initialize the variable to zero to make
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>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Tested-by: Rodrigo Madera <rodrigo.madera@gmail.com>
Tested-by: Christian Brauner <christian.brauner@ubuntu.com>
Reviewed-by: Christian Brauner <christian.brauner@ubuntu.com>
Link: https://lore.kernel.org/bpf/20200730160900.187157-1-hch@lst.de
Francesco Ruggeri [Thu, 2 Jul 2020 22:39:06 +0000 (15:39 -0700)]
igb: reinit_locked() should be called with rtnl_lock
We observed two panics involving races with igb_reset_task.
The first panic is caused by this race condition:
kworker reboot -f
igb_reset_task
igb_reinit_locked
igb_down
napi_synchronize
__igb_shutdown
igb_clear_interrupt_scheme
igb_free_q_vectors
igb_free_q_vector
adapter->q_vector[v_idx] = NULL;
napi_disable
Panics trying to access
adapter->q_vector[v_idx].napi_state
The second panic (a divide error) is caused by this race:
kworker reboot -f tx packet
igb_reset_task
__igb_shutdown
rtnl_lock()
...
igb_clear_interrupt_scheme
igb_free_q_vectors
adapter->num_tx_queues = 0
...
rtnl_unlock()
rtnl_lock()
igb_reinit_locked
igb_down
igb_up
netif_tx_start_all_queues
dev_hard_start_xmit
igb_xmit_frame
igb_tx_queue_mapping
Panics on
r_idx % adapter->num_tx_queues
This commit applies to igb_reset_task the same changes that
were applied to ixgbe in commit
2f90b8657ec9 ("ixgbe: this patch
adds support for DCB to the kernel and ixgbe driver"),
commit
8f4c5c9fb87a ("ixgbe: reinit_locked() should be called with
rtnl_lock") and commit
88adce4ea8f9 ("ixgbe: fix possible race in
reset subtask").
Signed-off-by: Francesco Ruggeri <fruggeri@arista.com>
Tested-by: Aaron Brown <aaron.f.brown@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
Aaron Ma [Thu, 18 Jun 2020 06:54:53 +0000 (14:54 +0800)]
e1000e: continue to init PHY even when failed to disable ULP
After 'commit
e086ba2fccda4 ("e1000e: disable s0ix entry and exit flows
for ME systems")',
ThinkPad P14s always failed to disable ULP by ME.
'commit
0c80cdbf3320 ("e1000e: Warn if disabling ULP failed")'
break out of init phy:
error log:
[ 42.364753] e1000e 0000:00:1f.6 enp0s31f6: Failed to disable ULP
[ 42.524626] e1000e 0000:00:1f.6 enp0s31f6: PHY Wakeup cause - Unicast Packet
[ 42.822476] e1000e 0000:00:1f.6 enp0s31f6: Hardware Error
When disable s0ix, E1000_FWSM_ULP_CFG_DONE will never be 1.
If continue to init phy like before, it can work as before.
iperf test result good too.
Fixes:
0c80cdbf3320 ("e1000e: Warn if disabling ULP failed")
Signed-off-by: Aaron Ma <aaron.ma@canonical.com>
Tested-by: Aaron Brown <aaron.f.brown@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
Felix Fietkau [Sat, 25 Jul 2020 08:45:33 +0000 (10:45 +0200)]
mac80211: remove STA txq pending airtime underflow warning
This warning can trigger if there is a mismatch between frames that were
sent with the sta pointer set vs tx status frames reported for the sta address.
This can happen due to race conditions on re-creating stations, or even
in the case of .sta_add/remove being used instead of .sta_state, which can cause
frames to be sent to a station that has not been uploaded yet.
If there is an actual underflow issue, it should show up in the device airtime
warning below, so it is better to remove this one.
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Link: https://lore.kernel.org/r/20200725084533.13829-1-nbd@nbd.name
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Vasanthakumar Thiagarajan [Wed, 22 Jul 2020 14:20:17 +0000 (19:50 +0530)]
mac80211: Fix bug in Tx ack status reporting in 802.3 xmit path
Allocated ack_frame id from local->ack_status_frames is not really
stored in the tx_info for 802.3 Tx path. Due to this, tx ack status
is not reported and ack_frame id is not freed for the buffers requiring
tx ack status. Also move the memset to 0 of tx_info before
IEEE80211_TX_CTL_REQ_TX_STATUS flag assignment.
Fixes:
50ff477a8639 ("mac80211: add 802.11 encapsulation offloading support")
Signed-off-by: Vasanthakumar Thiagarajan <vthiagar@codeaurora.org>
Link: https://lore.kernel.org/r/1595427617-1713-1-git-send-email-vthiagar@codeaurora.org
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Julian Squires [Mon, 6 Jul 2020 21:13:53 +0000 (17:13 -0400)]
cfg80211: check vendor command doit pointer before use
In the case where a vendor command does not implement doit, and has no
flags set, doit would not be validated and a NULL pointer dereference
would occur, for example when invoking the vendor command via iw.
I encountered this while developing new vendor commands. Perhaps in
practice it is advisable to always implement doit along with dumpit,
but it seems reasonable to me to always check doit anyway, not just
when NEED_WDEV.
Signed-off-by: Julian Squires <julian@cipht.net>
Link: https://lore.kernel.org/r/20200706211353.2366470-1-julian@cipht.net
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Remi Pommarel [Sat, 4 Jul 2020 13:54:19 +0000 (15:54 +0200)]
mac80211: mesh: Free pending skb when destroying a mpath
A mpath object can hold reference on a list of skb that are waiting for
mpath resolution to be sent. When destroying a mpath this skb list
should be cleaned up in order to not leak memory.
Fixing that kind of leak:
unreferenced object 0xffff0000181c9300 (size 1088):
comm "openvpn", pid 1782, jiffies
4295071698 (age 80.416s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 f9 80 36 00 00 00 00 00 ..........6.....
02 00 07 40 00 00 00 00 00 00 00 00 00 00 00 00 ...@............
backtrace:
[<
000000004bc6a443>] kmem_cache_alloc+0x1a4/0x2f0
[<
000000002caaef13>] sk_prot_alloc.isra.39+0x34/0x178
[<
00000000ceeaa916>] sk_alloc+0x34/0x228
[<
00000000ca1f1d04>] inet_create+0x198/0x518
[<
0000000035626b1c>] __sock_create+0x134/0x328
[<
00000000a12b3a87>] __sys_socket+0xb0/0x158
[<
00000000ff859f23>] __arm64_sys_socket+0x40/0x58
[<
00000000263486ec>] el0_svc_handler+0xd0/0x1a0
[<
0000000005b5157d>] el0_svc+0x8/0xc
unreferenced object 0xffff000012973a40 (size 216):
comm "openvpn", pid 1782, jiffies
4295082137 (age 38.660s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 c0 06 16 00 00 ff ff 00 93 1c 18 00 00 ff ff ................
backtrace:
[<
000000004bc6a443>] kmem_cache_alloc+0x1a4/0x2f0
[<
0000000023c8c8f9>] __alloc_skb+0xc0/0x2b8
[<
000000007ad950bb>] alloc_skb_with_frags+0x60/0x320
[<
00000000ef90023a>] sock_alloc_send_pskb+0x388/0x3c0
[<
00000000104fb1a3>] sock_alloc_send_skb+0x1c/0x28
[<
000000006919d2dd>] __ip_append_data+0xba4/0x11f0
[<
0000000083477587>] ip_make_skb+0x14c/0x1a8
[<
0000000024f3d592>] udp_sendmsg+0xaf0/0xcf0
[<
000000005aabe255>] inet_sendmsg+0x5c/0x80
[<
000000008651ea08>] __sys_sendto+0x15c/0x218
[<
000000003505c99b>] __arm64_sys_sendto+0x74/0x90
[<
00000000263486ec>] el0_svc_handler+0xd0/0x1a0
[<
0000000005b5157d>] el0_svc+0x8/0xc
Fixes:
2bdaf386f99c (mac80211: mesh: move path tables into if_mesh)
Signed-off-by: Remi Pommarel <repk@triplefau.lt>
Link: https://lore.kernel.org/r/20200704135419.27703-1-repk@triplefau.lt
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Remi Pommarel [Sat, 4 Jul 2020 13:50:07 +0000 (15:50 +0200)]
mac80211: mesh: Free ie data when leaving mesh
At ieee80211_join_mesh() some ie data could have been allocated (see
copy_mesh_setup()) and need to be cleaned up when leaving the mesh.
This fixes the following kmemleak report:
unreferenced object 0xffff0000116bc600 (size 128):
comm "wpa_supplicant", pid 608, jiffies
4294898983 (age 293.484s)
hex dump (first 32 bytes):
30 14 01 00 00 0f ac 04 01 00 00 0f ac 04 01 00 0...............
00 0f ac 08 00 00 00 00 c4 65 40 00 00 00 00 00 .........e@.....
backtrace:
[<
00000000bebe439d>] __kmalloc_track_caller+0x1c0/0x330
[<
00000000a349dbe1>] kmemdup+0x28/0x50
[<
0000000075d69baa>] ieee80211_join_mesh+0x6c/0x3b8 [mac80211]
[<
00000000683bb98b>] __cfg80211_join_mesh+0x1e8/0x4f0 [cfg80211]
[<
0000000072cb507f>] nl80211_join_mesh+0x520/0x6b8 [cfg80211]
[<
0000000077e9bcf9>] genl_family_rcv_msg+0x374/0x680
[<
00000000b1bd936d>] genl_rcv_msg+0x78/0x108
[<
0000000022c53788>] netlink_rcv_skb+0xb0/0x1c0
[<
0000000011af8ec9>] genl_rcv+0x34/0x48
[<
0000000069e41f53>] netlink_unicast+0x268/0x2e8
[<
00000000a7517316>] netlink_sendmsg+0x320/0x4c0
[<
0000000069cba205>] ____sys_sendmsg+0x354/0x3a0
[<
00000000e06bab0f>] ___sys_sendmsg+0xd8/0x120
[<
0000000037340728>] __sys_sendmsg+0xa4/0xf8
[<
000000004fed9776>] __arm64_sys_sendmsg+0x44/0x58
[<
000000001c1e5647>] el0_svc_handler+0xd0/0x1a0
Fixes:
c80d545da3f7 (mac80211: Let userspace enable and configure vendor specific path selection.)
Signed-off-by: Remi Pommarel <repk@triplefau.lt>
Link: https://lore.kernel.org/r/20200704135007.27292-1-repk@triplefau.lt
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Rajkumar Manoharan [Thu, 2 Jul 2020 02:20:24 +0000 (19:20 -0700)]
mac80211: fix warning in 6 GHz IE addition in mesh mode
The commit
24a2042cb22f ("mac80211: add HE 6 GHz Band Capability
element") failed to check device capability before adding HE 6 GHz
capability element. Below warning is reported in 11ac device in mesh.
Fix that by checking device capability at HE 6 GHz cap IE addition
in mesh beacon and association request.
WARNING: CPU: 1 PID: 1897 at net/mac80211/util.c:2878
ieee80211_ie_build_he_6ghz_cap+0x149/0x150 [mac80211]
[ 3138.720358] Call Trace:
[ 3138.720361] ieee80211_mesh_build_beacon+0x462/0x530 [mac80211]
[ 3138.720363] ieee80211_start_mesh+0xa8/0xf0 [mac80211]
[ 3138.720365] __cfg80211_join_mesh+0x122/0x3e0 [cfg80211]
[ 3138.720368] nl80211_join_mesh+0x3d3/0x510 [cfg80211]
Fixes:
24a2042cb22f ("mac80211: add HE 6 GHz Band Capability element")
Reported-by: Markus Theil <markus.theil@tu-ilmenau.de>
Signed-off-by: Rajkumar Manoharan <rmanohar@codeaurora.org>
Link: https://lore.kernel.org/r/1593656424-18240-1-git-send-email-rmanohar@codeaurora.org
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Sabrina Dubroca [Wed, 29 Jul 2020 16:38:43 +0000 (18:38 +0200)]
espintcp: count packets dropped in espintcp_rcv
Currently, espintcp_rcv drops packets silently, which makes debugging
issues difficult. Count packets as either XfrmInHdrError (when the
packet was too short or contained invalid data) or XfrmInError (for
other issues).
Signed-off-by: Sabrina Dubroca <sd@queasysnail.net>
Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
Sabrina Dubroca [Wed, 29 Jul 2020 16:38:42 +0000 (18:38 +0200)]
espintcp: handle short messages instead of breaking the encap socket
Currently, short messages (less than 4 bytes after the length header)
will break the stream of messages. This is unnecessary, since we can
still parse messages even if they're too short to contain any usable
data. This is also bogus, as keepalive messages (a single 0xff byte),
though not needed with TCP encapsulation, should be allowed.
This patch changes the stream parser so that short messages are
accepted and dropped in the kernel. Messages that contain a valid SPI
or non-ESP header are processed as before.
Fixes:
e27cca96cd68 ("xfrm: add espintcp (RFC 8229)")
Reported-by: Andrew Cagney <cagney@libreswan.org>
Signed-off-by: Sabrina Dubroca <sd@queasysnail.net>
Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
Andrii Nakryiko [Wed, 29 Jul 2020 04:09:13 +0000 (21:09 -0700)]
selftests/bpf: Extend map-in-map selftest to detect memory leaks
Add test validating that all inner maps are released properly after skeleton
is destroyed. To ensure determinism, trigger kernel-side synchronize_rcu()
before checking map existence by their IDs.
Signed-off-by: Andrii Nakryiko <andriin@fb.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: Song Liu <songliubraving@fb.com>
Link: https://lore.kernel.org/bpf/20200729040913.2815687-2-andriin@fb.com
Andrii Nakryiko [Wed, 29 Jul 2020 04:09:12 +0000 (21:09 -0700)]
bpf: Fix map leak in HASH_OF_MAPS map
Fix HASH_OF_MAPS bug of not putting inner map pointer on bpf_map_elem_update()
operation. This is due to per-cpu extra_elems optimization, which bypassed
free_htab_elem() logic doing proper clean ups. Make sure that inner map is put
properly in optimized case as well.
Fixes:
8c290e60fa2a ("bpf: fix hashmap extra_elems logic")
Signed-off-by: Andrii Nakryiko <andriin@fb.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: Song Liu <songliubraving@fb.com>
Link: https://lore.kernel.org/bpf/20200729040913.2815687-1-andriin@fb.com
Thomas Falcon [Wed, 29 Jul 2020 21:36:32 +0000 (16:36 -0500)]
ibmvnic: Fix IRQ mapping disposal in error path
RX queue IRQ mappings are disposed in both the TX IRQ and RX IRQ
error paths. Fix this and dispose of TX IRQ mappings correctly in
case of an error.
Fixes:
ea22d51a7831 ("ibmvnic: simplify and improve driver probe function")
Signed-off-by: Thomas Falcon <tlfalcon@linux.ibm.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
David S. Miller [Wed, 29 Jul 2020 19:16:21 +0000 (12:16 -0700)]
Merge branch 'mlxsw-fixes'
Ido Schimmel says:
====================
mlxsw fixes
This patch set contains various fixes for mlxsw.
Patches #1-#2 fix two trap related issues introduced in previous cycle.
Patches #3-#5 fix rare use-after-frees discovered by syzkaller. After
over a week of fuzzing with the fixes, the bugs did not reproduce.
Patch #6 from Amit fixes an issue in the ethtool selftest that was
recently discovered after running the test on a new platform that
supports only 1Gbps and 10Gbps speeds.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
Amit Cohen [Wed, 29 Jul 2020 09:26:48 +0000 (12:26 +0300)]
selftests: ethtool: Fix test when only two speeds are supported
The test case check_highest_speed_is_chosen() configures $h1 to
advertise a subset of its supported speeds and checks that $h2 chooses
the highest speed from the subset.
To find the common advertised speeds between $h1 and $h2,
common_speeds_get() is called.
Currently, the first speed returned from common_speeds_get() is removed
claiming "h1 does not advertise this speed". The claim is wrong because
the function is called after $h1 already advertised a subset of speeds.
In case $h1 supports only two speeds, it will advertise a single speed
which will be later removed because of previously mentioned bug. This
results in the test needlessly failing. When more than two speeds are
supported this is not an issue because the first advertised speed
is the lowest one.
Fix this by not removing any speed from the list of commonly advertised
speeds.
Fixes:
64916b57c0b1 ("selftests: forwarding: Add speed and auto-negotiation test")
Reported-by: Danielle Ratson <danieller@mellanox.com>
Signed-off-by: Amit Cohen <amitc@mellanox.com>
Signed-off-by: Ido Schimmel <idosch@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Ido Schimmel [Wed, 29 Jul 2020 09:26:47 +0000 (12:26 +0300)]
mlxsw: spectrum_router: Fix use-after-free in router init / de-init
Several notifiers are registered as part of router initialization.
Since some of these notifiers are registered before the end of the
initialization, it is possible for them to access uninitialized or freed
memory when processing notifications [1].
Additionally, some of these notifiers queue work items on a workqueue.
If these work items are executed after the router was de-initialized,
they will access freed memory.
Fix both problems by moving the registration of the notifiers to the end
of the router initialization and flush the work queue after they are
unregistered.
[1]
BUG: KASAN: use-after-free in __mutex_lock_common kernel/locking/mutex.c:938 [inline]
BUG: KASAN: use-after-free in __mutex_lock+0xeea/0x1340 kernel/locking/mutex.c:1103
Read of size 8 at addr
ffff888038c3a6e0 by task kworker/u4:1/61
CPU: 1 PID: 61 Comm: kworker/u4:1 Not tainted 5.8.0-rc2+ #36
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.1-0-ga5cab58e9a3f-prebuilt.qemu.org 04/01/2014
Workqueue: mlxsw_core_ordered mlxsw_sp_inet6addr_event_work
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0xf6/0x16e lib/dump_stack.c:118
print_address_description.constprop.0+0x1c/0x250 mm/kasan/report.c:383
__kasan_report mm/kasan/report.c:513 [inline]
kasan_report.cold+0x1f/0x37 mm/kasan/report.c:530
__mutex_lock_common kernel/locking/mutex.c:938 [inline]
__mutex_lock+0xeea/0x1340 kernel/locking/mutex.c:1103
mlxsw_sp_inet6addr_event_work+0xb3/0x1b0 drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c:7123
process_one_work+0xa3e/0x17a0 kernel/workqueue.c:2269
worker_thread+0x9e/0x1050 kernel/workqueue.c:2415
kthread+0x355/0x470 kernel/kthread.c:291
ret_from_fork+0x22/0x30 arch/x86/entry/entry_64.S:293
Allocated by task 1298:
save_stack+0x1b/0x40 mm/kasan/common.c:48
set_track mm/kasan/common.c:56 [inline]
__kasan_kmalloc mm/kasan/common.c:494 [inline]
__kasan_kmalloc.constprop.0+0xc2/0xd0 mm/kasan/common.c:467
kmalloc include/linux/slab.h:555 [inline]
kzalloc include/linux/slab.h:669 [inline]
mlxsw_sp_router_init+0xb2/0x1d20 drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c:8074
mlxsw_sp_init+0xbd8/0x3ac0 drivers/net/ethernet/mellanox/mlxsw/spectrum.c:2932
__mlxsw_core_bus_device_register+0x657/0x10d0 drivers/net/ethernet/mellanox/mlxsw/core.c:1375
mlxsw_core_bus_device_register drivers/net/ethernet/mellanox/mlxsw/core.c:1436 [inline]
mlxsw_devlink_core_bus_device_reload_up+0xcd/0x150 drivers/net/ethernet/mellanox/mlxsw/core.c:1133
devlink_reload net/core/devlink.c:2959 [inline]
devlink_reload+0x281/0x3b0 net/core/devlink.c:2944
devlink_nl_cmd_reload+0x2f1/0x7c0 net/core/devlink.c:2987
genl_family_rcv_msg_doit net/netlink/genetlink.c:691 [inline]
genl_family_rcv_msg net/netlink/genetlink.c:736 [inline]
genl_rcv_msg+0x611/0x9d0 net/netlink/genetlink.c:753
netlink_rcv_skb+0x152/0x440 net/netlink/af_netlink.c:2469
genl_rcv+0x24/0x40 net/netlink/genetlink.c:764
netlink_unicast_kernel net/netlink/af_netlink.c:1303 [inline]
netlink_unicast+0x53a/0x750 net/netlink/af_netlink.c:1329
netlink_sendmsg+0x850/0xd90 net/netlink/af_netlink.c:1918
sock_sendmsg_nosec net/socket.c:652 [inline]
sock_sendmsg+0x150/0x190 net/socket.c:672
____sys_sendmsg+0x6d8/0x840 net/socket.c:2363
___sys_sendmsg+0xff/0x170 net/socket.c:2417
__sys_sendmsg+0xe5/0x1b0 net/socket.c:2450
do_syscall_64+0x56/0xa0 arch/x86/entry/common.c:359
entry_SYSCALL_64_after_hwframe+0x44/0xa9
Freed by task 1348:
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+0x12c/0x170 mm/kasan/common.c:455
slab_free_hook mm/slub.c:1474 [inline]
slab_free_freelist_hook mm/slub.c:1507 [inline]
slab_free mm/slub.c:3072 [inline]
kfree+0xe6/0x320 mm/slub.c:4063
mlxsw_sp_fini+0x340/0x4e0 drivers/net/ethernet/mellanox/mlxsw/spectrum.c:3132
mlxsw_core_bus_device_unregister+0x16c/0x6d0 drivers/net/ethernet/mellanox/mlxsw/core.c:1474
mlxsw_devlink_core_bus_device_reload_down+0x8e/0xc0 drivers/net/ethernet/mellanox/mlxsw/core.c:1123
devlink_reload+0xc6/0x3b0 net/core/devlink.c:2952
devlink_nl_cmd_reload+0x2f1/0x7c0 net/core/devlink.c:2987
genl_family_rcv_msg_doit net/netlink/genetlink.c:691 [inline]
genl_family_rcv_msg net/netlink/genetlink.c:736 [inline]
genl_rcv_msg+0x611/0x9d0 net/netlink/genetlink.c:753
netlink_rcv_skb+0x152/0x440 net/netlink/af_netlink.c:2469
genl_rcv+0x24/0x40 net/netlink/genetlink.c:764
netlink_unicast_kernel net/netlink/af_netlink.c:1303 [inline]
netlink_unicast+0x53a/0x750 net/netlink/af_netlink.c:1329
netlink_sendmsg+0x850/0xd90 net/netlink/af_netlink.c:1918
sock_sendmsg_nosec net/socket.c:652 [inline]
sock_sendmsg+0x150/0x190 net/socket.c:672
____sys_sendmsg+0x6d8/0x840 net/socket.c:2363
___sys_sendmsg+0xff/0x170 net/socket.c:2417
__sys_sendmsg+0xe5/0x1b0 net/socket.c:2450
do_syscall_64+0x56/0xa0 arch/x86/entry/common.c:359
entry_SYSCALL_64_after_hwframe+0x44/0xa9
The buggy address belongs to the object at
ffff888038c3a000
which belongs to the cache kmalloc-2k of size 2048
The buggy address is located 1760 bytes inside of
2048-byte region [
ffff888038c3a000,
ffff888038c3a800)
The buggy address belongs to the page:
page:
ffffea0000e30e00 refcount:1 mapcount:0 mapping:
0000000000000000 index:0x0 head:
ffffea0000e30e00 order:3 compound_mapcount:0 compound_pincount:0
flags: 0x100000000010200(slab|head)
raw:
0100000000010200 dead000000000100 dead000000000122 ffff88806c40c000
raw:
0000000000000000 0000000000080008 00000001ffffffff 0000000000000000
page dumped because: kasan: bad access detected
Memory state around the buggy address:
ffff888038c3a580: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
ffff888038c3a600: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
>
ffff888038c3a680: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
^
ffff888038c3a700: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
ffff888038c3a780: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
Fixes:
965fa8e600d2 ("mlxsw: spectrum_router: Make RIF deletion more robust")
Signed-off-by: Ido Schimmel <idosch@mellanox.com>
Reviewed-by: Jiri Pirko <jiri@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Ido Schimmel [Wed, 29 Jul 2020 09:26:46 +0000 (12:26 +0300)]
mlxsw: core: Free EMAD transactions using kfree_rcu()
The lifetime of EMAD transactions (i.e., 'struct mlxsw_reg_trans') is
managed using RCU. They are freed using kfree_rcu() once the transaction
ends.
However, in case the transaction failed it is freed immediately after being
removed from the active transactions list. This is problematic because it is
still possible for a different CPU to dereference the transaction from an RCU
read-side critical section while traversing the active transaction list in
mlxsw_emad_rx_listener_func(). In which case, a use-after-free is triggered
[1].
Fix this by freeing the transaction after a grace period by calling
kfree_rcu().
[1]
BUG: KASAN: use-after-free in mlxsw_emad_rx_listener_func+0x969/0xac0 drivers/net/ethernet/mellanox/mlxsw/core.c:671
Read of size 8 at addr
ffff88800b7964e8 by task syz-executor.2/2881
CPU: 0 PID: 2881 Comm: syz-executor.2 Not tainted 5.8.0-rc4+ #44
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.1-0-ga5cab58e9a3f-prebuilt.qemu.org 04/01/2014
Call Trace:
<IRQ>
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0xf6/0x16e lib/dump_stack.c:118
print_address_description.constprop.0+0x1c/0x250 mm/kasan/report.c:383
__kasan_report mm/kasan/report.c:513 [inline]
kasan_report.cold+0x1f/0x37 mm/kasan/report.c:530
mlxsw_emad_rx_listener_func+0x969/0xac0 drivers/net/ethernet/mellanox/mlxsw/core.c:671
mlxsw_core_skb_receive+0x571/0x700 drivers/net/ethernet/mellanox/mlxsw/core.c:2061
mlxsw_pci_cqe_rdq_handle drivers/net/ethernet/mellanox/mlxsw/pci.c:595 [inline]
mlxsw_pci_cq_tasklet+0x12a6/0x2520 drivers/net/ethernet/mellanox/mlxsw/pci.c:651
tasklet_action_common.isra.0+0x13f/0x3e0 kernel/softirq.c:550
__do_softirq+0x223/0x964 kernel/softirq.c:292
asm_call_on_stack+0x12/0x20 arch/x86/entry/entry_64.S:711
</IRQ>
__run_on_irqstack arch/x86/include/asm/irq_stack.h:22 [inline]
run_on_irqstack_cond arch/x86/include/asm/irq_stack.h:48 [inline]
do_softirq_own_stack+0x109/0x140 arch/x86/kernel/irq_64.c:77
invoke_softirq kernel/softirq.c:387 [inline]
__irq_exit_rcu kernel/softirq.c:417 [inline]
irq_exit_rcu+0x16f/0x1a0 kernel/softirq.c:429
sysvec_apic_timer_interrupt+0x4e/0xd0 arch/x86/kernel/apic/apic.c:1091
asm_sysvec_apic_timer_interrupt+0x12/0x20 arch/x86/include/asm/idtentry.h:587
RIP: 0010:arch_local_irq_restore arch/x86/include/asm/irqflags.h:85 [inline]
RIP: 0010:__raw_spin_unlock_irqrestore include/linux/spinlock_api_smp.h:160 [inline]
RIP: 0010:_raw_spin_unlock_irqrestore+0x3b/0x40 kernel/locking/spinlock.c:191
Code: e8 2a c3 f4 fc 48 89 ef e8 12 96 f5 fc f6 c7 02 75 11 53 9d e8 d6 db 11 fd 65 ff 0d 1f 21 b3 56 5b 5d c3 e8 a7 d7 11 fd 53 9d <eb> ed 0f 1f 00 55 48 89 fd 65 ff 05 05 21 b3 56 ff 74 24 08 48 8d
RSP: 0018:
ffff8880446ffd80 EFLAGS:
00000286
RAX:
0000000000000006 RBX:
0000000000000286 RCX:
0000000000000006
RDX:
0000000000000000 RSI:
0000000000000000 RDI:
ffffffffa94ecea9
RBP:
ffff888012934408 R08:
0000000000000000 R09:
0000000000000000
R10:
0000000000000001 R11:
fffffbfff57be301 R12:
1ffff110088dffc1
R13:
ffff888037b817c0 R14:
ffff88802442415a R15:
ffff888024424000
__do_sys_perf_event_open+0x1b5d/0x2bd0 kernel/events/core.c:11874
do_syscall_64+0x56/0xa0 arch/x86/entry/common.c:384
entry_SYSCALL_64_after_hwframe+0x44/0xa9
RIP: 0033:0x473dbd
Code: Bad RIP value.
RSP: 002b:
00007f21e5e9cc28 EFLAGS:
00000246 ORIG_RAX:
000000000000012a
RAX:
ffffffffffffffda RBX:
000000000057bf00 RCX:
0000000000473dbd
RDX:
0000000000000000 RSI:
0000000000000000 RDI:
0000000020000040
RBP:
000000000057bf00 R08:
0000000000000000 R09:
0000000000000000
R10:
0000000000000003 R11:
0000000000000246 R12:
000000000057bf0c
R13:
00007ffd0493503f R14:
00000000004d0f46 R15:
00007f21e5e9cd80
Allocated by task 871:
save_stack+0x1b/0x40 mm/kasan/common.c:48
set_track mm/kasan/common.c:56 [inline]
__kasan_kmalloc mm/kasan/common.c:494 [inline]
__kasan_kmalloc.constprop.0+0xc2/0xd0 mm/kasan/common.c:467
kmalloc include/linux/slab.h:555 [inline]
kzalloc include/linux/slab.h:669 [inline]
mlxsw_core_reg_access_emad+0x70/0x1410 drivers/net/ethernet/mellanox/mlxsw/core.c:1812
mlxsw_core_reg_access+0xeb/0x540 drivers/net/ethernet/mellanox/mlxsw/core.c:1991
mlxsw_sp_port_get_hw_xstats+0x335/0x7e0 drivers/net/ethernet/mellanox/mlxsw/spectrum.c:1130
update_stats_cache+0xf4/0x140 drivers/net/ethernet/mellanox/mlxsw/spectrum.c:1173
process_one_work+0xa3e/0x17a0 kernel/workqueue.c:2269
worker_thread+0x9e/0x1050 kernel/workqueue.c:2415
kthread+0x355/0x470 kernel/kthread.c:291
ret_from_fork+0x22/0x30 arch/x86/entry/entry_64.S:293
Freed by task 871:
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+0x12c/0x170 mm/kasan/common.c:455
slab_free_hook mm/slub.c:1474 [inline]
slab_free_freelist_hook mm/slub.c:1507 [inline]
slab_free mm/slub.c:3072 [inline]
kfree+0xe6/0x320 mm/slub.c:4052
mlxsw_core_reg_access_emad+0xd45/0x1410 drivers/net/ethernet/mellanox/mlxsw/core.c:1819
mlxsw_core_reg_access+0xeb/0x540 drivers/net/ethernet/mellanox/mlxsw/core.c:1991
mlxsw_sp_port_get_hw_xstats+0x335/0x7e0 drivers/net/ethernet/mellanox/mlxsw/spectrum.c:1130
update_stats_cache+0xf4/0x140 drivers/net/ethernet/mellanox/mlxsw/spectrum.c:1173
process_one_work+0xa3e/0x17a0 kernel/workqueue.c:2269
worker_thread+0x9e/0x1050 kernel/workqueue.c:2415
kthread+0x355/0x470 kernel/kthread.c:291
ret_from_fork+0x22/0x30 arch/x86/entry/entry_64.S:293
The buggy address belongs to the object at
ffff88800b796400
which belongs to the cache kmalloc-512 of size 512
The buggy address is located 232 bytes inside of
512-byte region [
ffff88800b796400,
ffff88800b796600)
The buggy address belongs to the page:
page:
ffffea00002de500 refcount:1 mapcount:0 mapping:
0000000000000000 index:0x0 head:
ffffea00002de500 order:2 compound_mapcount:0 compound_pincount:0
flags: 0x100000000010200(slab|head)
raw:
0100000000010200 dead000000000100 dead000000000122 ffff88806c402500
raw:
0000000000000000 0000000000100010 00000001ffffffff 0000000000000000
page dumped because: kasan: bad access detected
Memory state around the buggy address:
ffff88800b796380: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
ffff88800b796400: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
>
ffff88800b796480: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
^
ffff88800b796500: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
ffff88800b796580: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
Fixes:
caf7297e7ab5 ("mlxsw: core: Introduce support for asynchronous EMAD register access")
Signed-off-by: Ido Schimmel <idosch@mellanox.com>
Reviewed-by: Jiri Pirko <jiri@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Ido Schimmel [Wed, 29 Jul 2020 09:26:45 +0000 (12:26 +0300)]
mlxsw: core: Increase scope of RCU read-side critical section
The lifetime of the Rx listener item ('rxl_item') is managed using RCU,
but is dereferenced outside of RCU read-side critical section, which can
lead to a use-after-free.
Fix this by increasing the scope of the RCU read-side critical section.
Fixes:
93c1edb27f9e ("mlxsw: Introduce Mellanox switch driver core")
Signed-off-by: Ido Schimmel <idosch@mellanox.com>
Reviewed-by: Jiri Pirko <jiri@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Ido Schimmel [Wed, 29 Jul 2020 09:26:44 +0000 (12:26 +0300)]
mlxsw: spectrum: Use different trap group for externally routed packets
Cited commit mistakenly removed the trap group for externally routed
packets (e.g., via the management interface) and grouped locally routed
and externally routed packet traps under the same group, thereby
subjecting them to the same policer.
This can result in problems, for example, when FRR is restarted and
suddenly all transient traffic is trapped to the CPU because of a
default route through the management interface. Locally routed packets
required to re-establish a BGP connection will never reach the CPU and
the routing tables will not be re-populated.
Fix this by using a different trap group for externally routed packets.
Fixes:
8110668ecd9a ("mlxsw: spectrum_trap: Register layer 3 control traps")
Reported-by: Alex Veber <alexve@mellanox.com>
Tested-by: Alex Veber <alexve@mellanox.com>
Signed-off-by: Ido Schimmel <idosch@mellanox.com>
Reviewed-by: Jiri Pirko <jiri@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Ido Schimmel [Wed, 29 Jul 2020 09:26:43 +0000 (12:26 +0300)]
mlxsw: spectrum_router: Allow programming link-local host routes
Cited commit added the ability to program link-local prefix routes to
the ASIC so that relevant packets are routed and trapped correctly.
However, host routes were not included in the change and thus not
programmed to the ASIC. This can result in packets being trapped via an
external route trap instead of a local route trap as in IPv4.
Fix this by programming all the link-local routes to the ASIC.
Fixes:
10d3757fcb07 ("mlxsw: spectrum_router: Allow programming link-local prefix routes")
Reported-by: Alex Veber <alexve@mellanox.com>
Tested-by: Alex Veber <alexve@mellanox.com>
Signed-off-by: Ido Schimmel <idosch@mellanox.com>
Reviewed-by: Jiri Pirko <jiri@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Ido Schimmel [Wed, 29 Jul 2020 08:37:13 +0000 (11:37 +0300)]
ipv4: Silence suspicious RCU usage warning
fib_trie_unmerge() is called with RTNL held, but not from an RCU
read-side critical section. This leads to the following warning [1] when
the FIB alias list in a leaf is traversed with
hlist_for_each_entry_rcu().
Since the function is always called with RTNL held and since
modification of the list is protected by RTNL, simply use
hlist_for_each_entry() and silence the warning.
[1]
WARNING: suspicious RCU usage
5.8.0-rc4-custom-01520-gc1f937f3f83b #30 Not tainted
-----------------------------
net/ipv4/fib_trie.c:1867 RCU-list traversed in non-reader section!!
other info that might help us debug this:
rcu_scheduler_active = 2, debug_locks = 1
1 lock held by ip/164:
#0:
ffffffff85a27850 (rtnl_mutex){+.+.}-{3:3}, at: rtnetlink_rcv_msg+0x49a/0xbd0
stack backtrace:
CPU: 0 PID: 164 Comm: ip Not tainted 5.8.0-rc4-custom-01520-gc1f937f3f83b #30
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-2.fc32 04/01/2014
Call Trace:
dump_stack+0x100/0x184
lockdep_rcu_suspicious+0x153/0x15d
fib_trie_unmerge+0x608/0xdb0
fib_unmerge+0x44/0x360
fib4_rule_configure+0xc8/0xad0
fib_nl_newrule+0x37a/0x1dd0
rtnetlink_rcv_msg+0x4f7/0xbd0
netlink_rcv_skb+0x17a/0x480
rtnetlink_rcv+0x22/0x30
netlink_unicast+0x5ae/0x890
netlink_sendmsg+0x98a/0xf40
____sys_sendmsg+0x879/0xa00
___sys_sendmsg+0x122/0x190
__sys_sendmsg+0x103/0x1d0
__x64_sys_sendmsg+0x7d/0xb0
do_syscall_64+0x54/0xa0
entry_SYSCALL_64_after_hwframe+0x44/0xa9
RIP: 0033:0x7fc80a234e97
Code: Bad RIP value.
RSP: 002b:
00007ffef8b66798 EFLAGS:
00000246 ORIG_RAX:
000000000000002e
RAX:
ffffffffffffffda RBX:
0000000000000000 RCX:
00007fc80a234e97
RDX:
0000000000000000 RSI:
00007ffef8b66800 RDI:
0000000000000003
RBP:
000000005f141b1c R08:
0000000000000001 R09:
0000000000000000
R10:
00007fc80a2a8ac0 R11:
0000000000000246 R12:
0000000000000001
R13:
0000000000000000 R14:
00007ffef8b67008 R15:
0000556fccb10020
Fixes:
0ddcf43d5d4a ("ipv4: FIB Local/MAIN table collapse")
Signed-off-by: Ido Schimmel <idosch@mellanox.com>
Reviewed-by: Jiri Pirko <jiri@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Ido Schimmel [Wed, 29 Jul 2020 08:34:36 +0000 (11:34 +0300)]
vxlan: Ensure FDB dump is performed under RCU
The commit cited below removed the RCU read-side critical section from
rtnl_fdb_dump() which means that the ndo_fdb_dump() callback is invoked
without RCU protection.
This results in the following warning [1] in the VXLAN driver, which
relied on the callback being invoked from an RCU read-side critical
section.
Fix this by calling rcu_read_lock() in the VXLAN driver, as already done
in the bridge driver.
[1]
WARNING: suspicious RCU usage
5.8.0-rc4-custom-01521-g481007553ce6 #29 Not tainted
-----------------------------
drivers/net/vxlan.c:1379 RCU-list traversed in non-reader section!!
other info that might help us debug this:
rcu_scheduler_active = 2, debug_locks = 1
1 lock held by bridge/166:
#0:
ffffffff85a27850 (rtnl_mutex){+.+.}-{3:3}, at: netlink_dump+0xea/0x1090
stack backtrace:
CPU: 1 PID: 166 Comm: bridge Not tainted 5.8.0-rc4-custom-01521-g481007553ce6 #29
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-2.fc32 04/01/2014
Call Trace:
dump_stack+0x100/0x184
lockdep_rcu_suspicious+0x153/0x15d
vxlan_fdb_dump+0x51e/0x6d0
rtnl_fdb_dump+0x4dc/0xad0
netlink_dump+0x540/0x1090
__netlink_dump_start+0x695/0x950
rtnetlink_rcv_msg+0x802/0xbd0
netlink_rcv_skb+0x17a/0x480
rtnetlink_rcv+0x22/0x30
netlink_unicast+0x5ae/0x890
netlink_sendmsg+0x98a/0xf40
__sys_sendto+0x279/0x3b0
__x64_sys_sendto+0xe6/0x1a0
do_syscall_64+0x54/0xa0
entry_SYSCALL_64_after_hwframe+0x44/0xa9
RIP: 0033:0x7fe14fa2ade0
Code: Bad RIP value.
RSP: 002b:
00007fff75bb5b88 EFLAGS:
00000246 ORIG_RAX:
000000000000002c
RAX:
ffffffffffffffda RBX:
00005614b1ba0020 RCX:
00007fe14fa2ade0
RDX:
000000000000011c RSI:
00007fff75bb5b90 RDI:
0000000000000003
RBP:
00007fff75bb5b90 R08:
0000000000000000 R09:
0000000000000000
R10:
0000000000000000 R11:
0000000000000246 R12:
00005614b1b89160
R13:
0000000000000000 R14:
0000000000000000 R15:
0000000000000000
Fixes:
5e6d24358799 ("bridge: netlink dump interface at par with brctl")
Signed-off-by: Ido Schimmel <idosch@mellanox.com>
Reviewed-by: Jiri Pirko <jiri@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Martin Varghese [Tue, 28 Jul 2020 17:05:52 +0000 (22:35 +0530)]
Documentation: bareudp: Corrected description of bareudp module.
Removed redundant words.
Fixes:
571912c69f0e ("net: UDP tunnel encapsulation module for tunnelling different protocols like MPLS, IP, NSH etc.")
Signed-off-by: Martin Varghese <martin.varghese@nokia.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Guillaume Nault [Sat, 25 Jul 2020 13:06:47 +0000 (15:06 +0200)]
bareudp: forbid mixing IP and MPLS in multiproto mode
In multiproto mode, bareudp_xmit() accepts sending multicast MPLS and
IPv6 packets regardless of the bareudp ethertype. In practice, this
let an IP tunnel send multicast MPLS packets, or an MPLS tunnel send
IPv6 packets.
We need to restrict the test further, so that the multiproto mode only
enables
* IPv6 for IPv4 tunnels,
* or multicast MPLS for unicast MPLS tunnels.
To improve clarity, the protocol validation is moved to its own
function, where each logical test has its own condition.
v2: s/ntohs/htons/
Fixes:
4b5f67232d95 ("net: Special handling for IP & MPLS.")
Signed-off-by: Guillaume Nault <gnault@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Xiyu Yang [Sat, 25 Jul 2020 08:02:18 +0000 (16:02 +0800)]
ipv6: Fix nexthop refcnt leak when creating ipv6 route info
ip6_route_info_create() invokes nexthop_get(), which increases the
refcount of the "nh".
When ip6_route_info_create() returns, local variable "nh" becomes
invalid, so the refcount should be decreased to keep refcount balanced.
The reference counting issue happens in one exception handling path of
ip6_route_info_create(). When nexthops can not be used with source
routing, the function forgets to decrease the refcnt increased by
nexthop_get(), causing a refcnt leak.
Fix this issue by pulling up the error source routing handling when
nexthops can not be used with source routing.
Fixes:
f88d8ea67fbd ("ipv6: Plumb support for nexthop object in a fib6_info")
Signed-off-by: Xiyu Yang <xiyuyang19@fudan.edu.cn>
Signed-off-by: Xin Tan <tanxin.ctf@gmail.com>
Reviewed-by: David Ahern <dsahern@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
David S. Miller [Wed, 29 Jul 2020 00:14:48 +0000 (17:14 -0700)]
Merge branch 'Fix-bugs-in-Octeontx2-netdev-driver'
Subbaraya Sundeep says:
====================
Fix bugs in Octeontx2 netdev driver
There are problems in the existing Octeontx2
netdev drivers like missing cancel_work for the
reset task, missing lock in reset task and
missing unergister_netdev in driver remove.
This patch set fixes the above problems.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
Subbaraya Sundeep [Sat, 25 Jul 2020 04:43:54 +0000 (10:13 +0530)]
octeontx2-pf: Unregister netdev at driver remove
Added unregister_netdev in the driver remove
function. Generally unregister_netdev is called
after disabling all the device interrupts but here
it is called before disabling device mailbox
interrupts. The reason behind this is VF needs
mailbox interrupt to communicate with its PF to
clean up its resources during otx2_stop.
otx2_stop disables packet I/O and queue interrupts
first and by using mailbox interrupt communicates
to PF to free VF resources. Hence this patch
calls unregister_device just before
disabling mailbox interrupts.
Fixes:
3184fb5ba96e ("octeontx2-vf: Virtual function driver support")
Signed-off-by: Subbaraya Sundeep <sbhatta@marvell.com>
Signed-off-by: Sunil Goutham <sgoutham@marvell.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Subbaraya Sundeep [Sat, 25 Jul 2020 04:43:53 +0000 (10:13 +0530)]
octeontx2-pf: cancel reset_task work
During driver exit cancel the queued
reset_task work in VF driver.
Fixes:
3184fb5ba96e ("octeontx2-vf: Virtual function driver support")
Signed-off-by: Subbaraya Sundeep <sbhatta@marvell.com>
Signed-off-by: Sunil Goutham <sgoutham@marvell.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Subbaraya Sundeep [Sat, 25 Jul 2020 04:43:52 +0000 (10:13 +0530)]
octeontx2-pf: Fix reset_task bugs
Two bugs exist in the code related to reset_task
in PF driver one is the missing protection
against network stack ndo_open and ndo_close.
Other one is the missing cancel_work.
This patch fixes those problems.
Fixes:
4ff7d1488a84 ("octeontx2-pf: Error handling support")
Signed-off-by: Subbaraya Sundeep <sbhatta@marvell.com>
Signed-off-by: Sunil Goutham <sgoutham@marvell.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Jakub Kicinski [Fri, 24 Jul 2020 23:15:43 +0000 (16:15 -0700)]
mlx4: disable device on shutdown
It appears that not disabling a PCI device on .shutdown may lead to
a Hardware Error with particular (perhaps buggy) BIOS versions:
mlx4_en: eth0: Close port called
mlx4_en 0000:04:00.0: removed PHC
reboot: Restarting system
{1}[Hardware Error]: Hardware error from APEI Generic Hardware Error Source: 1
{1}[Hardware Error]: event severity: fatal
{1}[Hardware Error]: Error 0, type: fatal
{1}[Hardware Error]: section_type: PCIe error
{1}[Hardware Error]: port_type: 4, root port
{1}[Hardware Error]: version: 1.16
{1}[Hardware Error]: command: 0x4010, status: 0x0143
{1}[Hardware Error]: device_id: 0000:00:02.2
{1}[Hardware Error]: slot: 0
{1}[Hardware Error]: secondary_bus: 0x04
{1}[Hardware Error]: vendor_id: 0x8086, device_id: 0x2f06
{1}[Hardware Error]: class_code: 000604
{1}[Hardware Error]: bridge: secondary_status: 0x2000, control: 0x0003
{1}[Hardware Error]: aer_uncor_status: 0x00100000, aer_uncor_mask: 0x00000000
{1}[Hardware Error]: aer_uncor_severity: 0x00062030
{1}[Hardware Error]: TLP Header:
40000018 040000ff 791f4080 00000000
[hw error repeats]
Kernel panic - not syncing: Fatal hardware error!
CPU: 0 PID: 2189 Comm: reboot Kdump: loaded Not tainted 5.6.x-blabla #1
Hardware name: HP ProLiant DL380 Gen9/ProLiant DL380 Gen9, BIOS P89 05/05/2017
Fix the mlx4 driver.
This is a very similar problem to what had been fixed in:
commit
0d98ba8d70b0 ("scsi: hpsa: disable device during shutdown")
to address https://bugzilla.kernel.org/show_bug.cgi?id=199779.
Fixes:
2ba5fbd62b25 ("net/mlx4_core: Handle AER flow properly")
Reported-by: Jake Lawrence <lawja@fb.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Reviewed-by: Saeed Mahameed <saeedm@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
David S. Miller [Wed, 29 Jul 2020 00:09:49 +0000 (17:09 -0700)]
Merge branch 'rhashtable-Fix-unprotected-RCU-dereference-in-__rht_ptr'
Herbert Xu says:
====================
rhashtable: Fix unprotected RCU dereference in __rht_ptr
This patch series fixes an unprotected dereference in __rht_ptr.
The first patch is a minimal fix that does not use the correct
RCU markings but is suitable for backport, and the second patch
cleans up the RCU markings.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
Herbert Xu [Fri, 24 Jul 2020 10:14:34 +0000 (20:14 +1000)]
rhashtable: Restore RCU marking on rhash_lock_head
This patch restores the RCU marking on bucket_table->buckets as
it really does need RCU protection. Its removal had led to a fatal
bug.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: David S. Miller <davem@davemloft.net>
Herbert Xu [Fri, 24 Jul 2020 10:12:53 +0000 (20:12 +1000)]
rhashtable: Fix unprotected RCU dereference in __rht_ptr
The rcu_dereference call in rht_ptr_rcu is completely bogus because
we've already dereferenced the value in __rht_ptr and operated on it.
This causes potential double readings which could be fatal. The RCU
dereference must occur prior to the comparison in __rht_ptr.
This patch changes the order of RCU dereference so that it is done
first and the result is then fed to __rht_ptr. The RCU marking
changes have been minimised using casts which will be removed in
a follow-up patch.
Fixes:
ba6306e3f648 ("rhashtable: Remove RCU marking from...")
Reported-by: "Gong, Sishuai" <sishuai@purdue.edu>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: David S. Miller <davem@davemloft.net>
René van Dorst [Thu, 23 Jul 2020 19:07:10 +0000 (20:07 +0100)]
net: ethernet: mtk_eth_soc: Always call mtk_gmac0_rgmii_adjust() for mt7623
Modify mtk_gmac0_rgmii_adjust() so it can always be called.
mtk_gmac0_rgmii_adjust() sets-up the TRGMII clocks.
Signed-off-by: René van Dorst <opensource@vdorst.com>
Signed-off-By: David Woodhouse <dwmw2@infradead.org>
Tested-by: Frank Wunderlich <frank-w@public-files.de>
Signed-off-by: David S. Miller <davem@davemloft.net>
David S. Miller [Tue, 28 Jul 2020 23:55:13 +0000 (16:55 -0700)]
Merge tag 'mlx5-fixes-2020-07-28' of git://git./linux/kernel/git/saeed/linux
Saeed Mahameed says:
====================
mlx5 fixes-2020-07-28
This series introduces some fixes to mlx5 driver.
v1->v2:
- Drop the "Hold reference on mirred devices" patch, until Or's
comments are addressed.
- Imporve "Modify uplink state" patch commit message per Or's request.
Please pull and let me know if there is any problem.
For -Stable:
For -stable v4.9
('net/mlx5e: Fix error path of device attach')
For -stable v4.15
('net/mlx5: Verify Hardware supports requested ptp function on a given
pin')
For -stable v5.3
('net/mlx5e: Modify uplink state on interface up/down')
For -stable v5.4
('net/mlx5e: Fix kernel crash when setting vf VLANID on a VF dev')
('net/mlx5: E-switch, Destroy TSAR when fail to enable the mode')
For -stable v5.5
('net/mlx5: E-switch, Destroy TSAR after reload interface')
For -stable v5.7
('net/mlx5: Fix a bug of using ptp channel index as pin index')
====================
Acked-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
David S. Miller [Tue, 28 Jul 2020 20:35:44 +0000 (13:35 -0700)]
Merge branch 'net-lan78xx-fix-NULL-deref-and-memory-leak'
Johan Hovold says:
====================
net: lan78xx: fix NULL deref and memory leak
The first two patches fix a NULL-pointer dereference at probe that can
be triggered by a malicious device and a small transfer-buffer memory
leak, respectively.
For another subsystem I would have marked them:
Cc: stable@vger.kernel.org # 4.3
The third one replaces the driver's current broken endpoint lookup
helper, which could end up accepting incomplete interfaces and whose
results weren't even useeren
Johan
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
Johan Hovold [Tue, 28 Jul 2020 12:10:31 +0000 (14:10 +0200)]
net: lan78xx: replace bogus endpoint lookup
Drop the bogus endpoint-lookup helper which could end up accepting
interfaces based on endpoints belonging to unrelated altsettings.
Note that the returned bulk pipes and interrupt endpoint descriptor
were never actually used. Instead the bulk-endpoint numbers are
hardcoded to 1 and 2 (matching the specification), while the interrupt-
endpoint descriptor was assumed to be the third descriptor created by
USB core.
Try to bring some order to this by dropping the bogus lookup helper and
adding the missing endpoint sanity checks while keeping the interrupt-
descriptor assumption for now.
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Johan Hovold [Tue, 28 Jul 2020 12:10:30 +0000 (14:10 +0200)]
net: lan78xx: fix transfer-buffer memory leak
The interrupt URB transfer-buffer was never freed on disconnect or after
probe errors.
Fixes:
55d7de9de6c3 ("Microchip's LAN7800 family USB 2/3 to 10/100/1000 Ethernet device driver")
Cc: Woojung.Huh@microchip.com <Woojung.Huh@microchip.com>
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Johan Hovold [Tue, 28 Jul 2020 12:10:29 +0000 (14:10 +0200)]
net: lan78xx: add missing endpoint sanity check
Add the missing endpoint sanity check to prevent a NULL-pointer
dereference should a malicious device lack the expected endpoints.
Note that the driver has a broken endpoint-lookup helper,
lan78xx_get_endpoints(), which can end up accepting interfaces in an
altsetting without endpoints as long as *some* altsetting has a bulk-in
and a bulk-out endpoint.
Fixes:
55d7de9de6c3 ("Microchip's LAN7800 family USB 2/3 to 10/100/1000 Ethernet device driver")
Cc: Woojung.Huh@microchip.com <Woojung.Huh@microchip.com>
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Rustam Kovhaev [Tue, 28 Jul 2020 06:42:17 +0000 (23:42 -0700)]
usb: hso: check for return value in hso_serial_common_create()
in case of an error tty_register_device_attr() returns ERR_PTR(),
add IS_ERR() check
Reported-and-tested-by: syzbot+67b2bd0e34f952d0321e@syzkaller.appspotmail.com
Link: https://syzkaller.appspot.com/bug?extid=67b2bd0e34f952d0321e
Signed-off-by: Rustam Kovhaev <rkovhaev@gmail.com>
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Alaa Hleihel [Wed, 15 Jul 2020 08:46:30 +0000 (11:46 +0300)]
net/mlx5e: Fix kernel crash when setting vf VLANID on a VF dev
After the cited commit, function 'mlx5_eswitch_set_vport_vlan' started
to acquire esw->state_lock.
However, esw is not defined for VF devices, hence attempting to set vf
VLANID on a VF dev will cause a kernel panic.
Fix it by moving up the (redundant) esw validation from function
'__mlx5_eswitch_set_vport_vlan' since the rest of the callers now have
and use a valid esw.
For example with vf device eth4:
# ip link set dev eth4 vf 0 vlan 0
Trace of the panic:
[ 411.409842] BUG: unable to handle page fault for address:
00000000000011b8
[ 411.449745] #PF: supervisor read access in kernel mode
[ 411.452348] #PF: error_code(0x0000) - not-present page
[ 411.454938] PGD
80000004189c9067 P4D
80000004189c9067 PUD
41899a067 PMD 0
[ 411.458382] Oops: 0000 [#1] SMP PTI
[ 411.460268] CPU: 4 PID: 5711 Comm: ip Not tainted 5.8.0-rc4_for_upstream_min_debug_2020_07_08_22_04 #1
[ 411.462447] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.12.1-0-ga5cab58e9a3f-prebuilt.qemu.org 04/01/2014
[ 411.464158] RIP: 0010:__mutex_lock+0x4e/0x940
[ 411.464928] Code: fd 41 54 49 89 f4 41 52 53 89 d3 48 83 ec 70 44 8b 1d ee 03 b0 01 65 48 8b 04 25 28 00 00 00 48 89 45 c8 31 c0 45 85 db 75 0a <48> 3b 7f 60 0f 85 7e 05 00 00 49 8d 45 68 41 56 41 b8 01 00 00 00
[ 411.467678] RSP: 0018:
ffff88841fcd74b0 EFLAGS:
00010246
[ 411.468562] RAX:
0000000000000000 RBX:
0000000000000000 RCX:
0000000000000000
[ 411.469715] RDX:
0000000000000000 RSI:
0000000000000002 RDI:
0000000000001158
[ 411.470812] RBP:
ffff88841fcd7550 R08:
ffffffffa00fa1ce R09:
0000000000000000
[ 411.471835] R10:
ffff88841fcd7570 R11:
0000000000000000 R12:
0000000000000002
[ 411.472862] R13:
0000000000001158 R14:
ffffffffa00fa1ce R15:
0000000000000000
[ 411.474004] FS:
00007faee7ca6b80(0000) GS:
ffff88846fc00000(0000) knlGS:
0000000000000000
[ 411.475237] CS: 0010 DS: 0000 ES: 0000 CR0:
0000000080050033
[ 411.476129] CR2:
00000000000011b8 CR3:
000000041909c006 CR4:
0000000000360ea0
[ 411.477260] DR0:
0000000000000000 DR1:
0000000000000000 DR2:
0000000000000000
[ 411.478340] DR3:
0000000000000000 DR6:
00000000fffe0ff0 DR7:
0000000000000400
[ 411.479332] Call Trace:
[ 411.479760] ? __nla_validate_parse.part.6+0x57/0x8f0
[ 411.482825] ? mlx5_eswitch_set_vport_vlan+0x3e/0xa0 [mlx5_core]
[ 411.483804] mlx5_eswitch_set_vport_vlan+0x3e/0xa0 [mlx5_core]
[ 411.484733] mlx5e_set_vf_vlan+0x41/0x50 [mlx5_core]
[ 411.485545] do_setlink+0x613/0x1000
[ 411.486165] __rtnl_newlink+0x53d/0x8c0
[ 411.486791] ? mark_held_locks+0x49/0x70
[ 411.487429] ? __lock_acquire+0x8fe/0x1eb0
[ 411.488085] ? rcu_read_lock_sched_held+0x52/0x60
[ 411.488998] ? kmem_cache_alloc_trace+0x16d/0x2d0
[ 411.489759] rtnl_newlink+0x47/0x70
[ 411.490357] rtnetlink_rcv_msg+0x24e/0x450
[ 411.490978] ? netlink_deliver_tap+0x92/0x3d0
[ 411.491631] ? validate_linkmsg+0x330/0x330
[ 411.492262] netlink_rcv_skb+0x47/0x110
[ 411.492852] netlink_unicast+0x1ac/0x270
[ 411.493551] netlink_sendmsg+0x336/0x450
[ 411.494209] sock_sendmsg+0x30/0x40
[ 411.494779] ____sys_sendmsg+0x1dd/0x1f0
[ 411.495378] ? copy_msghdr_from_user+0x5c/0x90
[ 411.496082] ___sys_sendmsg+0x87/0xd0
[ 411.496683] ? lock_acquire+0xb9/0x3a0
[ 411.497322] ? lru_cache_add+0x5/0x170
[ 411.497944] ? find_held_lock+0x2d/0x90
[ 411.498568] ? handle_mm_fault+0xe46/0x18c0
[ 411.499205] ? __sys_sendmsg+0x51/0x90
[ 411.499784] __sys_sendmsg+0x51/0x90
[ 411.500341] do_syscall_64+0x59/0x2e0
[ 411.500938] ? asm_exc_page_fault+0x8/0x30
[ 411.501609] ? rcu_read_lock_sched_held+0x52/0x60
[ 411.502350] entry_SYSCALL_64_after_hwframe+0x44/0xa9
[ 411.503093] RIP: 0033:0x7faee73b85a7
[ 411.503654] Code: Bad RIP value.
Fixes:
0e18134f4f9f ("net/mlx5e: Eswitch, use state_lock to synchronize vlan change")
Signed-off-by: Alaa Hleihel <alaa@mellanox.com>
Reviewed-by: Roi Dayan <roid@mellanox.com>
Reviewed-by: Vlad Buslov <vladbu@mellanox.com>
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
Ron Diskin [Sun, 5 Apr 2020 10:58:40 +0000 (13:58 +0300)]
net/mlx5e: Modify uplink state on interface up/down
When setting the PF interface up/down, notify the firmware to update
uplink state via MODIFY_VPORT_STATE, when E-Switch is enabled.
This behavior will prevent sending traffic out on uplink port when PF is
down, such as sending traffic from a VF interface which is still up.
Currently when calling mlx5e_open/close(), the driver only sends PAOS
command to notify the firmware to set the physical port state to
up/down, however, it is not sufficient. When VF is in "auto" state, it
follows the uplink state, which was not updated on mlx5e_open/close()
before this patch.
When switchdev mode is enabled and uplink representor is first enabled,
set the uplink port state value back to its FW default "AUTO".
Fixes:
63bfd399de55 ("net/mlx5e: Send PAOS command on interface up/down")
Signed-off-by: Ron Diskin <rondi@mellanox.com>
Reviewed-by: Roi Dayan <roid@mellanox.com>
Reviewed-by: Moshe Shemesh <moshe@mellanox.com>
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
Eran Ben Elisha [Mon, 20 Jul 2020 15:34:37 +0000 (18:34 +0300)]
net/mlx5: Query PPS pin operational status before registering it
In a special configuration, a ConnectX6-Dx pin pps-out might be activated
when driver is loaded. Fix the driver to always read the operational pin
mode when registering it, and advertise it accordingly.
Fixes:
ee7f12205abc ("net/mlx5e: Implement 1PPS support")
Signed-off-by: Eran Ben Elisha <eranbe@mellanox.com>
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
Raed Salem [Thu, 9 Jul 2020 12:51:53 +0000 (15:51 +0300)]
net/mlx5e: Fix slab-out-of-bounds in mlx5e_rep_is_lag_netdev
mlx5e_rep_is_lag_netdev is used as first check as part of netdev events
handler for bond device of non-uplink representors, this handler can get
any netdevice under the same network namespace of mlx5e netdevice. Current
code treats the netdev as mlx5e netdev and only later on verifies this,
hence causes the following Kasan trace:
[15402.744990] ==================================================================
[15402.746942] BUG: KASAN: slab-out-of-bounds in mlx5e_rep_is_lag_netdev+0xcb/0xf0 [mlx5_core]
[15402.749009] Read of size 8 at addr
ffff880391f3f6b0 by task ovs-vswitchd/5347
[15402.752065] CPU: 7 PID: 5347 Comm: ovs-vswitchd Kdump: loaded Tainted: G B O --------- -t - 4.18.0-g3dcc204d291d-dirty #1
[15402.755349] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.12.1-0-ga5cab58e9a3f-prebuilt.qemu.org 04/01/2014
[15402.757600] Call Trace:
[15402.758968] dump_stack+0x71/0xab
[15402.760427] print_address_description+0x6a/0x270
[15402.761969] kasan_report+0x179/0x2d0
[15402.763445] ? mlx5e_rep_is_lag_netdev+0xcb/0xf0 [mlx5_core]
[15402.765121] mlx5e_rep_is_lag_netdev+0xcb/0xf0 [mlx5_core]
[15402.766782] mlx5e_rep_esw_bond_netevent+0x129/0x620 [mlx5_core]
Fix by deferring the violating access to be post the netdev verify check.
Fixes:
7e51891a237f ("net/mlx5e: Use netdev events to set/del egress acl forward-to-vport rule")
Signed-off-by: Raed Salem <raeds@mellanox.com>
Reviewed-by: Roi Dayan <roid@mellanox.com>
Reviewed-by: Vu Pham <vuhuong@mellanox.com>
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
Eran Ben Elisha [Wed, 8 Jul 2020 08:10:01 +0000 (11:10 +0300)]
net/mlx5: Verify Hardware supports requested ptp function on a given pin
Fix a bug where driver did not verify Hardware pin capabilities for
PTP functions.
Fixes:
ee7f12205abc ("net/mlx5e: Implement 1PPS support")
Signed-off-by: Eran Ben Elisha <eranbe@mellanox.com>
Reviewed-by: Ariel Levkovich <lariel@mellanox.com>
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
Eran Ben Elisha [Wed, 8 Jul 2020 15:53:19 +0000 (18:53 +0300)]
net/mlx5: Fix a bug of using ptp channel index as pin index
On PTP mlx5_ptp_enable(on=0) flow, driver mistakenly used channel index
as pin index.
After ptp patch marked in fixes tag was introduced, driver can freely
call ptp_find_pin() as part of the .enable() callback.
Fix driver mlx5_ptp_enable(on=0) flow to always use ptp_find_pin(). With
that, Driver will use the correct pin index in mlx5_ptp_enable(on=0) flow.
In addition, when initializing the pins, always set channel to zero. As
all pins can be attached to all channels, let ptp_set_pinfunc() to move
them between the channels.
For stable branches, this fix to be applied only on kernels that includes
both patches in fixes tag. Otherwise, mlx5_ptp_enable(on=0) will be stuck
on pincfg_mux.
Fixes:
62582a7ee783 ("ptp: Avoid deadlocks in the programmable pin code.")
Fixes:
ee7f12205abc ("net/mlx5e: Implement 1PPS support")
Signed-off-by: Eran Ben Elisha <eranbe@mellanox.com>
Reviewed-by: Ariel Levkovich <lariel@mellanox.com>
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
Maor Dickman [Wed, 8 Jul 2020 10:01:36 +0000 (13:01 +0300)]
net/mlx5e: Fix missing cleanup of ethtool steering during rep rx cleanup
The cited commit add initialization of ethtool steering during
representor rx initializations without cleaning it up in representor
rx cleanup, this may cause for stale ethtool flows to remain after
moving back from switchdev mode to legacy mode.
Fixed by calling ethtool steering cleanup during rep rx cleanup.
Fixes:
6783e8b29f63 ("net/mlx5e: Init ethtool steering for representors")
Signed-off-by: Maor Dickman <maord@mellanox.com>
Reviewed-by: Roi Dayan <roid@mellanox.com>
Reviewed-by: Vlad Buslov <vladbu@mellanox.com>
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
Aya Levin [Wed, 1 Jul 2020 09:21:53 +0000 (12:21 +0300)]
net/mlx5e: Fix error path of device attach
On failure to attach the netdev, fix the rollback by re-setting the
device's state back to MLX5E_STATE_DESTROYING.
Failing to attach doesn't stop statistics polling via .ndo_get_stats64.
In this case, although the device is not attached, it falsely continues
to query the firmware for counters. Setting the device's state back to
MLX5E_STATE_DESTROYING prevents the firmware counters query.
Fixes:
26e59d8077a3 ("net/mlx5e: Implement mlx5e interface attach/detach callbacks")
Signed-off-by: Aya Levin <ayal@mellanox.com>
Reviewed-by: Tariq Toukan <tariqt@mellanox.com>
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
Maor Gottlieb [Thu, 25 Jun 2020 07:56:07 +0000 (10:56 +0300)]
net/mlx5: Fix forward to next namespace
The steering tree is as follow (nic RX as example):
---------
|root_ns|
---------
|
--------------------------------
| | |
---------- ---------- ---------
|p(prio)0| | p1 | | pn |
---------- ---------- ---------
| |
---------------- ---------------
|ns(e.g bypass)| |ns(e.g. lag) |
---------------- ---------------
| | |
---- ---- ----
|p0| |p1| |pn|
---- ---- ----
|
----
|FT|
----
find_next_chained_ft(prio) returns the first flow table in the next
priority. If prio is a parent of a flow table then it returns the first
flow table in the next priority in the same namespace, else if prio
is parent of namespace, then it should return the first flow table
in the next namespace. Currently if the user requests to forward to
next namespace, the code calls to find_next_chained_ft with the prio
of the next namespace and not the prio of the namesapce itself.
Fixes:
9254f8ed15b6 ("net/mlx5: Add support in forward to namespace")
Signed-off-by: Maor Gottlieb <maorg@mellanox.com>
Reviewed-by: Mark Bloch <markb@mellanox.com>
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
Parav Pandit [Sat, 27 Jun 2020 10:11:56 +0000 (13:11 +0300)]
net/mlx5: E-switch, Destroy TSAR after reload interface
When eswitch offloads is enabled, TSAR is created before reloading
the interfaces.
However when eswitch offloads mode is disabled, TSAR is disabled before
reloading the interfaces.
To keep the eswitch enable/disable sequence as mirror, destroy TSAR
after reloading the interfaces.
Fixes:
1bd27b11c1df ("net/mlx5: Introduce E-switch QoS management")
Signed-off-by: Parav Pandit <parav@mellanox.com>
Reviewed-by: Roi Dayan <roid@mellanox.com>
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
Parav Pandit [Sat, 27 Jun 2020 10:29:28 +0000 (13:29 +0300)]
net/mlx5: E-switch, Destroy TSAR when fail to enable the mode
When either esw_legacy_enable() or esw_offloads_enable() fails,
code missed to destroy the created TSAR.
Hence, add the missing call to destroy the TSAR.
Fixes:
610090ebce92 ("net/mlx5: E-switch, Initialize TSAR Qos hardware block before its user vports")
Signed-off-by: Parav Pandit <parav@mellanox.com>
Reviewed-by: Roi Dayan <roid@mellanox.com>
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
David S. Miller [Tue, 28 Jul 2020 19:54:48 +0000 (12:54 -0700)]
Merge branch 'hns3-fixes'
Huazhong Tan says:
====================
net: hns3: fixes for -net
There are some bugfixes for the HNS3 ethernet driver. patch#1 fixes
a desc filling bug, patch#2 fixes a false TX timeout issue, and
patch#3~#5 fixes some bugs related to VLAN and FD.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
Guojia Liao [Tue, 28 Jul 2020 02:16:52 +0000 (10:16 +0800)]
net: hns3: fix for VLAN config when reset failed
When device is resetting or reset failed, firmware is unable to
handle mailbox. VLAN should not be configured in this case.
Fixes:
fe4144d47eef ("net: hns3: sync VLAN filter entries when kill VLAN ID failed")
Signed-off-by: Guojia Liao <liaoguojia@huawei.com>
Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Guojia Liao [Tue, 28 Jul 2020 02:16:51 +0000 (10:16 +0800)]
net: hns3: fix aRFS FD rules leftover after add a user FD rule
When user had created a FD rule, all the aRFS rules should be clear up.
HNS3 process flow as below:
1.get spin lock of fd_ruls_list
2.clear up all aRFS rules
3.release lock
4.get spin lock of fd_ruls_list
5.creat a rules
6.release lock;
There is a short period of time between step 3 and step 4, which would
creatting some new aRFS FD rules if driver was receiving packet.
So refactor the fd_rule_lock to fix it.
Fixes:
441228875706 ("net: hns3: refine the flow director handle")
Signed-off-by: Guojia Liao <liaoguojia@huawei.com>
Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Jian Shen [Tue, 28 Jul 2020 02:16:50 +0000 (10:16 +0800)]
net: hns3: add reset check for VF updating port based VLAN
Currently hclgevf_update_port_base_vlan_info() may be called when
VF is resetting, which may cause hns3_nic_net_open() being called
twice unexpectedly.
So fix it by adding a reset check for it, and extend critical
region for rntl_lock in hclgevf_update_port_base_vlan_info().
Fixes:
92f11ea177cd ("net: hns3: fix set port based VLAN issue for VF")
Signed-off-by: Jian Shen <shenjian15@huawei.com>
Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Yonglong Liu [Tue, 28 Jul 2020 02:16:49 +0000 (10:16 +0800)]
net: hns3: fix a TX timeout issue
When the queue depth and queue parameters are modified, there is
a low probability that TX timeout occurs. The two operations cause
the link to be down or up when the watchdog is still working. All
queues are stopped when the link is down. After the carrier is on,
all queues are woken up. If the watchdog detects the link between
the carrier on and wakeup queues, a false TX timeout occurs.
So fix this issue by modifying the sequence of carrier on and queue
wakeup, which is symmetrical to the link down action.
Fixes:
76ad4f0ee747 ("net: hns3: Add support of HNS3 Ethernet Driver for hip08 SoC")
Signed-off-by: Yonglong Liu <liuyonglong@huawei.com>
Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Yunsheng Lin [Tue, 28 Jul 2020 02:16:48 +0000 (10:16 +0800)]
net: hns3: fix desc filling bug when skb is expanded or lineared
The linear and frag data part may be changed when the skb is expanded
or lineared in skb_cow_head() or skb_checksum_help(), which is called
by hns3_fill_skb_desc(), so the linear len return by skb_headlen()
before the calling of hns3_fill_skb_desc() is unreliable.
Move hns3_fill_skb_desc() before the calling of skb_headlen() to fix
this bug.
Fixes:
76ad4f0ee747 ("net: hns3: Add support of HNS3 Ethernet Driver for hip08 SoC")
Signed-off-by: Yunsheng Lin <linyunsheng@huawei.com>
Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Sabrina Dubroca [Mon, 27 Jul 2020 14:03:47 +0000 (16:03 +0200)]
xfrm: esp6: fix the location of the transport header with encapsulation
commit
17175d1a27c6 ("xfrm: esp6: fix encapsulation header offset
computation") changed esp6_input_done2 to correctly find the size of
the IPv6 header that precedes the TCP/UDP encapsulation header, but
didn't adjust the final call to skb_set_transport_header, which I
assumed was correct in using skb_network_header_len.
Xiumei Mu reported that when we create xfrm states that include port
numbers in the selector, traffic from the user sockets is dropped. It
turns out that we get a state mismatch in __xfrm_policy_check, because
we end up trying to compare the encapsulation header's ports with the
selector that's based on user traffic ports.
Fixes:
0146dca70b87 ("xfrm: add support for UDPv6 encapsulation of ESP")
Fixes:
26333c37fc28 ("xfrm: add IPv6 support for espintcp")
Reported-by: Xiumei Mu <xmu@redhat.com>
Signed-off-by: Sabrina Dubroca <sd@queasysnail.net>
Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
Al Viro [Mon, 27 Jul 2020 18:22:20 +0000 (19:22 +0100)]
fix a braino in cmsghdr_from_user_compat_to_kern()
commit
547ce4cfb34c ("switch cmsghdr_from_user_compat_to_kern() to
copy_from_user()") missed one of the places where ucmlen should've been
replaced with cmsg.cmsg_len, now that we are fetching the entire struct
rather than doing it field-by-field.
As the result, compat sendmsg() with several different-sized cmsg
attached started to fail with EINVAL. Trivial to fix, fortunately.
Fixes:
547ce4cfb34c ("switch cmsghdr_from_user_compat_to_kern() to copy_from_user()")
Reported-by: Nick Bowler <nbowler@draconx.ca>
Tested-by: Nick Bowler <nbowler@draconx.ca>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: David S. Miller <davem@davemloft.net>
David S. Miller [Mon, 27 Jul 2020 19:56:59 +0000 (12:56 -0700)]
Merge branch 'selftests-net-Fix-clang-warnings-on-powerpc'
Tanner Love says:
====================
selftests/net: Fix clang warnings on powerpc
This is essentially a v2 of
http://patchwork.ozlabs.org/project/netdev/patch/
20200724181757.2331172-1-tannerlove.kernel@gmail.com/,
but it has been split up in order to have only one "Fixes" tag per
patch.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
Tanner Love [Mon, 27 Jul 2020 16:25:31 +0000 (12:25 -0400)]
selftests/net: tcp_mmap: fix clang warning for target arch PowerPC
When size_t maps to unsigned int (e.g. on 32-bit powerpc), then the
comparison with 1<<35 is always true. Clang 9 threw:
warning: result of comparison of constant
34359738368 with \
expression of type 'size_t' (aka 'unsigned int') is always true \
[-Wtautological-constant-out-of-range-compare]
while (total < FILE_SZ) {
Tested: make -C tools/testing/selftests TARGETS="net" run_tests
Fixes:
192dc405f308 ("selftests: net: add tcp_mmap program")
Signed-off-by: Tanner Love <tannerlove@google.com>
Acked-by: Willem de Bruijn <willemb@google.com>
Reviewed-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Tanner Love [Mon, 27 Jul 2020 16:25:30 +0000 (12:25 -0400)]
selftests/net: so_txtime: fix clang issues for target arch PowerPC
On powerpcle, int64_t maps to long long. Clang 9 threw:
warning: absolute value function 'labs' given an argument of type \
'long long' but has parameter of type 'long' which may cause \
truncation of value [-Wabsolute-value]
if (labs(tstop - texpect) > cfg_variance_us)
Tested: make -C tools/testing/selftests TARGETS="net" run_tests
Fixes:
af5136f95045 ("selftests/net: SO_TXTIME with ETF and FQ")
Signed-off-by: Tanner Love <tannerlove@google.com>
Acked-by: Willem de Bruijn <willemb@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Tanner Love [Mon, 27 Jul 2020 16:25:29 +0000 (12:25 -0400)]
selftests/net: psock_fanout: fix clang issues for target arch PowerPC
Clang 9 threw:
warning: format specifies type 'unsigned short' but the argument has \
type 'int' [-Wformat]
typeflags, PORT_BASE, PORT_BASE + port_off);
Tested: make -C tools/testing/selftests TARGETS="net" run_tests
Fixes:
77f65ebdca50 ("packet: packet fanout rollover during socket overload")
Signed-off-by: Tanner Love <tannerlove@google.com>
Acked-by: Willem de Bruijn <willemb@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Tanner Love [Mon, 27 Jul 2020 16:25:28 +0000 (12:25 -0400)]
selftests/net: rxtimestamp: fix clang issues for target arch PowerPC
The signedness of char is implementation-dependent. Some systems
(including PowerPC and ARM) use unsigned char. Clang 9 threw:
warning: result of comparison of constant -1 with expression of type \
'char' is always true [-Wtautological-constant-out-of-range-compare]
&arg_index)) != -1) {
Tested: make -C tools/testing/selftests TARGETS="net" run_tests
Fixes:
16e781224198 ("selftests/net: Add a test to validate behavior of rx timestamps")
Signed-off-by: Tanner Love <tannerlove@google.com>
Acked-by: Willem de Bruijn <willemb@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
laurent brando [Mon, 27 Jul 2020 10:26:14 +0000 (18:26 +0800)]
net: mscc: ocelot: fix hardware timestamp dequeue logic
The next hw timestamp should be snapshoot to the read registers
only once the current timestamp has been read.
If none of the pending skbs matches the current HW timestamp
just gracefully flush the available timestamp by reading it.
Signed-off-by: laurent brando <laurent.brando@nxp.com>
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Signed-off-by: Yangbo Lu <yangbo.lu@nxp.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Matthieu Baerts [Mon, 27 Jul 2020 10:24:33 +0000 (12:24 +0200)]
mptcp: fix joined subflows with unblocking sk
Unblocking sockets used for outgoing connections were not containing
inet info about the initial connection due to a typo there: the value of
"err" variable is negative in the kernelspace.
This fixes the creation of additional subflows where the remote port has
to be reused if the other host didn't announce another one. This also
fixes inet_diag showing blank info about MPTCP sockets from unblocking
sockets doing a connect().
Fixes:
41be81a8d3d0 ("mptcp: fix unblocking connect()")
Signed-off-by: Matthieu Baerts <matthieu.baerts@tessares.net>
Acked-by: Paolo Abeni <pabeni@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Linus Torvalds [Sat, 25 Jul 2020 21:42:11 +0000 (14:42 -0700)]
Merge tag 'riscv-for-linus-5.8-rc7' of git://git./linux/kernel/git/riscv/linux into master
Pull RISC-V fixes from Palmer Dabbelt:
"A few more fixes this week:
- A fix to avoid using SBI calls during kasan initialization, as the
SBI calls themselves have not been probed yet.
- Three fixes related to systems with multiple memory regions"
* tag 'riscv-for-linus-5.8-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux:
riscv: Parse all memory blocks to remove unusable memory
RISC-V: Do not rely on initrd_start/end computed during early dt parsing
RISC-V: Set maximum number of mapped pages correctly
riscv: kasan: use local_tlb_flush_all() to avoid uninitialized __sbi_rfence
Linus Torvalds [Sat, 25 Jul 2020 21:25:47 +0000 (14:25 -0700)]
Merge tag 'x86-urgent-2020-07-25' of git://git./linux/kernel/git/tip/tip into master
Pull x86 fixes from Ingo Molnar:
"Misc fixes:
- Fix a section end page alignment assumption that was causing
crashes
- Fix ORC unwinding on freshly forked tasks which haven't executed
yet and which have empty user task stacks
- Fix the debug.exception-trace=1 sysctl dumping of user stacks,
which was broken by recent maccess changes"
* tag 'x86-urgent-2020-07-25' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
x86/dumpstack: Dump user space code correctly again
x86/stacktrace: Fix reliable check for empty user task stacks
x86/unwind/orc: Fix ORC for newly forked tasks
x86, vmlinux.lds: Page-align end of ..page_aligned sections
Linus Torvalds [Sat, 25 Jul 2020 20:55:38 +0000 (13:55 -0700)]
Merge tag 'perf-urgent-2020-07-25' of git://git./linux/kernel/git/tip/tip into master
Pull uprobe fix from Ingo Molnar:
"Fix an interaction/regression between uprobes based shared library
tracing & GDB"
* tag 'perf-urgent-2020-07-25' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
uprobes: Change handle_swbp() to send SIGTRAP with si_code=SI_KERNEL, to fix GDB regression
Linus Torvalds [Sat, 25 Jul 2020 20:27:12 +0000 (13:27 -0700)]
Merge tag 'timers-urgent-2020-07-25' of git://git./linux/kernel/git/tip/tip into master
Pull timer fix from Ingo Molnar:
"Fix a suspend/resume regression (crash) on TI AM3/AM4 SoC's"
* tag 'timers-urgent-2020-07-25' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
clocksource/drivers/timer-ti-dm: Fix suspend and resume for am3 and am4
Linus Torvalds [Sat, 25 Jul 2020 20:24:40 +0000 (13:24 -0700)]
Merge tag 'sched-urgent-2020-07-25' of git://git./linux/kernel/git/tip/tip into master
Pull scheduler fixes from Ingo Molnar:
"Fix a race introduced by the recent loadavg race fix, plus add a debug
check for a hard to debug case of bogus wakeup function flags"
* tag 'sched-urgent-2020-07-25' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
sched: Warn if garbage is passed to default_wake_function()
sched: Fix race against ptrace_freeze_trace()
Linus Torvalds [Sat, 25 Jul 2020 20:18:42 +0000 (13:18 -0700)]
Merge tag 'efi-urgent-2020-07-25' of git://git./linux/kernel/git/tip/tip into master
Pull EFI fixes from Ingo Molnar:
"Various EFI fixes:
- Fix the layering violation in the use of the EFI runtime services
availability mask in users of the 'efivars' abstraction
- Revert build fix for GCC v4.8 which is no longer supported
- Clean up some x86 EFI stub details, some of which are borderline
bugs that copy around garbage into padding fields - let's fix these
out of caution.
- Fix build issues while working on RISC-V support
- Avoid --whole-archive when linking the stub on arm64"
* tag 'efi-urgent-2020-07-25' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
efi: Revert "efi/x86: Fix build with gcc 4"
efi/efivars: Expose RT service availability via efivars abstraction
efi/libstub: Move the function prototypes to header file
efi/libstub: Fix gcc error around __umoddi3 for 32 bit builds
efi/libstub/arm64: link stub lib.a conditionally
efi/x86: Only copy upto the end of setup_header
efi/x86: Remove unused variables
Linus Torvalds [Sat, 25 Jul 2020 19:53:46 +0000 (12:53 -0700)]
Merge tag '5.8-rc6-cifs-fix' of git://git.samba.org/sfrench/cifs-2.6 into master
Pull cifs fix from Steve French:
"A fix for a recently discovered regression in rename to older servers
caused by a recent patch"
* tag '5.8-rc6-cifs-fix' of git://git.samba.org/sfrench/cifs-2.6:
Revert "cifs: Fix the target file was deleted when rename failed."
Linus Torvalds [Sat, 25 Jul 2020 18:50:59 +0000 (11:50 -0700)]
Merge git://git./linux/kernel/git/netdev/net into master
Pull networking fixes from David Miller:
1) Fix RCU locaking in iwlwifi, from Johannes Berg.
2) mt76 can access uninitialized NAPI struct, from Felix Fietkau.
3) Fix race in updating pause settings in bnxt_en, from Vasundhara
Volam.
4) Propagate error return properly during unbind failures in ax88172a,
from George Kennedy.
5) Fix memleak in adf7242_probe, from Liu Jian.
6) smc_drv_probe() can leak, from Wang Hai.
7) Don't muck with the carrier state if register_netdevice() fails in
the bonding driver, from Taehee Yoo.
8) Fix memleak in dpaa_eth_probe, from Liu Jian.
9) Need to check skb_put_padto() return value in hsr_fill_tag(), from
Murali Karicheri.
10) Don't lose ionic RSS hash settings across FW update, from Shannon
Nelson.
11) Fix clobbered SKB control block in act_ct, from Wen Xu.
12) Missing newlink in "tx_timeout" sysfs output, from Xiongfeng Wang.
13) IS_UDPLITE cleanup a long time ago, incorrectly handled
transformations involving UDPLITE_RECV_CC. From Miaohe Lin.
14) Unbalanced locking in netdevsim, from Taehee Yoo.
15) Suppress false-positive error messages in qed driver, from Alexander
Lobakin.
16) Out of bounds read in ax25_connect and ax25_sendmsg, from Peilin Ye.
17) Missing SKB release in cxgb4's uld_send(), from Navid Emamdoost.
18) Uninitialized value in geneve_changelink(), from Cong Wang.
19) Fix deadlock in xen-netfront, from Andera Righi.
19) flush_backlog() frees skbs with IRQs disabled, so should use
dev_kfree_skb_irq() instead of kfree_skb(). From Subash Abhinov
Kasiviswanathan.
* git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net: (111 commits)
drivers/net/wan: lapb: Corrected the usage of skb_cow
dev: Defer free of skbs in flush_backlog
qrtr: orphan socket in qrtr_release()
xen-netfront: fix potential deadlock in xennet_remove()
flow_offload: Move rhashtable inclusion to the source file
geneve: fix an uninitialized value in geneve_changelink()
bonding: check return value of register_netdevice() in bond_newlink()
tcp: allow at most one TLP probe per flight
AX.25: Prevent integer overflows in connect and sendmsg
cxgb4: add missing release on skb in uld_send()
net: atlantic: fix PTP on AQC10X
AX.25: Prevent out-of-bounds read in ax25_sendmsg()
sctp: shrink stream outq when fails to do addstream reconf
sctp: shrink stream outq only when new outcnt < old outcnt
AX.25: Fix out-of-bounds read in ax25_connect()
enetc: Remove the mdio bus on PF probe bailout
net: ethernet: ti: add NETIF_F_HW_TC hw feature flag for taprio offload
net: ethernet: ave: Fix error returns in ave_init
drivers/net/wan/x25_asy: Fix to make it work
ipvs: fix the connection sync failed in some cases
...
Atish Patra [Wed, 15 Jul 2020 23:30:09 +0000 (16:30 -0700)]
riscv: Parse all memory blocks to remove unusable memory
Currently, maximum physical memory allowed is equal to -PAGE_OFFSET.
That's why we remove any memory blocks spanning beyond that size. However,
it is done only for memblock containing linux kernel which will not work
if there are multiple memblocks.
Process all memory blocks to figure out how much memory needs to be removed
and remove at the end instead of updating the memblock list in place.
Signed-off-by: Atish Patra <atish.patra@wdc.com>
Signed-off-by: Palmer Dabbelt <palmerdabbelt@google.com>
Atish Patra [Wed, 15 Jul 2020 23:30:08 +0000 (16:30 -0700)]
RISC-V: Do not rely on initrd_start/end computed during early dt parsing
Currently, initrd_start/end are computed during early_init_dt_scan
but used during arch_setup. We will get the following panic if initrd is used
and CONFIG_DEBUG_VIRTUAL is turned on.
[ 0.000000] ------------[ cut here ]------------
[ 0.000000] kernel BUG at arch/riscv/mm/physaddr.c:33!
[ 0.000000] Kernel BUG [#1]
[ 0.000000] Modules linked in:
[ 0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 5.8.0-rc4-00015-ged0b226fed02 #886
[ 0.000000] epc:
ffffffe0002058d2 ra :
ffffffe0000053f0 sp :
ffffffe001001f40
[ 0.000000] gp :
ffffffe00106e250 tp :
ffffffe001009d40 t0 :
ffffffe00107ee28
[ 0.000000] t1 :
0000000000000000 t2 :
ffffffe000a2e880 s0 :
ffffffe001001f50
[ 0.000000] s1 :
ffffffe0001383e8 a0 :
ffffffe00c087e00 a1 :
0000000080200000
[ 0.000000] a2 :
00000000010bf000 a3 :
ffffffe00106f3c8 a4 :
ffffffe0010bf000
[ 0.000000] a5 :
ffffffe000000000 a6 :
0000000000000006 a7 :
0000000000000001
[ 0.000000] s2 :
ffffffe00106f068 s3 :
ffffffe00106f070 s4 :
0000000080200000
[ 0.000000] s5 :
0000000082200000 s6 :
0000000000000000 s7 :
0000000000000000
[ 0.000000] s8 :
0000000080011010 s9 :
0000000080012700 s10:
0000000000000000
[ 0.000000] s11:
0000000000000000 t3 :
000000000001fe30 t4 :
000000000001fe30
[ 0.000000] t5 :
0000000000000000 t6 :
ffffffe00107c471
[ 0.000000] status:
0000000000000100 badaddr:
0000000000000000 cause:
0000000000000003
[ 0.000000] random: get_random_bytes called from print_oops_end_marker+0x22/0x46 with crng_init=0
To avoid the error, initrd_start/end can be computed from phys_initrd_start/size
in setup itself. It also improves the initrd placement by aligning the start
and size with the page size.
Fixes:
76d2a0493a17 ("RISC-V: Init and Halt Code")
Signed-off-by: Atish Patra <atish.patra@wdc.com>
Signed-off-by: Palmer Dabbelt <palmerdabbelt@google.com>
Xie He [Fri, 24 Jul 2020 16:33:47 +0000 (09:33 -0700)]
drivers/net/wan: lapb: Corrected the usage of skb_cow
This patch fixed 2 issues with the usage of skb_cow in LAPB drivers
"lapbether" and "hdlc_x25":
1) After skb_cow fails, kfree_skb should be called to drop a reference
to the skb. But in both drivers, kfree_skb is not called.
2) skb_cow should be called before skb_push so that is can ensure the
safety of skb_push. But in "lapbether", it is incorrectly called after
skb_push.
More details about these 2 issues:
1) The behavior of calling kfree_skb on failure is also the behavior of
netif_rx, which is called by this function with "return netif_rx(skb);".
So this function should follow this behavior, too.
2) In "lapbether", skb_cow is called after skb_push. This results in 2
logical issues:
a) skb_push is not protected by skb_cow;
b) An extra headroom of 1 byte is ensured after skb_push. This extra
headroom has no use in this function. It also has no use in the
upper-layer function that this function passes the skb to
(x25_lapb_receive_frame in net/x25/x25_dev.c).
So logically skb_cow should instead be called before skb_push.
Cc: Eric Dumazet <edumazet@google.com>
Cc: Martin Schiller <ms@dev.tdt.de>
Signed-off-by: Xie He <xie.he.0141@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>