* [PATCH 4.14 01/49] netfilter: ipset: Missing nfnl_lock()/nfnl_unlock() is added to ip_set_net_exit()
2018-04-17 15:58 [PATCH 4.14 00/49] 4.14.35-stable review Greg Kroah-Hartman
@ 2018-04-17 15:58 ` Greg Kroah-Hartman
2018-04-17 15:58 ` [PATCH 4.14 02/49] cdc_ether: flag the Cinterion AHS8 modem by gemalto as WWAN Greg Kroah-Hartman
` (51 subsequent siblings)
52 siblings, 0 replies; 58+ messages in thread
From: Greg Kroah-Hartman @ 2018-04-17 15:58 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Jozsef Kadlecsik,
syzbot+36b06f219f2439fe62e1, Pablo Neira Ayuso
4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jozsef Kadlecsik <kadlec@blackhole.kfki.hu>
commit f998b6b10144cd9809da6af02758615f789e8aa1 upstream.
Patch "netfilter: ipset: use nfnl_mutex_is_locked" is added the real
mutex locking check, which revealed the missing locking in ip_set_net_exit().
Signed-off-by: Jozsef Kadlecsik <kadlec@blackhole.kfki.hu>
Reported-by: syzbot+36b06f219f2439fe62e1@syzkaller.appspotmail.com
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
net/netfilter/ipset/ip_set_core.c | 2 ++
1 file changed, 2 insertions(+)
--- a/net/netfilter/ipset/ip_set_core.c
+++ b/net/netfilter/ipset/ip_set_core.c
@@ -2055,6 +2055,7 @@ ip_set_net_exit(struct net *net)
inst->is_deleted = true; /* flag for ip_set_nfnl_put */
+ nfnl_lock(NFNL_SUBSYS_IPSET);
for (i = 0; i < inst->ip_set_max; i++) {
set = ip_set(inst, i);
if (set) {
@@ -2062,6 +2063,7 @@ ip_set_net_exit(struct net *net)
ip_set_destroy_set(set);
}
}
+ nfnl_unlock(NFNL_SUBSYS_IPSET);
kfree(rcu_dereference_protected(inst->ip_set_list, 1));
}
^ permalink raw reply [flat|nested] 58+ messages in thread* [PATCH 4.14 02/49] cdc_ether: flag the Cinterion AHS8 modem by gemalto as WWAN
2018-04-17 15:58 [PATCH 4.14 00/49] 4.14.35-stable review Greg Kroah-Hartman
2018-04-17 15:58 ` [PATCH 4.14 01/49] netfilter: ipset: Missing nfnl_lock()/nfnl_unlock() is added to ip_set_net_exit() Greg Kroah-Hartman
@ 2018-04-17 15:58 ` Greg Kroah-Hartman
2018-04-17 15:58 ` [PATCH 4.14 03/49] rds: MP-RDS may use an invalid c_path Greg Kroah-Hartman
` (50 subsequent siblings)
52 siblings, 0 replies; 58+ messages in thread
From: Greg Kroah-Hartman @ 2018-04-17 15:58 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Bassem Boubaker, Oliver Neukum,
David S. Miller
4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Bassem Boubaker <bassem.boubaker@actia.fr>
[ Upstream commit 53765341ee821c0a0f1dec41adc89c9096ad694c ]
The Cinterion AHS8 is a 3G device with one embedded WWAN interface
using cdc_ether as a driver.
The modem is controlled via AT commands through the exposed TTYs.
AT+CGDCONT write command can be used to activate or deactivate a WWAN
connection for a PDP context defined with the same command. UE
supports one WWAN adapter.
Signed-off-by: Bassem Boubaker <bassem.boubaker@actia.fr>
Acked-by: Oliver Neukum <oneukum@suse.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/net/usb/cdc_ether.c | 6 ++++++
1 file changed, 6 insertions(+)
--- a/drivers/net/usb/cdc_ether.c
+++ b/drivers/net/usb/cdc_ether.c
@@ -896,6 +896,12 @@ static const struct usb_device_id produc
USB_CDC_PROTO_NONE),
.driver_info = (unsigned long)&wwan_info,
}, {
+ /* Cinterion AHS3 modem by GEMALTO */
+ USB_DEVICE_AND_INTERFACE_INFO(0x1e2d, 0x0055, USB_CLASS_COMM,
+ USB_CDC_SUBCLASS_ETHERNET,
+ USB_CDC_PROTO_NONE),
+ .driver_info = (unsigned long)&wwan_info,
+}, {
USB_INTERFACE_INFO(USB_CLASS_COMM, USB_CDC_SUBCLASS_ETHERNET,
USB_CDC_PROTO_NONE),
.driver_info = (unsigned long) &cdc_info,
^ permalink raw reply [flat|nested] 58+ messages in thread* [PATCH 4.14 03/49] rds: MP-RDS may use an invalid c_path
2018-04-17 15:58 [PATCH 4.14 00/49] 4.14.35-stable review Greg Kroah-Hartman
2018-04-17 15:58 ` [PATCH 4.14 01/49] netfilter: ipset: Missing nfnl_lock()/nfnl_unlock() is added to ip_set_net_exit() Greg Kroah-Hartman
2018-04-17 15:58 ` [PATCH 4.14 02/49] cdc_ether: flag the Cinterion AHS8 modem by gemalto as WWAN Greg Kroah-Hartman
@ 2018-04-17 15:58 ` Greg Kroah-Hartman
2018-04-17 15:58 ` [PATCH 4.14 04/49] slip: Check if rstate is initialized before uncompressing Greg Kroah-Hartman
` (49 subsequent siblings)
52 siblings, 0 replies; 58+ messages in thread
From: Greg Kroah-Hartman @ 2018-04-17 15:58 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Ka-Cheong Poon, Santosh Shilimkar,
David S. Miller
4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ka-Cheong Poon <ka-cheong.poon@oracle.com>
[ Upstream commit a43cced9a348901f9015f4730b70b69e7c41a9c9 ]
rds_sendmsg() calls rds_send_mprds_hash() to find a c_path to use to
send a message. Suppose the RDS connection is not yet up. In
rds_send_mprds_hash(), it does
if (conn->c_npaths == 0)
wait_event_interruptible(conn->c_hs_waitq,
(conn->c_npaths != 0));
If it is interrupted before the connection is set up,
rds_send_mprds_hash() will return a non-zero hash value. Hence
rds_sendmsg() will use a non-zero c_path to send the message. But if
the RDS connection ends up to be non-MP capable, the message will be
lost as only the zero c_path can be used.
Signed-off-by: Ka-Cheong Poon <ka-cheong.poon@oracle.com>
Acked-by: Santosh Shilimkar <santosh.shilimkar@oracle.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
net/rds/send.c | 15 ++++++++++-----
1 file changed, 10 insertions(+), 5 deletions(-)
--- a/net/rds/send.c
+++ b/net/rds/send.c
@@ -1,5 +1,5 @@
/*
- * Copyright (c) 2006 Oracle. All rights reserved.
+ * Copyright (c) 2006, 2018 Oracle and/or its affiliates. All rights reserved.
*
* This software is available to you under a choice of one of two
* licenses. You may choose to be licensed under the terms of the GNU
@@ -986,10 +986,15 @@ static int rds_send_mprds_hash(struct rd
if (conn->c_npaths == 0 && hash != 0) {
rds_send_ping(conn, 0);
- if (conn->c_npaths == 0) {
- wait_event_interruptible(conn->c_hs_waitq,
- (conn->c_npaths != 0));
- }
+ /* The underlying connection is not up yet. Need to wait
+ * until it is up to be sure that the non-zero c_path can be
+ * used. But if we are interrupted, we have to use the zero
+ * c_path in case the connection ends up being non-MP capable.
+ */
+ if (conn->c_npaths == 0)
+ if (wait_event_interruptible(conn->c_hs_waitq,
+ conn->c_npaths != 0))
+ hash = 0;
if (conn->c_npaths == 1)
hash = 0;
}
^ permalink raw reply [flat|nested] 58+ messages in thread* [PATCH 4.14 04/49] slip: Check if rstate is initialized before uncompressing
2018-04-17 15:58 [PATCH 4.14 00/49] 4.14.35-stable review Greg Kroah-Hartman
` (2 preceding siblings ...)
2018-04-17 15:58 ` [PATCH 4.14 03/49] rds: MP-RDS may use an invalid c_path Greg Kroah-Hartman
@ 2018-04-17 15:58 ` Greg Kroah-Hartman
2018-04-17 15:58 ` [PATCH 4.14 05/49] vhost: fix vhost_vq_access_ok() log check Greg Kroah-Hartman
` (48 subsequent siblings)
52 siblings, 0 replies; 58+ messages in thread
From: Greg Kroah-Hartman @ 2018-04-17 15:58 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Tejaswi Tanikella, David S. Miller
4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Tejaswi Tanikella <tejaswit@codeaurora.org>
[ Upstream commit 3f01ddb962dc506916c243f9524e8bef97119b77 ]
On receiving a packet the state index points to the rstate which must be
used to fill up IP and TCP headers. But if the state index points to a
rstate which is unitialized, i.e. filled with zeros, it gets stuck in an
infinite loop inside ip_fast_csum trying to compute the ip checsum of a
header with zero length.
89.666953: <2> [<ffffff9dd3e94d38>] slhc_uncompress+0x464/0x468
89.666965: <2> [<ffffff9dd3e87d88>] ppp_receive_nonmp_frame+0x3b4/0x65c
89.666978: <2> [<ffffff9dd3e89dd4>] ppp_receive_frame+0x64/0x7e0
89.666991: <2> [<ffffff9dd3e8a708>] ppp_input+0x104/0x198
89.667005: <2> [<ffffff9dd3e93868>] pppopns_recv_core+0x238/0x370
89.667027: <2> [<ffffff9dd4428fc8>] __sk_receive_skb+0xdc/0x250
89.667040: <2> [<ffffff9dd3e939e4>] pppopns_recv+0x44/0x60
89.667053: <2> [<ffffff9dd4426848>] __sock_queue_rcv_skb+0x16c/0x24c
89.667065: <2> [<ffffff9dd4426954>] sock_queue_rcv_skb+0x2c/0x38
89.667085: <2> [<ffffff9dd44f7358>] raw_rcv+0x124/0x154
89.667098: <2> [<ffffff9dd44f7568>] raw_local_deliver+0x1e0/0x22c
89.667117: <2> [<ffffff9dd44c8ba0>] ip_local_deliver_finish+0x70/0x24c
89.667131: <2> [<ffffff9dd44c92f4>] ip_local_deliver+0x100/0x10c
./scripts/faddr2line vmlinux slhc_uncompress+0x464/0x468 output:
ip_fast_csum at arch/arm64/include/asm/checksum.h:40
(inlined by) slhc_uncompress at drivers/net/slip/slhc.c:615
Adding a variable to indicate if the current rstate is initialized. If
such a packet arrives, move to toss state.
Signed-off-by: Tejaswi Tanikella <tejaswit@codeaurora.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/net/slip/slhc.c | 5 +++++
include/net/slhc_vj.h | 1 +
2 files changed, 6 insertions(+)
--- a/drivers/net/slip/slhc.c
+++ b/drivers/net/slip/slhc.c
@@ -509,6 +509,10 @@ slhc_uncompress(struct slcompress *comp,
if(x < 0 || x > comp->rslot_limit)
goto bad;
+ /* Check if the cstate is initialized */
+ if (!comp->rstate[x].initialized)
+ goto bad;
+
comp->flags &=~ SLF_TOSS;
comp->recv_current = x;
} else {
@@ -673,6 +677,7 @@ slhc_remember(struct slcompress *comp, u
if (cs->cs_tcp.doff > 5)
memcpy(cs->cs_tcpopt, icp + ihl*4 + sizeof(struct tcphdr), (cs->cs_tcp.doff - 5) * 4);
cs->cs_hsize = ihl*2 + cs->cs_tcp.doff*2;
+ cs->initialized = true;
/* Put headers back on packet
* Neither header checksum is recalculated
*/
--- a/include/net/slhc_vj.h
+++ b/include/net/slhc_vj.h
@@ -127,6 +127,7 @@ typedef __u32 int32;
*/
struct cstate {
byte_t cs_this; /* connection id number (xmit) */
+ bool initialized; /* true if initialized */
struct cstate *next; /* next in ring (xmit) */
struct iphdr cs_ip; /* ip/tcp hdr from most recent packet */
struct tcphdr cs_tcp;
^ permalink raw reply [flat|nested] 58+ messages in thread* [PATCH 4.14 05/49] vhost: fix vhost_vq_access_ok() log check
2018-04-17 15:58 [PATCH 4.14 00/49] 4.14.35-stable review Greg Kroah-Hartman
` (3 preceding siblings ...)
2018-04-17 15:58 ` [PATCH 4.14 04/49] slip: Check if rstate is initialized before uncompressing Greg Kroah-Hartman
@ 2018-04-17 15:58 ` Greg Kroah-Hartman
2018-04-17 15:58 ` [PATCH 4.14 06/49] vhost: Fix vhost_copy_to_user() Greg Kroah-Hartman
` (47 subsequent siblings)
52 siblings, 0 replies; 58+ messages in thread
From: Greg Kroah-Hartman @ 2018-04-17 15:58 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, syzbot+65a84dde0214b0387ccd,
Jason Wang, Stefan Hajnoczi, Michael S. Tsirkin, David S. Miller
4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Stefan Hajnoczi <stefanha@redhat.com>
[ Upstream commit d14d2b78090c7de0557362b26a4ca591aa6a9faa ]
Commit d65026c6c62e7d9616c8ceb5a53b68bcdc050525 ("vhost: validate log
when IOTLB is enabled") introduced a regression. The logic was
originally:
if (vq->iotlb)
return 1;
return A && B;
After the patch the short-circuit logic for A was inverted:
if (A || vq->iotlb)
return A;
return B;
This patch fixes the regression by rewriting the checks in the obvious
way, no longer returning A when vq->iotlb is non-NULL (which is hard to
understand).
Reported-by: syzbot+65a84dde0214b0387ccd@syzkaller.appspotmail.com
Cc: Jason Wang <jasowang@redhat.com>
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Acked-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/vhost/vhost.c | 8 +++++---
1 file changed, 5 insertions(+), 3 deletions(-)
--- a/drivers/vhost/vhost.c
+++ b/drivers/vhost/vhost.c
@@ -1252,10 +1252,12 @@ static int vq_log_access_ok(struct vhost
/* Caller should have vq mutex and device mutex */
int vhost_vq_access_ok(struct vhost_virtqueue *vq)
{
- int ret = vq_log_access_ok(vq, vq->log_base);
+ if (!vq_log_access_ok(vq, vq->log_base))
+ return 0;
- if (ret || vq->iotlb)
- return ret;
+ /* Access validation occurs at prefetch time with IOTLB */
+ if (vq->iotlb)
+ return 1;
return vq_access_ok(vq, vq->num, vq->desc, vq->avail, vq->used);
}
^ permalink raw reply [flat|nested] 58+ messages in thread* [PATCH 4.14 06/49] vhost: Fix vhost_copy_to_user()
2018-04-17 15:58 [PATCH 4.14 00/49] 4.14.35-stable review Greg Kroah-Hartman
` (4 preceding siblings ...)
2018-04-17 15:58 ` [PATCH 4.14 05/49] vhost: fix vhost_vq_access_ok() log check Greg Kroah-Hartman
@ 2018-04-17 15:58 ` Greg Kroah-Hartman
2018-04-17 15:58 ` [PATCH 4.14 07/49] lan78xx: Correctly indicate invalid OTP Greg Kroah-Hartman
` (46 subsequent siblings)
52 siblings, 0 replies; 58+ messages in thread
From: Greg Kroah-Hartman @ 2018-04-17 15:58 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Eric Auger, Jason Wang,
Michael S. Tsirkin, David S. Miller
4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Eric Auger <eric.auger@redhat.com>
[ Upstream commit 7ced6c98c7ab7a1f6743931e28671b833af79b1e ]
vhost_copy_to_user is used to copy vring used elements to userspace.
We should use VHOST_ADDR_USED instead of VHOST_ADDR_DESC.
Fixes: f88949138058 ("vhost: introduce O(1) vq metadata cache")
Signed-off-by: Eric Auger <eric.auger@redhat.com>
Acked-by: Jason Wang <jasowang@redhat.com>
Acked-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/vhost/vhost.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/vhost/vhost.c
+++ b/drivers/vhost/vhost.c
@@ -756,7 +756,7 @@ static int vhost_copy_to_user(struct vho
struct iov_iter t;
void __user *uaddr = vhost_vq_meta_fetch(vq,
(u64)(uintptr_t)to, size,
- VHOST_ADDR_DESC);
+ VHOST_ADDR_USED);
if (uaddr)
return __copy_to_user(uaddr, from, size);
^ permalink raw reply [flat|nested] 58+ messages in thread* [PATCH 4.14 07/49] lan78xx: Correctly indicate invalid OTP
2018-04-17 15:58 [PATCH 4.14 00/49] 4.14.35-stable review Greg Kroah-Hartman
` (5 preceding siblings ...)
2018-04-17 15:58 ` [PATCH 4.14 06/49] vhost: Fix vhost_copy_to_user() Greg Kroah-Hartman
@ 2018-04-17 15:58 ` Greg Kroah-Hartman
2018-04-17 15:58 ` [PATCH 4.14 08/49] media: v4l2-compat-ioctl32: dont oops on overlay Greg Kroah-Hartman
` (45 subsequent siblings)
52 siblings, 0 replies; 58+ messages in thread
From: Greg Kroah-Hartman @ 2018-04-17 15:58 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Phil Elwell, David S. Miller
4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Phil Elwell <phil@raspberrypi.org>
[ Upstream commit 4bfc33807a9a02764bdd1e42e794b3b401240f27 ]
lan78xx_read_otp tries to return -EINVAL in the event of invalid OTP
content, but the value gets overwritten before it is returned and the
read goes ahead anyway. Make the read conditional as it should be
and preserve the error code.
Fixes: 55d7de9de6c3 ("Microchip's LAN7800 family USB 2/3 to 10/100/1000 Ethernet device driver")
Signed-off-by: Phil Elwell <phil@raspberrypi.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/net/usb/lan78xx.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/drivers/net/usb/lan78xx.c
+++ b/drivers/net/usb/lan78xx.c
@@ -928,7 +928,8 @@ static int lan78xx_read_otp(struct lan78
offset += 0x100;
else
ret = -EINVAL;
- ret = lan78xx_read_raw_otp(dev, offset, length, data);
+ if (!ret)
+ ret = lan78xx_read_raw_otp(dev, offset, length, data);
}
return ret;
^ permalink raw reply [flat|nested] 58+ messages in thread* [PATCH 4.14 08/49] media: v4l2-compat-ioctl32: dont oops on overlay
2018-04-17 15:58 [PATCH 4.14 00/49] 4.14.35-stable review Greg Kroah-Hartman
` (6 preceding siblings ...)
2018-04-17 15:58 ` [PATCH 4.14 07/49] lan78xx: Correctly indicate invalid OTP Greg Kroah-Hartman
@ 2018-04-17 15:58 ` Greg Kroah-Hartman
2018-04-17 15:58 ` [PATCH 4.14 09/49] media: v4l: vsp1: Fix header display list status check in continuous mode Greg Kroah-Hartman
` (44 subsequent siblings)
52 siblings, 0 replies; 58+ messages in thread
From: Greg Kroah-Hartman @ 2018-04-17 15:58 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Mauro Carvalho Chehab, Sakari Ailus,
Hans Verkuil
4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Mauro Carvalho Chehab <mchehab@s-opensource.com>
commit 85ea29f19eab56ec16ec6b92bc67305998706afa upstream.
At put_v4l2_window32(), it tries to access kp->clips. However,
kp points to an userspace pointer. So, it should be obtained
via get_user(), otherwise it can OOPS:
vivid-000: ================== END STATUS ==================
BUG: unable to handle kernel paging request at 00000000fffb18e0
IP: [<ffffffffc05468d9>] __put_v4l2_format32+0x169/0x220 [videodev]
PGD 3f5776067 PUD 3f576f067 PMD 3f5769067 PTE 800000042548f067
Oops: 0001 [#1] SMP
Modules linked in: vivid videobuf2_vmalloc videobuf2_memops v4l2_dv_timings videobuf2_core v4l2_common videodev media xt_CHECKSUM iptable_mangle ipt_MASQUERADE nf_nat_masquerade_ipv4 iptable_nat nf_nat_ipv4 nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack nf_conntrack tun bridge stp llc ebtable_filter ebtables ip6table_filter ip6_tables bluetooth rfkill binfmt_misc snd_hda_codec_hdmi i915 snd_hda_intel snd_hda_controller snd_hda_codec intel_rapl x86_pkg_temp_thermal snd_hwdep intel_powerclamp snd_pcm coretemp snd_seq_midi kvm_intel kvm snd_seq_midi_event snd_rawmidi i2c_algo_bit drm_kms_helper snd_seq drm crct10dif_pclmul e1000e snd_seq_device crc32_pclmul snd_timer ghash_clmulni_intel snd mei_me mei ptp pps_core soundcore lpc_ich video crc32c_intel [last unloaded: media]
CPU: 2 PID: 28332 Comm: v4l2-compliance Not tainted 3.18.102+ #107
Hardware name: /NUC5i7RYB, BIOS RYBDWi35.86A.0364.2017.0511.0949 05/11/2017
task: ffff8804293f8000 ti: ffff8803f5640000 task.ti: ffff8803f5640000
RIP: 0010:[<ffffffffc05468d9>] [<ffffffffc05468d9>] __put_v4l2_format32+0x169/0x220 [videodev]
RSP: 0018:ffff8803f5643e28 EFLAGS: 00010246
RAX: 0000000000000000 RBX: 0000000000000000 RCX: 00000000fffb1ab4
RDX: 00000000fffb1a68 RSI: 00000000fffb18d8 RDI: 00000000fffb1aa8
RBP: ffff8803f5643e48 R08: 0000000000000001 R09: ffff8803f54b0378
R10: 0000000000000000 R11: 0000000000000168 R12: 00000000fffb18c0
R13: 00000000fffb1a94 R14: 00000000fffb18c8 R15: 0000000000000000
FS: 0000000000000000(0000) GS:ffff880456d00000(0063) knlGS:00000000f7100980
CS: 0010 DS: 002b ES: 002b CR0: 0000000080050033
CR2: 00000000fffb18e0 CR3: 00000003f552b000 CR4: 00000000003407e0
Stack:
00000000fffb1a94 00000000c0cc5640 0000000000000056 ffff8804274f3600
ffff8803f5643ed0 ffffffffc0547e16 0000000000000003 ffff8803f5643eb0
ffffffff81301460 ffff88009db44b01 ffff880441942520 ffff8800c0d05640
Call Trace:
[<ffffffffc0547e16>] v4l2_compat_ioctl32+0x12d6/0x1b1d [videodev]
[<ffffffff81301460>] ? file_has_perm+0x70/0xc0
[<ffffffff81252a2c>] compat_SyS_ioctl+0xec/0x1200
[<ffffffff8173241a>] sysenter_dispatch+0x7/0x21
Code: 00 00 48 8b 80 48 c0 ff ff 48 83 e8 38 49 39 c6 0f 87 2b ff ff ff 49 8d 45 1c e8 a3 ce e3 c0 85 c0 0f 85 1a ff ff ff 41 8d 40 ff <4d> 8b 64 24 20 41 89 d5 48 8d 44 40 03 4d 8d 34 c4 eb 15 0f 1f
RIP [<ffffffffc05468d9>] __put_v4l2_format32+0x169/0x220 [videodev]
RSP <ffff8803f5643e28>
CR2: 00000000fffb18e0
Tested with vivid driver on Kernel v3.18.102.
Same bug happens upstream too:
BUG: KASAN: user-memory-access in __put_v4l2_format32+0x98/0x4d0 [videodev]
Read of size 8 at addr 00000000ffe48400 by task v4l2-compliance/8713
CPU: 0 PID: 8713 Comm: v4l2-compliance Not tainted 4.16.0-rc4+ #108
Hardware name: /NUC5i7RYB, BIOS RYBDWi35.86A.0364.2017.0511.0949 05/11/2017
Call Trace:
dump_stack+0x5c/0x7c
kasan_report+0x164/0x380
? __put_v4l2_format32+0x98/0x4d0 [videodev]
__put_v4l2_format32+0x98/0x4d0 [videodev]
v4l2_compat_ioctl32+0x1aec/0x27a0 [videodev]
? __fsnotify_inode_delete+0x20/0x20
? __put_v4l2_format32+0x4d0/0x4d0 [videodev]
compat_SyS_ioctl+0x646/0x14d0
? do_ioctl+0x30/0x30
do_fast_syscall_32+0x191/0x3f4
entry_SYSENTER_compat+0x6b/0x7a
==================================================================
Disabling lock debugging due to kernel taint
BUG: unable to handle kernel paging request at 00000000ffe48400
IP: __put_v4l2_format32+0x98/0x4d0 [videodev]
PGD 3a22fb067 P4D 3a22fb067 PUD 39b6f0067 PMD 39b6f1067 PTE 80000003256af067
Oops: 0001 [#1] SMP KASAN
Modules linked in: vivid videobuf2_vmalloc videobuf2_dma_contig videobuf2_memops v4l2_tpg v4l2_dv_timings videobuf2_v4l2 videobuf2_common v4l2_common videodev xt_CHECKSUM iptable_mangle ipt_MASQUERADE nf_nat_masquerade_ipv4 iptable_nat nf_nat_ipv4 nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack nf_conntrack libcrc32c tun bridge stp llc ebtable_filter ebtables ip6table_filter ip6_tables bluetooth rfkill ecdh_generic binfmt_misc snd_hda_codec_hdmi intel_rapl x86_pkg_temp_thermal intel_powerclamp i915 coretemp snd_hda_intel snd_hda_codec kvm_intel snd_hwdep snd_hda_core kvm snd_pcm irqbypass crct10dif_pclmul crc32_pclmul snd_seq_midi ghash_clmulni_intel snd_seq_midi_event i2c_algo_bit intel_cstate snd_rawmidi intel_uncore snd_seq drm_kms_helper e1000e snd_seq_device snd_timer intel_rapl_perf
drm ptp snd mei_me mei lpc_ich pps_core soundcore video crc32c_intel
CPU: 0 PID: 8713 Comm: v4l2-compliance Tainted: G B 4.16.0-rc4+ #108
Hardware name: /NUC5i7RYB, BIOS RYBDWi35.86A.0364.2017.0511.0949 05/11/2017
RIP: 0010:__put_v4l2_format32+0x98/0x4d0 [videodev]
RSP: 0018:ffff8803b9be7d30 EFLAGS: 00010282
RAX: 0000000000000000 RBX: ffff8803ac983e80 RCX: ffffffff8cd929f2
RDX: 1ffffffff1d0a149 RSI: 0000000000000297 RDI: 0000000000000297
RBP: 00000000ffe485c0 R08: fffffbfff1cf5123 R09: ffffffff8e7a8948
R10: 0000000000000001 R11: fffffbfff1cf5122 R12: 00000000ffe483e0
R13: 00000000ffe485c4 R14: ffff8803ac985918 R15: 00000000ffe483e8
FS: 0000000000000000(0000) GS:ffff880407400000(0063) knlGS:00000000f7a46980
CS: 0010 DS: 002b ES: 002b CR0: 0000000080050033
CR2: 00000000ffe48400 CR3: 00000003a83f2003 CR4: 00000000003606f0
Call Trace:
v4l2_compat_ioctl32+0x1aec/0x27a0 [videodev]
? __fsnotify_inode_delete+0x20/0x20
? __put_v4l2_format32+0x4d0/0x4d0 [videodev]
compat_SyS_ioctl+0x646/0x14d0
? do_ioctl+0x30/0x30
do_fast_syscall_32+0x191/0x3f4
entry_SYSENTER_compat+0x6b/0x7a
Code: 4c 89 f7 4d 8d 7c 24 08 e8 e6 a4 69 cb 48 8b 83 98 1a 00 00 48 83 e8 10 49 39 c7 0f 87 9d 01 00 00 49 8d 7c 24 20 e8 c8 a4 69 cb <4d> 8b 74 24 20 4c 89 ef 4c 89 fe ba 10 00 00 00 e8 23 d9 08 cc
RIP: __put_v4l2_format32+0x98/0x4d0 [videodev] RSP: ffff8803b9be7d30
CR2: 00000000ffe48400
cc: stable@vger.kernel.org
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Reviewed-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Reviewed-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/media/v4l2-core/v4l2-compat-ioctl32.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
--- a/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
+++ b/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
@@ -101,7 +101,7 @@ static int get_v4l2_window32(struct v4l2
static int put_v4l2_window32(struct v4l2_window __user *kp,
struct v4l2_window32 __user *up)
{
- struct v4l2_clip __user *kclips = kp->clips;
+ struct v4l2_clip __user *kclips;
struct v4l2_clip32 __user *uclips;
compat_caddr_t p;
u32 clipcount;
@@ -116,6 +116,8 @@ static int put_v4l2_window32(struct v4l2
if (!clipcount)
return 0;
+ if (get_user(kclips, &kp->clips))
+ return -EFAULT;
if (get_user(p, &up->clips))
return -EFAULT;
uclips = compat_ptr(p);
^ permalink raw reply [flat|nested] 58+ messages in thread* [PATCH 4.14 09/49] media: v4l: vsp1: Fix header display list status check in continuous mode
2018-04-17 15:58 [PATCH 4.14 00/49] 4.14.35-stable review Greg Kroah-Hartman
` (7 preceding siblings ...)
2018-04-17 15:58 ` [PATCH 4.14 08/49] media: v4l2-compat-ioctl32: dont oops on overlay Greg Kroah-Hartman
@ 2018-04-17 15:58 ` Greg Kroah-Hartman
2018-04-17 15:58 ` [PATCH 4.14 10/49] parisc: Fix out of array access in match_pci_device() Greg Kroah-Hartman
` (43 subsequent siblings)
52 siblings, 0 replies; 58+ messages in thread
From: Greg Kroah-Hartman @ 2018-04-17 15:58 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Kieran Bingham, Laurent Pinchart,
Mauro Carvalho Chehab
4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>
commit 613928e85317b945c863bb893f5737d2f22f5425 upstream.
To allow dual pipelines utilising two WPF entities when available, the
VSP was updated to support header-mode display list in continuous
pipelines.
A small bug in the status check of the command register causes the
second pipeline to be directly afflicted by the running of the first;
appearing as a perceived performance issue with stuttering display.
Fix the vsp1_dl_list_hw_update_pending() call to ensure that the read
comparison corresponds to the correct pipeline.
Fixes: eaf4bfad6ad8 ("v4l: vsp1: Add support for header display lists in continuous mode")
Cc: "Stable v4.14+" <stable@vger.kernel.org>
Signed-off-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/media/platform/vsp1/vsp1_dl.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/drivers/media/platform/vsp1/vsp1_dl.c
+++ b/drivers/media/platform/vsp1/vsp1_dl.c
@@ -508,7 +508,8 @@ static bool vsp1_dl_list_hw_update_pendi
return !!(vsp1_read(vsp1, VI6_DL_BODY_SIZE)
& VI6_DL_BODY_SIZE_UPD);
else
- return !!(vsp1_read(vsp1, VI6_CMD(dlm->index) & VI6_CMD_UPDHDR));
+ return !!(vsp1_read(vsp1, VI6_CMD(dlm->index))
+ & VI6_CMD_UPDHDR);
}
static void vsp1_dl_list_hw_enqueue(struct vsp1_dl_list *dl)
^ permalink raw reply [flat|nested] 58+ messages in thread* [PATCH 4.14 10/49] parisc: Fix out of array access in match_pci_device()
2018-04-17 15:58 [PATCH 4.14 00/49] 4.14.35-stable review Greg Kroah-Hartman
` (8 preceding siblings ...)
2018-04-17 15:58 ` [PATCH 4.14 09/49] media: v4l: vsp1: Fix header display list status check in continuous mode Greg Kroah-Hartman
@ 2018-04-17 15:58 ` Greg Kroah-Hartman
2018-04-17 15:58 ` [PATCH 4.14 11/49] parisc: Fix HPMC handler by increasing size to multiple of 16 bytes Greg Kroah-Hartman
` (42 subsequent siblings)
52 siblings, 0 replies; 58+ messages in thread
From: Greg Kroah-Hartman @ 2018-04-17 15:58 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Helge Deller
4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Helge Deller <deller@gmx.de>
commit 615b2665fd20c327b631ff1e79426775de748094 upstream.
As found by the ubsan checker, the value of the 'index' variable can be
out of range for the bc[] array:
UBSAN: Undefined behaviour in arch/parisc/kernel/drivers.c:655:21
index 6 is out of range for type 'char [6]'
Backtrace:
[<104fa850>] __ubsan_handle_out_of_bounds+0x68/0x80
[<1019d83c>] check_parent+0xc0/0x170
[<1019d91c>] descend_children+0x30/0x6c
[<1059e164>] device_for_each_child+0x60/0x98
[<1019cd54>] parse_tree_node+0x40/0x54
[<1019d86c>] check_parent+0xf0/0x170
[<1019d91c>] descend_children+0x30/0x6c
[<1059e164>] device_for_each_child+0x60/0x98
[<1019d938>] descend_children+0x4c/0x6c
[<1059e164>] device_for_each_child+0x60/0x98
[<1019cd54>] parse_tree_node+0x40/0x54
[<1019cffc>] hwpath_to_device+0xa4/0xc4
Signed-off-by: Helge Deller <deller@gmx.de>
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/parisc/kernel/drivers.c | 4 ++++
1 file changed, 4 insertions(+)
--- a/arch/parisc/kernel/drivers.c
+++ b/arch/parisc/kernel/drivers.c
@@ -651,6 +651,10 @@ static int match_pci_device(struct devic
(modpath->mod == PCI_FUNC(devfn)));
}
+ /* index might be out of bounds for bc[] */
+ if (index >= 6)
+ return 0;
+
id = PCI_SLOT(pdev->devfn) | (PCI_FUNC(pdev->devfn) << 5);
return (modpath->bc[index] == id);
}
^ permalink raw reply [flat|nested] 58+ messages in thread* [PATCH 4.14 11/49] parisc: Fix HPMC handler by increasing size to multiple of 16 bytes
2018-04-17 15:58 [PATCH 4.14 00/49] 4.14.35-stable review Greg Kroah-Hartman
` (9 preceding siblings ...)
2018-04-17 15:58 ` [PATCH 4.14 10/49] parisc: Fix out of array access in match_pci_device() Greg Kroah-Hartman
@ 2018-04-17 15:58 ` Greg Kroah-Hartman
2018-04-17 15:58 ` [PATCH 4.14 12/49] Drivers: hv: vmbus: do not mark HV_PCIE as perf_device Greg Kroah-Hartman
` (41 subsequent siblings)
52 siblings, 0 replies; 58+ messages in thread
From: Greg Kroah-Hartman @ 2018-04-17 15:58 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Helge Deller
4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Helge Deller <deller@gmx.de>
commit d5654e156bc4d68a87bbaa6d7e020baceddf6e68 upstream.
Make sure that the HPMC (High Priority Machine Check) handler is 16-byte
aligned and that it's length in the IVT is a multiple of 16 bytes.
Otherwise PDC may decide not to call the HPMC crash handler.
Signed-off-by: Helge Deller <deller@gmx.de>
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/parisc/kernel/hpmc.S | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
--- a/arch/parisc/kernel/hpmc.S
+++ b/arch/parisc/kernel/hpmc.S
@@ -84,6 +84,7 @@ END(hpmc_pim_data)
.text
.import intr_save, code
+ .align 16
ENTRY_CFI(os_hpmc)
.os_hpmc:
@@ -300,12 +301,15 @@ os_hpmc_6:
b .
nop
+ .align 16 /* make function length multiple of 16 bytes */
ENDPROC_CFI(os_hpmc)
.os_hpmc_end:
__INITRODATA
+.globl os_hpmc_size
.align 4
- .export os_hpmc_size
+ .type os_hpmc_size, @object
+ .size os_hpmc_size, 4
os_hpmc_size:
.word .os_hpmc_end-.os_hpmc
^ permalink raw reply [flat|nested] 58+ messages in thread* [PATCH 4.14 12/49] Drivers: hv: vmbus: do not mark HV_PCIE as perf_device
2018-04-17 15:58 [PATCH 4.14 00/49] 4.14.35-stable review Greg Kroah-Hartman
` (10 preceding siblings ...)
2018-04-17 15:58 ` [PATCH 4.14 11/49] parisc: Fix HPMC handler by increasing size to multiple of 16 bytes Greg Kroah-Hartman
@ 2018-04-17 15:58 ` Greg Kroah-Hartman
2018-04-17 15:58 ` [PATCH 4.14 13/49] PCI: hv: Serialize the present and eject work items Greg Kroah-Hartman
` (40 subsequent siblings)
52 siblings, 0 replies; 58+ messages in thread
From: Greg Kroah-Hartman @ 2018-04-17 15:58 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Dexuan Cui, Stephen Hemminger,
K. Y. Srinivasan
4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Dexuan Cui <decui@microsoft.com>
commit 238064f13d057390a8c5e1a6a80f4f0a0ec46499 upstream.
The pci-hyperv driver's channel callback hv_pci_onchannelcallback() is not
really a hot path, so we don't need to mark it as a perf_device, meaning
with this patch all HV_PCIE channels' target_cpu will be CPU0.
Signed-off-by: Dexuan Cui <decui@microsoft.com>
Cc: stable@vger.kernel.org
Cc: Stephen Hemminger <sthemmin@microsoft.com>
Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/hv/channel_mgmt.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/hv/channel_mgmt.c
+++ b/drivers/hv/channel_mgmt.c
@@ -71,7 +71,7 @@ static const struct vmbus_device vmbus_d
/* PCIE */
{ .dev_type = HV_PCIE,
HV_PCIE_GUID,
- .perf_device = true,
+ .perf_device = false,
},
/* Synthetic Frame Buffer */
^ permalink raw reply [flat|nested] 58+ messages in thread* [PATCH 4.14 13/49] PCI: hv: Serialize the present and eject work items
2018-04-17 15:58 [PATCH 4.14 00/49] 4.14.35-stable review Greg Kroah-Hartman
` (11 preceding siblings ...)
2018-04-17 15:58 ` [PATCH 4.14 12/49] Drivers: hv: vmbus: do not mark HV_PCIE as perf_device Greg Kroah-Hartman
@ 2018-04-17 15:58 ` Greg Kroah-Hartman
2018-04-17 15:58 ` [PATCH 4.14 14/49] KVM: PPC: Book3S HV: trace_tlbie must not be called in realmode Greg Kroah-Hartman
` (39 subsequent siblings)
52 siblings, 0 replies; 58+ messages in thread
From: Greg Kroah-Hartman @ 2018-04-17 15:58 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Adrian Suhov, Chris Valean,
Dexuan Cui, Lorenzo Pieralisi, Michael Kelley, Haiyang Zhang,
Vitaly Kuznetsov, Jack Morgenstein, Stephen Hemminger,
K. Y. Srinivasan
4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Dexuan Cui <decui@microsoft.com>
commit 021ad274d7dc31611d4f47f7dd4ac7a224526f30 upstream.
When we hot-remove the device, we first receive a PCI_EJECT message and
then receive a PCI_BUS_RELATIONS message with bus_rel->device_count == 0.
The first message is offloaded to hv_eject_device_work(), and the second
is offloaded to pci_devices_present_work(). Both the paths can be running
list_del(&hpdev->list_entry), causing general protection fault, because
system_wq can run them concurrently.
The patch eliminates the race condition.
Since access to present/eject work items is serialized, we do not need the
hbus->enum_sem anymore, so remove it.
Fixes: 4daace0d8ce8 ("PCI: hv: Add paravirtual PCI front-end for Microsoft Hyper-V VMs")
Link: https://lkml.kernel.org/r/KL1P15301MB00064DA6B4D221123B5241CFBFD70@KL1P15301MB0006.APCP153.PROD.OUTLOOK.COM
Tested-by: Adrian Suhov <v-adsuho@microsoft.com>
Tested-by: Chris Valean <v-chvale@microsoft.com>
Signed-off-by: Dexuan Cui <decui@microsoft.com>
[lorenzo.pieralisi@arm.com: squashed semaphore removal patch]
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Reviewed-by: Michael Kelley <mikelley@microsoft.com>
Acked-by: Haiyang Zhang <haiyangz@microsoft.com>
Cc: <stable@vger.kernel.org> # v4.6+
Cc: Vitaly Kuznetsov <vkuznets@redhat.com>
Cc: Jack Morgenstein <jackm@mellanox.com>
Cc: Stephen Hemminger <sthemmin@microsoft.com>
Cc: K. Y. Srinivasan <kys@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/pci/host/pci-hyperv.c | 34 ++++++++++++++++------------------
1 file changed, 16 insertions(+), 18 deletions(-)
--- a/drivers/pci/host/pci-hyperv.c
+++ b/drivers/pci/host/pci-hyperv.c
@@ -457,7 +457,6 @@ struct hv_pcibus_device {
spinlock_t device_list_lock; /* Protect lists below */
void __iomem *cfg_addr;
- struct semaphore enum_sem;
struct list_head resources_for_children;
struct list_head children;
@@ -471,6 +470,8 @@ struct hv_pcibus_device {
struct retarget_msi_interrupt retarget_msi_interrupt_params;
spinlock_t retarget_msi_interrupt_lock;
+
+ struct workqueue_struct *wq;
};
/*
@@ -1604,12 +1605,8 @@ static struct hv_pci_dev *get_pcichild_w
* It must also treat the omission of a previously observed device as
* notification that the device no longer exists.
*
- * Note that this function is a work item, and it may not be
- * invoked in the order that it was queued. Back to back
- * updates of the list of present devices may involve queuing
- * multiple work items, and this one may run before ones that
- * were sent later. As such, this function only does something
- * if is the last one in the queue.
+ * Note that this function is serialized with hv_eject_device_work(),
+ * because both are pushed to the ordered workqueue hbus->wq.
*/
static void pci_devices_present_work(struct work_struct *work)
{
@@ -1630,11 +1627,6 @@ static void pci_devices_present_work(str
INIT_LIST_HEAD(&removed);
- if (down_interruptible(&hbus->enum_sem)) {
- put_hvpcibus(hbus);
- return;
- }
-
/* Pull this off the queue and process it if it was the last one. */
spin_lock_irqsave(&hbus->device_list_lock, flags);
while (!list_empty(&hbus->dr_list)) {
@@ -1651,7 +1643,6 @@ static void pci_devices_present_work(str
spin_unlock_irqrestore(&hbus->device_list_lock, flags);
if (!dr) {
- up(&hbus->enum_sem);
put_hvpcibus(hbus);
return;
}
@@ -1738,7 +1729,6 @@ static void pci_devices_present_work(str
break;
}
- up(&hbus->enum_sem);
put_hvpcibus(hbus);
kfree(dr);
}
@@ -1784,7 +1774,7 @@ static void hv_pci_devices_present(struc
spin_unlock_irqrestore(&hbus->device_list_lock, flags);
get_hvpcibus(hbus);
- schedule_work(&dr_wrk->wrk);
+ queue_work(hbus->wq, &dr_wrk->wrk);
}
/**
@@ -1862,7 +1852,7 @@ static void hv_pci_eject_device(struct h
get_pcichild(hpdev, hv_pcidev_ref_pnp);
INIT_WORK(&hpdev->wrk, hv_eject_device_work);
get_hvpcibus(hpdev->hbus);
- schedule_work(&hpdev->wrk);
+ queue_work(hpdev->hbus->wq, &hpdev->wrk);
}
/**
@@ -2475,13 +2465,18 @@ static int hv_pci_probe(struct hv_device
spin_lock_init(&hbus->config_lock);
spin_lock_init(&hbus->device_list_lock);
spin_lock_init(&hbus->retarget_msi_interrupt_lock);
- sema_init(&hbus->enum_sem, 1);
init_completion(&hbus->remove_event);
+ hbus->wq = alloc_ordered_workqueue("hv_pci_%x", 0,
+ hbus->sysdata.domain);
+ if (!hbus->wq) {
+ ret = -ENOMEM;
+ goto free_bus;
+ }
ret = vmbus_open(hdev->channel, pci_ring_size, pci_ring_size, NULL, 0,
hv_pci_onchannelcallback, hbus);
if (ret)
- goto free_bus;
+ goto destroy_wq;
hv_set_drvdata(hdev, hbus);
@@ -2550,6 +2545,8 @@ free_config:
hv_free_config_window(hbus);
close:
vmbus_close(hdev->channel);
+destroy_wq:
+ destroy_workqueue(hbus->wq);
free_bus:
free_page((unsigned long)hbus);
return ret;
@@ -2629,6 +2626,7 @@ static int hv_pci_remove(struct hv_devic
irq_domain_free_fwnode(hbus->sysdata.fwnode);
put_hvpcibus(hbus);
wait_for_completion(&hbus->remove_event);
+ destroy_workqueue(hbus->wq);
free_page((unsigned long)hbus);
return 0;
}
^ permalink raw reply [flat|nested] 58+ messages in thread* [PATCH 4.14 14/49] KVM: PPC: Book3S HV: trace_tlbie must not be called in realmode
2018-04-17 15:58 [PATCH 4.14 00/49] 4.14.35-stable review Greg Kroah-Hartman
` (12 preceding siblings ...)
2018-04-17 15:58 ` [PATCH 4.14 13/49] PCI: hv: Serialize the present and eject work items Greg Kroah-Hartman
@ 2018-04-17 15:58 ` Greg Kroah-Hartman
2018-04-17 15:58 ` [PATCH 4.14 15/49] perf intel-pt: Fix overlap detection to identify consecutive buffers correctly Greg Kroah-Hartman
` (38 subsequent siblings)
52 siblings, 0 replies; 58+ messages in thread
From: Greg Kroah-Hartman @ 2018-04-17 15:58 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Nicholas Piggin, Michael Ellerman
4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Nicholas Piggin <npiggin@gmail.com>
commit 19ce7909ed11c49f7eddf59e7f49cd3062bf83d5 upstream.
This crashes with a "Bad real address for load" attempting to load
from the vmalloc region in realmode (faulting address is in DAR).
Oops: Bad interrupt in KVM entry/exit code, sig: 6 [#1]
LE SMP NR_CPUS=2048 NUMA PowerNV
CPU: 53 PID: 6582 Comm: qemu-system-ppc Not tainted 4.16.0-01530-g43d1859f0994
NIP: c0000000000155ac LR: c0000000000c2430 CTR: c000000000015580
REGS: c000000fff76dd80 TRAP: 0200 Not tainted (4.16.0-01530-g43d1859f0994)
MSR: 9000000000201003 <SF,HV,ME,RI,LE> CR: 48082222 XER: 00000000
CFAR: 0000000102900ef0 DAR: d00017fffd941a28 DSISR: 00000040 SOFTE: 3
NIP [c0000000000155ac] perf_trace_tlbie+0x2c/0x1a0
LR [c0000000000c2430] do_tlbies+0x230/0x2f0
I suspect the reason is the per-cpu data is not in the linear chunk.
This could be restored if that was able to be fixed, but for now,
just remove the tracepoints.
Fixes: 0428491cba92 ("powerpc/mm: Trace tlbie(l) instructions")
Cc: stable@vger.kernel.org # v4.13+
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/powerpc/kvm/book3s_hv_rm_mmu.c | 4 ----
1 file changed, 4 deletions(-)
--- a/arch/powerpc/kvm/book3s_hv_rm_mmu.c
+++ b/arch/powerpc/kvm/book3s_hv_rm_mmu.c
@@ -447,8 +447,6 @@ static void do_tlbies(struct kvm *kvm, u
for (i = 0; i < npages; ++i) {
asm volatile(PPC_TLBIE_5(%0,%1,0,0,0) : :
"r" (rbvalues[i]), "r" (kvm->arch.lpid));
- trace_tlbie(kvm->arch.lpid, 0, rbvalues[i],
- kvm->arch.lpid, 0, 0, 0);
}
asm volatile("eieio; tlbsync; ptesync" : : : "memory");
kvm->arch.tlbie_lock = 0;
@@ -458,8 +456,6 @@ static void do_tlbies(struct kvm *kvm, u
for (i = 0; i < npages; ++i) {
asm volatile(PPC_TLBIEL(%0,%1,0,0,0) : :
"r" (rbvalues[i]), "r" (0));
- trace_tlbie(kvm->arch.lpid, 1, rbvalues[i],
- 0, 0, 0, 0);
}
asm volatile("ptesync" : : : "memory");
}
^ permalink raw reply [flat|nested] 58+ messages in thread* [PATCH 4.14 15/49] perf intel-pt: Fix overlap detection to identify consecutive buffers correctly
2018-04-17 15:58 [PATCH 4.14 00/49] 4.14.35-stable review Greg Kroah-Hartman
` (13 preceding siblings ...)
2018-04-17 15:58 ` [PATCH 4.14 14/49] KVM: PPC: Book3S HV: trace_tlbie must not be called in realmode Greg Kroah-Hartman
@ 2018-04-17 15:58 ` Greg Kroah-Hartman
2018-04-17 15:58 ` [PATCH 4.14 16/49] perf intel-pt: Fix sync_switch Greg Kroah-Hartman
` (37 subsequent siblings)
52 siblings, 0 replies; 58+ messages in thread
From: Greg Kroah-Hartman @ 2018-04-17 15:58 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Adrian Hunter, Jiri Olsa,
Arnaldo Carvalho de Melo
4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Adrian Hunter <adrian.hunter@intel.com>
commit 117db4b27bf08dba412faf3924ba55fe970c57b8 upstream.
Overlap detection was not not updating the buffer's 'consecutive' flag.
Marking buffers consecutive has the advantage that decoding begins from
the start of the buffer instead of the first PSB. Fix overlap detection
to identify consecutive buffers correctly.
Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: stable@vger.kernel.org
Link: http://lkml.kernel.org/r/1520431349-30689-2-git-send-email-adrian.hunter@intel.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
tools/perf/util/intel-pt-decoder/intel-pt-decoder.c | 62 +++++++++-----------
tools/perf/util/intel-pt-decoder/intel-pt-decoder.h | 2
tools/perf/util/intel-pt.c | 5 +
3 files changed, 34 insertions(+), 35 deletions(-)
--- a/tools/perf/util/intel-pt-decoder/intel-pt-decoder.c
+++ b/tools/perf/util/intel-pt-decoder/intel-pt-decoder.c
@@ -2390,14 +2390,6 @@ const struct intel_pt_state *intel_pt_de
return &decoder->state;
}
-static bool intel_pt_at_psb(unsigned char *buf, size_t len)
-{
- if (len < INTEL_PT_PSB_LEN)
- return false;
- return memmem(buf, INTEL_PT_PSB_LEN, INTEL_PT_PSB_STR,
- INTEL_PT_PSB_LEN);
-}
-
/**
* intel_pt_next_psb - move buffer pointer to the start of the next PSB packet.
* @buf: pointer to buffer pointer
@@ -2486,6 +2478,7 @@ static unsigned char *intel_pt_last_psb(
* @buf: buffer
* @len: size of buffer
* @tsc: TSC value returned
+ * @rem: returns remaining size when TSC is found
*
* Find a TSC packet in @buf and return the TSC value. This function assumes
* that @buf starts at a PSB and that PSB+ will contain TSC and so stops if a
@@ -2493,7 +2486,8 @@ static unsigned char *intel_pt_last_psb(
*
* Return: %true if TSC is found, false otherwise.
*/
-static bool intel_pt_next_tsc(unsigned char *buf, size_t len, uint64_t *tsc)
+static bool intel_pt_next_tsc(unsigned char *buf, size_t len, uint64_t *tsc,
+ size_t *rem)
{
struct intel_pt_pkt packet;
int ret;
@@ -2504,6 +2498,7 @@ static bool intel_pt_next_tsc(unsigned c
return false;
if (packet.type == INTEL_PT_TSC) {
*tsc = packet.payload;
+ *rem = len;
return true;
}
if (packet.type == INTEL_PT_PSBEND)
@@ -2554,6 +2549,8 @@ static int intel_pt_tsc_cmp(uint64_t tsc
* @len_a: size of first buffer
* @buf_b: second buffer
* @len_b: size of second buffer
+ * @consecutive: returns true if there is data in buf_b that is consecutive
+ * to buf_a
*
* If the trace contains TSC we can look at the last TSC of @buf_a and the
* first TSC of @buf_b in order to determine if the buffers overlap, and then
@@ -2566,33 +2563,41 @@ static int intel_pt_tsc_cmp(uint64_t tsc
static unsigned char *intel_pt_find_overlap_tsc(unsigned char *buf_a,
size_t len_a,
unsigned char *buf_b,
- size_t len_b)
+ size_t len_b, bool *consecutive)
{
uint64_t tsc_a, tsc_b;
unsigned char *p;
- size_t len;
+ size_t len, rem_a, rem_b;
p = intel_pt_last_psb(buf_a, len_a);
if (!p)
return buf_b; /* No PSB in buf_a => no overlap */
len = len_a - (p - buf_a);
- if (!intel_pt_next_tsc(p, len, &tsc_a)) {
+ if (!intel_pt_next_tsc(p, len, &tsc_a, &rem_a)) {
/* The last PSB+ in buf_a is incomplete, so go back one more */
len_a -= len;
p = intel_pt_last_psb(buf_a, len_a);
if (!p)
return buf_b; /* No full PSB+ => assume no overlap */
len = len_a - (p - buf_a);
- if (!intel_pt_next_tsc(p, len, &tsc_a))
+ if (!intel_pt_next_tsc(p, len, &tsc_a, &rem_a))
return buf_b; /* No TSC in buf_a => assume no overlap */
}
while (1) {
/* Ignore PSB+ with no TSC */
- if (intel_pt_next_tsc(buf_b, len_b, &tsc_b) &&
- intel_pt_tsc_cmp(tsc_a, tsc_b) < 0)
- return buf_b; /* tsc_a < tsc_b => no overlap */
+ if (intel_pt_next_tsc(buf_b, len_b, &tsc_b, &rem_b)) {
+ int cmp = intel_pt_tsc_cmp(tsc_a, tsc_b);
+
+ /* Same TSC, so buffers are consecutive */
+ if (!cmp && rem_b >= rem_a) {
+ *consecutive = true;
+ return buf_b + len_b - (rem_b - rem_a);
+ }
+ if (cmp < 0)
+ return buf_b; /* tsc_a < tsc_b => no overlap */
+ }
if (!intel_pt_step_psb(&buf_b, &len_b))
return buf_b + len_b; /* No PSB in buf_b => no data */
@@ -2606,6 +2611,8 @@ static unsigned char *intel_pt_find_over
* @buf_b: second buffer
* @len_b: size of second buffer
* @have_tsc: can use TSC packets to detect overlap
+ * @consecutive: returns true if there is data in buf_b that is consecutive
+ * to buf_a
*
* When trace samples or snapshots are recorded there is the possibility that
* the data overlaps. Note that, for the purposes of decoding, data is only
@@ -2616,7 +2623,7 @@ static unsigned char *intel_pt_find_over
*/
unsigned char *intel_pt_find_overlap(unsigned char *buf_a, size_t len_a,
unsigned char *buf_b, size_t len_b,
- bool have_tsc)
+ bool have_tsc, bool *consecutive)
{
unsigned char *found;
@@ -2628,7 +2635,8 @@ unsigned char *intel_pt_find_overlap(uns
return buf_b; /* No overlap */
if (have_tsc) {
- found = intel_pt_find_overlap_tsc(buf_a, len_a, buf_b, len_b);
+ found = intel_pt_find_overlap_tsc(buf_a, len_a, buf_b, len_b,
+ consecutive);
if (found)
return found;
}
@@ -2643,28 +2651,16 @@ unsigned char *intel_pt_find_overlap(uns
}
/* Now len_b >= len_a */
- if (len_b > len_a) {
- /* The leftover buffer 'b' must start at a PSB */
- while (!intel_pt_at_psb(buf_b + len_a, len_b - len_a)) {
- if (!intel_pt_step_psb(&buf_a, &len_a))
- return buf_b; /* No overlap */
- }
- }
-
while (1) {
/* Potential overlap so check the bytes */
found = memmem(buf_a, len_a, buf_b, len_a);
- if (found)
+ if (found) {
+ *consecutive = true;
return buf_b + len_a;
+ }
/* Try again at next PSB in buffer 'a' */
if (!intel_pt_step_psb(&buf_a, &len_a))
return buf_b; /* No overlap */
-
- /* The leftover buffer 'b' must start at a PSB */
- while (!intel_pt_at_psb(buf_b + len_a, len_b - len_a)) {
- if (!intel_pt_step_psb(&buf_a, &len_a))
- return buf_b; /* No overlap */
- }
}
}
--- a/tools/perf/util/intel-pt-decoder/intel-pt-decoder.h
+++ b/tools/perf/util/intel-pt-decoder/intel-pt-decoder.h
@@ -117,7 +117,7 @@ const struct intel_pt_state *intel_pt_de
unsigned char *intel_pt_find_overlap(unsigned char *buf_a, size_t len_a,
unsigned char *buf_b, size_t len_b,
- bool have_tsc);
+ bool have_tsc, bool *consecutive);
int intel_pt__strerror(int code, char *buf, size_t buflen);
--- a/tools/perf/util/intel-pt.c
+++ b/tools/perf/util/intel-pt.c
@@ -209,14 +209,17 @@ static void intel_pt_dump_event(struct i
static int intel_pt_do_fix_overlap(struct intel_pt *pt, struct auxtrace_buffer *a,
struct auxtrace_buffer *b)
{
+ bool consecutive = false;
void *start;
start = intel_pt_find_overlap(a->data, a->size, b->data, b->size,
- pt->have_tsc);
+ pt->have_tsc, &consecutive);
if (!start)
return -EINVAL;
b->use_size = b->data + b->size - start;
b->use_data = start;
+ if (b->use_size && consecutive)
+ b->consecutive = true;
return 0;
}
^ permalink raw reply [flat|nested] 58+ messages in thread* [PATCH 4.14 16/49] perf intel-pt: Fix sync_switch
2018-04-17 15:58 [PATCH 4.14 00/49] 4.14.35-stable review Greg Kroah-Hartman
` (14 preceding siblings ...)
2018-04-17 15:58 ` [PATCH 4.14 15/49] perf intel-pt: Fix overlap detection to identify consecutive buffers correctly Greg Kroah-Hartman
@ 2018-04-17 15:58 ` Greg Kroah-Hartman
2018-04-17 15:58 ` [PATCH 4.14 17/49] perf intel-pt: Fix error recovery from missing TIP packet Greg Kroah-Hartman
` (36 subsequent siblings)
52 siblings, 0 replies; 58+ messages in thread
From: Greg Kroah-Hartman @ 2018-04-17 15:58 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Adrian Hunter, Jiri Olsa,
Arnaldo Carvalho de Melo
4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Adrian Hunter <adrian.hunter@intel.com>
commit 63d8e38f6ae6c36dd5b5ba0e8c112e8861532ea2 upstream.
sync_switch is a facility to synchronize decoding more closely with the
point in the kernel when the context actually switched.
The flag when sync_switch is enabled was global to the decoding, whereas
it is really specific to the CPU.
The trace data for different CPUs is put on different queues, so add
sync_switch to the intel_pt_queue structure and use that in preference
to the global setting in the intel_pt structure.
That fixes problems decoding one CPU's trace because sync_switch was
disabled on a different CPU's queue.
Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: stable@vger.kernel.org
Link: http://lkml.kernel.org/r/1520431349-30689-3-git-send-email-adrian.hunter@intel.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
tools/perf/util/intel-pt.c | 32 +++++++++++++++++++++++++-------
1 file changed, 25 insertions(+), 7 deletions(-)
--- a/tools/perf/util/intel-pt.c
+++ b/tools/perf/util/intel-pt.c
@@ -145,6 +145,7 @@ struct intel_pt_queue {
bool stop;
bool step_through_buffers;
bool use_buffer_pid_tid;
+ bool sync_switch;
pid_t pid, tid;
int cpu;
int switch_state;
@@ -965,10 +966,12 @@ static int intel_pt_setup_queue(struct i
if (pt->timeless_decoding || !pt->have_sched_switch)
ptq->use_buffer_pid_tid = true;
}
+
+ ptq->sync_switch = pt->sync_switch;
}
if (!ptq->on_heap &&
- (!pt->sync_switch ||
+ (!ptq->sync_switch ||
ptq->switch_state != INTEL_PT_SS_EXPECTING_SWITCH_EVENT)) {
const struct intel_pt_state *state;
int ret;
@@ -1552,7 +1555,7 @@ static int intel_pt_sample(struct intel_
if (pt->synth_opts.last_branch)
intel_pt_update_last_branch_rb(ptq);
- if (!pt->sync_switch)
+ if (!ptq->sync_switch)
return 0;
if (intel_pt_is_switch_ip(ptq, state->to_ip)) {
@@ -1633,6 +1636,21 @@ static u64 intel_pt_switch_ip(struct int
return switch_ip;
}
+static void intel_pt_enable_sync_switch(struct intel_pt *pt)
+{
+ unsigned int i;
+
+ pt->sync_switch = true;
+
+ for (i = 0; i < pt->queues.nr_queues; i++) {
+ struct auxtrace_queue *queue = &pt->queues.queue_array[i];
+ struct intel_pt_queue *ptq = queue->priv;
+
+ if (ptq)
+ ptq->sync_switch = true;
+ }
+}
+
static int intel_pt_run_decoder(struct intel_pt_queue *ptq, u64 *timestamp)
{
const struct intel_pt_state *state = ptq->state;
@@ -1649,7 +1667,7 @@ static int intel_pt_run_decoder(struct i
if (pt->switch_ip) {
intel_pt_log("switch_ip: %"PRIx64" ptss_ip: %"PRIx64"\n",
pt->switch_ip, pt->ptss_ip);
- pt->sync_switch = true;
+ intel_pt_enable_sync_switch(pt);
}
}
}
@@ -1665,9 +1683,9 @@ static int intel_pt_run_decoder(struct i
if (state->err) {
if (state->err == INTEL_PT_ERR_NODATA)
return 1;
- if (pt->sync_switch &&
+ if (ptq->sync_switch &&
state->from_ip >= pt->kernel_start) {
- pt->sync_switch = false;
+ ptq->sync_switch = false;
intel_pt_next_tid(pt, ptq);
}
if (pt->synth_opts.errors) {
@@ -1693,7 +1711,7 @@ static int intel_pt_run_decoder(struct i
state->timestamp, state->est_timestamp);
ptq->timestamp = state->est_timestamp;
/* Use estimated TSC in unknown switch state */
- } else if (pt->sync_switch &&
+ } else if (ptq->sync_switch &&
ptq->switch_state == INTEL_PT_SS_UNKNOWN &&
intel_pt_is_switch_ip(ptq, state->to_ip) &&
ptq->next_tid == -1) {
@@ -1840,7 +1858,7 @@ static int intel_pt_sync_switch(struct i
return 1;
ptq = intel_pt_cpu_to_ptq(pt, cpu);
- if (!ptq)
+ if (!ptq || !ptq->sync_switch)
return 1;
switch (ptq->switch_state) {
^ permalink raw reply [flat|nested] 58+ messages in thread* [PATCH 4.14 17/49] perf intel-pt: Fix error recovery from missing TIP packet
2018-04-17 15:58 [PATCH 4.14 00/49] 4.14.35-stable review Greg Kroah-Hartman
` (15 preceding siblings ...)
2018-04-17 15:58 ` [PATCH 4.14 16/49] perf intel-pt: Fix sync_switch Greg Kroah-Hartman
@ 2018-04-17 15:58 ` Greg Kroah-Hartman
2018-04-17 15:58 ` [PATCH 4.14 18/49] perf intel-pt: Fix timestamp following overflow Greg Kroah-Hartman
` (35 subsequent siblings)
52 siblings, 0 replies; 58+ messages in thread
From: Greg Kroah-Hartman @ 2018-04-17 15:58 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Adrian Hunter, Jiri Olsa,
Arnaldo Carvalho de Melo
4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Adrian Hunter <adrian.hunter@intel.com>
commit 1c196a6c771c47a2faa63d38d913e03284f73a16 upstream.
When a TIP packet is expected but there is a different packet, it is an
error. However the unexpected packet might be something important like a
TSC packet, so after the error, it is necessary to continue from there,
rather than the next packet. That is achieved by setting pkt_step to
zero.
Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: stable@vger.kernel.org
Link: http://lkml.kernel.org/r/1520431349-30689-4-git-send-email-adrian.hunter@intel.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
tools/perf/util/intel-pt-decoder/intel-pt-decoder.c | 1 +
1 file changed, 1 insertion(+)
--- a/tools/perf/util/intel-pt-decoder/intel-pt-decoder.c
+++ b/tools/perf/util/intel-pt-decoder/intel-pt-decoder.c
@@ -1616,6 +1616,7 @@ static int intel_pt_walk_fup_tip(struct
case INTEL_PT_PWRX:
intel_pt_log("ERROR: Missing TIP after FUP\n");
decoder->pkt_state = INTEL_PT_STATE_ERR3;
+ decoder->pkt_step = 0;
return -ENOENT;
case INTEL_PT_OVF:
^ permalink raw reply [flat|nested] 58+ messages in thread* [PATCH 4.14 18/49] perf intel-pt: Fix timestamp following overflow
2018-04-17 15:58 [PATCH 4.14 00/49] 4.14.35-stable review Greg Kroah-Hartman
` (16 preceding siblings ...)
2018-04-17 15:58 ` [PATCH 4.14 17/49] perf intel-pt: Fix error recovery from missing TIP packet Greg Kroah-Hartman
@ 2018-04-17 15:58 ` Greg Kroah-Hartman
2018-04-17 15:58 ` [PATCH 4.14 19/49] perf/core: Fix use-after-free in uprobe_perf_close() Greg Kroah-Hartman
` (34 subsequent siblings)
52 siblings, 0 replies; 58+ messages in thread
From: Greg Kroah-Hartman @ 2018-04-17 15:58 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Adrian Hunter, Jiri Olsa,
Arnaldo Carvalho de Melo
4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Adrian Hunter <adrian.hunter@intel.com>
commit 91d29b288aed3406caf7c454bf2b898c96cfd177 upstream.
timestamp_insn_cnt is used to estimate the timestamp based on the number of
instructions since the last known timestamp.
If the estimate is not accurate enough decoding might not be correctly
synchronized with side-band events causing more trace errors.
However there are always timestamps following an overflow, so the
estimate is not needed and can indeed result in more errors.
Suppress the estimate by setting timestamp_insn_cnt to zero.
Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: stable@vger.kernel.org
Link: http://lkml.kernel.org/r/1520431349-30689-5-git-send-email-adrian.hunter@intel.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
tools/perf/util/intel-pt-decoder/intel-pt-decoder.c | 1 +
1 file changed, 1 insertion(+)
--- a/tools/perf/util/intel-pt-decoder/intel-pt-decoder.c
+++ b/tools/perf/util/intel-pt-decoder/intel-pt-decoder.c
@@ -1378,6 +1378,7 @@ static int intel_pt_overflow(struct inte
intel_pt_clear_tx_flags(decoder);
decoder->have_tma = false;
decoder->cbr = 0;
+ decoder->timestamp_insn_cnt = 0;
decoder->pkt_state = INTEL_PT_STATE_ERR_RESYNC;
decoder->overflow = true;
return -EOVERFLOW;
^ permalink raw reply [flat|nested] 58+ messages in thread* [PATCH 4.14 19/49] perf/core: Fix use-after-free in uprobe_perf_close()
2018-04-17 15:58 [PATCH 4.14 00/49] 4.14.35-stable review Greg Kroah-Hartman
` (17 preceding siblings ...)
2018-04-17 15:58 ` [PATCH 4.14 18/49] perf intel-pt: Fix timestamp following overflow Greg Kroah-Hartman
@ 2018-04-17 15:58 ` Greg Kroah-Hartman
2018-04-17 15:58 ` [PATCH 4.14 20/49] radeon: hide pointless #warning when compile testing Greg Kroah-Hartman
` (33 subsequent siblings)
52 siblings, 0 replies; 58+ messages in thread
From: Greg Kroah-Hartman @ 2018-04-17 15:58 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Prashant Bhole, Oleg Nesterov,
Peter Zijlstra (Intel),
stable, Alexander Shishkin, Arnaldo Carvalho de Melo, Jiri Olsa,
Linus Torvalds, Namhyung Kim, Thomas Gleixner, Ingo Molnar
4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Prashant Bhole <bhole_prashant_q7@lab.ntt.co.jp>
commit 621b6d2ea297d0fb6030452c5bcd221f12165fcf upstream.
A use-after-free bug was caught by KASAN while running usdt related
code (BCC project. bcc/tests/python/test_usdt2.py):
==================================================================
BUG: KASAN: use-after-free in uprobe_perf_close+0x222/0x3b0
Read of size 4 at addr ffff880384f9b4a4 by task test_usdt2.py/870
CPU: 4 PID: 870 Comm: test_usdt2.py Tainted: G W 4.16.0-next-20180409 #215
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Ubuntu-1.8.2-1ubuntu1 04/01/2014
Call Trace:
dump_stack+0xc7/0x15b
? show_regs_print_info+0x5/0x5
? printk+0x9c/0xc3
? kmsg_dump_rewind_nolock+0x6e/0x6e
? uprobe_perf_close+0x222/0x3b0
print_address_description+0x83/0x3a0
? uprobe_perf_close+0x222/0x3b0
kasan_report+0x1dd/0x460
? uprobe_perf_close+0x222/0x3b0
uprobe_perf_close+0x222/0x3b0
? probes_open+0x180/0x180
? free_filters_list+0x290/0x290
trace_uprobe_register+0x1bb/0x500
? perf_event_attach_bpf_prog+0x310/0x310
? probe_event_disable+0x4e0/0x4e0
perf_uprobe_destroy+0x63/0xd0
_free_event+0x2bc/0xbd0
? lockdep_rcu_suspicious+0x100/0x100
? ring_buffer_attach+0x550/0x550
? kvm_sched_clock_read+0x1a/0x30
? perf_event_release_kernel+0x3e4/0xc00
? __mutex_unlock_slowpath+0x12e/0x540
? wait_for_completion+0x430/0x430
? lock_downgrade+0x3c0/0x3c0
? lock_release+0x980/0x980
? do_raw_spin_trylock+0x118/0x150
? do_raw_spin_unlock+0x121/0x210
? do_raw_spin_trylock+0x150/0x150
perf_event_release_kernel+0x5d4/0xc00
? put_event+0x30/0x30
? fsnotify+0xd2d/0xea0
? sched_clock_cpu+0x18/0x1a0
? __fsnotify_update_child_dentry_flags.part.0+0x1b0/0x1b0
? pvclock_clocksource_read+0x152/0x2b0
? pvclock_read_flags+0x80/0x80
? kvm_sched_clock_read+0x1a/0x30
? sched_clock_cpu+0x18/0x1a0
? pvclock_clocksource_read+0x152/0x2b0
? locks_remove_file+0xec/0x470
? pvclock_read_flags+0x80/0x80
? fcntl_setlk+0x880/0x880
? ima_file_free+0x8d/0x390
? lockdep_rcu_suspicious+0x100/0x100
? ima_file_check+0x110/0x110
? fsnotify+0xea0/0xea0
? kvm_sched_clock_read+0x1a/0x30
? rcu_note_context_switch+0x600/0x600
perf_release+0x21/0x40
__fput+0x264/0x620
? fput+0xf0/0xf0
? do_raw_spin_unlock+0x121/0x210
? do_raw_spin_trylock+0x150/0x150
? SyS_fchdir+0x100/0x100
? fsnotify+0xea0/0xea0
task_work_run+0x14b/0x1e0
? task_work_cancel+0x1c0/0x1c0
? copy_fd_bitmaps+0x150/0x150
? vfs_read+0xe5/0x260
exit_to_usermode_loop+0x17b/0x1b0
? trace_event_raw_event_sys_exit+0x1a0/0x1a0
do_syscall_64+0x3f6/0x490
? syscall_return_slowpath+0x2c0/0x2c0
? lockdep_sys_exit+0x1f/0xaa
? syscall_return_slowpath+0x1a3/0x2c0
? lockdep_sys_exit+0x1f/0xaa
? prepare_exit_to_usermode+0x11c/0x1e0
? enter_from_user_mode+0x30/0x30
random: crng init done
? __put_user_4+0x1c/0x30
entry_SYSCALL_64_after_hwframe+0x3d/0xa2
RIP: 0033:0x7f41d95f9340
RSP: 002b:00007fffe71e4268 EFLAGS: 00000246 ORIG_RAX: 0000000000000003
RAX: 0000000000000000 RBX: 000000000000000d RCX: 00007f41d95f9340
RDX: 0000000000000000 RSI: 0000000000002401 RDI: 000000000000000d
RBP: 0000000000000000 R08: 00007f41ca8ff700 R09: 00007f41d996dd1f
R10: 00007fffe71e41e0 R11: 0000000000000246 R12: 00007fffe71e4330
R13: 0000000000000000 R14: fffffffffffffffc R15: 00007fffe71e4290
Allocated by task 870:
kasan_kmalloc+0xa0/0xd0
kmem_cache_alloc_node+0x11a/0x430
copy_process.part.19+0x11a0/0x41c0
_do_fork+0x1be/0xa20
do_syscall_64+0x198/0x490
entry_SYSCALL_64_after_hwframe+0x3d/0xa2
Freed by task 0:
__kasan_slab_free+0x12e/0x180
kmem_cache_free+0x102/0x4d0
free_task+0xfe/0x160
__put_task_struct+0x189/0x290
delayed_put_task_struct+0x119/0x250
rcu_process_callbacks+0xa6c/0x1b60
__do_softirq+0x238/0x7ae
The buggy address belongs to the object at ffff880384f9b480
which belongs to the cache task_struct of size 12928
It occurs because task_struct is freed before perf_event which refers
to the task and task flags are checked while teardown of the event.
perf_event_alloc() assigns task_struct to hw.target of perf_event,
but there is no reference counting for it.
As a fix we get_task_struct() in perf_event_alloc() at above mentioned
assignment and put_task_struct() in _free_event().
Signed-off-by: Prashant Bhole <bhole_prashant_q7@lab.ntt.co.jp>
Reviewed-by: Oleg Nesterov <oleg@redhat.com>
Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: <stable@kernel.org>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Arnaldo Carvalho de Melo <acme@kernel.org>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Fixes: 63b6da39bb38e8f1a1ef3180d32a39d6 ("perf: Fix perf_event_exit_task() race")
Link: http://lkml.kernel.org/r/20180409100346.6416-1-bhole_prashant_q7@lab.ntt.co.jp
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
kernel/events/core.c | 6 ++++++
1 file changed, 6 insertions(+)
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -4199,6 +4199,9 @@ static void _free_event(struct perf_even
if (event->ctx)
put_ctx(event->ctx);
+ if (event->hw.target)
+ put_task_struct(event->hw.target);
+
exclusive_event_destroy(event);
module_put(event->pmu->module);
@@ -9508,6 +9511,7 @@ perf_event_alloc(struct perf_event_attr
* and we cannot use the ctx information because we need the
* pmu before we get a ctx.
*/
+ get_task_struct(task);
event->hw.target = task;
}
@@ -9623,6 +9627,8 @@ err_ns:
perf_detach_cgroup(event);
if (event->ns)
put_pid_ns(event->ns);
+ if (event->hw.target)
+ put_task_struct(event->hw.target);
kfree(event);
return ERR_PTR(err);
^ permalink raw reply [flat|nested] 58+ messages in thread* [PATCH 4.14 20/49] radeon: hide pointless #warning when compile testing
2018-04-17 15:58 [PATCH 4.14 00/49] 4.14.35-stable review Greg Kroah-Hartman
` (18 preceding siblings ...)
2018-04-17 15:58 ` [PATCH 4.14 19/49] perf/core: Fix use-after-free in uprobe_perf_close() Greg Kroah-Hartman
@ 2018-04-17 15:58 ` Greg Kroah-Hartman
2018-04-17 15:59 ` [PATCH 4.14 21/49] x86/MCE/AMD: Define a function to get SMCA bank type Greg Kroah-Hartman
` (32 subsequent siblings)
52 siblings, 0 replies; 58+ messages in thread
From: Greg Kroah-Hartman @ 2018-04-17 15:58 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Arnd Bergmann, Michel Dänzer,
Alex Deucher
4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Arnd Bergmann <arnd@arndb.de>
commit c02216acf4177c4411d33735c81cad687790fa59 upstream.
In randconfig testing, we sometimes get this warning:
drivers/gpu/drm/radeon/radeon_object.c: In function 'radeon_bo_create':
drivers/gpu/drm/radeon/radeon_object.c:242:2: error: #warning Please enable CONFIG_MTRR and CONFIG_X86_PAT for better performance thanks to write-combining [-Werror=cpp]
#warning Please enable CONFIG_MTRR and CONFIG_X86_PAT for better performance \
This is rather annoying since almost all other code produces no build-time
output unless we have found a real bug. We already fixed this in the
amdgpu driver in commit 31bb90f1cd08 ("drm/amdgpu: shut up #warning for
compile testing") by adding a CONFIG_COMPILE_TEST check last year and
agreed to do the same here, but both Michel and I then forgot about it
until I came across the issue again now.
For stable kernels, as this is one of very few remaining randconfig
warnings in 4.14.
Cc: stable@vger.kernel.org
Link: https://patchwork.kernel.org/patch/9550009/
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/gpu/drm/radeon/radeon_object.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/drivers/gpu/drm/radeon/radeon_object.c
+++ b/drivers/gpu/drm/radeon/radeon_object.c
@@ -240,9 +240,10 @@ int radeon_bo_create(struct radeon_devic
* may be slow
* See https://bugs.freedesktop.org/show_bug.cgi?id=88758
*/
-
+#ifndef CONFIG_COMPILE_TEST
#warning Please enable CONFIG_MTRR and CONFIG_X86_PAT for better performance \
thanks to write-combining
+#endif
if (bo->flags & RADEON_GEM_GTT_WC)
DRM_INFO_ONCE("Please enable CONFIG_MTRR and CONFIG_X86_PAT for "
^ permalink raw reply [flat|nested] 58+ messages in thread* [PATCH 4.14 21/49] x86/MCE/AMD: Define a function to get SMCA bank type
2018-04-17 15:58 [PATCH 4.14 00/49] 4.14.35-stable review Greg Kroah-Hartman
` (19 preceding siblings ...)
2018-04-17 15:58 ` [PATCH 4.14 20/49] radeon: hide pointless #warning when compile testing Greg Kroah-Hartman
@ 2018-04-17 15:59 ` Greg Kroah-Hartman
2018-04-17 15:59 ` [PATCH 4.14 22/49] scsi: qla2xxx: Fix small memory leak in qla2x00_probe_one on probe failure Greg Kroah-Hartman
` (31 subsequent siblings)
52 siblings, 0 replies; 58+ messages in thread
From: Greg Kroah-Hartman @ 2018-04-17 15:59 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Yazen Ghannam, Borislav Petkov,
Thomas Gleixner
4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Yazen Ghannam <yazen.ghannam@amd.com>
commit 11cf887728a3d1de77cc12ce247b64ef32608891 upstream.
Scalable MCA systems have various types of banks. The bank's type
can determine how we handle errors from it. For example, if a bank
represents a UMC (Unified Memory Controller) then we will need to
convert its address from a normalized address to a system physical
address before handling the error.
[ bp: Verify m->bank is within range and use bank pointer. ]
Signed-off-by: Yazen Ghannam <yazen.ghannam@amd.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Link: http://lkml.kernel.org/r/20171207203955.118171-1-Yazen.Ghannam@amd.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/x86/kernel/cpu/mcheck/mce_amd.c | 14 ++++++++++++++
1 file changed, 14 insertions(+)
--- a/arch/x86/kernel/cpu/mcheck/mce_amd.c
+++ b/arch/x86/kernel/cpu/mcheck/mce_amd.c
@@ -110,6 +110,20 @@ const char *smca_get_long_name(enum smca
}
EXPORT_SYMBOL_GPL(smca_get_long_name);
+static enum smca_bank_types smca_get_bank_type(struct mce *m)
+{
+ struct smca_bank *b;
+
+ if (m->bank >= N_SMCA_BANK_TYPES)
+ return N_SMCA_BANK_TYPES;
+
+ b = &smca_banks[m->bank];
+ if (!b->hwid)
+ return N_SMCA_BANK_TYPES;
+
+ return b->hwid->bank_type;
+}
+
static struct smca_hwid smca_hwid_mcatypes[] = {
/* { bank_type, hwid_mcatype, xec_bitmap } */
^ permalink raw reply [flat|nested] 58+ messages in thread* [PATCH 4.14 22/49] scsi: qla2xxx: Fix small memory leak in qla2x00_probe_one on probe failure
2018-04-17 15:58 [PATCH 4.14 00/49] 4.14.35-stable review Greg Kroah-Hartman
` (20 preceding siblings ...)
2018-04-17 15:59 ` [PATCH 4.14 21/49] x86/MCE/AMD: Define a function to get SMCA bank type Greg Kroah-Hartman
@ 2018-04-17 15:59 ` Greg Kroah-Hartman
2018-04-17 15:59 ` [PATCH 4.14 23/49] apparmor: fix logging of the existence test for signals Greg Kroah-Hartman
` (30 subsequent siblings)
52 siblings, 0 replies; 58+ messages in thread
From: Greg Kroah-Hartman @ 2018-04-17 15:59 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Bill Kuzeja, Himanshu Madhani,
Martin K. Petersen
4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Bill Kuzeja <William.Kuzeja@stratus.com>
commit 6d6340672ba3a99c4cf7af79c2edf7aa25595c84 upstream.
The code that fixes the crashes in the following commit introduced a small
memory leak:
commit 6a2cf8d3663e ("scsi: qla2xxx: Fix crashes in qla2x00_probe_one on probe failure")
Fixing this requires a bit of reworking, which I've explained. Also provide
some code cleanup.
There is a small window in qla2x00_probe_one where if qla2x00_alloc_queues
fails, we end up never freeing req and rsp and leak 0xc0 and 0xc8 bytes
respectively (the sizes of req and rsp).
I originally put in checks to test for this condition which were based on
the incorrect assumption that if ha->rsp_q_map and ha->req_q_map were
allocated, then rsp and req were allocated as well. This is incorrect.
There is a window between these allocations:
ret = qla2x00_mem_alloc(ha, req_length, rsp_length, &req, &rsp);
goto probe_hw_failed;
[if successful, both rsp and req allocated]
base_vha = qla2x00_create_host(sht, ha);
goto probe_hw_failed;
ret = qla2x00_request_irqs(ha, rsp);
goto probe_failed;
if (qla2x00_alloc_queues(ha, req, rsp)) {
goto probe_failed;
[if successful, now ha->rsp_q_map and ha->req_q_map allocated]
To simplify this, we should just set req and rsp to NULL after we free
them. Sounds simple enough? The problem is that req and rsp are pointers
defined in the qla2x00_probe_one and they are not always passed by reference
to the routines that free them.
Here are paths which can free req and rsp:
PATH 1:
qla2x00_probe_one
ret = qla2x00_mem_alloc(ha, req_length, rsp_length, &req, &rsp);
[req and rsp are passed by reference, but if this fails, we currently
do not NULL out req and rsp. Easily fixed]
PATH 2:
qla2x00_probe_one
failing in qla2x00_request_irqs or qla2x00_alloc_queues
probe_failed:
qla2x00_free_device(base_vha);
qla2x00_free_req_que(ha, req)
qla2x00_free_rsp_que(ha, rsp)
PATH 3:
qla2x00_probe_one:
failing in qla2x00_mem_alloc or qla2x00_create_host
probe_hw_failed:
qla2x00_free_req_que(ha, req)
qla2x00_free_rsp_que(ha, rsp)
PATH 1: This should currently work, but it doesn't because rsp and rsp are
not set to NULL in qla2x00_mem_alloc. Easily remedied.
PATH 2: req and rsp aren't passed in at all to qla2x00_free_device but are
derived from ha->req_q_map[0] and ha->rsp_q_map[0]. These are only set up if
qla2x00_alloc_queues succeeds.
In qla2x00_free_queues, we are protected from crashing if these don't exist
because req_qid_map and rsp_qid_map are only set on their allocation. We are
guarded in this way:
for (cnt = 0; cnt < ha->max_req_queues; cnt++) {
if (!test_bit(cnt, ha->req_qid_map))
continue;
PATH 3: This works. We haven't freed req or rsp yet (or they were never
allocated if qla2x00_mem_alloc failed), so we'll attempt to free them here.
To summarize, there are a few small changes to make this work correctly and
(and for some cleanup):
1) (For PATH 1) Set *rsp and *req to NULL in case of failure in
qla2x00_mem_alloc so these are correctly set to NULL back in
qla2x00_probe_one
2) After jumping to probe_failed: and calling qla2x00_free_device,
explicitly set rsp and req to NULL so further calls with these pointers do
not crash, i.e. the free queue calls in the probe_hw_failed section we fall
through to.
3) Fix return code check in the call to qla2x00_alloc_queues. We currently
drop the return code on the floor. The probe fails but the caller of the
probe doesn't have an error code, so it attaches to pci. This can result in
a crash on module shutdown.
4) Remove unnecessary NULL checks in qla2x00_free_req_que,
qla2x00_free_rsp_que, and the egregious NULL checks before kfrees and vfrees
in qla2x00_mem_free.
I tested this out running a scenario where the card breaks at various times
during initialization. I made sure I forced every error exit path in
qla2x00_probe_one.
Cc: <stable@vger.kernel.org> # v4.16
Fixes: 6a2cf8d3663e ("scsi: qla2xxx: Fix crashes in qla2x00_probe_one on probe failure")
Signed-off-by: Bill Kuzeja <william.kuzeja@stratus.com>
Acked-by: Himanshu Madhani <himanshu.madhani@cavium.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/scsi/qla2xxx/qla_os.c | 44 ++++++++++++++++++++----------------------
1 file changed, 21 insertions(+), 23 deletions(-)
--- a/drivers/scsi/qla2xxx/qla_os.c
+++ b/drivers/scsi/qla2xxx/qla_os.c
@@ -459,9 +459,6 @@ fail_req_map:
static void qla2x00_free_req_que(struct qla_hw_data *ha, struct req_que *req)
{
- if (!ha->req_q_map)
- return;
-
if (IS_QLAFX00(ha)) {
if (req && req->ring_fx00)
dma_free_coherent(&ha->pdev->dev,
@@ -472,17 +469,14 @@ static void qla2x00_free_req_que(struct
(req->length + 1) * sizeof(request_t),
req->ring, req->dma);
- if (req) {
+ if (req)
kfree(req->outstanding_cmds);
- kfree(req);
- }
+
+ kfree(req);
}
static void qla2x00_free_rsp_que(struct qla_hw_data *ha, struct rsp_que *rsp)
{
- if (!ha->rsp_q_map)
- return;
-
if (IS_QLAFX00(ha)) {
if (rsp && rsp->ring)
dma_free_coherent(&ha->pdev->dev,
@@ -493,8 +487,7 @@ static void qla2x00_free_rsp_que(struct
(rsp->length + 1) * sizeof(response_t),
rsp->ring, rsp->dma);
}
- if (rsp)
- kfree(rsp);
+ kfree(rsp);
}
static void qla2x00_free_queues(struct qla_hw_data *ha)
@@ -3075,7 +3068,8 @@ qla2x00_probe_one(struct pci_dev *pdev,
goto probe_failed;
/* Alloc arrays of request and response ring ptrs */
- if (qla2x00_alloc_queues(ha, req, rsp)) {
+ ret = qla2x00_alloc_queues(ha, req, rsp);
+ if (ret) {
ql_log(ql_log_fatal, base_vha, 0x003d,
"Failed to allocate memory for queue pointers..."
"aborting.\n");
@@ -3368,8 +3362,15 @@ probe_failed:
}
qla2x00_free_device(base_vha);
-
scsi_host_put(base_vha->host);
+ /*
+ * Need to NULL out local req/rsp after
+ * qla2x00_free_device => qla2x00_free_queues frees
+ * what these are pointing to. Or else we'll
+ * fall over below in qla2x00_free_req/rsp_que.
+ */
+ req = NULL;
+ rsp = NULL;
probe_hw_failed:
qla2x00_mem_free(ha);
@@ -4062,6 +4063,7 @@ fail_npiv_info:
(*rsp)->dma = 0;
fail_rsp_ring:
kfree(*rsp);
+ *rsp = NULL;
fail_rsp:
dma_free_coherent(&ha->pdev->dev, ((*req)->length + 1) *
sizeof(request_t), (*req)->ring, (*req)->dma);
@@ -4069,6 +4071,7 @@ fail_rsp:
(*req)->dma = 0;
fail_req_ring:
kfree(*req);
+ *req = NULL;
fail_req:
dma_free_coherent(&ha->pdev->dev, sizeof(struct ct_sns_pkt),
ha->ct_sns, ha->ct_sns_dma);
@@ -4436,16 +4439,11 @@ qla2x00_mem_free(struct qla_hw_data *ha)
dma_free_coherent(&ha->pdev->dev, ha->init_cb_size,
ha->init_cb, ha->init_cb_dma);
- if (ha->optrom_buffer)
- vfree(ha->optrom_buffer);
- if (ha->nvram)
- kfree(ha->nvram);
- if (ha->npiv_info)
- kfree(ha->npiv_info);
- if (ha->swl)
- kfree(ha->swl);
- if (ha->loop_id_map)
- kfree(ha->loop_id_map);
+ vfree(ha->optrom_buffer);
+ kfree(ha->nvram);
+ kfree(ha->npiv_info);
+ kfree(ha->swl);
+ kfree(ha->loop_id_map);
ha->srb_mempool = NULL;
ha->ctx_mempool = NULL;
^ permalink raw reply [flat|nested] 58+ messages in thread* [PATCH 4.14 23/49] apparmor: fix logging of the existence test for signals
2018-04-17 15:58 [PATCH 4.14 00/49] 4.14.35-stable review Greg Kroah-Hartman
` (21 preceding siblings ...)
2018-04-17 15:59 ` [PATCH 4.14 22/49] scsi: qla2xxx: Fix small memory leak in qla2x00_probe_one on probe failure Greg Kroah-Hartman
@ 2018-04-17 15:59 ` Greg Kroah-Hartman
2018-04-17 15:59 ` [PATCH 4.14 24/49] apparmor: fix display of .ns_name for containers Greg Kroah-Hartman
` (29 subsequent siblings)
52 siblings, 0 replies; 58+ messages in thread
From: Greg Kroah-Hartman @ 2018-04-17 15:59 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, John Johansen
4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: John Johansen <john.johansen@canonical.com>
commit 98cf5bbff413eadf1b9cb195a7b80cc61c72a50e upstream.
The existence test is not being properly logged as the signal mapping
maps it to the last entry in the named signal table. This is done
to help catch bugs by making the 0 mapped signal value invalid so
that we can catch the signal value not being filled in.
When fixing the off-by-one comparision logic the reporting of the
existence test was broken, because the logic behind the mapped named
table was hidden. Fix this by adding a define for the name lookup
and using it.
Cc: Stable <stable@vger.kernel.org>
Fixes: f7dc4c9a855a1 ("apparmor: fix off-by-one comparison on MAXMAPPED_SIG")
Signed-off-by: John Johansen <john.johansen@canonical.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
security/apparmor/include/sig_names.h | 4 +++-
security/apparmor/ipc.c | 2 +-
2 files changed, 4 insertions(+), 2 deletions(-)
--- a/security/apparmor/include/sig_names.h
+++ b/security/apparmor/include/sig_names.h
@@ -2,6 +2,8 @@
#define SIGUNKNOWN 0
#define MAXMAPPED_SIG 35
+#define MAXMAPPED_SIGNAME (MAXMAPPED_SIG + 1)
+
/* provide a mapping of arch signal to internal signal # for mediation
* those that are always an alias SIGCLD for SIGCLHD and SIGPOLL for SIGIO
* map to the same entry those that may/or may not get a separate entry
@@ -56,7 +58,7 @@ static const int sig_map[MAXMAPPED_SIG]
};
/* this table is ordered post sig_map[sig] mapping */
-static const char *const sig_names[MAXMAPPED_SIG + 1] = {
+static const char *const sig_names[MAXMAPPED_SIGNAME] = {
"unknown",
"hup",
"int",
--- a/security/apparmor/ipc.c
+++ b/security/apparmor/ipc.c
@@ -174,7 +174,7 @@ static void audit_signal_cb(struct audit
audit_signal_mask(ab, aad(sa)->denied);
}
}
- if (aad(sa)->signal < MAXMAPPED_SIG)
+ if (aad(sa)->signal < MAXMAPPED_SIGNAME)
audit_log_format(ab, " signal=%s", sig_names[aad(sa)->signal]);
else
audit_log_format(ab, " signal=rtmin+%d",
^ permalink raw reply [flat|nested] 58+ messages in thread* [PATCH 4.14 24/49] apparmor: fix display of .ns_name for containers
2018-04-17 15:58 [PATCH 4.14 00/49] 4.14.35-stable review Greg Kroah-Hartman
` (22 preceding siblings ...)
2018-04-17 15:59 ` [PATCH 4.14 23/49] apparmor: fix logging of the existence test for signals Greg Kroah-Hartman
@ 2018-04-17 15:59 ` Greg Kroah-Hartman
2018-04-17 15:59 ` [PATCH 4.14 25/49] apparmor: fix resource audit messages when auditing peer Greg Kroah-Hartman
` (28 subsequent siblings)
52 siblings, 0 replies; 58+ messages in thread
From: Greg Kroah-Hartman @ 2018-04-17 15:59 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Serge Hallyn, John Johansen
4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: John Johansen <john.johansen@canonical.com>
commit 040d9e2bce0a5b321c402b79ee43a8e8d2fd3b06 upstream.
The .ns_name should not be virtualized by the current ns view. It
needs to report the ns base name as that is being used during startup
as part of determining apparmor policy namespace support.
BugLink: http://bugs.launchpad.net/bugs/1746463
Fixes: d9f02d9c237aa ("apparmor: fix display of ns name")
Cc: Stable <stable@vger.kernel.org>
Reported-by: Serge Hallyn <serge@hallyn.com>
Tested-by: Serge Hallyn <serge@hallyn.com>
Signed-off-by: John Johansen <john.johansen@canonical.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
security/apparmor/apparmorfs.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
--- a/security/apparmor/apparmorfs.c
+++ b/security/apparmor/apparmorfs.c
@@ -1189,9 +1189,7 @@ static int seq_ns_level_show(struct seq_
static int seq_ns_name_show(struct seq_file *seq, void *v)
{
struct aa_label *label = begin_current_label_crit_section();
-
- seq_printf(seq, "%s\n", aa_ns_name(labels_ns(label),
- labels_ns(label), true));
+ seq_printf(seq, "%s\n", labels_ns(label)->base.name);
end_current_label_crit_section(label);
return 0;
^ permalink raw reply [flat|nested] 58+ messages in thread* [PATCH 4.14 25/49] apparmor: fix resource audit messages when auditing peer
2018-04-17 15:58 [PATCH 4.14 00/49] 4.14.35-stable review Greg Kroah-Hartman
` (23 preceding siblings ...)
2018-04-17 15:59 ` [PATCH 4.14 24/49] apparmor: fix display of .ns_name for containers Greg Kroah-Hartman
@ 2018-04-17 15:59 ` Greg Kroah-Hartman
2018-04-17 15:59 ` [PATCH 4.14 26/49] block/loop: fix deadlock after loop_set_status Greg Kroah-Hartman
` (27 subsequent siblings)
52 siblings, 0 replies; 58+ messages in thread
From: Greg Kroah-Hartman @ 2018-04-17 15:59 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, John Johansen
4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: John Johansen <john.johansen@canonical.com>
commit b5beb07ad32ab533027aa988d96a44965ec116f7 upstream.
Resource auditing is using the peer field which is not available
when the rlim data struct is used, because it is a different element
of the same union. Accessing peer during resource auditing could
cause garbage log entries or even oops the kernel.
Move the rlim data block into the same struct as the peer field
so they can be used together.
CC: <stable@vger.kernel.org>
Fixes: 86b92cb782b3 ("apparmor: move resource checks to using labels")
Signed-off-by: John Johansen <john.johansen@canonical.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
security/apparmor/include/audit.h | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
--- a/security/apparmor/include/audit.h
+++ b/security/apparmor/include/audit.h
@@ -126,6 +126,10 @@ struct apparmor_audit_data {
const char *target;
kuid_t ouid;
} fs;
+ struct {
+ int rlim;
+ unsigned long max;
+ } rlim;
int signal;
};
};
@@ -135,10 +139,6 @@ struct apparmor_audit_data {
long pos;
} iface;
struct {
- int rlim;
- unsigned long max;
- } rlim;
- struct {
const char *src_name;
const char *type;
const char *trans;
^ permalink raw reply [flat|nested] 58+ messages in thread* [PATCH 4.14 26/49] block/loop: fix deadlock after loop_set_status
2018-04-17 15:58 [PATCH 4.14 00/49] 4.14.35-stable review Greg Kroah-Hartman
` (24 preceding siblings ...)
2018-04-17 15:59 ` [PATCH 4.14 25/49] apparmor: fix resource audit messages when auditing peer Greg Kroah-Hartman
@ 2018-04-17 15:59 ` Greg Kroah-Hartman
2018-04-17 15:59 ` [PATCH 4.14 27/49] nfit: fix region registration vs block-data-window ranges Greg Kroah-Hartman
` (26 subsequent siblings)
52 siblings, 0 replies; 58+ messages in thread
From: Greg Kroah-Hartman @ 2018-04-17 15:59 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Tetsuo Handa, syzbot, Ming Lei,
Dmitry Vyukov, Jens Axboe, Jens Axboe
4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
commit 1e047eaab3bb5564f25b41e9cd3a053009f4e789 upstream.
syzbot is reporting deadlocks at __blkdev_get() [1].
----------------------------------------
[ 92.493919] systemd-udevd D12696 525 1 0x00000000
[ 92.495891] Call Trace:
[ 92.501560] schedule+0x23/0x80
[ 92.502923] schedule_preempt_disabled+0x5/0x10
[ 92.504645] __mutex_lock+0x416/0x9e0
[ 92.510760] __blkdev_get+0x73/0x4f0
[ 92.512220] blkdev_get+0x12e/0x390
[ 92.518151] do_dentry_open+0x1c3/0x2f0
[ 92.519815] path_openat+0x5d9/0xdc0
[ 92.521437] do_filp_open+0x7d/0xf0
[ 92.527365] do_sys_open+0x1b8/0x250
[ 92.528831] do_syscall_64+0x6e/0x270
[ 92.530341] entry_SYSCALL_64_after_hwframe+0x42/0xb7
[ 92.931922] 1 lock held by systemd-udevd/525:
[ 92.933642] #0: 00000000a2849e25 (&bdev->bd_mutex){+.+.}, at: __blkdev_get+0x73/0x4f0
----------------------------------------
The reason of deadlock turned out that wait_event_interruptible() in
blk_queue_enter() got stuck with bdev->bd_mutex held at __blkdev_put()
due to q->mq_freeze_depth == 1.
----------------------------------------
[ 92.787172] a.out S12584 634 633 0x80000002
[ 92.789120] Call Trace:
[ 92.796693] schedule+0x23/0x80
[ 92.797994] blk_queue_enter+0x3cb/0x540
[ 92.803272] generic_make_request+0xf0/0x3d0
[ 92.807970] submit_bio+0x67/0x130
[ 92.810928] submit_bh_wbc+0x15e/0x190
[ 92.812461] __block_write_full_page+0x218/0x460
[ 92.815792] __writepage+0x11/0x50
[ 92.817209] write_cache_pages+0x1ae/0x3d0
[ 92.825585] generic_writepages+0x5a/0x90
[ 92.831865] do_writepages+0x43/0xd0
[ 92.836972] __filemap_fdatawrite_range+0xc1/0x100
[ 92.838788] filemap_write_and_wait+0x24/0x70
[ 92.840491] __blkdev_put+0x69/0x1e0
[ 92.841949] blkdev_close+0x16/0x20
[ 92.843418] __fput+0xda/0x1f0
[ 92.844740] task_work_run+0x87/0xb0
[ 92.846215] do_exit+0x2f5/0xba0
[ 92.850528] do_group_exit+0x34/0xb0
[ 92.852018] SyS_exit_group+0xb/0x10
[ 92.853449] do_syscall_64+0x6e/0x270
[ 92.854944] entry_SYSCALL_64_after_hwframe+0x42/0xb7
[ 92.943530] 1 lock held by a.out/634:
[ 92.945105] #0: 00000000a2849e25 (&bdev->bd_mutex){+.+.}, at: __blkdev_put+0x3c/0x1e0
----------------------------------------
The reason of q->mq_freeze_depth == 1 turned out that loop_set_status()
forgot to call blk_mq_unfreeze_queue() at error paths for
info->lo_encrypt_type != NULL case.
----------------------------------------
[ 37.509497] CPU: 2 PID: 634 Comm: a.out Tainted: G W 4.16.0+ #457
[ 37.513608] Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 05/19/2017
[ 37.518832] RIP: 0010:blk_freeze_queue_start+0x17/0x40
[ 37.521778] RSP: 0018:ffffb0c2013e7c60 EFLAGS: 00010246
[ 37.524078] RAX: 0000000000000000 RBX: ffff8b07b1519798 RCX: 0000000000000000
[ 37.527015] RDX: 0000000000000002 RSI: ffffb0c2013e7cc0 RDI: ffff8b07b1519798
[ 37.529934] RBP: ffffb0c2013e7cc0 R08: 0000000000000008 R09: 47a189966239b898
[ 37.532684] R10: dad78b99b278552f R11: 9332dca72259d5ef R12: ffff8b07acd73678
[ 37.535452] R13: 0000000000004c04 R14: 0000000000000000 R15: ffff8b07b841e940
[ 37.538186] FS: 00007fede33b9740(0000) GS:ffff8b07b8e80000(0000) knlGS:0000000000000000
[ 37.541168] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 37.543590] CR2: 00000000206fdf18 CR3: 0000000130b30006 CR4: 00000000000606e0
[ 37.546410] Call Trace:
[ 37.547902] blk_freeze_queue+0x9/0x30
[ 37.549968] loop_set_status+0x67/0x3c0 [loop]
[ 37.549975] loop_set_status64+0x3b/0x70 [loop]
[ 37.549986] lo_ioctl+0x223/0x810 [loop]
[ 37.549995] blkdev_ioctl+0x572/0x980
[ 37.550003] block_ioctl+0x34/0x40
[ 37.550006] do_vfs_ioctl+0xa7/0x6d0
[ 37.550017] ksys_ioctl+0x6b/0x80
[ 37.573076] SyS_ioctl+0x5/0x10
[ 37.574831] do_syscall_64+0x6e/0x270
[ 37.576769] entry_SYSCALL_64_after_hwframe+0x42/0xb7
----------------------------------------
[1] https://syzkaller.appspot.com/bug?id=cd662bc3f6022c0979d01a262c318fab2ee9b56f
Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Reported-by: syzbot <bot+48594378e9851eab70bcd6f99327c7db58c5a28a@syzkaller.appspotmail.com>
Fixes: ecdd09597a572513 ("block/loop: fix race between I/O and set_status")
Cc: Ming Lei <tom.leiming@gmail.com>
Cc: Dmitry Vyukov <dvyukov@google.com>
Cc: stable <stable@vger.kernel.org>
Cc: Jens Axboe <axboe@fb.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/block/loop.c | 12 ++++++++----
1 file changed, 8 insertions(+), 4 deletions(-)
--- a/drivers/block/loop.c
+++ b/drivers/block/loop.c
@@ -1098,11 +1098,15 @@ loop_set_status(struct loop_device *lo,
if (info->lo_encrypt_type) {
unsigned int type = info->lo_encrypt_type;
- if (type >= MAX_LO_CRYPT)
- return -EINVAL;
+ if (type >= MAX_LO_CRYPT) {
+ err = -EINVAL;
+ goto exit;
+ }
xfer = xfer_funcs[type];
- if (xfer == NULL)
- return -EINVAL;
+ if (xfer == NULL) {
+ err = -EINVAL;
+ goto exit;
+ }
} else
xfer = NULL;
^ permalink raw reply [flat|nested] 58+ messages in thread* [PATCH 4.14 27/49] nfit: fix region registration vs block-data-window ranges
2018-04-17 15:58 [PATCH 4.14 00/49] 4.14.35-stable review Greg Kroah-Hartman
` (25 preceding siblings ...)
2018-04-17 15:59 ` [PATCH 4.14 26/49] block/loop: fix deadlock after loop_set_status Greg Kroah-Hartman
@ 2018-04-17 15:59 ` Greg Kroah-Hartman
2018-04-17 15:59 ` [PATCH 4.14 28/49] s390/qdio: dont retry EQBS after CCQ 96 Greg Kroah-Hartman
` (25 subsequent siblings)
52 siblings, 0 replies; 58+ messages in thread
From: Greg Kroah-Hartman @ 2018-04-17 15:59 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Dave Jiang, Dan Williams
4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Dan Williams <dan.j.williams@intel.com>
commit 8d0d8ed3356aa9ed43b819aaedd39b08ca453007 upstream.
Commit 1cf03c00e7c1 "nfit: scrub and register regions in a workqueue"
mistakenly attempts to register a region per BLK aperture. There is
nothing to register for individual apertures as they belong as a set to
a BLK aperture group that are registered with a corresponding
DIMM-control-region. Filter them for registration to prevent some
needless devm_kzalloc() allocations.
Cc: <stable@vger.kernel.org>
Fixes: 1cf03c00e7c1 ("nfit: scrub and register regions in a workqueue")
Reviewed-by: Dave Jiang <dave.jiang@intel.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/acpi/nfit/core.c | 22 ++++++++++++++--------
1 file changed, 14 insertions(+), 8 deletions(-)
--- a/drivers/acpi/nfit/core.c
+++ b/drivers/acpi/nfit/core.c
@@ -2748,15 +2748,21 @@ static void acpi_nfit_scrub(struct work_
static int acpi_nfit_register_regions(struct acpi_nfit_desc *acpi_desc)
{
struct nfit_spa *nfit_spa;
- int rc;
- list_for_each_entry(nfit_spa, &acpi_desc->spas, list)
- if (nfit_spa_type(nfit_spa->spa) == NFIT_SPA_DCR) {
- /* BLK regions don't need to wait for ars results */
- rc = acpi_nfit_register_region(acpi_desc, nfit_spa);
- if (rc)
- return rc;
- }
+ list_for_each_entry(nfit_spa, &acpi_desc->spas, list) {
+ int rc, type = nfit_spa_type(nfit_spa->spa);
+
+ /* PMEM and VMEM will be registered by the ARS workqueue */
+ if (type == NFIT_SPA_PM || type == NFIT_SPA_VOLATILE)
+ continue;
+ /* BLK apertures belong to BLK region registration below */
+ if (type == NFIT_SPA_BDW)
+ continue;
+ /* BLK regions don't need to wait for ARS results */
+ rc = acpi_nfit_register_region(acpi_desc, nfit_spa);
+ if (rc)
+ return rc;
+ }
acpi_desc->ars_start_flags = 0;
if (!acpi_desc->cancel)
^ permalink raw reply [flat|nested] 58+ messages in thread* [PATCH 4.14 28/49] s390/qdio: dont retry EQBS after CCQ 96
2018-04-17 15:58 [PATCH 4.14 00/49] 4.14.35-stable review Greg Kroah-Hartman
` (26 preceding siblings ...)
2018-04-17 15:59 ` [PATCH 4.14 27/49] nfit: fix region registration vs block-data-window ranges Greg Kroah-Hartman
@ 2018-04-17 15:59 ` Greg Kroah-Hartman
2018-04-17 15:59 ` [PATCH 4.14 29/49] s390/qdio: dont merge ERROR output buffers Greg Kroah-Hartman
` (24 subsequent siblings)
52 siblings, 0 replies; 58+ messages in thread
From: Greg Kroah-Hartman @ 2018-04-17 15:59 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Julian Wiedmann, Benjamin Block,
Martin Schwidefsky
4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Julian Wiedmann <jwi@linux.vnet.ibm.com>
commit dae55b6fef58530c13df074bcc182c096609339e upstream.
Immediate retry of EQBS after CCQ 96 means that we potentially misreport
the state of buffers inspected during the first EQBS call.
This occurs when
1. the first EQBS finds all inspected buffers still in the initial state
set by the driver (ie INPUT EMPTY or OUTPUT PRIMED),
2. the EQBS terminates early with CCQ 96, and
3. by the time that the second EQBS comes around, the state of those
previously inspected buffers has changed.
If the state reported by the second EQBS is 'driver-owned', all we know
is that the previous buffers are driver-owned now as well. But we can't
tell if they all have the same state. So for instance
- the second EQBS reports OUTPUT EMPTY, but any number of the previous
buffers could be OUTPUT ERROR by now,
- the second EQBS reports OUTPUT ERROR, but any number of the previous
buffers could be OUTPUT EMPTY by now.
Effectively, this can result in both over- and underreporting of errors.
If the state reported by the second EQBS is 'HW-owned', that doesn't
guarantee that the previous buffers have not been switched to
driver-owned in the mean time. So for instance
- the second EQBS reports INPUT EMPTY, but any number of the previous
buffers could be INPUT PRIMED (or INPUT ERROR) by now.
This would result in failure to process pending work on the queue. If
it's the final check before yielding initiative, this can cause
a (temporary) queue stall due to IRQ avoidance.
Fixes: 25f269f17316 ("[S390] qdio: EQBS retry after CCQ 96")
Cc: <stable@vger.kernel.org> #v3.2+
Signed-off-by: Julian Wiedmann <jwi@linux.vnet.ibm.com>
Reviewed-by: Benjamin Block <bblock@linux.vnet.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/s390/cio/qdio_main.c | 11 ++---------
1 file changed, 2 insertions(+), 9 deletions(-)
--- a/drivers/s390/cio/qdio_main.c
+++ b/drivers/s390/cio/qdio_main.c
@@ -126,7 +126,7 @@ static inline int qdio_check_ccq(struct
static int qdio_do_eqbs(struct qdio_q *q, unsigned char *state,
int start, int count, int auto_ack)
{
- int rc, tmp_count = count, tmp_start = start, nr = q->nr, retried = 0;
+ int rc, tmp_count = count, tmp_start = start, nr = q->nr;
unsigned int ccq = 0;
qperf_inc(q, eqbs);
@@ -149,14 +149,7 @@ again:
qperf_inc(q, eqbs_partial);
DBF_DEV_EVENT(DBF_WARN, q->irq_ptr, "EQBS part:%02x",
tmp_count);
- /*
- * Retry once, if that fails bail out and process the
- * extracted buffers before trying again.
- */
- if (!retried++)
- goto again;
- else
- return count - tmp_count;
+ return count - tmp_count;
}
DBF_ERROR("%4x EQBS ERROR", SCH_NO(q));
^ permalink raw reply [flat|nested] 58+ messages in thread* [PATCH 4.14 29/49] s390/qdio: dont merge ERROR output buffers
2018-04-17 15:58 [PATCH 4.14 00/49] 4.14.35-stable review Greg Kroah-Hartman
` (27 preceding siblings ...)
2018-04-17 15:59 ` [PATCH 4.14 28/49] s390/qdio: dont retry EQBS after CCQ 96 Greg Kroah-Hartman
@ 2018-04-17 15:59 ` Greg Kroah-Hartman
2018-04-17 15:59 ` [PATCH 4.14 30/49] s390/ipl: ensure loadparm valid flag is set Greg Kroah-Hartman
` (23 subsequent siblings)
52 siblings, 0 replies; 58+ messages in thread
From: Greg Kroah-Hartman @ 2018-04-17 15:59 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Julian Wiedmann, Ursula Braun,
Benjamin Block, Martin Schwidefsky
4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Julian Wiedmann <jwi@linux.vnet.ibm.com>
commit 0cf1e05157b9e5530dcc3ca9fec9bf617fc93375 upstream.
On an Output queue, both EMPTY and PENDING buffer states imply that the
buffer is ready for completion-processing by the upper-layer drivers.
So for a non-QEBSM Output queue, get_buf_states() merges mixed
batches of PENDING and EMPTY buffers into one large batch of EMPTY
buffers. The upper-layer driver (ie. qeth) later distuingishes PENDING
from EMPTY by inspecting the slsb_state for
QDIO_OUTBUF_STATE_FLAG_PENDING.
But the merge logic in get_buf_states() contains a bug that causes us to
erronously also merge ERROR buffers into such a batch of EMPTY buffers
(ERROR is 0xaf, EMPTY is 0xa1; so ERROR & EMPTY == EMPTY).
Effectively, most outbound ERROR buffers are currently discarded
silently and processed as if they had succeeded.
Note that this affects _all_ non-QEBSM device types, not just IQD with CQ.
Fix it by explicitly spelling out the exact conditions for merging.
For extracting the "get initial state" part out of the loop, this relies
on the fact that get_buf_states() is never called with a count of 0. The
QEBSM path already strictly requires this, and the two callers with
variable 'count' make sure of it.
Fixes: 104ea556ee7f ("qdio: support asynchronous delivery of storage blocks")
Cc: <stable@vger.kernel.org> #v3.2+
Signed-off-by: Julian Wiedmann <jwi@linux.vnet.ibm.com>
Reviewed-by: Ursula Braun <ubraun@linux.vnet.ibm.com>
Reviewed-by: Benjamin Block <bblock@linux.vnet.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/s390/cio/qdio_main.c | 31 ++++++++++++++++++++-----------
1 file changed, 20 insertions(+), 11 deletions(-)
--- a/drivers/s390/cio/qdio_main.c
+++ b/drivers/s390/cio/qdio_main.c
@@ -205,7 +205,10 @@ again:
return 0;
}
-/* returns number of examined buffers and their common state in *state */
+/*
+ * Returns number of examined buffers and their common state in *state.
+ * Requested number of buffers-to-examine must be > 0.
+ */
static inline int get_buf_states(struct qdio_q *q, unsigned int bufnr,
unsigned char *state, unsigned int count,
int auto_ack, int merge_pending)
@@ -216,17 +219,23 @@ static inline int get_buf_states(struct
if (is_qebsm(q))
return qdio_do_eqbs(q, state, bufnr, count, auto_ack);
- for (i = 0; i < count; i++) {
- if (!__state) {
- __state = q->slsb.val[bufnr];
- if (merge_pending && __state == SLSB_P_OUTPUT_PENDING)
- __state = SLSB_P_OUTPUT_EMPTY;
- } else if (merge_pending) {
- if ((q->slsb.val[bufnr] & __state) != __state)
- break;
- } else if (q->slsb.val[bufnr] != __state)
- break;
+ /* get initial state: */
+ __state = q->slsb.val[bufnr];
+ if (merge_pending && __state == SLSB_P_OUTPUT_PENDING)
+ __state = SLSB_P_OUTPUT_EMPTY;
+
+ for (i = 1; i < count; i++) {
bufnr = next_buf(bufnr);
+
+ /* merge PENDING into EMPTY: */
+ if (merge_pending &&
+ q->slsb.val[bufnr] == SLSB_P_OUTPUT_PENDING &&
+ __state == SLSB_P_OUTPUT_EMPTY)
+ continue;
+
+ /* stop if next state differs from initial state: */
+ if (q->slsb.val[bufnr] != __state)
+ break;
}
*state = __state;
return i;
^ permalink raw reply [flat|nested] 58+ messages in thread* [PATCH 4.14 30/49] s390/ipl: ensure loadparm valid flag is set
2018-04-17 15:58 [PATCH 4.14 00/49] 4.14.35-stable review Greg Kroah-Hartman
` (28 preceding siblings ...)
2018-04-17 15:59 ` [PATCH 4.14 29/49] s390/qdio: dont merge ERROR output buffers Greg Kroah-Hartman
@ 2018-04-17 15:59 ` Greg Kroah-Hartman
2018-04-17 15:59 ` [PATCH 4.14 31/49] get_user_pages_fast(): return -EFAULT on access_ok failure Greg Kroah-Hartman
` (22 subsequent siblings)
52 siblings, 0 replies; 58+ messages in thread
From: Greg Kroah-Hartman @ 2018-04-17 15:59 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Heiko Carstens, Vasily Gorbik,
Martin Schwidefsky
4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Vasily Gorbik <gor@linux.ibm.com>
commit 15deb080a6087b73089139569558965750e69d67 upstream.
When loadparm is set in reipl parm block, the kernel should also set
DIAG308_FLAGS_LP_VALID flag.
This fixes loadparm ignoring during z/VM fcp -> ccw reipl and kvm direct
boot -> ccw reipl.
Cc: <stable@vger.kernel.org>
Reviewed-by: Heiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/s390/kernel/ipl.c | 1 +
1 file changed, 1 insertion(+)
--- a/arch/s390/kernel/ipl.c
+++ b/arch/s390/kernel/ipl.c
@@ -799,6 +799,7 @@ static ssize_t reipl_generic_loadparm_st
/* copy and convert to ebcdic */
memcpy(ipb->hdr.loadparm, buf, lp_len);
ASCEBC(ipb->hdr.loadparm, LOADPARM_LEN);
+ ipb->hdr.flags |= DIAG308_FLAGS_LP_VALID;
return len;
}
^ permalink raw reply [flat|nested] 58+ messages in thread* [PATCH 4.14 31/49] get_user_pages_fast(): return -EFAULT on access_ok failure
2018-04-17 15:58 [PATCH 4.14 00/49] 4.14.35-stable review Greg Kroah-Hartman
` (29 preceding siblings ...)
2018-04-17 15:59 ` [PATCH 4.14 30/49] s390/ipl: ensure loadparm valid flag is set Greg Kroah-Hartman
@ 2018-04-17 15:59 ` Greg Kroah-Hartman
2018-04-17 15:59 ` [PATCH 4.14 32/49] getname_kernel() needs to make sure that ->name != ->iname in long case Greg Kroah-Hartman
` (21 subsequent siblings)
52 siblings, 0 replies; 58+ messages in thread
From: Greg Kroah-Hartman @ 2018-04-17 15:59 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Michael S. Tsirkin,
syzbot+6304bf97ef436580fede, Andrew Morton, Kirill A. Shutemov,
Huang Ying, Jonathan Corbet, Peter Zijlstra, Thomas Gleixner,
Thorsten Leemhuis, Linus Torvalds
4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Michael S. Tsirkin <mst@redhat.com>
commit c61611f70958d86f659bca25c02ae69413747a8d upstream.
get_user_pages_fast is supposed to be a faster drop-in equivalent of
get_user_pages. As such, callers expect it to return a negative return
code when passed an invalid address, and never expect it to return 0
when passed a positive number of pages, since its documentation says:
* Returns number of pages pinned. This may be fewer than the number
* requested. If nr_pages is 0 or negative, returns 0. If no pages
* were pinned, returns -errno.
When get_user_pages_fast fall back on get_user_pages this is exactly
what happens. Unfortunately the implementation is inconsistent: it
returns 0 if passed a kernel address, confusing callers: for example,
the following is pretty common but does not appear to do the right thing
with a kernel address:
ret = get_user_pages_fast(addr, 1, writeable, &page);
if (ret < 0)
return ret;
Change get_user_pages_fast to return -EFAULT when supplied a kernel
address to make it match expectations.
All callers have been audited for consistency with the documented
semantics.
Link: http://lkml.kernel.org/r/1522962072-182137-4-git-send-email-mst@redhat.com
Fixes: 5b65c4677a57 ("mm, x86/mm: Fix performance regression in get_user_pages_fast()")
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Reported-by: syzbot+6304bf97ef436580fede@syzkaller.appspotmail.com
Reviewed-by: Andrew Morton <akpm@linux-foundation.org>
Cc: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Cc: Huang Ying <ying.huang@intel.com>
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Thorsten Leemhuis <regressions@leemhuis.info>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
mm/gup.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
--- a/mm/gup.c
+++ b/mm/gup.c
@@ -1816,9 +1816,12 @@ int get_user_pages_fast(unsigned long st
len = (unsigned long) nr_pages << PAGE_SHIFT;
end = start + len;
+ if (nr_pages <= 0)
+ return 0;
+
if (unlikely(!access_ok(write ? VERIFY_WRITE : VERIFY_READ,
(void __user *)start, len)))
- return 0;
+ return -EFAULT;
if (gup_fast_permitted(start, nr_pages, write)) {
local_irq_disable();
^ permalink raw reply [flat|nested] 58+ messages in thread* [PATCH 4.14 32/49] getname_kernel() needs to make sure that ->name != ->iname in long case
2018-04-17 15:58 [PATCH 4.14 00/49] 4.14.35-stable review Greg Kroah-Hartman
` (30 preceding siblings ...)
2018-04-17 15:59 ` [PATCH 4.14 31/49] get_user_pages_fast(): return -EFAULT on access_ok failure Greg Kroah-Hartman
@ 2018-04-17 15:59 ` Greg Kroah-Hartman
2018-04-17 15:59 ` [PATCH 4.14 33/49] Bluetooth: Fix connection if directed advertising and privacy is used Greg Kroah-Hartman
` (20 subsequent siblings)
52 siblings, 0 replies; 58+ messages in thread
From: Greg Kroah-Hartman @ 2018-04-17 15:59 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Al Viro
4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Al Viro <viro@zeniv.linux.org.uk>
commit 30ce4d1903e1d8a7ccd110860a5eef3c638ed8be upstream.
missed it in "kill struct filename.separate" several years ago.
Cc: stable@vger.kernel.org
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
fs/namei.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/fs/namei.c
+++ b/fs/namei.c
@@ -222,9 +222,10 @@ getname_kernel(const char * filename)
if (len <= EMBEDDED_NAME_MAX) {
result->name = (char *)result->iname;
} else if (len <= PATH_MAX) {
+ const size_t size = offsetof(struct filename, iname[1]);
struct filename *tmp;
- tmp = kmalloc(sizeof(*tmp), GFP_KERNEL);
+ tmp = kmalloc(size, GFP_KERNEL);
if (unlikely(!tmp)) {
__putname(result);
return ERR_PTR(-ENOMEM);
^ permalink raw reply [flat|nested] 58+ messages in thread* [PATCH 4.14 33/49] Bluetooth: Fix connection if directed advertising and privacy is used
2018-04-17 15:58 [PATCH 4.14 00/49] 4.14.35-stable review Greg Kroah-Hartman
` (31 preceding siblings ...)
2018-04-17 15:59 ` [PATCH 4.14 32/49] getname_kernel() needs to make sure that ->name != ->iname in long case Greg Kroah-Hartman
@ 2018-04-17 15:59 ` Greg Kroah-Hartman
2018-04-17 15:59 ` [PATCH 4.14 34/49] Bluetooth: hci_bcm: Treat Interrupt ACPI resources as always being active-low Greg Kroah-Hartman
` (19 subsequent siblings)
52 siblings, 0 replies; 58+ messages in thread
From: Greg Kroah-Hartman @ 2018-04-17 15:59 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Szymon Janc, Marcel Holtmann
4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Szymon Janc <szymon.janc@codecoup.pl>
commit 082f2300cfa1a3d9d5221c38c5eba85d4ab98bd8 upstream.
Local random address needs to be updated before creating connection if
RPA from LE Direct Advertising Report was resolved in host. Otherwise
remote device might ignore connection request due to address mismatch.
This was affecting following qualification test cases:
GAP/CONN/SCEP/BV-03-C, GAP/CONN/GCEP/BV-05-C, GAP/CONN/DCEP/BV-05-C
Before patch:
< HCI Command: LE Set Random Address (0x08|0x0005) plen 6 #11350 [hci0] 84680.231216
Address: 56:BC:E8:24:11:68 (Resolvable)
Identity type: Random (0x01)
Identity: F2:F1:06:3D:9C:42 (Static)
> HCI Event: Command Complete (0x0e) plen 4 #11351 [hci0] 84680.246022
LE Set Random Address (0x08|0x0005) ncmd 1
Status: Success (0x00)
< HCI Command: LE Set Scan Parameters (0x08|0x000b) plen 7 #11352 [hci0] 84680.246417
Type: Passive (0x00)
Interval: 60.000 msec (0x0060)
Window: 30.000 msec (0x0030)
Own address type: Random (0x01)
Filter policy: Accept all advertisement, inc. directed unresolved RPA (0x02)
> HCI Event: Command Complete (0x0e) plen 4 #11353 [hci0] 84680.248854
LE Set Scan Parameters (0x08|0x000b) ncmd 1
Status: Success (0x00)
< HCI Command: LE Set Scan Enable (0x08|0x000c) plen 2 #11354 [hci0] 84680.249466
Scanning: Enabled (0x01)
Filter duplicates: Enabled (0x01)
> HCI Event: Command Complete (0x0e) plen 4 #11355 [hci0] 84680.253222
LE Set Scan Enable (0x08|0x000c) ncmd 1
Status: Success (0x00)
> HCI Event: LE Meta Event (0x3e) plen 18 #11356 [hci0] 84680.458387
LE Direct Advertising Report (0x0b)
Num reports: 1
Event type: Connectable directed - ADV_DIRECT_IND (0x01)
Address type: Random (0x01)
Address: 53:38:DA:46:8C:45 (Resolvable)
Identity type: Public (0x00)
Identity: 11:22:33:44:55:66 (OUI 11-22-33)
Direct address type: Random (0x01)
Direct address: 7C:D6:76:8C:DF:82 (Resolvable)
Identity type: Random (0x01)
Identity: F2:F1:06:3D:9C:42 (Static)
RSSI: -74 dBm (0xb6)
< HCI Command: LE Set Scan Enable (0x08|0x000c) plen 2 #11357 [hci0] 84680.458737
Scanning: Disabled (0x00)
Filter duplicates: Disabled (0x00)
> HCI Event: Command Complete (0x0e) plen 4 #11358 [hci0] 84680.469982
LE Set Scan Enable (0x08|0x000c) ncmd 1
Status: Success (0x00)
< HCI Command: LE Create Connection (0x08|0x000d) plen 25 #11359 [hci0] 84680.470444
Scan interval: 60.000 msec (0x0060)
Scan window: 60.000 msec (0x0060)
Filter policy: White list is not used (0x00)
Peer address type: Random (0x01)
Peer address: 53:38:DA:46:8C:45 (Resolvable)
Identity type: Public (0x00)
Identity: 11:22:33:44:55:66 (OUI 11-22-33)
Own address type: Random (0x01)
Min connection interval: 30.00 msec (0x0018)
Max connection interval: 50.00 msec (0x0028)
Connection latency: 0 (0x0000)
Supervision timeout: 420 msec (0x002a)
Min connection length: 0.000 msec (0x0000)
Max connection length: 0.000 msec (0x0000)
> HCI Event: Command Status (0x0f) plen 4 #11360 [hci0] 84680.474971
LE Create Connection (0x08|0x000d) ncmd 1
Status: Success (0x00)
< HCI Command: LE Create Connection Cancel (0x08|0x000e) plen 0 #11361 [hci0] 84682.545385
> HCI Event: Command Complete (0x0e) plen 4 #11362 [hci0] 84682.551014
LE Create Connection Cancel (0x08|0x000e) ncmd 1
Status: Success (0x00)
> HCI Event: LE Meta Event (0x3e) plen 19 #11363 [hci0] 84682.551074
LE Connection Complete (0x01)
Status: Unknown Connection Identifier (0x02)
Handle: 0
Role: Master (0x00)
Peer address type: Public (0x00)
Peer address: 00:00:00:00:00:00 (OUI 00-00-00)
Connection interval: 0.00 msec (0x0000)
Connection latency: 0 (0x0000)
Supervision timeout: 0 msec (0x0000)
Master clock accuracy: 0x00
After patch:
< HCI Command: LE Set Scan Parameters (0x08|0x000b) plen 7 #210 [hci0] 667.152459
Type: Passive (0x00)
Interval: 60.000 msec (0x0060)
Window: 30.000 msec (0x0030)
Own address type: Random (0x01)
Filter policy: Accept all advertisement, inc. directed unresolved RPA (0x02)
> HCI Event: Command Complete (0x0e) plen 4 #211 [hci0] 667.153613
LE Set Scan Parameters (0x08|0x000b) ncmd 1
Status: Success (0x00)
< HCI Command: LE Set Scan Enable (0x08|0x000c) plen 2 #212 [hci0] 667.153704
Scanning: Enabled (0x01)
Filter duplicates: Enabled (0x01)
> HCI Event: Command Complete (0x0e) plen 4 #213 [hci0] 667.154584
LE Set Scan Enable (0x08|0x000c) ncmd 1
Status: Success (0x00)
> HCI Event: LE Meta Event (0x3e) plen 18 #214 [hci0] 667.182619
LE Direct Advertising Report (0x0b)
Num reports: 1
Event type: Connectable directed - ADV_DIRECT_IND (0x01)
Address type: Random (0x01)
Address: 50:52:D9:A6:48:A0 (Resolvable)
Identity type: Public (0x00)
Identity: 11:22:33:44:55:66 (OUI 11-22-33)
Direct address type: Random (0x01)
Direct address: 7C:C1:57:A5:B7:A8 (Resolvable)
Identity type: Random (0x01)
Identity: F4:28:73:5D:38:B0 (Static)
RSSI: -70 dBm (0xba)
< HCI Command: LE Set Scan Enable (0x08|0x000c) plen 2 #215 [hci0] 667.182704
Scanning: Disabled (0x00)
Filter duplicates: Disabled (0x00)
> HCI Event: Command Complete (0x0e) plen 4 #216 [hci0] 667.183599
LE Set Scan Enable (0x08|0x000c) ncmd 1
Status: Success (0x00)
< HCI Command: LE Set Random Address (0x08|0x0005) plen 6 #217 [hci0] 667.183645
Address: 7C:C1:57:A5:B7:A8 (Resolvable)
Identity type: Random (0x01)
Identity: F4:28:73:5D:38:B0 (Static)
> HCI Event: Command Complete (0x0e) plen 4 #218 [hci0] 667.184590
LE Set Random Address (0x08|0x0005) ncmd 1
Status: Success (0x00)
< HCI Command: LE Create Connection (0x08|0x000d) plen 25 #219 [hci0] 667.184613
Scan interval: 60.000 msec (0x0060)
Scan window: 60.000 msec (0x0060)
Filter policy: White list is not used (0x00)
Peer address type: Random (0x01)
Peer address: 50:52:D9:A6:48:A0 (Resolvable)
Identity type: Public (0x00)
Identity: 11:22:33:44:55:66 (OUI 11-22-33)
Own address type: Random (0x01)
Min connection interval: 30.00 msec (0x0018)
Max connection interval: 50.00 msec (0x0028)
Connection latency: 0 (0x0000)
Supervision timeout: 420 msec (0x002a)
Min connection length: 0.000 msec (0x0000)
Max connection length: 0.000 msec (0x0000)
> HCI Event: Command Status (0x0f) plen 4 #220 [hci0] 667.186558
LE Create Connection (0x08|0x000d) ncmd 1
Status: Success (0x00)
> HCI Event: LE Meta Event (0x3e) plen 19 #221 [hci0] 667.485824
LE Connection Complete (0x01)
Status: Success (0x00)
Handle: 0
Role: Master (0x00)
Peer address type: Random (0x01)
Peer address: 50:52:D9:A6:48:A0 (Resolvable)
Identity type: Public (0x00)
Identity: 11:22:33:44:55:66 (OUI 11-22-33)
Connection interval: 50.00 msec (0x0028)
Connection latency: 0 (0x0000)
Supervision timeout: 420 msec (0x002a)
Master clock accuracy: 0x07
@ MGMT Event: Device Connected (0x000b) plen 13 {0x0002} [hci0] 667.485996
LE Address: 11:22:33:44:55:66 (OUI 11-22-33)
Flags: 0x00000000
Data length: 0
Signed-off-by: Szymon Janc <szymon.janc@codecoup.pl>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
include/net/bluetooth/hci_core.h | 2 +-
net/bluetooth/hci_conn.c | 29 +++++++++++++++++++++--------
net/bluetooth/hci_event.c | 15 +++++++++++----
net/bluetooth/l2cap_core.c | 2 +-
4 files changed, 34 insertions(+), 14 deletions(-)
--- a/include/net/bluetooth/hci_core.h
+++ b/include/net/bluetooth/hci_core.h
@@ -895,7 +895,7 @@ struct hci_conn *hci_connect_le_scan(str
u16 conn_timeout);
struct hci_conn *hci_connect_le(struct hci_dev *hdev, bdaddr_t *dst,
u8 dst_type, u8 sec_level, u16 conn_timeout,
- u8 role);
+ u8 role, bdaddr_t *direct_rpa);
struct hci_conn *hci_connect_acl(struct hci_dev *hdev, bdaddr_t *dst,
u8 sec_level, u8 auth_type);
struct hci_conn *hci_connect_sco(struct hci_dev *hdev, int type, bdaddr_t *dst,
--- a/net/bluetooth/hci_conn.c
+++ b/net/bluetooth/hci_conn.c
@@ -749,18 +749,31 @@ static bool conn_use_rpa(struct hci_conn
}
static void hci_req_add_le_create_conn(struct hci_request *req,
- struct hci_conn *conn)
+ struct hci_conn *conn,
+ bdaddr_t *direct_rpa)
{
struct hci_cp_le_create_conn cp;
struct hci_dev *hdev = conn->hdev;
u8 own_addr_type;
- /* Update random address, but set require_privacy to false so
- * that we never connect with an non-resolvable address.
+ /* If direct address was provided we use it instead of current
+ * address.
*/
- if (hci_update_random_address(req, false, conn_use_rpa(conn),
- &own_addr_type))
- return;
+ if (direct_rpa) {
+ if (bacmp(&req->hdev->random_addr, direct_rpa))
+ hci_req_add(req, HCI_OP_LE_SET_RANDOM_ADDR, 6,
+ direct_rpa);
+
+ /* direct address is always RPA */
+ own_addr_type = ADDR_LE_DEV_RANDOM;
+ } else {
+ /* Update random address, but set require_privacy to false so
+ * that we never connect with an non-resolvable address.
+ */
+ if (hci_update_random_address(req, false, conn_use_rpa(conn),
+ &own_addr_type))
+ return;
+ }
memset(&cp, 0, sizeof(cp));
@@ -825,7 +838,7 @@ static void hci_req_directed_advertising
struct hci_conn *hci_connect_le(struct hci_dev *hdev, bdaddr_t *dst,
u8 dst_type, u8 sec_level, u16 conn_timeout,
- u8 role)
+ u8 role, bdaddr_t *direct_rpa)
{
struct hci_conn_params *params;
struct hci_conn *conn;
@@ -940,7 +953,7 @@ struct hci_conn *hci_connect_le(struct h
hci_dev_set_flag(hdev, HCI_LE_SCAN_INTERRUPTED);
}
- hci_req_add_le_create_conn(&req, conn);
+ hci_req_add_le_create_conn(&req, conn, direct_rpa);
create_conn:
err = hci_req_run(&req, create_le_conn_complete);
--- a/net/bluetooth/hci_event.c
+++ b/net/bluetooth/hci_event.c
@@ -4646,7 +4646,8 @@ static void hci_le_conn_update_complete_
/* This function requires the caller holds hdev->lock */
static struct hci_conn *check_pending_le_conn(struct hci_dev *hdev,
bdaddr_t *addr,
- u8 addr_type, u8 adv_type)
+ u8 addr_type, u8 adv_type,
+ bdaddr_t *direct_rpa)
{
struct hci_conn *conn;
struct hci_conn_params *params;
@@ -4697,7 +4698,8 @@ static struct hci_conn *check_pending_le
}
conn = hci_connect_le(hdev, addr, addr_type, BT_SECURITY_LOW,
- HCI_LE_AUTOCONN_TIMEOUT, HCI_ROLE_MASTER);
+ HCI_LE_AUTOCONN_TIMEOUT, HCI_ROLE_MASTER,
+ direct_rpa);
if (!IS_ERR(conn)) {
/* If HCI_AUTO_CONN_EXPLICIT is set, conn is already owned
* by higher layer that tried to connect, if no then
@@ -4807,8 +4809,13 @@ static void process_adv_report(struct hc
bdaddr_type = irk->addr_type;
}
- /* Check if we have been requested to connect to this device */
- conn = check_pending_le_conn(hdev, bdaddr, bdaddr_type, type);
+ /* Check if we have been requested to connect to this device.
+ *
+ * direct_addr is set only for directed advertising reports (it is NULL
+ * for advertising reports) and is already verified to be RPA above.
+ */
+ conn = check_pending_le_conn(hdev, bdaddr, bdaddr_type, type,
+ direct_addr);
if (conn && type == LE_ADV_IND) {
/* Store report for later inclusion by
* mgmt_device_connected
--- a/net/bluetooth/l2cap_core.c
+++ b/net/bluetooth/l2cap_core.c
@@ -7156,7 +7156,7 @@ int l2cap_chan_connect(struct l2cap_chan
hcon = hci_connect_le(hdev, dst, dst_type,
chan->sec_level,
HCI_LE_CONN_TIMEOUT,
- HCI_ROLE_SLAVE);
+ HCI_ROLE_SLAVE, NULL);
else
hcon = hci_connect_le_scan(hdev, dst, dst_type,
chan->sec_level,
^ permalink raw reply [flat|nested] 58+ messages in thread* [PATCH 4.14 34/49] Bluetooth: hci_bcm: Treat Interrupt ACPI resources as always being active-low
2018-04-17 15:58 [PATCH 4.14 00/49] 4.14.35-stable review Greg Kroah-Hartman
` (32 preceding siblings ...)
2018-04-17 15:59 ` [PATCH 4.14 33/49] Bluetooth: Fix connection if directed advertising and privacy is used Greg Kroah-Hartman
@ 2018-04-17 15:59 ` Greg Kroah-Hartman
2018-04-17 15:59 ` [PATCH 4.14 35/49] rtl8187: Fix NULL pointer dereference in priv->conf_mutex Greg Kroah-Hartman
` (18 subsequent siblings)
52 siblings, 0 replies; 58+ messages in thread
From: Greg Kroah-Hartman @ 2018-04-17 15:59 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Hans de Goede, Marcel Holtmann
4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Hans de Goede <hdegoede@redhat.com>
commit bb5208b314c5127b716b2ee4f55803a8bb73b750 upstream.
Older devices with a serdev attached bcm bt hci, use an Interrupt ACPI
resource to describe the IRQ (rather then a GpioInt resource).
These device seem to all claim the IRQ is active-high and seem to all need
a DMI quirk to treat it as active-low. Instead simply always assume that
Interrupt resource specified IRQs are always active-low.
This fixes the bt device not being able to wake the host from runtime-
suspend on the: Asus T100TAM, Asus T200TA, Lenovo Yoga2 and the Toshiba
Encore, without the need to add 4 new DMI quirks for these models.
This also allows us to remove 2 DMI quirks for the Asus T100TA and Asus
T100CHI series. Likely the 2 remaining quirks can also be removed but I
could not find a DSDT of these devices to verify this.
Cc: stable@vger.kernel.org
Buglink: https://bugzilla.kernel.org/show_bug.cgi?id=198953
Buglink: https://bugzilla.redhat.com/show_bug.cgi?id=1554835
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/bluetooth/hci_bcm.c | 20 +++-----------------
1 file changed, 3 insertions(+), 17 deletions(-)
--- a/drivers/bluetooth/hci_bcm.c
+++ b/drivers/bluetooth/hci_bcm.c
@@ -694,22 +694,6 @@ static const struct acpi_gpio_mapping ac
#ifdef CONFIG_ACPI
/* IRQ polarity of some chipsets are not defined correctly in ACPI table. */
static const struct dmi_system_id bcm_active_low_irq_dmi_table[] = {
- {
- .ident = "Asus T100TA",
- .matches = {
- DMI_EXACT_MATCH(DMI_SYS_VENDOR,
- "ASUSTeK COMPUTER INC."),
- DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "T100TA"),
- },
- },
- {
- .ident = "Asus T100CHI",
- .matches = {
- DMI_EXACT_MATCH(DMI_SYS_VENDOR,
- "ASUSTeK COMPUTER INC."),
- DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "T100CHI"),
- },
- },
{ /* Handle ThinkPad 8 tablets with BCM2E55 chipset ACPI ID */
.ident = "Lenovo ThinkPad 8",
.matches = {
@@ -730,7 +714,9 @@ static int bcm_resource(struct acpi_reso
switch (ares->type) {
case ACPI_RESOURCE_TYPE_EXTENDED_IRQ:
irq = &ares->data.extended_irq;
- dev->irq_active_low = irq->polarity == ACPI_ACTIVE_LOW;
+ if (irq->polarity != ACPI_ACTIVE_LOW)
+ dev_info(&dev->pdev->dev, "ACPI Interrupt resource is active-high, this is usually wrong, treating the IRQ as active-low\n");
+ dev->irq_active_low = true;
break;
case ACPI_RESOURCE_TYPE_GPIO:
^ permalink raw reply [flat|nested] 58+ messages in thread* [PATCH 4.14 35/49] rtl8187: Fix NULL pointer dereference in priv->conf_mutex
2018-04-17 15:58 [PATCH 4.14 00/49] 4.14.35-stable review Greg Kroah-Hartman
` (33 preceding siblings ...)
2018-04-17 15:59 ` [PATCH 4.14 34/49] Bluetooth: hci_bcm: Treat Interrupt ACPI resources as always being active-low Greg Kroah-Hartman
@ 2018-04-17 15:59 ` Greg Kroah-Hartman
2018-04-17 15:59 ` [PATCH 4.14 36/49] x86/MCE: Report only DRAM ECC as memory errors on AMD systems Greg Kroah-Hartman
` (17 subsequent siblings)
52 siblings, 0 replies; 58+ messages in thread
From: Greg Kroah-Hartman @ 2018-04-17 15:59 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Sudhir Sreedharan, Kalle Valo
4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Sudhir Sreedharan <ssreedharan@mvista.com>
commit 7972326a26b5bf8dc2adac575c4e03ee7e9d193a upstream.
This can be reproduced by bind/unbind the driver multiple times
in AM3517 board.
Analysis revealed that rtl8187_start() was invoked before probe
finishes(ie. before the mutex is initialized).
INFO: trying to register non-static key.
the code is fine but needs lockdep annotation.
turning off the locking correctness validator.
CPU: 0 PID: 821 Comm: wpa_supplicant Not tainted 4.9.80-dirty #250
Hardware name: Generic AM3517 (Flattened Device Tree)
[<c010e0d8>] (unwind_backtrace) from [<c010beac>] (show_stack+0x10/0x14)
[<c010beac>] (show_stack) from [<c017401c>] (register_lock_class+0x4f4/0x55c)
[<c017401c>] (register_lock_class) from [<c0176fe0>] (__lock_acquire+0x74/0x1938)
[<c0176fe0>] (__lock_acquire) from [<c0178cfc>] (lock_acquire+0xfc/0x23c)
[<c0178cfc>] (lock_acquire) from [<c08aa2f8>] (mutex_lock_nested+0x50/0x3b0)
[<c08aa2f8>] (mutex_lock_nested) from [<c05f5bf8>] (rtl8187_start+0x2c/0xd54)
[<c05f5bf8>] (rtl8187_start) from [<c082dea0>] (drv_start+0xa8/0x320)
[<c082dea0>] (drv_start) from [<c084d1d4>] (ieee80211_do_open+0x2bc/0x8e4)
[<c084d1d4>] (ieee80211_do_open) from [<c069be94>] (__dev_open+0xb8/0x120)
[<c069be94>] (__dev_open) from [<c069c11c>] (__dev_change_flags+0x88/0x14c)
[<c069c11c>] (__dev_change_flags) from [<c069c1f8>] (dev_change_flags+0x18/0x48)
[<c069c1f8>] (dev_change_flags) from [<c0710b08>] (devinet_ioctl+0x738/0x840)
[<c0710b08>] (devinet_ioctl) from [<c067925c>] (sock_ioctl+0x164/0x2f4)
[<c067925c>] (sock_ioctl) from [<c02883f8>] (do_vfs_ioctl+0x8c/0x9d0)
[<c02883f8>] (do_vfs_ioctl) from [<c0288da8>] (SyS_ioctl+0x6c/0x7c)
[<c0288da8>] (SyS_ioctl) from [<c0107760>] (ret_fast_syscall+0x0/0x1c)
Unable to handle kernel NULL pointer dereference at virtual address 00000000
pgd = cd1ec000
[00000000] *pgd=8d1de831, *pte=00000000, *ppte=00000000
Internal error: Oops: 817 [#1] PREEMPT ARM
Modules linked in:
CPU: 0 PID: 821 Comm: wpa_supplicant Not tainted 4.9.80-dirty #250
Hardware name: Generic AM3517 (Flattened Device Tree)
task: ce73eec0 task.stack: cd1ea000
PC is at mutex_lock_nested+0xe8/0x3b0
LR is at mutex_lock_nested+0xd0/0x3b0
Cc: stable@vger.kernel.org
Signed-off-by: Sudhir Sreedharan <ssreedharan@mvista.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/net/wireless/realtek/rtl818x/rtl8187/dev.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/net/wireless/realtek/rtl818x/rtl8187/dev.c
+++ b/drivers/net/wireless/realtek/rtl818x/rtl8187/dev.c
@@ -1450,6 +1450,7 @@ static int rtl8187_probe(struct usb_inte
goto err_free_dev;
}
mutex_init(&priv->io_mutex);
+ mutex_init(&priv->conf_mutex);
SET_IEEE80211_DEV(dev, &intf->dev);
usb_set_intfdata(intf, dev);
@@ -1625,7 +1626,6 @@ static int rtl8187_probe(struct usb_inte
printk(KERN_ERR "rtl8187: Cannot register device\n");
goto err_free_dmabuf;
}
- mutex_init(&priv->conf_mutex);
skb_queue_head_init(&priv->b_tx_status.queue);
wiphy_info(dev->wiphy, "hwaddr %pM, %s V%d + %s, rfkill mask %d\n",
^ permalink raw reply [flat|nested] 58+ messages in thread* [PATCH 4.14 36/49] x86/MCE: Report only DRAM ECC as memory errors on AMD systems
2018-04-17 15:58 [PATCH 4.14 00/49] 4.14.35-stable review Greg Kroah-Hartman
` (34 preceding siblings ...)
2018-04-17 15:59 ` [PATCH 4.14 35/49] rtl8187: Fix NULL pointer dereference in priv->conf_mutex Greg Kroah-Hartman
@ 2018-04-17 15:59 ` Greg Kroah-Hartman
2018-04-17 15:59 ` [4.14,37/49] " Greg Kroah-Hartman
` (16 subsequent siblings)
52 siblings, 0 replies; 58+ messages in thread
From: Greg Kroah-Hartman @ 2018-04-17 15:59 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Yazen Ghannam, Borislav Petkov,
Thomas Gleixner
4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Yazen Ghannam <yazen.ghannam@amd.com>
commit c6708d50f166bea2d763c96485d31fdbc50204f1 upstream.
The MCA_STATUS[ErrorCodeExt] field is very bank type specific.
We currently check if the ErrorCodeExt value is 0x0 or 0x8 in
mce_is_memory_error(), but we don't check the bank number. This means
that we could flag non-memory errors as memory errors.
We know that we want to flag DRAM ECC errors as memory errors, so let's do
those cases first. We can add more cases later when needed.
Define a wrapper function in mce_amd.c so we can use SMCA enums.
[ bp: Remove brackets around return statements. ]
Signed-off-by: Yazen Ghannam <yazen.ghannam@amd.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Link: http://lkml.kernel.org/r/20171207203955.118171-2-Yazen.Ghannam@amd.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/x86/include/asm/mce.h | 2 ++
arch/x86/kernel/cpu/mcheck/mce.c | 4 +---
arch/x86/kernel/cpu/mcheck/mce_amd.c | 11 +++++++++++
3 files changed, 14 insertions(+), 3 deletions(-)
--- a/arch/x86/include/asm/mce.h
+++ b/arch/x86/include/asm/mce.h
@@ -376,6 +376,7 @@ struct smca_bank {
extern struct smca_bank smca_banks[MAX_NR_BANKS];
extern const char *smca_get_long_name(enum smca_bank_types t);
+extern bool amd_mce_is_memory_error(struct mce *m);
extern int mce_threshold_create_device(unsigned int cpu);
extern int mce_threshold_remove_device(unsigned int cpu);
@@ -384,6 +385,7 @@ extern int mce_threshold_remove_device(u
static inline int mce_threshold_create_device(unsigned int cpu) { return 0; };
static inline int mce_threshold_remove_device(unsigned int cpu) { return 0; };
+static inline bool amd_mce_is_memory_error(struct mce *m) { return false; };
#endif
--- a/arch/x86/kernel/cpu/mcheck/mce.c
+++ b/arch/x86/kernel/cpu/mcheck/mce.c
@@ -512,10 +512,8 @@ static int mce_usable_address(struct mce
bool mce_is_memory_error(struct mce *m)
{
if (m->cpuvendor == X86_VENDOR_AMD) {
- /* ErrCodeExt[20:16] */
- u8 xec = (m->status >> 16) & 0x1f;
+ return amd_mce_is_memory_error(m);
- return (xec == 0x0 || xec == 0x8);
} else if (m->cpuvendor == X86_VENDOR_INTEL) {
/*
* Intel SDM Volume 3B - 15.9.2 Compound Error Codes
--- a/arch/x86/kernel/cpu/mcheck/mce_amd.c
+++ b/arch/x86/kernel/cpu/mcheck/mce_amd.c
@@ -752,6 +752,17 @@ out_err:
}
EXPORT_SYMBOL_GPL(umc_normaddr_to_sysaddr);
+bool amd_mce_is_memory_error(struct mce *m)
+{
+ /* ErrCodeExt[20:16] */
+ u8 xec = (m->status >> 16) & 0x1f;
+
+ if (mce_flags.smca)
+ return smca_get_bank_type(m) == SMCA_UMC && xec == 0x0;
+
+ return m->bank == 4 && xec == 0x8;
+}
+
static void __log_error(unsigned int bank, u64 status, u64 addr, u64 misc)
{
struct mce m;
^ permalink raw reply [flat|nested] 58+ messages in thread* [PATCH 4.14 37/49] x86/mce/AMD: Pass the bank number to smca_get_bank_type()
@ 2018-04-17 15:59 ` Greg Kroah-Hartman
0 siblings, 0 replies; 58+ messages in thread
From: Greg Kroah-Hartman @ 2018-04-17 15:59 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Yazen Ghannam, Borislav Petkov,
Borislav Petkov, Linus Torvalds, Peter Zijlstra, Thomas Gleixner,
Tony Luck, linux-edac, Ingo Molnar
4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Yazen Ghannam <yazen.ghannam@amd.com>
commit e5d6a126d4c473499f354254a15ca0c2d8c84ca3 upstream.
Pass the bank number to smca_get_bank_type() since that's all we need.
Also, we should compare the bank number to MAX_NR_BANKS (size of the
smca_banks array) not the number of bank types. Bank types are reused
for multiple banks, so the number of types can be different from the
number of banks in a system and thus we could return an invalid bank
type.
Signed-off-by: Yazen Ghannam <yazen.ghannam@amd.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
Cc: <stable@vger.kernel.org> # 4.14.x
Cc: <stable@vger.kernel.org> # 4.14.x: 11cf887728a3 x86/MCE/AMD: Define a function to get SMCA bank type
Cc: <stable@vger.kernel.org> # 4.14.x: c6708d50f166 x86/MCE: Report only DRAM ECC as memory errors on AMD systems
Cc: Borislav Petkov <bp@alien8.de>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Tony Luck <tony.luck@intel.com>
Cc: linux-edac <linux-edac@vger.kernel.org>
Link: http://lkml.kernel.org/r/20180221101900.10326-6-bp@alien8.de
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/x86/kernel/cpu/mcheck/mce_amd.c | 15 +++++++--------
1 file changed, 7 insertions(+), 8 deletions(-)
--- a/arch/x86/kernel/cpu/mcheck/mce_amd.c
+++ b/arch/x86/kernel/cpu/mcheck/mce_amd.c
@@ -110,14 +110,14 @@ const char *smca_get_long_name(enum smca
}
EXPORT_SYMBOL_GPL(smca_get_long_name);
-static enum smca_bank_types smca_get_bank_type(struct mce *m)
+static enum smca_bank_types smca_get_bank_type(unsigned int bank)
{
struct smca_bank *b;
- if (m->bank >= N_SMCA_BANK_TYPES)
+ if (bank >= MAX_NR_BANKS)
return N_SMCA_BANK_TYPES;
- b = &smca_banks[m->bank];
+ b = &smca_banks[bank];
if (!b->hwid)
return N_SMCA_BANK_TYPES;
@@ -758,7 +758,7 @@ bool amd_mce_is_memory_error(struct mce
u8 xec = (m->status >> 16) & 0x1f;
if (mce_flags.smca)
- return smca_get_bank_type(m) == SMCA_UMC && xec == 0x0;
+ return smca_get_bank_type(m->bank) == SMCA_UMC && xec == 0x0;
return m->bank == 4 && xec == 0x8;
}
@@ -1061,7 +1061,7 @@ static struct kobj_type threshold_ktype
static const char *get_name(unsigned int bank, struct threshold_block *b)
{
- unsigned int bank_type;
+ enum smca_bank_types bank_type;
if (!mce_flags.smca) {
if (b && bank == 4)
@@ -1070,11 +1070,10 @@ static const char *get_name(unsigned int
return th_names[bank];
}
- if (!smca_banks[bank].hwid)
+ bank_type = smca_get_bank_type(bank);
+ if (bank_type >= N_SMCA_BANK_TYPES)
return NULL;
- bank_type = smca_banks[bank].hwid->bank_type;
-
if (b && bank_type == SMCA_UMC) {
if (b->block < ARRAY_SIZE(smca_umc_block_names))
return smca_umc_block_names[b->block];
^ permalink raw reply [flat|nested] 58+ messages in thread* [4.14,37/49] x86/mce/AMD: Pass the bank number to smca_get_bank_type()
@ 2018-04-17 15:59 ` Greg Kroah-Hartman
0 siblings, 0 replies; 58+ messages in thread
From: Greg Kroah-Hartman @ 2018-04-17 15:59 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Yazen Ghannam, Borislav Petkov,
Borislav Petkov, Linus Torvalds, Peter Zijlstra, Thomas Gleixner,
Tony Luck, linux-edac, Ingo Molnar
4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Yazen Ghannam <yazen.ghannam@amd.com>
commit e5d6a126d4c473499f354254a15ca0c2d8c84ca3 upstream.
Pass the bank number to smca_get_bank_type() since that's all we need.
Also, we should compare the bank number to MAX_NR_BANKS (size of the
smca_banks array) not the number of bank types. Bank types are reused
for multiple banks, so the number of types can be different from the
number of banks in a system and thus we could return an invalid bank
type.
Signed-off-by: Yazen Ghannam <yazen.ghannam@amd.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
Cc: <stable@vger.kernel.org> # 4.14.x
Cc: <stable@vger.kernel.org> # 4.14.x: 11cf887728a3 x86/MCE/AMD: Define a function to get SMCA bank type
Cc: <stable@vger.kernel.org> # 4.14.x: c6708d50f166 x86/MCE: Report only DRAM ECC as memory errors on AMD systems
Cc: Borislav Petkov <bp@alien8.de>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Tony Luck <tony.luck@intel.com>
Cc: linux-edac <linux-edac@vger.kernel.org>
Link: http://lkml.kernel.org/r/20180221101900.10326-6-bp@alien8.de
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/x86/kernel/cpu/mcheck/mce_amd.c | 15 +++++++--------
1 file changed, 7 insertions(+), 8 deletions(-)
--
To unsubscribe from this list: send the line "unsubscribe linux-edac" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--- a/arch/x86/kernel/cpu/mcheck/mce_amd.c
+++ b/arch/x86/kernel/cpu/mcheck/mce_amd.c
@@ -110,14 +110,14 @@ const char *smca_get_long_name(enum smca
}
EXPORT_SYMBOL_GPL(smca_get_long_name);
-static enum smca_bank_types smca_get_bank_type(struct mce *m)
+static enum smca_bank_types smca_get_bank_type(unsigned int bank)
{
struct smca_bank *b;
- if (m->bank >= N_SMCA_BANK_TYPES)
+ if (bank >= MAX_NR_BANKS)
return N_SMCA_BANK_TYPES;
- b = &smca_banks[m->bank];
+ b = &smca_banks[bank];
if (!b->hwid)
return N_SMCA_BANK_TYPES;
@@ -758,7 +758,7 @@ bool amd_mce_is_memory_error(struct mce
u8 xec = (m->status >> 16) & 0x1f;
if (mce_flags.smca)
- return smca_get_bank_type(m) == SMCA_UMC && xec == 0x0;
+ return smca_get_bank_type(m->bank) == SMCA_UMC && xec == 0x0;
return m->bank == 4 && xec == 0x8;
}
@@ -1061,7 +1061,7 @@ static struct kobj_type threshold_ktype
static const char *get_name(unsigned int bank, struct threshold_block *b)
{
- unsigned int bank_type;
+ enum smca_bank_types bank_type;
if (!mce_flags.smca) {
if (b && bank == 4)
@@ -1070,11 +1070,10 @@ static const char *get_name(unsigned int
return th_names[bank];
}
- if (!smca_banks[bank].hwid)
+ bank_type = smca_get_bank_type(bank);
+ if (bank_type >= N_SMCA_BANK_TYPES)
return NULL;
- bank_type = smca_banks[bank].hwid->bank_type;
-
if (b && bank_type == SMCA_UMC) {
if (b->block < ARRAY_SIZE(smca_umc_block_names))
return smca_umc_block_names[b->block];
^ permalink raw reply [flat|nested] 58+ messages in thread
* [PATCH 4.14 38/49] x86/mce/AMD, EDAC/mce_amd: Enumerate Reserved SMCA bank type
@ 2018-04-17 15:59 ` Greg Kroah-Hartman
0 siblings, 0 replies; 58+ messages in thread
From: Greg Kroah-Hartman @ 2018-04-17 15:59 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Yazen Ghannam, Borislav Petkov,
Borislav Petkov, Linus Torvalds, Peter Zijlstra, Thomas Gleixner,
Tony Luck, linux-edac, Ingo Molnar
4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Yazen Ghannam <yazen.ghannam@amd.com>
commit 68627a697c195937672ce07683094c72b1174786 upstream.
Currently, bank 4 is reserved on Fam17h, so we chose not to initialize
bank 4 in the smca_banks array. This means that when we check if a bank
is initialized, like during boot or resume, we will see that bank 4 is
not initialized and try to initialize it.
This will cause a call trace, when resuming from suspend, due to
rdmsr_*on_cpu() calls in the init path. The rdmsr_*on_cpu() calls issue
an IPI but we're running with interrupts disabled. This triggers:
WARNING: CPU: 0 PID: 11523 at kernel/smp.c:291 smp_call_function_single+0xdc/0xe0
...
Reserved banks will be read-as-zero, so their MCA_IPID register will be
zero. So, like the smca_banks array, the threshold_banks array will not
have an entry for a reserved bank since all its MCA_MISC* registers will
be zero.
Enumerate a "Reserved" bank type that matches on a HWID_MCATYPE of 0,0.
Use the "Reserved" type when checking if a bank is reserved. It's
possible that other bank numbers may be reserved on future systems.
Don't try to find the block address on reserved banks.
Signed-off-by: Yazen Ghannam <yazen.ghannam@amd.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
Cc: <stable@vger.kernel.org> # 4.14.x
Cc: Borislav Petkov <bp@alien8.de>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Tony Luck <tony.luck@intel.com>
Cc: linux-edac <linux-edac@vger.kernel.org>
Link: http://lkml.kernel.org/r/20180221101900.10326-7-bp@alien8.de
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/x86/include/asm/mce.h | 1 +
arch/x86/kernel/cpu/mcheck/mce_amd.c | 7 +++++++
drivers/edac/mce_amd.c | 11 +++++++----
3 files changed, 15 insertions(+), 4 deletions(-)
--- a/arch/x86/include/asm/mce.h
+++ b/arch/x86/include/asm/mce.h
@@ -346,6 +346,7 @@ enum smca_bank_types {
SMCA_IF, /* Instruction Fetch */
SMCA_L2_CACHE, /* L2 Cache */
SMCA_DE, /* Decoder Unit */
+ SMCA_RESERVED, /* Reserved */
SMCA_EX, /* Execution Unit */
SMCA_FP, /* Floating Point */
SMCA_L3_CACHE, /* L3 Cache */
--- a/arch/x86/kernel/cpu/mcheck/mce_amd.c
+++ b/arch/x86/kernel/cpu/mcheck/mce_amd.c
@@ -82,6 +82,7 @@ static struct smca_bank_name smca_names[
[SMCA_IF] = { "insn_fetch", "Instruction Fetch Unit" },
[SMCA_L2_CACHE] = { "l2_cache", "L2 Cache" },
[SMCA_DE] = { "decode_unit", "Decode Unit" },
+ [SMCA_RESERVED] = { "reserved", "Reserved" },
[SMCA_EX] = { "execution_unit", "Execution Unit" },
[SMCA_FP] = { "floating_point", "Floating Point Unit" },
[SMCA_L3_CACHE] = { "l3_cache", "L3 Cache" },
@@ -127,6 +128,9 @@ static enum smca_bank_types smca_get_ban
static struct smca_hwid smca_hwid_mcatypes[] = {
/* { bank_type, hwid_mcatype, xec_bitmap } */
+ /* Reserved type */
+ { SMCA_RESERVED, HWID_MCATYPE(0x00, 0x0), 0x0 },
+
/* ZN Core (HWID=0xB0) MCA types */
{ SMCA_LS, HWID_MCATYPE(0xB0, 0x0), 0x1FFFEF },
{ SMCA_IF, HWID_MCATYPE(0xB0, 0x1), 0x3FFF },
@@ -431,6 +435,9 @@ static u32 get_block_address(unsigned in
u32 addr = 0, offset = 0;
if (mce_flags.smca) {
+ if (smca_get_bank_type(bank) == SMCA_RESERVED)
+ return addr;
+
if (!block) {
addr = MSR_AMD64_SMCA_MCx_MISC(bank);
} else {
--- a/drivers/edac/mce_amd.c
+++ b/drivers/edac/mce_amd.c
@@ -854,21 +854,24 @@ static void decode_mc6_mce(struct mce *m
static void decode_smca_error(struct mce *m)
{
struct smca_hwid *hwid;
- unsigned int bank_type;
+ enum smca_bank_types bank_type;
const char *ip_name;
u8 xec = XEC(m->status, xec_mask);
if (m->bank >= ARRAY_SIZE(smca_banks))
return;
- if (x86_family(m->cpuid) >= 0x17 && m->bank == 4)
- pr_emerg(HW_ERR "Bank 4 is reserved on Fam17h.\n");
-
hwid = smca_banks[m->bank].hwid;
if (!hwid)
return;
bank_type = hwid->bank_type;
+
+ if (bank_type == SMCA_RESERVED) {
+ pr_emerg(HW_ERR "Bank %d is reserved.\n", m->bank);
+ return;
+ }
+
ip_name = smca_get_long_name(bank_type);
pr_emerg(HW_ERR "%s Extended Error Code: %d\n", ip_name, xec);
^ permalink raw reply [flat|nested] 58+ messages in thread* [4.14,38/49] x86/mce/AMD, EDAC/mce_amd: Enumerate Reserved SMCA bank type
@ 2018-04-17 15:59 ` Greg Kroah-Hartman
0 siblings, 0 replies; 58+ messages in thread
From: Greg Kroah-Hartman @ 2018-04-17 15:59 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Yazen Ghannam, Borislav Petkov,
Borislav Petkov, Linus Torvalds, Peter Zijlstra, Thomas Gleixner,
Tony Luck, linux-edac, Ingo Molnar
4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Yazen Ghannam <yazen.ghannam@amd.com>
commit 68627a697c195937672ce07683094c72b1174786 upstream.
Currently, bank 4 is reserved on Fam17h, so we chose not to initialize
bank 4 in the smca_banks array. This means that when we check if a bank
is initialized, like during boot or resume, we will see that bank 4 is
not initialized and try to initialize it.
This will cause a call trace, when resuming from suspend, due to
rdmsr_*on_cpu() calls in the init path. The rdmsr_*on_cpu() calls issue
an IPI but we're running with interrupts disabled. This triggers:
WARNING: CPU: 0 PID: 11523 at kernel/smp.c:291 smp_call_function_single+0xdc/0xe0
...
Reserved banks will be read-as-zero, so their MCA_IPID register will be
zero. So, like the smca_banks array, the threshold_banks array will not
have an entry for a reserved bank since all its MCA_MISC* registers will
be zero.
Enumerate a "Reserved" bank type that matches on a HWID_MCATYPE of 0,0.
Use the "Reserved" type when checking if a bank is reserved. It's
possible that other bank numbers may be reserved on future systems.
Don't try to find the block address on reserved banks.
Signed-off-by: Yazen Ghannam <yazen.ghannam@amd.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
Cc: <stable@vger.kernel.org> # 4.14.x
Cc: Borislav Petkov <bp@alien8.de>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Tony Luck <tony.luck@intel.com>
Cc: linux-edac <linux-edac@vger.kernel.org>
Link: http://lkml.kernel.org/r/20180221101900.10326-7-bp@alien8.de
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/x86/include/asm/mce.h | 1 +
arch/x86/kernel/cpu/mcheck/mce_amd.c | 7 +++++++
drivers/edac/mce_amd.c | 11 +++++++----
3 files changed, 15 insertions(+), 4 deletions(-)
--
To unsubscribe from this list: send the line "unsubscribe linux-edac" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--- a/arch/x86/include/asm/mce.h
+++ b/arch/x86/include/asm/mce.h
@@ -346,6 +346,7 @@ enum smca_bank_types {
SMCA_IF, /* Instruction Fetch */
SMCA_L2_CACHE, /* L2 Cache */
SMCA_DE, /* Decoder Unit */
+ SMCA_RESERVED, /* Reserved */
SMCA_EX, /* Execution Unit */
SMCA_FP, /* Floating Point */
SMCA_L3_CACHE, /* L3 Cache */
--- a/arch/x86/kernel/cpu/mcheck/mce_amd.c
+++ b/arch/x86/kernel/cpu/mcheck/mce_amd.c
@@ -82,6 +82,7 @@ static struct smca_bank_name smca_names[
[SMCA_IF] = { "insn_fetch", "Instruction Fetch Unit" },
[SMCA_L2_CACHE] = { "l2_cache", "L2 Cache" },
[SMCA_DE] = { "decode_unit", "Decode Unit" },
+ [SMCA_RESERVED] = { "reserved", "Reserved" },
[SMCA_EX] = { "execution_unit", "Execution Unit" },
[SMCA_FP] = { "floating_point", "Floating Point Unit" },
[SMCA_L3_CACHE] = { "l3_cache", "L3 Cache" },
@@ -127,6 +128,9 @@ static enum smca_bank_types smca_get_ban
static struct smca_hwid smca_hwid_mcatypes[] = {
/* { bank_type, hwid_mcatype, xec_bitmap } */
+ /* Reserved type */
+ { SMCA_RESERVED, HWID_MCATYPE(0x00, 0x0), 0x0 },
+
/* ZN Core (HWID=0xB0) MCA types */
{ SMCA_LS, HWID_MCATYPE(0xB0, 0x0), 0x1FFFEF },
{ SMCA_IF, HWID_MCATYPE(0xB0, 0x1), 0x3FFF },
@@ -431,6 +435,9 @@ static u32 get_block_address(unsigned in
u32 addr = 0, offset = 0;
if (mce_flags.smca) {
+ if (smca_get_bank_type(bank) == SMCA_RESERVED)
+ return addr;
+
if (!block) {
addr = MSR_AMD64_SMCA_MCx_MISC(bank);
} else {
--- a/drivers/edac/mce_amd.c
+++ b/drivers/edac/mce_amd.c
@@ -854,21 +854,24 @@ static void decode_mc6_mce(struct mce *m
static void decode_smca_error(struct mce *m)
{
struct smca_hwid *hwid;
- unsigned int bank_type;
+ enum smca_bank_types bank_type;
const char *ip_name;
u8 xec = XEC(m->status, xec_mask);
if (m->bank >= ARRAY_SIZE(smca_banks))
return;
- if (x86_family(m->cpuid) >= 0x17 && m->bank == 4)
- pr_emerg(HW_ERR "Bank 4 is reserved on Fam17h.\n");
-
hwid = smca_banks[m->bank].hwid;
if (!hwid)
return;
bank_type = hwid->bank_type;
+
+ if (bank_type == SMCA_RESERVED) {
+ pr_emerg(HW_ERR "Bank %d is reserved.\n", m->bank);
+ return;
+ }
+
ip_name = smca_get_long_name(bank_type);
pr_emerg(HW_ERR "%s Extended Error Code: %d\n", ip_name, xec);
^ permalink raw reply [flat|nested] 58+ messages in thread
* [PATCH 4.14 39/49] x86/mce/AMD: Get address from already initialized block
@ 2018-04-17 15:59 ` Greg Kroah-Hartman
0 siblings, 0 replies; 58+ messages in thread
From: Greg Kroah-Hartman @ 2018-04-17 15:59 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Yazen Ghannam, Borislav Petkov,
Borislav Petkov, Linus Torvalds, Peter Zijlstra, Thomas Gleixner,
Tony Luck, linux-edac, Ingo Molnar
4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Yazen Ghannam <yazen.ghannam@amd.com>
commit 27bd59502702fe51d9eb00450a75b727ec6bfcb4 upstream.
The block address is saved after the block is initialized when
threshold_init_device() is called.
Use the saved block address, if available, rather than trying to
rediscover it.
This will avoid a call trace, when resuming from suspend, due to the
rdmsr_safe_on_cpu() call in get_block_address(). The rdmsr_safe_on_cpu()
call issues an IPI but we're running with interrupts disabled. This
triggers:
WARNING: CPU: 0 PID: 11523 at kernel/smp.c:291 smp_call_function_single+0xdc/0xe0
Signed-off-by: Yazen Ghannam <yazen.ghannam@amd.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
Cc: <stable@vger.kernel.org> # 4.14.x
Cc: Borislav Petkov <bp@alien8.de>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Tony Luck <tony.luck@intel.com>
Cc: linux-edac <linux-edac@vger.kernel.org>
Link: http://lkml.kernel.org/r/20180221101900.10326-8-bp@alien8.de
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/x86/kernel/cpu/mcheck/mce_amd.c | 15 +++++++++++++++
1 file changed, 15 insertions(+)
--- a/arch/x86/kernel/cpu/mcheck/mce_amd.c
+++ b/arch/x86/kernel/cpu/mcheck/mce_amd.c
@@ -434,6 +434,21 @@ static u32 get_block_address(unsigned in
{
u32 addr = 0, offset = 0;
+ if ((bank >= mca_cfg.banks) || (block >= NR_BLOCKS))
+ return addr;
+
+ /* Get address from already initialized block. */
+ if (per_cpu(threshold_banks, cpu)) {
+ struct threshold_bank *bankp = per_cpu(threshold_banks, cpu)[bank];
+
+ if (bankp && bankp->blocks) {
+ struct threshold_block *blockp = &bankp->blocks[block];
+
+ if (blockp)
+ return blockp->address;
+ }
+ }
+
if (mce_flags.smca) {
if (smca_get_bank_type(bank) == SMCA_RESERVED)
return addr;
^ permalink raw reply [flat|nested] 58+ messages in thread* [4.14,39/49] x86/mce/AMD: Get address from already initialized block
@ 2018-04-17 15:59 ` Greg Kroah-Hartman
0 siblings, 0 replies; 58+ messages in thread
From: Greg Kroah-Hartman @ 2018-04-17 15:59 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Yazen Ghannam, Borislav Petkov,
Borislav Petkov, Linus Torvalds, Peter Zijlstra, Thomas Gleixner,
Tony Luck, linux-edac, Ingo Molnar
4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Yazen Ghannam <yazen.ghannam@amd.com>
commit 27bd59502702fe51d9eb00450a75b727ec6bfcb4 upstream.
The block address is saved after the block is initialized when
threshold_init_device() is called.
Use the saved block address, if available, rather than trying to
rediscover it.
This will avoid a call trace, when resuming from suspend, due to the
rdmsr_safe_on_cpu() call in get_block_address(). The rdmsr_safe_on_cpu()
call issues an IPI but we're running with interrupts disabled. This
triggers:
WARNING: CPU: 0 PID: 11523 at kernel/smp.c:291 smp_call_function_single+0xdc/0xe0
Signed-off-by: Yazen Ghannam <yazen.ghannam@amd.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
Cc: <stable@vger.kernel.org> # 4.14.x
Cc: Borislav Petkov <bp@alien8.de>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Tony Luck <tony.luck@intel.com>
Cc: linux-edac <linux-edac@vger.kernel.org>
Link: http://lkml.kernel.org/r/20180221101900.10326-8-bp@alien8.de
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/x86/kernel/cpu/mcheck/mce_amd.c | 15 +++++++++++++++
1 file changed, 15 insertions(+)
--
To unsubscribe from this list: send the line "unsubscribe linux-edac" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--- a/arch/x86/kernel/cpu/mcheck/mce_amd.c
+++ b/arch/x86/kernel/cpu/mcheck/mce_amd.c
@@ -434,6 +434,21 @@ static u32 get_block_address(unsigned in
{
u32 addr = 0, offset = 0;
+ if ((bank >= mca_cfg.banks) || (block >= NR_BLOCKS))
+ return addr;
+
+ /* Get address from already initialized block. */
+ if (per_cpu(threshold_banks, cpu)) {
+ struct threshold_bank *bankp = per_cpu(threshold_banks, cpu)[bank];
+
+ if (bankp && bankp->blocks) {
+ struct threshold_block *blockp = &bankp->blocks[block];
+
+ if (blockp)
+ return blockp->address;
+ }
+ }
+
if (mce_flags.smca) {
if (smca_get_bank_type(bank) == SMCA_RESERVED)
return addr;
^ permalink raw reply [flat|nested] 58+ messages in thread
* [PATCH 4.14 40/49] hwmon: (ina2xx) Fix access to uninitialized mutex
2018-04-17 15:58 [PATCH 4.14 00/49] 4.14.35-stable review Greg Kroah-Hartman
` (38 preceding siblings ...)
2018-04-17 15:59 ` [4.14,39/49] " Greg Kroah-Hartman
@ 2018-04-17 15:59 ` Greg Kroah-Hartman
2018-04-17 15:59 ` [PATCH 4.14 41/49] ath9k: Protect queue draining by rcu_read_lock() Greg Kroah-Hartman
` (12 subsequent siblings)
52 siblings, 0 replies; 58+ messages in thread
From: Greg Kroah-Hartman @ 2018-04-17 15:59 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Marek Szyprowski, Guenter Roeck
4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Marek Szyprowski <m.szyprowski@samsung.com>
commit 0c4c5860e9983eb3da7a3d73ca987643c3ed034b upstream.
Initialize data->config_lock mutex before it is used by the driver code.
This fixes following warning on Odroid XU3 boards:
INFO: trying to register non-static key.
the code is fine but needs lockdep annotation.
turning off the locking correctness validator.
CPU: 5 PID: 1 Comm: swapper/0 Not tainted 4.15.0-rc7-next-20180115-00001-gb75575dee3f2 #107
Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
[<c0111504>] (unwind_backtrace) from [<c010dbec>] (show_stack+0x10/0x14)
[<c010dbec>] (show_stack) from [<c09b3f74>] (dump_stack+0x90/0xc8)
[<c09b3f74>] (dump_stack) from [<c0179528>] (register_lock_class+0x1c0/0x59c)
[<c0179528>] (register_lock_class) from [<c017bd1c>] (__lock_acquire+0x78/0x1850)
[<c017bd1c>] (__lock_acquire) from [<c017de30>] (lock_acquire+0xc8/0x2b8)
[<c017de30>] (lock_acquire) from [<c09ca59c>] (__mutex_lock+0x60/0xa0c)
[<c09ca59c>] (__mutex_lock) from [<c09cafd0>] (mutex_lock_nested+0x1c/0x24)
[<c09cafd0>] (mutex_lock_nested) from [<c068b0d0>] (ina2xx_set_shunt+0x70/0xb0)
[<c068b0d0>] (ina2xx_set_shunt) from [<c068b218>] (ina2xx_probe+0x88/0x1b0)
[<c068b218>] (ina2xx_probe) from [<c0673d90>] (i2c_device_probe+0x1e0/0x2d0)
[<c0673d90>] (i2c_device_probe) from [<c053a268>] (driver_probe_device+0x2b8/0x4a0)
[<c053a268>] (driver_probe_device) from [<c053a54c>] (__driver_attach+0xfc/0x120)
[<c053a54c>] (__driver_attach) from [<c05384cc>] (bus_for_each_dev+0x58/0x7c)
[<c05384cc>] (bus_for_each_dev) from [<c0539590>] (bus_add_driver+0x174/0x250)
[<c0539590>] (bus_add_driver) from [<c053b5e0>] (driver_register+0x78/0xf4)
[<c053b5e0>] (driver_register) from [<c0675ef0>] (i2c_register_driver+0x38/0xa8)
[<c0675ef0>] (i2c_register_driver) from [<c0102b40>] (do_one_initcall+0x48/0x18c)
[<c0102b40>] (do_one_initcall) from [<c0e00df0>] (kernel_init_freeable+0x110/0x1d4)
[<c0e00df0>] (kernel_init_freeable) from [<c09c8120>] (kernel_init+0x8/0x114)
[<c09c8120>] (kernel_init) from [<c01010b4>] (ret_from_fork+0x14/0x20)
Fixes: 5d389b125186 ("hwmon: (ina2xx) Make calibration register value fixed")
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/hwmon/ina2xx.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
--- a/drivers/hwmon/ina2xx.c
+++ b/drivers/hwmon/ina2xx.c
@@ -454,6 +454,7 @@ static int ina2xx_probe(struct i2c_clien
/* set the device type */
data->config = &ina2xx_config[chip];
+ mutex_init(&data->config_lock);
if (of_property_read_u32(dev->of_node, "shunt-resistor", &val) < 0) {
struct ina2xx_platform_data *pdata = dev_get_platdata(dev);
@@ -480,8 +481,6 @@ static int ina2xx_probe(struct i2c_clien
return -ENODEV;
}
- mutex_init(&data->config_lock);
-
data->groups[group++] = &ina2xx_group;
if (id->driver_data == ina226)
data->groups[group++] = &ina226_group;
^ permalink raw reply [flat|nested] 58+ messages in thread* [PATCH 4.14 41/49] ath9k: Protect queue draining by rcu_read_lock()
2018-04-17 15:58 [PATCH 4.14 00/49] 4.14.35-stable review Greg Kroah-Hartman
` (39 preceding siblings ...)
2018-04-17 15:59 ` [PATCH 4.14 40/49] hwmon: (ina2xx) Fix access to uninitialized mutex Greg Kroah-Hartman
@ 2018-04-17 15:59 ` Greg Kroah-Hartman
2018-04-17 15:59 ` [PATCH 4.14 42/49] sunrpc: remove incorrect HMAC request initialization Greg Kroah-Hartman
` (11 subsequent siblings)
52 siblings, 0 replies; 58+ messages in thread
From: Greg Kroah-Hartman @ 2018-04-17 15:59 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Ben Greear,
Toke Høiland-Jørgensen, Kalle Valo
4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Toke Høiland-Jørgensen <toke@toke.dk>
commit 182b1917109892ab9f26d66bfdcbc4ba6f0a0a65 upstream.
When ath9k was switched over to use the mac80211 intermediate queues,
node cleanup now drains the mac80211 queues. However, this call path is
not protected by rcu_read_lock() as it was previously entirely internal
to the driver which uses its own locking.
This leads to a possible rcu_dereference() without holding
rcu_read_lock(); but only if a station is cleaned up while having
packets queued on the TXQ. Fix this by adding the rcu_read_lock() to the
caller in ath9k.
Fixes: 50f08edf9809 ("ath9k: Switch to using mac80211 intermediate software queues.")
Cc: stable@vger.kernel.org
Reported-by: Ben Greear <greearb@candelatech.com>
Signed-off-by: Toke Høiland-Jørgensen <toke@toke.dk>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/net/wireless/ath/ath9k/xmit.c | 4 ++++
1 file changed, 4 insertions(+)
--- a/drivers/net/wireless/ath/ath9k/xmit.c
+++ b/drivers/net/wireless/ath/ath9k/xmit.c
@@ -2892,6 +2892,8 @@ void ath_tx_node_cleanup(struct ath_soft
struct ath_txq *txq;
int tidno;
+ rcu_read_lock();
+
for (tidno = 0; tidno < IEEE80211_NUM_TIDS; tidno++) {
tid = ath_node_to_tid(an, tidno);
txq = tid->txq;
@@ -2909,6 +2911,8 @@ void ath_tx_node_cleanup(struct ath_soft
if (!an->sta)
break; /* just one multicast ath_atx_tid */
}
+
+ rcu_read_unlock();
}
#ifdef CONFIG_ATH9K_TX99
^ permalink raw reply [flat|nested] 58+ messages in thread* [PATCH 4.14 42/49] sunrpc: remove incorrect HMAC request initialization
2018-04-17 15:58 [PATCH 4.14 00/49] 4.14.35-stable review Greg Kroah-Hartman
` (40 preceding siblings ...)
2018-04-17 15:59 ` [PATCH 4.14 41/49] ath9k: Protect queue draining by rcu_read_lock() Greg Kroah-Hartman
@ 2018-04-17 15:59 ` Greg Kroah-Hartman
2018-04-17 15:59 ` [PATCH 4.14 43/49] f2fs: fix heap mode to reset it back Greg Kroah-Hartman
` (10 subsequent siblings)
52 siblings, 0 replies; 58+ messages in thread
From: Greg Kroah-Hartman @ 2018-04-17 15:59 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Michael Young, Eric Biggers, J. Bruce Fields
4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Eric Biggers <ebiggers@google.com>
commit f3aefb6a7066e24bfea7fcf1b07907576de69d63 upstream.
make_checksum_hmac_md5() is allocating an HMAC transform and doing
crypto API calls in the following order:
crypto_ahash_init()
crypto_ahash_setkey()
crypto_ahash_digest()
This is wrong because it makes no sense to init() the request before a
key has been set, given that the initial state depends on the key. And
digest() is short for init() + update() + final(), so in this case
there's no need to explicitly call init() at all.
Before commit 9fa68f620041 ("crypto: hash - prevent using keyed hashes
without setting key") the extra init() had no real effect, at least for
the software HMAC implementation. (There are also hardware drivers that
implement HMAC-MD5, and it's not immediately obvious how gracefully they
handle init() before setkey().) But now the crypto API detects this
incorrect initialization and returns -ENOKEY. This is breaking NFS
mounts in some cases.
Fix it by removing the incorrect call to crypto_ahash_init().
Reported-by: Michael Young <m.a.young@durham.ac.uk>
Fixes: 9fa68f620041 ("crypto: hash - prevent using keyed hashes without setting key")
Fixes: fffdaef2eb4a ("gss_krb5: Add support for rc4-hmac encryption")
Cc: stable@vger.kernel.org
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: J. Bruce Fields <bfields@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
net/sunrpc/auth_gss/gss_krb5_crypto.c | 3 ---
1 file changed, 3 deletions(-)
--- a/net/sunrpc/auth_gss/gss_krb5_crypto.c
+++ b/net/sunrpc/auth_gss/gss_krb5_crypto.c
@@ -237,9 +237,6 @@ make_checksum_hmac_md5(struct krb5_ctx *
ahash_request_set_callback(req, CRYPTO_TFM_REQ_MAY_SLEEP, NULL, NULL);
- err = crypto_ahash_init(req);
- if (err)
- goto out;
err = crypto_ahash_setkey(hmac_md5, cksumkey, kctx->gk5e->keylength);
if (err)
goto out;
^ permalink raw reply [flat|nested] 58+ messages in thread* [PATCH 4.14 43/49] f2fs: fix heap mode to reset it back
2018-04-17 15:58 [PATCH 4.14 00/49] 4.14.35-stable review Greg Kroah-Hartman
` (41 preceding siblings ...)
2018-04-17 15:59 ` [PATCH 4.14 42/49] sunrpc: remove incorrect HMAC request initialization Greg Kroah-Hartman
@ 2018-04-17 15:59 ` Greg Kroah-Hartman
2018-04-17 15:59 ` [PATCH 4.14 44/49] lib: fix stall in __bitmap_parselist() Greg Kroah-Hartman
` (9 subsequent siblings)
52 siblings, 0 replies; 58+ messages in thread
From: Greg Kroah-Hartman @ 2018-04-17 15:59 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Yunlong Song, Chao Yu, Jaegeuk Kim
4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Yunlong Song <yunlong.song@huawei.com>
commit b94929d975c8423defc9aededb0f499ff936b509 upstream.
Commit 7a20b8a61eff81bdb7097a578752a74860e9d142 ("f2fs: allocate node
and hot data in the beginning of partition") introduces another mount
option, heap, to reset it back. But it does not do anything for heap
mode, so fix it.
Cc: stable@vger.kernel.org
Signed-off-by: Yunlong Song <yunlong.song@huawei.com>
Reviewed-by: Chao Yu <yuchao0@huawei.com>
Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
fs/f2fs/gc.c | 5 +++--
fs/f2fs/segment.c | 3 ++-
2 files changed, 5 insertions(+), 3 deletions(-)
--- a/fs/f2fs/gc.c
+++ b/fs/f2fs/gc.c
@@ -191,8 +191,9 @@ static void select_policy(struct f2fs_sb
if (gc_type != FG_GC && p->max_search > sbi->max_victim_search)
p->max_search = sbi->max_victim_search;
- /* let's select beginning hot/small space first */
- if (type == CURSEG_HOT_DATA || IS_NODESEG(type))
+ /* let's select beginning hot/small space first in no_heap mode*/
+ if (test_opt(sbi, NOHEAP) &&
+ (type == CURSEG_HOT_DATA || IS_NODESEG(type)))
p->offset = 0;
else
p->offset = SIT_I(sbi)->last_victim[p->gc_mode];
--- a/fs/f2fs/segment.c
+++ b/fs/f2fs/segment.c
@@ -1992,7 +1992,8 @@ static unsigned int __get_next_segno(str
if (sbi->segs_per_sec != 1)
return CURSEG_I(sbi, type)->segno;
- if (type == CURSEG_HOT_DATA || IS_NODESEG(type))
+ if (test_opt(sbi, NOHEAP) &&
+ (type == CURSEG_HOT_DATA || IS_NODESEG(type)))
return 0;
if (SIT_I(sbi)->last_victim[ALLOC_NEXT])
^ permalink raw reply [flat|nested] 58+ messages in thread* [PATCH 4.14 44/49] lib: fix stall in __bitmap_parselist()
2018-04-17 15:58 [PATCH 4.14 00/49] 4.14.35-stable review Greg Kroah-Hartman
` (42 preceding siblings ...)
2018-04-17 15:59 ` [PATCH 4.14 43/49] f2fs: fix heap mode to reset it back Greg Kroah-Hartman
@ 2018-04-17 15:59 ` Greg Kroah-Hartman
2018-04-17 15:59 ` Greg Kroah-Hartman
` (8 subsequent siblings)
52 siblings, 0 replies; 58+ messages in thread
From: Greg Kroah-Hartman @ 2018-04-17 15:59 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Yury Norov, Tetsuo Handa, syzbot,
Noam Camus, Rasmus Villemoes, Matthew Wilcox,
Mauro Carvalho Chehab, Andrew Morton, Linus Torvalds
4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Yury Norov <ynorov@caviumnetworks.com>
commit 8351760ff5b2042039554b4948ddabaac644a976 upstream.
syzbot is catching stalls at __bitmap_parselist()
(https://syzkaller.appspot.com/bug?id=ad7e0351fbc90535558514a71cd3edc11681997a).
The trigger is
unsigned long v = 0;
bitmap_parselist("7:,", &v, BITS_PER_LONG);
which results in hitting infinite loop at
while (a <= b) {
off = min(b - a + 1, used_size);
bitmap_set(maskp, a, off);
a += group_size;
}
due to used_size == group_size == 0.
Link: http://lkml.kernel.org/r/20180404162647.15763-1-ynorov@caviumnetworks.com
Fixes: 0a5ce0831d04382a ("lib/bitmap.c: make bitmap_parselist() thread-safe and much faster")
Signed-off-by: Yury Norov <ynorov@caviumnetworks.com>
Reported-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Reported-by: syzbot <syzbot+6887cbb011c8054e8a3d@syzkaller.appspotmail.com>
Cc: Noam Camus <noamca@mellanox.com>
Cc: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Cc: Matthew Wilcox <mawilcox@microsoft.com>
Cc: Mauro Carvalho Chehab <mchehab@kernel.org>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
lib/bitmap.c | 2 +-
lib/test_bitmap.c | 4 ++++
2 files changed, 5 insertions(+), 1 deletion(-)
--- a/lib/bitmap.c
+++ b/lib/bitmap.c
@@ -605,7 +605,7 @@ static int __bitmap_parselist(const char
/* if no digit is after '-', it's wrong*/
if (at_start && in_range)
return -EINVAL;
- if (!(a <= b) || !(used_size <= group_size))
+ if (!(a <= b) || group_size == 0 || !(used_size <= group_size))
return -EINVAL;
if (b >= nmaskbits)
return -ERANGE;
--- a/lib/test_bitmap.c
+++ b/lib/test_bitmap.c
@@ -218,6 +218,10 @@ static const struct test_bitmap_parselis
{-EINVAL, "-1", NULL, 8, 0},
{-EINVAL, "-0", NULL, 8, 0},
{-EINVAL, "10-1", NULL, 8, 0},
+ {-EINVAL, "0-31:", NULL, 8, 0},
+ {-EINVAL, "0-31:0", NULL, 8, 0},
+ {-EINVAL, "0-31:0/0", NULL, 8, 0},
+ {-EINVAL, "0-31:1/0", NULL, 8, 0},
{-EINVAL, "0-31:10/1", NULL, 8, 0},
};
^ permalink raw reply [flat|nested] 58+ messages in thread* [PATCH 4.14 45/49] blk-mq: dont keep offline CPUs mapped to hctx 0
2018-04-17 15:58 [PATCH 4.14 00/49] 4.14.35-stable review Greg Kroah-Hartman
@ 2018-04-17 15:59 ` Greg Kroah-Hartman
2018-04-17 15:58 ` [PATCH 4.14 02/49] cdc_ether: flag the Cinterion AHS8 modem by gemalto as WWAN Greg Kroah-Hartman
` (51 subsequent siblings)
52 siblings, 0 replies; 58+ messages in thread
From: Greg Kroah-Hartman @ 2018-04-17 15:59 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Stefan Haberland, Keith Busch,
Christian Borntraeger, Christoph Hellwig, Sagi Grimberg,
Ming Lei, Jens Axboe
4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ming Lei <ming.lei@redhat.com>
commit bffa9909a6b48d8ca3398dec601bc9162a4020c4 upstream.
>From commit 4b855ad37194 ("blk-mq: Create hctx for each present CPU),
blk-mq doesn't remap queue after CPU topo is changed, that said when
some of these offline CPUs become online, they are still mapped to
hctx 0, then hctx 0 may become the bottleneck of IO dispatch and
completion.
This patch sets up the mapping from the beginning, and aligns to
queue mapping for PCI device (blk_mq_pci_map_queues()).
Cc: Stefan Haberland <sth@linux.vnet.ibm.com>
Cc: Keith Busch <keith.busch@intel.com>
Cc: stable@vger.kernel.org
Fixes: 4b855ad37194 ("blk-mq: Create hctx for each present CPU)
Tested-by: Christian Borntraeger <borntraeger@de.ibm.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Sagi Grimberg <sagi@grimberg.me>
Signed-off-by: Ming Lei <ming.lei@redhat.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
block/blk-mq-cpumap.c | 5 -----
1 file changed, 5 deletions(-)
--- a/block/blk-mq-cpumap.c
+++ b/block/blk-mq-cpumap.c
@@ -16,11 +16,6 @@
static int cpu_to_queue_index(unsigned int nr_queues, const int cpu)
{
- /*
- * Non present CPU will be mapped to queue index 0.
- */
- if (!cpu_present(cpu))
- return 0;
return cpu % nr_queues;
}
^ permalink raw reply [flat|nested] 58+ messages in thread* [PATCH 4.14 45/49] blk-mq: dont keep offline CPUs mapped to hctx 0
@ 2018-04-17 15:59 ` Greg Kroah-Hartman
0 siblings, 0 replies; 58+ messages in thread
From: Greg Kroah-Hartman @ 2018-04-17 15:59 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Stefan Haberland, Keith Busch,
Christian Borntraeger, Christoph Hellwig, Sagi Grimberg,
Ming Lei, Jens Axboe
4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ming Lei <ming.lei@redhat.com>
commit bffa9909a6b48d8ca3398dec601bc9162a4020c4 upstream.
>>From commit 4b855ad37194 ("blk-mq: Create hctx for each present CPU),
blk-mq doesn't remap queue after CPU topo is changed, that said when
some of these offline CPUs become online, they are still mapped to
hctx 0, then hctx 0 may become the bottleneck of IO dispatch and
completion.
This patch sets up the mapping from the beginning, and aligns to
queue mapping for PCI device (blk_mq_pci_map_queues()).
Cc: Stefan Haberland <sth@linux.vnet.ibm.com>
Cc: Keith Busch <keith.busch@intel.com>
Cc: stable@vger.kernel.org
Fixes: 4b855ad37194 ("blk-mq: Create hctx for each present CPU)
Tested-by: Christian Borntraeger <borntraeger@de.ibm.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Sagi Grimberg <sagi@grimberg.me>
Signed-off-by: Ming Lei <ming.lei@redhat.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
block/blk-mq-cpumap.c | 5 -----
1 file changed, 5 deletions(-)
--- a/block/blk-mq-cpumap.c
+++ b/block/blk-mq-cpumap.c
@@ -16,11 +16,6 @@
static int cpu_to_queue_index(unsigned int nr_queues, const int cpu)
{
- /*
- * Non present CPU will be mapped to queue index 0.
- */
- if (!cpu_present(cpu))
- return 0;
return cpu % nr_queues;
}
^ permalink raw reply [flat|nested] 58+ messages in thread
* [PATCH 4.14 46/49] ovl: fix lookup with middle layer opaque dir and absolute path redirects
2018-04-17 15:58 [PATCH 4.14 00/49] 4.14.35-stable review Greg Kroah-Hartman
` (44 preceding siblings ...)
2018-04-17 15:59 ` Greg Kroah-Hartman
@ 2018-04-17 15:59 ` Greg Kroah-Hartman
2018-04-17 15:59 ` [PATCH 4.14 47/49] xen: xenbus_dev_frontend: Fix XS_TRANSACTION_END handling Greg Kroah-Hartman
` (6 subsequent siblings)
52 siblings, 0 replies; 58+ messages in thread
From: Greg Kroah-Hartman @ 2018-04-17 15:59 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Amir Goldstein, Vivek Goyal, Miklos Szeredi
4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Amir Goldstein <amir73il@gmail.com>
commit 3ec9b3fafcaf441cc4d46b9742cd6ec0c79f8df0 upstream.
As of now if we encounter an opaque dir while looking for a dentry, we set
d->last=true. This means that there is no need to look further in any of
the lower layers. This works fine as long as there are no redirets or
relative redircts. But what if there is an absolute redirect on the
children dentry of opaque directory. We still need to continue to look into
next lower layer. This patch fixes it.
Here is an example to demonstrate the issue. Say you have following setup.
upper: /redirect (redirect=/a/b/c)
lower1: /a/[b]/c ([b] is opaque) (c has absolute redirect=/a/b/d/)
lower0: /a/b/d/foo
Now "redirect" dir should merge with lower1:/a/b/c/ and lower0:/a/b/d.
Note, despite the fact lower1:/a/[b] is opaque, we need to continue to look
into lower0 because children c has an absolute redirect.
Following is a reproducer.
Watch me make foo disappear:
$ mkdir lower middle upper work work2 merged
$ mkdir lower/origin
$ touch lower/origin/foo
$ mount -t overlay none merged/ \
-olowerdir=lower,upperdir=middle,workdir=work2
$ mkdir merged/pure
$ mv merged/origin merged/pure/redirect
$ umount merged
$ mount -t overlay none merged/ \
-olowerdir=middle:lower,upperdir=upper,workdir=work
$ mv merged/pure/redirect merged/redirect
Now you see foo inside a twice redirected merged dir:
$ ls merged/redirect
foo
$ umount merged
$ mount -t overlay none merged/ \
-olowerdir=middle:lower,upperdir=upper,workdir=work
After mount cycle you don't see foo inside the same dir:
$ ls merged/redirect
During middle layer lookup, the opaqueness of middle/pure is left in
the lookup state and then middle/pure/redirect is wrongly treated as
opaque.
Fixes: 02b69b284cd7 ("ovl: lookup redirects")
Cc: <stable@vger.kernel.org> #v4.10
Signed-off-by: Amir Goldstein <amir73il@gmail.com>
Signed-off-by: Vivek Goyal <vgoyal@redhat.com>
Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
fs/overlayfs/namei.c | 9 +++++++++
1 file changed, 9 insertions(+)
--- a/fs/overlayfs/namei.c
+++ b/fs/overlayfs/namei.c
@@ -56,6 +56,15 @@ static int ovl_check_redirect(struct den
if (s == next)
goto invalid;
}
+ /*
+ * One of the ancestor path elements in an absolute path
+ * lookup in ovl_lookup_layer() could have been opaque and
+ * that will stop further lookup in lower layers (d->stop=true)
+ * But we have found an absolute redirect in decendant path
+ * element and that should force continue lookup in lower
+ * layers (reset d->stop).
+ */
+ d->stop = false;
} else {
if (strchr(buf, '/') != NULL)
goto invalid;
^ permalink raw reply [flat|nested] 58+ messages in thread* [PATCH 4.14 47/49] xen: xenbus_dev_frontend: Fix XS_TRANSACTION_END handling
2018-04-17 15:58 [PATCH 4.14 00/49] 4.14.35-stable review Greg Kroah-Hartman
` (45 preceding siblings ...)
2018-04-17 15:59 ` [PATCH 4.14 46/49] ovl: fix lookup with middle layer opaque dir and absolute path redirects Greg Kroah-Hartman
@ 2018-04-17 15:59 ` Greg Kroah-Hartman
2018-04-17 15:59 ` [PATCH 4.14 48/49] hugetlbfs: fix bug in pgoff overflow checking Greg Kroah-Hartman
` (5 subsequent siblings)
52 siblings, 0 replies; 58+ messages in thread
From: Greg Kroah-Hartman @ 2018-04-17 15:59 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Simon Gaiser, Juergen Gross, Boris Ostrovsky
4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Simon Gaiser <simon@invisiblethingslab.com>
commit 2a22ee6c3ab1d761bc9c04f1e4117edd55b82f09 upstream.
Commit fd8aa9095a95 ("xen: optimize xenbus driver for multiple
concurrent xenstore accesses") made a subtle change to the semantic of
xenbus_dev_request_and_reply() and xenbus_transaction_end().
Before on an error response to XS_TRANSACTION_END
xenbus_dev_request_and_reply() would not decrement the active
transaction counter. But xenbus_transaction_end() has always counted the
transaction as finished regardless of the response.
The new behavior is that xenbus_dev_request_and_reply() and
xenbus_transaction_end() will always count the transaction as finished
regardless the response code (handled in xs_request_exit()).
But xenbus_dev_frontend tries to end a transaction on closing of the
device if the XS_TRANSACTION_END failed before. Trying to close the
transaction twice corrupts the reference count. So fix this by also
considering a transaction closed if we have sent XS_TRANSACTION_END once
regardless of the return code.
Cc: <stable@vger.kernel.org> # 4.11
Fixes: fd8aa9095a95 ("xen: optimize xenbus driver for multiple concurrent xenstore accesses")
Signed-off-by: Simon Gaiser <simon@invisiblethingslab.com>
Reviewed-by: Juergen Gross <jgross@suse.com>
Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/xen/xenbus/xenbus_dev_frontend.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/xen/xenbus/xenbus_dev_frontend.c
+++ b/drivers/xen/xenbus/xenbus_dev_frontend.c
@@ -365,7 +365,7 @@ void xenbus_dev_queue_reply(struct xb_re
if (WARN_ON(rc))
goto out;
}
- } else if (req->msg.type == XS_TRANSACTION_END) {
+ } else if (req->type == XS_TRANSACTION_END) {
trans = xenbus_get_transaction(u, req->msg.tx_id);
if (WARN_ON(!trans))
goto out;
^ permalink raw reply [flat|nested] 58+ messages in thread* [PATCH 4.14 48/49] hugetlbfs: fix bug in pgoff overflow checking
2018-04-17 15:58 [PATCH 4.14 00/49] 4.14.35-stable review Greg Kroah-Hartman
` (46 preceding siblings ...)
2018-04-17 15:59 ` [PATCH 4.14 47/49] xen: xenbus_dev_frontend: Fix XS_TRANSACTION_END handling Greg Kroah-Hartman
@ 2018-04-17 15:59 ` Greg Kroah-Hartman
2018-04-17 15:59 ` [PATCH 4.14 49/49] nfsd: fix incorrect umasks Greg Kroah-Hartman
` (4 subsequent siblings)
52 siblings, 0 replies; 58+ messages in thread
From: Greg Kroah-Hartman @ 2018-04-17 15:59 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Dan Rue, Mike Kravetz, Anders Roxell,
Michal Hocko, Yisheng Xie, Kirill A . Shutemov, Nic Losby,
Andrew Morton, Linus Torvalds
4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Mike Kravetz <mike.kravetz@oracle.com>
commit 5df63c2a149ae65a9ec239e7c2af44efa6f79beb upstream.
This is a fix for a regression in 32 bit kernels caused by an invalid
check for pgoff overflow in hugetlbfs mmap setup. The check incorrectly
specified that the size of a loff_t was the same as the size of a long.
The regression prevents mapping hugetlbfs files at offsets greater than
4GB on 32 bit kernels.
On 32 bit kernels conversion from a page based unsigned long can not
overflow a loff_t byte offset. Therefore, skip this check if
sizeof(unsigned long) != sizeof(loff_t).
Link: http://lkml.kernel.org/r/20180330145402.5053-1-mike.kravetz@oracle.com
Fixes: 63489f8e8211 ("hugetlbfs: check for pgoff value overflow")
Reported-by: Dan Rue <dan.rue@linaro.org>
Signed-off-by: Mike Kravetz <mike.kravetz@oracle.com>
Tested-by: Anders Roxell <anders.roxell@linaro.org>
Cc: Michal Hocko <mhocko@kernel.org>
Cc: Yisheng Xie <xieyisheng1@huawei.com>
Cc: "Kirill A . Shutemov" <kirill.shutemov@linux.intel.com>
Cc: Nic Losby <blurbdust@gmail.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
fs/hugetlbfs/inode.c | 10 +++++++---
1 file changed, 7 insertions(+), 3 deletions(-)
--- a/fs/hugetlbfs/inode.c
+++ b/fs/hugetlbfs/inode.c
@@ -148,10 +148,14 @@ static int hugetlbfs_file_mmap(struct fi
/*
* page based offset in vm_pgoff could be sufficiently large to
- * overflow a (l)off_t when converted to byte offset.
+ * overflow a loff_t when converted to byte offset. This can
+ * only happen on architectures where sizeof(loff_t) ==
+ * sizeof(unsigned long). So, only check in those instances.
*/
- if (vma->vm_pgoff & PGOFF_LOFFT_MAX)
- return -EINVAL;
+ if (sizeof(unsigned long) == sizeof(loff_t)) {
+ if (vma->vm_pgoff & PGOFF_LOFFT_MAX)
+ return -EINVAL;
+ }
/* must be huge page aligned */
if (vma->vm_pgoff & (~huge_page_mask(h) >> PAGE_SHIFT))
^ permalink raw reply [flat|nested] 58+ messages in thread* [PATCH 4.14 49/49] nfsd: fix incorrect umasks
2018-04-17 15:58 [PATCH 4.14 00/49] 4.14.35-stable review Greg Kroah-Hartman
` (47 preceding siblings ...)
2018-04-17 15:59 ` [PATCH 4.14 48/49] hugetlbfs: fix bug in pgoff overflow checking Greg Kroah-Hartman
@ 2018-04-17 15:59 ` Greg Kroah-Hartman
2018-04-17 21:05 ` [PATCH 4.14 00/49] 4.14.35-stable review Shuah Khan
` (3 subsequent siblings)
52 siblings, 0 replies; 58+ messages in thread
From: Greg Kroah-Hartman @ 2018-04-17 15:59 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Lucash Stach, J. Bruce Fields
4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: J. Bruce Fields <bfields@redhat.com>
commit 880a3a5325489a143269a8e172e7563ebf9897bc upstream.
We're neglecting to clear the umask after it's set, which can cause a
later unrelated rpc to (incorrectly) use the same umask if it happens to
be processed by the same thread.
There's a more subtle problem here too:
An NFSv4 compound request is decoded all in one pass before any
operations are executed.
Currently we're setting current->fs->umask at the time we decode the
compound. In theory a single compound could contain multiple creates
each setting a umask. In that case we'd end up using whichever umask
was passed in the *last* operation as the umask for all the creates,
whether that was correct or not.
So, we should just be saving the umask at decode time and waiting to set
it until we actually process the corresponding operation.
In practice it's unlikely any client would do multiple creates in a
single compound. And even if it did they'd likely be from the same
process (hence carry the same umask). So this is a little academic, but
we should get it right anyway.
Fixes: 47057abde515 (nfsd: add support for the umask attribute)
Cc: stable@vger.kernel.org
Reported-by: Lucash Stach <l.stach@pengutronix.de>
Signed-off-by: J. Bruce Fields <bfields@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
fs/nfsd/nfs4proc.c | 12 ++++++++++--
fs/nfsd/nfs4xdr.c | 8 +++-----
fs/nfsd/xdr4.h | 2 ++
3 files changed, 15 insertions(+), 7 deletions(-)
--- a/fs/nfsd/nfs4proc.c
+++ b/fs/nfsd/nfs4proc.c
@@ -32,6 +32,7 @@
* NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
* SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
*/
+#include <linux/fs_struct.h>
#include <linux/file.h>
#include <linux/falloc.h>
#include <linux/slab.h>
@@ -252,11 +253,13 @@ do_open_lookup(struct svc_rqst *rqstp, s
* Note: create modes (UNCHECKED,GUARDED...) are the same
* in NFSv4 as in v3 except EXCLUSIVE4_1.
*/
+ current->fs->umask = open->op_umask;
status = do_nfsd_create(rqstp, current_fh, open->op_fname.data,
open->op_fname.len, &open->op_iattr,
*resfh, open->op_createmode,
(u32 *)open->op_verf.data,
&open->op_truncate, &open->op_created);
+ current->fs->umask = 0;
if (!status && open->op_label.len)
nfsd4_security_inode_setsecctx(*resfh, &open->op_label, open->op_bmval);
@@ -608,6 +611,7 @@ nfsd4_create(struct svc_rqst *rqstp, str
if (status)
return status;
+ current->fs->umask = create->cr_umask;
switch (create->cr_type) {
case NF4LNK:
status = nfsd_symlink(rqstp, &cstate->current_fh,
@@ -616,20 +620,22 @@ nfsd4_create(struct svc_rqst *rqstp, str
break;
case NF4BLK:
+ status = nfserr_inval;
rdev = MKDEV(create->cr_specdata1, create->cr_specdata2);
if (MAJOR(rdev) != create->cr_specdata1 ||
MINOR(rdev) != create->cr_specdata2)
- return nfserr_inval;
+ goto out_umask;
status = nfsd_create(rqstp, &cstate->current_fh,
create->cr_name, create->cr_namelen,
&create->cr_iattr, S_IFBLK, rdev, &resfh);
break;
case NF4CHR:
+ status = nfserr_inval;
rdev = MKDEV(create->cr_specdata1, create->cr_specdata2);
if (MAJOR(rdev) != create->cr_specdata1 ||
MINOR(rdev) != create->cr_specdata2)
- return nfserr_inval;
+ goto out_umask;
status = nfsd_create(rqstp, &cstate->current_fh,
create->cr_name, create->cr_namelen,
&create->cr_iattr,S_IFCHR, rdev, &resfh);
@@ -673,6 +679,8 @@ nfsd4_create(struct svc_rqst *rqstp, str
fh_dup2(&cstate->current_fh, &resfh);
out:
fh_put(&resfh);
+out_umask:
+ current->fs->umask = 0;
return status;
}
--- a/fs/nfsd/nfs4xdr.c
+++ b/fs/nfsd/nfs4xdr.c
@@ -33,7 +33,6 @@
* SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
*/
-#include <linux/fs_struct.h>
#include <linux/file.h>
#include <linux/slab.h>
#include <linux/namei.h>
@@ -683,7 +682,7 @@ nfsd4_decode_create(struct nfsd4_compoun
status = nfsd4_decode_fattr(argp, create->cr_bmval, &create->cr_iattr,
&create->cr_acl, &create->cr_label,
- ¤t->fs->umask);
+ &create->cr_umask);
if (status)
goto out;
@@ -928,7 +927,6 @@ nfsd4_decode_open(struct nfsd4_compounda
case NFS4_OPEN_NOCREATE:
break;
case NFS4_OPEN_CREATE:
- current->fs->umask = 0;
READ_BUF(4);
open->op_createmode = be32_to_cpup(p++);
switch (open->op_createmode) {
@@ -936,7 +934,7 @@ nfsd4_decode_open(struct nfsd4_compounda
case NFS4_CREATE_GUARDED:
status = nfsd4_decode_fattr(argp, open->op_bmval,
&open->op_iattr, &open->op_acl, &open->op_label,
- ¤t->fs->umask);
+ &open->op_umask);
if (status)
goto out;
break;
@@ -951,7 +949,7 @@ nfsd4_decode_open(struct nfsd4_compounda
COPYMEM(open->op_verf.data, NFS4_VERIFIER_SIZE);
status = nfsd4_decode_fattr(argp, open->op_bmval,
&open->op_iattr, &open->op_acl, &open->op_label,
- ¤t->fs->umask);
+ &open->op_umask);
if (status)
goto out;
break;
--- a/fs/nfsd/xdr4.h
+++ b/fs/nfsd/xdr4.h
@@ -118,6 +118,7 @@ struct nfsd4_create {
} u;
u32 cr_bmval[3]; /* request */
struct iattr cr_iattr; /* request */
+ int cr_umask; /* request */
struct nfsd4_change_info cr_cinfo; /* response */
struct nfs4_acl *cr_acl;
struct xdr_netobj cr_label;
@@ -228,6 +229,7 @@ struct nfsd4_open {
u32 op_why_no_deleg; /* response - DELEG_NONE_EXT only */
u32 op_create; /* request */
u32 op_createmode; /* request */
+ int op_umask; /* request */
u32 op_bmval[3]; /* request */
struct iattr op_iattr; /* UNCHECKED4, GUARDED4, EXCLUSIVE4_1 */
nfs4_verifier op_verf __attribute__((aligned(32)));
^ permalink raw reply [flat|nested] 58+ messages in thread* Re: [PATCH 4.14 00/49] 4.14.35-stable review
2018-04-17 15:58 [PATCH 4.14 00/49] 4.14.35-stable review Greg Kroah-Hartman
` (48 preceding siblings ...)
2018-04-17 15:59 ` [PATCH 4.14 49/49] nfsd: fix incorrect umasks Greg Kroah-Hartman
@ 2018-04-17 21:05 ` Shuah Khan
2018-04-17 22:43 ` kernelci.org bot
` (2 subsequent siblings)
52 siblings, 0 replies; 58+ messages in thread
From: Shuah Khan @ 2018-04-17 21:05 UTC (permalink / raw)
To: Greg Kroah-Hartman, linux-kernel
Cc: torvalds, akpm, linux, patches, ben.hutchings, lkft-triage,
stable, Shuah Khan
On 04/17/2018 09:58 AM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.14.35 release.
> There are 49 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 Apr 19 15:56:59 UTC 2018.
> 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.14.35-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.14.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
>
Compiled and booted on my test system. No dmesg regressions.
thanks,
-- Shuah
^ permalink raw reply [flat|nested] 58+ messages in thread* Re: [PATCH 4.14 00/49] 4.14.35-stable review
2018-04-17 15:58 [PATCH 4.14 00/49] 4.14.35-stable review Greg Kroah-Hartman
` (49 preceding siblings ...)
2018-04-17 21:05 ` [PATCH 4.14 00/49] 4.14.35-stable review Shuah Khan
@ 2018-04-17 22:43 ` kernelci.org bot
2018-04-18 7:27 ` Naresh Kamboju
2018-04-18 15:38 ` Guenter Roeck
52 siblings, 0 replies; 58+ messages in thread
From: kernelci.org bot @ 2018-04-17 22:43 UTC (permalink / raw)
To: Greg Kroah-Hartman, linux-kernel
Cc: Greg Kroah-Hartman, torvalds, akpm, linux, shuahkh, patches,
ben.hutchings, lkft-triage, stable
stable-rc/linux-4.14.y boot: 54 boots: 0 failed, 52 passed with 2 untried/unknown (v4.14.34-50-gadacb0d81317)
Full Boot Summary: https://kernelci.org/boot/all/job/stable-rc/branch/linux-4.14.y/kernel/v4.14.34-50-gadacb0d81317/
Full Build Summary: https://kernelci.org/build/stable-rc/branch/linux-4.14.y/kernel/v4.14.34-50-gadacb0d81317/
Tree: stable-rc
Branch: linux-4.14.y
Git Describe: v4.14.34-50-gadacb0d81317
Git Commit: adacb0d813172896acb603b9af86907f1ee62a1f
Git URL: http://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
Tested: 28 unique boards, 11 SoC families, 13 builds out of 184
---
For more info write to <info@kernelci.org>
^ permalink raw reply [flat|nested] 58+ messages in thread* Re: [PATCH 4.14 00/49] 4.14.35-stable review
2018-04-17 15:58 [PATCH 4.14 00/49] 4.14.35-stable review Greg Kroah-Hartman
` (50 preceding siblings ...)
2018-04-17 22:43 ` kernelci.org bot
@ 2018-04-18 7:27 ` Naresh Kamboju
2018-04-18 15:38 ` Guenter Roeck
52 siblings, 0 replies; 58+ messages in thread
From: Naresh Kamboju @ 2018-04-18 7:27 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: open list, Linus Torvalds, Andrew Morton, Guenter Roeck,
Shuah Khan, patches, Ben Hutchings, lkft-triage, linux- stable
On 17 April 2018 at 21:28, Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:
> This is the start of the stable review cycle for the 4.14.35 release.
> There are 49 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 Apr 19 15:56:59 UTC 2018.
> 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.14.35-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.14.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
Results from Linaro’s test farm.
No regressions on arm64, arm and x86_64.
kselftest: BPF tests test_xdp_meta.sh and test_xdp_redirect.sh were being
skipped with "Could not run test without the ip {xdp,xdpgeneric} support",
which got added into iproute2 4.11 and now being run and reported failed
on stable-rc-4.14.35-rc1 and also on linux-mainline kernel 4.17.
We have an open bug to investigate this failure.
LKFT: mainline: BPF: test_xdp_redirect.sh and test_xdp_meta.sh skipped -
Could not run test without the ip xdpgeneric support
https://bugs.linaro.org/show_bug.cgi?id=3630
Summary
------------------------------------------------------------------------
kernel: 4.14.35-rc1
git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-4.14.y
git commit: adacb0d813172896acb603b9af86907f1ee62a1f
git describe: v4.14.34-50-gadacb0d81317
Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-4.14-oe/build/v4.14.34-50-gadacb0d81317
No regressions (compared to build v4.14.34)
------------------------------------------------------------------------
Boards, architectures and test suites:
-------------------------------------
dragonboard-410c - arm64
* boot - pass: 20
* kselftest - skip: 20, fail: 2, pass: 43
* libhugetlbfs - skip: 1, pass: 90
* ltp-cap_bounds-tests - pass: 2
* ltp-containers-tests - skip: 17, pass: 64
* ltp-fcntl-locktests-tests - pass: 2
* ltp-filecaps-tests - pass: 2
* ltp-fs-tests - skip: 6, pass: 57
* ltp-fs_bind-tests - pass: 2
* ltp-fs_perms_simple-tests - pass: 19
* ltp-fsx-tests - pass: 2
* ltp-hugetlb-tests - skip: 1, pass: 21
* ltp-io-tests - pass: 3
* ltp-ipc-tests - pass: 9
* ltp-math-tests - pass: 11
* ltp-nptl-tests - pass: 2
* ltp-pty-tests - pass: 4
* ltp-sched-tests - pass: 14
* ltp-securebits-tests - pass: 4
* ltp-syscalls-tests - skip: 134, pass: 1016
* ltp-timers-tests - pass: 13
hi6220-hikey - arm64
* boot - pass: 20
* kselftest - skip: 17, fail: 2, pass: 46
* libhugetlbfs - skip: 1, pass: 90
* ltp-cap_bounds-tests - pass: 2
* ltp-containers-tests - skip: 17, pass: 64
* ltp-fcntl-locktests-tests - pass: 2
* ltp-filecaps-tests - pass: 2
* ltp-fs-tests - skip: 6, pass: 57
* ltp-fs_bind-tests - pass: 2
* ltp-fs_perms_simple-tests - pass: 19
* ltp-fsx-tests - pass: 2
* ltp-hugetlb-tests - skip: 1, pass: 21
* ltp-io-tests - pass: 3
* ltp-ipc-tests - pass: 9
* ltp-math-tests - pass: 11
* ltp-nptl-tests - pass: 2
* ltp-pty-tests - pass: 4
* ltp-sched-tests - skip: 4, pass: 10
* ltp-securebits-tests - pass: 4
* ltp-syscalls-tests - skip: 135, pass: 1015
* ltp-timers-tests - pass: 13
juno-r2 - arm64
* boot - pass: 20
* kselftest - skip: 18, fail: 2, pass: 45
* libhugetlbfs - skip: 1, pass: 90
* ltp-cap_bounds-tests - pass: 2
* ltp-containers-tests - skip: 17, pass: 64
* ltp-fcntl-locktests-tests - pass: 2
* ltp-filecaps-tests - pass: 2
* ltp-fs-tests - skip: 6, pass: 57
* ltp-fs_bind-tests - pass: 2
* ltp-fs_perms_simple-tests - pass: 19
* ltp-fsx-tests - pass: 2
* ltp-hugetlb-tests - pass: 22
* ltp-io-tests - pass: 3
* ltp-ipc-tests - pass: 9
* ltp-math-tests - pass: 11
* ltp-nptl-tests - pass: 2
* ltp-pty-tests - pass: 4
* ltp-sched-tests - skip: 4, pass: 10
* ltp-securebits-tests - pass: 4
* ltp-syscalls-tests - skip: 134, pass: 1016
* ltp-timers-tests - pass: 13
qemu_x86_64
* boot - pass: 22
* kselftest - skip: 22, fail: 2, pass: 56
* kselftest-vsyscall-mode-native - skip: 22, fail: 2, pass: 56
* kselftest-vsyscall-mode-none - skip: 22, fail: 2, pass: 56
* libhugetlbfs - skip: 1, pass: 90
* ltp-cap_bounds-tests - pass: 2
* ltp-containers-tests - skip: 17, pass: 64
* ltp-fcntl-locktests-tests - pass: 2
* ltp-filecaps-tests - pass: 2
* ltp-fs-tests - skip: 6, pass: 57
* ltp-fs_bind-tests - pass: 2
* ltp-fs_perms_simple-tests - pass: 19
* ltp-fsx-tests - pass: 2
* ltp-hugetlb-tests - pass: 22
* ltp-io-tests - pass: 3
* ltp-ipc-tests - pass: 9
* ltp-math-tests - pass: 11
* ltp-nptl-tests - pass: 2
* ltp-pty-tests - pass: 4
* ltp-sched-tests - skip: 1, pass: 13
* ltp-securebits-tests - pass: 4
* ltp-syscalls-tests - skip: 147, pass: 1003
* ltp-timers-tests - pass: 13
x15 - arm
* boot - pass: 20
* kselftest - skip: 19, fail: 4, pass: 39
* libhugetlbfs - skip: 1, pass: 87
* ltp-cap_bounds-tests - pass: 2
* ltp-containers-tests - skip: 18, pass: 63
* ltp-fcntl-locktests-tests - pass: 2
* ltp-filecaps-tests - pass: 2
* ltp-fs-tests - skip: 5, pass: 58
* ltp-fs_bind-tests - pass: 2
* ltp-fs_perms_simple-tests - pass: 19
* ltp-fsx-tests - pass: 2
* ltp-hugetlb-tests - skip: 2, pass: 20
* ltp-io-tests - pass: 3
* ltp-ipc-tests - pass: 9
* ltp-math-tests - pass: 11
* ltp-nptl-tests - pass: 2
* ltp-pty-tests - pass: 4
* ltp-sched-tests - skip: 1, pass: 13
* ltp-securebits-tests - pass: 4
* ltp-syscalls-tests - skip: 75, pass: 1075
* ltp-timers-tests - pass: 13
x86_64
* boot - fail: 1, pass: 22
* kselftest - skip: 19, fail: 2, pass: 59
* kselftest-vsyscall-mode-native - skip: 19, fail: 2, pass: 59
* kselftest-vsyscall-mode-none - skip: 19, fail: 3, pass: 58
* libhugetlbfs - skip: 1, pass: 90
* ltp-cap_bounds-tests - pass: 2
* ltp-containers-tests - skip: 17, pass: 64
* ltp-fcntl-locktests-tests - pass: 2
* ltp-filecaps-tests - pass: 2
* ltp-fs-tests - skip: 5, pass: 58
* ltp-fs_bind-tests - pass: 2
* ltp-fs_perms_simple-tests - pass: 19
* ltp-fsx-tests - pass: 2
* ltp-hugetlb-tests - pass: 22
* ltp-io-tests - pass: 3
* ltp-ipc-tests - pass: 9
* ltp-math-tests - pass: 11
* ltp-nptl-tests - pass: 2
* ltp-pty-tests - pass: 4
* ltp-sched-tests - skip: 5, pass: 9
* ltp-securebits-tests - pass: 4
* ltp-syscalls-tests - skip: 116, pass: 1034
* ltp-timers-tests - pass: 13
--
Linaro QA (beta)
https://qa-reports.linaro.org
^ permalink raw reply [flat|nested] 58+ messages in thread* Re: [PATCH 4.14 00/49] 4.14.35-stable review
2018-04-17 15:58 [PATCH 4.14 00/49] 4.14.35-stable review Greg Kroah-Hartman
` (51 preceding siblings ...)
2018-04-18 7:27 ` Naresh Kamboju
@ 2018-04-18 15:38 ` Guenter Roeck
52 siblings, 0 replies; 58+ messages in thread
From: Guenter Roeck @ 2018-04-18 15:38 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: linux-kernel, torvalds, akpm, shuahkh, patches, ben.hutchings,
lkft-triage, stable
On Tue, Apr 17, 2018 at 05:58:39PM +0200, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.14.35 release.
> There are 49 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 Apr 19 15:56:59 UTC 2018.
> Anything received after that time might be too late.
>
Build results:
total: 145 pass: 145 fail: 0
Qemu test results:
total: 141 pass: 141 fail: 0
Details are available at http://kerneltests.org/builders.
Guenter
^ permalink raw reply [flat|nested] 58+ messages in thread