This is a note to let you know that I've just added the patch titled
sctp: do not leak kernel memory to user space
to the 4.15-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
sctp-do-not-leak-kernel-memory-to-user-space.patch
and it can be found in the queue-4.15 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Tue Apr 10 23:19:36 CEST 2018
From: Eric Dumazet <edumazet(a)google.com>
Date: Sat, 7 Apr 2018 17:15:22 -0700
Subject: sctp: do not leak kernel memory to user space
From: Eric Dumazet <edumazet(a)google.com>
[ Upstream commit 6780db244d6b1537d139dea0ec8aad10cf9e4adb ]
syzbot produced a nice report [1]
Issue here is that a recvmmsg() managed to leak 8 bytes of kernel memory
to user space, because sin_zero (padding field) was not properly cleared.
[1]
BUG: KMSAN: uninit-value in copy_to_user include/linux/uaccess.h:184 [inline]
BUG: KMSAN: uninit-value in move_addr_to_user+0x32e/0x530 net/socket.c:227
CPU: 1 PID: 3586 Comm: syzkaller481044 Not tainted 4.16.0+ #82
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:17 [inline]
dump_stack+0x185/0x1d0 lib/dump_stack.c:53
kmsan_report+0x142/0x240 mm/kmsan/kmsan.c:1067
kmsan_internal_check_memory+0x164/0x1d0 mm/kmsan/kmsan.c:1176
kmsan_copy_to_user+0x69/0x160 mm/kmsan/kmsan.c:1199
copy_to_user include/linux/uaccess.h:184 [inline]
move_addr_to_user+0x32e/0x530 net/socket.c:227
___sys_recvmsg+0x4e2/0x810 net/socket.c:2211
__sys_recvmmsg+0x54e/0xdb0 net/socket.c:2313
SYSC_recvmmsg+0x29b/0x3e0 net/socket.c:2394
SyS_recvmmsg+0x76/0xa0 net/socket.c:2378
do_syscall_64+0x309/0x430 arch/x86/entry/common.c:287
entry_SYSCALL_64_after_hwframe+0x3d/0xa2
RIP: 0033:0x4401c9
RSP: 002b:00007ffc56f73098 EFLAGS: 00000217 ORIG_RAX: 000000000000012b
RAX: ffffffffffffffda RBX: 00000000004002c8 RCX: 00000000004401c9
RDX: 0000000000000001 RSI: 0000000020003ac0 RDI: 0000000000000003
RBP: 00000000006ca018 R08: 0000000020003bc0 R09: 0000000000000010
R10: 0000000000000000 R11: 0000000000000217 R12: 0000000000401af0
R13: 0000000000401b80 R14: 0000000000000000 R15: 0000000000000000
Local variable description: ----addr@___sys_recvmsg
Variable was created at:
___sys_recvmsg+0xd5/0x810 net/socket.c:2172
__sys_recvmmsg+0x54e/0xdb0 net/socket.c:2313
Bytes 8-15 of 16 are uninitialized
==================================================================
Kernel panic - not syncing: panic_on_warn set ...
CPU: 1 PID: 3586 Comm: syzkaller481044 Tainted: G B 4.16.0+ #82
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:17 [inline]
dump_stack+0x185/0x1d0 lib/dump_stack.c:53
panic+0x39d/0x940 kernel/panic.c:183
kmsan_report+0x238/0x240 mm/kmsan/kmsan.c:1083
kmsan_internal_check_memory+0x164/0x1d0 mm/kmsan/kmsan.c:1176
kmsan_copy_to_user+0x69/0x160 mm/kmsan/kmsan.c:1199
copy_to_user include/linux/uaccess.h:184 [inline]
move_addr_to_user+0x32e/0x530 net/socket.c:227
___sys_recvmsg+0x4e2/0x810 net/socket.c:2211
__sys_recvmmsg+0x54e/0xdb0 net/socket.c:2313
SYSC_recvmmsg+0x29b/0x3e0 net/socket.c:2394
SyS_recvmmsg+0x76/0xa0 net/socket.c:2378
do_syscall_64+0x309/0x430 arch/x86/entry/common.c:287
entry_SYSCALL_64_after_hwframe+0x3d/0xa2
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Signed-off-by: Eric Dumazet <edumazet(a)google.com>
Cc: Vlad Yasevich <vyasevich(a)gmail.com>
Cc: Neil Horman <nhorman(a)tuxdriver.com>
Reported-by: syzbot <syzkaller(a)googlegroups.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/sctp/ipv6.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
--- a/net/sctp/ipv6.c
+++ b/net/sctp/ipv6.c
@@ -728,8 +728,10 @@ static int sctp_v6_addr_to_user(struct s
sctp_v6_map_v4(addr);
}
- if (addr->sa.sa_family == AF_INET)
+ if (addr->sa.sa_family == AF_INET) {
+ memset(addr->v4.sin_zero, 0, sizeof(addr->v4.sin_zero));
return sizeof(struct sockaddr_in);
+ }
return sizeof(struct sockaddr_in6);
}
Patches currently in stable-queue which might be from edumazet(a)google.com are
queue-4.15/sctp-sctp_sockaddr_af-must-check-minimal-addr-length-for-af_inet6.patch
queue-4.15/net-fix-possible-out-of-bound-read-in-skb_network_protocol.patch
queue-4.15/pptp-remove-a-buggy-dst-release-in-pptp_connect.patch
queue-4.15/net-fool-proof-dev_valid_name.patch
queue-4.15/ipv6-the-entire-ipv6-header-chain-must-fit-the-first-fragment.patch
queue-4.15/vti6-better-validate-user-provided-tunnel-names.patch
queue-4.15/ipv6-sit-better-validate-user-provided-tunnel-names.patch
queue-4.15/ip6_tunnel-better-validate-user-provided-tunnel-names.patch
queue-4.15/sctp-do-not-leak-kernel-memory-to-user-space.patch
queue-4.15/ip_tunnel-better-validate-user-provided-tunnel-names.patch
queue-4.15/netlink-make-sure-nladdr-has-correct-size-in-netlink_connect.patch
queue-4.15/ip6_gre-better-validate-user-provided-tunnel-names.patch
This is a note to let you know that I've just added the patch titled
route: check sysctl_fib_multipath_use_neigh earlier than hash
to the 4.15-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
route-check-sysctl_fib_multipath_use_neigh-earlier-than-hash.patch
and it can be found in the queue-4.15 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Tue Apr 10 23:19:36 CEST 2018
From: Xin Long <lucien.xin(a)gmail.com>
Date: Sun, 1 Apr 2018 22:40:35 +0800
Subject: route: check sysctl_fib_multipath_use_neigh earlier than hash
From: Xin Long <lucien.xin(a)gmail.com>
[ Upstream commit 6174a30df1b902e1fedbd728f5343937e83e64e6 ]
Prior to this patch, when one packet is hashed into path [1]
(hash <= nh_upper_bound) and it's neigh is dead, it will try
path [2]. However, if path [2]'s neigh is alive but it's
hash > nh_upper_bound, it will not return this alive path.
This packet will never be sent even if path [2] is alive.
3.3.3.1/24:
nexthop via 1.1.1.254 dev eth1 weight 1 <--[1] (dead neigh)
nexthop via 2.2.2.254 dev eth2 weight 1 <--[2]
With sysctl_fib_multipath_use_neigh set is supposed to find an
available path respecting to the l3/l4 hash. But if there is
no available route with this hash, it should at least return
an alive route even with other hash.
This patch is to fix it by processing fib_multipath_use_neigh
earlier than the hash check, so that it will at least return
an alive route if there is when fib_multipath_use_neigh is
enabled. It's also compatible with before when there are alive
routes with the l3/l4 hash.
Fixes: a6db4494d218 ("net: ipv4: Consider failed nexthops in multipath routes")
Reported-by: Jianlin Shi <jishi(a)redhat.com>
Signed-off-by: Xin Long <lucien.xin(a)gmail.com>
Acked-by: David Ahern <dsa(a)cumulusnetworks.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/ipv4/fib_semantics.c | 20 +++++++++++---------
1 file changed, 11 insertions(+), 9 deletions(-)
--- a/net/ipv4/fib_semantics.c
+++ b/net/ipv4/fib_semantics.c
@@ -1746,18 +1746,20 @@ void fib_select_multipath(struct fib_res
bool first = false;
for_nexthops(fi) {
+ if (net->ipv4.sysctl_fib_multipath_use_neigh) {
+ if (!fib_good_nh(nh))
+ continue;
+ if (!first) {
+ res->nh_sel = nhsel;
+ first = true;
+ }
+ }
+
if (hash > atomic_read(&nh->nh_upper_bound))
continue;
- if (!net->ipv4.sysctl_fib_multipath_use_neigh ||
- fib_good_nh(nh)) {
- res->nh_sel = nhsel;
- return;
- }
- if (!first) {
- res->nh_sel = nhsel;
- first = true;
- }
+ res->nh_sel = nhsel;
+ return;
} endfor_nexthops(fi);
}
#endif
Patches currently in stable-queue which might be from lucien.xin(a)gmail.com are
queue-4.15/team-move-dev_mc_sync-after-master_upper_dev_link-in-team_port_add.patch
queue-4.15/bonding-process-the-err-returned-by-dev_set_allmulti-properly-in-bond_enslave.patch
queue-4.15/bonding-fix-the-err-path-for-dev-hwaddr-sync-in-bond_enslave.patch
queue-4.15/bonding-move-dev_mc_sync-after-master_upper_dev_link-in-bond_enslave.patch
queue-4.15/route-check-sysctl_fib_multipath_use_neigh-earlier-than-hash.patch
This is a note to let you know that I've just added the patch titled
r8169: fix setting driver_data after register_netdev
to the 4.15-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
r8169-fix-setting-driver_data-after-register_netdev.patch
and it can be found in the queue-4.15 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Tue Apr 10 23:19:36 CEST 2018
From: Heiner Kallweit <hkallweit1(a)gmail.com>
Date: Mon, 26 Mar 2018 19:19:30 +0200
Subject: r8169: fix setting driver_data after register_netdev
From: Heiner Kallweit <hkallweit1(a)gmail.com>
[ Upstream commit 19c9ea363a244f85f90a424f9936e6d56449e33c ]
pci_set_drvdata() is called only after registering the net_device,
therefore we could run into a NPE if one of the functions using
driver_data is called before it's set.
Fix this by calling pci_set_drvdata() before registering the
net_device.
This fix is a candidate for stable. As far as I can see the
bug has been there in kernel version 3.2 already, therefore
I can't provide a reference which commit is fixed by it.
The fix may need small adjustments per kernel version because
due to other changes the label which is jumped to if
register_netdev() fails has changed over time.
Reported-by: David Miller <davem(a)davemloft.net>
Signed-off-by: Heiner Kallweit <hkallweit1(a)gmail.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/ethernet/realtek/r8169.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/drivers/net/ethernet/realtek/r8169.c
+++ b/drivers/net/ethernet/realtek/r8169.c
@@ -8699,12 +8699,12 @@ static int rtl_init_one(struct pci_dev *
goto err_out_msi_5;
}
+ pci_set_drvdata(pdev, dev);
+
rc = register_netdev(dev);
if (rc < 0)
goto err_out_cnt_6;
- pci_set_drvdata(pdev, dev);
-
netif_info(tp, probe, dev, "%s at 0x%p, %pM, XID %08x IRQ %d\n",
rtl_chip_infos[chipset].name, ioaddr, dev->dev_addr,
(u32)(RTL_R32(TxConfig) & 0x9cf0f8ff), pdev->irq);
Patches currently in stable-queue which might be from hkallweit1(a)gmail.com are
queue-4.15/r8169-fix-setting-driver_data-after-register_netdev.patch
This is a note to let you know that I've just added the patch titled
pptp: remove a buggy dst release in pptp_connect()
to the 4.15-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
pptp-remove-a-buggy-dst-release-in-pptp_connect.patch
and it can be found in the queue-4.15 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Tue Apr 10 23:19:36 CEST 2018
From: Eric Dumazet <edumazet(a)google.com>
Date: Mon, 2 Apr 2018 18:48:37 -0700
Subject: pptp: remove a buggy dst release in pptp_connect()
From: Eric Dumazet <edumazet(a)google.com>
[ Upstream commit bfacfb457b36911a10140b8cb3ce76a74883ac5a ]
Once dst has been cached in socket via sk_setup_caps(),
it is illegal to call ip_rt_put() (or dst_release()),
since sk_setup_caps() did not change dst refcount.
We can still dereference it since we hold socket lock.
Caugth by syzbot :
BUG: KASAN: use-after-free in atomic_dec_return include/asm-generic/atomic-instrumented.h:198 [inline]
BUG: KASAN: use-after-free in dst_release+0x27/0xa0 net/core/dst.c:185
Write of size 4 at addr ffff8801c54dc040 by task syz-executor4/20088
CPU: 1 PID: 20088 Comm: syz-executor4 Not tainted 4.16.0+ #376
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:17 [inline]
dump_stack+0x1a7/0x27d lib/dump_stack.c:53
print_address_description+0x73/0x250 mm/kasan/report.c:256
kasan_report_error mm/kasan/report.c:354 [inline]
kasan_report+0x23c/0x360 mm/kasan/report.c:412
check_memory_region_inline mm/kasan/kasan.c:260 [inline]
check_memory_region+0x137/0x190 mm/kasan/kasan.c:267
kasan_check_write+0x14/0x20 mm/kasan/kasan.c:278
atomic_dec_return include/asm-generic/atomic-instrumented.h:198 [inline]
dst_release+0x27/0xa0 net/core/dst.c:185
sk_dst_set include/net/sock.h:1812 [inline]
sk_dst_reset include/net/sock.h:1824 [inline]
sock_setbindtodevice net/core/sock.c:610 [inline]
sock_setsockopt+0x431/0x1b20 net/core/sock.c:707
SYSC_setsockopt net/socket.c:1845 [inline]
SyS_setsockopt+0x2ff/0x360 net/socket.c:1828
do_syscall_64+0x281/0x940 arch/x86/entry/common.c:287
entry_SYSCALL_64_after_hwframe+0x42/0xb7
RIP: 0033:0x4552d9
RSP: 002b:00007f4878126c68 EFLAGS: 00000246 ORIG_RAX: 0000000000000036
RAX: ffffffffffffffda RBX: 00007f48781276d4 RCX: 00000000004552d9
RDX: 0000000000000019 RSI: 0000000000000001 RDI: 0000000000000013
RBP: 000000000072bea0 R08: 0000000000000010 R09: 0000000000000000
R10: 00000000200010c0 R11: 0000000000000246 R12: 00000000ffffffff
R13: 0000000000000526 R14: 00000000006fac30 R15: 0000000000000000
Allocated by task 20088:
save_stack+0x43/0xd0 mm/kasan/kasan.c:447
set_track mm/kasan/kasan.c:459 [inline]
kasan_kmalloc+0xad/0xe0 mm/kasan/kasan.c:552
kasan_slab_alloc+0x12/0x20 mm/kasan/kasan.c:489
kmem_cache_alloc+0x12e/0x760 mm/slab.c:3542
dst_alloc+0x11f/0x1a0 net/core/dst.c:104
rt_dst_alloc+0xe9/0x540 net/ipv4/route.c:1520
__mkroute_output net/ipv4/route.c:2265 [inline]
ip_route_output_key_hash_rcu+0xa49/0x2c60 net/ipv4/route.c:2493
ip_route_output_key_hash+0x20b/0x370 net/ipv4/route.c:2322
__ip_route_output_key include/net/route.h:126 [inline]
ip_route_output_flow+0x26/0xa0 net/ipv4/route.c:2577
ip_route_output_ports include/net/route.h:163 [inline]
pptp_connect+0xa84/0x1170 drivers/net/ppp/pptp.c:453
SYSC_connect+0x213/0x4a0 net/socket.c:1639
SyS_connect+0x24/0x30 net/socket.c:1620
do_syscall_64+0x281/0x940 arch/x86/entry/common.c:287
entry_SYSCALL_64_after_hwframe+0x42/0xb7
Freed by task 20082:
save_stack+0x43/0xd0 mm/kasan/kasan.c:447
set_track mm/kasan/kasan.c:459 [inline]
__kasan_slab_free+0x11a/0x170 mm/kasan/kasan.c:520
kasan_slab_free+0xe/0x10 mm/kasan/kasan.c:527
__cache_free mm/slab.c:3486 [inline]
kmem_cache_free+0x83/0x2a0 mm/slab.c:3744
dst_destroy+0x266/0x380 net/core/dst.c:140
dst_destroy_rcu+0x16/0x20 net/core/dst.c:153
__rcu_reclaim kernel/rcu/rcu.h:178 [inline]
rcu_do_batch kernel/rcu/tree.c:2675 [inline]
invoke_rcu_callbacks kernel/rcu/tree.c:2930 [inline]
__rcu_process_callbacks kernel/rcu/tree.c:2897 [inline]
rcu_process_callbacks+0xd6c/0x17b0 kernel/rcu/tree.c:2914
__do_softirq+0x2d7/0xb85 kernel/softirq.c:285
The buggy address belongs to the object at ffff8801c54dc000
which belongs to the cache ip_dst_cache of size 168
The buggy address is located 64 bytes inside of
168-byte region [ffff8801c54dc000, ffff8801c54dc0a8)
The buggy address belongs to the page:
page:ffffea0007153700 count:1 mapcount:0 mapping:ffff8801c54dc000 index:0x0
flags: 0x2fffc0000000100(slab)
raw: 02fffc0000000100 ffff8801c54dc000 0000000000000000 0000000100000010
raw: ffffea0006b34b20 ffffea0006b6c1e0 ffff8801d674a1c0 0000000000000000
page dumped because: kasan: bad access detected
Signed-off-by: Eric Dumazet <edumazet(a)google.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/ppp/pptp.c | 1 -
1 file changed, 1 deletion(-)
--- a/drivers/net/ppp/pptp.c
+++ b/drivers/net/ppp/pptp.c
@@ -464,7 +464,6 @@ static int pptp_connect(struct socket *s
po->chan.mtu = dst_mtu(&rt->dst);
if (!po->chan.mtu)
po->chan.mtu = PPP_MRU;
- ip_rt_put(rt);
po->chan.mtu -= PPTP_HEADER_OVERHEAD;
po->chan.hdrlen = 2 + sizeof(struct pptp_gre_header);
Patches currently in stable-queue which might be from edumazet(a)google.com are
queue-4.15/sctp-sctp_sockaddr_af-must-check-minimal-addr-length-for-af_inet6.patch
queue-4.15/net-fix-possible-out-of-bound-read-in-skb_network_protocol.patch
queue-4.15/pptp-remove-a-buggy-dst-release-in-pptp_connect.patch
queue-4.15/net-fool-proof-dev_valid_name.patch
queue-4.15/ipv6-the-entire-ipv6-header-chain-must-fit-the-first-fragment.patch
queue-4.15/vti6-better-validate-user-provided-tunnel-names.patch
queue-4.15/ipv6-sit-better-validate-user-provided-tunnel-names.patch
queue-4.15/ip6_tunnel-better-validate-user-provided-tunnel-names.patch
queue-4.15/sctp-do-not-leak-kernel-memory-to-user-space.patch
queue-4.15/ip_tunnel-better-validate-user-provided-tunnel-names.patch
queue-4.15/netlink-make-sure-nladdr-has-correct-size-in-netlink_connect.patch
queue-4.15/ip6_gre-better-validate-user-provided-tunnel-names.patch
This is a note to let you know that I've just added the patch titled
nfp: use full 40 bits of the NSP buffer address
to the 4.15-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
nfp-use-full-40-bits-of-the-nsp-buffer-address.patch
and it can be found in the queue-4.15 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Tue Apr 10 23:19:36 CEST 2018
From: Dirk van der Merwe <dirk.vandermerwe(a)netronome.com>
Date: Tue, 3 Apr 2018 17:24:23 -0700
Subject: nfp: use full 40 bits of the NSP buffer address
From: Dirk van der Merwe <dirk.vandermerwe(a)netronome.com>
[ Upstream commit 1489bbd10e16079ce30a53d3c22a431fd47af791 ]
The NSP default buffer is a piece of NFP memory where additional
command data can be placed. Its format has been copied from
host buffer, but the PCIe selection bits do not make sense in
this case. If those get masked out from a NFP address - writes
to random place in the chip memory may be issued and crash the
device.
Even in the general NSP buffer case, it doesn't make sense to have the
PCIe selection bits there anymore. These are unused at the moment, and
when it becomes necessary, the PCIe selection bits should rather be
moved to another register to utilise more bits for the buffer address.
This has never been an issue because the buffer used to be
allocated in memory with less-than-38-bit-long address but that
is about to change.
Fixes: 1a64821c6af7 ("nfp: add support for service processor access")
Signed-off-by: Dirk van der Merwe <dirk.vandermerwe(a)netronome.com>
Reviewed-by: Jakub Kicinski <jakub.kicinski(a)netronome.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/ethernet/netronome/nfp/nfpcore/nfp_nsp.c | 9 +++++----
1 file changed, 5 insertions(+), 4 deletions(-)
--- a/drivers/net/ethernet/netronome/nfp/nfpcore/nfp_nsp.c
+++ b/drivers/net/ethernet/netronome/nfp/nfpcore/nfp_nsp.c
@@ -68,10 +68,11 @@
/* CPP address to retrieve the data from */
#define NSP_BUFFER 0x10
#define NSP_BUFFER_CPP GENMASK_ULL(63, 40)
-#define NSP_BUFFER_PCIE GENMASK_ULL(39, 38)
-#define NSP_BUFFER_ADDRESS GENMASK_ULL(37, 0)
+#define NSP_BUFFER_ADDRESS GENMASK_ULL(39, 0)
#define NSP_DFLT_BUFFER 0x18
+#define NSP_DFLT_BUFFER_CPP GENMASK_ULL(63, 40)
+#define NSP_DFLT_BUFFER_ADDRESS GENMASK_ULL(39, 0)
#define NSP_DFLT_BUFFER_CONFIG 0x20
#define NSP_DFLT_BUFFER_SIZE_MB GENMASK_ULL(7, 0)
@@ -412,8 +413,8 @@ static int nfp_nsp_command_buf(struct nf
if (err < 0)
return err;
- cpp_id = FIELD_GET(NSP_BUFFER_CPP, reg) << 8;
- cpp_buf = FIELD_GET(NSP_BUFFER_ADDRESS, reg);
+ cpp_id = FIELD_GET(NSP_DFLT_BUFFER_CPP, reg) << 8;
+ cpp_buf = FIELD_GET(NSP_DFLT_BUFFER_ADDRESS, reg);
if (in_buf && in_size) {
err = nfp_cpp_write(cpp, cpp_id, cpp_buf, in_buf, in_size);
Patches currently in stable-queue which might be from dirk.vandermerwe(a)netronome.com are
queue-4.15/nfp-use-full-40-bits-of-the-nsp-buffer-address.patch
This is a note to let you know that I've just added the patch titled
netlink: make sure nladdr has correct size in netlink_connect()
to the 4.15-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
netlink-make-sure-nladdr-has-correct-size-in-netlink_connect.patch
and it can be found in the queue-4.15 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Tue Apr 10 23:19:36 CEST 2018
From: Alexander Potapenko <glider(a)google.com>
Date: Fri, 23 Mar 2018 13:49:02 +0100
Subject: netlink: make sure nladdr has correct size in netlink_connect()
From: Alexander Potapenko <glider(a)google.com>
[ Upstream commit 7880287981b60a6808f39f297bb66936e8bdf57a ]
KMSAN reports use of uninitialized memory in the case when |alen| is
smaller than sizeof(struct sockaddr_nl), and therefore |nladdr| isn't
fully copied from the userspace.
Signed-off-by: Alexander Potapenko <glider(a)google.com>
Fixes: 1da177e4c3f41524 ("Linux-2.6.12-rc2")
Reviewed-by: Eric Dumazet <edumazet(a)google.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/netlink/af_netlink.c | 3 +++
1 file changed, 3 insertions(+)
--- a/net/netlink/af_netlink.c
+++ b/net/netlink/af_netlink.c
@@ -1052,6 +1052,9 @@ static int netlink_connect(struct socket
if (addr->sa_family != AF_NETLINK)
return -EINVAL;
+ if (alen < sizeof(struct sockaddr_nl))
+ return -EINVAL;
+
if ((nladdr->nl_groups || nladdr->nl_pid) &&
!netlink_allowed(sock, NL_CFG_F_NONROOT_SEND))
return -EPERM;
Patches currently in stable-queue which might be from glider(a)google.com are
queue-4.15/netlink-make-sure-nladdr-has-correct-size-in-netlink_connect.patch
This is a note to let you know that I've just added the patch titled
net_sched: fix a missing idr_remove() in u32_delete_key()
to the 4.15-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
net_sched-fix-a-missing-idr_remove-in-u32_delete_key.patch
and it can be found in the queue-4.15 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Tue Apr 10 23:19:36 CEST 2018
From: Cong Wang <xiyou.wangcong(a)gmail.com>
Date: Fri, 6 Apr 2018 17:19:41 -0700
Subject: net_sched: fix a missing idr_remove() in u32_delete_key()
From: Cong Wang <xiyou.wangcong(a)gmail.com>
[ Upstream commit f12c643209db0626f2f54780d86bb93bfa7a9c2d ]
When we delete a u32 key via u32_delete_key(), we forget to
call idr_remove() to remove its handle from IDR.
Fixes: e7614370d6f0 ("net_sched: use idr to allocate u32 filter handles")
Reported-by: Marcin Kabiesz <admin(a)hostcenter.eu>
Tested-by: Marcin Kabiesz <admin(a)hostcenter.eu>
Signed-off-by: Cong Wang <xiyou.wangcong(a)gmail.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/sched/cls_u32.c | 1 +
1 file changed, 1 insertion(+)
--- a/net/sched/cls_u32.c
+++ b/net/sched/cls_u32.c
@@ -478,6 +478,7 @@ static int u32_delete_key(struct tcf_pro
RCU_INIT_POINTER(*kp, key->next);
tcf_unbind_filter(tp, &key->res);
+ idr_remove(&ht->handle_idr, key->handle);
tcf_exts_get_net(&key->exts);
call_rcu(&key->rcu, u32_delete_key_freepf_rcu);
return 0;
Patches currently in stable-queue which might be from xiyou.wangcong(a)gmail.com are
queue-4.15/net_sched-fix-a-missing-idr_remove-in-u32_delete_key.patch
This is a note to let you know that I've just added the patch titled
net sched actions: fix dumping which requires several messages to user space
to the 4.15-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
net-sched-actions-fix-dumping-which-requires-several-messages-to-user-space.patch
and it can be found in the queue-4.15 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Tue Apr 10 23:19:36 CEST 2018
From: Craig Dillabaugh <cdillaba(a)mojatatu.com>
Date: Mon, 26 Mar 2018 14:58:32 -0400
Subject: net sched actions: fix dumping which requires several messages to user space
From: Craig Dillabaugh <cdillaba(a)mojatatu.com>
[ Upstream commit 734549eb550c0c720bc89e50501f1b1e98cdd841 ]
Fixes a bug in the tcf_dump_walker function that can cause some actions
to not be reported when dumping a large number of actions. This issue
became more aggrevated when cookies feature was added. In particular
this issue is manifest when large cookie values are assigned to the
actions and when enough actions are created that the resulting table
must be dumped in multiple batches.
The number of actions returned in each batch is limited by the total
number of actions and the memory buffer size. With small cookies
the numeric limit is reached before the buffer size limit, which avoids
the code path triggering this bug. When large cookies are used buffer
fills before the numeric limit, and the erroneous code path is hit.
For example after creating 32 csum actions with the cookie
aaaabbbbccccdddd
$ tc actions ls action csum
total acts 26
action order 0: csum (tcp) action continue
index 1 ref 1 bind 0
cookie aaaabbbbccccdddd
.....
action order 25: csum (tcp) action continue
index 26 ref 1 bind 0
cookie aaaabbbbccccdddd
total acts 6
action order 0: csum (tcp) action continue
index 28 ref 1 bind 0
cookie aaaabbbbccccdddd
......
action order 5: csum (tcp) action continue
index 32 ref 1 bind 0
cookie aaaabbbbccccdddd
Note that the action with index 27 is omitted from the report.
Fixes: 4b3550ef530c ("[NET_SCHED]: Use nla_nest_start/nla_nest_end")"
Signed-off-by: Craig Dillabaugh <cdillaba(a)mojatatu.com>
Acked-by: Jamal Hadi Salim <jhs(a)mojatatu.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/sched/act_api.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
--- a/net/sched/act_api.c
+++ b/net/sched/act_api.c
@@ -135,8 +135,10 @@ static int tcf_dump_walker(struct tcf_id
continue;
nest = nla_nest_start(skb, n_i);
- if (!nest)
+ if (!nest) {
+ index--;
goto nla_put_failure;
+ }
err = tcf_action_dump_1(skb, p, 0, 0);
if (err < 0) {
index--;
Patches currently in stable-queue which might be from cdillaba(a)mojatatu.com are
queue-4.15/net-sched-actions-fix-dumping-which-requires-several-messages-to-user-space.patch
This is a note to let you know that I've just added the patch titled
net/mlx5e: Sync netdev vxlan ports at open
to the 4.15-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
net-mlx5e-sync-netdev-vxlan-ports-at-open.patch
and it can be found in the queue-4.15 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Tue Apr 10 23:19:36 CEST 2018
From: Shahar Klein <shahark(a)mellanox.com>
Date: Tue, 20 Mar 2018 14:44:40 +0200
Subject: net/mlx5e: Sync netdev vxlan ports at open
From: Shahar Klein <shahark(a)mellanox.com>
[ Upstream commit a117f73dc2430443f23e18367fa545981129c1a6 ]
When mlx5_core is loaded it is expected to sync ports
with all vxlan devices so it can support vxlan encap/decap.
This is done via udp_tunnel_get_rx_info(). Currently this
call is set in mlx5e_nic_enable() and if the netdev is not in
NETREG_REGISTERED state it will not be called.
Normally on load the netdev state is not NETREG_REGISTERED
so udp_tunnel_get_rx_info() will not be called.
Moving udp_tunnel_get_rx_info() to mlx5e_open() so
it will be called on netdev UP event and allow encap/decap.
Fixes: 610e89e05c3f ("net/mlx5e: Don't sync netdev state when not registered")
Signed-off-by: Shahar Klein <shahark(a)mellanox.com>
Reviewed-by: Roi Dayan <roid(a)mellanox.com>
Signed-off-by: Saeed Mahameed <saeedm(a)mellanox.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/ethernet/mellanox/mlx5/core/en_main.c | 9 +++------
1 file changed, 3 insertions(+), 6 deletions(-)
--- a/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
@@ -2715,6 +2715,9 @@ int mlx5e_open(struct net_device *netdev
mlx5_set_port_admin_status(priv->mdev, MLX5_PORT_UP);
mutex_unlock(&priv->state_lock);
+ if (mlx5e_vxlan_allowed(priv->mdev))
+ udp_tunnel_get_rx_info(netdev);
+
return err;
}
@@ -4428,12 +4431,6 @@ static void mlx5e_nic_enable(struct mlx5
#ifdef CONFIG_MLX5_CORE_EN_DCB
mlx5e_dcbnl_init_app(priv);
#endif
- /* Device already registered: sync netdev system state */
- if (mlx5e_vxlan_allowed(mdev)) {
- rtnl_lock();
- udp_tunnel_get_rx_info(netdev);
- rtnl_unlock();
- }
queue_work(priv->wq, &priv->set_rx_mode_work);
Patches currently in stable-queue which might be from shahark(a)mellanox.com are
queue-4.15/net-mlx5e-sync-netdev-vxlan-ports-at-open.patch
This is a note to let you know that I've just added the patch titled
net/mlx5e: Verify coalescing parameters in range
to the 4.15-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
net-mlx5e-verify-coalescing-parameters-in-range.patch
and it can be found in the queue-4.15 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Tue Apr 10 23:19:36 CEST 2018
From: Moshe Shemesh <moshe(a)mellanox.com>
Date: Thu, 15 Feb 2018 12:41:48 +0200
Subject: net/mlx5e: Verify coalescing parameters in range
From: Moshe Shemesh <moshe(a)mellanox.com>
[ Upstream commit b392a2078b5e0094ff38aa0c9d2a31b3f607d4ef ]
Add check of coalescing parameters received through ethtool are within
range of values supported by the HW.
Driver gets the coalescing rx/tx-usecs and rx/tx-frames as set by the
users through ethtool. The ethtool support up to 32 bit value for each.
However, mlx5 modify cq limits the coalescing time parameter to 12 bit
and coalescing frames parameters to 16 bits.
Return out of range error if user tries to set these parameters to
higher values.
Fixes: f62b8bb8f2d3 ('net/mlx5: Extend mlx5_core to support ConnectX-4 Ethernet functionality')
Signed-off-by: Moshe Shemesh <moshe(a)mellanox.com>
Signed-off-by: Saeed Mahameed <saeedm(a)mellanox.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/ethernet/mellanox/mlx5/core/en_ethtool.c | 17 +++++++++++++++++
1 file changed, 17 insertions(+)
--- a/drivers/net/ethernet/mellanox/mlx5/core/en_ethtool.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en_ethtool.c
@@ -492,6 +492,9 @@ static int mlx5e_get_coalesce(struct net
return mlx5e_ethtool_get_coalesce(priv, coal);
}
+#define MLX5E_MAX_COAL_TIME MLX5_MAX_CQ_PERIOD
+#define MLX5E_MAX_COAL_FRAMES MLX5_MAX_CQ_COUNT
+
static void
mlx5e_set_priv_channels_coalesce(struct mlx5e_priv *priv, struct ethtool_coalesce *coal)
{
@@ -526,6 +529,20 @@ int mlx5e_ethtool_set_coalesce(struct ml
if (!MLX5_CAP_GEN(mdev, cq_moderation))
return -EOPNOTSUPP;
+ if (coal->tx_coalesce_usecs > MLX5E_MAX_COAL_TIME ||
+ coal->rx_coalesce_usecs > MLX5E_MAX_COAL_TIME) {
+ netdev_info(priv->netdev, "%s: maximum coalesce time supported is %lu usecs\n",
+ __func__, MLX5E_MAX_COAL_TIME);
+ return -ERANGE;
+ }
+
+ if (coal->tx_max_coalesced_frames > MLX5E_MAX_COAL_FRAMES ||
+ coal->rx_max_coalesced_frames > MLX5E_MAX_COAL_FRAMES) {
+ netdev_info(priv->netdev, "%s: maximum coalesced frames supported is %lu\n",
+ __func__, MLX5E_MAX_COAL_FRAMES);
+ return -ERANGE;
+ }
+
mutex_lock(&priv->state_lock);
new_channels.params = priv->channels.params;
Patches currently in stable-queue which might be from moshe(a)mellanox.com are
queue-4.15/net-mlx4_core-fix-memory-leak-while-delete-slave-s-resources.patch
queue-4.15/net-mlx5e-verify-coalescing-parameters-in-range.patch
This is a note to let you know that I've just added the patch titled
net/mlx5e: Set EQE based as default TX interrupt moderation mode
to the 4.15-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
net-mlx5e-set-eqe-based-as-default-tx-interrupt-moderation-mode.patch
and it can be found in the queue-4.15 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Tue Apr 10 23:19:36 CEST 2018
From: Tal Gilboa <talgi(a)mellanox.com>
Date: Fri, 30 Mar 2018 15:50:08 -0700
Subject: net/mlx5e: Set EQE based as default TX interrupt moderation mode
From: Tal Gilboa <talgi(a)mellanox.com>
[ Upstream commit 48bfc39791b8b4a25f165e711f18b9c1617cefbc ]
The default TX moderation mode was mistakenly set to CQE based. The
intention was to add a control ability in order to improve some specific
use-cases. In general, we prefer to use EQE based moderation as it gives
much better numbers for the common cases.
CQE based causes a degradation in the common case since it resets the
moderation timer on CQE generation. This causes an issue when TSO is
well utilized (large TSO sessions). The timer is set to 16us so traffic
of ~64KB TSO sessions per second would mean timer reset (CQE per TSO
session -> long time between CQEs). In this case we quickly reach the
tcp_limit_output_bytes (256KB by default) and cause a halt in TX traffic.
By setting EQE based moderation we make sure timer would expire after
16us regardless of the packet rate.
This fixes an up to 40% packet rate and up to 23% bandwidth degradtions.
Fixes: 0088cbbc4b66 ("net/mlx5e: Enable CQE based moderation on TX CQ")
Signed-off-by: Tal Gilboa <talgi(a)mellanox.com>
Signed-off-by: Saeed Mahameed <saeedm(a)mellanox.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/ethernet/mellanox/mlx5/core/en_main.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
--- a/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
@@ -4075,7 +4075,7 @@ void mlx5e_build_nic_params(struct mlx5_
struct mlx5e_params *params,
u16 max_channels)
{
- u8 cq_period_mode = 0;
+ u8 rx_cq_period_mode;
u32 link_speed = 0;
u32 pci_bw = 0;
@@ -4111,12 +4111,12 @@ void mlx5e_build_nic_params(struct mlx5_
params->lro_timeout = mlx5e_choose_lro_timeout(mdev, MLX5E_DEFAULT_LRO_TIMEOUT);
/* CQ moderation params */
- cq_period_mode = MLX5_CAP_GEN(mdev, cq_period_start_from_cqe) ?
+ rx_cq_period_mode = MLX5_CAP_GEN(mdev, cq_period_start_from_cqe) ?
MLX5_CQ_PERIOD_MODE_START_FROM_CQE :
MLX5_CQ_PERIOD_MODE_START_FROM_EQE;
params->rx_am_enabled = MLX5_CAP_GEN(mdev, cq_moderation);
- mlx5e_set_rx_cq_mode_params(params, cq_period_mode);
- mlx5e_set_tx_cq_mode_params(params, cq_period_mode);
+ mlx5e_set_rx_cq_mode_params(params, rx_cq_period_mode);
+ mlx5e_set_tx_cq_mode_params(params, MLX5_CQ_PERIOD_MODE_START_FROM_EQE);
/* TX inline */
params->tx_max_inline = mlx5e_get_max_inline_cap(mdev);
Patches currently in stable-queue which might be from talgi(a)mellanox.com are
queue-4.15/net-mlx5e-set-eqe-based-as-default-tx-interrupt-moderation-mode.patch
This is a note to let you know that I've just added the patch titled
net/mlx5e: Fix traffic being dropped on VF representor
to the 4.15-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
net-mlx5e-fix-traffic-being-dropped-on-vf-representor.patch
and it can be found in the queue-4.15 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Tue Apr 10 23:19:36 CEST 2018
From: Roi Dayan <roid(a)mellanox.com>
Date: Wed, 28 Feb 2018 12:56:42 +0200
Subject: net/mlx5e: Fix traffic being dropped on VF representor
From: Roi Dayan <roid(a)mellanox.com>
[ Upstream commit 4246f698dd58e3c6246fa919ef0b0a1d29a57e4a ]
Increase representor netdev RQ size to avoid dropped packets.
The current size (two) is just too small to keep up with
conventional slow path traffic patterns.
Also match the SQ size to the RQ size.
Fixes: cb67b832921c ("net/mlx5e: Introduce SRIOV VF representors")
Signed-off-by: Roi Dayan <roid(a)mellanox.com>
Reviewed-by: Paul Blakey <paulb(a)mellanox.com>
Reviewed-by: Or Gerlitz <ogerlitz(a)mellanox.com>
Signed-off-by: Saeed Mahameed <saeedm(a)mellanox.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/ethernet/mellanox/mlx5/core/en_rep.c | 9 +++++++--
1 file changed, 7 insertions(+), 2 deletions(-)
--- a/drivers/net/ethernet/mellanox/mlx5/core/en_rep.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en_rep.c
@@ -44,6 +44,11 @@
#include "en_tc.h"
#include "fs_core.h"
+#define MLX5E_REP_PARAMS_LOG_SQ_SIZE \
+ max(0x6, MLX5E_PARAMS_MINIMUM_LOG_SQ_SIZE)
+#define MLX5E_REP_PARAMS_LOG_RQ_SIZE \
+ max(0x6, MLX5E_PARAMS_MINIMUM_LOG_RQ_SIZE)
+
static const char mlx5e_rep_driver_name[] = "mlx5e_rep";
static void mlx5e_rep_get_drvinfo(struct net_device *dev,
@@ -824,9 +829,9 @@ static void mlx5e_build_rep_params(struc
MLX5_CQ_PERIOD_MODE_START_FROM_CQE :
MLX5_CQ_PERIOD_MODE_START_FROM_EQE;
- params->log_sq_size = MLX5E_PARAMS_MINIMUM_LOG_SQ_SIZE;
+ params->log_sq_size = MLX5E_REP_PARAMS_LOG_SQ_SIZE;
params->rq_wq_type = MLX5_WQ_TYPE_LINKED_LIST;
- params->log_rq_size = MLX5E_PARAMS_MINIMUM_LOG_RQ_SIZE;
+ params->log_rq_size = MLX5E_REP_PARAMS_LOG_RQ_SIZE;
params->rx_am_enabled = MLX5_CAP_GEN(mdev, cq_moderation);
mlx5e_set_rx_cq_mode_params(params, cq_period_mode);
Patches currently in stable-queue which might be from roid(a)mellanox.com are
queue-4.15/net-mlx5e-fix-memory-usage-issues-in-offloading-tc-flows.patch
queue-4.15/net-mlx5e-fix-traffic-being-dropped-on-vf-representor.patch
queue-4.15/net-mlx5e-sync-netdev-vxlan-ports-at-open.patch
queue-4.15/net-mlx5e-don-t-override-vport-admin-link-state-in-switchdev-mode.patch
This is a note to let you know that I've just added the patch titled
net/mlx5e: Fix memory usage issues in offloading TC flows
to the 4.15-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
net-mlx5e-fix-memory-usage-issues-in-offloading-tc-flows.patch
and it can be found in the queue-4.15 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Tue Apr 10 23:19:36 CEST 2018
From: Jianbo Liu <jianbol(a)mellanox.com>
Date: Thu, 8 Mar 2018 09:20:55 +0000
Subject: net/mlx5e: Fix memory usage issues in offloading TC flows
From: Jianbo Liu <jianbol(a)mellanox.com>
[ Upstream commit af1607c37d9d85a66fbcf43b7f11bf3d94b9bb69 ]
For NIC flows, the parsed attributes are not freed when we exit
successfully from mlx5e_configure_flower().
There is possible double free for eswitch flows. If error is returned
from rhashtable_insert_fast(), the parse attrs will be freed in
mlx5e_tc_del_flow(), but they will be freed again before exiting
mlx5e_configure_flower().
To fix both issues we do the following:
(1) change the condition that determines if to issue the free call to
check if this flow is NIC flow, or it does not have encap action.
(2) reorder the code such that that the check and free calls are done
before we attempt to add into the hash table.
Fixes: 232c001398ae ('net/mlx5e: Add support to neighbour update flow')
Signed-off-by: Jianbo Liu <jianbol(a)mellanox.com>
Reviewed-by: Or Gerlitz <ogerlitz(a)mellanox.com>
Reviewed-by: Roi Dayan <roid(a)mellanox.com>
Signed-off-by: Saeed Mahameed <saeedm(a)mellanox.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/ethernet/mellanox/mlx5/core/en_tc.c | 16 ++++++++--------
1 file changed, 8 insertions(+), 8 deletions(-)
--- a/drivers/net/ethernet/mellanox/mlx5/core/en_tc.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en_tc.c
@@ -2102,19 +2102,19 @@ int mlx5e_configure_flower(struct mlx5e_
if (err != -EAGAIN)
flow->flags |= MLX5E_TC_FLOW_OFFLOADED;
+ if (!(flow->flags & MLX5E_TC_FLOW_ESWITCH) ||
+ !(flow->esw_attr->action & MLX5_FLOW_CONTEXT_ACTION_ENCAP))
+ kvfree(parse_attr);
+
err = rhashtable_insert_fast(&tc->ht, &flow->node,
tc->ht_params);
- if (err)
- goto err_del_rule;
+ if (err) {
+ mlx5e_tc_del_flow(priv, flow);
+ kfree(flow);
+ }
- if (flow->flags & MLX5E_TC_FLOW_ESWITCH &&
- !(flow->esw_attr->action & MLX5_FLOW_CONTEXT_ACTION_ENCAP))
- kvfree(parse_attr);
return err;
-err_del_rule:
- mlx5e_tc_del_flow(priv, flow);
-
err_free:
kvfree(parse_attr);
kfree(flow);
Patches currently in stable-queue which might be from jianbol(a)mellanox.com are
queue-4.15/net-mlx5e-fix-memory-usage-issues-in-offloading-tc-flows.patch
queue-4.15/net-mlx5e-don-t-override-vport-admin-link-state-in-switchdev-mode.patch
This is a note to let you know that I've just added the patch titled
net/mlx5e: Avoid using the ipv6 stub in the TC offload neigh update path
to the 4.15-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
net-mlx5e-avoid-using-the-ipv6-stub-in-the-tc-offload-neigh-update-path.patch
and it can be found in the queue-4.15 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Tue Apr 10 23:19:36 CEST 2018
From: Or Gerlitz <ogerlitz(a)mellanox.com>
Date: Tue, 13 Mar 2018 21:43:43 +0200
Subject: net/mlx5e: Avoid using the ipv6 stub in the TC offload neigh update path
From: Or Gerlitz <ogerlitz(a)mellanox.com>
[ Upstream commit 423c9db29943cfc43e3a408192e9efa4178af6a1 ]
Currently we use the global ipv6_stub var to access the ipv6 global
nd table. This practice gets us to troubles when the stub is only partially
set e.g when ipv6 is loaded under the disabled policy. In this case, as of commit
343d60aada5a ("ipv6: change ipv6_stub_impl.ipv6_dst_lookup to take net argument")
the stub is not null, but stub->nd_tbl is and we crash.
As we can access the ipv6 nd_tbl directly, the fix is just to avoid the
reference through the stub. There is one place in the code where we
issue ipv6 route lookup and keep doing it through the stub, but that
mentioned commit makes sure we get -EAFNOSUPPORT from the stack.
Fixes: 232c001398ae ("net/mlx5e: Add support to neighbour update flow")
Signed-off-by: Or Gerlitz <ogerlitz(a)mellanox.com>
Reviewed-by: Aviv Heller <avivh(a)mellanox.com>
Signed-off-by: Saeed Mahameed <saeedm(a)mellanox.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/ethernet/mellanox/mlx5/core/en_rep.c | 6 +++---
drivers/net/ethernet/mellanox/mlx5/core/en_tc.c | 2 +-
2 files changed, 4 insertions(+), 4 deletions(-)
--- a/drivers/net/ethernet/mellanox/mlx5/core/en_rep.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en_rep.c
@@ -231,7 +231,7 @@ void mlx5e_remove_sqs_fwd_rules(struct m
static void mlx5e_rep_neigh_update_init_interval(struct mlx5e_rep_priv *rpriv)
{
#if IS_ENABLED(CONFIG_IPV6)
- unsigned long ipv6_interval = NEIGH_VAR(&ipv6_stub->nd_tbl->parms,
+ unsigned long ipv6_interval = NEIGH_VAR(&nd_tbl.parms,
DELAY_PROBE_TIME);
#else
unsigned long ipv6_interval = ~0UL;
@@ -367,7 +367,7 @@ static int mlx5e_rep_netevent_event(stru
case NETEVENT_NEIGH_UPDATE:
n = ptr;
#if IS_ENABLED(CONFIG_IPV6)
- if (n->tbl != ipv6_stub->nd_tbl && n->tbl != &arp_tbl)
+ if (n->tbl != &nd_tbl && n->tbl != &arp_tbl)
#else
if (n->tbl != &arp_tbl)
#endif
@@ -415,7 +415,7 @@ static int mlx5e_rep_netevent_event(stru
* done per device delay prob time parameter.
*/
#if IS_ENABLED(CONFIG_IPV6)
- if (!p->dev || (p->tbl != ipv6_stub->nd_tbl && p->tbl != &arp_tbl))
+ if (!p->dev || (p->tbl != &nd_tbl && p->tbl != &arp_tbl))
#else
if (!p->dev || p->tbl != &arp_tbl)
#endif
--- a/drivers/net/ethernet/mellanox/mlx5/core/en_tc.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en_tc.c
@@ -495,7 +495,7 @@ void mlx5e_tc_update_neigh_used_value(st
tbl = &arp_tbl;
#if IS_ENABLED(CONFIG_IPV6)
else if (m_neigh->family == AF_INET6)
- tbl = ipv6_stub->nd_tbl;
+ tbl = &nd_tbl;
#endif
else
return;
Patches currently in stable-queue which might be from ogerlitz(a)mellanox.com are
queue-4.15/net-mlx5e-fix-memory-usage-issues-in-offloading-tc-flows.patch
queue-4.15/net-mlx5e-fix-traffic-being-dropped-on-vf-representor.patch
queue-4.15/net-mlx5e-avoid-using-the-ipv6-stub-in-the-tc-offload-neigh-update-path.patch
queue-4.15/net-mlx5e-don-t-override-vport-admin-link-state-in-switchdev-mode.patch
This is a note to let you know that I've just added the patch titled
net/mlx5e: Don't override vport admin link state in switchdev mode
to the 4.15-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
net-mlx5e-don-t-override-vport-admin-link-state-in-switchdev-mode.patch
and it can be found in the queue-4.15 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Tue Apr 10 23:19:36 CEST 2018
From: Jianbo Liu <jianbol(a)mellanox.com>
Date: Fri, 2 Mar 2018 02:09:08 +0000
Subject: net/mlx5e: Don't override vport admin link state in switchdev mode
From: Jianbo Liu <jianbol(a)mellanox.com>
The vport admin original link state will be re-applied after returning
back to legacy mode, it is not right to change the admin link state value
when in switchdev mode.
Use direct vport commands to alter logical vport state in netdev
representor open/close flows rather than the administrative eswitch API.
Fixes: 20a1ea674783 ('net/mlx5e: Support VF vport link state control for SRIOV switchdev mode')
Signed-off-by: Jianbo Liu <jianbol(a)mellanox.com>
Reviewed-by: Roi Dayan <roid(a)mellanox.com>
Reviewed-by: Or Gerlitz <ogerlitz(a)mellanox.com>
Signed-off-by: Saeed Mahameed <saeedm(a)mellanox.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/ethernet/mellanox/mlx5/core/en_rep.c | 11 ++++++-----
1 file changed, 6 insertions(+), 5 deletions(-)
--- a/drivers/net/ethernet/mellanox/mlx5/core/en_rep.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en_rep.c
@@ -611,7 +611,6 @@ static int mlx5e_rep_open(struct net_dev
struct mlx5e_priv *priv = netdev_priv(dev);
struct mlx5e_rep_priv *rpriv = priv->ppriv;
struct mlx5_eswitch_rep *rep = rpriv->rep;
- struct mlx5_eswitch *esw = priv->mdev->priv.eswitch;
int err;
mutex_lock(&priv->state_lock);
@@ -619,8 +618,9 @@ static int mlx5e_rep_open(struct net_dev
if (err)
goto unlock;
- if (!mlx5_eswitch_set_vport_state(esw, rep->vport,
- MLX5_ESW_VPORT_ADMIN_STATE_UP))
+ if (!mlx5_modify_vport_admin_state(priv->mdev,
+ MLX5_QUERY_VPORT_STATE_IN_OP_MOD_ESW_VPORT,
+ rep->vport, MLX5_ESW_VPORT_ADMIN_STATE_UP))
netif_carrier_on(dev);
unlock:
@@ -633,11 +633,12 @@ static int mlx5e_rep_close(struct net_de
struct mlx5e_priv *priv = netdev_priv(dev);
struct mlx5e_rep_priv *rpriv = priv->ppriv;
struct mlx5_eswitch_rep *rep = rpriv->rep;
- struct mlx5_eswitch *esw = priv->mdev->priv.eswitch;
int ret;
mutex_lock(&priv->state_lock);
- (void)mlx5_eswitch_set_vport_state(esw, rep->vport, MLX5_ESW_VPORT_ADMIN_STATE_DOWN);
+ mlx5_modify_vport_admin_state(priv->mdev,
+ MLX5_QUERY_VPORT_STATE_IN_OP_MOD_ESW_VPORT,
+ rep->vport, MLX5_ESW_VPORT_ADMIN_STATE_DOWN);
ret = mlx5e_close_locked(dev);
mutex_unlock(&priv->state_lock);
return ret;
Patches currently in stable-queue which might be from jianbol(a)mellanox.com are
queue-4.15/net-mlx5e-fix-memory-usage-issues-in-offloading-tc-flows.patch
queue-4.15/net-mlx5e-don-t-override-vport-admin-link-state-in-switchdev-mode.patch
This is a note to let you know that I've just added the patch titled
net/ipv6: Fix route leaking between VRFs
to the 4.15-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
net-ipv6-fix-route-leaking-between-vrfs.patch
and it can be found in the queue-4.15 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Tue Apr 10 23:19:36 CEST 2018
From: David Ahern <dsahern(a)gmail.com>
Date: Thu, 29 Mar 2018 17:44:57 -0700
Subject: net/ipv6: Fix route leaking between VRFs
From: David Ahern <dsahern(a)gmail.com>
[ Upstream commit b6cdbc85234b072340b8923e69f49ec293f905dc ]
Donald reported that IPv6 route leaking between VRFs is not working.
The root cause is the strict argument in the call to rt6_lookup when
validating the nexthop spec.
ip6_route_check_nh validates the gateway and device (if given) of a
route spec. It in turn could call rt6_lookup (e.g., lookup in a given
table did not succeed so it falls back to a full lookup) and if so
sets the strict argument to 1. That means if the egress device is given,
the route lookup needs to return a result with the same device. This
strict requirement does not work with VRFs (IPv4 or IPv6) because the
oif in the flow struct is overridden with the index of the VRF device
to trigger a match on the l3mdev rule and force the lookup to its table.
The right long term solution is to add an l3mdev index to the flow
struct such that the oif is not overridden. That solution will not
backport well, so this patch aims for a simpler solution to relax the
strict argument if the route spec device is an l3mdev slave. As done
in other places, use the FLOWI_FLAG_SKIP_NH_OIF to know that the
RT6_LOOKUP_F_IFACE flag needs to be removed.
Fixes: ca254490c8df ("net: Add VRF support to IPv6 stack")
Reported-by: Donald Sharp <sharpd(a)cumulusnetworks.com>
Signed-off-by: David Ahern <dsahern(a)gmail.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/ipv6/route.c | 3 +++
1 file changed, 3 insertions(+)
--- a/net/ipv6/route.c
+++ b/net/ipv6/route.c
@@ -922,6 +922,9 @@ static struct rt6_info *ip6_pol_route_lo
struct rt6_info *rt, *rt_cache;
struct fib6_node *fn;
+ if (fl6->flowi6_flags & FLOWI_FLAG_SKIP_NH_OIF)
+ flags &= ~RT6_LOOKUP_F_IFACE;
+
rcu_read_lock();
fn = fib6_lookup(&table->tb6_root, &fl6->daddr, &fl6->saddr);
restart:
Patches currently in stable-queue which might be from dsahern(a)gmail.com are
queue-4.15/perf-evsel-fix-swap-for-samples-with-raw-data.patch
queue-4.15/perf-tools-fix-copyfile_offset-update-of-output-offset.patch
queue-4.15/net-ipv6-fix-route-leaking-between-vrfs.patch
queue-4.15/vrf-fix-use-after-free-and-double-free-in-vrf_finish_output.patch
This is a note to let you know that I've just added the patch titled
net/mlx4_core: Fix memory leak while delete slave's resources
to the 4.15-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
net-mlx4_core-fix-memory-leak-while-delete-slave-s-resources.patch
and it can be found in the queue-4.15 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Tue Apr 10 23:19:36 CEST 2018
From: Moshe Shemesh <moshe(a)mellanox.com>
Date: Tue, 27 Mar 2018 14:41:19 +0300
Subject: net/mlx4_core: Fix memory leak while delete slave's resources
From: Moshe Shemesh <moshe(a)mellanox.com>
[ Upstream commit 461d5f1b59490ce0096dfda45e10038c122a7892 ]
mlx4_delete_all_resources_for_slave in resource tracker should free all
memory allocated for a slave.
While releasing memory of fs_rule, it misses releasing memory of
fs_rule->mirr_mbox.
Fixes: 78efed275117 ('net/mlx4_core: Support mirroring VF DMFS rules on both ports')
Signed-off-by: Moshe Shemesh <moshe(a)mellanox.com>
Signed-off-by: Tariq Toukan <tariqt(a)mellanox.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/ethernet/mellanox/mlx4/resource_tracker.c | 1 +
1 file changed, 1 insertion(+)
--- a/drivers/net/ethernet/mellanox/mlx4/resource_tracker.c
+++ b/drivers/net/ethernet/mellanox/mlx4/resource_tracker.c
@@ -5088,6 +5088,7 @@ static void rem_slave_fs_rule(struct mlx
&tracker->res_tree[RES_FS_RULE]);
list_del(&fs_rule->com.list);
spin_unlock_irq(mlx4_tlock(dev));
+ kfree(fs_rule->mirr_mbox);
kfree(fs_rule);
state = 0;
break;
Patches currently in stable-queue which might be from moshe(a)mellanox.com are
queue-4.15/net-mlx4_core-fix-memory-leak-while-delete-slave-s-resources.patch
queue-4.15/net-mlx5e-verify-coalescing-parameters-in-range.patch
This is a note to let you know that I've just added the patch titled
net/ipv6: Increment OUTxxx counters after netfilter hook
to the 4.15-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
net-ipv6-increment-outxxx-counters-after-netfilter-hook.patch
and it can be found in the queue-4.15 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Tue Apr 10 23:19:36 CEST 2018
From: Jeff Barnhill <0xeffeff(a)gmail.com>
Date: Thu, 5 Apr 2018 21:29:47 +0000
Subject: net/ipv6: Increment OUTxxx counters after netfilter hook
From: Jeff Barnhill <0xeffeff(a)gmail.com>
[ Upstream commit 71a1c915238c970cd9bdd5bf158b1279d6b6d55b ]
At the end of ip6_forward(), IPSTATS_MIB_OUTFORWDATAGRAMS and
IPSTATS_MIB_OUTOCTETS are incremented immediately before the NF_HOOK call
for NFPROTO_IPV6 / NF_INET_FORWARD. As a result, these counters get
incremented regardless of whether or not the netfilter hook allows the
packet to continue being processed. This change increments the counters
in ip6_forward_finish() so that it will not happen if the netfilter hook
chooses to terminate the packet, which is similar to how IPv4 works.
Signed-off-by: Jeff Barnhill <0xeffeff(a)gmail.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/ipv6/ip6_output.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
--- a/net/ipv6/ip6_output.c
+++ b/net/ipv6/ip6_output.c
@@ -375,6 +375,11 @@ static int ip6_forward_proxy_check(struc
static inline int ip6_forward_finish(struct net *net, struct sock *sk,
struct sk_buff *skb)
{
+ struct dst_entry *dst = skb_dst(skb);
+
+ __IP6_INC_STATS(net, ip6_dst_idev(dst), IPSTATS_MIB_OUTFORWDATAGRAMS);
+ __IP6_ADD_STATS(net, ip6_dst_idev(dst), IPSTATS_MIB_OUTOCTETS, skb->len);
+
return dst_output(net, sk, skb);
}
@@ -568,8 +573,6 @@ int ip6_forward(struct sk_buff *skb)
hdr->hop_limit--;
- __IP6_INC_STATS(net, ip6_dst_idev(dst), IPSTATS_MIB_OUTFORWDATAGRAMS);
- __IP6_ADD_STATS(net, ip6_dst_idev(dst), IPSTATS_MIB_OUTOCTETS, skb->len);
return NF_HOOK(NFPROTO_IPV6, NF_INET_FORWARD,
net, NULL, skb, skb->dev, dst->dev,
ip6_forward_finish);
Patches currently in stable-queue which might be from 0xeffeff(a)gmail.com are
queue-4.15/net-ipv6-increment-outxxx-counters-after-netfilter-hook.patch
This is a note to let you know that I've just added the patch titled
net: fool proof dev_valid_name()
to the 4.15-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
net-fool-proof-dev_valid_name.patch
and it can be found in the queue-4.15 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Tue Apr 10 23:19:36 CEST 2018
From: Eric Dumazet <edumazet(a)google.com>
Date: Thu, 5 Apr 2018 06:39:26 -0700
Subject: net: fool proof dev_valid_name()
From: Eric Dumazet <edumazet(a)google.com>
[ Upstream commit a9d48205d0aedda021fc3728972a9e9934c2b9de ]
We want to use dev_valid_name() to validate tunnel names,
so better use strnlen(name, IFNAMSIZ) than strlen(name) to make
sure to not upset KASAN.
Signed-off-by: Eric Dumazet <edumazet(a)google.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/core/dev.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -1027,7 +1027,7 @@ bool dev_valid_name(const char *name)
{
if (*name == '\0')
return false;
- if (strlen(name) >= IFNAMSIZ)
+ if (strnlen(name, IFNAMSIZ) == IFNAMSIZ)
return false;
if (!strcmp(name, ".") || !strcmp(name, ".."))
return false;
Patches currently in stable-queue which might be from edumazet(a)google.com are
queue-4.15/sctp-sctp_sockaddr_af-must-check-minimal-addr-length-for-af_inet6.patch
queue-4.15/net-fix-possible-out-of-bound-read-in-skb_network_protocol.patch
queue-4.15/pptp-remove-a-buggy-dst-release-in-pptp_connect.patch
queue-4.15/net-fool-proof-dev_valid_name.patch
queue-4.15/ipv6-the-entire-ipv6-header-chain-must-fit-the-first-fragment.patch
queue-4.15/vti6-better-validate-user-provided-tunnel-names.patch
queue-4.15/ipv6-sit-better-validate-user-provided-tunnel-names.patch
queue-4.15/ip6_tunnel-better-validate-user-provided-tunnel-names.patch
queue-4.15/sctp-do-not-leak-kernel-memory-to-user-space.patch
queue-4.15/ip_tunnel-better-validate-user-provided-tunnel-names.patch
queue-4.15/netlink-make-sure-nladdr-has-correct-size-in-netlink_connect.patch
queue-4.15/ip6_gre-better-validate-user-provided-tunnel-names.patch