2020-06-09 18:16:48

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.19 00/25] 4.19.128-rc1 review

This is the start of the stable review cycle for the 4.19.128 release.
There are 25 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 Thu, 11 Jun 2020 17:40:24 +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/v4.x/stable-review/patch-4.19.128-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-4.19.y
and the diffstat can be found below.

thanks,

greg k-h

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

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

Greg Kroah-Hartman <[email protected]>
Revert "net/mlx5: Annotate mutex destroy for root ns"

Oleg Nesterov <[email protected]>
uprobes: ensure that uprobe->offset and ->ref_ctr_offset are properly aligned

Josh Poimboeuf <[email protected]>
x86/speculation: Add Ivy Bridge to affected list

Mark Gross <[email protected]>
x86/speculation: Add SRBDS vulnerability and mitigation documentation

Mark Gross <[email protected]>
x86/speculation: Add Special Register Buffer Data Sampling (SRBDS) mitigation

Mark Gross <[email protected]>
x86/cpu: Add 'table' argument to cpu_matches()

Mark Gross <[email protected]>
x86/cpu: Add a steppings field to struct x86_cpu_id

Srinivas Kandagatla <[email protected]>
nvmem: qfprom: remove incorrect write support

Oliver Neukum <[email protected]>
CDC-ACM: heed quirk also in error handling

Pascal Terjan <[email protected]>
staging: rtl8712: Fix IEEE80211_ADDBA_PARAM_BUF_SIZE_MASK

Jiri Slaby <[email protected]>
tty: hvc_console, fix crashes on parallel open/close

Dmitry Torokhov <[email protected]>
vt: keyboard: avoid signed integer overflow in k_ascii

Dinghao Liu <[email protected]>
usb: musb: Fix runtime PM imbalance on error

Bin Liu <[email protected]>
usb: musb: start session in resume for host port

Mathieu Othacehe <[email protected]>
iio: vcnl4000: Fix i2c swapped word reading.

Daniele Palmas <[email protected]>
USB: serial: option: add Telit LE910C1-EUX compositions

Bin Liu <[email protected]>
USB: serial: usb_wwan: do not resubmit rx urb on fatal errors

Matt Jolly <[email protected]>
USB: serial: qcserial: add DW5816e QDL support

Willem de Bruijn <[email protected]>
net: check untrusted gso_size at kernel entry

Stefano Garzarella <[email protected]>
vsock: fix timeout in vsock_accept()

Chuhong Yuan <[email protected]>
NFC: st21nfca: add missed kfree_skb() in an error path

Daniele Palmas <[email protected]>
net: usb: qmi_wwan: add Telit LE910C1-EUX composition

Eric Dumazet <[email protected]>
l2tp: do not use inet_hash()/inet_unhash()

Eric Dumazet <[email protected]>
l2tp: add sk_family checks to l2tp_validate_socket

Yang Yingliang <[email protected]>
devinet: fix memleak in inetdev_init()


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

Diffstat:

Documentation/ABI/testing/sysfs-devices-system-cpu | 1 +
Documentation/admin-guide/hw-vuln/index.rst | 1 +
.../special-register-buffer-data-sampling.rst | 149 +++++++++++++++++++++
Documentation/admin-guide/kernel-parameters.txt | 20 +++
Makefile | 4 +-
arch/x86/include/asm/cpu_device_id.h | 27 ++++
arch/x86/include/asm/cpufeatures.h | 2 +
arch/x86/include/asm/msr-index.h | 4 +
arch/x86/kernel/cpu/bugs.c | 106 +++++++++++++++
arch/x86/kernel/cpu/common.c | 54 ++++++--
arch/x86/kernel/cpu/cpu.h | 1 +
arch/x86/kernel/cpu/match.c | 7 +-
drivers/base/cpu.c | 8 ++
drivers/iio/light/vcnl4000.c | 6 +-
drivers/net/ethernet/mellanox/mlx5/core/fs_core.c | 6 -
drivers/net/usb/qmi_wwan.c | 1 +
drivers/nfc/st21nfca/dep.c | 4 +-
drivers/nvmem/qfprom.c | 14 --
drivers/staging/rtl8712/wifi.h | 9 +-
drivers/tty/hvc/hvc_console.c | 23 ++--
drivers/tty/vt/keyboard.c | 26 ++--
drivers/usb/class/cdc-acm.c | 2 +-
drivers/usb/musb/musb_core.c | 7 +
drivers/usb/musb/musb_debugfs.c | 10 +-
drivers/usb/serial/option.c | 4 +
drivers/usb/serial/qcserial.c | 1 +
drivers/usb/serial/usb_wwan.c | 4 +
include/linux/mod_devicetable.h | 6 +
include/linux/virtio_net.h | 14 +-
kernel/events/uprobes.c | 16 ++-
net/ipv4/devinet.c | 1 +
net/l2tp/l2tp_core.c | 3 +
net/l2tp/l2tp_ip.c | 29 +++-
net/l2tp/l2tp_ip6.c | 30 +++--
net/vmw_vsock/af_vsock.c | 2 +-
35 files changed, 503 insertions(+), 99 deletions(-)



2020-06-09 18:16:49

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.19 18/25] nvmem: qfprom: remove incorrect write support

From: Srinivas Kandagatla <[email protected]>

commit 8d9eb0d6d59a5d7028c80a30831143d3e75515a7 upstream.

qfprom has different address spaces for read and write. Reads are
always done from corrected address space, where as writes are done
on raw address space.
Writing to corrected address space is invalid and ignored, so it
does not make sense to have this support in the driver which only
supports corrected address space regions at the moment.

Fixes: 4ab11996b489 ("nvmem: qfprom: Add Qualcomm QFPROM support.")
Signed-off-by: Srinivas Kandagatla <[email protected]>
Reviewed-by: Douglas Anderson <[email protected]>
Cc: stable <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/nvmem/qfprom.c | 14 --------------
1 file changed, 14 deletions(-)

--- a/drivers/nvmem/qfprom.c
+++ b/drivers/nvmem/qfprom.c
@@ -35,25 +35,11 @@ static int qfprom_reg_read(void *context
return 0;
}

-static int qfprom_reg_write(void *context,
- unsigned int reg, void *_val, size_t bytes)
-{
- struct qfprom_priv *priv = context;
- u8 *val = _val;
- int i = 0, words = bytes;
-
- while (words--)
- writeb(*val++, priv->base + reg + i++);
-
- return 0;
-}
-
static struct nvmem_config econfig = {
.name = "qfprom",
.stride = 1,
.word_size = 1,
.reg_read = qfprom_reg_read,
- .reg_write = qfprom_reg_write,
};

static int qfprom_probe(struct platform_device *pdev)


2020-06-09 18:16:59

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.19 15/25] tty: hvc_console, fix crashes on parallel open/close

From: Jiri Slaby <[email protected]>

commit 24eb2377f977fe06d84fca558f891f95bc28a449 upstream.

hvc_open sets tty->driver_data to NULL when open fails at some point.
Typically, the failure happens in hp->ops->notifier_add(). If there is
a racing process which tries to open such mangled tty, which was not
closed yet, the process will crash in hvc_open as tty->driver_data is
NULL.

All this happens because close wants to know whether open failed or not.
But ->open should not NULL this and other tty fields for ->close to be
happy. ->open should call tty_port_set_initialized(true) and close
should check by tty_port_initialized() instead. So do this properly in
this driver.

So this patch removes these from ->open:
* tty_port_tty_set(&hp->port, NULL). This happens on last close.
* tty->driver_data = NULL. Dtto.
* tty_port_put(&hp->port). This happens in shutdown and until now, this
must have been causing a reference underflow, if I am not missing
something.

Signed-off-by: Jiri Slaby <[email protected]>
Cc: stable <[email protected]>
Reported-and-tested-by: Raghavendra <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/tty/hvc/hvc_console.c | 23 ++++++++---------------
1 file changed, 8 insertions(+), 15 deletions(-)

--- a/drivers/tty/hvc/hvc_console.c
+++ b/drivers/tty/hvc/hvc_console.c
@@ -371,15 +371,14 @@ static int hvc_open(struct tty_struct *t
* tty fields and return the kref reference.
*/
if (rc) {
- tty_port_tty_set(&hp->port, NULL);
- tty->driver_data = NULL;
- tty_port_put(&hp->port);
printk(KERN_ERR "hvc_open: request_irq failed with rc %d.\n", rc);
- } else
+ } else {
/* We are ready... raise DTR/RTS */
if (C_BAUD(tty))
if (hp->ops->dtr_rts)
hp->ops->dtr_rts(hp, 1);
+ tty_port_set_initialized(&hp->port, true);
+ }

/* Force wakeup of the polling thread */
hvc_kick();
@@ -389,22 +388,12 @@ static int hvc_open(struct tty_struct *t

static void hvc_close(struct tty_struct *tty, struct file * filp)
{
- struct hvc_struct *hp;
+ struct hvc_struct *hp = tty->driver_data;
unsigned long flags;

if (tty_hung_up_p(filp))
return;

- /*
- * No driver_data means that this close was issued after a failed
- * hvc_open by the tty layer's release_dev() function and we can just
- * exit cleanly because the kref reference wasn't made.
- */
- if (!tty->driver_data)
- return;
-
- hp = tty->driver_data;
-
spin_lock_irqsave(&hp->port.lock, flags);

if (--hp->port.count == 0) {
@@ -412,6 +401,9 @@ static void hvc_close(struct tty_struct
/* We are done with the tty pointer now. */
tty_port_tty_set(&hp->port, NULL);

+ if (!tty_port_initialized(&hp->port))
+ return;
+
if (C_HUPCL(tty))
if (hp->ops->dtr_rts)
hp->ops->dtr_rts(hp, 0);
@@ -428,6 +420,7 @@ static void hvc_close(struct tty_struct
* waking periodically to check chars_in_buffer().
*/
tty_wait_until_sent(tty, HVC_CLOSE_WAIT);
+ tty_port_set_initialized(&hp->port, false);
} else {
if (hp->port.count < 0)
printk(KERN_ERR "hvc_close %X: oops, count is %d\n",


2020-06-09 18:18:26

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.19 03/25] l2tp: do not use inet_hash()/inet_unhash()

From: Eric Dumazet <[email protected]>

[ Upstream commit 02c71b144c811bcdd865e0a1226d0407d11357e8 ]

syzbot recently found a way to crash the kernel [1]

Issue here is that inet_hash() & inet_unhash() are currently
only meant to be used by TCP & DCCP, since only these protocols
provide the needed hashinfo pointer.

L2TP uses a single list (instead of a hash table)

This old bug became an issue after commit 610236587600
("bpf: Add new cgroup attach type to enable sock modifications")
since after this commit, sk_common_release() can be called
while the L2TP socket is still considered 'hashed'.

general protection fault, probably for non-canonical address 0xdffffc0000000001: 0000 [#1] PREEMPT SMP KASAN
KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f]
CPU: 0 PID: 7063 Comm: syz-executor654 Not tainted 5.7.0-rc6-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
RIP: 0010:inet_unhash+0x11f/0x770 net/ipv4/inet_hashtables.c:600
Code: 03 0f b6 04 02 84 c0 74 08 3c 03 0f 8e dd 04 00 00 48 8d 7d 08 44 8b 73 08 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 55 05 00 00 48 8d 7d 14 4c 8b 6d 08 48 b8 00 00
RSP: 0018:ffffc90001777d30 EFLAGS: 00010202
RAX: dffffc0000000000 RBX: ffff88809a6df940 RCX: ffffffff8697c242
RDX: 0000000000000001 RSI: ffffffff8697c251 RDI: 0000000000000008
RBP: 0000000000000000 R08: ffff88809f3ae1c0 R09: fffffbfff1514cc1
R10: ffffffff8a8a6607 R11: fffffbfff1514cc0 R12: ffff88809a6df9b0
R13: 0000000000000007 R14: 0000000000000000 R15: ffffffff873a4d00
FS: 0000000001d2b880(0000) GS:ffff8880ae600000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00000000006cd090 CR3: 000000009403a000 CR4: 00000000001406f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
sk_common_release+0xba/0x370 net/core/sock.c:3210
inet_create net/ipv4/af_inet.c:390 [inline]
inet_create+0x966/0xe00 net/ipv4/af_inet.c:248
__sock_create+0x3cb/0x730 net/socket.c:1428
sock_create net/socket.c:1479 [inline]
__sys_socket+0xef/0x200 net/socket.c:1521
__do_sys_socket net/socket.c:1530 [inline]
__se_sys_socket net/socket.c:1528 [inline]
__x64_sys_socket+0x6f/0xb0 net/socket.c:1528
do_syscall_64+0xf6/0x7d0 arch/x86/entry/common.c:295
entry_SYSCALL_64_after_hwframe+0x49/0xb3
RIP: 0033:0x441e29
Code: e8 fc b3 02 00 48 83 c4 18 c3 0f 1f 80 00 00 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 eb 08 fc ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:00007ffdce184148 EFLAGS: 00000246 ORIG_RAX: 0000000000000029
RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 0000000000441e29
RDX: 0000000000000073 RSI: 0000000000000002 RDI: 0000000000000002
RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 0000000000402c30 R14: 0000000000000000 R15: 0000000000000000
Modules linked in:
---[ end trace 23b6578228ce553e ]---
RIP: 0010:inet_unhash+0x11f/0x770 net/ipv4/inet_hashtables.c:600
Code: 03 0f b6 04 02 84 c0 74 08 3c 03 0f 8e dd 04 00 00 48 8d 7d 08 44 8b 73 08 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 55 05 00 00 48 8d 7d 14 4c 8b 6d 08 48 b8 00 00
RSP: 0018:ffffc90001777d30 EFLAGS: 00010202
RAX: dffffc0000000000 RBX: ffff88809a6df940 RCX: ffffffff8697c242
RDX: 0000000000000001 RSI: ffffffff8697c251 RDI: 0000000000000008
RBP: 0000000000000000 R08: ffff88809f3ae1c0 R09: fffffbfff1514cc1
R10: ffffffff8a8a6607 R11: fffffbfff1514cc0 R12: ffff88809a6df9b0
R13: 0000000000000007 R14: 0000000000000000 R15: ffffffff873a4d00
FS: 0000000001d2b880(0000) GS:ffff8880ae600000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00000000006cd090 CR3: 000000009403a000 CR4: 00000000001406f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400

Fixes: 0d76751fad77 ("l2tp: Add L2TPv3 IP encapsulation (no UDP) support")
Signed-off-by: Eric Dumazet <[email protected]>
Cc: James Chapman <[email protected]>
Cc: Andrii Nakryiko <[email protected]>
Reported-by: [email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
net/l2tp/l2tp_ip.c | 29 ++++++++++++++++++++++-------
net/l2tp/l2tp_ip6.c | 30 ++++++++++++++++++++++--------
2 files changed, 44 insertions(+), 15 deletions(-)

--- a/net/l2tp/l2tp_ip.c
+++ b/net/l2tp/l2tp_ip.c
@@ -24,7 +24,6 @@
#include <net/icmp.h>
#include <net/udp.h>
#include <net/inet_common.h>
-#include <net/inet_hashtables.h>
#include <net/tcp_states.h>
#include <net/protocol.h>
#include <net/xfrm.h>
@@ -213,15 +212,31 @@ discard:
return 0;
}

-static int l2tp_ip_open(struct sock *sk)
+static int l2tp_ip_hash(struct sock *sk)
{
- /* Prevent autobind. We don't have ports. */
- inet_sk(sk)->inet_num = IPPROTO_L2TP;
+ if (sk_unhashed(sk)) {
+ write_lock_bh(&l2tp_ip_lock);
+ sk_add_node(sk, &l2tp_ip_table);
+ write_unlock_bh(&l2tp_ip_lock);
+ }
+ return 0;
+}

+static void l2tp_ip_unhash(struct sock *sk)
+{
+ if (sk_unhashed(sk))
+ return;
write_lock_bh(&l2tp_ip_lock);
- sk_add_node(sk, &l2tp_ip_table);
+ sk_del_node_init(sk);
write_unlock_bh(&l2tp_ip_lock);
+}
+
+static int l2tp_ip_open(struct sock *sk)
+{
+ /* Prevent autobind. We don't have ports. */
+ inet_sk(sk)->inet_num = IPPROTO_L2TP;

+ l2tp_ip_hash(sk);
return 0;
}

@@ -598,8 +613,8 @@ static struct proto l2tp_ip_prot = {
.sendmsg = l2tp_ip_sendmsg,
.recvmsg = l2tp_ip_recvmsg,
.backlog_rcv = l2tp_ip_backlog_recv,
- .hash = inet_hash,
- .unhash = inet_unhash,
+ .hash = l2tp_ip_hash,
+ .unhash = l2tp_ip_unhash,
.obj_size = sizeof(struct l2tp_ip_sock),
#ifdef CONFIG_COMPAT
.compat_setsockopt = compat_ip_setsockopt,
--- a/net/l2tp/l2tp_ip6.c
+++ b/net/l2tp/l2tp_ip6.c
@@ -24,8 +24,6 @@
#include <net/icmp.h>
#include <net/udp.h>
#include <net/inet_common.h>
-#include <net/inet_hashtables.h>
-#include <net/inet6_hashtables.h>
#include <net/tcp_states.h>
#include <net/protocol.h>
#include <net/xfrm.h>
@@ -226,15 +224,31 @@ discard:
return 0;
}

-static int l2tp_ip6_open(struct sock *sk)
+static int l2tp_ip6_hash(struct sock *sk)
{
- /* Prevent autobind. We don't have ports. */
- inet_sk(sk)->inet_num = IPPROTO_L2TP;
+ if (sk_unhashed(sk)) {
+ write_lock_bh(&l2tp_ip6_lock);
+ sk_add_node(sk, &l2tp_ip6_table);
+ write_unlock_bh(&l2tp_ip6_lock);
+ }
+ return 0;
+}

+static void l2tp_ip6_unhash(struct sock *sk)
+{
+ if (sk_unhashed(sk))
+ return;
write_lock_bh(&l2tp_ip6_lock);
- sk_add_node(sk, &l2tp_ip6_table);
+ sk_del_node_init(sk);
write_unlock_bh(&l2tp_ip6_lock);
+}
+
+static int l2tp_ip6_open(struct sock *sk)
+{
+ /* Prevent autobind. We don't have ports. */
+ inet_sk(sk)->inet_num = IPPROTO_L2TP;

+ l2tp_ip6_hash(sk);
return 0;
}

@@ -732,8 +746,8 @@ static struct proto l2tp_ip6_prot = {
.sendmsg = l2tp_ip6_sendmsg,
.recvmsg = l2tp_ip6_recvmsg,
.backlog_rcv = l2tp_ip6_backlog_recv,
- .hash = inet6_hash,
- .unhash = inet_unhash,
+ .hash = l2tp_ip6_hash,
+ .unhash = l2tp_ip6_unhash,
.obj_size = sizeof(struct l2tp_ip6_sock),
#ifdef CONFIG_COMPAT
.compat_setsockopt = compat_ipv6_setsockopt,


2020-06-09 18:18:27

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.19 12/25] usb: musb: start session in resume for host port

From: Bin Liu <[email protected]>

commit 7f88a5ac393f39319f69b8b20cc8d5759878d1a1 upstream.

Commit 17539f2f4f0b ("usb: musb: fix enumeration after resume") replaced
musb_start() in musb_resume() to not override softconnect bit, but it
doesn't restart the session for host port which was done in musb_start().
The session could be disabled in musb_suspend(), which leads the host
port doesn't stay in host mode.

So let's start the session specifically for host port in musb_resume().

Fixes: 17539f2f4f0b ("usb: musb: fix enumeration after resume")

Cc: [email protected]
Signed-off-by: Bin Liu <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/usb/musb/musb_core.c | 7 +++++++
1 file changed, 7 insertions(+)

--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -2737,6 +2737,13 @@ static int musb_resume(struct device *de
musb_enable_interrupts(musb);
musb_platform_enable(musb);

+ /* session might be disabled in suspend */
+ if (musb->port_mode == MUSB_HOST &&
+ !(musb->ops->quirks & MUSB_PRESERVE_SESSION)) {
+ devctl |= MUSB_DEVCTL_SESSION;
+ musb_writeb(musb->mregs, MUSB_DEVCTL, devctl);
+ }
+
spin_lock_irqsave(&musb->lock, flags);
error = musb_run_resume_work(musb);
if (error)


2020-06-09 19:54:32

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.19 17/25] CDC-ACM: heed quirk also in error handling

From: Oliver Neukum <[email protected]>

commit 97fe809934dd2b0b37dfef3a2fc70417f485d7af upstream.

If buffers are iterated over in the error case, the lower limits
for quirky devices must be heeded.

Signed-off-by: Oliver Neukum <[email protected]>
Reported-by: Jean Rene Dawin <[email protected]>
Fixes: a4e7279cd1d19 ("cdc-acm: introduce a cool down")
Cc: stable <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/usb/class/cdc-acm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/usb/class/cdc-acm.c
+++ b/drivers/usb/class/cdc-acm.c
@@ -590,7 +590,7 @@ static void acm_softint(struct work_stru
}

if (test_and_clear_bit(ACM_ERROR_DELAY, &acm->flags)) {
- for (i = 0; i < ACM_NR; i++)
+ for (i = 0; i < acm->rx_buflimit; i++)
if (test_and_clear_bit(i, &acm->urbs_in_error_delay))
acm_submit_read_urb(acm, i, GFP_NOIO);
}


2020-06-09 19:57:24

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.19 08/25] USB: serial: qcserial: add DW5816e QDL support

From: Matt Jolly <[email protected]>

commit 3429444abdd9dbd5faebd9bee552ec6162b17ad6 upstream.

Add support for Dell Wireless 5816e Download Mode (AKA boot & hold mode /
QDL download mode) to drivers/usb/serial/qcserial.c

This is required to update device firmware.

Signed-off-by: Matt Jolly <[email protected]>
Cc: [email protected]
Signed-off-by: Johan Hovold <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/usb/serial/qcserial.c | 1 +
1 file changed, 1 insertion(+)

--- a/drivers/usb/serial/qcserial.c
+++ b/drivers/usb/serial/qcserial.c
@@ -173,6 +173,7 @@ static const struct usb_device_id id_tab
{DEVICE_SWI(0x413c, 0x81b3)}, /* Dell Wireless 5809e Gobi(TM) 4G LTE Mobile Broadband Card (rev3) */
{DEVICE_SWI(0x413c, 0x81b5)}, /* Dell Wireless 5811e QDL */
{DEVICE_SWI(0x413c, 0x81b6)}, /* Dell Wireless 5811e QDL */
+ {DEVICE_SWI(0x413c, 0x81cb)}, /* Dell Wireless 5816e QDL */
{DEVICE_SWI(0x413c, 0x81cc)}, /* Dell Wireless 5816e */
{DEVICE_SWI(0x413c, 0x81cf)}, /* Dell Wireless 5819 */
{DEVICE_SWI(0x413c, 0x81d0)}, /* Dell Wireless 5819 */


2020-06-09 19:57:24

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.19 21/25] x86/speculation: Add Special Register Buffer Data Sampling (SRBDS) mitigation

From: Mark Gross <[email protected]>

commit 7e5b3c267d256822407a22fdce6afdf9cd13f9fb upstream

SRBDS is an MDS-like speculative side channel that can leak bits from the
random number generator (RNG) across cores and threads. New microcode
serializes the processor access during the execution of RDRAND and
RDSEED. This ensures that the shared buffer is overwritten before it is
released for reuse.

While it is present on all affected CPU models, the microcode mitigation
is not needed on models that enumerate ARCH_CAPABILITIES[MDS_NO] in the
cases where TSX is not supported or has been disabled with TSX_CTRL.

The mitigation is activated by default on affected processors and it
increases latency for RDRAND and RDSEED instructions. Among other
effects this will reduce throughput from /dev/urandom.

* Enable administrator to configure the mitigation off when desired using
either mitigations=off or srbds=off.

* Export vulnerability status via sysfs

* Rename file-scoped macros to apply for non-whitelist table initializations.

[ bp: Massage,
- s/VULNBL_INTEL_STEPPING/VULNBL_INTEL_STEPPINGS/g,
- do not read arch cap MSR a second time in tsx_fused_off() - just pass it in,
- flip check in cpu_set_bug_bits() to save an indentation level,
- reflow comments.
jpoimboe: s/Mitigated/Mitigation/ in user-visible strings
tglx: Dropped the fused off magic for now
]

Signed-off-by: Mark Gross <[email protected]>
Signed-off-by: Borislav Petkov <[email protected]>
Signed-off-by: Thomas Gleixner <[email protected]>
Reviewed-by: Tony Luck <[email protected]>
Reviewed-by: Pawan Gupta <[email protected]>
Reviewed-by: Josh Poimboeuf <[email protected]>
Tested-by: Neelima Krishnan <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
Documentation/ABI/testing/sysfs-devices-system-cpu | 1
Documentation/admin-guide/kernel-parameters.txt | 20 +++
arch/x86/include/asm/cpufeatures.h | 2
arch/x86/include/asm/msr-index.h | 4
arch/x86/kernel/cpu/bugs.c | 106 +++++++++++++++++++++
arch/x86/kernel/cpu/common.c | 31 ++++++
arch/x86/kernel/cpu/cpu.h | 1
drivers/base/cpu.c | 8 +
8 files changed, 173 insertions(+)

--- a/Documentation/ABI/testing/sysfs-devices-system-cpu
+++ b/Documentation/ABI/testing/sysfs-devices-system-cpu
@@ -478,6 +478,7 @@ What: /sys/devices/system/cpu/vulnerabi
/sys/devices/system/cpu/vulnerabilities/spec_store_bypass
/sys/devices/system/cpu/vulnerabilities/l1tf
/sys/devices/system/cpu/vulnerabilities/mds
+ /sys/devices/system/cpu/vulnerabilities/srbds
/sys/devices/system/cpu/vulnerabilities/tsx_async_abort
/sys/devices/system/cpu/vulnerabilities/itlb_multihit
Date: January 2018
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -4415,6 +4415,26 @@
spia_pedr=
spia_peddr=

+ srbds= [X86,INTEL]
+ Control the Special Register Buffer Data Sampling
+ (SRBDS) mitigation.
+
+ Certain CPUs are vulnerable to an MDS-like
+ exploit which can leak bits from the random
+ number generator.
+
+ By default, this issue is mitigated by
+ microcode. However, the microcode fix can cause
+ the RDRAND and RDSEED instructions to become
+ much slower. Among other effects, this will
+ result in reduced throughput from /dev/urandom.
+
+ The microcode mitigation can be disabled with
+ the following option:
+
+ off: Disable mitigation and remove
+ performance impact to RDRAND and RDSEED
+
srcutree.counter_wrap_check [KNL]
Specifies how frequently to check for
grace-period sequence counter wrap for the
--- a/arch/x86/include/asm/cpufeatures.h
+++ b/arch/x86/include/asm/cpufeatures.h
@@ -347,6 +347,7 @@
/* Intel-defined CPU features, CPUID level 0x00000007:0 (EDX), word 18 */
#define X86_FEATURE_AVX512_4VNNIW (18*32+ 2) /* AVX-512 Neural Network Instructions */
#define X86_FEATURE_AVX512_4FMAPS (18*32+ 3) /* AVX-512 Multiply Accumulation Single precision */
+#define X86_FEATURE_SRBDS_CTRL (18*32+ 9) /* "" SRBDS mitigation MSR available */
#define X86_FEATURE_TSX_FORCE_ABORT (18*32+13) /* "" TSX_FORCE_ABORT */
#define X86_FEATURE_MD_CLEAR (18*32+10) /* VERW clears CPU buffers */
#define X86_FEATURE_PCONFIG (18*32+18) /* Intel PCONFIG */
@@ -391,5 +392,6 @@
#define X86_BUG_SWAPGS X86_BUG(21) /* CPU is affected by speculation through SWAPGS */
#define X86_BUG_TAA X86_BUG(22) /* CPU is affected by TSX Async Abort(TAA) */
#define X86_BUG_ITLB_MULTIHIT X86_BUG(23) /* CPU may incur MCE during certain page attribute changes */
+#define X86_BUG_SRBDS X86_BUG(24) /* CPU may leak RNG bits if not mitigated */

#endif /* _ASM_X86_CPUFEATURES_H */
--- a/arch/x86/include/asm/msr-index.h
+++ b/arch/x86/include/asm/msr-index.h
@@ -110,6 +110,10 @@
#define TSX_CTRL_RTM_DISABLE BIT(0) /* Disable RTM feature */
#define TSX_CTRL_CPUID_CLEAR BIT(1) /* Disable TSX enumeration */

+/* SRBDS support */
+#define MSR_IA32_MCU_OPT_CTRL 0x00000123
+#define RNGDS_MITG_DIS BIT(0)
+
#define MSR_IA32_SYSENTER_CS 0x00000174
#define MSR_IA32_SYSENTER_ESP 0x00000175
#define MSR_IA32_SYSENTER_EIP 0x00000176
--- a/arch/x86/kernel/cpu/bugs.c
+++ b/arch/x86/kernel/cpu/bugs.c
@@ -41,6 +41,7 @@ static void __init l1tf_select_mitigatio
static void __init mds_select_mitigation(void);
static void __init mds_print_mitigation(void);
static void __init taa_select_mitigation(void);
+static void __init srbds_select_mitigation(void);

/* The base value of the SPEC_CTRL MSR that always has to be preserved. */
u64 x86_spec_ctrl_base;
@@ -108,6 +109,7 @@ void __init check_bugs(void)
l1tf_select_mitigation();
mds_select_mitigation();
taa_select_mitigation();
+ srbds_select_mitigation();

/*
* As MDS and TAA mitigations are inter-related, print MDS
@@ -391,6 +393,97 @@ static int __init tsx_async_abort_parse_
early_param("tsx_async_abort", tsx_async_abort_parse_cmdline);

#undef pr_fmt
+#define pr_fmt(fmt) "SRBDS: " fmt
+
+enum srbds_mitigations {
+ SRBDS_MITIGATION_OFF,
+ SRBDS_MITIGATION_UCODE_NEEDED,
+ SRBDS_MITIGATION_FULL,
+ SRBDS_MITIGATION_TSX_OFF,
+ SRBDS_MITIGATION_HYPERVISOR,
+};
+
+static enum srbds_mitigations srbds_mitigation __ro_after_init = SRBDS_MITIGATION_FULL;
+
+static const char * const srbds_strings[] = {
+ [SRBDS_MITIGATION_OFF] = "Vulnerable",
+ [SRBDS_MITIGATION_UCODE_NEEDED] = "Vulnerable: No microcode",
+ [SRBDS_MITIGATION_FULL] = "Mitigation: Microcode",
+ [SRBDS_MITIGATION_TSX_OFF] = "Mitigation: TSX disabled",
+ [SRBDS_MITIGATION_HYPERVISOR] = "Unknown: Dependent on hypervisor status",
+};
+
+static bool srbds_off;
+
+void update_srbds_msr(void)
+{
+ u64 mcu_ctrl;
+
+ if (!boot_cpu_has_bug(X86_BUG_SRBDS))
+ return;
+
+ if (boot_cpu_has(X86_FEATURE_HYPERVISOR))
+ return;
+
+ if (srbds_mitigation == SRBDS_MITIGATION_UCODE_NEEDED)
+ return;
+
+ rdmsrl(MSR_IA32_MCU_OPT_CTRL, mcu_ctrl);
+
+ switch (srbds_mitigation) {
+ case SRBDS_MITIGATION_OFF:
+ case SRBDS_MITIGATION_TSX_OFF:
+ mcu_ctrl |= RNGDS_MITG_DIS;
+ break;
+ case SRBDS_MITIGATION_FULL:
+ mcu_ctrl &= ~RNGDS_MITG_DIS;
+ break;
+ default:
+ break;
+ }
+
+ wrmsrl(MSR_IA32_MCU_OPT_CTRL, mcu_ctrl);
+}
+
+static void __init srbds_select_mitigation(void)
+{
+ u64 ia32_cap;
+
+ if (!boot_cpu_has_bug(X86_BUG_SRBDS))
+ return;
+
+ /*
+ * Check to see if this is one of the MDS_NO systems supporting
+ * TSX that are only exposed to SRBDS when TSX is enabled.
+ */
+ ia32_cap = x86_read_arch_cap_msr();
+ if ((ia32_cap & ARCH_CAP_MDS_NO) && !boot_cpu_has(X86_FEATURE_RTM))
+ srbds_mitigation = SRBDS_MITIGATION_TSX_OFF;
+ else if (boot_cpu_has(X86_FEATURE_HYPERVISOR))
+ srbds_mitigation = SRBDS_MITIGATION_HYPERVISOR;
+ else if (!boot_cpu_has(X86_FEATURE_SRBDS_CTRL))
+ srbds_mitigation = SRBDS_MITIGATION_UCODE_NEEDED;
+ else if (cpu_mitigations_off() || srbds_off)
+ srbds_mitigation = SRBDS_MITIGATION_OFF;
+
+ update_srbds_msr();
+ pr_info("%s\n", srbds_strings[srbds_mitigation]);
+}
+
+static int __init srbds_parse_cmdline(char *str)
+{
+ if (!str)
+ return -EINVAL;
+
+ if (!boot_cpu_has_bug(X86_BUG_SRBDS))
+ return 0;
+
+ srbds_off = !strcmp(str, "off");
+ return 0;
+}
+early_param("srbds", srbds_parse_cmdline);
+
+#undef pr_fmt
#define pr_fmt(fmt) "Spectre V1 : " fmt

enum spectre_v1_mitigation {
@@ -1491,6 +1584,11 @@ static char *ibpb_state(void)
return "";
}

+static ssize_t srbds_show_state(char *buf)
+{
+ return sprintf(buf, "%s\n", srbds_strings[srbds_mitigation]);
+}
+
static ssize_t cpu_show_common(struct device *dev, struct device_attribute *attr,
char *buf, unsigned int bug)
{
@@ -1535,6 +1633,9 @@ static ssize_t cpu_show_common(struct de
case X86_BUG_ITLB_MULTIHIT:
return itlb_multihit_show_state(buf);

+ case X86_BUG_SRBDS:
+ return srbds_show_state(buf);
+
default:
break;
}
@@ -1581,4 +1682,9 @@ ssize_t cpu_show_itlb_multihit(struct de
{
return cpu_show_common(dev, attr, buf, X86_BUG_ITLB_MULTIHIT);
}
+
+ssize_t cpu_show_srbds(struct device *dev, struct device_attribute *attr, char *buf)
+{
+ return cpu_show_common(dev, attr, buf, X86_BUG_SRBDS);
+}
#endif
--- a/arch/x86/kernel/cpu/common.c
+++ b/arch/x86/kernel/cpu/common.c
@@ -1013,6 +1013,27 @@ static const __initconst struct x86_cpu_
{}
};

+#define VULNBL_INTEL_STEPPINGS(model, steppings, issues) \
+ X86_MATCH_VENDOR_FAM_MODEL_STEPPINGS_FEATURE(INTEL, 6, \
+ INTEL_FAM6_##model, steppings, \
+ X86_FEATURE_ANY, issues)
+
+#define SRBDS BIT(0)
+
+static const struct x86_cpu_id cpu_vuln_blacklist[] __initconst = {
+ VULNBL_INTEL_STEPPINGS(IVYBRIDGE, X86_STEPPING_ANY, SRBDS),
+ VULNBL_INTEL_STEPPINGS(HASWELL_CORE, X86_STEPPING_ANY, SRBDS),
+ VULNBL_INTEL_STEPPINGS(HASWELL_ULT, X86_STEPPING_ANY, SRBDS),
+ VULNBL_INTEL_STEPPINGS(HASWELL_GT3E, X86_STEPPING_ANY, SRBDS),
+ VULNBL_INTEL_STEPPINGS(BROADWELL_GT3E, X86_STEPPING_ANY, SRBDS),
+ VULNBL_INTEL_STEPPINGS(BROADWELL_CORE, X86_STEPPING_ANY, SRBDS),
+ VULNBL_INTEL_STEPPINGS(SKYLAKE_MOBILE, X86_STEPPING_ANY, SRBDS),
+ VULNBL_INTEL_STEPPINGS(SKYLAKE_DESKTOP, X86_STEPPING_ANY, SRBDS),
+ VULNBL_INTEL_STEPPINGS(KABYLAKE_MOBILE, X86_STEPPINGS(0x0, 0xC), SRBDS),
+ VULNBL_INTEL_STEPPINGS(KABYLAKE_DESKTOP,X86_STEPPINGS(0x0, 0xD), SRBDS),
+ {}
+};
+
static bool __init cpu_matches(const struct x86_cpu_id *table, unsigned long which)
{
const struct x86_cpu_id *m = x86_match_cpu(table);
@@ -1078,6 +1099,15 @@ static void __init cpu_set_bug_bits(stru
(ia32_cap & ARCH_CAP_TSX_CTRL_MSR)))
setup_force_cpu_bug(X86_BUG_TAA);

+ /*
+ * SRBDS affects CPUs which support RDRAND or RDSEED and are listed
+ * in the vulnerability blacklist.
+ */
+ if ((cpu_has(c, X86_FEATURE_RDRAND) ||
+ cpu_has(c, X86_FEATURE_RDSEED)) &&
+ cpu_matches(cpu_vuln_blacklist, SRBDS))
+ setup_force_cpu_bug(X86_BUG_SRBDS);
+
if (cpu_matches(cpu_vuln_whitelist, NO_MELTDOWN))
return;

@@ -1522,6 +1552,7 @@ void identify_secondary_cpu(struct cpuin
mtrr_ap_init();
validate_apic_and_package_id(c);
x86_spec_ctrl_setup_ap();
+ update_srbds_msr();
}

static __init int setup_noclflush(char *arg)
--- a/arch/x86/kernel/cpu/cpu.h
+++ b/arch/x86/kernel/cpu/cpu.h
@@ -80,6 +80,7 @@ extern void detect_ht(struct cpuinfo_x86
unsigned int aperfmperf_get_khz(int cpu);

extern void x86_spec_ctrl_setup_ap(void);
+extern void update_srbds_msr(void);

extern u64 x86_read_arch_cap_msr(void);

--- a/drivers/base/cpu.c
+++ b/drivers/base/cpu.c
@@ -565,6 +565,12 @@ ssize_t __weak cpu_show_itlb_multihit(st
return sprintf(buf, "Not affected\n");
}

+ssize_t __weak cpu_show_srbds(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ return sprintf(buf, "Not affected\n");
+}
+
static DEVICE_ATTR(meltdown, 0444, cpu_show_meltdown, NULL);
static DEVICE_ATTR(spectre_v1, 0444, cpu_show_spectre_v1, NULL);
static DEVICE_ATTR(spectre_v2, 0444, cpu_show_spectre_v2, NULL);
@@ -573,6 +579,7 @@ static DEVICE_ATTR(l1tf, 0444, cpu_show_
static DEVICE_ATTR(mds, 0444, cpu_show_mds, NULL);
static DEVICE_ATTR(tsx_async_abort, 0444, cpu_show_tsx_async_abort, NULL);
static DEVICE_ATTR(itlb_multihit, 0444, cpu_show_itlb_multihit, NULL);
+static DEVICE_ATTR(srbds, 0444, cpu_show_srbds, NULL);

static struct attribute *cpu_root_vulnerabilities_attrs[] = {
&dev_attr_meltdown.attr,
@@ -583,6 +590,7 @@ static struct attribute *cpu_root_vulner
&dev_attr_mds.attr,
&dev_attr_tsx_async_abort.attr,
&dev_attr_itlb_multihit.attr,
+ &dev_attr_srbds.attr,
NULL
};



2020-06-09 20:25:40

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.19 04/25] net: usb: qmi_wwan: add Telit LE910C1-EUX composition

From: Daniele Palmas <[email protected]>

[ Upstream commit 591612aa578cd7148b7b9d74869ef40118978389 ]

Add support for Telit LE910C1-EUX composition

0x1031: tty, tty, tty, rmnet
Signed-off-by: Daniele Palmas <[email protected]>
Acked-by: Bjørn Mork <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/net/usb/qmi_wwan.c | 1 +
1 file changed, 1 insertion(+)

--- a/drivers/net/usb/qmi_wwan.c
+++ b/drivers/net/usb/qmi_wwan.c
@@ -1260,6 +1260,7 @@ static const struct usb_device_id produc
{QMI_FIXED_INTF(0x1bbb, 0x0203, 2)}, /* Alcatel L800MA */
{QMI_FIXED_INTF(0x2357, 0x0201, 4)}, /* TP-LINK HSUPA Modem MA180 */
{QMI_FIXED_INTF(0x2357, 0x9000, 4)}, /* TP-LINK MA260 */
+ {QMI_QUIRK_SET_DTR(0x1bc7, 0x1031, 3)}, /* Telit LE910C1-EUX */
{QMI_QUIRK_SET_DTR(0x1bc7, 0x1040, 2)}, /* Telit LE922A */
{QMI_FIXED_INTF(0x1bc7, 0x1100, 3)}, /* Telit ME910 */
{QMI_FIXED_INTF(0x1bc7, 0x1101, 3)}, /* Telit ME910 dual modem */


2020-06-09 20:35:20

by Naresh Kamboju

[permalink] [raw]
Subject: Re: [PATCH 4.19 00/25] 4.19.128-rc1 review

On Tue, 9 Jun 2020 at 23:21, Greg Kroah-Hartman
<[email protected]> wrote:
>
> This is the start of the stable review cycle for the 4.19.128 release.
> There are 25 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 Thu, 11 Jun 2020 17:40:24 +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/v4.x/stable-review/patch-4.19.128-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-4.19.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
>
> -------------
> Pseudo-Shortlog of commits:
>
> Greg Kroah-Hartman <[email protected]>
> Linux 4.19.128-rc1
>
> Greg Kroah-Hartman <[email protected]>
> Revert "net/mlx5: Annotate mutex destroy for root ns"
>
> Oleg Nesterov <[email protected]>
> uprobes: ensure that uprobe->offset and ->ref_ctr_offset are properly aligned

stable-rc 4.19 build failure for x86_64, i386 and arm.

make -sk KBUILD_BUILD_USER=TuxBuild -C/linux -j16 ARCH=x86 HOSTCC=gcc
CC="sccache gcc" O=build
75 #
76 In file included from ../kernel/events/uprobes.c:25:
77 ../kernel/events/uprobes.c: In function ‘__uprobe_register’:
78 ../kernel/events/uprobes.c:916:18: error: ‘ref_ctr_offset’
undeclared (first use in this function); did you mean
‘per_cpu_offset’?
79 916 | if (!IS_ALIGNED(ref_ctr_offset, sizeof(short)))
80 | ^~~~~~~~~~~~~~
81 ../include/linux/kernel.h:62:30: note: in definition of macro ‘IS_ALIGNED’
82 62 | #define IS_ALIGNED(x, a) (((x) & ((typeof(x))(a) - 1)) == 0)
83 | ^
84 ../kernel/events/uprobes.c:916:18: note: each undeclared identifier
is reported only once for each function it appears in
85 916 | if (!IS_ALIGNED(ref_ctr_offset, sizeof(short)))
86 | ^~~~~~~~~~~~~~
87 ../include/linux/kernel.h:62:30: note: in definition of macro ‘IS_ALIGNED’
88 62 | #define IS_ALIGNED(x, a) (((x) & ((typeof(x))(a) - 1)) == 0)
89 | ^
90 make[3]: *** [../scripts/Makefile.build:304: kernel/events/uprobes.o] Error 1

kernel config:
https://builds.tuxbuild.com/I3PT6_HS4PTt7EFgJUIPxA/kernel.config

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

2020-06-09 20:36:36

by Shuah Khan

[permalink] [raw]
Subject: Re: [PATCH 4.19 00/25] 4.19.128-rc1 review

On 6/9/20 1:01 PM, Naresh Kamboju wrote:
> On Tue, 9 Jun 2020 at 23:21, Greg Kroah-Hartman
> <[email protected]> wrote:
>>
>> This is the start of the stable review cycle for the 4.19.128 release.
>> There are 25 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 Thu, 11 Jun 2020 17:40:24 +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/v4.x/stable-review/patch-4.19.128-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-4.19.y
>> and the diffstat can be found below.
>>
>> thanks,
>>
>> greg k-h
>>
>> -------------
>> Pseudo-Shortlog of commits:
>>
>> Greg Kroah-Hartman <[email protected]>
>> Linux 4.19.128-rc1
>>
>> Greg Kroah-Hartman <[email protected]>
>> Revert "net/mlx5: Annotate mutex destroy for root ns"
>>
>> Oleg Nesterov <[email protected]>
>> uprobes: ensure that uprobe->offset and ->ref_ctr_offset are properly aligned
>
> stable-rc 4.19 build failure for x86_64, i386 and arm.
>
> make -sk KBUILD_BUILD_USER=TuxBuild -C/linux -j16 ARCH=x86 HOSTCC=gcc
> CC="sccache gcc" O=build
> 75 #
> 76 In file included from ../kernel/events/uprobes.c:25:
> 77 ../kernel/events/uprobes.c: In function ‘__uprobe_register’:
> 78 ../kernel/events/uprobes.c:916:18: error: ‘ref_ctr_offset’
> undeclared (first use in this function); did you mean
> ‘per_cpu_offset’?
> 79 916 | if (!IS_ALIGNED(ref_ctr_offset, sizeof(short)))
> 80 | ^~~~~~~~~~~~~~
> 81 ../include/linux/kernel.h:62:30: note: in definition of macro ‘IS_ALIGNED’
> 82 62 | #define IS_ALIGNED(x, a) (((x) & ((typeof(x))(a) - 1)) == 0)
> 83 | ^
> 84 ../kernel/events/uprobes.c:916:18: note: each undeclared identifier
> is reported only once for each function it appears in
> 85 916 | if (!IS_ALIGNED(ref_ctr_offset, sizeof(short)))
> 86 | ^~~~~~~~~~~~~~
> 87 ../include/linux/kernel.h:62:30: note: in definition of macro ‘IS_ALIGNED’
> 88 62 | #define IS_ALIGNED(x, a) (((x) & ((typeof(x))(a) - 1)) == 0)
> 89 | ^
> 90 make[3]: *** [../scripts/Makefile.build:304: kernel/events/uprobes.o] Error 1
>
> kernel config:
> https://builds.tuxbuild.com/I3PT6_HS4PTt7EFgJUIPxA/kernel.config
>

I am seeing the same problem on x86_64

CONFIG_UPROBES is enabled in my config.

thanks,
-- Shuah

2020-06-09 20:38:53

by Greg Kroah-Hartman

[permalink] [raw]
Subject: Re: [PATCH 4.19 00/25] 4.19.128-rc1 review

On Tue, Jun 09, 2020 at 01:20:42PM -0600, Shuah Khan wrote:
> On 6/9/20 1:01 PM, Naresh Kamboju wrote:
> > On Tue, 9 Jun 2020 at 23:21, Greg Kroah-Hartman
> > <[email protected]> wrote:
> > >
> > > This is the start of the stable review cycle for the 4.19.128 release.
> > > There are 25 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 Thu, 11 Jun 2020 17:40:24 +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/v4.x/stable-review/patch-4.19.128-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-4.19.y
> > > and the diffstat can be found below.
> > >
> > > thanks,
> > >
> > > greg k-h
> > >
> > > -------------
> > > Pseudo-Shortlog of commits:
> > >
> > > Greg Kroah-Hartman <[email protected]>
> > > Linux 4.19.128-rc1
> > >
> > > Greg Kroah-Hartman <[email protected]>
> > > Revert "net/mlx5: Annotate mutex destroy for root ns"
> > >
> > > Oleg Nesterov <[email protected]>
> > > uprobes: ensure that uprobe->offset and ->ref_ctr_offset are properly aligned
> >
> > stable-rc 4.19 build failure for x86_64, i386 and arm.
> >
> > make -sk KBUILD_BUILD_USER=TuxBuild -C/linux -j16 ARCH=x86 HOSTCC=gcc
> > CC="sccache gcc" O=build
> > 75 #
> > 76 In file included from ../kernel/events/uprobes.c:25:
> > 77 ../kernel/events/uprobes.c: In function ‘__uprobe_register’:
> > 78 ../kernel/events/uprobes.c:916:18: error: ‘ref_ctr_offset’
> > undeclared (first use in this function); did you mean
> > ‘per_cpu_offset’?
> > 79 916 | if (!IS_ALIGNED(ref_ctr_offset, sizeof(short)))
> > 80 | ^~~~~~~~~~~~~~
> > 81 ../include/linux/kernel.h:62:30: note: in definition of macro ‘IS_ALIGNED’
> > 82 62 | #define IS_ALIGNED(x, a) (((x) & ((typeof(x))(a) - 1)) == 0)
> > 83 | ^
> > 84 ../kernel/events/uprobes.c:916:18: note: each undeclared identifier
> > is reported only once for each function it appears in
> > 85 916 | if (!IS_ALIGNED(ref_ctr_offset, sizeof(short)))
> > 86 | ^~~~~~~~~~~~~~
> > 87 ../include/linux/kernel.h:62:30: note: in definition of macro ‘IS_ALIGNED’
> > 88 62 | #define IS_ALIGNED(x, a) (((x) & ((typeof(x))(a) - 1)) == 0)
> > 89 | ^
> > 90 make[3]: *** [../scripts/Makefile.build:304: kernel/events/uprobes.o] Error 1
> >
> > kernel config:
> > https://builds.tuxbuild.com/I3PT6_HS4PTt7EFgJUIPxA/kernel.config
> >
>
> I am seeing the same problem on x86_64
>
> CONFIG_UPROBES is enabled in my config.

Should be fixed in the -rc2 release, sorry about that.

greg k-h

2020-06-09 20:57:25

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.19 13/25] usb: musb: Fix runtime PM imbalance on error

From: Dinghao Liu <[email protected]>

commit e4befc121df03dc8ed2ac1031c98f9538e244bae upstream.

When copy_from_user() returns an error code, there
is a runtime PM usage counter imbalance.

Fix this by moving copy_from_user() to the beginning
of this function.

Fixes: 7b6c1b4c0e1e ("usb: musb: fix runtime PM in debugfs")

Signed-off-by: Dinghao Liu <[email protected]>
Cc: [email protected]
Signed-off-by: Bin Liu <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/usb/musb/musb_debugfs.c | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)

--- a/drivers/usb/musb/musb_debugfs.c
+++ b/drivers/usb/musb/musb_debugfs.c
@@ -168,6 +168,11 @@ static ssize_t musb_test_mode_write(stru
u8 test;
char buf[24];

+ memset(buf, 0x00, sizeof(buf));
+
+ if (copy_from_user(buf, ubuf, min_t(size_t, sizeof(buf) - 1, count)))
+ return -EFAULT;
+
pm_runtime_get_sync(musb->controller);
test = musb_readb(musb->mregs, MUSB_TESTMODE);
if (test) {
@@ -176,11 +181,6 @@ static ssize_t musb_test_mode_write(stru
goto ret;
}

- memset(buf, 0x00, sizeof(buf));
-
- if (copy_from_user(buf, ubuf, min_t(size_t, sizeof(buf) - 1, count)))
- return -EFAULT;
-
if (strstarts(buf, "force host full-speed"))
test = MUSB_TEST_FORCE_HOST | MUSB_TEST_FORCE_FS;



2020-06-09 20:57:26

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.19 01/25] devinet: fix memleak in inetdev_init()

From: Yang Yingliang <[email protected]>

[ Upstream commit 1b49cd71b52403822731dc9f283185d1da355f97 ]

When devinet_sysctl_register() failed, the memory allocated
in neigh_parms_alloc() should be freed.

Fixes: 20e61da7ffcf ("ipv4: fail early when creating netdev named all or default")
Signed-off-by: Yang Yingliang <[email protected]>
Acked-by: Cong Wang <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
net/ipv4/devinet.c | 1 +
1 file changed, 1 insertion(+)

--- a/net/ipv4/devinet.c
+++ b/net/ipv4/devinet.c
@@ -269,6 +269,7 @@ static struct in_device *inetdev_init(st
err = devinet_sysctl_register(in_dev);
if (err) {
in_dev->dead = 1;
+ neigh_parms_release(&arp_tbl, in_dev->arp_parms);
in_dev_put(in_dev);
in_dev = NULL;
goto out;


2020-06-09 20:57:46

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.19 06/25] vsock: fix timeout in vsock_accept()

From: Stefano Garzarella <[email protected]>

[ Upstream commit 7e0afbdfd13d1e708fe96e31c46c4897101a6a43 ]

The accept(2) is an "input" socket interface, so we should use
SO_RCVTIMEO instead of SO_SNDTIMEO to set the timeout.

So this patch replace sock_sndtimeo() with sock_rcvtimeo() to
use the right timeout in the vsock_accept().

Fixes: d021c344051a ("VSOCK: Introduce VM Sockets")
Signed-off-by: Stefano Garzarella <[email protected]>
Reviewed-by: Jorgen Hansen <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
net/vmw_vsock/af_vsock.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/net/vmw_vsock/af_vsock.c
+++ b/net/vmw_vsock/af_vsock.c
@@ -1283,7 +1283,7 @@ static int vsock_accept(struct socket *s
/* Wait for children sockets to appear; these are the new sockets
* created upon connection establishment.
*/
- timeout = sock_sndtimeo(listener, flags & O_NONBLOCK);
+ timeout = sock_rcvtimeo(listener, flags & O_NONBLOCK);
prepare_to_wait(sk_sleep(listener), &wait, TASK_INTERRUPTIBLE);

while ((connected = vsock_dequeue_accept(listener)) == NULL &&


2020-06-09 20:58:50

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.19 22/25] x86/speculation: Add SRBDS vulnerability and mitigation documentation

From: Mark Gross <[email protected]>

commit 7222a1b5b87417f22265c92deea76a6aecd0fb0f upstream

Add documentation for the SRBDS vulnerability and its mitigation.

[ bp: Massage.
jpoimboe: sysfs table strings. ]

Signed-off-by: Mark Gross <[email protected]>
Signed-off-by: Borislav Petkov <[email protected]>
Reviewed-by: Tony Luck <[email protected]>
Reviewed-by: Josh Poimboeuf <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
Documentation/admin-guide/hw-vuln/index.rst | 1
Documentation/admin-guide/hw-vuln/special-register-buffer-data-sampling.rst | 148 ++++++++++
2 files changed, 149 insertions(+)
create mode 100644 Documentation/admin-guide/hw-vuln/special-register-buffer-data-sampling.rst

--- a/Documentation/admin-guide/hw-vuln/index.rst
+++ b/Documentation/admin-guide/hw-vuln/index.rst
@@ -14,3 +14,4 @@ are configurable at compile, boot or run
mds
tsx_async_abort
multihit.rst
+ special-register-buffer-data-sampling.rst
--- /dev/null
+++ b/Documentation/admin-guide/hw-vuln/special-register-buffer-data-sampling.rst
@@ -0,0 +1,148 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+SRBDS - Special Register Buffer Data Sampling
+=============================================
+
+SRBDS is a hardware vulnerability that allows MDS :doc:`mds` techniques to
+infer values returned from special register accesses. Special register
+accesses are accesses to off core registers. According to Intel's evaluation,
+the special register reads that have a security expectation of privacy are
+RDRAND, RDSEED and SGX EGETKEY.
+
+When RDRAND, RDSEED and EGETKEY instructions are used, the data is moved
+to the core through the special register mechanism that is susceptible
+to MDS attacks.
+
+Affected processors
+--------------------
+Core models (desktop, mobile, Xeon-E3) that implement RDRAND and/or RDSEED may
+be affected.
+
+A processor is affected by SRBDS if its Family_Model and stepping is
+in the following list, with the exception of the listed processors
+exporting MDS_NO while Intel TSX is available yet not enabled. The
+latter class of processors are only affected when Intel TSX is enabled
+by software using TSX_CTRL_MSR otherwise they are not affected.
+
+ ============= ============ ========
+ common name Family_Model Stepping
+ ============= ============ ========
+ Haswell 06_3CH All
+ Haswell_L 06_45H All
+ Haswell_G 06_46H All
+
+ Broadwell_G 06_47H All
+ Broadwell 06_3DH All
+
+ Skylake_L 06_4EH All
+ Skylake 06_5EH All
+
+ Kabylake_L 06_8EH <=0xC
+
+ Kabylake 06_9EH <=0xD
+ ============= ============ ========
+
+Related CVEs
+------------
+
+The following CVE entry is related to this SRBDS issue:
+
+ ============== ===== =====================================
+ CVE-2020-0543 SRBDS Special Register Buffer Data Sampling
+ ============== ===== =====================================
+
+Attack scenarios
+----------------
+An unprivileged user can extract values returned from RDRAND and RDSEED
+executed on another core or sibling thread using MDS techniques.
+
+
+Mitigation mechanism
+-------------------
+Intel will release microcode updates that modify the RDRAND, RDSEED, and
+EGETKEY instructions to overwrite secret special register data in the shared
+staging buffer before the secret data can be accessed by another logical
+processor.
+
+During execution of the RDRAND, RDSEED, or EGETKEY instructions, off-core
+accesses from other logical processors will be delayed until the special
+register read is complete and the secret data in the shared staging buffer is
+overwritten.
+
+This has three effects on performance:
+
+#. RDRAND, RDSEED, or EGETKEY instructions have higher latency.
+
+#. Executing RDRAND at the same time on multiple logical processors will be
+ serialized, resulting in an overall reduction in the maximum RDRAND
+ bandwidth.
+
+#. Executing RDRAND, RDSEED or EGETKEY will delay memory accesses from other
+ logical processors that miss their core caches, with an impact similar to
+ legacy locked cache-line-split accesses.
+
+The microcode updates provide an opt-out mechanism (RNGDS_MITG_DIS) to disable
+the mitigation for RDRAND and RDSEED instructions executed outside of Intel
+Software Guard Extensions (Intel SGX) enclaves. On logical processors that
+disable the mitigation using this opt-out mechanism, RDRAND and RDSEED do not
+take longer to execute and do not impact performance of sibling logical
+processors memory accesses. The opt-out mechanism does not affect Intel SGX
+enclaves (including execution of RDRAND or RDSEED inside an enclave, as well
+as EGETKEY execution).
+
+IA32_MCU_OPT_CTRL MSR Definition
+--------------------------------
+Along with the mitigation for this issue, Intel added a new thread-scope
+IA32_MCU_OPT_CTRL MSR, (address 0x123). The presence of this MSR and
+RNGDS_MITG_DIS (bit 0) is enumerated by CPUID.(EAX=07H,ECX=0).EDX[SRBDS_CTRL =
+9]==1. This MSR is introduced through the microcode update.
+
+Setting IA32_MCU_OPT_CTRL[0] (RNGDS_MITG_DIS) to 1 for a logical processor
+disables the mitigation for RDRAND and RDSEED executed outside of an Intel SGX
+enclave on that logical processor. Opting out of the mitigation for a
+particular logical processor does not affect the RDRAND and RDSEED mitigations
+for other logical processors.
+
+Note that inside of an Intel SGX enclave, the mitigation is applied regardless
+of the value of RNGDS_MITG_DS.
+
+Mitigation control on the kernel command line
+---------------------------------------------
+The kernel command line allows control over the SRBDS mitigation at boot time
+with the option "srbds=". The option for this is:
+
+ ============= =============================================================
+ off This option disables SRBDS mitigation for RDRAND and RDSEED on
+ affected platforms.
+ ============= =============================================================
+
+SRBDS System Information
+-----------------------
+The Linux kernel provides vulnerability status information through sysfs. For
+SRBDS this can be accessed by the following sysfs file:
+/sys/devices/system/cpu/vulnerabilities/srbds
+
+The possible values contained in this file are:
+
+ ============================== =============================================
+ Not affected Processor not vulnerable
+ Vulnerable Processor vulnerable and mitigation disabled
+ Vulnerable: No microcode Processor vulnerable and microcode is missing
+ mitigation
+ Mitigation: Microcode Processor is vulnerable and mitigation is in
+ effect.
+ Mitigation: TSX disabled Processor is only vulnerable when TSX is
+ enabled while this system was booted with TSX
+ disabled.
+ Unknown: Dependent on
+ hypervisor status Running on virtual guest processor that is
+ affected but with no way to know if host
+ processor is mitigated or vulnerable.
+ ============================== =============================================
+
+SRBDS Default mitigation
+------------------------
+This new microcode serializes processor access during execution of RDRAND,
+RDSEED ensures that the shared buffer is overwritten before it is released for
+reuse. Use the "srbds=off" kernel command line to disable the mitigation for
+RDRAND and RDSEED.


2020-06-09 20:59:10

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.19 09/25] USB: serial: usb_wwan: do not resubmit rx urb on fatal errors

From: Bin Liu <[email protected]>

commit 986c1748c84d7727defeaeca74a73b37f7d5cce1 upstream.

usb_wwan_indat_callback() shouldn't resubmit rx urb if the previous urb
status is a fatal error. Or the usb controller would keep processing the
new urbs then run into interrupt storm, and has no chance to recover.

Fixes: 6c1ee66a0b2b ("USB-Serial: Fix error handling of usb_wwan")
Cc: [email protected]
Signed-off-by: Bin Liu <[email protected]>
Signed-off-by: Johan Hovold <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/usb/serial/usb_wwan.c | 4 ++++
1 file changed, 4 insertions(+)

--- a/drivers/usb/serial/usb_wwan.c
+++ b/drivers/usb/serial/usb_wwan.c
@@ -299,6 +299,10 @@ static void usb_wwan_indat_callback(stru
if (status) {
dev_dbg(dev, "%s: nonzero status: %d on endpoint %02x.\n",
__func__, status, endpoint);
+
+ /* don't resubmit on fatal errors */
+ if (status == -ESHUTDOWN || status == -ENOENT)
+ return;
} else {
if (urb->actual_length) {
tty_insert_flip_string(&port->port, data,


2020-06-09 21:00:17

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.19 05/25] NFC: st21nfca: add missed kfree_skb() in an error path

From: Chuhong Yuan <[email protected]>

[ Upstream commit 3decabdc714ca56c944f4669b4cdec5c2c1cea23 ]

st21nfca_tm_send_atr_res() misses to call kfree_skb() in an error path.
Add the missed function call to fix it.

Fixes: 1892bf844ea0 ("NFC: st21nfca: Adding P2P support to st21nfca in Initiator & Target mode")
Signed-off-by: Chuhong Yuan <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/nfc/st21nfca/dep.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)

--- a/drivers/nfc/st21nfca/dep.c
+++ b/drivers/nfc/st21nfca/dep.c
@@ -184,8 +184,10 @@ static int st21nfca_tm_send_atr_res(stru
memcpy(atr_res->gbi, atr_req->gbi, gb_len);
r = nfc_set_remote_general_bytes(hdev->ndev, atr_res->gbi,
gb_len);
- if (r < 0)
+ if (r < 0) {
+ kfree_skb(skb);
return r;
+ }
}

info->dep_info.curr_nfc_dep_pni = 0;


2020-06-09 21:00:29

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.19 11/25] iio: vcnl4000: Fix i2c swapped word reading.

From: Mathieu Othacehe <[email protected]>

commit 18dfb5326370991c81a6d1ed6d1aeee055cb8c05 upstream.

The bytes returned by the i2c reading need to be swapped
unconditionally. Otherwise, on be16 platforms, an incorrect value will be
returned.

Taking the slow path via next merge window as its been around a while
and we have a patch set dependent on this which would be held up.

Fixes: 62a1efb9f868 ("iio: add vcnl4000 combined ALS and proximity sensor")
Signed-off-by: Mathieu Othacehe <[email protected]>
Cc: <[email protected]>
Signed-off-by: Jonathan Cameron <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/iio/light/vcnl4000.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)

--- a/drivers/iio/light/vcnl4000.c
+++ b/drivers/iio/light/vcnl4000.c
@@ -166,7 +166,6 @@ static int vcnl4000_measure(struct vcnl4
u8 rdy_mask, u8 data_reg, int *val)
{
int tries = 20;
- __be16 buf;
int ret;

mutex_lock(&data->vcnl4000_lock);
@@ -193,13 +192,12 @@ static int vcnl4000_measure(struct vcnl4
goto fail;
}

- ret = i2c_smbus_read_i2c_block_data(data->client,
- data_reg, sizeof(buf), (u8 *) &buf);
+ ret = i2c_smbus_read_word_swapped(data->client, data_reg);
if (ret < 0)
goto fail;

mutex_unlock(&data->vcnl4000_lock);
- *val = be16_to_cpu(buf);
+ *val = ret;

return 0;



2020-06-09 21:00:31

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.19 25/25] Revert "net/mlx5: Annotate mutex destroy for root ns"

From: Greg Kroah-Hartman <[email protected]>

This reverts commit 95fde2e46860c183f6f47a99381a3b9bff488bd5 which is
commit 9ca415399dae133b00273a4283ef31d003a6818d upstream.

It was backported incorrectly, Paul writes at:
https://lore.kernel.org/r/[email protected]

I happened to notice this commit:

9ca415399dae - "net/mlx5: Annotate mutex destroy for root ns"

...was backported to 4.19 and 5.4 and v5.6 in linux-stable.

It patches del_sw_root_ns() - which only exists after v5.7-rc7 from:

6eb7a268a99b - "net/mlx5: Don't maintain a case of del_sw_func being
null"

which creates the one line del_sw_root_ns stub function around
kfree(node) by breaking it out of tree_put_node().

In the absense of del_sw_root_ns - the backport finds an identical one
line kfree stub fcn - named del_sw_prio from this earlier commit:

139ed6c6c46a - "net/mlx5: Fix steering memory leak" [in v4.15-rc5]

and then puts the mutex_destroy() into that (wrong) function, instead of
putting it into tree_put_node where the root ns case used to be hand

Reported-by: Paul Gortmaker <[email protected]>
Cc: Roi Dayan <[email protected]>
Cc: Mark Bloch <[email protected]>
Cc: Saeed Mahameed <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/net/ethernet/mellanox/mlx5/core/fs_core.c | 6 ------
1 file changed, 6 deletions(-)

--- a/drivers/net/ethernet/mellanox/mlx5/core/fs_core.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/fs_core.c
@@ -364,12 +364,6 @@ static void del_sw_ns(struct fs_node *no

static void del_sw_prio(struct fs_node *node)
{
- struct mlx5_flow_root_namespace *root_ns;
- struct mlx5_flow_namespace *ns;
-
- fs_get_obj(ns, node);
- root_ns = container_of(ns, struct mlx5_flow_root_namespace, ns);
- mutex_destroy(&root_ns->chain_lock);
kfree(node);
}



2020-06-10 16:14:06

by Jon Hunter

[permalink] [raw]
Subject: Re: [PATCH 4.19 00/25] 4.19.128-rc1 review


On 09/06/2020 18:44, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.19.128 release.
> There are 25 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 Thu, 11 Jun 2020 17:40:24 +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/v4.x/stable-review/patch-4.19.128-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-4.19.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h

All tests are passing for Tegra ...

Test results for stable-v4.19:
11 builds: 11 pass, 0 fail
22 boots: 22 pass, 0 fail
36 tests: 36 pass, 0 fail

Linux version: 4.19.128-rc2-gf6c346f2d42d
Boards tested: tegra124-jetson-tk1, tegra186-p2771-0000,
tegra194-p2972-0000, tegra20-ventana,
tegra210-p2371-2180, tegra30-cardhu-a04

Cheers
Jon

--
nvpublic

2020-06-11 22:19:52

by Saeed Mahameed

[permalink] [raw]
Subject: Re: [PATCH 4.19 25/25] Revert "net/mlx5: Annotate mutex destroy for root ns"

On Tue, 2020-06-09 at 19:45 +0200, Greg Kroah-Hartman wrote:
> From: Greg Kroah-Hartman <[email protected]>
>
> This reverts commit 95fde2e46860c183f6f47a99381a3b9bff488bd5 which is
> commit 9ca415399dae133b00273a4283ef31d003a6818d upstream.
>
> It was backported incorrectly, Paul writes at:
> https://lore.kernel.org/r/[email protected]
>
> I happened to notice this commit:
>
> 9ca415399dae - "net/mlx5: Annotate mutex destroy for root ns"
>
> ...was backported to 4.19 and 5.4 and v5.6 in linux-stable.
>
> It patches del_sw_root_ns() - which only exists after v5.7-rc7
> from:
>
> 6eb7a268a99b - "net/mlx5: Don't maintain a case of del_sw_func
> being
> null"
>
> which creates the one line del_sw_root_ns stub function around
> kfree(node) by breaking it out of tree_put_node().
>
> In the absense of del_sw_root_ns - the backport finds an
> identical one
> line kfree stub fcn - named del_sw_prio from this earlier
> commit:
>
> 139ed6c6c46a - "net/mlx5: Fix steering memory leak" [in v4.15-
> rc5]
>
> and then puts the mutex_destroy() into that (wrong) function,
> instead of
> putting it into tree_put_node where the root ns case used to be
> hand
>
> Reported-by: Paul Gortmaker <[email protected]>
> Cc: Roi Dayan <[email protected]>
> Cc: Mark Bloch <[email protected]>
> Cc: Saeed Mahameed <[email protected]>
> Signed-off-by: Greg Kroah-Hartman <[email protected]>

Acked-by: Saeed Mahameed <[email protected]>


I don't know if this was due to something wrong in my backporting
process or AUTOSEL/wrong Fixes tag related. I will check later and will
try my best to avoid this in the future.

Thanks,
Saeed.

2020-06-12 01:10:37

by Sasha Levin

[permalink] [raw]
Subject: Re: [PATCH 4.19 25/25] Revert "net/mlx5: Annotate mutex destroy for root ns"

On Thu, Jun 11, 2020 at 10:17:33PM +0000, Saeed Mahameed wrote:
>On Tue, 2020-06-09 at 19:45 +0200, Greg Kroah-Hartman wrote:
>> From: Greg Kroah-Hartman <[email protected]>
>>
>> This reverts commit 95fde2e46860c183f6f47a99381a3b9bff488bd5 which is
>> commit 9ca415399dae133b00273a4283ef31d003a6818d upstream.
>>
>> It was backported incorrectly, Paul writes at:
>> https://lore.kernel.org/r/[email protected]
>>
>> I happened to notice this commit:
>>
>> 9ca415399dae - "net/mlx5: Annotate mutex destroy for root ns"
>>
>> ...was backported to 4.19 and 5.4 and v5.6 in linux-stable.
>>
>> It patches del_sw_root_ns() - which only exists after v5.7-rc7
>> from:
>>
>> 6eb7a268a99b - "net/mlx5: Don't maintain a case of del_sw_func
>> being
>> null"
>>
>> which creates the one line del_sw_root_ns stub function around
>> kfree(node) by breaking it out of tree_put_node().
>>
>> In the absense of del_sw_root_ns - the backport finds an
>> identical one
>> line kfree stub fcn - named del_sw_prio from this earlier
>> commit:
>>
>> 139ed6c6c46a - "net/mlx5: Fix steering memory leak" [in v4.15-
>> rc5]
>>
>> and then puts the mutex_destroy() into that (wrong) function,
>> instead of
>> putting it into tree_put_node where the root ns case used to be
>> hand
>>
>> Reported-by: Paul Gortmaker <[email protected]>
>> Cc: Roi Dayan <[email protected]>
>> Cc: Mark Bloch <[email protected]>
>> Cc: Saeed Mahameed <[email protected]>
>> Signed-off-by: Greg Kroah-Hartman <[email protected]>
>
>Acked-by: Saeed Mahameed <[email protected]>
>
>
>I don't know if this was due to something wrong in my backporting
>process or AUTOSEL/wrong Fixes tag related. I will check later and will
>try my best to avoid this in the future.

I'm not sure what happened there, but FWIW - AUTOSEL wasn't involved.

--
Thanks,
Sasha

2020-06-15 13:33:00

by Pavel Machek

[permalink] [raw]
Subject: Re: [PATCH 4.19 11/25] iio: vcnl4000: Fix i2c swapped word reading.

Hi!

> From: Mathieu Othacehe <[email protected]>
>
> commit 18dfb5326370991c81a6d1ed6d1aeee055cb8c05 upstream.
>
> The bytes returned by the i2c reading need to be swapped
> unconditionally. Otherwise, on be16 platforms, an incorrect value will be
> returned.
>
> Taking the slow path via next merge window as its been around a while
> and we have a patch set dependent on this which would be held up.

Is there some explanation how this is correct Somewhere? I assume i2c
hardware has fixed endianity (not depending on CPU), so unconditional
swapping will cause problems either on le or on be machines...?

Best regards,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


Attachments:
(No filename) (801.00 B)
signature.asc (201.00 B)
Download all attachments

2020-06-16 08:23:14

by Jonathan Cameron

[permalink] [raw]
Subject: Re: [PATCH 4.19 11/25] iio: vcnl4000: Fix i2c swapped word reading.

On Mon, 15 Jun 2020 15:30:18 +0200
Pavel Machek <[email protected]> wrote:

> Hi!
>
> > From: Mathieu Othacehe <[email protected]>
> >
> > commit 18dfb5326370991c81a6d1ed6d1aeee055cb8c05 upstream.
> >
> > The bytes returned by the i2c reading need to be swapped
> > unconditionally. Otherwise, on be16 platforms, an incorrect value will be
> > returned.
> >
> > Taking the slow path via next merge window as its been around a while
> > and we have a patch set dependent on this which would be held up.
>
> Is there some explanation how this is correct Somewhere? I assume i2c
> hardware has fixed endianity (not depending on CPU), so unconditional
> swapping will cause problems either on le or on be machines...?
>

Hmm, this isn't introducing a bug, but looking again, it appears
that the original code was fine as well..

smbus/I2C has a fixed ordering on the wire (when people actually obey the spec).
So when an i2c_smbus_read_word_data call is made, the drivers / subsystem
assume that ordering an provide the data in CPU endian order.

Unfortunately a reasonable set of devices provide data in the opposite
order from that required by the i2c spec. Thus it needs to be unconditionally
swapped to put it back into the correct order.
i2c_smbus_read_word_data_swapped does that for us.

Now the reason it worked before was this was previously doing a
block read rather than a word read. i2c_smbus_read_i2c_block_data
which is just reading a bunch of bytes rather than doing a word read.

So this is a false positive as a fix. Sorry about that.
Conversely it shouldn't break anything.

Looking back at the history, what happened was that up to v5 of this patchset
factored out the reads, but whilst doing that converted them to
i2c_smbus_read_word_data with a be16_to_cpu call which was buggy and
picked up in review. Hence confusion occurred and I guess my eyes saw
what they expected to see once the fix was pulled to the front of the series.

Thanks,

Jonathan



> Best regards,
> Pavel