2020-12-06 11:46:58

by Greg KH

[permalink] [raw]
Subject: [PATCH 5.9 00/46] 5.9.13-rc1 review

This is the start of the stable review cycle for the 5.9.13 release.
There are 46 patches in this series, all will be posted as a response
to this one. If anyone has any issues with these being applied, please
let me know.

Responses should be made by Tue, 08 Dec 2020 11:15:42 +0000.
Anything received after that time might be too late.

The whole patch series can be found in one patch at:
https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.9.13-rc1.gz
or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.9.y
and the diffstat can be found below.

thanks,

greg k-h

-------------
Pseudo-Shortlog of commits:

Greg Kroah-Hartman <[email protected]>
Linux 5.9.13-rc1

Chris Wilson <[email protected]>
drm/i915/gt: Fixup tgl mocs for PTE tracking

Eric Sandeen <[email protected]>
uapi: fix statx attribute value overlap for DAX & MOUNT_ROOT

Vasily Averin <[email protected]>
tracing: Remove WARN_ON in start_thread()

Minchan Kim <[email protected]>
tracing: Fix alignment of static buffer

Linus Walleij <[email protected]>
Input: atmel_mxt_ts - fix lost interrupts

Po-Hsu Lin <[email protected]>
Input: i8042 - add ByteSpeed touchpad to noloop table

Sanjay Govind <[email protected]>
Input: xpad - support Ardwiino Controllers

Hector Martin <[email protected]>
ALSA: usb-audio: US16x08: fix value count for level meters

Randy Dunlap <[email protected]>
net: mlx5e: fix fs_tcp.c build when IPV6 is not enabled

Eran Ben Elisha <[email protected]>
net/mlx5: Fix wrong address reclaim when command interface is down

Yevgeny Kliteynik <[email protected]>
net/mlx5: DR, Proper handling of unsupported Connect-X6DX SW steering

Davide Caratti <[email protected]>
net/sched: act_mpls: ensure LSE is pullable before reading it

Davide Caratti <[email protected]>
net: openvswitch: ensure LSE is pullable before reading it

Davide Caratti <[email protected]>
net: skbuff: ensure LSE is pullable before decrementing the MPLS ttl

Wang Hai <[email protected]>
net: mvpp2: Fix error return code in mvpp2_open()

Dan Carpenter <[email protected]>
chelsio/chtls: fix a double free in chtls_setkey()

Zhang Changzhong <[email protected]>
vxlan: fix error return code in __vxlan_dev_create()

Zhang Changzhong <[email protected]>
net: pasemi: fix error return code in pasemi_mac_open()

Zhang Changzhong <[email protected]>
cxgb3: fix error return code in t3_sge_alloc_qset()

Dan Carpenter <[email protected]>
net/x25: prevent a couple of overflows

Yangbo Lu <[email protected]>
dpaa_eth: copy timestamp fields to new skb in A-050385 workaround

Antoine Tenart <[email protected]>
net: ip6_gre: set dev->hard_header_len when using header_ops

Eric Dumazet <[email protected]>
geneve: pull IP header before ECN decapsulation

Toke Høiland-Jørgensen <[email protected]>
inet_ecn: Fix endianness of checksum update when setting ECT(1)

Hoang Le <[email protected]>
tipc: fix incompatible mtu of transmission

Thomas Falcon <[email protected]>
ibmvnic: Fix TX completion error handling

Thomas Falcon <[email protected]>
ibmvnic: Ensure that SCRQ entry reads are correctly ordered

Vinay Kumar Yadav <[email protected]>
chelsio/chtls: fix panic during unload reload chtls

Krzysztof Kozlowski <[email protected]>
dt-bindings: net: correct interrupt flags in examples

Guillaume Nault <[email protected]>
ipv4: Fix tos mask in inet_rtm_getroute()

Antoine Tenart <[email protected]>
netfilter: bridge: reset skb->pkt_type after NF_INET_POST_ROUTING traversal

Eyal Birger <[email protected]>
net/packet: fix packet receive on L3 devices without visible hard header

Paolo Abeni <[email protected]>
mptcp: fix NULL ptr dereference on bad MPJ

Stefano Garzarella <[email protected]>
vsock/virtio: discard packets only when socket is really closed

Yves-Alexis Perez <[email protected]>
usbnet: ipheth: fix connectivity with iOS 14

Jens Axboe <[email protected]>
tun: honor IOCB_NOWAIT flag

Alexander Duyck <[email protected]>
tcp: Set INET_ECN_xmit configuration in tcp_reinit_congestion_control

Willem de Bruijn <[email protected]>
sock: set sk_err to ee_errno on dequeue from errq

Anmol Karn <[email protected]>
rose: Fix Null pointer dereference in rose_send_frame()

Maxim Mikityanskiy <[email protected]>
net/tls: Protect from calling tls_dev_del for TLS RX twice

Vadim Fedorenko <[email protected]>
net/tls: missing received data after fast remote close

Eelco Chaudron <[email protected]>
net: openvswitch: fix TTL decrement action netlink message format

Julian Wiedmann <[email protected]>
net/af_iucv: set correct sk_protocol for child sockets

Wang Hai <[email protected]>
ipv6: addrlabel: fix possible memory leak in ip6addrlbl_net_init

Parav Pandit <[email protected]>
devlink: Make sure devlink instance and port are in same net namespace

Parav Pandit <[email protected]>
devlink: Hold rtnl lock while reading netdev attributes


-------------

Diffstat:

.../devicetree/bindings/net/can/tcan4x5x.txt | 2 +-
.../devicetree/bindings/net/nfc/nxp-nci.txt | 2 +-
.../devicetree/bindings/net/nfc/pn544.txt | 2 +-
Makefile | 4 +-
drivers/crypto/chelsio/chtls/chtls_cm.c | 1 +
drivers/crypto/chelsio/chtls/chtls_hw.c | 1 +
drivers/gpu/drm/i915/gt/intel_mocs.c | 5 +-
drivers/input/joystick/xpad.c | 2 +
drivers/input/serio/i8042-x86ia64io.h | 4 ++
drivers/input/touchscreen/atmel_mxt_ts.c | 4 +-
drivers/net/ethernet/chelsio/cxgb3/sge.c | 1 +
drivers/net/ethernet/freescale/dpaa/dpaa_eth.c | 10 ++-
drivers/net/ethernet/ibm/ibmvnic.c | 22 ++++++-
drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c | 1 +
.../ethernet/mellanox/mlx5/core/en_accel/fs_tcp.c | 2 +
.../net/ethernet/mellanox/mlx5/core/pagealloc.c | 21 +++++-
.../ethernet/mellanox/mlx5/core/steering/dr_cmd.c | 1 +
.../mellanox/mlx5/core/steering/dr_domain.c | 5 ++
.../mellanox/mlx5/core/steering/dr_types.h | 1 +
drivers/net/ethernet/pasemi/pasemi_mac.c | 8 ++-
drivers/net/geneve.c | 20 ++++--
drivers/net/tun.c | 14 +++-
drivers/net/usb/ipheth.c | 2 +-
drivers/net/vxlan.c | 4 +-
include/linux/mlx5/mlx5_ifc.h | 9 ++-
include/linux/netdevice.h | 5 ++
include/net/inet_ecn.h | 2 +-
include/net/tls.h | 6 ++
include/uapi/linux/openvswitch.h | 2 +
include/uapi/linux/stat.h | 9 ++-
kernel/trace/trace.c | 2 +-
kernel/trace/trace_hwlat.c | 2 +-
net/bridge/br_netfilter_hooks.c | 7 +-
net/core/devlink.c | 7 +-
net/core/skbuff.c | 5 +-
net/ipv4/route.c | 7 +-
net/ipv4/tcp_cong.c | 5 ++
net/ipv6/addrlabel.c | 26 +++++---
net/ipv6/ip6_gre.c | 16 ++++-
net/iucv/af_iucv.c | 4 +-
net/mptcp/subflow.c | 5 +-
net/openvswitch/actions.c | 10 +--
net/openvswitch/flow_netlink.c | 74 ++++++++++++++++------
net/packet/af_packet.c | 38 ++++++-----
net/rose/rose_loopback.c | 17 +++--
net/sched/act_mpls.c | 3 +
net/tipc/node.c | 2 +
net/tls/tls_device.c | 5 +-
net/tls/tls_sw.c | 6 ++
net/vmw_vsock/virtio_transport_common.c | 8 ++-
net/x25/af_x25.c | 6 +-
sound/usb/mixer_us16x08.c | 2 +-
52 files changed, 321 insertions(+), 108 deletions(-)



2020-12-06 11:47:03

by Greg KH

[permalink] [raw]
Subject: [PATCH 5.9 35/46] net/sched: act_mpls: ensure LSE is pullable before reading it

From: Davide Caratti <[email protected]>

[ Upstream commit 9608fa653059c3f72faab0c148ac8773c46e7314 ]

when 'act_mpls' is used to mangle the LSE, the current value is read from
the packet dereferencing 4 bytes at mpls_hdr(): ensure that the label is
contained in the skb "linear" area.

Found by code inspection.

v2:
- use MPLS_HLEN instead of sizeof(new_lse), thanks to Jakub Kicinski

Fixes: 2a2ea50870ba ("net: sched: add mpls manipulation actions to TC")
Signed-off-by: Davide Caratti <[email protected]>
Acked-by: Guillaume Nault <[email protected]>
Link: https://lore.kernel.org/r/3243506cba43d14858f3bd21ee0994160e44d64a.1606987058.git.dcaratti@redhat.com
Signed-off-by: Jakub Kicinski <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
net/sched/act_mpls.c | 3 +++
1 file changed, 3 insertions(+)

--- a/net/sched/act_mpls.c
+++ b/net/sched/act_mpls.c
@@ -88,6 +88,9 @@ static int tcf_mpls_act(struct sk_buff *
goto drop;
break;
case TCA_MPLS_ACT_MODIFY:
+ if (!pskb_may_pull(skb,
+ skb_network_offset(skb) + MPLS_HLEN))
+ goto drop;
new_lse = tcf_mpls_get_lse(mpls_hdr(skb), p, false);
if (skb_mpls_update_lse(skb, new_lse))
goto drop;


2020-12-06 11:47:06

by Greg KH

[permalink] [raw]
Subject: [PATCH 5.9 03/46] ipv6: addrlabel: fix possible memory leak in ip6addrlbl_net_init

From: Wang Hai <[email protected]>

[ Upstream commit e255e11e66da8281e337e4e352956e8a4999fca4 ]

kmemleak report a memory leak as follows:

unreferenced object 0xffff8880059c6a00 (size 64):
comm "ip", pid 23696, jiffies 4296590183 (age 1755.384s)
hex dump (first 32 bytes):
20 01 00 10 00 00 00 00 00 00 00 00 00 00 00 00 ...............
1c 00 00 00 00 00 00 00 00 00 00 00 07 00 00 00 ................
backtrace:
[<00000000aa4e7a87>] ip6addrlbl_add+0x90/0xbb0
[<0000000070b8d7f1>] ip6addrlbl_net_init+0x109/0x170
[<000000006a9ca9d4>] ops_init+0xa8/0x3c0
[<000000002da57bf2>] setup_net+0x2de/0x7e0
[<000000004e52d573>] copy_net_ns+0x27d/0x530
[<00000000b07ae2b4>] create_new_namespaces+0x382/0xa30
[<000000003b76d36f>] unshare_nsproxy_namespaces+0xa1/0x1d0
[<0000000030653721>] ksys_unshare+0x3a4/0x780
[<0000000007e82e40>] __x64_sys_unshare+0x2d/0x40
[<0000000031a10c08>] do_syscall_64+0x33/0x40
[<0000000099df30e7>] entry_SYSCALL_64_after_hwframe+0x44/0xa9

We should free all rules when we catch an error in ip6addrlbl_net_init().
otherwise a memory leak will occur.

Fixes: 2a8cc6c89039 ("[IPV6] ADDRCONF: Support RFC3484 configurable address selection policy table.")
Reported-by: Hulk Robot <[email protected]>
Signed-off-by: Wang Hai <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Jakub Kicinski <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
net/ipv6/addrlabel.c | 26 +++++++++++++++++---------
1 file changed, 17 insertions(+), 9 deletions(-)

--- a/net/ipv6/addrlabel.c
+++ b/net/ipv6/addrlabel.c
@@ -306,7 +306,9 @@ static int ip6addrlbl_del(struct net *ne
/* add default label */
static int __net_init ip6addrlbl_net_init(struct net *net)
{
- int err = 0;
+ struct ip6addrlbl_entry *p = NULL;
+ struct hlist_node *n;
+ int err;
int i;

ADDRLABEL(KERN_DEBUG "%s\n", __func__);
@@ -315,14 +317,20 @@ static int __net_init ip6addrlbl_net_ini
INIT_HLIST_HEAD(&net->ipv6.ip6addrlbl_table.head);

for (i = 0; i < ARRAY_SIZE(ip6addrlbl_init_table); i++) {
- int ret = ip6addrlbl_add(net,
- ip6addrlbl_init_table[i].prefix,
- ip6addrlbl_init_table[i].prefixlen,
- 0,
- ip6addrlbl_init_table[i].label, 0);
- /* XXX: should we free all rules when we catch an error? */
- if (ret && (!err || err != -ENOMEM))
- err = ret;
+ err = ip6addrlbl_add(net,
+ ip6addrlbl_init_table[i].prefix,
+ ip6addrlbl_init_table[i].prefixlen,
+ 0,
+ ip6addrlbl_init_table[i].label, 0);
+ if (err)
+ goto err_ip6addrlbl_add;
+ }
+ return 0;
+
+err_ip6addrlbl_add:
+ hlist_for_each_entry_safe(p, n, &net->ipv6.ip6addrlbl_table.head, list) {
+ hlist_del_rcu(&p->list);
+ kfree_rcu(p, rcu);
}
return err;
}


2020-12-06 11:47:07

by Greg KH

[permalink] [raw]
Subject: [PATCH 5.9 27/46] net/x25: prevent a couple of overflows

From: Dan Carpenter <[email protected]>

[ Upstream commit 6ee50c8e262a0f0693dad264c3c99e30e6442a56 ]

The .x25_addr[] address comes from the user and is not necessarily
NUL terminated. This leads to a couple problems. The first problem is
that the strlen() in x25_bind() can read beyond the end of the buffer.

The second problem is more subtle and could result in memory corruption.
The call tree is:
x25_connect()
--> x25_write_internal()
--> x25_addr_aton()

The .x25_addr[] buffers are copied to the "addresses" buffer from
x25_write_internal() so it will lead to stack corruption.

Verify that the strings are NUL terminated and return -EINVAL if they
are not.

Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Fixes: a9288525d2ae ("X25: Dont let x25_bind use addresses containing characters")
Reported-by: "kiyin(尹亮)" <[email protected]>
Signed-off-by: Dan Carpenter <[email protected]>
Acked-by: Martin Schiller <[email protected]>
Link: https://lore.kernel.org/r/X8ZeAKm8FnFpN//B@mwanda
Signed-off-by: Jakub Kicinski <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
net/x25/af_x25.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)

--- a/net/x25/af_x25.c
+++ b/net/x25/af_x25.c
@@ -681,7 +681,8 @@ static int x25_bind(struct socket *sock,
int len, i, rc = 0;

if (addr_len != sizeof(struct sockaddr_x25) ||
- addr->sx25_family != AF_X25) {
+ addr->sx25_family != AF_X25 ||
+ strnlen(addr->sx25_addr.x25_addr, X25_ADDR_LEN) == X25_ADDR_LEN) {
rc = -EINVAL;
goto out;
}
@@ -775,7 +776,8 @@ static int x25_connect(struct socket *so

rc = -EINVAL;
if (addr_len != sizeof(struct sockaddr_x25) ||
- addr->sx25_family != AF_X25)
+ addr->sx25_family != AF_X25 ||
+ strnlen(addr->sx25_addr.x25_addr, X25_ADDR_LEN) == X25_ADDR_LEN)
goto out;

rc = -ENETUNREACH;


2020-12-06 11:47:08

by Greg KH

[permalink] [raw]
Subject: [PATCH 5.9 29/46] net: pasemi: fix error return code in pasemi_mac_open()

From: Zhang Changzhong <[email protected]>

[ Upstream commit aba84871bd4f52c4dfcf3ad5d4501a6c9d2de90e ]

Fix to return a negative error code from the error handling
case instead of 0, as done elsewhere in this function.

Fixes: 72b05b9940f0 ("pasemi_mac: RX/TX ring management cleanup")
Fixes: 8d636d8bc5ff ("pasemi_mac: jumbo frame support")
Reported-by: Hulk Robot <[email protected]>
Signed-off-by: Zhang Changzhong <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Jakub Kicinski <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/net/ethernet/pasemi/pasemi_mac.c | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)

--- a/drivers/net/ethernet/pasemi/pasemi_mac.c
+++ b/drivers/net/ethernet/pasemi/pasemi_mac.c
@@ -1078,16 +1078,20 @@ static int pasemi_mac_open(struct net_de

mac->tx = pasemi_mac_setup_tx_resources(dev);

- if (!mac->tx)
+ if (!mac->tx) {
+ ret = -ENOMEM;
goto out_tx_ring;
+ }

/* We might already have allocated rings in case mtu was changed
* before interface was brought up.
*/
if (dev->mtu > 1500 && !mac->num_cs) {
pasemi_mac_setup_csrings(mac);
- if (!mac->num_cs)
+ if (!mac->num_cs) {
+ ret = -ENOMEM;
goto out_tx_ring;
+ }
}

/* Zero out rmon counters */


2020-12-06 11:47:08

by Greg KH

[permalink] [raw]
Subject: [PATCH 5.9 30/46] vxlan: fix error return code in __vxlan_dev_create()

From: Zhang Changzhong <[email protected]>

[ Upstream commit 832e09798c261cf58de3a68cfcc6556408c16a5a ]

Fix to return a negative error code from the error handling
case instead of 0, as done elsewhere in this function.

Fixes: 0ce1822c2a08 ("vxlan: add adjacent link to limit depth level")
Reported-by: Hulk Robot <[email protected]>
Signed-off-by: Zhang Changzhong <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Jakub Kicinski <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/net/vxlan.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)

--- a/drivers/net/vxlan.c
+++ b/drivers/net/vxlan.c
@@ -3881,8 +3881,10 @@ static int __vxlan_dev_create(struct net

if (dst->remote_ifindex) {
remote_dev = __dev_get_by_index(net, dst->remote_ifindex);
- if (!remote_dev)
+ if (!remote_dev) {
+ err = -ENODEV;
goto errout;
+ }

err = netdev_upper_dev_link(remote_dev, dev, extack);
if (err)


2020-12-06 11:47:19

by Greg KH

[permalink] [raw]
Subject: [PATCH 5.9 10/46] tcp: Set INET_ECN_xmit configuration in tcp_reinit_congestion_control

From: Alexander Duyck <[email protected]>

[ Upstream commit 55472017a4219ca965a957584affdb17549ae4a4 ]

When setting congestion control via a BPF program it is seen that the
SYN/ACK for packets within a given flow will not include the ECT0 flag. A
bit of simple printk debugging shows that when this is configured without
BPF we will see the value INET_ECN_xmit value initialized in
tcp_assign_congestion_control however when we configure this via BPF the
socket is in the closed state and as such it isn't configured, and I do not
see it being initialized when we transition the socket into the listen
state. The result of this is that the ECT0 bit is configured based on
whatever the default state is for the socket.

Any easy way to reproduce this is to monitor the following with tcpdump:
tools/testing/selftests/bpf/test_progs -t bpf_tcp_ca

Without this patch the SYN/ACK will follow whatever the default is. If dctcp
all SYN/ACK packets will have the ECT0 bit set, and if it is not then ECT0
will be cleared on all SYN/ACK packets. With this patch applied the SYN/ACK
bit matches the value seen on the other packets in the given stream.

Fixes: 91b5b21c7c16 ("bpf: Add support for changing congestion control")
Signed-off-by: Alexander Duyck <[email protected]>
Signed-off-by: Jakub Kicinski <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
net/ipv4/tcp_cong.c | 5 +++++
1 file changed, 5 insertions(+)

--- a/net/ipv4/tcp_cong.c
+++ b/net/ipv4/tcp_cong.c
@@ -197,6 +197,11 @@ static void tcp_reinit_congestion_contro
icsk->icsk_ca_setsockopt = 1;
memset(icsk->icsk_ca_priv, 0, sizeof(icsk->icsk_ca_priv));

+ if (ca->flags & TCP_CONG_NEEDS_ECN)
+ INET_ECN_xmit(sk);
+ else
+ INET_ECN_dontxmit(sk);
+
if (!((1 << sk->sk_state) & (TCPF_CLOSE | TCPF_LISTEN)))
tcp_init_congestion_control(sk);
}


2020-12-06 11:47:20

by Greg KH

[permalink] [raw]
Subject: [PATCH 5.9 12/46] usbnet: ipheth: fix connectivity with iOS 14

From: Yves-Alexis Perez <[email protected]>

[ Upstream commit f33d9e2b48a34e1558b67a473a1fc1d6e793f93c ]

Starting with iOS 14 released in September 2020, connectivity using the
personal hotspot USB tethering function of iOS devices is broken.

Communication between the host and the device (for example ICMP traffic
or DNS resolution using the DNS service running in the device itself)
works fine, but communication to endpoints further away doesn't work.

Investigation on the matter shows that no UDP and ICMP traffic from the
tethered host is reaching the Internet at all. For TCP traffic there are
exchanges between tethered host and server but packets are modified in
transit leading to impossible communication.

After some trials Matti Vuorela discovered that reducing the URB buffer
size by two bytes restored the previous behavior. While a better
solution might exist to fix the issue, since the protocol is not
publicly documented and considering the small size of the fix, let's do
that.

Tested-by: Matti Vuorela <[email protected]>
Signed-off-by: Yves-Alexis Perez <[email protected]>
Link: https://lore.kernel.org/linux-usb/CAAn0qaXmysJ9vx3ZEMkViv_B19ju-_ExN8Yn_uSefxpjS6g4Lw@mail.gmail.com/
Link: https://github.com/libimobiledevice/libimobiledevice/issues/1038
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Jakub Kicinski <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/net/usb/ipheth.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/net/usb/ipheth.c
+++ b/drivers/net/usb/ipheth.c
@@ -59,7 +59,7 @@
#define IPHETH_USBINTF_SUBCLASS 253
#define IPHETH_USBINTF_PROTO 1

-#define IPHETH_BUF_SIZE 1516
+#define IPHETH_BUF_SIZE 1514
#define IPHETH_IP_ALIGN 2 /* padding at front of URB */
#define IPHETH_TX_TIMEOUT (5 * HZ)



2020-12-06 11:47:23

by Greg KH

[permalink] [raw]
Subject: [PATCH 5.9 16/46] netfilter: bridge: reset skb->pkt_type after NF_INET_POST_ROUTING traversal

From: Antoine Tenart <[email protected]>

[ Upstream commit 44f64f23bae2f0fad25503bc7ab86cd08d04cd47 ]

Netfilter changes PACKET_OTHERHOST to PACKET_HOST before invoking the
hooks as, while it's an expected value for a bridge, routing expects
PACKET_HOST. The change is undone later on after hook traversal. This
can be seen with pairs of functions updating skb>pkt_type and then
reverting it to its original value:

For hook NF_INET_PRE_ROUTING:
setup_pre_routing / br_nf_pre_routing_finish

For hook NF_INET_FORWARD:
br_nf_forward_ip / br_nf_forward_finish

But the third case where netfilter does this, for hook
NF_INET_POST_ROUTING, the packet type is changed in br_nf_post_routing
but never reverted. A comment says:

/* We assume any code from br_dev_queue_push_xmit onwards doesn't care
* about the value of skb->pkt_type. */

But when having a tunnel (say vxlan) attached to a bridge we have the
following call trace:

br_nf_pre_routing
br_nf_pre_routing_ipv6
br_nf_pre_routing_finish
br_nf_forward_ip
br_nf_forward_finish
br_nf_post_routing <- pkt_type is updated to PACKET_HOST
br_nf_dev_queue_xmit <- but not reverted to its original value
vxlan_xmit
vxlan_xmit_one
skb_tunnel_check_pmtu <- a check on pkt_type is performed

In this specific case, this creates issues such as when an ICMPv6 PTB
should be sent back. When CONFIG_BRIDGE_NETFILTER is enabled, the PTB
isn't sent (as skb_tunnel_check_pmtu checks if pkt_type is PACKET_HOST
and returns early).

If the comment is right and no one cares about the value of
skb->pkt_type after br_dev_queue_push_xmit (which isn't true), resetting
it to its original value should be safe.

Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Signed-off-by: Antoine Tenart <[email protected]>
Reviewed-by: Florian Westphal <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Jakub Kicinski <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
net/bridge/br_netfilter_hooks.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)

--- a/net/bridge/br_netfilter_hooks.c
+++ b/net/bridge/br_netfilter_hooks.c
@@ -735,6 +735,11 @@ static int br_nf_dev_queue_xmit(struct n
mtu_reserved = nf_bridge_mtu_reduction(skb);
mtu = skb->dev->mtu;

+ if (nf_bridge->pkt_otherhost) {
+ skb->pkt_type = PACKET_OTHERHOST;
+ nf_bridge->pkt_otherhost = false;
+ }
+
if (nf_bridge->frag_max_size && nf_bridge->frag_max_size < mtu)
mtu = nf_bridge->frag_max_size;

@@ -835,8 +840,6 @@ static unsigned int br_nf_post_routing(v
else
return NF_ACCEPT;

- /* We assume any code from br_dev_queue_push_xmit onwards doesn't care
- * about the value of skb->pkt_type. */
if (skb->pkt_type == PACKET_OTHERHOST) {
skb->pkt_type = PACKET_HOST;
nf_bridge->pkt_otherhost = true;


2020-12-06 11:47:24

by Greg KH

[permalink] [raw]
Subject: [PATCH 5.9 41/46] Input: i8042 - add ByteSpeed touchpad to noloop table

From: Po-Hsu Lin <[email protected]>

commit a48491c65b513e5cdc3e7a886a4db915f848a5f5 upstream.

It looks like the C15B laptop got another vendor: ByteSpeed LLC.

Avoid AUX loopback on this touchpad as well, thus input subsystem will
be able to recognize a Synaptics touchpad in the AUX port.

BugLink: https://bugs.launchpad.net/bugs/1906128
Signed-off-by: Po-Hsu Lin <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Cc: [email protected]
Signed-off-by: Dmitry Torokhov <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/input/serio/i8042-x86ia64io.h | 4 ++++
1 file changed, 4 insertions(+)

--- a/drivers/input/serio/i8042-x86ia64io.h
+++ b/drivers/input/serio/i8042-x86ia64io.h
@@ -219,6 +219,10 @@ static const struct dmi_system_id __init
DMI_MATCH(DMI_SYS_VENDOR, "PEGATRON CORPORATION"),
DMI_MATCH(DMI_PRODUCT_NAME, "C15B"),
},
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "ByteSpeed LLC"),
+ DMI_MATCH(DMI_PRODUCT_NAME, "ByteSpeed Laptop C15B"),
+ },
},
{ }
};


2020-12-06 11:47:50

by Greg KH

[permalink] [raw]
Subject: [PATCH 5.9 46/46] drm/i915/gt: Fixup tgl mocs for PTE tracking

From: Chris Wilson <[email protected]>

commit be33805c65297611971003d72e7f9235e23ec84d upstream.

Forcing mocs:1 [used for our winsys follows-pte mode] to be cached
caused display glitches. Though it is documented as deprecated (and so
likely behaves as uncached) use the follow-pte bit and force it out of
L3 cache.

Testcase: igt/kms_frontbuffer_tracking
Testcase: igt/kms_big_fb
Signed-off-by: Chris Wilson <[email protected]>
Cc: Ayaz A Siddiqui <[email protected]>
Cc: Lucas De Marchi <[email protected]>
Cc: Matt Roper <[email protected]>
Cc: Ville Syrjälä <[email protected]>
Cc: Joonas Lahtinen <[email protected]>
Reviewed-by: Ville Syrjälä <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
(cherry picked from commit a04ac827366594c7244f60e9be79fcb404af69f0)
Fixes: 849c0fe9e831 ("drm/i915/gt: Initialize reserved and unspecified MOCS indices")
Signed-off-by: Rodrigo Vivi <[email protected]>
[Rodrigo: Updated Fixes tag]
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/gpu/drm/i915/gt/intel_mocs.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)

--- a/drivers/gpu/drm/i915/gt/intel_mocs.c
+++ b/drivers/gpu/drm/i915/gt/intel_mocs.c
@@ -243,8 +243,9 @@ static const struct drm_i915_mocs_entry
* only, __init_mocs_table() take care to program unused index with
* this entry.
*/
- MOCS_ENTRY(1, LE_3_WB | LE_TC_1_LLC | LE_LRUM(3),
- L3_3_WB),
+ MOCS_ENTRY(I915_MOCS_PTE,
+ LE_0_PAGETABLE | LE_TC_0_PAGETABLE,
+ L3_1_UC),
GEN11_MOCS_ENTRIES,

/* Implicitly enable L1 - HDC:L1 + L3 + LLC */


2020-12-06 11:47:52

by Greg KH

[permalink] [raw]
Subject: [PATCH 5.9 15/46] net/packet: fix packet receive on L3 devices without visible hard header

From: Eyal Birger <[email protected]>

[ Upstream commit d549699048b4b5c22dd710455bcdb76966e55aa3 ]

In the patchset merged by commit b9fcf0a0d826
("Merge branch 'support-AF_PACKET-for-layer-3-devices'") L3 devices which
did not have header_ops were given one for the purpose of protocol parsing
on af_packet transmit path.

That change made af_packet receive path regard these devices as having a
visible L3 header and therefore aligned incoming skb->data to point to the
skb's mac_header. Some devices, such as ipip, xfrmi, and others, do not
reset their mac_header prior to ingress and therefore their incoming
packets became malformed.

Ideally these devices would reset their mac headers, or af_packet would be
able to rely on dev->hard_header_len being 0 for such cases, but it seems
this is not the case.

Fix by changing af_packet RX ll visibility criteria to include the
existence of a '.create()' header operation, which is used when creating
a device hard header - via dev_hard_header() - by upper layers, and does
not exist in these L3 devices.

As this predicate may be useful in other situations, add it as a common
dev_has_header() helper in netdevice.h.

Fixes: b9fcf0a0d826 ("Merge branch 'support-AF_PACKET-for-layer-3-devices'")
Signed-off-by: Eyal Birger <[email protected]>
Acked-by: Jason A. Donenfeld <[email protected]>
Acked-by: Willem de Bruijn <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Jakub Kicinski <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
include/linux/netdevice.h | 5 +++++
net/packet/af_packet.c | 38 +++++++++++++++++++++-----------------
2 files changed, 26 insertions(+), 17 deletions(-)

--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -3103,6 +3103,11 @@ static inline bool dev_validate_header(c
return false;
}

+static inline bool dev_has_header(const struct net_device *dev)
+{
+ return dev->header_ops && dev->header_ops->create;
+}
+
typedef int gifconf_func_t(struct net_device * dev, char __user * bufptr,
int len, int size);
int register_gifconf(unsigned int family, gifconf_func_t *gifconf);
--- a/net/packet/af_packet.c
+++ b/net/packet/af_packet.c
@@ -93,38 +93,42 @@

/*
Assumptions:
- - if device has no dev->hard_header routine, it adds and removes ll header
- inside itself. In this case ll header is invisible outside of device,
- but higher levels still should reserve dev->hard_header_len.
- Some devices are enough clever to reallocate skb, when header
- will not fit to reserved space (tunnel), another ones are silly
- (PPP).
+ - If the device has no dev->header_ops->create, there is no LL header
+ visible above the device. In this case, its hard_header_len should be 0.
+ The device may prepend its own header internally. In this case, its
+ needed_headroom should be set to the space needed for it to add its
+ internal header.
+ For example, a WiFi driver pretending to be an Ethernet driver should
+ set its hard_header_len to be the Ethernet header length, and set its
+ needed_headroom to be (the real WiFi header length - the fake Ethernet
+ header length).
- packet socket receives packets with pulled ll header,
so that SOCK_RAW should push it back.

On receive:
-----------

-Incoming, dev->hard_header!=NULL
+Incoming, dev_has_header(dev) == true
mac_header -> ll header
data -> data

-Outgoing, dev->hard_header!=NULL
+Outgoing, dev_has_header(dev) == true
mac_header -> ll header
data -> ll header

-Incoming, dev->hard_header==NULL
- mac_header -> UNKNOWN position. It is very likely, that it points to ll
- header. PPP makes it, that is wrong, because introduce
- assymetry between rx and tx paths.
+Incoming, dev_has_header(dev) == false
+ mac_header -> data
+ However drivers often make it point to the ll header.
+ This is incorrect because the ll header should be invisible to us.
data -> data

-Outgoing, dev->hard_header==NULL
- mac_header -> data. ll header is still not built!
+Outgoing, dev_has_header(dev) == false
+ mac_header -> data. ll header is invisible to us.
data -> data

Resume
- If dev->hard_header==NULL we are unlikely to restore sensible ll header.
+ If dev_has_header(dev) == false we are unable to restore the ll header,
+ because it is invisible to us.


On transmit:
@@ -2066,7 +2070,7 @@ static int packet_rcv(struct sk_buff *sk

skb->dev = dev;

- if (dev->header_ops) {
+ if (dev_has_header(dev)) {
/* The device has an explicit notion of ll header,
* exported to higher levels.
*
@@ -2195,7 +2199,7 @@ static int tpacket_rcv(struct sk_buff *s
if (!net_eq(dev_net(dev), sock_net(sk)))
goto drop;

- if (dev->header_ops) {
+ if (dev_has_header(dev)) {
if (sk->sk_type != SOCK_DGRAM)
skb_push(skb, skb->data - skb_mac_header(skb));
else if (skb->pkt_type == PACKET_OUTGOING) {


2020-12-06 11:47:58

by Greg KH

[permalink] [raw]
Subject: [PATCH 5.9 44/46] tracing: Remove WARN_ON in start_thread()

From: Vasily Averin <[email protected]>

commit 310e3a4b5a4fc718a72201c1e4cf5c64ac6f5442 upstream.

This patch reverts commit 978defee11a5 ("tracing: Do a WARN_ON()
if start_thread() in hwlat is called when thread exists")

.start hook can be legally called several times if according
tracer is stopped

screen window 1
[root@localhost ~]# echo 1 > /sys/kernel/tracing/events/kmem/kfree/enable
[root@localhost ~]# echo 1 > /sys/kernel/tracing/options/pause-on-trace
[root@localhost ~]# less -F /sys/kernel/tracing/trace

screen window 2
[root@localhost ~]# cat /sys/kernel/debug/tracing/tracing_on
0
[root@localhost ~]# echo hwlat > /sys/kernel/debug/tracing/current_tracer
[root@localhost ~]# echo 1 > /sys/kernel/debug/tracing/tracing_on
[root@localhost ~]# cat /sys/kernel/debug/tracing/tracing_on
0
[root@localhost ~]# echo 2 > /sys/kernel/debug/tracing/tracing_on

triggers warning in dmesg:
WARNING: CPU: 3 PID: 1403 at kernel/trace/trace_hwlat.c:371 hwlat_tracer_start+0xc9/0xd0

Link: https://lkml.kernel.org/r/[email protected]

Cc: Ingo Molnar <[email protected]>
Cc: [email protected]
Fixes: 978defee11a5 ("tracing: Do a WARN_ON() if start_thread() in hwlat is called when thread exists")
Signed-off-by: Vasily Averin <[email protected]>
Signed-off-by: Steven Rostedt (VMware) <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
kernel/trace/trace_hwlat.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/kernel/trace/trace_hwlat.c
+++ b/kernel/trace/trace_hwlat.c
@@ -368,7 +368,7 @@ static int start_kthread(struct trace_ar
struct task_struct *kthread;
int next_cpu;

- if (WARN_ON(hwlat_kthread))
+ if (hwlat_kthread)
return 0;

/* Just pick the first CPU on first iteration */


2020-12-06 11:47:59

by Greg KH

[permalink] [raw]
Subject: [PATCH 5.9 07/46] net/tls: Protect from calling tls_dev_del for TLS RX twice

From: Maxim Mikityanskiy <[email protected]>

[ Upstream commit 025cc2fb6a4e84e9a0552c0017dcd1c24b7ac7da ]

tls_device_offload_cleanup_rx doesn't clear tls_ctx->netdev after
calling tls_dev_del if TLX TX offload is also enabled. Clearing
tls_ctx->netdev gets postponed until tls_device_gc_task. It leaves a
time frame when tls_device_down may get called and call tls_dev_del for
RX one extra time, confusing the driver, which may lead to a crash.

This patch corrects this racy behavior by adding a flag to prevent
tls_device_down from calling tls_dev_del the second time.

Fixes: e8f69799810c ("net/tls: Add generic NIC offload infrastructure")
Signed-off-by: Maxim Mikityanskiy <[email protected]>
Signed-off-by: Saeed Mahameed <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Jakub Kicinski <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
include/net/tls.h | 6 ++++++
net/tls/tls_device.c | 5 ++++-
2 files changed, 10 insertions(+), 1 deletion(-)

--- a/include/net/tls.h
+++ b/include/net/tls.h
@@ -199,6 +199,12 @@ enum tls_context_flags {
* to be atomic.
*/
TLS_TX_SYNC_SCHED = 1,
+ /* tls_dev_del was called for the RX side, device state was released,
+ * but tls_ctx->netdev might still be kept, because TX-side driver
+ * resources might not be released yet. Used to prevent the second
+ * tls_dev_del call in tls_device_down if it happens simultaneously.
+ */
+ TLS_RX_DEV_CLOSED = 2,
};

struct cipher_context {
--- a/net/tls/tls_device.c
+++ b/net/tls/tls_device.c
@@ -1262,6 +1262,8 @@ void tls_device_offload_cleanup_rx(struc
if (tls_ctx->tx_conf != TLS_HW) {
dev_put(netdev);
tls_ctx->netdev = NULL;
+ } else {
+ set_bit(TLS_RX_DEV_CLOSED, &tls_ctx->flags);
}
out:
up_read(&device_offload_lock);
@@ -1291,7 +1293,8 @@ static int tls_device_down(struct net_de
if (ctx->tx_conf == TLS_HW)
netdev->tlsdev_ops->tls_dev_del(netdev, ctx,
TLS_OFFLOAD_CTX_DIR_TX);
- if (ctx->rx_conf == TLS_HW)
+ if (ctx->rx_conf == TLS_HW &&
+ !test_bit(TLS_RX_DEV_CLOSED, &ctx->flags))
netdev->tlsdev_ops->tls_dev_del(netdev, ctx,
TLS_OFFLOAD_CTX_DIR_RX);
WRITE_ONCE(ctx->netdev, NULL);


2020-12-06 11:48:06

by Greg KH

[permalink] [raw]
Subject: [PATCH 5.9 04/46] net/af_iucv: set correct sk_protocol for child sockets

From: Julian Wiedmann <[email protected]>

[ Upstream commit c5dab0941fcdc9664eb0ec0d4d51433216d91336 ]

Child sockets erroneously inherit their parent's sk_type (ie. SOCK_*),
instead of the PF_IUCV protocol that the parent was created with in
iucv_sock_create().

We're currently not using sk->sk_protocol ourselves, so this shouldn't
have much impact (except eg. getting the output in skb_dump() right).

Fixes: eac3731bd04c ("[S390]: Add AF_IUCV socket support")
Signed-off-by: Julian Wiedmann <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Jakub Kicinski <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
net/iucv/af_iucv.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

--- a/net/iucv/af_iucv.c
+++ b/net/iucv/af_iucv.c
@@ -1645,7 +1645,7 @@ static int iucv_callback_connreq(struct
}

/* Create the new socket */
- nsk = iucv_sock_alloc(NULL, sk->sk_type, GFP_ATOMIC, 0);
+ nsk = iucv_sock_alloc(NULL, sk->sk_protocol, GFP_ATOMIC, 0);
if (!nsk) {
err = pr_iucv->path_sever(path, user_data);
iucv_path_free(path);
@@ -1851,7 +1851,7 @@ static int afiucv_hs_callback_syn(struct
goto out;
}

- nsk = iucv_sock_alloc(NULL, sk->sk_type, GFP_ATOMIC, 0);
+ nsk = iucv_sock_alloc(NULL, sk->sk_protocol, GFP_ATOMIC, 0);
bh_lock_sock(sk);
if ((sk->sk_state != IUCV_LISTEN) ||
sk_acceptq_is_full(sk) ||


2020-12-06 11:48:15

by Greg KH

[permalink] [raw]
Subject: [PATCH 5.9 40/46] Input: xpad - support Ardwiino Controllers

From: Sanjay Govind <[email protected]>

commit 2aab1561439032be2e98811dd0ddbeb5b2ae4c61 upstream.

This commit adds support for Ardwiino Controllers

Signed-off-by: Sanjay Govind <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Cc: [email protected]
Signed-off-by: Dmitry Torokhov <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/input/joystick/xpad.c | 2 ++
1 file changed, 2 insertions(+)

--- a/drivers/input/joystick/xpad.c
+++ b/drivers/input/joystick/xpad.c
@@ -241,6 +241,7 @@ static const struct xpad_device {
{ 0x1038, 0x1430, "SteelSeries Stratus Duo", 0, XTYPE_XBOX360 },
{ 0x1038, 0x1431, "SteelSeries Stratus Duo", 0, XTYPE_XBOX360 },
{ 0x11c9, 0x55f0, "Nacon GC-100XF", 0, XTYPE_XBOX360 },
+ { 0x1209, 0x2882, "Ardwiino Controller", 0, XTYPE_XBOX360 },
{ 0x12ab, 0x0004, "Honey Bee Xbox360 dancepad", MAP_DPAD_TO_BUTTONS, XTYPE_XBOX360 },
{ 0x12ab, 0x0301, "PDP AFTERGLOW AX.1", 0, XTYPE_XBOX360 },
{ 0x12ab, 0x0303, "Mortal Kombat Klassic FightStick", MAP_TRIGGERS_TO_BUTTONS, XTYPE_XBOX360 },
@@ -418,6 +419,7 @@ static const struct usb_device_id xpad_t
XPAD_XBOXONE_VENDOR(0x0f0d), /* Hori Controllers */
XPAD_XBOX360_VENDOR(0x1038), /* SteelSeries Controllers */
XPAD_XBOX360_VENDOR(0x11c9), /* Nacon GC100XF */
+ XPAD_XBOX360_VENDOR(0x1209), /* Ardwiino Controllers */
XPAD_XBOX360_VENDOR(0x12ab), /* X-Box 360 dance pads */
XPAD_XBOX360_VENDOR(0x1430), /* RedOctane X-Box 360 controllers */
XPAD_XBOX360_VENDOR(0x146b), /* BigBen Interactive Controllers */


2020-12-06 11:48:25

by Greg KH

[permalink] [raw]
Subject: [PATCH 5.9 33/46] net: skbuff: ensure LSE is pullable before decrementing the MPLS ttl

From: Davide Caratti <[email protected]>

[ Upstream commit 13de4ed9e3a9ccbe54d05f7d5c773f69ecaf6c64 ]

skb_mpls_dec_ttl() reads the LSE without ensuring that it is contained in
the skb "linear" area. Fix this calling pskb_may_pull() before reading the
current ttl.

Found by code inspection.

Fixes: 2a2ea50870ba ("net: sched: add mpls manipulation actions to TC")
Reported-by: Marcelo Ricardo Leitner <[email protected]>
Signed-off-by: Davide Caratti <[email protected]>
Link: https://lore.kernel.org/r/53659f28be8bc336c113b5254dc637cc76bbae91.1606987074.git.dcaratti@redhat.com
Signed-off-by: Jakub Kicinski <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
net/core/skbuff.c | 3 +++
1 file changed, 3 insertions(+)

--- a/net/core/skbuff.c
+++ b/net/core/skbuff.c
@@ -5725,6 +5725,9 @@ int skb_mpls_dec_ttl(struct sk_buff *skb
if (unlikely(!eth_p_mpls(skb->protocol)))
return -EINVAL;

+ if (!pskb_may_pull(skb, skb_network_offset(skb) + MPLS_HLEN))
+ return -ENOMEM;
+
lse = be32_to_cpu(mpls_hdr(skb)->label_stack_entry);
ttl = (lse & MPLS_LS_TTL_MASK) >> MPLS_LS_TTL_SHIFT;
if (!--ttl)


2020-12-06 11:48:26

by Greg KH

[permalink] [raw]
Subject: [PATCH 5.9 37/46] net/mlx5: Fix wrong address reclaim when command interface is down

From: Eran Ben Elisha <[email protected]>

[ Upstream commit 1d2bb5ad89f47d8ce8aedc70ef85059ab3870292 ]

When command interface is down, driver to reclaim all 4K page chucks that
were hold by the Firmeware. Fix a bug for 64K page size systems, where
driver repeatedly released only the first chunk of the page.

Define helper function to fill 4K chunks for a given Firmware pages.
Iterate over all unreleased Firmware pages and call the hepler per each.

Fixes: 5adff6a08862 ("net/mlx5: Fix incorrect page count when in internal error")
Signed-off-by: Eran Ben Elisha <[email protected]>
Signed-off-by: Saeed Mahameed <[email protected]>
Signed-off-by: Jakub Kicinski <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/net/ethernet/mellanox/mlx5/core/pagealloc.c | 21 ++++++++++++++++++--
1 file changed, 19 insertions(+), 2 deletions(-)

--- a/drivers/net/ethernet/mellanox/mlx5/core/pagealloc.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/pagealloc.c
@@ -422,6 +422,24 @@ static void release_all_pages(struct mlx
npages, ec_function, func_id);
}

+static u32 fwp_fill_manage_pages_out(struct fw_page *fwp, u32 *out, u32 index,
+ u32 npages)
+{
+ u32 pages_set = 0;
+ unsigned int n;
+
+ for_each_clear_bit(n, &fwp->bitmask, MLX5_NUM_4K_IN_PAGE) {
+ MLX5_ARRAY_SET64(manage_pages_out, out, pas, index + pages_set,
+ fwp->addr + (n * MLX5_ADAPTER_PAGE_SIZE));
+ pages_set++;
+
+ if (!--npages)
+ break;
+ }
+
+ return pages_set;
+}
+
static int reclaim_pages_cmd(struct mlx5_core_dev *dev,
u32 *in, int in_size, u32 *out, int out_size)
{
@@ -448,8 +466,7 @@ static int reclaim_pages_cmd(struct mlx5
fwp = rb_entry(p, struct fw_page, rb_node);
p = rb_next(p);

- MLX5_ARRAY_SET64(manage_pages_out, out, pas, i, fwp->addr);
- i++;
+ i += fwp_fill_manage_pages_out(fwp, out, i, npages - i);
}

MLX5_SET(manage_pages_out, out, output_num_entries, i);


2020-12-06 11:48:28

by Greg KH

[permalink] [raw]
Subject: [PATCH 5.9 24/46] geneve: pull IP header before ECN decapsulation

From: Eric Dumazet <[email protected]>

[ Upstream commit 4179b00c04d18ea7013f68d578d80f3c9d13150a ]

IP_ECN_decapsulate() and IP6_ECN_decapsulate() assume
IP header is already pulled.

geneve does not ensure this yet.

Fixing this generically in IP_ECN_decapsulate() and
IP6_ECN_decapsulate() is not possible, since callers
pass a pointer that might be freed by pskb_may_pull()

syzbot reported :

BUG: KMSAN: uninit-value in __INET_ECN_decapsulate include/net/inet_ecn.h:238 [inline]
BUG: KMSAN: uninit-value in INET_ECN_decapsulate+0x345/0x1db0 include/net/inet_ecn.h:260
CPU: 1 PID: 8941 Comm: syz-executor.0 Not tainted 5.10.0-rc4-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
Call Trace:
<IRQ>
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x21c/0x280 lib/dump_stack.c:118
kmsan_report+0xf7/0x1e0 mm/kmsan/kmsan_report.c:118
__msan_warning+0x5f/0xa0 mm/kmsan/kmsan_instr.c:197
__INET_ECN_decapsulate include/net/inet_ecn.h:238 [inline]
INET_ECN_decapsulate+0x345/0x1db0 include/net/inet_ecn.h:260
geneve_rx+0x2103/0x2980 include/net/inet_ecn.h:306
geneve_udp_encap_recv+0x105c/0x1340 drivers/net/geneve.c:377
udp_queue_rcv_one_skb+0x193a/0x1af0 net/ipv4/udp.c:2093
udp_queue_rcv_skb+0x282/0x1050 net/ipv4/udp.c:2167
udp_unicast_rcv_skb net/ipv4/udp.c:2325 [inline]
__udp4_lib_rcv+0x399d/0x5880 net/ipv4/udp.c:2394
udp_rcv+0x5c/0x70 net/ipv4/udp.c:2564
ip_protocol_deliver_rcu+0x572/0xc50 net/ipv4/ip_input.c:204
ip_local_deliver_finish net/ipv4/ip_input.c:231 [inline]
NF_HOOK include/linux/netfilter.h:301 [inline]
ip_local_deliver+0x583/0x8d0 net/ipv4/ip_input.c:252
dst_input include/net/dst.h:449 [inline]
ip_rcv_finish net/ipv4/ip_input.c:428 [inline]
NF_HOOK include/linux/netfilter.h:301 [inline]
ip_rcv+0x5c3/0x840 net/ipv4/ip_input.c:539
__netif_receive_skb_one_core net/core/dev.c:5315 [inline]
__netif_receive_skb+0x1ec/0x640 net/core/dev.c:5429
process_backlog+0x523/0xc10 net/core/dev.c:6319
napi_poll+0x420/0x1010 net/core/dev.c:6763
net_rx_action+0x35c/0xd40 net/core/dev.c:6833
__do_softirq+0x1a9/0x6fa kernel/softirq.c:298
asm_call_irq_on_stack+0xf/0x20
</IRQ>
__run_on_irqstack arch/x86/include/asm/irq_stack.h:26 [inline]
run_on_irqstack_cond arch/x86/include/asm/irq_stack.h:77 [inline]
do_softirq_own_stack+0x6e/0x90 arch/x86/kernel/irq_64.c:77
do_softirq kernel/softirq.c:343 [inline]
__local_bh_enable_ip+0x184/0x1d0 kernel/softirq.c:195
local_bh_enable+0x36/0x40 include/linux/bottom_half.h:32
rcu_read_unlock_bh include/linux/rcupdate.h:730 [inline]
__dev_queue_xmit+0x3a9b/0x4520 net/core/dev.c:4167
dev_queue_xmit+0x4b/0x60 net/core/dev.c:4173
packet_snd net/packet/af_packet.c:2992 [inline]
packet_sendmsg+0x86f9/0x99d0 net/packet/af_packet.c:3017
sock_sendmsg_nosec net/socket.c:651 [inline]
sock_sendmsg net/socket.c:671 [inline]
__sys_sendto+0x9dc/0xc80 net/socket.c:1992
__do_sys_sendto net/socket.c:2004 [inline]
__se_sys_sendto+0x107/0x130 net/socket.c:2000
__x64_sys_sendto+0x6e/0x90 net/socket.c:2000
do_syscall_64+0x9f/0x140 arch/x86/entry/common.c:48
entry_SYSCALL_64_after_hwframe+0x44/0xa9

Fixes: 2d07dc79fe04 ("geneve: add initial netdev driver for GENEVE tunnels")
Signed-off-by: Eric Dumazet <[email protected]>
Reported-by: syzbot <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Jakub Kicinski <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/net/geneve.c | 20 ++++++++++++++++----
1 file changed, 16 insertions(+), 4 deletions(-)

--- a/drivers/net/geneve.c
+++ b/drivers/net/geneve.c
@@ -258,11 +258,21 @@ static void geneve_rx(struct geneve_dev
skb_dst_set(skb, &tun_dst->dst);

/* Ignore packet loops (and multicast echo) */
- if (ether_addr_equal(eth_hdr(skb)->h_source, geneve->dev->dev_addr)) {
- geneve->dev->stats.rx_errors++;
- goto drop;
- }
+ if (ether_addr_equal(eth_hdr(skb)->h_source, geneve->dev->dev_addr))
+ goto rx_error;

+ switch (skb_protocol(skb, true)) {
+ case htons(ETH_P_IP):
+ if (pskb_may_pull(skb, sizeof(struct iphdr)))
+ goto rx_error;
+ break;
+ case htons(ETH_P_IPV6):
+ if (pskb_may_pull(skb, sizeof(struct ipv6hdr)))
+ goto rx_error;
+ break;
+ default:
+ goto rx_error;
+ }
oiph = skb_network_header(skb);
skb_reset_network_header(skb);

@@ -303,6 +313,8 @@ static void geneve_rx(struct geneve_dev
u64_stats_update_end(&stats->syncp);
}
return;
+rx_error:
+ geneve->dev->stats.rx_errors++;
drop:
/* Consume bad packet */
kfree_skb(skb);


2020-12-06 11:48:28

by Greg KH

[permalink] [raw]
Subject: [PATCH 5.9 20/46] ibmvnic: Ensure that SCRQ entry reads are correctly ordered

From: Thomas Falcon <[email protected]>

[ Upstream commit b71ec952234610b4f90ef17a2fdcb124d5320070 ]

Ensure that received Subordinate Command-Response Queue (SCRQ)
entries are properly read in order by the driver. These queues
are used in the ibmvnic device to process RX buffer and TX completion
descriptors. dma_rmb barriers have been added after checking for a
pending descriptor to ensure the correct descriptor entry is checked
and after reading the SCRQ descriptor to ensure the entire
descriptor is read before processing.

Fixes: 032c5e82847a ("Driver for IBM System i/p VNIC protocol")
Signed-off-by: Thomas Falcon <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/net/ethernet/ibm/ibmvnic.c | 18 ++++++++++++++++++
1 file changed, 18 insertions(+)

--- a/drivers/net/ethernet/ibm/ibmvnic.c
+++ b/drivers/net/ethernet/ibm/ibmvnic.c
@@ -2409,6 +2409,12 @@ restart_poll:

if (!pending_scrq(adapter, adapter->rx_scrq[scrq_num]))
break;
+ /* The queue entry at the current index is peeked at above
+ * to determine that there is a valid descriptor awaiting
+ * processing. We want to be sure that the current slot
+ * holds a valid descriptor before reading its contents.
+ */
+ dma_rmb();
next = ibmvnic_next_scrq(adapter, adapter->rx_scrq[scrq_num]);
rx_buff =
(struct ibmvnic_rx_buff *)be64_to_cpu(next->
@@ -3107,6 +3113,13 @@ restart_loop:
unsigned int pool = scrq->pool_index;
int num_entries = 0;

+ /* The queue entry at the current index is peeked at above
+ * to determine that there is a valid descriptor awaiting
+ * processing. We want to be sure that the current slot
+ * holds a valid descriptor before reading its contents.
+ */
+ dma_rmb();
+
next = ibmvnic_next_scrq(adapter, scrq);
for (i = 0; i < next->tx_comp.num_comps; i++) {
if (next->tx_comp.rcs[i]) {
@@ -3507,6 +3520,11 @@ static union sub_crq *ibmvnic_next_scrq(
}
spin_unlock_irqrestore(&scrq->lock, flags);

+ /* Ensure that the entire buffer descriptor has been
+ * loaded before reading its contents
+ */
+ dma_rmb();
+
return entry;
}



2020-12-06 11:48:28

by Greg KH

[permalink] [raw]
Subject: [PATCH 5.9 19/46] chelsio/chtls: fix panic during unload reload chtls

From: Vinay Kumar Yadav <[email protected]>

[ Upstream commit e3d5e971d2f83d8ddd4b91a50cea4517fb488383 ]

there is kernel panic in inet_twsk_free() while chtls
module unload when socket is in TIME_WAIT state because
sk_prot_creator was not preserved on connection socket.

Fixes: cc35c88ae4db ("crypto : chtls - CPL handler definition")
Signed-off-by: Udai Sharma <[email protected]>
Signed-off-by: Vinay Kumar Yadav <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Jakub Kicinski <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/crypto/chelsio/chtls/chtls_cm.c | 1 +
1 file changed, 1 insertion(+)

--- a/drivers/crypto/chelsio/chtls/chtls_cm.c
+++ b/drivers/crypto/chelsio/chtls/chtls_cm.c
@@ -1206,6 +1206,7 @@ static struct sock *chtls_recv_sock(stru
sk_setup_caps(newsk, dst);
ctx = tls_get_ctx(lsk);
newsk->sk_destruct = ctx->sk_destruct;
+ newsk->sk_prot_creator = lsk->sk_prot_creator;
csk->sk = newsk;
csk->passive_reap_next = oreq;
csk->tx_chan = cxgb4_port_chan(ndev);


2020-12-06 11:48:33

by Greg KH

[permalink] [raw]
Subject: [PATCH 5.9 21/46] ibmvnic: Fix TX completion error handling

From: Thomas Falcon <[email protected]>

[ Upstream commit ba246c175116e2e8fa4fdfa5f8e958e086a9a818 ]

TX completions received with an error return code are not
being processed properly. When an error code is seen, do not
proceed to the next completion before cleaning up the existing
entry's data structures.

Fixes: 032c5e82847a ("Driver for IBM System i/p VNIC protocol")
Signed-off-by: Thomas Falcon <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/net/ethernet/ibm/ibmvnic.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)

--- a/drivers/net/ethernet/ibm/ibmvnic.c
+++ b/drivers/net/ethernet/ibm/ibmvnic.c
@@ -3122,11 +3122,9 @@ restart_loop:

next = ibmvnic_next_scrq(adapter, scrq);
for (i = 0; i < next->tx_comp.num_comps; i++) {
- if (next->tx_comp.rcs[i]) {
+ if (next->tx_comp.rcs[i])
dev_err(dev, "tx error %x\n",
next->tx_comp.rcs[i]);
- continue;
- }
index = be32_to_cpu(next->tx_comp.correlators[i]);
if (index & IBMVNIC_TSO_POOL_MASK) {
tx_pool = &adapter->tso_pool[pool];


2020-12-06 11:48:33

by Greg KH

[permalink] [raw]
Subject: [PATCH 5.9 22/46] tipc: fix incompatible mtu of transmission

From: Hoang Le <[email protected]>

[ Upstream commit 0643334902fcdc770e2d9555811200213339a3f6 ]

In commit 682cd3cf946b6
("tipc: confgiure and apply UDP bearer MTU on running links"), we
introduced a function to change UDP bearer MTU and applied this new value
across existing per-link. However, we did not apply this new MTU value at
node level. This lead to packet dropped at link level if its size is
greater than new MTU value.

To fix this issue, we also apply this new MTU value for node level.

Fixes: 682cd3cf946b6 ("tipc: confgiure and apply UDP bearer MTU on running links")
Acked-by: Jon Maloy <[email protected]>
Signed-off-by: Hoang Le <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Jakub Kicinski <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
net/tipc/node.c | 2 ++
1 file changed, 2 insertions(+)

--- a/net/tipc/node.c
+++ b/net/tipc/node.c
@@ -2171,6 +2171,8 @@ void tipc_node_apply_property(struct net
else if (prop == TIPC_NLA_PROP_MTU)
tipc_link_set_mtu(e->link, b->mtu);
}
+ /* Update MTU for node link entry */
+ e->mtu = tipc_link_mss(e->link);
tipc_node_write_unlock(n);
tipc_bearer_xmit(net, bearer_id, &xmitq, &e->maddr, NULL);
}


2020-12-06 11:48:34

by Greg KH

[permalink] [raw]
Subject: [PATCH 5.9 23/46] inet_ecn: Fix endianness of checksum update when setting ECT(1)

From: "Toke H?iland-J?rgensen" <[email protected]>

[ Upstream commit 2867e1eac61016f59b3d730e3f7aa488e186e917 ]

When adding support for propagating ECT(1) marking in IP headers it seems I
suffered from endianness-confusion in the checksum update calculation: In
fact the ECN field is in the *lower* bits of the first 16-bit word of the
IP header when calculating in network byte order. This means that the
addition performed to update the checksum field was wrong; let's fix that.

Fixes: b723748750ec ("tunnel: Propagate ECT(1) when decapsulating as recommended by RFC6040")
Reported-by: Jonathan Morton <[email protected]>
Tested-by: Pete Heist <[email protected]>
Signed-off-by: Toke Høiland-Jørgensen <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Jakub Kicinski <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
include/net/inet_ecn.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/include/net/inet_ecn.h
+++ b/include/net/inet_ecn.h
@@ -107,7 +107,7 @@ static inline int IP_ECN_set_ect1(struct
if ((iph->tos & INET_ECN_MASK) != INET_ECN_ECT_0)
return 0;

- check += (__force u16)htons(0x100);
+ check += (__force u16)htons(0x1);

iph->check = (__force __sum16)(check + (check>=0xFFFF));
iph->tos ^= INET_ECN_MASK;


2020-12-06 11:48:36

by Greg KH

[permalink] [raw]
Subject: [PATCH 5.9 34/46] net: openvswitch: ensure LSE is pullable before reading it

From: Davide Caratti <[email protected]>

[ Upstream commit 43c13605bad44b8abbc9776d6e63f62ccb7a47d6 ]

when openvswitch is configured to mangle the LSE, the current value is
read from the packet dereferencing 4 bytes at mpls_hdr(): ensure that
the label is contained in the skb "linear" area.

Found by code inspection.

Fixes: d27cf5c59a12 ("net: core: add MPLS update core helper and use in OvS")
Signed-off-by: Davide Caratti <[email protected]>
Link: https://lore.kernel.org/r/aa099f245d93218b84b5c056b67b6058ccf81a66.1606987185.git.dcaratti@redhat.com
Signed-off-by: Jakub Kicinski <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
net/openvswitch/actions.c | 3 +++
1 file changed, 3 insertions(+)

--- a/net/openvswitch/actions.c
+++ b/net/openvswitch/actions.c
@@ -200,6 +200,9 @@ static int set_mpls(struct sk_buff *skb,
__be32 lse;
int err;

+ if (!pskb_may_pull(skb, skb_network_offset(skb) + MPLS_HLEN))
+ return -ENOMEM;
+
stack = mpls_hdr(skb);
lse = OVS_MASKED(stack->label_stack_entry, *mpls_lse, *mask);
err = skb_mpls_update_lse(skb, lse);


2020-12-06 11:48:39

by Greg KH

[permalink] [raw]
Subject: [PATCH 5.9 25/46] net: ip6_gre: set dev->hard_header_len when using header_ops

From: Antoine Tenart <[email protected]>

[ Upstream commit 832ba596494b2c9eac7760259eff2d8b7dcad0ee ]

syzkaller managed to crash the kernel using an NBMA ip6gre interface. I
could reproduce it creating an NBMA ip6gre interface and forwarding
traffic to it:

skbuff: skb_under_panic: text:ffffffff8250e927 len:148 put:44 head:ffff8c03c7a33
------------[ cut here ]------------
kernel BUG at net/core/skbuff.c:109!
Call Trace:
skb_push+0x10/0x10
ip6gre_header+0x47/0x1b0
neigh_connected_output+0xae/0xf0

ip6gre tunnel provides its own header_ops->create, and sets it
conditionally when initializing the tunnel in NBMA mode. When
header_ops->create is used, dev->hard_header_len should reflect the
length of the header created. Otherwise, when not used,
dev->needed_headroom should be used.

Fixes: eb95f52fc72d ("net: ipv6_gre: Fix GRO to work on IPv6 over GRE tap")
Cc: Maria Pasechnik <[email protected]>
Signed-off-by: Antoine Tenart <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Jakub Kicinski <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
net/ipv6/ip6_gre.c | 16 +++++++++++++---
1 file changed, 13 insertions(+), 3 deletions(-)

--- a/net/ipv6/ip6_gre.c
+++ b/net/ipv6/ip6_gre.c
@@ -1122,8 +1122,13 @@ static void ip6gre_tnl_link_config_route
return;

if (rt->dst.dev) {
- dev->needed_headroom = rt->dst.dev->hard_header_len +
- t_hlen;
+ unsigned short dst_len = rt->dst.dev->hard_header_len +
+ t_hlen;
+
+ if (t->dev->header_ops)
+ dev->hard_header_len = dst_len;
+ else
+ dev->needed_headroom = dst_len;

if (set_mtu) {
dev->mtu = rt->dst.dev->mtu - t_hlen;
@@ -1148,7 +1153,12 @@ static int ip6gre_calc_hlen(struct ip6_t
tunnel->hlen = tunnel->tun_hlen + tunnel->encap_hlen;

t_hlen = tunnel->hlen + sizeof(struct ipv6hdr);
- tunnel->dev->needed_headroom = LL_MAX_HEADER + t_hlen;
+
+ if (tunnel->dev->header_ops)
+ tunnel->dev->hard_header_len = LL_MAX_HEADER + t_hlen;
+ else
+ tunnel->dev->needed_headroom = LL_MAX_HEADER + t_hlen;
+
return t_hlen;
}



2020-12-06 11:48:45

by Greg KH

[permalink] [raw]
Subject: [PATCH 5.9 09/46] sock: set sk_err to ee_errno on dequeue from errq

From: Willem de Bruijn <[email protected]>

[ Upstream commit 985f7337421a811cb354ca93882f943c8335a6f5 ]

When setting sk_err, set it to ee_errno, not ee_origin.

Commit f5f99309fa74 ("sock: do not set sk_err in
sock_dequeue_err_skb") disabled updating sk_err on errq dequeue,
which is correct for most error types (origins):

- sk->sk_err = err;

Commit 38b257938ac6 ("sock: reset sk_err when the error queue is
empty") reenabled the behavior for IMCP origins, which do require it:

+ if (icmp_next)
+ sk->sk_err = SKB_EXT_ERR(skb_next)->ee.ee_origin;

But read from ee_errno.

Fixes: 38b257938ac6 ("sock: reset sk_err when the error queue is empty")
Reported-by: Ayush Ranjan <[email protected]>
Signed-off-by: Willem de Bruijn <[email protected]>
Acked-by: Soheil Hassas Yeganeh <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Jakub Kicinski <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
net/core/skbuff.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/net/core/skbuff.c
+++ b/net/core/skbuff.c
@@ -4555,7 +4555,7 @@ struct sk_buff *sock_dequeue_err_skb(str
if (skb && (skb_next = skb_peek(q))) {
icmp_next = is_icmp_err_skb(skb_next);
if (icmp_next)
- sk->sk_err = SKB_EXT_ERR(skb_next)->ee.ee_origin;
+ sk->sk_err = SKB_EXT_ERR(skb_next)->ee.ee_errno;
}
spin_unlock_irqrestore(&q->lock, flags);



2020-12-06 11:48:49

by Greg KH

[permalink] [raw]
Subject: [PATCH 5.9 36/46] net/mlx5: DR, Proper handling of unsupported Connect-X6DX SW steering

From: Yevgeny Kliteynik <[email protected]>

[ Upstream commit d421e466c2373095f165ddd25cbabd6c5b077928 ]

STEs format for Connect-X5 and Connect-X6DX different. Currently, on
Connext-X6DX the SW steering would break at some point when building STEs
w/o giving a proper error message. Fix this by checking the STE format of
the current device when initializing domain: add mlx5_ifc definitions for
Connect-X6DX SW steering, read FW capability to get the current format
version, and check this version when domain is being created.

Fixes: 26d688e33f88 ("net/mlx5: DR, Add Steering entry (STE) utilities")
Signed-off-by: Yevgeny Kliteynik <[email protected]>
Signed-off-by: Saeed Mahameed <[email protected]>
Signed-off-by: Jakub Kicinski <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/net/ethernet/mellanox/mlx5/core/steering/dr_cmd.c | 1 +
drivers/net/ethernet/mellanox/mlx5/core/steering/dr_domain.c | 5 +++++
drivers/net/ethernet/mellanox/mlx5/core/steering/dr_types.h | 1 +
include/linux/mlx5/mlx5_ifc.h | 9 ++++++++-
4 files changed, 15 insertions(+), 1 deletion(-)

--- a/drivers/net/ethernet/mellanox/mlx5/core/steering/dr_cmd.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/steering/dr_cmd.c
@@ -92,6 +92,7 @@ int mlx5dr_cmd_query_device(struct mlx5_
caps->eswitch_manager = MLX5_CAP_GEN(mdev, eswitch_manager);
caps->gvmi = MLX5_CAP_GEN(mdev, vhca_id);
caps->flex_protocols = MLX5_CAP_GEN(mdev, flex_parser_protocols);
+ caps->sw_format_ver = MLX5_CAP_GEN(mdev, steering_format_version);

if (mlx5dr_matcher_supp_flex_parser_icmp_v4(caps)) {
caps->flex_parser_id_icmp_dw0 = MLX5_CAP_GEN(mdev, flex_parser_id_icmp_dw0);
--- a/drivers/net/ethernet/mellanox/mlx5/core/steering/dr_domain.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/steering/dr_domain.c
@@ -223,6 +223,11 @@ static int dr_domain_caps_init(struct ml
if (ret)
return ret;

+ if (dmn->info.caps.sw_format_ver != MLX5_STEERING_FORMAT_CONNECTX_5) {
+ mlx5dr_err(dmn, "SW steering is not supported on this device\n");
+ return -EOPNOTSUPP;
+ }
+
ret = dr_domain_query_fdb_caps(mdev, dmn);
if (ret)
return ret;
--- a/drivers/net/ethernet/mellanox/mlx5/core/steering/dr_types.h
+++ b/drivers/net/ethernet/mellanox/mlx5/core/steering/dr_types.h
@@ -621,6 +621,7 @@ struct mlx5dr_cmd_caps {
u8 max_ft_level;
u16 roce_min_src_udp;
u8 num_esw_ports;
+ u8 sw_format_ver;
bool eswitch_manager;
bool rx_sw_owner;
bool tx_sw_owner;
--- a/include/linux/mlx5/mlx5_ifc.h
+++ b/include/linux/mlx5/mlx5_ifc.h
@@ -1222,6 +1222,11 @@ enum mlx5_fc_bulk_alloc_bitmask {

#define MLX5_FC_BULK_NUM_FCS(fc_enum) (MLX5_FC_BULK_SIZE_FACTOR * (fc_enum))

+enum {
+ MLX5_STEERING_FORMAT_CONNECTX_5 = 0,
+ MLX5_STEERING_FORMAT_CONNECTX_6DX = 1,
+};
+
struct mlx5_ifc_cmd_hca_cap_bits {
u8 reserved_at_0[0x30];
u8 vhca_id[0x10];
@@ -1519,7 +1524,9 @@ struct mlx5_ifc_cmd_hca_cap_bits {

u8 general_obj_types[0x40];

- u8 reserved_at_440[0x20];
+ u8 reserved_at_440[0x4];
+ u8 steering_format_version[0x4];
+ u8 create_qp_start_hint[0x18];

u8 reserved_at_460[0x3];
u8 log_max_uctx[0x5];


2020-12-06 11:48:56

by Greg KH

[permalink] [raw]
Subject: [PATCH 5.9 32/46] net: mvpp2: Fix error return code in mvpp2_open()

From: Wang Hai <[email protected]>

[ Upstream commit 82a10dc7f0960735f40e8d7d3bee56934291600f ]

Fix to return negative error code -ENOENT from invalid configuration
error handling case instead of 0, as done elsewhere in this function.

Fixes: 4bb043262878 ("net: mvpp2: phylink support")
Reported-by: Hulk Robot <[email protected]>
Signed-off-by: Wang Hai <[email protected]>
Reviewed-by: Andrew Lunn <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Jakub Kicinski <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c | 1 +
1 file changed, 1 insertion(+)

--- a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
+++ b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
@@ -4249,6 +4249,7 @@ static int mvpp2_open(struct net_device
if (!valid) {
netdev_err(port->dev,
"invalid configuration: no dt or link IRQ");
+ err = -ENOENT;
goto err_free_irq;
}



2020-12-06 11:48:56

by Greg KH

[permalink] [raw]
Subject: [PATCH 5.9 28/46] cxgb3: fix error return code in t3_sge_alloc_qset()

From: Zhang Changzhong <[email protected]>

[ Upstream commit ff9924897f8bfed82e61894b373ab9d2dfea5b10 ]

Fix to return a negative error code from the error handling
case instead of 0, as done elsewhere in this function.

Fixes: b1fb1f280d09 ("cxgb3 - Fix dma mapping error path")
Reported-by: Hulk Robot <[email protected]>
Signed-off-by: Zhang Changzhong <[email protected]>
Acked-by: Raju Rangoju <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Jakub Kicinski <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/net/ethernet/chelsio/cxgb3/sge.c | 1 +
1 file changed, 1 insertion(+)

--- a/drivers/net/ethernet/chelsio/cxgb3/sge.c
+++ b/drivers/net/ethernet/chelsio/cxgb3/sge.c
@@ -3176,6 +3176,7 @@ int t3_sge_alloc_qset(struct adapter *ad
GFP_KERNEL | __GFP_COMP);
if (!avail) {
CH_ALERT(adapter, "free list queue 0 initialization failed\n");
+ ret = -ENOMEM;
goto err;
}
if (avail < q->fl[0].size)


2020-12-06 11:49:12

by Greg KH

[permalink] [raw]
Subject: [PATCH 5.9 45/46] uapi: fix statx attribute value overlap for DAX & MOUNT_ROOT

From: Eric Sandeen <[email protected]>

commit 72d1249e2ffdbc344e465031ec5335fa3489d62e upstream.

STATX_ATTR_MOUNT_ROOT and STATX_ATTR_DAX got merged with the same value,
so one of them needs fixing. Move STATX_ATTR_DAX.

While we're in here, clarify the value-matching scheme for some of the
attributes, and explain why the value for DAX does not match.

Fixes: 80340fe3605c ("statx: add mount_root")
Fixes: 712b2698e4c0 ("fs/stat: Define DAX statx attribute")
Link: https://lore.kernel.org/linux-fsdevel/[email protected]/
Link: https://lore.kernel.org/lkml/[email protected]/
Reported-by: David Howells <[email protected]>
Signed-off-by: Eric Sandeen <[email protected]>
Reviewed-by: David Howells <[email protected]>
Reviewed-by: Darrick J. Wong <[email protected]>
Reviewed-by: Christoph Hellwig <[email protected]>
Reviewed-by: Ira Weiny <[email protected]>
Cc: <[email protected]> # 5.8
Signed-off-by: Linus Torvalds <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
include/uapi/linux/stat.h | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)

--- a/include/uapi/linux/stat.h
+++ b/include/uapi/linux/stat.h
@@ -171,9 +171,12 @@ struct statx {
* be of use to ordinary userspace programs such as GUIs or ls rather than
* specialised tools.
*
- * Note that the flags marked [I] correspond to generic FS_IOC_FLAGS
+ * Note that the flags marked [I] correspond to the FS_IOC_SETFLAGS flags
* semantically. Where possible, the numerical value is picked to correspond
- * also.
+ * also. Note that the DAX attribute indicates that the file is in the CPU
+ * direct access state. It does not correspond to the per-inode flag that
+ * some filesystems support.
+ *
*/
#define STATX_ATTR_COMPRESSED 0x00000004 /* [I] File is compressed by the fs */
#define STATX_ATTR_IMMUTABLE 0x00000010 /* [I] File is marked immutable */
@@ -183,7 +186,7 @@ struct statx {
#define STATX_ATTR_AUTOMOUNT 0x00001000 /* Dir: Automount trigger */
#define STATX_ATTR_MOUNT_ROOT 0x00002000 /* Root of a mount */
#define STATX_ATTR_VERITY 0x00100000 /* [I] Verity protected file */
-#define STATX_ATTR_DAX 0x00002000 /* [I] File is DAX */
+#define STATX_ATTR_DAX 0x00200000 /* File is currently in DAX state */


#endif /* _UAPI_LINUX_STAT_H */


2020-12-06 11:49:21

by Greg KH

[permalink] [raw]
Subject: [PATCH 5.9 39/46] ALSA: usb-audio: US16x08: fix value count for level meters

From: Hector Martin <[email protected]>

commit 402d5840b0d40a2a26c8651165d29b534abb6d36 upstream.

The level meter control returns 34 integers of info. This fixes:

snd-usb-audio 3-1:1.0: control 2:0:0:Level Meter:0: access overflow

Fixes: d2bb390a2081 ("ALSA: usb-audio: Tascam US-16x08 DSP mixer quirk")
Cc: [email protected]
Signed-off-by: Hector Martin <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Takashi Iwai <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
sound/usb/mixer_us16x08.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/sound/usb/mixer_us16x08.c
+++ b/sound/usb/mixer_us16x08.c
@@ -607,7 +607,7 @@ static int snd_us16x08_eq_put(struct snd
static int snd_us16x08_meter_info(struct snd_kcontrol *kcontrol,
struct snd_ctl_elem_info *uinfo)
{
- uinfo->count = 1;
+ uinfo->count = 34;
uinfo->type = SNDRV_CTL_ELEM_TYPE_INTEGER;
uinfo->value.integer.max = 0x7FFF;
uinfo->value.integer.min = 0;


2020-12-06 11:49:21

by Greg KH

[permalink] [raw]
Subject: [PATCH 5.9 11/46] tun: honor IOCB_NOWAIT flag

From: Jens Axboe <[email protected]>

[ Upstream commit 5aac0390a63b8718237a61dd0d24a29201d1c94a ]

tun only checks the file O_NONBLOCK flag, but it should also be checking
the iocb IOCB_NOWAIT flag. Any fops using ->read/write_iter() should check
both, otherwise it breaks users that correctly expect O_NONBLOCK semantics
if IOCB_NOWAIT is set.

Signed-off-by: Jens Axboe <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Jakub Kicinski <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/net/tun.c | 14 +++++++++++---
1 file changed, 11 insertions(+), 3 deletions(-)

--- a/drivers/net/tun.c
+++ b/drivers/net/tun.c
@@ -1979,12 +1979,15 @@ static ssize_t tun_chr_write_iter(struct
struct tun_file *tfile = file->private_data;
struct tun_struct *tun = tun_get(tfile);
ssize_t result;
+ int noblock = 0;

if (!tun)
return -EBADFD;

- result = tun_get_user(tun, tfile, NULL, from,
- file->f_flags & O_NONBLOCK, false);
+ if ((file->f_flags & O_NONBLOCK) || (iocb->ki_flags & IOCB_NOWAIT))
+ noblock = 1;
+
+ result = tun_get_user(tun, tfile, NULL, from, noblock, false);

tun_put(tun);
return result;
@@ -2203,10 +2206,15 @@ static ssize_t tun_chr_read_iter(struct
struct tun_file *tfile = file->private_data;
struct tun_struct *tun = tun_get(tfile);
ssize_t len = iov_iter_count(to), ret;
+ int noblock = 0;

if (!tun)
return -EBADFD;
- ret = tun_do_read(tun, tfile, to, file->f_flags & O_NONBLOCK, NULL);
+
+ if ((file->f_flags & O_NONBLOCK) || (iocb->ki_flags & IOCB_NOWAIT))
+ noblock = 1;
+
+ ret = tun_do_read(tun, tfile, to, noblock, NULL);
ret = min_t(ssize_t, ret, len);
if (ret > 0)
iocb->ki_pos = ret;


2020-12-06 11:49:28

by Greg KH

[permalink] [raw]
Subject: [PATCH 5.9 38/46] net: mlx5e: fix fs_tcp.c build when IPV6 is not enabled

From: Randy Dunlap <[email protected]>

[ Upstream commit 8a78a440108e55ddd845b0ef46df575248667520 ]

Fix build when CONFIG_IPV6 is not enabled by making a function
be built conditionally.

Fixes these build errors and warnings:

../drivers/net/ethernet/mellanox/mlx5/core/en_accel/fs_tcp.c: In function 'accel_fs_tcp_set_ipv6_flow':
../include/net/sock.h:380:34: error: 'struct sock_common' has no member named 'skc_v6_daddr'; did you mean 'skc_daddr'?
380 | #define sk_v6_daddr __sk_common.skc_v6_daddr
| ^~~~~~~~~~~~
../drivers/net/ethernet/mellanox/mlx5/core/en_accel/fs_tcp.c:55:14: note: in expansion of macro 'sk_v6_daddr'
55 | &sk->sk_v6_daddr, 16);
| ^~~~~~~~~~~
At top level:
../drivers/net/ethernet/mellanox/mlx5/core/en_accel/fs_tcp.c:47:13: warning: 'accel_fs_tcp_set_ipv6_flow' defined but not used [-Wunused-function]
47 | static void accel_fs_tcp_set_ipv6_flow(struct mlx5_flow_spec *spec, struct sock *sk)

Fixes: 5229a96e59ec ("net/mlx5e: Accel, Expose flow steering API for rules add/del")
Signed-off-by: Randy Dunlap <[email protected]>
Reported-by: kernel test robot <[email protected]>
Signed-off-by: Saeed Mahameed <[email protected]>
Signed-off-by: Jakub Kicinski <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/net/ethernet/mellanox/mlx5/core/en_accel/fs_tcp.c | 2 ++
1 file changed, 2 insertions(+)

--- a/drivers/net/ethernet/mellanox/mlx5/core/en_accel/fs_tcp.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en_accel/fs_tcp.c
@@ -44,6 +44,7 @@ static void accel_fs_tcp_set_ipv4_flow(s
outer_headers.dst_ipv4_dst_ipv6.ipv4_layout.ipv4);
}

+#if IS_ENABLED(CONFIG_IPV6)
static void accel_fs_tcp_set_ipv6_flow(struct mlx5_flow_spec *spec, struct sock *sk)
{
MLX5_SET_TO_ONES(fte_match_param, spec->match_criteria, outer_headers.ip_protocol);
@@ -63,6 +64,7 @@ static void accel_fs_tcp_set_ipv6_flow(s
outer_headers.dst_ipv4_dst_ipv6.ipv6_layout.ipv6),
0xff, 16);
}
+#endif

void mlx5e_accel_fs_del_sk(struct mlx5_flow_handle *rule)
{


2020-12-06 11:49:28

by Greg KH

[permalink] [raw]
Subject: [PATCH 5.9 13/46] vsock/virtio: discard packets only when socket is really closed

From: Stefano Garzarella <[email protected]>

[ Upstream commit 3fe356d58efae54dade9ec94ea7c919ed20cf4db ]

Starting from commit 8692cefc433f ("virtio_vsock: Fix race condition
in virtio_transport_recv_pkt"), we discard packets in
virtio_transport_recv_pkt() if the socket has been released.

When the socket is connected, we schedule a delayed work to wait the
RST packet from the other peer, also if SHUTDOWN_MASK is set in
sk->sk_shutdown.
This is done to complete the virtio-vsock shutdown algorithm, releasing
the port assigned to the socket definitively only when the other peer
has consumed all the packets.

If we discard the RST packet received, the socket will be closed only
when the VSOCK_CLOSE_TIMEOUT is reached.

Sergio discovered the issue while running ab(1) HTTP benchmark using
libkrun [1] and observing a latency increase with that commit.

To avoid this issue, we discard packet only if the socket is really
closed (SOCK_DONE flag is set).
We also set SOCK_DONE in virtio_transport_release() when we don't need
to wait any packets from the other peer (we didn't schedule the delayed
work). In this case we remove the socket from the vsock lists, releasing
the port assigned.

[1] https://github.com/containers/libkrun

Fixes: 8692cefc433f ("virtio_vsock: Fix race condition in virtio_transport_recv_pkt")
Cc: [email protected]
Reported-by: Sergio Lopez <[email protected]>
Tested-by: Sergio Lopez <[email protected]>
Signed-off-by: Stefano Garzarella <[email protected]>
Acked-by: Jia He <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Jakub Kicinski <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
net/vmw_vsock/virtio_transport_common.c | 8 +++++---
1 file changed, 5 insertions(+), 3 deletions(-)

--- a/net/vmw_vsock/virtio_transport_common.c
+++ b/net/vmw_vsock/virtio_transport_common.c
@@ -841,8 +841,10 @@ void virtio_transport_release(struct vso
virtio_transport_free_pkt(pkt);
}

- if (remove_sock)
+ if (remove_sock) {
+ sock_set_flag(sk, SOCK_DONE);
vsock_remove_sock(vsk);
+ }
}
EXPORT_SYMBOL_GPL(virtio_transport_release);

@@ -1132,8 +1134,8 @@ void virtio_transport_recv_pkt(struct vi

lock_sock(sk);

- /* Check if sk has been released before lock_sock */
- if (sk->sk_shutdown == SHUTDOWN_MASK) {
+ /* Check if sk has been closed before lock_sock */
+ if (sock_flag(sk, SOCK_DONE)) {
(void)virtio_transport_reset_no_sock(t, pkt);
release_sock(sk);
sock_put(sk);


2020-12-06 11:49:32

by Greg KH

[permalink] [raw]
Subject: [PATCH 5.9 14/46] mptcp: fix NULL ptr dereference on bad MPJ

From: Paolo Abeni <[email protected]>

[ Upstream commit d3ab78858f1451351221061a1c365495df196500 ]

If an msk listener receives an MPJ carrying an invalid token, it
will zero the request socket msk entry. That should later
cause fallback and subflow reset - as per RFC - at
subflow_syn_recv_sock() time due to failing hmac validation.

Since commit 4cf8b7e48a09 ("subflow: introduce and use
mptcp_can_accept_new_subflow()"), we unconditionally dereference
- in mptcp_can_accept_new_subflow - the subflow request msk
before performing hmac validation. In the above scenario we
hit a NULL ptr dereference.

Address the issue doing the hmac validation earlier.

Fixes: 4cf8b7e48a09 ("subflow: introduce and use mptcp_can_accept_new_subflow()")
Tested-by: Davide Caratti <[email protected]>
Signed-off-by: Paolo Abeni <[email protected]>
Reviewed-by: Matthieu Baerts <[email protected]>
Link: https://lore.kernel.org/r/03b2cfa3ac80d8fc18272edc6442a9ddf0b1e34e.1606400227.git.pabeni@redhat.com
Signed-off-by: Jakub Kicinski <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
net/mptcp/subflow.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)

--- a/net/mptcp/subflow.c
+++ b/net/mptcp/subflow.c
@@ -542,9 +542,8 @@ create_msk:
fallback = true;
} else if (subflow_req->mp_join) {
mptcp_get_options(skb, &mp_opt);
- if (!mp_opt.mp_join ||
- !mptcp_can_accept_new_subflow(subflow_req->msk) ||
- !subflow_hmac_valid(req, &mp_opt)) {
+ if (!mp_opt.mp_join || !subflow_hmac_valid(req, &mp_opt) ||
+ !mptcp_can_accept_new_subflow(subflow_req->msk)) {
SUBFLOW_REQ_INC_STATS(req, MPTCP_MIB_JOINACKMAC);
fallback = true;
}


2020-12-06 11:49:51

by Greg KH

[permalink] [raw]
Subject: [PATCH 5.9 42/46] Input: atmel_mxt_ts - fix lost interrupts

From: Linus Walleij <[email protected]>

commit 8c3b55a299c325830a987de21dab6a89ecb71164 upstream.

After commit 74d905d2d38a devices requiring the workaround for edge
triggered interrupts stopped working.

The hardware needs the quirk to be used before even proceeding to
check if the quirk is needed because mxt_acquire_irq() is called
before mxt_check_retrigen() is called and at this point pending IRQs
need to be checked, and if the workaround is not active, all
interrupts will be lost from this point.

Solve this by switching the calls around.

Reported-by: Andre Müller <[email protected]>
Tested-by: Andre Müller <[email protected]>
Suggested-by: Dmitry Torokhov <[email protected]>
Fixes: 74d905d2d38a ("Input: atmel_mxt_ts - only read messages in mxt_acquire_irq() when necessary")
Signed-off-by: Linus Walleij <[email protected]>
Cc: [email protected]
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Dmitry Torokhov <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/input/touchscreen/atmel_mxt_ts.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

--- a/drivers/input/touchscreen/atmel_mxt_ts.c
+++ b/drivers/input/touchscreen/atmel_mxt_ts.c
@@ -2183,11 +2183,11 @@ static int mxt_initialize(struct mxt_dat
msleep(MXT_FW_RESET_TIME);
}

- error = mxt_acquire_irq(data);
+ error = mxt_check_retrigen(data);
if (error)
return error;

- error = mxt_check_retrigen(data);
+ error = mxt_acquire_irq(data);
if (error)
return error;



2020-12-06 11:49:55

by Greg KH

[permalink] [raw]
Subject: [PATCH 5.9 43/46] tracing: Fix alignment of static buffer

From: Minchan Kim <[email protected]>

commit 8fa655a3a0013a0c2a2aada6f39a93ee6fc25549 upstream.

With 5.9 kernel on ARM64, I found ftrace_dump output was broken but
it had no problem with normal output "cat /sys/kernel/debug/tracing/trace".

With investigation, it seems coping the data into temporal buffer seems to
break the align binary printf expects if the static buffer is not aligned
with 4-byte. IIUC, get_arg in bstr_printf expects that args has already
right align to be decoded and seq_buf_bprintf says ``the arguments are saved
in a 32bit word array that is defined by the format string constraints``.
So if we don't keep the align under copy to temporal buffer, the output
will be broken by shifting some bytes.

This patch fixes it.

Link: https://lkml.kernel.org/r/[email protected]

Cc: <[email protected]>
Fixes: 8e99cf91b99bb ("tracing: Do not allocate buffer in trace_find_next_entry() in atomic")
Signed-off-by: Namhyung Kim <[email protected]>
Signed-off-by: Minchan Kim <[email protected]>
Signed-off-by: Steven Rostedt (VMware) <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
kernel/trace/trace.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/kernel/trace/trace.c
+++ b/kernel/trace/trace.c
@@ -3516,7 +3516,7 @@ __find_next_entry(struct trace_iterator
}

#define STATIC_TEMP_BUF_SIZE 128
-static char static_temp_buf[STATIC_TEMP_BUF_SIZE];
+static char static_temp_buf[STATIC_TEMP_BUF_SIZE] __aligned(4);

/* Find the next real entry, without updating the iterator itself */
struct trace_entry *trace_find_next_entry(struct trace_iterator *iter,


2020-12-06 11:50:20

by Greg KH

[permalink] [raw]
Subject: [PATCH 5.9 26/46] dpaa_eth: copy timestamp fields to new skb in A-050385 workaround

From: Yangbo Lu <[email protected]>

[ Upstream commit 07500a6085806d97039ebcba8d9b8b29129f0106 ]

The timestamp fields should be copied to new skb too in
A-050385 workaround for later TX timestamping handling.

Fixes: 3c68b8fffb48 ("dpaa_eth: FMan erratum A050385 workaround")
Signed-off-by: Yangbo Lu <[email protected]>
Acked-by: Camelia Groza <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Jakub Kicinski <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/net/ethernet/freescale/dpaa/dpaa_eth.c | 10 +++++++++-
1 file changed, 9 insertions(+), 1 deletion(-)

--- a/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c
+++ b/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c
@@ -2120,6 +2120,15 @@ workaround:
skb_copy_header(new_skb, skb);
new_skb->dev = skb->dev;

+ /* Copy relevant timestamp info from the old skb to the new */
+ if (priv->tx_tstamp) {
+ skb_shinfo(new_skb)->tx_flags = skb_shinfo(skb)->tx_flags;
+ skb_shinfo(new_skb)->hwtstamps = skb_shinfo(skb)->hwtstamps;
+ skb_shinfo(new_skb)->tskey = skb_shinfo(skb)->tskey;
+ if (skb->sk)
+ skb_set_owner_w(new_skb, skb->sk);
+ }
+
/* We move the headroom when we align it so we have to reset the
* network and transport header offsets relative to the new data
* pointer. The checksum offload relies on these offsets.
@@ -2127,7 +2136,6 @@ workaround:
skb_set_network_header(new_skb, skb_network_offset(skb));
skb_set_transport_header(new_skb, skb_transport_offset(skb));

- /* TODO: does timestamping need the result in the old skb? */
dev_kfree_skb(skb);
*s = new_skb;



2020-12-06 21:12:44

by Jeffrin Thalakkottoor

[permalink] [raw]
Subject: Re: [PATCH 5.9 00/46] 5.9.13-rc1 review

On Sun, 2020-12-06 at 12:17 +0100, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.9.13 release.
> There are 46 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied,
> please
> let me know.
>
> Responses should be made by Tue, 08 Dec 2020 11:15:42 +0000.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
>         https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.9.13-rc1.gz
> or in the git tree and branch at:
>         git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-
> stable-rc.git linux-5.9.yo
> and the diffstat can be found below.
>
> thanks,
> 5.9.13
> greg k-h
hello,

Compiled and booted 5.9.13-rc1+. No typical regression or regressions.

Tested-by: Jeffrin Jose T <[email protected]>

--
software engineer
rajagiri school of engineering and technology - autonomous


2020-12-07 07:20:19

by Naresh Kamboju

[permalink] [raw]
Subject: Re: [PATCH 5.9 00/46] 5.9.13-rc1 review

On Sun, 6 Dec 2020 at 17:14, Greg Kroah-Hartman
<[email protected]> wrote:
>
> This is the start of the stable review cycle for the 5.9.13 release.
> There are 46 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Tue, 08 Dec 2020 11:15:42 +0000.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.9.13-rc1.gz
> or in the git tree and branch at:
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.9.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h

Results from Linaro’s test farm.
No regressions on arm64, arm, x86_64, and i386.

Tested-by: Linux Kernel Functional Testing <[email protected]>

NOTE:
Following two warnings noticed.
WARNING: bad unlock balance detected! - mkfs.ext4/426 is trying to
release lock (rcu_read_lock)
https://lore.kernel.org/stable/CA+G9fYs=nR-d0n8kV4=OWD+v=GR2ufOEWU9S4oG1_fZRxhGouQ@mail.gmail.com/

sched: core.c:7270 Illegal context switch in RCU-bh read-side critical
section! __alloc_pages_nodemask
https://lore.kernel.org/stable/CA+G9fYvhJTwQkGyH7HQzSsDBHT7pm5ziA9VTkRhE_bDSQp3JYg@mail.gmail.com/

Summary
------------------------------------------------------------------------

kernel: 5.9.13-rc1
git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-5.9.y
git commit: 1372e1af58d410676db7917cc3484ca22d471623
git describe: v5.9.12-47-g1372e1af58d4
Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-5.9.y/build/v5.9.12-47-g1372e1af58d4

No regressions (compared to build v5.9.12)

No fixes (compared to build v5.9.12)


Ran 53360 total tests in the following environments and test suites.

Environments
--------------
- arc
- arm
- arm64
- dragonboard-410c
- hi6220-hikey
- i386
- juno-r2
- juno-r2-compat
- juno-r2-kasan
- mips
- nxp-ls2088
- parisc
- powerpc
- qemu-arm-clang
- qemu-arm64-clang
- qemu-arm64-kasan
- qemu-i386-clang
- qemu-x86_64-clang
- qemu-x86_64-kasan
- qemu-x86_64-kcsan
- qemu_arm
- qemu_arm64
- qemu_arm64-compat
- qemu_i386
- qemu_x86_64
- qemu_x86_64-compat
- riscv
- s390
- sh
- sparc
- x15
- x86
- x86-kasan

Test Suites
-----------
* build
* linux-log-parser
* install-android-platform-tools-r2600
* libhugetlbfs
* ltp-cap_bounds-tests
* ltp-containers-tests
* ltp-cpuhotplug-tests
* ltp-crypto-tests
* ltp-cve-tests
* ltp-dio-tests
* ltp-hugetlb-tests
* ltp-io-tests
* ltp-ipc-tests
* ltp-mm-tests
* ltp-nptl-tests
* ltp-pty-tests
* ltp-sched-tests
* ltp-securebits-tests
* ltp-syscalls-tests
* ltp-tracing-tests
* perf
* v4l2-compliance
* kvm-unit-tests
* ltp-commands-tests
* ltp-fcntl-locktests-tests
* ltp-filecaps-tests
* ltp-fs-tests
* ltp-fs_bind-tests
* ltp-fs_perms_simple-tests
* ltp-fsx-tests
* ltp-math-tests
* network-basic-tests
* kselftest
* ltp-controllers-tests
* ltp-open-posix-tests
* kunit
* kselftest-vsyscall-mode-native
* kselftest-vsyscall-mode-none

--
Linaro LKFT
https://lkft.linaro.org

2020-12-07 16:00:40

by Guenter Roeck

[permalink] [raw]
Subject: Re: [PATCH 5.9 00/46] 5.9.13-rc1 review

On Sun, Dec 06, 2020 at 12:17:08PM +0100, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.9.13 release.
> There are 46 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Tue, 08 Dec 2020 11:15:42 +0000.
> Anything received after that time might be too late.
>

Build results:
total: 154 pass: 154 fail: 0
Qemu test results:
total: 426 pass: 426 fail: 0

Tested-by: Guenter Roeck <[email protected]>

Guenter

2020-12-08 09:46:14

by Greg KH

[permalink] [raw]
Subject: Re: [PATCH 5.9 00/46] 5.9.13-rc1 review

On Mon, Dec 07, 2020 at 07:55:32AM -0800, Guenter Roeck wrote:
> On Sun, Dec 06, 2020 at 12:17:08PM +0100, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 5.9.13 release.
> > There are 46 patches in this series, all will be posted as a response
> > to this one. If anyone has any issues with these being applied, please
> > let me know.
> >
> > Responses should be made by Tue, 08 Dec 2020 11:15:42 +0000.
> > Anything received after that time might be too late.
> >
>
> Build results:
> total: 154 pass: 154 fail: 0
> Qemu test results:
> total: 426 pass: 426 fail: 0
>
> Tested-by: Guenter Roeck <[email protected]>

Thanks for testing them all and letting me know.

greg k-h

2020-12-08 09:46:47

by Greg KH

[permalink] [raw]
Subject: Re: [PATCH 5.9 00/46] 5.9.13-rc1 review

On Mon, Dec 07, 2020 at 12:47:38PM +0530, Naresh Kamboju wrote:
> On Sun, 6 Dec 2020 at 17:14, Greg Kroah-Hartman
> <[email protected]> wrote:
> >
> > This is the start of the stable review cycle for the 5.9.13 release.
> > There are 46 patches in this series, all will be posted as a response
> > to this one. If anyone has any issues with these being applied, please
> > let me know.
> >
> > Responses should be made by Tue, 08 Dec 2020 11:15:42 +0000.
> > Anything received after that time might be too late.
> >
> > The whole patch series can be found in one patch at:
> > https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.9.13-rc1.gz
> > or in the git tree and branch at:
> > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.9.y
> > and the diffstat can be found below.
> >
> > thanks,
> >
> > greg k-h
>
> Results from Linaro’s test farm.
> No regressions on arm64, arm, x86_64, and i386.
>
> Tested-by: Linux Kernel Functional Testing <[email protected]>

Thanks for testing all of these and letting me know.

greg k-h