4.9.94-stable review

Link http://lkml.kernel.org/r/4b03a961efda5ec9bfe46b7b9c9ad72d1efad343.1493909486.git.jpoimboe@redhat.com open here

Cc netdev <[email protected]>

Cc syzkaller <[email protected]>

Signed-off-by Ingo Molnar <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 arch/x86/lib/csum-copy_64.S |   12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

arch/x86/lib/csum-copy_64.S +6 -6

@@ -55,7 +55,7 @@ ENTRY(csum_partial_copy_generic)
 	movq  %r12, 3*8(%rsp)
 	movq  %r14, 4*8(%rsp)
 	movq  %r13, 5*8(%rsp)
-	movq  %rbp, 6*8(%rsp)
+	movq  %r15, 6*8(%rsp)
 
 	movq  %r8, (%rsp)
 	movq  %r9, 1*8(%rsp)

@@ -74,7 +74,7 @@ ENTRY(csum_partial_copy_generic)
 	/* main loop. clear in 64 byte blocks */
 	/* r9: zero, r8: temp2, rbx: temp1, rax: sum, rcx: saved length */
 	/* r11:	temp3, rdx: temp4, r12 loopcnt */
-	/* r10:	temp5, rbp: temp6, r14 temp7, r13 temp8 */
+	/* r10:	temp5, r15: temp6, r14 temp7, r13 temp8 */
 	.p2align 4
 .Lloop:
 	source

@@ -89,7 +89,7 @@ ENTRY(csum_partial_copy_generic)
 	source
 	movq  32(%rdi), %r10
 	source
-	movq  40(%rdi), %rbp
+	movq  40(%rdi), %r15
 	source
 	movq  48(%rdi), %r14
 	source

@@ -103,7 +103,7 @@ ENTRY(csum_partial_copy_generic)
 	adcq  %r11, %rax
 	adcq  %rdx, %rax
 	adcq  %r10, %rax
-	adcq  %rbp, %rax
+	adcq  %r15, %rax
 	adcq  %r14, %rax
 	adcq  %r13, %rax

@@ -121,7 +121,7 @@ ENTRY(csum_partial_copy_generic)
 	dest
 	movq %r10, 32(%rsi)
 	dest
-	movq %rbp, 40(%rsi)
+	movq %r15, 40(%rsi)
 	dest
 	movq %r14, 48(%rsi)
 	dest

@@ -203,7 +203,7 @@ ENTRY(csum_partial_copy_generic)
 	movq 3*8(%rsp), %r12
 	movq 4*8(%rsp), %r14
 	movq 5*8(%rsp), %r13
-	movq 6*8(%rsp), %rbp
+	movq 6*8(%rsp), %r15
 	addq $7*8, %rsp
 	ret

Greg Kroah-Hartman

author maintainer

2018-04-11 18:32 UTC #8 lore raw

PATCH 8/310 NFSv4.1: RECLAIM_COMPLETE must handle NFS4ERR_CONN_NOT_BOUND_TO_SESSION

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Trond Myklebust <[email protected]>

[ Upstream commit 0048fdd06614a4ea088f9fcad11511956b795698 ]

If the server returns NFS4ERR_CONN_NOT_BOUND_TO_SESSION because we are trunking, then RECLAIM_COMPLETE must handle that by calling nfs4_schedule_session_recovery() and then retrying.

Reported-by Chuck Lever <[email protected]>

Signed-off-by Trond Myklebust <[email protected]>

Tested-by Chuck Lever <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 fs/nfs/nfs4proc.c  |    7 ++++++-
 fs/nfs/nfs4state.c |   10 +++++++---
 2 files changed, 13 insertions(+), 4 deletions(-)

fs/nfs/nfs4proc.c +6 -1

@@ -8173,6 +8173,12 @@ static int nfs41_reclaim_complete_handle
 		/* fall through */
 	case -NFS4ERR_RETRY_UNCACHED_REP:
 		return -EAGAIN;
+	case -NFS4ERR_BADSESSION:
+	case -NFS4ERR_DEADSESSION:
+	case -NFS4ERR_CONN_NOT_BOUND_TO_SESSION:
+		nfs4_schedule_session_recovery(clp->cl_session,
+				task->tk_status);
+		break;
 	default:
 		nfs4_schedule_lease_recovery(clp);
 	}

@@ -8251,7 +8257,6 @@ static int nfs41_proc_reclaim_complete(s
 	if (status == 0)
 		status = task->tk_status;
 	rpc_put_task(task);
-	return 0;
 out:
 	dprintk("<-- %s status=%d\n", __func__, status);
 	return status;

fs/nfs/nfs4state.c +7 -3

@@ -1637,13 +1637,14 @@ static void nfs4_state_start_reclaim_reb
 	nfs4_state_mark_reclaim_helper(clp, nfs4_state_mark_reclaim_reboot);
 }
 
-static void nfs4_reclaim_complete(struct nfs_client *clp,
+static int nfs4_reclaim_complete(struct nfs_client *clp,
 				 const struct nfs4_state_recovery_ops *ops,
 				 struct rpc_cred *cred)
 {
 	/* Notify the server we're done reclaiming our state */
 	if (ops->reclaim_complete)
-		(void)ops->reclaim_complete(clp, cred);
+		return ops->reclaim_complete(clp, cred);
+	return 0;
 }
 
 static void nfs4_clear_reclaim_server(struct nfs_server *server)

@@ -1690,13 +1691,16 @@ static void nfs4_state_end_reclaim_reboo
 {
 	const struct nfs4_state_recovery_ops *ops;
 	struct rpc_cred *cred;
+	int err;
 
 	if (!nfs4_state_clear_reclaim_reboot(clp))
 		return;
 	ops = clp->cl_mvops->reboot_recovery_ops;
 	cred = nfs4_get_clid_cred(clp);
-	nfs4_reclaim_complete(clp, ops, cred);
+	err = nfs4_reclaim_complete(clp, ops, cred);
 	put_rpccred(cred);
+	if (err == -NFS4ERR_CONN_NOT_BOUND_TO_SESSION)
+		set_bit(NFS4CLNT_RECLAIM_REBOOT, &clp->cl_state);
 }
 
 static void nfs4_state_start_reclaim_nograce(struct nfs_client *clp)

Greg Kroah-Hartman

author maintainer

2018-04-11 18:32 UTC #9 lore raw

PATCH 9/310 x86/boot: Declare error() as noreturn

Link http://lkml.kernel.org/r/20170506045116.GA2879@beast open here

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Kees Cook <[email protected]>

[ Upstream commit 60854a12d281e2fa25662fa32ac8022bbff17432 ]

The compressed boot function error() is used to halt execution, but it wasn't marked with "noreturn". This fixes that in preparation for supporting kernel FORTIFY_SOURCE, which uses the noreturn annotation on panic, and calls error(). GCC would warn about a noreturn function calling a non-noreturn function:

arch/x86/boot/compressed/misc.c: In function ‘fortify_panic’:
arch/x86/boot/compressed/misc.c:416:1: warning: ‘noreturn’ function does return
}
^

Signed-off-by Kees Cook <[email protected]>

Cc Daniel Micay <[email protected]>

Cc Linus Torvalds <[email protected]>

Cc Peter Zijlstra <[email protected]>

Cc Thomas Gleixner <[email protected]>

Cc H. Peter Anvin <[email protected]>

Signed-off-by Ingo Molnar <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 arch/x86/boot/compressed/error.h |    4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

arch/x86/boot/compressed/error.h +3 -1

@@ -1,7 +1,9 @@
 #ifndef BOOT_COMPRESSED_ERROR_H
 #define BOOT_COMPRESSED_ERROR_H
 
+#include <linux/compiler.h>
+
 void warn(char *m);
-void error(char *m);
+void error(char *m) __noreturn;
 
 #endif /* BOOT_COMPRESSED_ERROR_H */

Greg Kroah-Hartman

author maintainer

2018-04-11 18:32 UTC #10 lore raw

PATCH 10/310 IB/srpt: Fix abort handling

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Bart Van Assche <[email protected]>

[ Upstream commit 55d694275f41a1c0eef4ef49044ff29bc3999490 ]

Let the target core check the CMD_T_ABORTED flag instead of the SRP target driver. Hence remove the transport_check_aborted_status() call. Since state == SRPT_STATE_CMD_RSP_SENT is something that really should not happen, do not try to recover if srpt_queue_response() is called for an I/O context that is in that state. This patch is a bug fix because the srpt_abort_cmd() call is misplaced - if that function is called from srpt_queue_response() it should either be called before the command state is changed or after the response has been sent.

Signed-off-by Bart Van Assche <[email protected]>

Reviewed-by Hannes Reinecke <[email protected]>

Cc Doug Ledford <[email protected]>

Cc Christoph Hellwig <[email protected]>

Cc Andy Grover <[email protected]>

Cc David Disseldorp <[email protected]>

Signed-off-by Nicholas Bellinger <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/infiniband/ulp/srpt/ib_srpt.c |    6 +-----
 1 file changed, 1 insertion(+), 5 deletions(-)

drivers/infiniband/ulp/srpt/ib_srpt.c +1 -5

@@ -2292,12 +2292,8 @@ static void srpt_queue_response(struct s
 	}
 	spin_unlock_irqrestore(&ioctx->spinlock, flags);
 
-	if (unlikely(transport_check_aborted_status(&ioctx->cmd, false)
-		     || WARN_ON_ONCE(state == SRPT_STATE_CMD_RSP_SENT))) {
-		atomic_inc(&ch->req_lim_delta);
-		srpt_abort_cmd(ioctx);
+	if (unlikely(WARN_ON_ONCE(state == SRPT_STATE_CMD_RSP_SENT)))
 		return;
-	}
 
 	/* For read commands, transfer the data to the initiator. */
 	if (ioctx->cmd.data_direction == DMA_FROM_DEVICE &&

Greg Kroah-Hartman

author maintainer

2018-04-11 18:32 UTC #13 lore raw

PATCH 13/310 mac80211: bail out from prep_connection() if a reconfig is ongoing

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Luca Coelho <[email protected]>

[ Upstream commit f8860ce836f2d502b07ef99559707fe55d90f5bc ]

If ieee80211_hw_restart() is called during authentication, the authentication process will continue, causing the driver to be called in a wrong state. This ultimately causes an oops in the iwlwifi driver (at least).

This fixes bugzilla 195299 partly.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=195299

Signed-off-by Luca Coelho <[email protected]>

Signed-off-by Johannes Berg <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 net/mac80211/mlme.c |    4 ++++
 1 file changed, 4 insertions(+)

net/mac80211/mlme.c +4 -0

@@ -4332,6 +4332,10 @@ static int ieee80211_prep_connection(str
 	if (WARN_ON(!ifmgd->auth_data && !ifmgd->assoc_data))
 		return -EINVAL;
 
+	/* If a reconfig is happening, bail out */
+	if (local->in_reconfig)
+		return -EBUSY;
+
 	if (assoc) {
 		rcu_read_lock();
 		have_sta = sta_info_get(sdata, cbss->bssid);

Greg Kroah-Hartman

author maintainer

2018-04-11 18:32 UTC #18 lore raw

PATCH 18/310 net: cdc_ncm: Fix TX zero padding

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Jim Baxter <[email protected]>

[ Upstream commit aeca3a77b1e0ed06a095933b89c86aed007383eb ]

The zero padding that is added to NTB's does not zero the memory correctly.
This is because the skb_put modifies the value of skb_out->len which results in the memset command not setting any memory to zero as (ctx->tx_max - skb_out->len) == 0.

I have resolved this by storing the size of the memory to be zeroed before the skb_put and using this in the memset call.

Signed-off-by Jim Baxter <[email protected]>

Reviewed-by Bjørn Mork <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/net/usb/cdc_ncm.c |   11 +++++++----
 1 file changed, 7 insertions(+), 4 deletions(-)

drivers/net/usb/cdc_ncm.c +7 -4

@@ -1118,6 +1118,7 @@ cdc_ncm_fill_tx_frame(struct usbnet *dev
 	u16 n = 0, index, ndplen;
 	u8 ready2send = 0;
 	u32 delayed_ndp_size;
+	size_t padding_count;
 
 	/* When our NDP gets written in cdc_ncm_ndp(), then skb_out->len gets updated
 	 * accordingly. Otherwise, we should check here.

@@ -1274,11 +1275,13 @@ cdc_ncm_fill_tx_frame(struct usbnet *dev
 	 * a ZLP after full sized NTBs.
 	 */
 	if (!(dev->driver_info->flags & FLAG_SEND_ZLP) &&
-	    skb_out->len > ctx->min_tx_pkt)
-		memset(skb_put(skb_out, ctx->tx_max - skb_out->len), 0,
-		       ctx->tx_max - skb_out->len);
-	else if (skb_out->len < ctx->tx_max && (skb_out->len % dev->maxpacket) == 0)
+	    skb_out->len > ctx->min_tx_pkt) {
+		padding_count = ctx->tx_max - skb_out->len;
+		memset(skb_put(skb_out, padding_count), 0, padding_count);
+	} else if (skb_out->len < ctx->tx_max &&
+		   (skb_out->len % dev->maxpacket) == 0) {
 		*skb_put(skb_out, 1) = 0;	/* force short packet */
+	}
 
 	/* set final frame length */
 	nth16 = (struct usb_cdc_ncm_nth16 *)skb_out->data;

Greg Kroah-Hartman

author maintainer

2018-04-11 18:32 UTC #19 lore raw

PATCH 19/310 net: ethernet: ti: cpsw: adjust cpsw fifos depth for fullduplex flow control

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Grygorii Strashko <[email protected]>

[ Upstream commit 48f5bccc60675f8426a6159935e8636a1fd89f56 ]

When users set flow control using ethtool the bits are set properly in the CPGMAC_SL MACCONTROL register, but the FIFO depth in the respective Port n Maximum FIFO Blocks (Pn_MAX_BLKS) registers remains set to the minimum size reset value. When receive flow control is enabled on a port, the port's associated FIFO block allocation must be adjusted. The port RX allocation must increase to accommodate the flow control runout. The TRM recommends numbers of 5 or 6.

Hence, apply required Port FIFO configuration to Pn_MAX_BLKS.Pn_TX_MAX_BLKS=0xF and Pn_MAX_BLKS.Pn_RX_MAX_BLKS=0x5 during interface initialization.

Cc Schuyler Patton <[email protected]>

Signed-off-by Grygorii Strashko <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/net/ethernet/ti/cpsw.c |   16 ++++++++++++++++
 1 file changed, 16 insertions(+)

drivers/net/ethernet/ti/cpsw.c +16 -0

@@ -282,6 +282,10 @@ struct cpsw_ss_regs {
 /* Bit definitions for the CPSW1_TS_SEQ_LTYPE register */
 #define CPSW_V1_SEQ_ID_OFS_SHIFT	16
 
+#define CPSW_MAX_BLKS_TX		15
+#define CPSW_MAX_BLKS_TX_SHIFT		4
+#define CPSW_MAX_BLKS_RX		5
+
 struct cpsw_host_regs {
 	u32	max_blks;
 	u32	blk_cnt;

@@ -1160,11 +1164,23 @@ static void cpsw_slave_open(struct cpsw_
 	switch (cpsw->version) {
 	case CPSW_VERSION_1:
 		slave_write(slave, TX_PRIORITY_MAPPING, CPSW1_TX_PRI_MAP);
+		/* Increase RX FIFO size to 5 for supporting fullduplex
+		 * flow control mode
+		 */
+		slave_write(slave,
+			    (CPSW_MAX_BLKS_TX << CPSW_MAX_BLKS_TX_SHIFT) |
+			    CPSW_MAX_BLKS_RX, CPSW1_MAX_BLKS);
 		break;
 	case CPSW_VERSION_2:
 	case CPSW_VERSION_3:
 	case CPSW_VERSION_4:
 		slave_write(slave, TX_PRIORITY_MAPPING, CPSW2_TX_PRI_MAP);
+		/* Increase RX FIFO size to 5 for supporting fullduplex
+		 * flow control mode
+		 */
+		slave_write(slave,
+			    (CPSW_MAX_BLKS_TX << CPSW_MAX_BLKS_TX_SHIFT) |
+			    CPSW_MAX_BLKS_RX, CPSW2_MAX_BLKS);
 		break;
 	}

Greg Kroah-Hartman

author maintainer

2018-04-11 18:32 UTC #21 lore raw

PATCH 21/310 drivers/misc/vmw_vmci/vmci_queue_pair.c: fix a couple integer overflow tests

Link http://lkml.kernel.org/r/20170322111950.GA11279@mwanda open here

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Dan Carpenter <[email protected]>

[ Upstream commit 146180c052a00172f4dc08eaade836fd02f61fb5 ]

The "DIV_ROUND_UP(size, PAGE_SIZE)" operation can overflow if "size" is more than ULLONG_MAX - PAGE_SIZE.

Cc Jorgen Hansen <[email protected]>

Cc Masahiro Yamada <[email protected]>

Cc Michal Hocko <[email protected]>

Cc Greg Kroah-Hartman <[email protected]>

Signed-off-by Andrew Morton <[email protected]>

Signed-off-by Linus Torvalds <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/misc/vmw_vmci/vmci_queue_pair.c |   10 ++++++++--
 1 file changed, 8 insertions(+), 2 deletions(-)

drivers/misc/vmw_vmci/vmci_queue_pair.c +8 -2

@@ -298,8 +298,11 @@ static void *qp_alloc_queue(u64 size, u3
 	size_t pas_size;
 	size_t vas_size;
 	size_t queue_size = sizeof(*queue) + sizeof(*queue->kernel_if);
-	const u64 num_pages = DIV_ROUND_UP(size, PAGE_SIZE) + 1;
+	u64 num_pages;
 
+	if (size > SIZE_MAX - PAGE_SIZE)
+		return NULL;
+	num_pages = DIV_ROUND_UP(size, PAGE_SIZE) + 1;
 	if (num_pages >
 		 (SIZE_MAX - queue_size) /
 		 (sizeof(*queue->kernel_if->u.g.pas) +

@@ -624,9 +627,12 @@ static struct vmci_queue *qp_host_alloc_
 {
 	struct vmci_queue *queue;
 	size_t queue_page_size;
-	const u64 num_pages = DIV_ROUND_UP(size, PAGE_SIZE) + 1;
+	u64 num_pages;
 	const size_t queue_size = sizeof(*queue) + sizeof(*(queue->kernel_if));
 
+	if (size > SIZE_MAX - PAGE_SIZE)
+		return NULL;
+	num_pages = DIV_ROUND_UP(size, PAGE_SIZE) + 1;
 	if (num_pages > (SIZE_MAX - queue_size) /
 		 sizeof(*queue->kernel_if->u.h.page))
 		return NULL;

Greg Kroah-Hartman

author maintainer

2018-04-11 18:32 UTC #22 lore raw

PATCH 22/310 pidns: disable pid allocation if pid_ns_prepare_proc() is failed in alloc_pid()

Link http://lkml.kernel.org/r/149201021004.4863.6762095011554287922.stgit@localhost.localdomain open here

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Kirill Tkhai <[email protected]>

[ Upstream commit 8896c23d2ef803f1883fea73117a435925c2b4c4 ]

alloc_pidmap() advances pid_namespace::last_pid. When first pid allocation fails, then next created process will have pid 2 and pid_ns_prepare_proc() won't be called. So, pid_namespace::proc_mnt will never be initialized (not to mention that there won't be a child reaper).

I saw crash stack of such case on kernel 3.10:

    BUG: unable to handle kernel NULL pointer dereference at (null)
    IP: proc_flush_task+0x8f/0x1b0
    Call Trace:
        release_task+0x3f/0x490
        wait_consider_task.part.10+0x7ff/0xb00
        do_wait+0x11f/0x280
        SyS_wait4+0x7d/0x110

We may fix this by restore of last_pid in 0 or by prohibiting of futher allocations. Since there was a similar issue in Oleg Nesterov's commit 314a8ad0f18a ("pidns: fix free_pid() to handle the first fork failure"). and it was fixed via prohibiting allocation, let's follow this way, and do the same.

Signed-off-by Kirill Tkhai <[email protected]>

Acked-by Cyrill Gorcunov <[email protected]>

Cc Andrei Vagin <[email protected]>

Cc Andreas Gruenbacher <[email protected]>

Cc Kees Cook <[email protected]>

Cc Michael Kerrisk <[email protected]>

Cc Al Viro <[email protected]>

Cc Oleg Nesterov <[email protected]>

Cc Paul Moore <[email protected]>

Cc Eric Biederman <[email protected]>

Cc Andy Lutomirski <[email protected]>

Cc Ingo Molnar <[email protected]>

Cc Serge Hallyn <[email protected]>

Signed-off-by Andrew Morton <[email protected]>

Signed-off-by Linus Torvalds <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 kernel/pid.c |    4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

kernel/pid.c +3 -1

@@ -322,8 +322,10 @@ struct pid *alloc_pid(struct pid_namespa
 	}
 
 	if (unlikely(is_child_reaper(pid))) {
-		if (pid_ns_prepare_proc(ns))
+		if (pid_ns_prepare_proc(ns)) {
+			disable_pid_allocation(ns);
 			goto out_free;
+		}
 	}
 
 	get_pid_ns(ns);

Greg Kroah-Hartman

author maintainer

2018-04-11 18:32 UTC #25 lore raw

PATCH 23/310 s390: move _text symbol to address higher than zero

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Heiko Carstens <[email protected]>

[ Upstream commit d04a4c76f71dd5335f8e499b59617382d84e2b8d ]

The perf tool assumes that kernel symbols are never present at address zero. In fact it assumes if functions that map symbols to addresses return zero, that the symbol was not found.

Given that s390's _text symbol historically is located at address zero this yields at least a couple of false errors and warnings in one of perf's test cases about not present symbols ("perf test 1").

To fix this simply move the _text symbol to address 0x200, just behind the initial psw and channel program located at the beginning of the kernel image. This is now hard coded within the linker script.

I tried a nicer solution which moves the initial psw and channel program into an own section. However that would move the symbols within the "real" head.text section to different addresses, since the ".org" statements within head.S are relative to the head.text section. If there is a new section in front, everything else will be moved. Alternatively I could have adjusted all ".org" statements. But this current solution seems to be the easiest one, since nobody really cares where the _text symbol is actually located.

Reported-by Zvonko Kosic <[email protected]>

Signed-off-by Heiko Carstens <[email protected]>

Signed-off-by Martin Schwidefsky <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 arch/s390/kernel/vmlinux.lds.S |    8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)

arch/s390/kernel/vmlinux.lds.S +7 -1

@@ -31,8 +31,14 @@ SECTIONS
 {
 	. = 0x00000000;
 	.text : {
-	_text = .;		/* Text and read-only data */
+		/* Text and read-only data */
 		HEAD_TEXT
+		/*
+		 * E.g. perf doesn't like symbols starting at address zero,
+		 * therefore skip the initial PSW and channel program located
+		 * at address zero and let _text start at 0x200.
+		 */
+	_text = 0x200;
 		TEXT_TEXT
 		SCHED_TEXT
 		CPUIDLE_TEXT

Greg Kroah-Hartman

author maintainer

2018-04-11 18:32 UTC #28 lore raw

PATCH 26/310 NFSv4.1: Work around a Linux server bug...

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Trond Myklebust <[email protected]>

[ Upstream commit f4b23de3dda1536590787c9e5c3d16b8738ab108 ]

It turns out the Linux server has a bug in its implementation of supattr_exclcreat; it returns the set of all attributes, whether or not they are supported by minor version 1.
In order to avoid a regression, we therefore apply the supported_attrs as a mask on top of whatever the server sent us.

Reported-by Anna Schumaker <[email protected]>

Signed-off-by Trond Myklebust <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 fs/nfs/nfs4proc.c |    6 ++++++
 1 file changed, 6 insertions(+)

fs/nfs/nfs4proc.c +6 -0

@@ -3300,6 +3300,7 @@ static int _nfs4_server_capabilities(str
 		.rpc_resp = &res,
 	};
 	int status;
+	int i;
 
 	bitmask[0] = FATTR4_WORD0_SUPPORTED_ATTRS |
 		     FATTR4_WORD0_FH_EXPIRE_TYPE |

@@ -3365,8 +3366,13 @@ static int _nfs4_server_capabilities(str
 		server->cache_consistency_bitmask[0] &= FATTR4_WORD0_CHANGE|FATTR4_WORD0_SIZE;
 		server->cache_consistency_bitmask[1] &= FATTR4_WORD1_TIME_METADATA|FATTR4_WORD1_TIME_MODIFY;
 		server->cache_consistency_bitmask[2] = 0;
+
+		/* Avoid a regression due to buggy server */
+		for (i = 0; i < ARRAY_SIZE(res.exclcreat_bitmask); i++)
+			res.exclcreat_bitmask[i] &= res.attr_bitmask[i];
 		memcpy(server->exclcreat_bitmask, res.exclcreat_bitmask,
 			sizeof(server->exclcreat_bitmask));
+
 		server->acl_bitmask = res.acl_bitmask;
 		server->fh_expire_type = res.fh_expire_type;
 	}

Greg Kroah-Hartman

author maintainer

2018-04-11 18:32 UTC #30 lore raw

PATCH 28/310 perf/callchain: Force USER_DS when invoking perf_callchain_user()

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Will Deacon <[email protected]>

[ Upstream commit 88b0193d9418c00340e45e0a913a0813bc6c8c96 ]

Perf can generate and record a user callchain in response to a synchronous request, such as a tracepoint firing. If this happens under set_fs(KERNEL_DS), then we can end up walking the user stack (and dereferencing/saving whatever we find there) without the protections usually afforded by checks such as access_ok.

Rather than play whack-a-mole with each architecture's stack unwinding implementation, fix the root of the problem by ensuring that we force USER_DS when invoking perf_callchain_user from the perf core.

Reported-by Al Viro <[email protected]>

Signed-off-by Will Deacon <[email protected]>

Acked-by Peter Zijlstra <[email protected]>

Cc Alexander Shishkin <[email protected]>

Cc Arnaldo Carvalho de Melo <[email protected]>

Cc Jiri Olsa <[email protected]>

Cc Linus Torvalds <[email protected]>

Cc Thomas Gleixner <[email protected]>

Signed-off-by Ingo Molnar <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 kernel/events/callchain.c |    6 ++++++
 1 file changed, 6 insertions(+)

kernel/events/callchain.c +6 -0

@@ -227,12 +227,18 @@ get_perf_callchain(struct pt_regs *regs,
 		}
 
 		if (regs) {
+			mm_segment_t fs;
+
 			if (crosstask)
 				goto exit_put;
 
 			if (add_mark)
 				perf_callchain_store_context(&ctx, PERF_CONTEXT_USER);
+
+			fs = get_fs();
+			set_fs(USER_DS);
 			perf_callchain_user(&ctx, regs);
+			set_fs(fs);
 		}
 	}

Greg Kroah-Hartman

author maintainer

2018-04-11 18:32 UTC #32 lore raw

PATCH 30/310 net: qca_spi: Fix alignment issues in rx path

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Stefan Wahren <[email protected]>

[ Upstream commit 8d66c30b12ed3cb533696dea8b9a9eadd5da426a ]

The qca_spi driver causes alignment issues on ARM devices. So fix this by using netdev_alloc_skb_ip_align().

Signed-off-by Stefan Wahren <[email protected]>

Fixes 291ab06ecf67 ("net: qualcomm: new Ethernet over SPI driver for QCA7000")

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/net/ethernet/qualcomm/qca_spi.c |   10 ++++++----
 1 file changed, 6 insertions(+), 4 deletions(-)

drivers/net/ethernet/qualcomm/qca_spi.c +6 -4

@@ -296,8 +296,9 @@ qcaspi_receive(struct qcaspi *qca)
 
 	/* Allocate rx SKB if we don't have one available. */
 	if (!qca->rx_skb) {
-		qca->rx_skb = netdev_alloc_skb(net_dev,
-					       net_dev->mtu + VLAN_ETH_HLEN);
+		qca->rx_skb = netdev_alloc_skb_ip_align(net_dev,
+							net_dev->mtu +
+							VLAN_ETH_HLEN);
 		if (!qca->rx_skb) {
 			netdev_dbg(net_dev, "out of RX resources\n");
 			qca->stats.out_of_mem++;

@@ -377,7 +378,7 @@ qcaspi_receive(struct qcaspi *qca)
 					qca->rx_skb, qca->rx_skb->dev);
 				qca->rx_skb->ip_summed = CHECKSUM_UNNECESSARY;
 				netif_rx_ni(qca->rx_skb);
-				qca->rx_skb = netdev_alloc_skb(net_dev,
+				qca->rx_skb = netdev_alloc_skb_ip_align(net_dev,
 					net_dev->mtu + VLAN_ETH_HLEN);
 				if (!qca->rx_skb) {
 					netdev_dbg(net_dev, "out of RX resources\n");

@@ -759,7 +760,8 @@ qcaspi_netdev_init(struct net_device *de
 	if (!qca->rx_buffer)
 		return -ENOBUFS;
 
-	qca->rx_skb = netdev_alloc_skb(dev, qca->net_dev->mtu + VLAN_ETH_HLEN);
+	qca->rx_skb = netdev_alloc_skb_ip_align(dev, qca->net_dev->mtu +
+						VLAN_ETH_HLEN);
 	if (!qca->rx_skb) {
 		kfree(qca->rx_buffer);
 		netdev_info(qca->net_dev, "Failed to allocate RX sk_buff.\n");

Greg Kroah-Hartman

author maintainer

2018-04-11 18:32 UTC #35 lore raw

PATCH 33/310 Input: elan_i2c - check if device is there before really probing

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Dmitry Torokhov <[email protected]>

[ Upstream commit c5928551fd41b2eecdad78fa2be2a4a13ed5fde9 ]

Before trying to properly initialize the touchpad and generate bunch of errors, let's first see it there is anything at the given address. If we get error, fail silently with -ENXIO.

Reviewed-by Guenter Roeck <[email protected]>

Signed-off-by Dmitry Torokhov <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/input/mouse/elan_i2c_core.c |    7 +++++++
 1 file changed, 7 insertions(+)

drivers/input/mouse/elan_i2c_core.c +7 -0

@@ -1082,6 +1082,13 @@ static int elan_probe(struct i2c_client
 		return error;
 	}
 
+	/* Make sure there is something at this address */
+	error = i2c_smbus_read_byte(client);
+	if (error < 0) {
+		dev_dbg(&client->dev, "nothing at this address: %d\n", error);
+		return -ENXIO;
+	}
+
 	/* Initialize the touchpad. */
 	error = elan_initialize(data);
 	if (error)

Greg Kroah-Hartman

author maintainer

2018-04-11 18:32 UTC #36 lore raw

PATCH 34/310 Input: elantech - force relative mode on a certain module

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: KT Liao <[email protected]>

[ Upstream commit d899520b0431e70279bfb5066ecb6dc91d0b7072 ]

One of Elan modules with sample version is 0x74 and hw_version is 0x03 has a bug in absolute mode implementation, so let it run in default PS/2 relative mode.

Signed-off-by KT Liao <[email protected]>

Signed-off-by Dmitry Torokhov <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/input/mouse/elantech.c |   11 +++++++++++
 1 file changed, 11 insertions(+)

drivers/input/mouse/elantech.c +11 -0

@@ -1711,6 +1711,17 @@ int elantech_init(struct psmouse *psmous
 			     etd->samples[0], etd->samples[1], etd->samples[2]);
 	}
 
+	if (etd->samples[1] == 0x74 && etd->hw_version == 0x03) {
+		/*
+		 * This module has a bug which makes absolute mode
+		 * unusable, so let's abort so we'll be using standard
+		 * PS/2 protocol.
+		 */
+		psmouse_info(psmouse,
+			     "absolute mode broken, forcing standard PS/2 protocol\n");
+		goto init_fail;
+	}
+
 	if (elantech_set_absolute_mode(psmouse)) {
 		psmouse_err(psmouse,
 			    "failed to put touchpad into absolute mode.\n");

Greg Kroah-Hartman

author maintainer

2018-04-11 18:32 UTC #37 lore raw

PATCH 35/310 KVM: PPC: Book3S PR: Check copy_to/from_user return values

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Paul Mackerras <[email protected]>

[ Upstream commit 67325e988faea735d663799b6d152b5f4254093c ]

The PR KVM implementation of the PAPR HPT hypercalls (H_ENTER etc.) access an image of the HPT in userspace memory using copy_from_user and copy_to_user. Recently, the declarations of those functions were annotated to indicate that the return value must be checked. Since this code doesn't currently check the return value, this causes compile warnings like the ones shown below, and since on PPC the default is to compile arch/powerpc with -Werror, this causes the build to fail.

To fix this, we check the return values, and if non-zero, fail the hypercall being processed with a H_FUNCTION error return value. There is really no good error return value to use since PAPR didn't envisage the possibility that the hypervisor may not be able to access the guest's HPT, and H_FUNCTION (function not supported) seems as good as any.

The typical compile warnings look like this:

CC arch/powerpc/kvm/book3s_pr_papr.o
/home/paulus/kernel/kvm/arch/powerpc/kvm/book3s_pr_papr.c: In function ‘kvmppc_h_pr_enter’:
/home/paulus/kernel/kvm/arch/powerpc/kvm/book3s_pr_papr.c:53:2: error: ignoring return value of ‘copy_from_user’, declared with attribute warn_unused_result [-Werror=unused-result]
copy_from_user(pteg, (void __user *)pteg_addr, sizeof(pteg));
^
/home/paulus/kernel/kvm/arch/powerpc/kvm/book3s_pr_papr.c:74:2: error: ignoring return value of ‘copy_to_user’, declared with attribute warn_unused_result [-Werror=unused-result]
copy_to_user((void __user *)pteg_addr, hpte, HPTE_SIZE);
^

... etc.

Signed-off-by Paul Mackerras <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 arch/powerpc/kvm/book3s_pr_papr.c |   34 ++++++++++++++++++++++++++--------
 1 file changed, 26 insertions(+), 8 deletions(-)

arch/powerpc/kvm/book3s_pr_papr.c +26 -8

@@ -50,7 +50,9 @@ static int kvmppc_h_pr_enter(struct kvm_
 	pteg_addr = get_pteg_addr(vcpu, pte_index);
 
 	mutex_lock(&vcpu->kvm->arch.hpt_mutex);
-	copy_from_user(pteg, (void __user *)pteg_addr, sizeof(pteg));
+	ret = H_FUNCTION;
+	if (copy_from_user(pteg, (void __user *)pteg_addr, sizeof(pteg)))
+		goto done;
 	hpte = pteg;
 
 	ret = H_PTEG_FULL;

@@ -71,7 +73,9 @@ static int kvmppc_h_pr_enter(struct kvm_
 	hpte[0] = cpu_to_be64(kvmppc_get_gpr(vcpu, 6));
 	hpte[1] = cpu_to_be64(kvmppc_get_gpr(vcpu, 7));
 	pteg_addr += i * HPTE_SIZE;
-	copy_to_user((void __user *)pteg_addr, hpte, HPTE_SIZE);
+	ret = H_FUNCTION;
+	if (copy_to_user((void __user *)pteg_addr, hpte, HPTE_SIZE))
+		goto done;
 	kvmppc_set_gpr(vcpu, 4, pte_index | i);
 	ret = H_SUCCESS;

@@ -93,7 +97,9 @@ static int kvmppc_h_pr_remove(struct kvm
 
 	pteg = get_pteg_addr(vcpu, pte_index);
 	mutex_lock(&vcpu->kvm->arch.hpt_mutex);
-	copy_from_user(pte, (void __user *)pteg, sizeof(pte));
+	ret = H_FUNCTION;
+	if (copy_from_user(pte, (void __user *)pteg, sizeof(pte)))
+		goto done;
 	pte[0] = be64_to_cpu((__force __be64)pte[0]);
 	pte[1] = be64_to_cpu((__force __be64)pte[1]);

@@ -103,7 +109,9 @@ static int kvmppc_h_pr_remove(struct kvm
 	    ((flags & H_ANDCOND) && (pte[0] & avpn) != 0))
 		goto done;
 
-	copy_to_user((void __user *)pteg, &v, sizeof(v));
+	ret = H_FUNCTION;
+	if (copy_to_user((void __user *)pteg, &v, sizeof(v)))
+		goto done;
 
 	rb = compute_tlbie_rb(pte[0], pte[1], pte_index);
 	vcpu->arch.mmu.tlbie(vcpu, rb, rb & 1 ? true : false);

@@ -171,7 +179,10 @@ static int kvmppc_h_pr_bulk_remove(struc
 		}
 
 		pteg = get_pteg_addr(vcpu, tsh & H_BULK_REMOVE_PTEX);
-		copy_from_user(pte, (void __user *)pteg, sizeof(pte));
+		if (copy_from_user(pte, (void __user *)pteg, sizeof(pte))) {
+			ret = H_FUNCTION;
+			break;
+		}
 		pte[0] = be64_to_cpu((__force __be64)pte[0]);
 		pte[1] = be64_to_cpu((__force __be64)pte[1]);

@@ -184,7 +195,10 @@ static int kvmppc_h_pr_bulk_remove(struc
 			tsh |= H_BULK_REMOVE_NOT_FOUND;
 		} else {
 			/* Splat the pteg in (userland) hpt */
-			copy_to_user((void __user *)pteg, &v, sizeof(v));
+			if (copy_to_user((void __user *)pteg, &v, sizeof(v))) {
+				ret = H_FUNCTION;
+				break;
+			}
 
 			rb = compute_tlbie_rb(pte[0], pte[1],
 					      tsh & H_BULK_REMOVE_PTEX);

@@ -211,7 +225,9 @@ static int kvmppc_h_pr_protect(struct kv
 
 	pteg = get_pteg_addr(vcpu, pte_index);
 	mutex_lock(&vcpu->kvm->arch.hpt_mutex);
-	copy_from_user(pte, (void __user *)pteg, sizeof(pte));
+	ret = H_FUNCTION;
+	if (copy_from_user(pte, (void __user *)pteg, sizeof(pte)))
+		goto done;
 	pte[0] = be64_to_cpu((__force __be64)pte[0]);
 	pte[1] = be64_to_cpu((__force __be64)pte[1]);

@@ -234,7 +250,9 @@ static int kvmppc_h_pr_protect(struct kv
 	vcpu->arch.mmu.tlbie(vcpu, rb, rb & 1 ? true : false);
 	pte[0] = (__force u64)cpu_to_be64(pte[0]);
 	pte[1] = (__force u64)cpu_to_be64(pte[1]);
-	copy_to_user((void __user *)pteg, pte, sizeof(pte));
+	ret = H_FUNCTION;
+	if (copy_to_user((void __user *)pteg, pte, sizeof(pte)))
+		goto done;
 	ret = H_SUCCESS;
 
  done:

Greg Kroah-Hartman

author maintainer

2018-04-11 18:32 UTC #38 lore raw

PATCH 36/310 irqchip/mbigen: Fix the clear register offset calculation

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: MaJun <[email protected]>

[ Upstream commit 9459a04b6a5a09967eec94a1b66f0a74312819d9 ]

The register array offset for clearing an interrupt is calculated by:

    offset = (hwirq - RESERVED_IRQ_PER_MBIGEN_CHIP) / 32;

This is wrong because the clear register array includes the reserved interrupts. So the clear operation ends up in the wrong register.

This went unnoticed so far, because the hardware clears the real bit through a timeout mechanism when the hardware is configured in debug mode. That debug mode was enabled on early generations of the hardware, so the problem was papered over.

On newer hardware with updated firmware the debug mode was disabled, so the bits did not get cleared which causes the system to malfunction.

Remove the subtraction of RESERVED_IRQ_PER_MBIGEN_CHIP, so the correct register is accessed.

[ tglx: Rewrote changelog ]

Fixes a6c2f87b8820 ("irqchip/mbigen: Implement the mbigen irq chip operation functions")

Signed-off-by MaJun <[email protected]>

Signed-off-by Hanjun Guo <[email protected]>

Acked-by Marc Zyngier <[email protected]>

Cc Kefeng Wang <[email protected]>

Cc Wei Yongjun <[email protected]>

Link http://lkml.kernel.org/r/[email protected] open here

Signed-off-by Thomas Gleixner <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/irqchip/irq-mbigen.c |    5 +----
 1 file changed, 1 insertion(+), 4 deletions(-)

drivers/irqchip/irq-mbigen.c +1 -4

@@ -105,10 +105,7 @@ static inline void get_mbigen_type_reg(i
 static inline void get_mbigen_clear_reg(irq_hw_number_t hwirq,
 					u32 *mask, u32 *addr)
 {
-	unsigned int ofst;
-
-	hwirq -= RESERVED_IRQ_PER_MBIGEN_CHIP;
-	ofst = hwirq / 32 * 4;
+	unsigned int ofst = (hwirq / 32) * 4;
 
 	*mask = 1 << (hwirq % 32);
 	*addr = ofst + REG_MBIGEN_CLEAR_OFFSET;

Greg Kroah-Hartman

author maintainer

2018-04-11 18:32 UTC #39 lore raw

PATCH 37/310 vmxnet3: ensure that adapter is in proper state during force_close

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Neil Horman <[email protected]>

[ Upstream commit 1c4d5f51a812a82de97beee24f48ed05c65ebda5 ]

There are several paths in vmxnet3, where settings changes cause the adapter to be brought down and back up (vmxnet3_set_ringparam among them). Should part of the reset operation fail, these paths call vmxnet3_force_close, which enables all napi instances prior to calling dev_close (with the expectation that vmxnet3_close will then properly disable them again). However, vmxnet3_force_close neglects to clear VMXNET3_STATE_BIT_QUIESCED prior to calling dev_close. As a result vmxnet3_quiesce_dev (called from vmxnet3_close), returns early, and leaves all the napi instances in a enabled state while the device itself is closed. If a device in this state is activated again, napi_enable will be called on already enabled napi_instances, leading to a BUG halt.

The fix is to simply enausre that the QUIESCED bit is cleared in vmxnet3_force_close to allow quesence to be completed properly on close.

Signed-off-by Neil Horman <[email protected]>

CC Shrikrishna Khare <[email protected]>

CC "VMware, Inc." <[email protected]>

CC "David S. Miller" <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/net/vmxnet3/vmxnet3_drv.c |    5 +++++
 1 file changed, 5 insertions(+)

drivers/net/vmxnet3/vmxnet3_drv.c +5 -0

@@ -2962,6 +2962,11 @@ vmxnet3_force_close(struct vmxnet3_adapt
 	/* we need to enable NAPI, otherwise dev_close will deadlock */
 	for (i = 0; i < adapter->num_rx_queues; i++)
 		napi_enable(&adapter->rx_queue[i].napi);
+	/*
+	 * Need to clear the quiesce bit to ensure that vmxnet3_close
+	 * can quiesce the device properly
+	 */
+	clear_bit(VMXNET3_STATE_BIT_QUIESCED, &adapter->state);
 	dev_close(adapter->netdev);
 }

Greg Kroah-Hartman

author maintainer

2018-04-11 18:32 UTC #42 lore raw

PATCH 40/310 bus: brcmstb_gisb: Use register offsets with writes too

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Doug Berger <[email protected]>

[ Upstream commit 856c7ccb9ce7a061f04bdf586f649cb93654e294 ]

This commit corrects the bug introduced in commit f80835875d3d ("bus: brcmstb_gisb: Look up register offsets in a table") such that gisb_write() translates the register enumeration into an offset from the base address for writes as well as reads.

Fixes f80835875d3d ("bus: brcmstb_gisb: Look up register offsets in a table")

Signed-off-by Doug Berger <[email protected]>

Acked-by Gregory Fong <[email protected]>

Signed-off-by Florian Fainelli <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/bus/brcmstb_gisb.c |    6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

drivers/bus/brcmstb_gisb.c +3 -3

@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2014 Broadcom Corporation
+ * Copyright (C) 2014-2017 Broadcom
  *
  * This program is free software; you can redistribute it and/or modify
  * it under the terms of the GNU General Public License version 2 as

@@ -127,9 +127,9 @@ static void gisb_write(struct brcmstb_gi
 		return;
 
 	if (gdev->big_endian)
-		iowrite32be(val, gdev->base + reg);
+		iowrite32be(val, gdev->base + offset);
 	else
-		iowrite32(val, gdev->base + reg);
+		iowrite32(val, gdev->base + offset);
 }
 
 static ssize_t gisb_arb_get_timeout(struct device *dev,

Greg Kroah-Hartman

author maintainer

2018-04-11 18:33 UTC #43 lore raw

PATCH 41/310 bus: brcmstb_gisb: correct support for 64-bit address output

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Doug Berger <[email protected]>

[ Upstream commit 0c2aa0e4b308815e877601845c1a89913f9bd2b9 ]

The GISB bus can support addresses beyond 32-bits. So this commit corrects support for reading a captured 64-bit address into a 64-bit variable by obtaining the high bits from the ARB_ERR_CAP_HI_ADDR register (when present) and then outputting the full 64-bit value.

It also removes unused definitions.

Fixes 44127b771d9c ("bus: add Broadcom GISB bus arbiter timeout/error handler")

Signed-off-by Doug Berger <[email protected]>

Acked-by Gregory Fong <[email protected]>

Signed-off-by Florian Fainelli <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/bus/brcmstb_gisb.c |   36 ++++++++++++++++++++----------------
 1 file changed, 20 insertions(+), 16 deletions(-)

drivers/bus/brcmstb_gisb.c +20 ~~-16~~

@@ -37,8 +37,6 @@
 #define  ARB_ERR_CAP_CLEAR		(1 << 0)
 #define  ARB_ERR_CAP_STATUS_TIMEOUT	(1 << 12)
 #define  ARB_ERR_CAP_STATUS_TEA		(1 << 11)
-#define  ARB_ERR_CAP_STATUS_BS_SHIFT	(1 << 2)
-#define  ARB_ERR_CAP_STATUS_BS_MASK	0x3c
 #define  ARB_ERR_CAP_STATUS_WRITE	(1 << 1)
 #define  ARB_ERR_CAP_STATUS_VALID	(1 << 0)

@@ -47,7 +45,6 @@ enum {
 	ARB_ERR_CAP_CLR,
 	ARB_ERR_CAP_HI_ADDR,
 	ARB_ERR_CAP_ADDR,
-	ARB_ERR_CAP_DATA,
 	ARB_ERR_CAP_STATUS,
 	ARB_ERR_CAP_MASTER,
 };

@@ -57,7 +54,6 @@ static const int gisb_offsets_bcm7038[]
 	[ARB_ERR_CAP_CLR]	= 0x0c4,
 	[ARB_ERR_CAP_HI_ADDR]	= -1,
 	[ARB_ERR_CAP_ADDR]	= 0x0c8,
-	[ARB_ERR_CAP_DATA]	= 0x0cc,
 	[ARB_ERR_CAP_STATUS]	= 0x0d0,
 	[ARB_ERR_CAP_MASTER]	= -1,
 };

@@ -67,7 +63,6 @@ static const int gisb_offsets_bcm7400[]
 	[ARB_ERR_CAP_CLR]	= 0x0c8,
 	[ARB_ERR_CAP_HI_ADDR]	= -1,
 	[ARB_ERR_CAP_ADDR]	= 0x0cc,
-	[ARB_ERR_CAP_DATA]	= 0x0d0,
 	[ARB_ERR_CAP_STATUS]	= 0x0d4,
 	[ARB_ERR_CAP_MASTER]	= 0x0d8,
 };

@@ -77,7 +72,6 @@ static const int gisb_offsets_bcm7435[]
 	[ARB_ERR_CAP_CLR]	= 0x168,
 	[ARB_ERR_CAP_HI_ADDR]	= -1,
 	[ARB_ERR_CAP_ADDR]	= 0x16c,
-	[ARB_ERR_CAP_DATA]	= 0x170,
 	[ARB_ERR_CAP_STATUS]	= 0x174,
 	[ARB_ERR_CAP_MASTER]	= 0x178,
 };

@@ -87,7 +81,6 @@ static const int gisb_offsets_bcm7445[]
 	[ARB_ERR_CAP_CLR]	= 0x7e4,
 	[ARB_ERR_CAP_HI_ADDR]	= 0x7e8,
 	[ARB_ERR_CAP_ADDR]	= 0x7ec,
-	[ARB_ERR_CAP_DATA]	= 0x7f0,
 	[ARB_ERR_CAP_STATUS]	= 0x7f4,
 	[ARB_ERR_CAP_MASTER]	= 0x7f8,
 };

@@ -109,9 +102,13 @@ static u32 gisb_read(struct brcmstb_gisb
 {
 	int offset = gdev->gisb_offsets[reg];
 
-	/* return 1 if the hardware doesn't have ARB_ERR_CAP_MASTER */
-	if (offset == -1)
-		return 1;
+	if (offset < 0) {
+		/* return 1 if the hardware doesn't have ARB_ERR_CAP_MASTER */
+		if (reg == ARB_ERR_CAP_MASTER)
+			return 1;
+		else
+			return 0;
+	}
 
 	if (gdev->big_endian)
 		return ioread32be(gdev->base + offset);

@@ -119,6 +116,16 @@ static u32 gisb_read(struct brcmstb_gisb
 		return ioread32(gdev->base + offset);
 }
 
+static u64 gisb_read_address(struct brcmstb_gisb_arb_device *gdev)
+{
+	u64 value;
+
+	value = gisb_read(gdev, ARB_ERR_CAP_ADDR);
+	value |= (u64)gisb_read(gdev, ARB_ERR_CAP_HI_ADDR) << 32;
+
+	return value;
+}
+
 static void gisb_write(struct brcmstb_gisb_arb_device *gdev, u32 val, int reg)
 {
 	int offset = gdev->gisb_offsets[reg];

@@ -185,7 +192,7 @@ static int brcmstb_gisb_arb_decode_addr(
 					const char *reason)
 {
 	u32 cap_status;
-	unsigned long arb_addr;
+	u64 arb_addr;
 	u32 master;
 	const char *m_name;
 	char m_fmt[11];

@@ -197,10 +204,7 @@ static int brcmstb_gisb_arb_decode_addr(
 		return 1;
 
 	/* Read the address and master */
-	arb_addr = gisb_read(gdev, ARB_ERR_CAP_ADDR) & 0xffffffff;
-#if (IS_ENABLED(CONFIG_PHYS_ADDR_T_64BIT))
-	arb_addr |= (u64)gisb_read(gdev, ARB_ERR_CAP_HI_ADDR) << 32;
-#endif
+	arb_addr = gisb_read_address(gdev);
 	master = gisb_read(gdev, ARB_ERR_CAP_MASTER);
 
 	m_name = brcmstb_gisb_master_to_str(gdev, master);

@@ -209,7 +213,7 @@ static int brcmstb_gisb_arb_decode_addr(
 		m_name = m_fmt;
 	}
 
-	pr_crit("%s: %s at 0x%lx [%c %s], core: %s\n",
+	pr_crit("%s: %s at 0x%llx [%c %s], core: %s\n",
 		__func__, reason, arb_addr,
 		cap_status & ARB_ERR_CAP_STATUS_WRITE ? 'W' : 'R',
 		cap_status & ARB_ERR_CAP_STATUS_TIMEOUT ? "timeout" : "",

Greg Kroah-Hartman

author maintainer

2018-04-11 18:33 UTC #50 lore raw

PATCH 48/310 powerpc/modules: If mprofile-kernel is enabled add it to vermagic

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Michael Ellerman <[email protected]>

[ Upstream commit 43e24e82f35291d4c1ca78877ce1b20d3aeb78f1 ]

On powerpc we can build the kernel with two different ABIs for mcount(), which is used by ftrace. Kernels built with one ABI do not know how to load modules built with the other ABI. The new style ABI is called "mprofile-kernel", for want of a better name.

Currently if we build a module using the old style ABI, and the kernel with mprofile-kernel, when we load the module we'll oops something like:

  # insmod autofs4-no-mprofile-kernel.ko
  ftrace-powerpc: Unexpected instruction f8810028 around bl _mcount
  ------------[ cut here ]------------
  WARNING: CPU: 6 PID: 3759 at ../kernel/trace/ftrace.c:2024 ftrace_bug+0x2b8/0x3c0
  CPU: 6 PID: 3759 Comm: insmod Not tainted 4.11.0-rc3-gcc-5.4.1-00017-g5a61ef74f269 #11
  ...
  NIP [c0000000001eaa48] ftrace_bug+0x2b8/0x3c0
  LR [c0000000001eaff8] ftrace_process_locs+0x4a8/0x590
  Call Trace:
    alloc_pages_current+0xc4/0x1d0 (unreliable)
    ftrace_process_locs+0x4a8/0x590
    load_module+0x1c8c/0x28f0
    SyS_finit_module+0x110/0x140
    system_call+0x38/0xfc
  ...
  ftrace failed to modify
  [<d000000002a31024>] 0xd000000002a31024
   actual:   35:65:00:48

We can avoid this by including in the vermagic whether the kernel/module was built with mprofile-kernel. Which results in:

  # insmod autofs4-pg.ko
  autofs4: version magic
  '4.11.0-rc3-gcc-5.4.1-00017-g5a61ef74f269 SMP mod_unload modversions '
  should be
  '4.11.0-rc3-gcc-5.4.1-00017-g5a61ef74f269-dirty SMP mod_unload modversions mprofile-kernel'
  insmod: ERROR: could not insert module autofs4-pg.ko: Invalid module format

Fixes 8c50b72a3b4f ("powerpc/ftrace: Add Kconfig & Make glue for mprofile-kernel")

Acked-by Balbir Singh <[email protected]>

Acked-by Jessica Yu <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 arch/powerpc/include/asm/module.h |    4 ++++
 1 file changed, 4 insertions(+)

arch/powerpc/include/asm/module.h +4 -0

@@ -14,6 +14,10 @@
 #include <asm-generic/module.h>
 
 
+#ifdef CC_USING_MPROFILE_KERNEL
+#define MODULE_ARCH_VERMAGIC	"mprofile-kernel"
+#endif
+
 #ifndef __powerpc64__
 /*
  * Thanks to Paul M for explaining this.

Greg Kroah-Hartman

author maintainer

2018-04-11 18:33 UTC #51 lore raw

PATCH 49/310 ARM: dts: imx6qdl-wandboard: Fix audio channel swap

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Fabio Estevam <[email protected]>

[ Upstream commit 79935915300c5eb88a0e94fa9148a7505c14a02a ]

When running a stress playback/stop loop test on a mx6wandboard channel swaps can be noticed randomly.

Increasing the SGTL5000 LRCLK pad strength to its maximum value fixes the issue, so add the 'lrclk-strength' property to avoid the audio channel swaps.

Signed-off-by Fabio Estevam <[email protected]>

Signed-off-by Shawn Guo <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 arch/arm/boot/dts/imx6qdl-wandboard.dtsi |    1 +
 1 file changed, 1 insertion(+)

arch/arm/boot/dts/imx6qdl-wandboard.dtsi +1 -0

@@ -88,6 +88,7 @@
 		clocks = <&clks IMX6QDL_CLK_CKO>;
 		VDDA-supply = <&reg_2p5v>;
 		VDDIO-supply = <&reg_3p3v>;
+		lrclk-strength = <3>;
 	};
 };

Greg Kroah-Hartman

author maintainer

2018-04-11 18:33 UTC #63 lore raw

PATCH 61/310 uio: fix incorrect memory leak cleanup

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Suman Anna <[email protected]>

[ Upstream commit 0d83539092ddb1ab79b4d65bccb866bf07ea2ccd ]

Commit 75f0aef6220d ("uio: fix memory leak") has fixed up some memory leaks during the failure paths of the addition of uio attributes, but still is not correct entirely. A kobject_uevent() failure still needs a kobject_put() and the kobject container structure allocation failure before the kobject_init() doesn't need a kobject_put(). Fix this properly.

Fixes 75f0aef6220d ("uio: fix memory leak")

Signed-off-by Suman Anna <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/uio/uio.c |    8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

drivers/uio/uio.c +4 -4

@@ -279,7 +279,7 @@ static int uio_dev_add_attributes(struct
 		map = kzalloc(sizeof(*map), GFP_KERNEL);
 		if (!map) {
 			ret = -ENOMEM;
-			goto err_map_kobj;
+			goto err_map;
 		}
 		kobject_init(&map->kobj, &map_attr_type);
 		map->mem = mem;

@@ -289,7 +289,7 @@ static int uio_dev_add_attributes(struct
 			goto err_map_kobj;
 		ret = kobject_uevent(&map->kobj, KOBJ_ADD);
 		if (ret)
-			goto err_map;
+			goto err_map_kobj;
 	}
 
 	for (pi = 0; pi < MAX_UIO_PORT_REGIONS; pi++) {

@@ -308,7 +308,7 @@ static int uio_dev_add_attributes(struct
 		portio = kzalloc(sizeof(*portio), GFP_KERNEL);
 		if (!portio) {
 			ret = -ENOMEM;
-			goto err_portio_kobj;
+			goto err_portio;
 		}
 		kobject_init(&portio->kobj, &portio_attr_type);
 		portio->port = port;

@@ -319,7 +319,7 @@ static int uio_dev_add_attributes(struct
 			goto err_portio_kobj;
 		ret = kobject_uevent(&portio->kobj, KOBJ_ADD);
 		if (ret)
-			goto err_portio;
+			goto err_portio_kobj;
 	}
 
 	return 0;

Greg Kroah-Hartman

author maintainer

2018-04-11 18:33 UTC #66 lore raw

PATCH 64/310 ARM: dts: rockchip: fix rk322x i2s1 pinctrl error

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Sugar Zhang <[email protected]>

[ Upstream commit 9d420e9b4140f8938ad6aa0d29e2428a2af6122b ]

Refer to Chapter 5.3.2 of rk3229 TRM, we can see that GPIO1A[2,4,5] using RK_FUNC_2 not RK_FUNC_1. This patch fixes it.

Signed-off-by Sugar Zhang <[email protected]>

Signed-off-by Frank Wang <[email protected]>

Signed-off-by Heiko Stuebner <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 arch/arm/boot/dts/rk322x.dtsi |    6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

arch/arm/boot/dts/rk322x.dtsi +3 -3

@@ -617,9 +617,9 @@
 						<0 12 RK_FUNC_1 &pcfg_pull_none>,
 						<0 13 RK_FUNC_1 &pcfg_pull_none>,
 						<0 14 RK_FUNC_1 &pcfg_pull_none>,
-						<1 2 RK_FUNC_1 &pcfg_pull_none>,
-						<1 4 RK_FUNC_1 &pcfg_pull_none>,
-						<1 5 RK_FUNC_1 &pcfg_pull_none>;
+						<1 2 RK_FUNC_2 &pcfg_pull_none>,
+						<1 4 RK_FUNC_2 &pcfg_pull_none>,
+						<1 5 RK_FUNC_2 &pcfg_pull_none>;
 			};
 		};

Greg Kroah-Hartman

author maintainer

2018-04-11 18:33 UTC #67 lore raw

PATCH 65/310 usb: chipidea: properly handle host or gadget initialization failure

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Jisheng Zhang <[email protected]>

[ Upstream commit c4a0bbbdb7f6e3c37fa6deb3ef28c5ed99da6175 ]

If ci_hdrc_host_init() or ci_hdrc_gadget_init() returns error and the error != -ENXIO, as Peter pointed out, "it stands for initialization for host or gadget has failed", so we'd better return failure rather continue.

And before destroying the otg, i.e ci_hdrc_otg_destroy(ci), we should also check ci->roles[CI_ROLE_GADGET].

Signed-off-by Jisheng Zhang <[email protected]>

Signed-off-by Peter Chen <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/usb/chipidea/core.c |   29 +++++++++++++++++++++--------
 1 file changed, 21 insertions(+), 8 deletions(-)

drivers/usb/chipidea/core.c +21 -8

@@ -839,7 +839,7 @@ static inline void ci_role_destroy(struc
 {
 	ci_hdrc_gadget_destroy(ci);
 	ci_hdrc_host_destroy(ci);
-	if (ci->is_otg)
+	if (ci->is_otg && ci->roles[CI_ROLE_GADGET])
 		ci_hdrc_otg_destroy(ci);
 }

@@ -939,27 +939,35 @@ static int ci_hdrc_probe(struct platform
 	/* initialize role(s) before the interrupt is requested */
 	if (dr_mode == USB_DR_MODE_OTG || dr_mode == USB_DR_MODE_HOST) {
 		ret = ci_hdrc_host_init(ci);
-		if (ret)
-			dev_info(dev, "doesn't support host\n");
+		if (ret) {
+			if (ret == -ENXIO)
+				dev_info(dev, "doesn't support host\n");
+			else
+				goto deinit_phy;
+		}
 	}
 
 	if (dr_mode == USB_DR_MODE_OTG || dr_mode == USB_DR_MODE_PERIPHERAL) {
 		ret = ci_hdrc_gadget_init(ci);
-		if (ret)
-			dev_info(dev, "doesn't support gadget\n");
+		if (ret) {
+			if (ret == -ENXIO)
+				dev_info(dev, "doesn't support gadget\n");
+			else
+				goto deinit_host;
+		}
 	}
 
 	if (!ci->roles[CI_ROLE_HOST] && !ci->roles[CI_ROLE_GADGET]) {
 		dev_err(dev, "no supported roles\n");
 		ret = -ENODEV;
-		goto deinit_phy;
+		goto deinit_gadget;
 	}
 
 	if (ci->is_otg && ci->roles[CI_ROLE_GADGET]) {
 		ret = ci_hdrc_otg_init(ci);
 		if (ret) {
 			dev_err(dev, "init otg fails, ret = %d\n", ret);
-			goto stop;
+			goto deinit_gadget;
 		}
 	}

@@ -1024,7 +1032,12 @@ static int ci_hdrc_probe(struct platform
 
 	ci_extcon_unregister(ci);
 stop:
-	ci_role_destroy(ci);
+	if (ci->is_otg && ci->roles[CI_ROLE_GADGET])
+		ci_hdrc_otg_destroy(ci);
+deinit_gadget:
+	ci_hdrc_gadget_destroy(ci);
+deinit_host:
+	ci_hdrc_host_destroy(ci);
 deinit_phy:
 	ci_usb_phy_exit(ci);

Greg Kroah-Hartman

author maintainer

2018-04-11 18:33 UTC #68 lore raw

PATCH 66/310 pxa_camera: fix module remove codepath for v4l2 clock

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Petr Cvek <[email protected]>

[ Upstream commit e3b4d10cc057522353c4a02f2f90dca6a52e006f ]

The conversion from soc_camera omitted a correct handling of the clock gating for a sensor. When the pxa_camera driver module was removed it tried to unregister clk, but this caused a similar warning:

  WARNING: CPU: 0 PID: 6740 at drivers/media/v4l2-core/v4l2-clk.c:278
  v4l2_clk_unregister(): Refusing to unregister ref-counted 0-0030 clock!

The clock was at time still refcounted by the sensor driver. Before the removing of the pxa_camera the clock must be dropped by the sensor driver. This should be triggered by v4l2_async_notifier_unregister() call which removes sensor driver module too, calls unbind() function and then tries to probe sensor driver again. Inside unbind() we can safely unregister the v4l2 clock as the sensor driver got removed. The original v4l2_clk_unregister() should be put inside test as the clock can be already unregistered from unbind(). If there was not any bound sensor the clock is still present.

The codepath is practically a copy from the old soc_camera. The bug was tested with a pxa_camera+ov9640 combination during the conversion of the ov9640 from the soc_camera.

Signed-off-by Petr Cvek <[email protected]>

Tested-by Robert Jarzmik <[email protected]>

Signed-off-by Hans Verkuil <[email protected]>

Signed-off-by Mauro Carvalho Chehab <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/media/platform/pxa_camera.c |   14 +++++++++++++-
 1 file changed, 13 insertions(+), 1 deletion(-)

drivers/media/platform/pxa_camera.c +13 -1

@@ -2169,6 +2169,12 @@ static void pxa_camera_sensor_unbind(str
 	pxa_dma_stop_channels(pcdev);
 
 	pxa_camera_destroy_formats(pcdev);
+
+	if (pcdev->mclk_clk) {
+		v4l2_clk_unregister(pcdev->mclk_clk);
+		pcdev->mclk_clk = NULL;
+	}
+
 	video_unregister_device(&pcdev->vdev);
 	pcdev->sensor = NULL;

@@ -2495,7 +2501,13 @@ static int pxa_camera_remove(struct plat
 	dma_release_channel(pcdev->dma_chans[1]);
 	dma_release_channel(pcdev->dma_chans[2]);
 
-	v4l2_clk_unregister(pcdev->mclk_clk);
+	v4l2_async_notifier_unregister(&pcdev->notifier);
+
+	if (pcdev->mclk_clk) {
+		v4l2_clk_unregister(pcdev->mclk_clk);
+		pcdev->mclk_clk = NULL;
+	}
+
 	v4l2_device_unregister(&pcdev->v4l2_dev);
 
 	dev_info(&pdev->dev, "PXA Camera driver unloaded\n");

Greg Kroah-Hartman

author maintainer

2018-04-11 18:33 UTC #69 lore raw

PATCH 67/310 USB: ene_usb6250: fix first command execution

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Alan Stern <[email protected]>

[ Upstream commit 4b309f1c4972c8f09e03ac64fc63510dbf5591a4 ]

In the ene_usb6250 sub-driver for usb-storage, the ene_transport() routine is supposed to initialize the driver before executing the current command, if the initialization has not already been performed. However, a bug in the routine causes it to skip the command after doing the initialization. Also, the routine does not return an appropriate error code if either the initialization or the command fails.

As a result of the first bug, the first command (a SCSI INQUIRY) is not carried out. The results can be seen in the system log, in the form of a warning message and empty or garbage INQUIRY data:

Apr 18 22:40:08 notebook2 kernel: scsi host6: scsi scan: INQUIRY result too short (5), using 36
Apr 18 22:40:08 notebook2 kernel: scsi 6:0:0:0: Direct-Access                                    PQ: 0 ANSI: 0

This patch fixes both errors.

Signed-off-by Alan Stern <[email protected]>

Reported-and-tested-by Andreas Hartmann <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/usb/storage/ene_ub6250.c |    9 +++++----
 1 file changed, 5 insertions(+), 4 deletions(-)

drivers/usb/storage/ene_ub6250.c +5 -4

@@ -2295,21 +2295,22 @@ static int ms_scsi_irp(struct us_data *u
 
 static int ene_transport(struct scsi_cmnd *srb, struct us_data *us)
 {
-	int result = 0;
+	int result = USB_STOR_XFER_GOOD;
 	struct ene_ub6250_info *info = (struct ene_ub6250_info *)(us->extra);
 
 	/*US_DEBUG(usb_stor_show_command(us, srb)); */
 	scsi_set_resid(srb, 0);
-	if (unlikely(!(info->SD_Status.Ready || info->MS_Status.Ready))) {
+	if (unlikely(!(info->SD_Status.Ready || info->MS_Status.Ready)))
 		result = ene_init(us);
-	} else {
+	if (result == USB_STOR_XFER_GOOD) {
+		result = USB_STOR_TRANSPORT_ERROR;
 		if (info->SD_Status.Ready)
 			result = sd_scsi_irp(us, srb);
 
 		if (info->MS_Status.Ready)
 			result = ms_scsi_irp(us, srb);
 	}
-	return 0;
+	return result;
 }
 
 static struct scsi_host_template ene_ub6250_host_template;

Greg Kroah-Hartman

author maintainer

2018-04-11 18:33 UTC #70 lore raw

PATCH 68/310 net: x25: fix one potential use-after-free issue

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: linzhang <[email protected]>

[ Upstream commit 64df6d525fcff1630098db9238bfd2b3e092d5c1 ]

The function x25_init is not properly unregister related resources on error handler.It is will result in kernel oops if x25_init init failed, so add properly unregister call on error handler.

Also, i adjust the coding style and make x25_register_sysctl properly return failure.

Signed-off-by linzhang <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 include/net/x25.h        |    4 ++--
 net/x25/af_x25.c         |   24 ++++++++++++++++--------
 net/x25/sysctl_net_x25.c |    5 ++++-
 3 files changed, 22 insertions(+), 11 deletions(-)

include/net/x25.h +2 -2

@@ -298,10 +298,10 @@ void x25_check_rbuf(struct sock *);
 
 /* sysctl_net_x25.c */
 #ifdef CONFIG_SYSCTL
-void x25_register_sysctl(void);
+int x25_register_sysctl(void);
 void x25_unregister_sysctl(void);
 #else
-static inline void x25_register_sysctl(void) {};
+static inline int x25_register_sysctl(void) { return 0; };
 static inline void x25_unregister_sysctl(void) {};
 #endif /* CONFIG_SYSCTL */

net/x25/af_x25.c +16 -8

@@ -1790,32 +1790,40 @@ void x25_kill_by_neigh(struct x25_neigh
 
 static int __init x25_init(void)
 {
-	int rc = proto_register(&x25_proto, 0);
+	int rc;
 
-	if (rc != 0)
+	rc = proto_register(&x25_proto, 0);
+	if (rc)
 		goto out;
 
 	rc = sock_register(&x25_family_ops);
-	if (rc != 0)
+	if (rc)
 		goto out_proto;
 
 	dev_add_pack(&x25_packet_type);
 
 	rc = register_netdevice_notifier(&x25_dev_notifier);
-	if (rc != 0)
+	if (rc)
 		goto out_sock;
 
-	pr_info("Linux Version 0.2\n");
+	rc = x25_register_sysctl();
+	if (rc)
+		goto out_dev;
 
-	x25_register_sysctl();
 	rc = x25_proc_init();
-	if (rc != 0)
-		goto out_dev;
+	if (rc)
+		goto out_sysctl;
+
+	pr_info("Linux Version 0.2\n");
+
 out:
 	return rc;
+out_sysctl:
+	x25_unregister_sysctl();
 out_dev:
 	unregister_netdevice_notifier(&x25_dev_notifier);
 out_sock:
+	dev_remove_pack(&x25_packet_type);
 	sock_unregister(AF_X25);
 out_proto:
 	proto_unregister(&x25_proto);

net/x25/sysctl_net_x25.c +4 -1

@@ -73,9 +73,12 @@ static struct ctl_table x25_table[] = {
 	{ 0, },
 };
 
-void __init x25_register_sysctl(void)
+int __init x25_register_sysctl(void)
 {
 	x25_table_header = register_net_sysctl(&init_net, "net/x25", x25_table);
+	if (!x25_table_header)
+		return -ENOMEM;
+	return 0;
 }
 
 void x25_unregister_sysctl(void)

Greg Kroah-Hartman

author maintainer

2018-04-11 18:33 UTC #71 lore raw

PATCH 69/310 USB: ene_usb6250: fix SCSI residue overwriting

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Alan Stern <[email protected]>

[ Upstream commit aa18c4b6e0e39bfb00af48734ec24bc189ac9909 ]

In the ene_usb6250 sub-driver for usb-storage, the SCSI residue is not reported correctly. The residue is initialized to 0, but this value is overwritten whenever the driver sends firmware to the card reader before performing the current command. As a result, a valid READ or WRITE operation appears to have failed, causing the SCSI core to retry the command multiple times and eventually fail.

This patch fixes the problem by resetting the SCSI residue to 0 after sending firmware to the device.

Signed-off-by Alan Stern <[email protected]>

Reported-and-tested-by Andreas Hartmann <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/usb/storage/ene_ub6250.c |    2 ++
 1 file changed, 2 insertions(+)

drivers/usb/storage/ene_ub6250.c +2 -0

@@ -1942,6 +1942,8 @@ static int ene_load_bincode(struct us_da
 	bcb->CDB[0] = 0xEF;
 
 	result = ene_send_scsi_cmd(us, FDIR_WRITE, buf, 0);
+	if (us->srb != NULL)
+		scsi_set_resid(us->srb, 0);
 	info->BIN_FLAG = flag;
 	kfree(buf);

Greg Kroah-Hartman

author maintainer

2018-04-11 18:33 UTC #72 lore raw

PATCH 70/310 serial: 8250: omap: Disable DMA for console UART

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Vignesh R <[email protected]>

[ Upstream commit 84b40e3b57eef1417479c00490dd4c9f6e5ffdbc ]

Kernel always writes log messages to console via serial8250_console_write()->serial8250_console_putchar() which directly accesses UART_TX register _without_ using DMA.

But, if other processes like systemd using same UART port, then these writes are handled by a different code flow using 8250_omap driver where there is provision to use DMA.

It seems that it is possible that both DMA and CPU might simultaneously put data to UART FIFO and lead to potential loss of data due to FIFO overflow and weird data corruption. This happens when both kernel console and userspace tries to write simultaneously to the same UART port. Therefore, disable DMA on kernel console port to avoid potential race between CPU and DMA.

Signed-off-by Vignesh R <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/tty/serial/8250/8250_omap.c |    4 ++++
 1 file changed, 4 insertions(+)

drivers/tty/serial/8250/8250_omap.c +4 -0

@@ -613,6 +613,10 @@ static int omap_8250_startup(struct uart
 	up->lsr_saved_flags = 0;
 	up->msr_saved_flags = 0;
 
+	/* Disable DMA for console UART */
+	if (uart_console(port))
+		up->dma = NULL;
+
 	if (up->dma) {
 		ret = serial8250_request_dma(up);
 		if (ret) {

Greg Kroah-Hartman

author maintainer

2018-04-11 18:33 UTC #73 lore raw

PATCH 71/310 serial: sh-sci: Fix race condition causing garbage during shutdown

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Geert Uytterhoeven <[email protected]>

[ Upstream commit 1cf4a7efdc71cab84c42cfea7200608711ea954f ]

If DMA is enabled and used, a burst of old data may be seen on the serial console during "poweroff" or "reboot". uart_flush_buffer() clears the circular buffer, but sci_port.tx_dma_len is not reset. This leads to a circular buffer overflow, dumping (UART_XMIT_SIZE - sci_port.tx_dma_len) bytes.

To fix this, add a .flush_buffer() callback that resets sci_port.tx_dma_len.

Inspired by commit 31ca2c63fdc0aee7 ("tty/serial: atmel: fix race condition (TX+DMA)").

Signed-off-by Geert Uytterhoeven <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/tty/serial/sh-sci.c |   16 ++++++++++++++--
 1 file changed, 14 insertions(+), 2 deletions(-)

drivers/tty/serial/sh-sci.c +14 -2

@@ -1545,7 +1545,16 @@ static void sci_free_dma(struct uart_por
 	if (s->chan_rx)
 		sci_rx_dma_release(s, false);
 }
-#else
+
+static void sci_flush_buffer(struct uart_port *port)
+{
+	/*
+	 * In uart_flush_buffer(), the xmit circular buffer has just been
+	 * cleared, so we have to reset tx_dma_len accordingly.
+	 */
+	to_sci_port(port)->tx_dma_len = 0;
+}
+#else /* !CONFIG_SERIAL_SH_SCI_DMA */
 static inline void sci_request_dma(struct uart_port *port)
 {
 }

@@ -1553,7 +1562,9 @@ static inline void sci_request_dma(struc
 static inline void sci_free_dma(struct uart_port *port)
 {
 }
-#endif
+
+#define sci_flush_buffer	NULL
+#endif /* !CONFIG_SERIAL_SH_SCI_DMA */
 
 static irqreturn_t sci_rx_interrupt(int irq, void *ptr)
 {

@@ -2551,6 +2562,7 @@ static const struct uart_ops sci_uart_op
 	.break_ctl	= sci_break_ctl,
 	.startup	= sci_startup,
 	.shutdown	= sci_shutdown,
+	.flush_buffer	= sci_flush_buffer,
 	.set_termios	= sci_set_termios,
 	.pm		= sci_pm,
 	.type		= sci_type,

Greg Kroah-Hartman

author maintainer

2018-04-11 18:33 UTC #74 lore raw

PATCH 72/310 net/wan/fsl_ucc_hdlc: fix unitialized variable warnings

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Holger Brunck <[email protected]>

[ Upstream commit 66bb144bd9096dd5268ef736ba769b8b6f4ef100 ]

This fixes the following compiler warnings:
drivers/net/wan/fsl_ucc_hdlc.c: In function 'ucc_hdlc_poll':
warning: 'skb' may be used uninitialized in this function [-Wmaybe-uninitialized]
skb->mac_header = skb->data - skb->head;

and

drivers/net/wan/fsl_ucc_hdlc.c: In function 'ucc_hdlc_probe':
drivers/net/wan/fsl_ucc_hdlc.c:1127:3: warning: 'utdm' may be used uninitialized in this function [-Wmaybe-uninitialized]
kfree(utdm);

Cc Zhao Qiang <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/net/wan/fsl_ucc_hdlc.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

drivers/net/wan/fsl_ucc_hdlc.c +2 -2

@@ -454,7 +454,7 @@ static int hdlc_tx_done(struct ucc_hdlc_
 static int hdlc_rx_done(struct ucc_hdlc_private *priv, int rx_work_limit)
 {
 	struct net_device *dev = priv->ndev;
-	struct sk_buff *skb;
+	struct sk_buff *skb = NULL;
 	hdlc_device *hdlc = dev_to_hdlc(dev);
 	struct qe_bd *bd;
 	u32 bd_status;

@@ -1002,7 +1002,7 @@ static int ucc_hdlc_probe(struct platfor
 	struct device_node *np = pdev->dev.of_node;
 	struct ucc_hdlc_private *uhdlc_priv = NULL;
 	struct ucc_tdm_info *ut_info;
-	struct ucc_tdm *utdm;
+	struct ucc_tdm *utdm = NULL;
 	struct resource res;
 	struct net_device *dev;
 	hdlc_device *hdlc;

Greg Kroah-Hartman

author maintainer

2018-04-11 18:33 UTC #75 lore raw

PATCH 73/310 net/wan/fsl_ucc_hdlc: fix incorrect memory allocation

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Holger Brunck <[email protected]>

[ Upstream commit 5b8aad93c52bdda6a731cab8497998cfa0f2df07 ]

We need space for the struct qe_bd and not for a pointer to this struct.

Cc Zhao Qiang <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/net/wan/fsl_ucc_hdlc.c |   12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

drivers/net/wan/fsl_ucc_hdlc.c +6 -6

@@ -137,7 +137,7 @@ static int uhdlc_init(struct ucc_hdlc_pr
 	priv->tx_ring_size = TX_BD_RING_LEN;
 	/* Alloc Rx BD */
 	priv->rx_bd_base = dma_alloc_coherent(priv->dev,
-			RX_BD_RING_LEN * sizeof(struct qe_bd *),
+			RX_BD_RING_LEN * sizeof(struct qe_bd),
 			&priv->dma_rx_bd, GFP_KERNEL);
 
 	if (!priv->rx_bd_base) {

@@ -148,7 +148,7 @@ static int uhdlc_init(struct ucc_hdlc_pr
 
 	/* Alloc Tx BD */
 	priv->tx_bd_base = dma_alloc_coherent(priv->dev,
-			TX_BD_RING_LEN * sizeof(struct qe_bd *),
+			TX_BD_RING_LEN * sizeof(struct qe_bd),
 			&priv->dma_tx_bd, GFP_KERNEL);
 
 	if (!priv->tx_bd_base) {

@@ -295,11 +295,11 @@ free_ucc_pram:
 	qe_muram_free(priv->ucc_pram_offset);
 free_tx_bd:
 	dma_free_coherent(priv->dev,
-			  TX_BD_RING_LEN * sizeof(struct qe_bd *),
+			  TX_BD_RING_LEN * sizeof(struct qe_bd),
 			  priv->tx_bd_base, priv->dma_tx_bd);
 free_rx_bd:
 	dma_free_coherent(priv->dev,
-			  RX_BD_RING_LEN * sizeof(struct qe_bd *),
+			  RX_BD_RING_LEN * sizeof(struct qe_bd),
 			  priv->rx_bd_base, priv->dma_rx_bd);
 free_uccf:
 	ucc_fast_free(priv->uccf);

@@ -688,7 +688,7 @@ static void uhdlc_memclean(struct ucc_hd
 
 	if (priv->rx_bd_base) {
 		dma_free_coherent(priv->dev,
-				  RX_BD_RING_LEN * sizeof(struct qe_bd *),
+				  RX_BD_RING_LEN * sizeof(struct qe_bd),
 				  priv->rx_bd_base, priv->dma_rx_bd);
 
 		priv->rx_bd_base = NULL;

@@ -697,7 +697,7 @@ static void uhdlc_memclean(struct ucc_hd
 
 	if (priv->tx_bd_base) {
 		dma_free_coherent(priv->dev,
-				  TX_BD_RING_LEN * sizeof(struct qe_bd *),
+				  TX_BD_RING_LEN * sizeof(struct qe_bd),
 				  priv->tx_bd_base, priv->dma_tx_bd);
 
 		priv->tx_bd_base = NULL;

Greg Kroah-Hartman

author maintainer

2018-04-11 18:33 UTC #76 lore raw

PATCH 74/310 fsl/qe: add bit description for SYNL register for GUMR

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Holger Brunck <[email protected]>

[ Upstream commit c7f235a7c2d09b1b83671ba2d93ebee981554467 ]

Add the bitmask for the two bit SYNL register according to the QUICK Engine Reference Manual.

Cc Zhao Qiang <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 include/soc/fsl/qe/qe.h |    4 ++++
 1 file changed, 4 insertions(+)

include/soc/fsl/qe/qe.h +4 -0

@@ -668,6 +668,10 @@ struct ucc_slow_pram {
 #define UCC_FAST_GUMR_CTSS	0x00800000
 #define UCC_FAST_GUMR_TXSY	0x00020000
 #define UCC_FAST_GUMR_RSYN	0x00010000
+#define UCC_FAST_GUMR_SYNL_MASK	0x0000C000
+#define UCC_FAST_GUMR_SYNL_16	0x0000C000
+#define UCC_FAST_GUMR_SYNL_8	0x00008000
+#define UCC_FAST_GUMR_SYNL_AUTO	0x00004000
 #define UCC_FAST_GUMR_RTSM	0x00002000
 #define UCC_FAST_GUMR_REVD	0x00000400
 #define UCC_FAST_GUMR_ENR	0x00000020

Greg Kroah-Hartman

author maintainer

2018-04-11 18:33 UTC #77 lore raw

PATCH 75/310 sh_eth: Use platform device for printing before register_netdev()

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Geert Uytterhoeven <[email protected]>

[ Upstream commit 5f5c5449acad0cd3322e53e1ac68c044483b0aa5 ]

The MDIO initialization failure message is printed using the network device, before it has been registered, leading to:

(null): failed to initialise MDIO

Use the platform device instead to fix this:

sh-eth ee700000.ethernet: failed to initialise MDIO

Fixes daacf03f0bbfefee ("sh_eth: Register MDIO bus before registering the network device")

Signed-off-by Geert Uytterhoeven <[email protected]>

Reviewed-by Laurent Pinchart <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/net/ethernet/renesas/sh_eth.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

drivers/net/ethernet/renesas/sh_eth.c +1 -1

@@ -3133,7 +3133,7 @@ static int sh_eth_drv_probe(struct platf
 	/* MDIO bus init */
 	ret = sh_mdio_init(mdp, pd);
 	if (ret) {
-		dev_err(&ndev->dev, "failed to initialise MDIO\n");
+		dev_err(&pdev->dev, "failed to initialise MDIO\n");
 		goto out_release;
 	}

Greg Kroah-Hartman

author maintainer

2018-04-11 18:33 UTC #79 lore raw

PATCH 77/310 scsi: csiostor: fix use after free in csio_hw_use_fwconfig()

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Varun Prakash <[email protected]>

[ Upstream commit a351e40b6de550049423a26f7ded7b639e363d89 ]

mbp pointer is passed to csio_hw_validate_caps() so call mempool_free() after calling csio_hw_validate_caps().

Signed-off-by Varun Prakash <[email protected]>

Fixes 541c571fa2fd ("csiostor:Use firmware version from cxgb4/t4fw_version.h")

Reviewed-by Johannes Thumshirn <[email protected]>

Signed-off-by Martin K. Petersen <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/scsi/csiostor/csio_hw.c |    5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

drivers/scsi/csiostor/csio_hw.c +4 -1

@@ -1769,7 +1769,6 @@ csio_hw_use_fwconfig(struct csio_hw *hw,
 		goto bye;
 	}
 
-	mempool_free(mbp, hw->mb_mempool);
 	if (finicsum != cfcsum) {
 		csio_warn(hw,
 		      "Config File checksum mismatch: csum=%#x, computed=%#x\n",

@@ -1780,6 +1779,10 @@ csio_hw_use_fwconfig(struct csio_hw *hw,
 	rv = csio_hw_validate_caps(hw, mbp);
 	if (rv != 0)
 		goto bye;
+
+	mempool_free(mbp, hw->mb_mempool);
+	mbp = NULL;
+
 	/*
 	 * Note that we're operating with parameters
 	 * not supplied by the driver, rather than from hard-wired

Greg Kroah-Hartman

author maintainer

2018-04-11 18:33 UTC #80 lore raw

PATCH 78/310 powerpc/mm: Fix virt_addr_valid() etc. on 64-bit hash

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Michael Ellerman <[email protected]>

[ Upstream commit e41e53cd4fe331d0d1f06f8e4ed7e2cc63ee2c34 ]

virt_addr_valid() is supposed to tell you if it's OK to call virt_to_page() on an address. What this means in practice is that it should only return true for addresses in the linear mapping which are backed by a valid PFN.

We are failing to properly check that the address is in the linear mapping, because virt_to_pfn() will return a valid looking PFN for more or less any address. That bug is actually caused by __pa(), used in virt_to_pfn().

eg: __pa(0xc000000000010000) = 0x10000  # Good
    __pa(0xd000000000010000) = 0x10000  # Bad!
    __pa(0x0000000000010000) = 0x10000  # Bad!

This started happening after commit bdbc29c19b26 ("powerpc: Work around gcc miscompilation of __pa() on 64-bit") (Aug 2013), where we changed the definition of __pa() to work around a GCC bug. Prior to that we subtracted PAGE_OFFSET from the value passed to __pa(), meaning __pa() of a 0xd or 0x0 address would give you something bogus back.

Until we can verify if that GCC bug is no longer an issue, or come up with another solution, this commit does the minimal fix to make virt_addr_valid() work, by explicitly checking that the address is in the linear mapping region.

Fixes bdbc29c19b26 ("powerpc: Work around gcc miscompilation of __pa() on 64-bit")

Reviewed-by Paul Mackerras <[email protected]>

Reviewed-by Balbir Singh <[email protected]>

Tested-by Breno Leitao <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 arch/powerpc/include/asm/page.h |   12 ++++++++++++
 1 file changed, 12 insertions(+)

arch/powerpc/include/asm/page.h +12 -0

@@ -132,7 +132,19 @@ extern long long virt_phys_offset;
 #define virt_to_pfn(kaddr)	(__pa(kaddr) >> PAGE_SHIFT)
 #define virt_to_page(kaddr)	pfn_to_page(virt_to_pfn(kaddr))
 #define pfn_to_kaddr(pfn)	__va((pfn) << PAGE_SHIFT)
+
+#ifdef CONFIG_PPC_BOOK3S_64
+/*
+ * On hash the vmalloc and other regions alias to the kernel region when passed
+ * through __pa(), which virt_to_pfn() uses. That means virt_addr_valid() can
+ * return true for some vmalloc addresses, which is incorrect. So explicitly
+ * check that the address is in the kernel region.
+ */
+#define virt_addr_valid(kaddr) (REGION_ID(kaddr) == KERNEL_REGION_ID && \
+				pfn_valid(virt_to_pfn(kaddr)))
+#else
 #define virt_addr_valid(kaddr)	pfn_valid(virt_to_pfn(kaddr))
+#endif
 
 /*
  * On Book-E parts we need __va to parse the device tree and we can't

Greg Kroah-Hartman

author maintainer

2018-04-11 18:33 UTC #81 lore raw

PATCH 79/310 ath5k: fix memory leak on buf on failed eeprom read

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Colin Ian King <[email protected]>

[ Upstream commit 8fed6823e06e43ee9cf7c0ffecec2f9111ce6201 ]

The AR5K_EEPROM_READ macro returns with -EIO if a read error occurs causing a memory leak on the allocated buffer buf. Fix this by explicitly calling ath5k_hw_nvram_read and exiting on the via the freebuf label that performs the necessary free'ing of buf when a read error occurs.

Detected by CoverityScan, CID#1248782 ("Resource Leak")

Signed-off-by Colin Ian King <[email protected]>

Signed-off-by Kalle Valo <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/net/wireless/ath/ath5k/debug.c |    5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

drivers/net/wireless/ath/ath5k/debug.c +4 -1

@@ -939,7 +939,10 @@ static int open_file_eeprom(struct inode
 	}
 
 	for (i = 0; i < eesize; ++i) {
-		AR5K_EEPROM_READ(i, val);
+		if (!ath5k_hw_nvram_read(ah, i, &val)) {
+			ret = -EIO;
+			goto freebuf;
+		}
 		buf[i] = val;
 	}

Greg Kroah-Hartman

author maintainer

2018-04-11 18:33 UTC #82 lore raw

PATCH 80/310 selftests/powerpc: Fix TM resched DSCR test with some compilers

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Michael Ellerman <[email protected]>

[ Upstream commit fe06fe860250a4f01d0eaf70a2563b1997174a74 ]

The tm-resched-dscr test has started failing sometimes, depending on what compiler it's built with, eg:

test: tm_resched_dscr
Check DSCR TM context switch: tm-resched-dscr: tm-resched-dscr.c:76: test_body: Assertion `rv' failed. !! child died by signal 6

When it fails we see that the compiler doesn't initialise rv to 1 before entering the inline asm block. Although that's counter intuitive, it is allowed because we tell the compiler that the inline asm will write to rv (using "=r"), meaning the original value is irrelevant.

Marking it as a read/write parameter would presumably work, but it seems simpler to fix it by setting the initial value of rv in the inline asm.

Fixes 96d016108640 ("powerpc: Correct DSCR during TM context switch")

Acked-by Michael Neuling <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 tools/testing/selftests/powerpc/tm/tm-resched-dscr.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

tools/testing/selftests/powerpc/tm/tm-resched-dscr.c +1 -1

@@ -42,12 +42,12 @@ int test_body(void)
 	printf("Check DSCR TM context switch: ");
 	fflush(stdout);
 	for (;;) {
-		rv = 1;
 		asm __volatile__ (
 			/* set a known value into the DSCR */
 			"ld      3, %[dscr1];"
 			"mtspr   %[sprn_dscr], 3;"
 
+			"li      %[rv], 1;"
 			/* start and suspend a transaction */
 			"tbegin.;"
 			"beq     1f;"

Greg Kroah-Hartman

author maintainer

2018-04-11 18:33 UTC #83 lore raw

PATCH 81/310 xfrm: fix state migration copy replay sequence numbers

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Antony Antony <[email protected]>

[ Upstream commit a486cd23661c9387fb076c3f6ae8b2aa9d20d54a ]

During xfrm migration copy replay and preplay sequence numbers from the previous state.

Here is a tcpdump output showing the problem. 10.0.10.46 is running vanilla kernel, is the IKE/IPsec responder. After the migration it sent wrong sequence number, reset to 1. The migration is from 10.0.0.52 to 10.0.0.53.

IP 10.0.0.52.4500 > 10.0.10.46.4500: UDP-encap: ESP(spi=0x43ef462d,seq=0x7cf), length 136 IP 10.0.10.46.4500 > 10.0.0.52.4500: UDP-encap: ESP(spi=0xca1c282d,seq=0x7cf), length 136 IP 10.0.0.52.4500 > 10.0.10.46.4500: UDP-encap: ESP(spi=0x43ef462d,seq=0x7d0), length 136 IP 10.0.10.46.4500 > 10.0.0.52.4500: UDP-encap: ESP(spi=0xca1c282d,seq=0x7d0), length 136

IP 10.0.0.53.4500 > 10.0.10.46.4500: NONESP-encap: isakmp: child_sa  inf2[I]
IP 10.0.10.46.4500 > 10.0.0.53.4500: NONESP-encap: isakmp: child_sa  inf2[R]
IP 10.0.0.53.4500 > 10.0.10.46.4500: NONESP-encap: isakmp: child_sa  inf2[I]
IP 10.0.10.46.4500 > 10.0.0.53.4500: NONESP-encap: isakmp: child_sa  inf2[R]

IP 10.0.0.53.4500 > 10.0.10.46.4500: UDP-encap: ESP(spi=0x43ef462d,seq=0x7d1), length 136

NOTE: next sequence is wrong 0x1

IP 10.0.10.46.4500 > 10.0.0.53.4500: UDP-encap: ESP(spi=0xca1c282d,seq=0x1), length 136 IP 10.0.0.53.4500 > 10.0.10.46.4500: UDP-encap: ESP(spi=0x43ef462d,seq=0x7d2), length 136 IP 10.0.10.46.4500 > 10.0.0.53.4500: UDP-encap: ESP(spi=0xca1c282d,seq=0x2), length 136

Signed-off-by Antony Antony <[email protected]>

Reviewed-by Richard Guy Briggs <[email protected]>

Signed-off-by Steffen Klassert <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 net/xfrm/xfrm_state.c |    2 ++
 1 file changed, 2 insertions(+)

net/xfrm/xfrm_state.c +2 -0

@@ -1246,6 +1246,8 @@ static struct xfrm_state *xfrm_state_clo
 	x->curlft.add_time = orig->curlft.add_time;
 	x->km.state = orig->km.state;
 	x->km.seq = orig->km.seq;
+	x->replay = orig->replay;
+	x->preplay = orig->preplay;
 
 	return x;

Greg Kroah-Hartman

author maintainer

2018-04-11 18:33 UTC #84 lore raw

PATCH 82/310 ASoC: simple-card: fix mic jack initialization

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Stefan Agner <[email protected]>

[ Upstream commit f746aa5e8636c83e53bbb2d988bb614f732b2b80 ]

Initialize asoc_simple_card_init_mic with the correct struct asoc_simple_jack.

Fixes 9eac361877b3 ("ASoC: simple-card: add new asoc_simple_jack and use it")

Signed-off-by Stefan Agner <[email protected]>

Acked-by Kuninori Morimoto <[email protected]>

Signed-off-by Mark Brown <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 sound/soc/generic/simple-card.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

sound/soc/generic/simple-card.c +1 -1

@@ -201,7 +201,7 @@ static int asoc_simple_card_dai_init(str
 	if (ret < 0)
 		return ret;
 
-	ret = asoc_simple_card_init_mic(rtd->card, &priv->hp_jack, PREFIX);
+	ret = asoc_simple_card_init_mic(rtd->card, &priv->mic_jack, PREFIX);
 	if (ret < 0)
 		return ret;

Greg Kroah-Hartman

author maintainer

2018-04-11 18:33 UTC #85 lore raw

PATCH 83/310 iio: hi8435: avoid garbage event at first enable

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Nikita Yushchenko <[email protected]>

[ Upstream commit ee19ac340c5fdfd89c6348be4563453c61ab54a9 ]

Currently, driver generates events for channels if new reading differs from previous one. This "previous value" is initialized to zero, which results into event if value is constant-one.

Fix that by initializing "previous value" by reading at event enable time.

This provides reliable sequence for userspace:
- enable event,
- AFTER THAT read current value,
- AFTER THAT each event will correspond to change.

Signed-off-by Nikita Yushchenko <[email protected]>

Signed-off-by Jonathan Cameron <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/iio/adc/hi8435.c |   15 +++++++++++++--
 1 file changed, 13 insertions(+), 2 deletions(-)

drivers/iio/adc/hi8435.c +13 -2

@@ -121,10 +121,21 @@ static int hi8435_write_event_config(str
 				     enum iio_event_direction dir, int state)
 {
 	struct hi8435_priv *priv = iio_priv(idev);
+	int ret;
+	u32 tmp;
+
+	if (state) {
+		ret = hi8435_readl(priv, HI8435_SO31_0_REG, &tmp);
+		if (ret < 0)
+			return ret;
+		if (tmp & BIT(chan->channel))
+			priv->event_prev_val |= BIT(chan->channel);
+		else
+			priv->event_prev_val &= ~BIT(chan->channel);
 
-	priv->event_scan_mask &= ~BIT(chan->channel);
-	if (state)
 		priv->event_scan_mask |= BIT(chan->channel);
+	} else
+		priv->event_scan_mask &= ~BIT(chan->channel);
 
 	return 0;
 }

Greg Kroah-Hartman

author maintainer

2018-04-11 18:33 UTC #86 lore raw

PATCH 84/310 iio: hi8435: cleanup reset gpio

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Nikita Yushchenko <[email protected]>

[ Upstream commit 61305664a542f874283f74bf0b27ddb31f5045d7 ]

Reset GPIO is active low.

Currently driver uses gpiod_set_value(1) to clean reset, which depends on device tree to contain GPIO_ACTIVE_HIGH - that does not match reality.

This fixes driver to use _raw version of gpiod_set_value() to enforce active-low semantics despite of what's written in device tree. Allowing device tree to override that only opens possibility for errors and does not add any value.

Additionally, use _cansleep version to make things work with i2c-gpio and other sleeping gpio drivers.

Signed-off-by Nikita Yushchenko <[email protected]>

Signed-off-by Jonathan Cameron <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/iio/adc/hi8435.c |   12 +++++++-----
 1 file changed, 7 insertions(+), 5 deletions(-)

drivers/iio/adc/hi8435.c +7 -5

@@ -453,13 +453,15 @@ static int hi8435_probe(struct spi_devic
 	priv->spi = spi;
 
 	reset_gpio = devm_gpiod_get(&spi->dev, NULL, GPIOD_OUT_LOW);
-	if (IS_ERR(reset_gpio)) {
-		/* chip s/w reset if h/w reset failed */
+	if (!IS_ERR(reset_gpio)) {
+		/* need >=100ns low pulse to reset chip */
+		gpiod_set_raw_value_cansleep(reset_gpio, 0);
+		udelay(1);
+		gpiod_set_raw_value_cansleep(reset_gpio, 1);
+	} else {
+		/* s/w reset chip if h/w reset is not available */
 		hi8435_writeb(priv, HI8435_CTRL_REG, HI8435_CTRL_SRST);
 		hi8435_writeb(priv, HI8435_CTRL_REG, 0);
-	} else {
-		udelay(5);
-		gpiod_set_value(reset_gpio, 1);
 	}
 
 	spi_set_drvdata(spi, idev);

Greg Kroah-Hartman

author maintainer

2018-04-11 18:33 UTC #87 lore raw

PATCH 85/310 iio: light: rpr0521 poweroff for probe fails

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Mikko Koivunen <[email protected]>

[ Upstream commit 12d74949133e2450533894ea01ce0c56646ce006 ]

Set sensor measurement off after probe fail in pm_runtime_set_active() or iio_device_register(). Without this change sensor measurement stays on even though probe fails on these calls.

This is maybe rare case, but causes constant power drain without any benefits when it happens. Power drain is 20-500uA, typically 180uA.

Signed-off-by Mikko Koivunen <[email protected]>

Acked-by Daniel Baluta <[email protected]>

Signed-off-by Jonathan Cameron <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/iio/light/rpr0521.c |   17 +++++++++++++++--
 1 file changed, 15 insertions(+), 2 deletions(-)

drivers/iio/light/rpr0521.c +15 -2

@@ -510,13 +510,26 @@ static int rpr0521_probe(struct i2c_clie
 
 	ret = pm_runtime_set_active(&client->dev);
 	if (ret < 0)
-		return ret;
+		goto err_poweroff;
 
 	pm_runtime_enable(&client->dev);
 	pm_runtime_set_autosuspend_delay(&client->dev, RPR0521_SLEEP_DELAY_MS);
 	pm_runtime_use_autosuspend(&client->dev);
 
-	return iio_device_register(indio_dev);
+	ret = iio_device_register(indio_dev);
+	if (ret)
+		goto err_pm_disable;
+
+	return 0;
+
+err_pm_disable:
+	pm_runtime_disable(&client->dev);
+	pm_runtime_set_suspended(&client->dev);
+	pm_runtime_put_noidle(&client->dev);
+err_poweroff:
+	rpr0521_poweroff(data);
+
+	return ret;
 }
 
 static int rpr0521_remove(struct i2c_client *client)

Greg Kroah-Hartman

author maintainer

2018-04-11 18:33 UTC #88 lore raw

PATCH 86/310 ext4: handle the rest of ext4_mb_load_buddy() ENOMEM errors

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Konstantin Khlebnikov <[email protected]>

[ Upstream commit 9651e6b2e20648d04d5e1fe6479a3056047e8781 ]

I've got another report about breaking ext4 by ENOMEM error returned from ext4_mb_load_buddy() caused by memory shortage in memory cgroup. This time inside ext4_discard_preallocations().

This patch replaces ext4_error() with ext4_warning() where errors returned from ext4_mb_load_buddy() are not fatal and handled by caller:
* ext4_mb_discard_group_preallocations() - called before generating ENOSPC, we'll try to discard other group or return ENOSPC into user-space.
* ext4_trim_all_free() - just stop trimming and return ENOMEM from ioctl.

Some callers cannot handle errors, thus __GFP_NOFAIL is used for them:
* ext4_discard_preallocations()
* ext4_mb_discard_lg_preallocations()

Fixes adb7ef600cc9 ("ext4: use __GFP_NOFAIL in ext4_free_blocks()")

Signed-off-by Konstantin Khlebnikov <[email protected]>

Signed-off-by Theodore Ts'o <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 fs/ext4/mballoc.c |   23 ++++++++++++++---------
 1 file changed, 14 insertions(+), 9 deletions(-)

fs/ext4/mballoc.c +14 -9

@@ -3877,7 +3877,8 @@ ext4_mb_discard_group_preallocations(str
 
 	err = ext4_mb_load_buddy(sb, group, &e4b);
 	if (err) {
-		ext4_error(sb, "Error loading buddy information for %u", group);
+		ext4_warning(sb, "Error %d loading buddy information for %u",
+			     err, group);
 		put_bh(bitmap_bh);
 		return 0;
 	}

@@ -4034,10 +4035,11 @@ repeat:
 		BUG_ON(pa->pa_type != MB_INODE_PA);
 		group = ext4_get_group_number(sb, pa->pa_pstart);
 
-		err = ext4_mb_load_buddy(sb, group, &e4b);
+		err = ext4_mb_load_buddy_gfp(sb, group, &e4b,
+					     GFP_NOFS|__GFP_NOFAIL);
 		if (err) {
-			ext4_error(sb, "Error loading buddy information for %u",
-					group);
+			ext4_error(sb, "Error %d loading buddy information for %u",
+				   err, group);
 			continue;
 		}

@@ -4293,11 +4295,14 @@ ext4_mb_discard_lg_preallocations(struct
 	spin_unlock(&lg->lg_prealloc_lock);
 
 	list_for_each_entry_safe(pa, tmp, &discard_list, u.pa_tmp_list) {
+		int err;
 
 		group = ext4_get_group_number(sb, pa->pa_pstart);
-		if (ext4_mb_load_buddy(sb, group, &e4b)) {
-			ext4_error(sb, "Error loading buddy information for %u",
-					group);
+		err = ext4_mb_load_buddy_gfp(sb, group, &e4b,
+					     GFP_NOFS|__GFP_NOFAIL);
+		if (err) {
+			ext4_error(sb, "Error %d loading buddy information for %u",
+				   err, group);
 			continue;
 		}
 		ext4_lock_group(sb, group);

@@ -5117,8 +5122,8 @@ ext4_trim_all_free(struct super_block *s
 
 	ret = ext4_mb_load_buddy(sb, group, &e4b);
 	if (ret) {
-		ext4_error(sb, "Error in loading buddy "
-				"information for %u", group);
+		ext4_warning(sb, "Error %d loading buddy information for %u",
+			     ret, group);
 		return ret;
 	}
 	bitmap = e4b.bd_bitmap;

Greg Kroah-Hartman

author maintainer

2018-04-11 18:33 UTC #90 lore raw

PATCH 88/310 ARM: davinci: da8xx: Create DSP device only when assigned memory

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Suman Anna <[email protected]>

[ Upstream commit f97f03578b997a8ec2b9bc4928f958a865137268 ]

The DSP device on Davinci platforms does not have an MMU and requires specific DDR memory to boot. This memory is reserved using the rproc_mem kernel boot parameter and is assigned to the device on non-DT boots. The remoteproc core uses the DMA API and so will fall back to assigning random memory if this memory is not assigned to the device, but the DSP remote processor boot will not be successful in such cases. So, check that memory has been reserved and assigned to the device specifically before even creating the DSP device.

Signed-off-by Suman Anna <[email protected]>

Signed-off-by Sekhar Nori <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 arch/arm/mach-davinci/devices-da8xx.c |   10 ++++++++++
 1 file changed, 10 insertions(+)

arch/arm/mach-davinci/devices-da8xx.c +10 -0

@@ -821,6 +821,8 @@ static struct platform_device da8xx_dsp
 	.resource	= da8xx_rproc_resources,
 };
 
+static bool rproc_mem_inited __initdata;
+
 #if IS_ENABLED(CONFIG_DA8XX_REMOTEPROC)
 
 static phys_addr_t rproc_base __initdata;

@@ -859,6 +861,8 @@ void __init da8xx_rproc_reserve_cma(void
 	ret = dma_declare_contiguous(&da8xx_dsp.dev, rproc_size, rproc_base, 0);
 	if (ret)
 		pr_err("%s: dma_declare_contiguous failed %d\n", __func__, ret);
+	else
+		rproc_mem_inited = true;
 }
 
 #else

@@ -873,6 +877,12 @@ int __init da8xx_register_rproc(void)
 {
 	int ret;
 
+	if (!rproc_mem_inited) {
+		pr_warn("%s: memory not reserved for DSP, not registering DSP device\n",
+			__func__);
+		return -ENOMEM;
+	}
+
 	ret = platform_device_register(&da8xx_dsp);
 	if (ret)
 		pr_err("%s: can't register DSP device: %d\n", __func__, ret);

Greg Kroah-Hartman

author maintainer

2018-04-11 18:33 UTC #91 lore raw

PATCH 89/310 ray_cs: Avoid reading past end of buffer

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Kees Cook <[email protected]>

[ Upstream commit e48d661eb13f2f83861428f001c567fdb3f317e8 ]

Using memcpy() from a buffer that is shorter than the length copied means the destination buffer is being filled with arbitrary data from the kernel rodata segment. In this case, the source was made longer, since it did not match the destination structure size. Additionally removes a needless cast.

This was found with the future CONFIG_FORTIFY_SOURCE feature.

Cc Daniel Micay <[email protected]>

Signed-off-by Kees Cook <[email protected]>

Signed-off-by Kalle Valo <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/net/wireless/ray_cs.c |    7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

drivers/net/wireless/ray_cs.c +5 -2

@@ -247,7 +247,10 @@ static const UCHAR b4_default_startup_pa
 	0x04, 0x08,		/* Noise gain, limit offset */
 	0x28, 0x28,		/* det rssi, med busy offsets */
 	7,			/* det sync thresh */
-	0, 2, 2			/* test mode, min, max */
+	0, 2, 2,		/* test mode, min, max */
+	0,			/* rx/tx delay */
+	0, 0, 0, 0, 0, 0,	/* current BSS id */
+	0			/* hop set */
 };
 
 /*===========================================================================*/

@@ -598,7 +601,7 @@ static void init_startup_params(ray_dev_
 	 *    a_beacon_period = hops    a_beacon_period = KuS
 	 *//* 64ms = 010000 */
 	if (local->fw_ver == 0x55) {
-		memcpy((UCHAR *) &local->sparm.b4, b4_default_startup_parms,
+		memcpy(&local->sparm.b4, b4_default_startup_parms,
 		       sizeof(struct b4_startup_params));
 		/* Translate sane kus input values to old build 4/5 format */
 		/* i = hop time in uS truncated to 3 bytes */

Greg Kroah-Hartman

author maintainer

2018-04-11 18:33 UTC #92 lore raw

PATCH 90/310 net/wan/fsl_ucc_hdlc: fix muram allocation error

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Holger Brunck <[email protected]>

[ Upstream commit 85deed56032b6c98b541895bfda9bdd74f6ed987 ]

sizeof(priv->ucc_pram) is 4 as it is the size of a pointer, but we want to reserve space for the struct ucc_hdlc_param.

Cc Zhao Qiang <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/net/wan/fsl_ucc_hdlc.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

drivers/net/wan/fsl_ucc_hdlc.c +1 -1

@@ -158,7 +158,7 @@ static int uhdlc_init(struct ucc_hdlc_pr
 	}
 
 	/* Alloc parameter ram for ucc hdlc */
-	priv->ucc_pram_offset = qe_muram_alloc(sizeof(priv->ucc_pram),
+	priv->ucc_pram_offset = qe_muram_alloc(sizeof(struct ucc_hdlc_param),
 				ALIGNMENT_OF_UCC_HDLC_PRAM);
 
 	if (priv->ucc_pram_offset < 0) {

Greg Kroah-Hartman

author maintainer

2018-04-11 18:33 UTC #93 lore raw

PATCH 91/310 leds: pca955x: Correct I2C Functionality

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Tin Huynh <[email protected]>

[ Upstream commit aace34c0bb8ea3c8bdcec865b6a4be4db0a68e33 ]

The driver checks an incorrect flag of functionality of adapter. When a driver requires i2c_smbus_read_byte_data and i2c_smbus_write_byte_data, it should check I2C_FUNC_SMBUS_BYTE_DATA instead I2C_FUNC_I2C.
This patch fixes the problem.

Signed-off-by Tin Huynh <[email protected]>

Signed-off-by Jacek Anaszewski <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/leds/leds-pca955x.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

drivers/leds/leds-pca955x.c +1 -1

@@ -266,7 +266,7 @@ static int pca955x_probe(struct i2c_clie
 			"slave address 0x%02x\n",
 			id->name, chip->bits, client->addr);
 
-	if (!i2c_check_functionality(adapter, I2C_FUNC_I2C))
+	if (!i2c_check_functionality(adapter, I2C_FUNC_SMBUS_BYTE_DATA))
 		return -EIO;
 
 	if (pdata) {

Greg Kroah-Hartman

author maintainer

2018-04-11 18:33 UTC #94 lore raw

PATCH 92/310 perf/core: Fix error handling in perf_event_alloc()

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Dan Carpenter <[email protected]>

[ Upstream commit 36cc2b9222b5106de34085c4dd8635ac67ef5cba ]

We don't set an error code here which means that perf_event_alloc() returns ERR_PTR(0) (in other words NULL). The callers are not expecting that and would Oops.

Link http://lkml.kernel.org/r/20170522090418.hvs6icgpdo53wkn5@mwanda open here

Signed-off-by Peter Zijlstra (Intel) <[email protected]>

Cc Alexander Shishkin <[email protected]>

Cc Arnaldo Carvalho de Melo <[email protected]>

Cc Jiri Olsa <[email protected]>

Cc Linus Torvalds <[email protected]>

Cc Peter Zijlstra <[email protected]>

Cc Stephane Eranian <[email protected]>

Cc Thomas Gleixner <[email protected]>

Cc Vince Weaver <[email protected]>

Fixes 375637bc5249 ("perf/core: Introduce address range filtering")

Signed-off-by Ingo Molnar <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 kernel/events/core.c |    4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

kernel/events/core.c +3 -1

@@ -9289,8 +9289,10 @@ perf_event_alloc(struct perf_event_attr
 		event->addr_filters_offs = kcalloc(pmu->nr_addr_filters,
 						   sizeof(unsigned long),
 						   GFP_KERNEL);
-		if (!event->addr_filters_offs)
+		if (!event->addr_filters_offs) {
+			err = -ENOMEM;
 			goto err_per_task;
+		}
 
 		/* force hw sync on the address filters */
 		event->addr_filters_gen = 1;

Greg Kroah-Hartman

author maintainer

2018-04-11 18:33 UTC #95 lore raw

PATCH 93/310 sched/numa: Use down_read_trylock() for the mmap_sem

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Vlastimil Babka <[email protected]>

[ Upstream commit 8655d5497735b288f8a9b458bd22e7d1bf95bb61 ]

A customer has reported a soft-lockup when running an intensive memory stress test, where the trace on multiple CPU's looks like this:

 RIP: 0010:[<ffffffff810c53fe>]
  [<ffffffff810c53fe>] native_queued_spin_lock_slowpath+0x10e/0x190
...
 Call Trace:
  [<ffffffff81182d07>] queued_spin_lock_slowpath+0x7/0xa
  [<ffffffff811bc331>] change_protection_range+0x3b1/0x930
  [<ffffffff811d4be8>] change_prot_numa+0x18/0x30
  [<ffffffff810adefe>] task_numa_work+0x1fe/0x310
  [<ffffffff81098322>] task_work_run+0x72/0x90

Further investigation showed that the lock contention here is pmd_lock().

The task_numa_work() function makes sure that only one thread is let to perform the work in a single scan period (via cmpxchg), but if there's a thread with mmap_sem locked for writing for several periods, multiple threads in task_numa_work() can build up a convoy waiting for mmap_sem for read and then all get unblocked at once.

This patch changes the down_read() to the trylock version, which prevents the build up. For a workload experiencing mmap_sem contention, it's probably better to postpone the NUMA balancing work anyway. This seems to have fixed the soft lockups involving pmd_lock(), which is in line with the convoy theory.

Signed-off-by Vlastimil Babka <[email protected]>

Signed-off-by Peter Zijlstra (Intel) <[email protected]>

Acked-by Rik van Riel <[email protected]>

Acked-by Mel Gorman <[email protected]>

Cc Linus Torvalds <[email protected]>

Cc Peter Zijlstra <[email protected]>

Cc Thomas Gleixner <[email protected]>

Link http://lkml.kernel.org/r/[email protected] open here

Signed-off-by Ingo Molnar <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 kernel/sched/fair.c |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

kernel/sched/fair.c +2 -1

@@ -2429,7 +2429,8 @@ void task_numa_work(struct callback_head
 		return;
 
 
-	down_read(&mm->mmap_sem);
+	if (!down_read_trylock(&mm->mmap_sem))
+		return;
 	vma = find_vma(mm, start);
 	if (!vma) {
 		reset_ptenuma_scan(p);

Greg Kroah-Hartman

author maintainer

2018-04-11 18:33 UTC #96 lore raw

PATCH 94/310 gpio: crystalcove: Do not write regular gpio registers for virtual GPIOs

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Hans de Goede <[email protected]>

[ Upstream commit 9a752b4c9ab924033bfdb8784c680d50b2bd5684 ]

The Crystal Cove PMIC has 16 real GPIOs but the ACPI code for devices with this PMIC may address up to 95 GPIOs, these extra GPIOs are called virtual GPIOs and are used by the ACPI code as a method of accessing various non GPIO bits of PMIC.

Commit dcdc3018d635 ("gpio: crystalcove: support virtual GPIO") added dummy support for these to avoid a bunch of ACPI errors, but instead of ignoring writes / reads to them by doing:

if (gpio >= CRYSTALCOVE_GPIO_NUM)

	return 0;

It accidentally introduced the following wrong check:

if (gpio > CRYSTALCOVE_VGPIO_NUM)

	return 0;

Which means that attempts by the ACPI code to access these gpios causes some arbitrary gpio to get touched through for example GPIO1P0CTLO + gpionr % 8.

Since we do support input/output (but not interrupts) on the 0x5e virtual GPIO, this commit makes to_reg return -ENOTSUPP for unsupported virtual GPIOs so as to not have to check for (gpio >= CRYSTALCOVE_GPIO_NUM && gpio != 0x5e) everywhere and to make it easier to add support for more virtual GPIOs in the future.

It then adds a check for to_reg returning an error to all callers where this may happen fixing the ACPI code accessing virtual GPIOs accidentally causing changes to real GPIOs.

Fixes dcdc3018d635 ("gpio: crystalcove: support virtual GPIO")

Cc Aaron Lu <[email protected]>

Reviewed-by Andy Shevchenko <[email protected]>

Signed-off-by Linus Walleij <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/gpio/gpio-crystalcove.c |   54 ++++++++++++++++++++++++++--------------
 1 file changed, 36 insertions(+), 18 deletions(-)

drivers/gpio/gpio-crystalcove.c +36 ~~-18~~

@@ -90,8 +90,18 @@ static inline int to_reg(int gpio, enum
 {
 	int reg;
 
-	if (gpio == 94)
-		return GPIOPANELCTL;
+	if (gpio >= CRYSTALCOVE_GPIO_NUM) {
+		/*
+		 * Virtual GPIO called from ACPI, for now we only support
+		 * the panel ctl.
+		 */
+		switch (gpio) {
+		case 0x5e:
+			return GPIOPANELCTL;
+		default:
+			return -EOPNOTSUPP;
+		}
+	}
 
 	if (reg_type == CTRL_IN) {
 		if (gpio < 8)

@@ -130,36 +140,36 @@ static void crystalcove_update_irq_ctrl(
 static int crystalcove_gpio_dir_in(struct gpio_chip *chip, unsigned gpio)
 {
 	struct crystalcove_gpio *cg = gpiochip_get_data(chip);
+	int reg = to_reg(gpio, CTRL_OUT);
 
-	if (gpio > CRYSTALCOVE_VGPIO_NUM)
+	if (reg < 0)
 		return 0;
 
-	return regmap_write(cg->regmap, to_reg(gpio, CTRL_OUT),
-			    CTLO_INPUT_SET);
+	return regmap_write(cg->regmap, reg, CTLO_INPUT_SET);
 }
 
 static int crystalcove_gpio_dir_out(struct gpio_chip *chip, unsigned gpio,
 				    int value)
 {
 	struct crystalcove_gpio *cg = gpiochip_get_data(chip);
+	int reg = to_reg(gpio, CTRL_OUT);
 
-	if (gpio > CRYSTALCOVE_VGPIO_NUM)
+	if (reg < 0)
 		return 0;
 
-	return regmap_write(cg->regmap, to_reg(gpio, CTRL_OUT),
-			    CTLO_OUTPUT_SET | value);
+	return regmap_write(cg->regmap, reg, CTLO_OUTPUT_SET | value);
 }
 
 static int crystalcove_gpio_get(struct gpio_chip *chip, unsigned gpio)
 {
 	struct crystalcove_gpio *cg = gpiochip_get_data(chip);
-	int ret;
 	unsigned int val;
+	int ret, reg = to_reg(gpio, CTRL_IN);
 
-	if (gpio > CRYSTALCOVE_VGPIO_NUM)
+	if (reg < 0)
 		return 0;
 
-	ret = regmap_read(cg->regmap, to_reg(gpio, CTRL_IN), &val);
+	ret = regmap_read(cg->regmap, reg, &val);
 	if (ret)
 		return ret;

@@ -170,14 +180,15 @@ static void crystalcove_gpio_set(struct
 				 unsigned gpio, int value)
 {
 	struct crystalcove_gpio *cg = gpiochip_get_data(chip);
+	int reg = to_reg(gpio, CTRL_OUT);
 
-	if (gpio > CRYSTALCOVE_VGPIO_NUM)
+	if (reg < 0)
 		return;
 
 	if (value)
-		regmap_update_bits(cg->regmap, to_reg(gpio, CTRL_OUT), 1, 1);
+		regmap_update_bits(cg->regmap, reg, 1, 1);
 	else
-		regmap_update_bits(cg->regmap, to_reg(gpio, CTRL_OUT), 1, 0);
+		regmap_update_bits(cg->regmap, reg, 1, 0);
 }
 
 static int crystalcove_irq_type(struct irq_data *data, unsigned type)

@@ -185,6 +196,9 @@ static int crystalcove_irq_type(struct i
 	struct crystalcove_gpio *cg =
 		gpiochip_get_data(irq_data_get_irq_chip_data(data));
 
+	if (data->hwirq >= CRYSTALCOVE_GPIO_NUM)
+		return 0;
+
 	switch (type) {
 	case IRQ_TYPE_NONE:
 		cg->intcnt_value = CTLI_INTCNT_DIS;

@@ -235,8 +249,10 @@ static void crystalcove_irq_unmask(struc
 	struct crystalcove_gpio *cg =
 		gpiochip_get_data(irq_data_get_irq_chip_data(data));
 
-	cg->set_irq_mask = false;
-	cg->update |= UPDATE_IRQ_MASK;
+	if (data->hwirq < CRYSTALCOVE_GPIO_NUM) {
+		cg->set_irq_mask = false;
+		cg->update |= UPDATE_IRQ_MASK;
+	}
 }
 
 static void crystalcove_irq_mask(struct irq_data *data)

@@ -244,8 +260,10 @@ static void crystalcove_irq_mask(struct
 	struct crystalcove_gpio *cg =
 		gpiochip_get_data(irq_data_get_irq_chip_data(data));
 
-	cg->set_irq_mask = true;
-	cg->update |= UPDATE_IRQ_MASK;
+	if (data->hwirq < CRYSTALCOVE_GPIO_NUM) {
+		cg->set_irq_mask = true;
+		cg->update |= UPDATE_IRQ_MASK;
+	}
 }
 
 static struct irq_chip crystalcove_irqchip = {

Greg Kroah-Hartman

author maintainer

2018-04-11 18:33 UTC #97 lore raw

PATCH 95/310 net/mlx5: Tolerate irq_set_affinity_hint() failures

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Tariq Toukan <[email protected]>

[ Upstream commit b665d98edc9ab295169be2fc5bb4e89a46de0a1a ]

Add tolerance to failures of irq_set_affinity_hint(). Its role is to give hints that optimizes performance, and should not block the driver load.

In non-SMP systems, functionality is not available as there is a single core, and all these calls definitely fail. Hence, do not call the function and avoid the warning prints.

Fixes db058a186f98 ("net/mlx5_core: Set irq affinity hints")

Signed-off-by Tariq Toukan <[email protected]>

Signed-off-by Saeed Mahameed <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/net/ethernet/mellanox/mlx5/core/main.c |   15 ++++-----------
 1 file changed, 4 insertions(+), 11 deletions(-)

drivers/net/ethernet/mellanox/mlx5/core/main.c +4 ~~-11~~

@@ -548,7 +548,6 @@ static int mlx5_irq_set_affinity_hint(st
 	struct mlx5_priv *priv  = &mdev->priv;
 	struct msix_entry *msix = priv->msix_arr;
 	int irq                 = msix[i + MLX5_EQ_VEC_COMP_BASE].vector;
-	int err;
 
 	if (!zalloc_cpumask_var(&priv->irq_info[i].mask, GFP_KERNEL)) {
 		mlx5_core_warn(mdev, "zalloc_cpumask_var failed");

@@ -558,18 +557,12 @@ static int mlx5_irq_set_affinity_hint(st
 	cpumask_set_cpu(cpumask_local_spread(i, priv->numa_node),
 			priv->irq_info[i].mask);
 
-	err = irq_set_affinity_hint(irq, priv->irq_info[i].mask);
-	if (err) {
-		mlx5_core_warn(mdev, "irq_set_affinity_hint failed,irq 0x%.4x",
-			       irq);
-		goto err_clear_mask;
-	}
+#ifdef CONFIG_SMP
+	if (irq_set_affinity_hint(irq, priv->irq_info[i].mask))
+		mlx5_core_warn(mdev, "irq_set_affinity_hint failed, irq 0x%.4x", irq);
+#endif
 
 	return 0;
-
-err_clear_mask:
-	free_cpumask_var(priv->irq_info[i].mask);
-	return err;
 }
 
 static void mlx5_irq_clear_affinity_hint(struct mlx5_core_dev *mdev, int i)

Greg Kroah-Hartman

author maintainer

2018-04-11 18:33 UTC #98 lore raw

PATCH 96/310 selinux: do not check open permission on sockets

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Stephen Smalley <[email protected]>

[ Upstream commit ccb544781d34afdb73a9a73ae53035d824d193bf ]

open permission is currently only defined for files in the kernel (COMMON_FILE_PERMS rather than COMMON_FILE_SOCK_PERMS). Construction of an artificial test case that tries to open a socket via /proc/pid/fd will generate a recvfrom avc denial because recvfrom and open happen to map to the same permission bit in socket vs file classes.

open of a socket via /proc/pid/fd is not supported by the kernel regardless and will ultimately return ENXIO. But we hit the permission check first and can thus produce these odd/misleading denials. Omit the open check when operating on a socket.

Signed-off-by Stephen Smalley <[email protected]>

Signed-off-by Paul Moore <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 security/selinux/hooks.c |   10 +++++++---
 1 file changed, 7 insertions(+), 3 deletions(-)

security/selinux/hooks.c +7 -3

@@ -2033,8 +2033,9 @@ static inline u32 file_to_av(struct file
 static inline u32 open_file_to_av(struct file *file)
 {
 	u32 av = file_to_av(file);
+	struct inode *inode = file_inode(file);
 
-	if (selinux_policycap_openperm)
+	if (selinux_policycap_openperm && inode->i_sb->s_magic != SOCKFS_MAGIC)
 		av |= FILE__OPEN;
 
 	return av;

@@ -3031,6 +3032,7 @@ static int selinux_inode_permission(stru
 static int selinux_inode_setattr(struct dentry *dentry, struct iattr *iattr)
 {
 	const struct cred *cred = current_cred();
+	struct inode *inode = d_backing_inode(dentry);
 	unsigned int ia_valid = iattr->ia_valid;
 	__u32 av = FILE__WRITE;

@@ -3046,8 +3048,10 @@ static int selinux_inode_setattr(struct
 			ATTR_ATIME_SET | ATTR_MTIME_SET | ATTR_TIMES_SET))
 		return dentry_has_perm(cred, dentry, FILE__SETATTR);
 
-	if (selinux_policycap_openperm && (ia_valid & ATTR_SIZE)
-			&& !(ia_valid & ATTR_FILE))
+	if (selinux_policycap_openperm &&
+	    inode->i_sb->s_magic != SOCKFS_MAGIC &&
+	    (ia_valid & ATTR_SIZE) &&
+	    !(ia_valid & ATTR_FILE))
 		av |= FILE__OPEN;
 
 	return dentry_has_perm(cred, dentry, av);

Greg Kroah-Hartman

author maintainer

2018-04-11 18:33 UTC #99 lore raw

PATCH 97/310 block: fix an error code in add_partition()

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Dan Carpenter <[email protected]>

[ Upstream commit 7bd897cfce1eb373892d35d7f73201b0f9b221c4 ]

We don't set an error code on this path. It means that we return NULL instead of an error pointer and the caller does a NULL dereference.

Fixes 6d1d8050b4bc ("block, partition: add partition_meta_info to hd_struct")

Signed-off-by Jens Axboe <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 block/partition-generic.c |    4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

block/partition-generic.c +3 -1

@@ -321,8 +321,10 @@ struct hd_struct *add_partition(struct g
 
 	if (info) {
 		struct partition_meta_info *pinfo = alloc_part_info(disk);
-		if (!pinfo)
+		if (!pinfo) {
+			err = -ENOMEM;
 			goto out_free_stats;
+		}
 		memcpy(pinfo, info, sizeof(*info));
 		p->info = pinfo;
 	}

Greg Kroah-Hartman

author maintainer

2018-04-11 18:33 UTC #100 lore raw

PATCH 98/310 mlx5: fix bug reading rss_hash_type from CQE

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Jesper Dangaard Brouer <[email protected]>

[ Upstream commit 12e8b570e732eaa5eae3a2895ba3fbcf91bde2b4 ]

Masks for extracting part of the Completion Queue Entry (CQE) field rss_hash_type was swapped, namely CQE_RSS_HTYPE_IP and CQE_RSS_HTYPE_L4.

The bug resulted in setting skb->l4_hash, even-though the rss_hash_type indicated that hash was NOT computed over the L4 (UDP or TCP) part of the packet.

Added comments from the datasheet, to make it more clear what these masks are selecting.

Signed-off-by Jesper Dangaard Brouer <[email protected]>

Acked-by Saeed Mahameed <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 include/linux/mlx5/device.h |   10 ++++++++--
 1 file changed, 8 insertions(+), 2 deletions(-)

include/linux/mlx5/device.h +8 -2

@@ -750,8 +750,14 @@ enum {
 };
 
 enum {
-	CQE_RSS_HTYPE_IP	= 0x3 << 6,
-	CQE_RSS_HTYPE_L4	= 0x3 << 2,
+	CQE_RSS_HTYPE_IP	= 0x3 << 2,
+	/* cqe->rss_hash_type[3:2] - IP destination selected for hash
+	 * (00 = none,  01 = IPv4, 10 = IPv6, 11 = Reserved)
+	 */
+	CQE_RSS_HTYPE_L4	= 0x3 << 6,
+	/* cqe->rss_hash_type[7:6] - L4 destination selected for hash
+	 * (00 = none, 01 = TCP. 10 = UDP, 11 = IPSEC.SPI
+	 */
 };
 
 enum {

Greg Kroah-Hartman

author maintainer

2018-04-11 18:33 UTC #101 lore raw

PATCH 99/310 net: ieee802154: fix net_device reference release too early

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Lin Zhang <[email protected]>

[ Upstream commit a611c58b3d42a92e6b23423e166dd17c0c7fffce ]

This patch fixes the kernel oops when release net_device reference in advance. In function raw_sendmsg(i think the dgram_sendmsg has the same problem), there is a race condition between dev_put and dev_queue_xmit when the device is gong that maybe lead to dev_queue_ximt to see an illegal net_device pointer.

My test kernel is 3.13.0-32 and because i am not have a real 802154 device, so i change lowpan_newlink function to this:

        /* find and hold real wpan device */
        real_dev = dev_get_by_index(src_net, nla_get_u32(tb[IFLA_LINK]));
        if (!real_dev)
                return -ENODEV;

// if (real_dev->type != ARPHRD_IEEE802154) {
// dev_put(real_dev);
// return -EINVAL;
// }

        lowpan_dev_info(dev)->real_dev = real_dev;
        lowpan_dev_info(dev)->fragment_tag = 0;
        mutex_init(&lowpan_dev_info(dev)->dev_list_mtx);

Also, in order to simulate preempt, i change the raw_sendmsg function to this:

        skb->dev = dev;
        skb->sk  = sk;
        skb->protocol = htons(ETH_P_IEEE802154);
        dev_put(dev);
        //simulate preempt
        schedule_timeout_uninterruptible(30 * HZ);
        err = dev_queue_xmit(skb);
        if (err > 0)
                err = net_xmit_errno(err);

and this is my userspace test code named test_send_data:

int main(int argc, char **argv)

{
        char buf[127];
        int sockfd;
        sockfd = socket(AF_IEEE802154, SOCK_RAW, 0);
        if (sockfd < 0) {
                printf("create sockfd error: %s\n", strerror(errno));
                return -1;
        }
        send(sockfd, buf, sizeof(buf), 0);
        return 0;
}

This is my test case:

root@zhanglin-x-computer:~/develop/802154# uname -a
Linux zhanglin-x-computer 3.13.0-32-generic #57-Ubuntu SMP Tue Jul 15
03:51:08 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
root@zhanglin-x-computer:~/develop/802154# ip link add link eth0 name
lowpan0 type lowpan
root@zhanglin-x-computer:~/develop/802154#
//keep the lowpan0 device down
root@zhanglin-x-computer:~/develop/802154# ./test_send_data &
//wait a while
root@zhanglin-x-computer:~/develop/802154# ip link del link dev lowpan0
//the device is gone
//oops
[381.303307] general protection fault: 0000 [#1]SMP
[381.303407] Modules linked in: af_802154 6lowpan bnep rfcomm
bluetooth nls_iso8859_1 snd_hda_codec_hdmi snd_hda_codec_realtek
rts5139(C) snd_hda_intel
snd_had_codec snd_hwdep snd_pcm snd_page_alloc snd_seq_midi
snd_seq_midi_event snd_rawmidi snd_req intel_rapl snd_seq_device
coretemp i915 kvm_intel
kvm snd_timer snd crct10dif_pclmul crc32_pclmul ghash_clmulni_intel
cypted drm_kms_helper drm i2c_algo_bit soundcore video mac_hid
parport_pc ppdev ip parport hid_generic
usbhid hid ahci r8169 mii libahdi
[381.304286] CPU:1 PID: 2524 Commm: 1 Tainted: G C 0 3.13.0-32-generic
[381.304409] Hardware name: Haier Haier DT Computer/Haier DT Codputer,
BIOS FIBT19H02_X64 06/09/2014
[381.304546] tasks: ffff000096965fc0 ti: ffffB0013779c000 task.ti:
ffffB8013779c000
[381.304659] RIP: 0010:[<ffffffff01621fe1>] [<ffffffff81621fe1>]
__dev_queue_ximt+0x61/0x500
[381.304798] RSP: 0018:ffffB8013779dca0 EFLAGS: 00010202
[381.304880] RAX: 272b031d57565351 RBX: 0000000000000000 RCX: ffff8800968f1a00
[381.304987] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff8800968f1a00
[381.305095] RBP: ffff8e013773dce0 R08: 0000000000000266 R09: 0000000000000004
[381.305202] R10: 0000000000000004 R11: 0000000000000005 R12: ffff88013902e000
[381.305310] R13: 000000000000007f R14: 000000000000007f R15: ffff8800968f1a00
[381.305418] FS:  00007fc57f50f740(0000) GS: ffff88013fc80000(0000)
knlGS: 0000000000000000
[381.305540] CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[381.305627] CR2: 00007fad0841c000 CR3: 00000001368dd000 CR4: 00000000001007e0
[361.905734] Stack:
[381.305768]  00000000002052d0 000000003facb30a ffff88013779dcc0
ffff880137764000
[381.305898]  ffff88013779de70 000000000000007f 000000000000007f
ffff88013902e000
[381.306026]  ffff88013779dcf0 ffffffff81622490 ffff88013779dd39
ffffffffa03af9f1
[381.306155] Call Trace:
[381.306202]  [<ffffffff81622490>] dev_queue_xmit+0x10/0x20
[381.306294]  [<ffffffffa03af9f1>] raw_sendmsg+0x1b1/0x270 [af_802154]
[381.306396]  [<ffffffffa03af054>] ieee802154_sock_sendmsg+0x14/0x20 [af_802154]
[381.306512]  [<ffffffff816079eb>] sock_sendmsg+0x8b/0xc0
[381.306600]  [<ffffffff811d52a5>] ? __d_alloc+0x25/0x180
[381.306687]  [<ffffffff811a1f56>] ? kmem_cache_alloc_trace+0x1c6/0x1f0
[381.306791]  [<ffffffff81607b91>] SYSC_sendto+0x121/0x1c0
[381.306878]  [<ffffffff8109ddf4>] ? vtime_account_user+x54/0x60
[381.306975]  [<ffffffff81020d45>] ? syscall_trace_enter+0x145/0x250
[381.307073]  [<ffffffff816086ae>] SyS_sendto+0xe/0x10
[381.307156]  [<ffffffff8172c87f>] tracesys+0xe1/0xe6
[381.307233] Code: c6 a1 a4 ff 41 8b 57 78 49 8b 47 20 85 d2 48 8b 80
78 07 00 00 75 21 49 8b 57 18 48 85 d2 74 18 48 85 c0 74 13 8b 92 ac
01 00 00 <3b> 50 10 73 08 8b 44 90 14 41 89 47 78 41 f6 84 24 d5 00 00
00
[381.307801] RIP [<ffffffff81621fe1>] _dev_queue_xmit+0x61/0x500
[381.307901]  RSP <ffff88013779dca0>
[381.347512] Kernel panic - not syncing: Fatal exception in interrupt
[381.347747] drm_kms_helper: panic occurred, switching back to text console

In my opinion, there is always exist a chance that the device is gong before call dev_queue_xmit.

I think the latest kernel is have the same problem and that dev_put should be behind of the dev_queue_xmit.

Signed-off-by Lin Zhang <[email protected]>

Acked-by Stefan Schmidt <[email protected]>

Signed-off-by Marcel Holtmann <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 net/ieee802154/socket.c |    8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

net/ieee802154/socket.c +4 -4

@@ -304,12 +304,12 @@ static int raw_sendmsg(struct sock *sk,
 	skb->sk  = sk;
 	skb->protocol = htons(ETH_P_IEEE802154);
 
-	dev_put(dev);
-
 	err = dev_queue_xmit(skb);
 	if (err > 0)
 		err = net_xmit_errno(err);
 
+	dev_put(dev);
+
 	return err ?: size;
 
 out_skb:

@@ -693,12 +693,12 @@ static int dgram_sendmsg(struct sock *sk
 	skb->sk  = sk;
 	skb->protocol = htons(ETH_P_IEEE802154);
 
-	dev_put(dev);
-
 	err = dev_queue_xmit(skb);
 	if (err > 0)
 		err = net_xmit_errno(err);
 
+	dev_put(dev);
+
 	return err ?: size;
 
 out_skb:

Greg Kroah-Hartman

author maintainer

2018-04-11 18:33 UTC #102 lore raw

PATCH 100/310 libceph: NULL deref on crush_decode() error path

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Dan Carpenter <[email protected]>

[ Upstream commit 293dffaad8d500e1a5336eeb90d544cf40d4fbd8 ]

If there is not enough space then ceph_decode_32_safe() does a goto bad. We need to return an error code in that situation. The current code returns ERR_PTR(0) which is NULL. The callers are not expecting that and it results in a NULL dereference.

Fixes f24e9980eb86 ("ceph: OSD client")

Reviewed-by Ilya Dryomov <[email protected]>

Signed-off-by Ilya Dryomov <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 net/ceph/osdmap.c |    1 +
 1 file changed, 1 insertion(+)

net/ceph/osdmap.c +1 -0

@@ -295,6 +295,7 @@ static struct crush_map *crush_decode(vo
 		u32 yes;
 		struct crush_rule *r;
 
+		err = -EINVAL;
 		ceph_decode_32_safe(p, end, yes, bad);
 		if (!yes) {
 			dout("crush_decode NO rule %d off %x %p to %p\n",

Greg Kroah-Hartman

author maintainer

2018-04-11 18:34 UTC #103 lore raw

PATCH 101/310 perf report: Fix off-by-one for non-activation frames

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Milian Wolff <[email protected]>

[ Upstream commit 1982ad48fc82c284a5cc55697a012d3357e84d01 ]

As the documentation for dwfl_frame_pc says, frames that are no activation frames need to have their program counter decremented by one to properly find the function of the caller.

This fixes many cases where perf report currently attributes the cost to the next line. I.e. I have code like this:

~~~~~~~~~~~~~~~
#include <thread>
#include <chrono>

using namespace std;

  int main()
  {
    this_thread::sleep_for(chrono::milliseconds(1000));
    this_thread::sleep_for(chrono::milliseconds(100));
    this_thread::sleep_for(chrono::milliseconds(10));

    return 0;

}
~~~~~~~~~~~~~~~

Now compile and record it:

~~~~~~~~~~~~~~~
g++ -std=c++11 -g -O2 test.cpp
echo 1 | sudo tee /proc/sys/kernel/sched_schedstats

  perf record \
    --event sched:sched_stat_sleep \
    --event sched:sched_process_exit \
    --event sched:sched_switch --call-graph=dwarf \
    --output perf.data.raw \
    ./a.out

echo 0 | sudo tee /proc/sys/kernel/sched_schedstats perf inject --sched-stat --input perf.data.raw --output perf.data
~~~~~~~~~~~~~~~

Before this patch, the report clearly shows the off-by-one issue. Most notably, the last sleep invocation is incorrectly attributed to the "return 0;" line:

~~~~~~~~~~~~~~~
Overhead Source:Line
........ ...........

100.00% core.c:0

            |
            ---__schedule core.c:0
               schedule
               do_nanosleep hrtimer.c:0
               hrtimer_nanosleep
               sys_nanosleep
               entry_SYSCALL_64_fastpath .tmp_entry_64.o:0
               __nanosleep_nocancel .:0
               std::this_thread::sleep_for<long, std::ratio<1l, 1000l> > thread:323
               |
               |--90.08%--main test.cpp:9
               |          __libc_start_main
               |          _start
               |
               |--9.01%--main test.cpp:10
               |          __libc_start_main
               |          _start
               |
                --0.91%--main test.cpp:13
                          __libc_start_main
                          _start

~~~~~~~~~~~~~~~

With this patch here applied, the issue is fixed. The report becomes much more usable:

~~~~~~~~~~~~~~~
Overhead Source:Line
........ ...........

100.00% core.c:0

            |
            ---__schedule core.c:0
               schedule
               do_nanosleep hrtimer.c:0
               hrtimer_nanosleep
               sys_nanosleep
               entry_SYSCALL_64_fastpath .tmp_entry_64.o:0
               __nanosleep_nocancel .:0
               std::this_thread::sleep_for<long, std::ratio<1l, 1000l> > thread:323
               |
               |--90.08%--main test.cpp:8
               |          __libc_start_main
               |          _start
               |
               |--9.01%--main test.cpp:9
               |          __libc_start_main
               |          _start
               |
                --0.91%--main test.cpp:10
                          __libc_start_main
                          _start

~~~~~~~~~~~~~~~

Similarly it works for signal frames:

~~~~~~~~~~~~~~~
__noinline void bar(void)

  {
    volatile long cnt = 0;

    for (cnt = 0; cnt < 100000000; cnt++);

}

  __noinline void foo(void)
  {
    bar();
  }

  void sig_handler(int sig)
  {
    foo();
  }

  int main(void)
  {
    signal(SIGUSR1, sig_handler);
    raise(SIGUSR1);

    foo();
    return 0;

}
~~~~~~~~~~~~~~~~

Before, the report wrongly points to signal.c:29 after raise():

~~~~~~~~~~~~~~~~

  $ perf report --stdio --no-children -g srcline -s srcline
  ...
   100.00%  signal.c:11
            |
            ---bar signal.c:11
               |
               |--50.49%--main signal.c:29
               |          __libc_start_main
               |          _start
               |
                --49.51%--0x33a8f
                          raise .:0
                          main signal.c:29
                          __libc_start_main
                          _start
~~~~~~~~~~~~~~~~

With this patch in, the issue is fixed and we instead get:

~~~~~~~~~~~~~~~~
100.00% signal signal [.] bar

            |
            ---bar signal.c:11
               |
               |--50.49%--main signal.c:29
               |          __libc_start_main
               |          _start
               |
                --49.51%--0x33a8f
                          raise .:0
                          main signal.c:27
                          __libc_start_main
                          _start

~~~~~~~~~~~~~~~~

Note how this patch fixes this issue for both unwinding methods, i.e. both dwfl and libunwind. The former case is straight-forward thanks to dwfl_frame_pc(). For libunwind, we replace the functionality via unw_is_signal_frame() for any but the very first frame.

Signed-off-by Milian Wolff <[email protected]>

Signed-off-by Namhyung Kim <[email protected]>

Cc Arnaldo Carvalho de Melo <[email protected]>

Cc David Ahern <[email protected]>

Cc Jiri Olsa <[email protected]>

Cc Linus Torvalds <[email protected]>

Cc Peter Zijlstra <[email protected]>

Cc Thomas Gleixner <[email protected]>

Cc Yao Jin <[email protected]>

Link http://lkml.kernel.org/r/[email protected] open here

Signed-off-by Ingo Molnar <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 tools/perf/util/unwind-libdw.c           |    6 +++++-
 tools/perf/util/unwind-libunwind-local.c |   11 +++++++++++
 2 files changed, 16 insertions(+), 1 deletion(-)

tools/perf/util/unwind-libdw.c +5 -1

@@ -167,12 +167,16 @@ frame_callback(Dwfl_Frame *state, void *
 {
 	struct unwind_info *ui = arg;
 	Dwarf_Addr pc;
+	bool isactivation;
 
-	if (!dwfl_frame_pc(state, &pc, NULL)) {
+	if (!dwfl_frame_pc(state, &pc, &isactivation)) {
 		pr_err("%s", dwfl_errmsg(-1));
 		return DWARF_CB_ABORT;
 	}
 
+	if (!isactivation)
+		--pc;
+
 	return entry(pc, ui) || !(--ui->max_stack) ?
 	       DWARF_CB_ABORT : DWARF_CB_OK;
 }

tools/perf/util/unwind-libunwind-local.c +11 -0

@@ -646,6 +646,17 @@ static int get_entries(struct unwind_inf
 
 		while (!ret && (unw_step(&c) > 0) && i < max_stack) {
 			unw_get_reg(&c, UNW_REG_IP, &ips[i]);
+
+			/*
+			 * Decrement the IP for any non-activation frames.
+			 * this is required to properly find the srcline
+			 * for caller frames.
+			 * See also the documentation for dwfl_frame_pc(),
+			 * which this code tries to replicate.
+			 */
+			if (unw_is_signal_frame(&c) <= 0)
+				--ips[i];
+
 			++i;
 		}

Greg Kroah-Hartman

author maintainer

2018-04-11 18:34 UTC #104 lore raw

PATCH 102/310 netfilter: ctnetlink: fix incorrect nf_ct_put during hash resize

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Liping Zhang <[email protected]>

[ Upstream commit fefa92679dbe0c613e62b6c27235dcfbe9640ad1 ]

If nf_conntrack_htable_size was adjusted by the user during the ct dump operation, we may invoke nf_ct_put twice for the same ct, i.e. the "last" ct. This will cause the ct will be freed but still linked in hash buckets.

It's very easy to reproduce the problem by the following commands:

  # while : ; do
  echo $RANDOM > /proc/sys/net/netfilter/nf_conntrack_buckets
  done
  # while : ; do
  conntrack -L
  done
  # iperf -s 127.0.0.1 &
  # iperf -c 127.0.0.1 -P 60 -t 36000

After a while, the system will hang like this:
NMI watchdog: BUG: soft lockup - CPU#1 stuck for 22s! [bash:20184] NMI watchdog: BUG: soft lockup - CPU#0 stuck for 22s! [iperf:20382]
...

So at last if we find cb->args[1] is equal to "last", this means hash resize happened, then we can set cb->args[1] to 0 to fix the above issue.

Fixes d205dc40798d ("[NETFILTER]: ctnetlink: fix deadlock in table dumping")

Signed-off-by Liping Zhang <[email protected]>

Signed-off-by Pablo Neira Ayuso <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 net/netfilter/nf_conntrack_netlink.c |    7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

net/netfilter/nf_conntrack_netlink.c +6 -1

@@ -890,8 +890,13 @@ restart:
 	}
 out:
 	local_bh_enable();
-	if (last)
+	if (last) {
+		/* nf ct hash resize happened, now clear the leftover. */
+		if ((struct nf_conn *)cb->args[1] == last)
+			cb->args[1] = 0;
+
 		nf_ct_put(last);
+	}
 
 	while (i) {
 		i--;

Greg Kroah-Hartman

author maintainer

2018-04-11 18:34 UTC #106 lore raw

PATCH 104/310 ASoC: rsnd: SSI PIO adjust to 24bit mode

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Kuninori Morimoto <[email protected]>

[ Upstream commit 7819a942de7b993771bd9377babc80485fe7606b ]

commit 90431eb49bff ("ASoC: rsnd: don't use PDTA bit for 24bit on SSI") fixups 24bit mode data alignment, but PIO was not cared. This patch fixes PIO mode 24bit data alignment

Signed-off-by Kuninori Morimoto <[email protected]>

Signed-off-by Mark Brown <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 sound/soc/sh/rcar/ssi.c |   11 +++++++++--
 1 file changed, 9 insertions(+), 2 deletions(-)

sound/soc/sh/rcar/ssi.c +9 -2

@@ -552,6 +552,13 @@ static void __rsnd_ssi_interrupt(struct
 		struct snd_pcm_runtime *runtime = rsnd_io_to_runtime(io);
 		u32 *buf = (u32 *)(runtime->dma_area +
 				   rsnd_dai_pointer_offset(io, 0));
+		int shift = 0;
+
+		switch (runtime->sample_bits) {
+		case 32:
+			shift = 8;
+			break;
+		}
 
 		/*
 		 * 8/16/32 data can be assesse to TDR/RDR register

@@ -559,9 +566,9 @@ static void __rsnd_ssi_interrupt(struct
 		 * see rsnd_ssi_init()
 		 */
 		if (rsnd_io_is_play(io))
-			rsnd_mod_write(mod, SSITDR, *buf);
+			rsnd_mod_write(mod, SSITDR, (*buf) << shift);
 		else
-			*buf = rsnd_mod_read(mod, SSIRDR);
+			*buf = (rsnd_mod_read(mod, SSIRDR) >> shift);
 
 		elapsed = rsnd_dai_pointer_update(io, sizeof(*buf));
 	}

Greg Kroah-Hartman

author maintainer

2018-04-11 18:34 UTC #107 lore raw

PATCH 105/310 scsi: bnx2fc: fix race condition in bnx2fc_get_host_stats()

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Maurizio Lombardi <[email protected]>

[ Upstream commit c2dd893a3b0772d1c680e109b9d5715d7f73022b ]

If multiple tasks attempt to read the stats, it may happen that the start_req_done completion is re-initialized while still being used by another task, causing a list corruption.

This patch fixes the bug by adding a mutex to serialize the calls to bnx2fc_get_host_stats().

WARNING: at lib/list_debug.c:48 list_del+0x6e/0xa0() (Not tainted)
Hardware name: PowerEdge R820

list_del corruption. prev->next should be ffff882035627d90, but was ffff884069541588

Pid: 40267, comm: perl Not tainted 2.6.32-642.3.1.el6.x86_64 #1

Call Trace:
 [<ffffffff8107c691>] ? warn_slowpath_common+0x91/0xe0
 [<ffffffff8107c796>] ? warn_slowpath_fmt+0x46/0x60
 [<ffffffff812ad16e>] ? list_del+0x6e/0xa0
 [<ffffffff81547eed>] ? wait_for_common+0x14d/0x180
 [<ffffffff8106c4a0>] ? default_wake_function+0x0/0x20
 [<ffffffff81547fd3>] ? wait_for_completion_timeout+0x13/0x20
 [<ffffffffa05410b1>] ? bnx2fc_get_host_stats+0xa1/0x280 [bnx2fc]
 [<ffffffffa04cf630>] ? fc_stat_show+0x90/0xc0 [scsi_transport_fc]
 [<ffffffffa04cf8b6>] ? show_fcstat_tx_frames+0x16/0x20 [scsi_transport_fc]
 [<ffffffff8137c647>] ? dev_attr_show+0x27/0x50
 [<ffffffff8113b9be>] ? __get_free_pages+0xe/0x50
 [<ffffffff812170e1>] ? sysfs_read_file+0x111/0x200
 [<ffffffff8119a305>] ? vfs_read+0xb5/0x1a0
 [<ffffffff8119b0b6>] ? fget_light_pos+0x16/0x50
 [<ffffffff8119a651>] ? sys_read+0x51/0xb0
 [<ffffffff810ee1fe>] ? __audit_syscall_exit+0x25e/0x290
 [<ffffffff8100b0d2>] ? system_call_fastpath+0x16/0x1b

Signed-off-by Maurizio Lombardi <[email protected]>

Acked-by Chad Dupuis <[email protected]>

Signed-off-by Martin K. Petersen <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/scsi/bnx2fc/bnx2fc.h      |    1 +
 drivers/scsi/bnx2fc/bnx2fc_fcoe.c |   10 ++++++++--
 2 files changed, 9 insertions(+), 2 deletions(-)

drivers/scsi/bnx2fc/bnx2fc.h +1 -0

@@ -191,6 +191,7 @@ struct bnx2fc_hba {
 	struct bnx2fc_cmd_mgr *cmd_mgr;
 	spinlock_t hba_lock;
 	struct mutex hba_mutex;
+	struct mutex hba_stats_mutex;
 	unsigned long adapter_state;
 		#define ADAPTER_STATE_UP		0
 		#define ADAPTER_STATE_GOING_DOWN	1

drivers/scsi/bnx2fc/bnx2fc_fcoe.c +8 -2

@@ -670,15 +670,17 @@ static struct fc_host_statistics *bnx2fc
 	if (!fw_stats)
 		return NULL;
 
+	mutex_lock(&hba->hba_stats_mutex);
+
 	bnx2fc_stats = fc_get_host_stats(shost);
 
 	init_completion(&hba->stat_req_done);
 	if (bnx2fc_send_stat_req(hba))
-		return bnx2fc_stats;
+		goto unlock_stats_mutex;
 	rc = wait_for_completion_timeout(&hba->stat_req_done, (2 * HZ));
 	if (!rc) {
 		BNX2FC_HBA_DBG(lport, "FW stat req timed out\n");
-		return bnx2fc_stats;
+		goto unlock_stats_mutex;
 	}
 	BNX2FC_STATS(hba, rx_stat2, fc_crc_cnt);
 	bnx2fc_stats->invalid_crc_count += hba->bfw_stats.fc_crc_cnt;

@@ -700,6 +702,9 @@ static struct fc_host_statistics *bnx2fc
 
 	memcpy(&hba->prev_stats, hba->stats_buffer,
 	       sizeof(struct fcoe_statistics_params));
+
+unlock_stats_mutex:
+	mutex_unlock(&hba->hba_stats_mutex);
 	return bnx2fc_stats;
 }

@@ -1348,6 +1353,7 @@ static struct bnx2fc_hba *bnx2fc_hba_cre
 	}
 	spin_lock_init(&hba->hba_lock);
 	mutex_init(&hba->hba_mutex);
+	mutex_init(&hba->hba_stats_mutex);
 
 	hba->cnic = cnic;

Greg Kroah-Hartman

author maintainer

2018-04-11 18:34 UTC #108 lore raw

PATCH 106/310 fix race in drivers/char/random.c:get_reg()

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Michael Schmitz <[email protected]>

[ Upstream commit 9dfa7bba35ac08a63565d58c454dccb7e1bb0a08 ]

get_reg() can be reentered on architectures with prioritized interrupts (m68k in this case), causing f->reg_index to be incremented after the range check. Out of bounds memory access past the pt_regs struct results. This will go mostly undetected unless access is beyond end of memory.

Prevent the race by disabling interrupts in get_reg().

Tested on m68k (Atari Falcon, and ARAnyM emulator).

Kudos to Geert Uytterhoeven for helping to trace this race.

Signed-off-by Michael Schmitz <[email protected]>

Signed-off-by Theodore Ts'o <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/char/random.c |    6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

drivers/char/random.c +5 -1

@@ -1115,12 +1115,16 @@ static void add_interrupt_bench(cycles_t
 static __u32 get_reg(struct fast_pool *f, struct pt_regs *regs)
 {
 	__u32 *ptr = (__u32 *) regs;
+	unsigned long flags;
 
 	if (regs == NULL)
 		return 0;
+	local_irq_save(flags);
 	if (f->reg_idx >= sizeof(struct pt_regs) / sizeof(__u32))
 		f->reg_idx = 0;
-	return *(ptr + f->reg_idx++);
+	ptr += f->reg_idx++;
+	local_irq_restore(flags);
+	return *ptr;
 }
 
 void add_interrupt_randomness(int irq, int irq_flags)

Greg Kroah-Hartman

author maintainer

2018-04-11 18:34 UTC #109 lore raw

PATCH 107/310 ext4: fix off-by-one on max nr_pages in ext4_find_unwritten_pgoff()

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Eryu Guan <[email protected]>

[ Upstream commit 624327f8794704c5066b11a52f9da6a09dce7f9a ]

ext4_find_unwritten_pgoff() is used to search for offset of hole or data in page range [index, end] (both inclusive), and the max number of pages to search should be at least one, if end == index. Otherwise the only page is missed and no hole or data is found, which is not correct.

When block size is smaller than page size, this can be demonstrated by preallocating a file with size smaller than page size and writing data to the last block. E.g. run this xfs_io command on a 1k block size ext4 on x86_64 host.

  # xfs_io -fc "falloc 0 3k" -c "pwrite 2k 1k" \
  	    -c "seek -d 0" /mnt/ext4/testfile
  wrote 1024/1024 bytes at offset 2048
  1 KiB, 1 ops; 0.0000 sec (42.459 MiB/sec and 43478.2609 ops/sec)
  Whence  Result
  DATA    EOF

Data at offset 2k was missed, and lseek(2) returned ENXIO.

This is unconvered by generic/285 subtest 07 and 08 on ppc64 host, where pagesize is 64k. Because a recent change to generic/285 reduced the preallocated file size to smaller than 64k.

Signed-off-by Eryu Guan <[email protected]>

Signed-off-by Theodore Ts'o <[email protected]>

Reviewed-by Jan Kara <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 fs/ext4/file.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

fs/ext4/file.c +1 -1

@@ -429,7 +429,7 @@ static int ext4_find_unwritten_pgoff(str
 		int i, num;
 		unsigned long nr_pages;
 
-		num = min_t(pgoff_t, end - index, PAGEVEC_SIZE);
+		num = min_t(pgoff_t, end - index, PAGEVEC_SIZE - 1) + 1;
 		nr_pages = pagevec_lookup(&pvec, inode->i_mapping, index,
 					  (pgoff_t)num);
 		if (nr_pages == 0)

Greg Kroah-Hartman

author maintainer

2018-04-11 18:34 UTC #110 lore raw

PATCH 108/310 ARM64: PCI: Fix struct acpi_pci_root_ops allocation failure path

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Timmy Li <[email protected]>

[ Upstream commit 717902cc93118119a6fce7765da6cf2786987418 ]

Commit 093d24a20442 ("arm64: PCI: Manage controller-specific data on per-controller basis") added code to allocate ACPI PCI root_ops dynamically on a per host bridge basis but failed to update the corresponding memory allocation failure path in pci_acpi_scan_root() leading to a potential memory leakage.

Fix it by adding the required kfree call.

Fixes 093d24a20442 ("arm64: PCI: Manage controller-specific data on per-controller basis")

Reviewed-by Tomasz Nowicki <[email protected]>

Signed-off-by Timmy Li <[email protected]>

[[email protected]: refactored code, rewrote commit log]

Signed-off-by Lorenzo Pieralisi <[email protected]>

CC Will Deacon <[email protected]>

CC Bjorn Helgaas <[email protected]>

Signed-off-by Catalin Marinas <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 arch/arm64/kernel/pci.c |    4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

arch/arm64/kernel/pci.c +3 -1

@@ -175,8 +175,10 @@ struct pci_bus *pci_acpi_scan_root(struc
 		return NULL;
 
 	root_ops = kzalloc_node(sizeof(*root_ops), GFP_KERNEL, node);
-	if (!root_ops)
+	if (!root_ops) {
+		kfree(ri);
 		return NULL;
+	}
 
 	ri->cfg = pci_acpi_setup_ecam_mapping(root);
 	if (!ri->cfg) {

Greg Kroah-Hartman

author maintainer

2018-04-11 18:34 UTC #111 lore raw

PATCH 109/310 tcp: better validation of received ack sequences

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Eric Dumazet <[email protected]>

[ Upstream commit d0e1a1b5a833b625c93d3d49847609350ebd79db ]

Paul Fiterau Brostean reported :

<quote>
Linux TCP stack we analyze exhibits behavior that seems odd to me. The scenario is as follows (all packets have empty payloads, no window scaling, rcv/snd window size should not be a factor):

TEST HARNESS (CLIENT) LINUX SERVER

1. - LISTEN (server listen,
then accepts)

2. - --> <SEQ=100><CTL=SYN> --> SYN-RECEIVED

3. - <-- <SEQ=300><ACK=101><CTL=SYN,ACK> <-- SYN-RECEIVED

4. - --> <SEQ=101><ACK=301><CTL=ACK> --> ESTABLISHED

5. - <-- <SEQ=301><ACK=101><CTL=FIN,ACK> <-- FIN WAIT-1 (server
opts to close the data connection calling "close" on the connection socket)

6. - --> <SEQ=101><ACK=99999><CTL=FIN,ACK> --> CLOSING (client sends
FIN,ACK with not yet sent acknowledgement number)

7. - <-- <SEQ=302><ACK=102><CTL=ACK> <-- CLOSING (ACK is 102
instead of 101, why?)

... (silence from CLIENT)

8. - <-- <SEQ=301><ACK=102><CTL=FIN,ACK> <-- CLOSING
(retransmission, again ACK is 102)

Now, note that packet 6 while having the expected sequence number, acknowledges something that wasn't sent by the server. So I would expect
the packet to maybe prompt an ACK response from the server, and then be ignored. Yet it is not ignored and actually leads to an increase of the acknowledgement number in the server's retransmission of the FIN,ACK packet. The explanation I found is that the FIN in packet 6 was processed, despite the acknowledgement number being unacceptable. Further experiments indeed show that the server processes this FIN, transitioning to CLOSING, then on receiving an ACK for the FIN it had send in packet 5, the server (or better said connection) transitions from CLOSING to TIME_WAIT (as signaled by netstat).

</quote>

Indeed, tcp_rcv_state_process() calls tcp_ack() but does not exploit the @acceptable status but for TCP_SYN_RECV state.

What we want here is to send a challenge ACK, if not in TCP_SYN_RECV state. TCP_FIN_WAIT1 state is not the only state we should fix.

Add a FLAG_NO_CHALLENGE_ACK so that tcp_rcv_state_process() can choose to send a challenge ACK and discard the packet instead of wrongly change socket state.

With help from Neal Cardwell.

Signed-off-by Eric Dumazet <[email protected]>

Reported-by Paul Fiterau Brostean <[email protected]>

Cc Neal Cardwell <[email protected]>

Cc Yuchung Cheng <[email protected]>

Cc Soheil Hassas Yeganeh <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 net/ipv4/tcp_input.c |   24 +++++++++++-------------
 1 file changed, 11 insertions(+), 13 deletions(-)

net/ipv4/tcp_input.c +11 ~~-13~~

@@ -115,6 +115,7 @@ int sysctl_tcp_invalid_ratelimit __read_
 #define FLAG_DSACKING_ACK	0x800 /* SACK blocks contained D-SACK info */
 #define FLAG_SACK_RENEGING	0x2000 /* snd_una advanced to a sacked seq */
 #define FLAG_UPDATE_TS_RECENT	0x4000 /* tcp_replace_ts_recent() */
+#define FLAG_NO_CHALLENGE_ACK	0x8000 /* do not call tcp_send_challenge_ack()	*/
 
 #define FLAG_ACKED		(FLAG_DATA_ACKED|FLAG_SYN_ACKED)
 #define FLAG_NOT_DUP		(FLAG_DATA|FLAG_WIN_UPDATE|FLAG_ACKED)

@@ -3618,7 +3619,8 @@ static int tcp_ack(struct sock *sk, cons
 	if (before(ack, prior_snd_una)) {
 		/* RFC 5961 5.2 [Blind Data Injection Attack].[Mitigation] */
 		if (before(ack, prior_snd_una - tp->max_window)) {
-			tcp_send_challenge_ack(sk, skb);
+			if (!(flag & FLAG_NO_CHALLENGE_ACK))
+				tcp_send_challenge_ack(sk, skb);
 			return -1;
 		}
 		goto old_ack;

@@ -5969,13 +5971,17 @@ int tcp_rcv_state_process(struct sock *s
 
 	/* step 5: check the ACK field */
 	acceptable = tcp_ack(sk, skb, FLAG_SLOWPATH |
-				      FLAG_UPDATE_TS_RECENT) > 0;
+				      FLAG_UPDATE_TS_RECENT |
+				      FLAG_NO_CHALLENGE_ACK) > 0;
 
+	if (!acceptable) {
+		if (sk->sk_state == TCP_SYN_RECV)
+			return 1;	/* send one RST */
+		tcp_send_challenge_ack(sk, skb);
+		goto discard;
+	}
 	switch (sk->sk_state) {
 	case TCP_SYN_RECV:
-		if (!acceptable)
-			return 1;
-
 		if (!tp->srtt_us)
 			tcp_synack_rtt_meas(sk, req);

@@ -6045,14 +6051,6 @@ int tcp_rcv_state_process(struct sock *s
 		 * our SYNACK so stop the SYNACK timer.
 		 */
 		if (req) {
-			/* Return RST if ack_seq is invalid.
-			 * Note that RFC793 only says to generate a
-			 * DUPACK for it but for TCP Fast Open it seems
-			 * better to treat this case like TCP_SYN_RECV
-			 * above.
-			 */
-			if (!acceptable)
-				return 1;
 			/* We no longer need the request sock. */
 			reqsk_fastopen_remove(sk, req, false);
 			tcp_rearm_rto(sk);

Greg Kroah-Hartman

author maintainer

2018-04-11 18:34 UTC #112 lore raw

PATCH 110/310 net: move somaxconn init from sysctl code

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Roman Kapl <[email protected]>

[ Upstream commit 7c3f1875c66fbc19762760097cabc91849ea0bbb ]

The default value for somaxconn is set in sysctl_core_net_init(), but this function is not called when kernel is configured without CONFIG_SYSCTL.

This results in the kernel not being able to accept TCP connections,
because the backlog has zero size. Usually, the user ends up with:
"TCP: request_sock_TCP: Possible SYN flooding on port 7. Dropping request. Check SNMP counters." If SYN cookies are not enabled the connection is rejected.

Before ef547f2ac16 (tcp: remove max_qlen_log), the effects were less severe, because the backlog was always at least eight slots long.

Signed-off-by Roman Kapl <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 net/core/net_namespace.c   |   19 +++++++++++++++++++
 net/core/sysctl_net_core.c |    2 --
 2 files changed, 19 insertions(+), 2 deletions(-)

net/core/net_namespace.c +19 -0

@@ -312,6 +312,25 @@ out_undo:
 	goto out;
 }
 
+static int __net_init net_defaults_init_net(struct net *net)
+{
+	net->core.sysctl_somaxconn = SOMAXCONN;
+	return 0;
+}
+
+static struct pernet_operations net_defaults_ops = {
+	.init = net_defaults_init_net,
+};
+
+static __init int net_defaults_init(void)
+{
+	if (register_pernet_subsys(&net_defaults_ops))
+		panic("Cannot initialize net default settings");
+
+	return 0;
+}
+
+core_initcall(net_defaults_init);
 
 #ifdef CONFIG_NET_NS
 static struct ucounts *inc_net_namespaces(struct user_namespace *ns)

net/core/sysctl_net_core.c +0 -2

@@ -438,8 +438,6 @@ static __net_init int sysctl_core_net_in
 {
 	struct ctl_table *tbl;
 
-	net->core.sysctl_somaxconn = SOMAXCONN;
-
 	tbl = netns_core_table;
 	if (!net_eq(net, &init_net)) {
 		tbl = kmemdup(tbl, sizeof(netns_core_table), GFP_KERNEL);

Greg Kroah-Hartman

author maintainer

2018-04-11 18:34 UTC #113 lore raw

PATCH 111/310 Input: elan_i2c - clear INT before resetting controller

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: KT Liao <[email protected]>

[ Upstream commit 4b3c7dbbfff0673e8a89575414b864d8b001d3bb ]

Some old touchpad FWs need to have interrupt cleared before issuing reset command after updating firmware. We clear interrupt by attempting to read full report from the controller, and discarding any data read.

Signed-off-by KT Liao <[email protected]>

Signed-off-by Dmitry Torokhov <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/input/mouse/elan_i2c_i2c.c |    9 ++++++++-
 1 file changed, 8 insertions(+), 1 deletion(-)

drivers/input/mouse/elan_i2c_i2c.c +8 -1

@@ -557,7 +557,14 @@ static int elan_i2c_finish_fw_update(str
 	long ret;
 	int error;
 	int len;
-	u8 buffer[ETP_I2C_INF_LENGTH];
+	u8 buffer[ETP_I2C_REPORT_LEN];
+
+	len = i2c_master_recv(client, buffer, ETP_I2C_REPORT_LEN);
+	if (len != ETP_I2C_REPORT_LEN) {
+		error = len < 0 ? len : -EIO;
+		dev_warn(dev, "failed to read I2C data after FW WDT reset: %d (%d)\n",
+			error, len);
+	}
 
 	reinit_completion(completion);
 	enable_irq(client->irq);

Greg Kroah-Hartman

author maintainer

2018-04-11 18:34 UTC #117 lore raw

PATCH 115/310 KVM: X86: Fix preempt the preemption timer cancel

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Wanpeng Li <[email protected]>

[ Upstream commit 5acc1ca4fb15f00bfa3d4046e35ca381bc25d580 ]

Preemption can occur during cancel preemption timer, and there will be inconsistent status in lapic, vmx and vmcs field.

CPU0 CPU1

  preemption timer vmexit
  handle_preemption_timer(vCPU0)
    kvm_lapic_expired_hv_timer
      vmx_cancel_hv_timer
        vmx->hv_deadline_tsc = -1
        vmcs_clear_bits
        /* hv_timer_in_use still true */
  sched_out
                           sched_in
                           kvm_arch_vcpu_load
                             vmx_set_hv_timer
                               write vmx->hv_deadline_tsc
                               vmcs_set_bits
                           /* back in kvm_lapic_expired_hv_timer */
                           hv_timer_in_use = false
                           ...
                           vmx_vcpu_run
                             vmx_arm_hv_run
                               write preemption timer deadline
                             spurious preemption timer vmexit
                               handle_preemption_timer(vCPU0)
                                 kvm_lapic_expired_hv_timer
                                   WARN_ON(!apic->lapic_timer.hv_timer_in_use);

This can be reproduced sporadically during boot of L2 on a preemptible L1, causing a splat on L1.

 WARNING: CPU: 3 PID: 1952 at arch/x86/kvm/lapic.c:1529 kvm_lapic_expired_hv_timer+0xb5/0xd0 [kvm]
 CPU: 3 PID: 1952 Comm: qemu-system-x86 Not tainted 4.12.0-rc1+ #24 RIP: 0010:kvm_lapic_expired_hv_timer+0xb5/0xd0 [kvm]
  Call Trace:
  handle_preemption_timer+0xe/0x20 [kvm_intel]
  vmx_handle_exit+0xc9/0x15f0 [kvm_intel]
  ? lock_acquire+0xdb/0x250
  ? lock_acquire+0xdb/0x250
  ? kvm_arch_vcpu_ioctl_run+0xdf3/0x1ce0 [kvm]
  kvm_arch_vcpu_ioctl_run+0xe55/0x1ce0 [kvm]
  kvm_vcpu_ioctl+0x384/0x7b0 [kvm]
  ? kvm_vcpu_ioctl+0x384/0x7b0 [kvm]
  ? __fget+0xf3/0x210
  do_vfs_ioctl+0xa4/0x700
  ? __fget+0x114/0x210
  SyS_ioctl+0x79/0x90
  do_syscall_64+0x8f/0x750
  ? trace_hardirqs_on_thunk+0x1a/0x1c
  entry_SYSCALL64_slow_path+0x25/0x25

This patch fixes it by disabling preemption while cancelling preemption timer. This way cancel_hv_timer is atomic with respect to kvm_arch_vcpu_load.

Cc Paolo Bonzini <[email protected]>

Cc Radim Krčmář <[email protected]>

Signed-off-by Wanpeng Li <[email protected]>

Signed-off-by Paolo Bonzini <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 arch/x86/kvm/lapic.c |    2 ++
 1 file changed, 2 insertions(+)

arch/x86/kvm/lapic.c +2 -0

@@ -1363,8 +1363,10 @@ EXPORT_SYMBOL_GPL(kvm_lapic_hv_timer_in_
 
 static void cancel_hv_tscdeadline(struct kvm_lapic *apic)
 {
+	preempt_disable();
 	kvm_x86_ops->cancel_hv_timer(apic->vcpu);
 	apic->lapic_timer.hv_timer_in_use = false;
+	preempt_enable();
 }
 
 void kvm_lapic_expired_hv_timer(struct kvm_vcpu *vcpu)

Greg Kroah-Hartman

author maintainer

2018-04-11 18:34 UTC #118 lore raw

PATCH 116/310 KVM: nVMX: Fix handling of lmsw instruction

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: "Jan H. Sch�nherr" <[email protected]>

[ Upstream commit e1d39b17e044e8ae819827810d87d809ba5f58c0 ]

The decision whether or not to exit from L2 to L1 on an lmsw instruction is based on bogus values: instead of using the information encoded within the exit qualification, it uses the data also used for the mov-to-cr instruction, which boils down to using whatever is in %eax at that point.

Use the correct values instead.

Without this fix, an L1 may not get notified when a 32-bit Linux L2 switches its secondary CPUs to protected mode; the L1 is only notified on the next modification of CR0. This short time window poses a problem, when there is some other reason to exit to L1 in between. Then, L2 will be resumed in real mode and chaos ensues.

Signed-off-by Jan H. Schönherr <[email protected]>

Reviewed-by Wanpeng Li <[email protected]>

Signed-off-by Paolo Bonzini <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 arch/x86/kvm/vmx.c |    7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

arch/x86/kvm/vmx.c +5 -2

@@ -7924,11 +7924,13 @@ static bool nested_vmx_exit_handled_cr(s
 {
 	unsigned long exit_qualification = vmcs_readl(EXIT_QUALIFICATION);
 	int cr = exit_qualification & 15;
-	int reg = (exit_qualification >> 8) & 15;
-	unsigned long val = kvm_register_readl(vcpu, reg);
+	int reg;
+	unsigned long val;
 
 	switch ((exit_qualification >> 4) & 3) {
 	case 0: /* mov to cr */
+		reg = (exit_qualification >> 8) & 15;
+		val = kvm_register_readl(vcpu, reg);
 		switch (cr) {
 		case 0:
 			if (vmcs12->cr0_guest_host_mask &

@@ -7983,6 +7985,7 @@ static bool nested_vmx_exit_handled_cr(s
 		 * lmsw can change bits 1..3 of cr0, and only set bit 0 of
 		 * cr0. Other attempted changes are ignored, with no exit.
 		 */
+		val = (exit_qualification >> LMSW_SOURCE_DATA_SHIFT) & 0x0f;
 		if (vmcs12->cr0_guest_host_mask & 0xe &
 		    (val ^ vmcs12->cr0_read_shadow))
 			return true;

Greg Kroah-Hartman

author maintainer

2018-04-11 18:34 UTC #120 lore raw

PATCH 118/310 drm/msm: Take the mutex before calling msm_gem_new_impl

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Jordan Crouse <[email protected]>

[ Upstream commit 90dd57de4a043f642179b1323a31ca3ced826611 ]

Amongst its other duties, msm_gem_new_impl adds the newly created GEM object to the shared inactive list which may also be actively modifiying the list during submission. All the paths to modify the list are protected by the mutex except for the one through msm_gem_import which can end up causing list corruption.

Signed-off-by Jordan Crouse <[email protected]>

[add extra WARN_ON(!mutex_is_locked(&dev->struct_mutex))]

Signed-off-by Rob Clark <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/gpu/drm/msm/msm_gem.c |    6 ++++++
 1 file changed, 6 insertions(+)

drivers/gpu/drm/msm/msm_gem.c +6 -0

@@ -770,6 +770,8 @@ static int msm_gem_new_impl(struct drm_d
 	unsigned sz;
 	bool use_vram = false;
 
+	WARN_ON(!mutex_is_locked(&dev->struct_mutex));
+
 	switch (flags & MSM_BO_CACHE_MASK) {
 	case MSM_BO_UNCACHED:
 	case MSM_BO_CACHED:

@@ -863,7 +865,11 @@ struct drm_gem_object *msm_gem_import(st
 
 	size = PAGE_ALIGN(dmabuf->size);
 
+	/* Take mutex so we can modify the inactive list in msm_gem_new_impl */
+	mutex_lock(&dev->struct_mutex);
 	ret = msm_gem_new_impl(dev, size, MSM_BO_WC, dmabuf->resv, &obj);
+	mutex_unlock(&dev->struct_mutex);
+
 	if (ret)
 		goto fail;

Greg Kroah-Hartman

author maintainer

2018-04-11 18:34 UTC #125 lore raw

PATCH 123/310 perf probe: Add warning message if there is unexpected event name

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Masami Hiramatsu <[email protected]>

[ Upstream commit 9f5c6d8777a2d962b0eeacb2a16f37da6bea545b ]

This improve the error message so that user can know event-name error before writing new events to kprobe-events interface.

E.g.
======
#./perf probe -x /lib64/libc-2.25.so malloc_get_state*

   Internal error: "malloc_get_state@GLIBC_2" is an invalid event name.
     Error: Failed to add events.
   ======

Reported-by Arnaldo Carvalho de Melo <[email protected]>

Signed-off-by Masami Hiramatsu <[email protected]>

Acked-by Ravi Bangoria <[email protected]>

Reviewed-by Thomas Richter <[email protected]>

Tested-by Arnaldo Carvalho de Melo <[email protected]>

Cc Paul Clarke <[email protected]>

Cc bhargavb <[email protected]>

Link http://lkml.kernel.org/r/151275040665.24652.5188568529237584489.stgit@devbox open here

Signed-off-by Arnaldo Carvalho de Melo <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 tools/perf/util/probe-event.c |    8 ++++++++
 1 file changed, 8 insertions(+)

tools/perf/util/probe-event.c +8 -0

@@ -2609,6 +2609,14 @@ static int get_new_event_name(char *buf,
 
 out:
 	free(nbase);
+
+	/* Final validation */
+	if (ret >= 0 && !is_c_func_name(buf)) {
+		pr_warning("Internal error: \"%s\" is an invalid event name.\n",
+			   buf);
+		ret = -EINVAL;
+	}
+
 	return ret;
 }

Greg Kroah-Hartman

author maintainer

2018-04-11 18:34 UTC #126 lore raw

PATCH 124/310 l2tp: fix missing print session offset info

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Hangbin Liu <[email protected]>

[ Upstream commit 820da5357572715c6235ba3b3daa2d5b43a1198f ]

Report offset parameter in L2TP_CMD_SESSION_GET command if it has been configured by userspace

Fixes 309795f4bec ("l2tp: Add netlink control API for L2TP")

Reported-by Jianlin Shi <[email protected]>

Signed-off-by Hangbin Liu <[email protected]>

Signed-off-by Lorenzo Bianconi <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 net/l2tp/l2tp_netlink.c |    2 ++
 1 file changed, 2 insertions(+)

net/l2tp/l2tp_netlink.c +2 -0

@@ -750,6 +750,8 @@ static int l2tp_nl_session_send(struct s
 
 	if ((session->ifname[0] &&
 	     nla_put_string(skb, L2TP_ATTR_IFNAME, session->ifname)) ||
+	    (session->offset &&
+	     nla_put_u16(skb, L2TP_ATTR_OFFSET, session->offset)) ||
 	    (session->cookie_len &&
 	     nla_put(skb, L2TP_ATTR_COOKIE, session->cookie_len,
 		     &session->cookie[0])) ||

Greg Kroah-Hartman

author maintainer

2018-04-11 18:34 UTC #128 lore raw

PATCH 126/310 ACPI / video: Default lcd_only to true on Win8-ready and newer machines

Link https://bugzilla.redhat.com/show_bug.cgi?id=1097436

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Hans de Goede <[email protected]>

[ Upstream commit 5928c281524fe451114e04f1dfa11246a37e859f ]

We're seeing a lot of bogus backlight interfaces on newer machines without a LCD such as desktops, servers and HDMI sticks. This causes userspace to show a non-functional brightness slider in e.g. the GNOME3 system menu, which is undesirable. And, in general, we should simply just not register a non functional backlight interface.

Checking the LCD flag causes the bogus acpi_video backlight interfaces to go away (on the machines this was tested on).

This change sets the lcd_only option by default on any machines which are Win8-ready, to fix this.

This is not entirely without a risk of regressions, but video_detect.c already prefers native-backlight interfaces over the acpi_video one on Win8-ready machines, calling acpi_video_unregister_backlight() as soon as a native interface shows up. This is done because the ACPI backlight interface often is broken on Win8-ready machines, because win8 does not seem to actually use it.

So in practice we already end up not registering the ACPI backlight interface on (most) Win8-ready machines with a LCD panel, thus this change does not change anything for (most) machines with a LCD panel and on machines without a LCD panel we actually don't want to register any backlight interfaces.

This has been tested on the following machines and fixes a bogus backlight interface showing up there:
- Desktop with an Asrock B150M Pro4S/D3 m.b. using i5-6500 builtin gfx
- Intel Compute Stick STK1AW32SC
- Meegopad T08 HDMI stick

Bogus backlight interfaces have also been reported on:
- Desktop with Asus H87I-Plus m.b.
- Desktop with ASRock B75M-ITX m.b.
- Desktop with Gigabyte Z87-D3HP m.b.
- Dell PowerEdge T20 desktop

Link https://bugzilla.redhat.com/show_bug.cgi?id=1133327

Link https://bugzilla.redhat.com/show_bug.cgi?id=1133329

Link https://bugzilla.redhat.com/show_bug.cgi?id=1133646

Signed-off-by Rafael J. Wysocki <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/acpi/acpi_video.c |   14 ++++++++++++--
 1 file changed, 12 insertions(+), 2 deletions(-)

drivers/acpi/acpi_video.c +12 -2

@@ -87,8 +87,8 @@ MODULE_PARM_DESC(report_key_events,
 static bool device_id_scheme = false;
 module_param(device_id_scheme, bool, 0444);
 
-static bool only_lcd = false;
-module_param(only_lcd, bool, 0444);
+static int only_lcd = -1;
+module_param(only_lcd, int, 0444);
 
 static int register_count;
 static DEFINE_MUTEX(register_count_mutex);

@@ -2082,6 +2082,16 @@ int acpi_video_register(void)
 		goto leave;
 	}
 
+	/*
+	 * We're seeing a lot of bogus backlight interfaces on newer machines
+	 * without a LCD such as desktops, servers and HDMI sticks. Checking
+	 * the lcd flag fixes this, so enable this on any machines which are
+	 * win8 ready (where we also prefer the native backlight driver, so
+	 * normally the acpi_video code should not register there anyways).
+	 */
+	if (only_lcd == -1)
+		only_lcd = acpi_osi_is_win8();
+
 	dmi_check_system(video_dmi_table);
 
 	ret = acpi_bus_register_driver(&acpi_video_bus);

Greg Kroah-Hartman

author maintainer

2018-04-11 18:34 UTC #130 lore raw

PATCH 128/310 VFS: close race between getcwd() and d_move()

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: NeilBrown <[email protected]>

[ Upstream commit 61647823aa920e395afcce4b57c32afb51456cab ]

d_move() will call __d_drop() and then __d_rehash() on the dentry being moved. This creates a small window when the dentry appears to be unhashed. Many tests of d_unhashed() are made under ->d_lock and so are safe from racing with this window, but some aren't. In particular, getcwd() calls d_unlinked() (which calls d_unhashed()) without d_lock protection, so it can race.

This races has been seen in practice with lustre, which uses d_move() as part of name lookup. See:
https://jira.hpdd.intel.com/browse/LU-9735
It could race with a regular rename(), and result in ENOENT instead of either the 'before' or 'after' name.

The race can be demonstrated with a simple program which has two threads, one renaming a directory back and forth while another calls getcwd() within that directory: it should never fail, but does. See:
https://patchwork.kernel.org/patch/9455345/

We could fix this race by taking d_lock and rechecking when d_unhashed() reports true. Alternately when can remove the window, which is the approach this patch takes.

___d_drop() is introduce which does *not* clear d_hash.pprev so the dentry still appears to be hashed. __d_drop() calls ___d_drop(), then clears d_hash.pprev.
__d_move() now uses ___d_drop() and only clears d_hash.pprev when not rehashing.

Signed-off-by NeilBrown <[email protected]>

Signed-off-by Al Viro <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 fs/dcache.c |   23 ++++++++++++++++-------
 1 file changed, 16 insertions(+), 7 deletions(-)

fs/dcache.c +16 -7

@@ -461,9 +461,11 @@ static void dentry_lru_add(struct dentry
  * d_drop() is used mainly for stuff that wants to invalidate a dentry for some
  * reason (NFS timeouts or autofs deletes).
  *
- * __d_drop requires dentry->d_lock.
+ * __d_drop requires dentry->d_lock
+ * ___d_drop doesn't mark dentry as "unhashed"
+ *   (dentry->d_hash.pprev will be LIST_POISON2, not NULL).
  */
-void __d_drop(struct dentry *dentry)
+static void ___d_drop(struct dentry *dentry)
 {
 	if (!d_unhashed(dentry)) {
 		struct hlist_bl_head *b;

@@ -479,12 +481,17 @@ void __d_drop(struct dentry *dentry)
 
 		hlist_bl_lock(b);
 		__hlist_bl_del(&dentry->d_hash);
-		dentry->d_hash.pprev = NULL;
 		hlist_bl_unlock(b);
 		/* After this call, in-progress rcu-walk path lookup will fail. */
 		write_seqcount_invalidate(&dentry->d_seq);
 	}
 }
+
+void __d_drop(struct dentry *dentry)
+{
+	___d_drop(dentry);
+	dentry->d_hash.pprev = NULL;
+}
 EXPORT_SYMBOL(__d_drop);
 
 void d_drop(struct dentry *dentry)

@@ -2378,7 +2385,7 @@ EXPORT_SYMBOL(d_delete);
 static void __d_rehash(struct dentry *entry)
 {
 	struct hlist_bl_head *b = d_hash(entry->d_name.hash);
-	BUG_ON(!d_unhashed(entry));
+
 	hlist_bl_lock(b);
 	hlist_bl_add_head_rcu(&entry->d_hash, b);
 	hlist_bl_unlock(b);

@@ -2815,9 +2822,9 @@ static void __d_move(struct dentry *dent
 	write_seqcount_begin_nested(&target->d_seq, DENTRY_D_LOCK_NESTED);
 
 	/* unhash both */
-	/* __d_drop does write_seqcount_barrier, but they're OK to nest. */
-	__d_drop(dentry);
-	__d_drop(target);
+	/* ___d_drop does write_seqcount_barrier, but they're OK to nest. */
+	___d_drop(dentry);
+	___d_drop(target);
 
 	/* Switch the names.. */
 	if (exchange)

@@ -2829,6 +2836,8 @@ static void __d_move(struct dentry *dent
 	__d_rehash(dentry);
 	if (exchange)
 		__d_rehash(target);
+	else
+		target->d_hash.pprev = NULL;
 
 	/* ... and switch them in the tree */
 	if (IS_ROOT(dentry)) {

Greg Kroah-Hartman

author maintainer

2018-04-11 18:34 UTC #131 lore raw

PATCH 129/310 PM / devfreq: Fix potential NULL pointer dereference in governor_store

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: "Gustavo A. R. Silva" <[email protected]>

[ Upstream commit 63f1e05f7fe9ca509c60154d6a833abf96eecdc9 ]

df->governor is being dereferenced before it is null checked, hence there is a potential null pointer dereference.

Notice that df->governor is being null checked at line 1004:
if (df->governor) {, which implies it might be null.

Fix this by null checking df->governor before dereferencing it.

Addresses-Coverity-ID: 1401988 ("Dereference before null check")

Fixes bcf23c79c4e4 ("PM / devfreq: Fix available_governor sysfs")

Signed-off-by Gustavo A. R. Silva <[email protected]>

Reviewed-by Chanwoo Choi <[email protected]>

Signed-off-by MyungJoo Ham <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/devfreq/devfreq.c |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

drivers/devfreq/devfreq.c +2 -1

@@ -943,7 +943,8 @@ static ssize_t governor_store(struct dev
 	if (df->governor == governor) {
 		ret = 0;
 		goto out;
-	} else if (df->governor->immutable || governor->immutable) {
+	} else if ((df->governor && df->governor->immutable) ||
+					governor->immutable) {
 		ret = -EINVAL;
 		goto out;
 	}

Greg Kroah-Hartman

author maintainer

2018-04-11 18:34 UTC #133 lore raw

PATCH 131/310 media: videobuf2-core: dont go out of the buffer range

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Mauro Carvalho Chehab <[email protected]>

[ Upstream commit df93dc61b0d8b19a5c9db545cf3fcc24f88dfde4 ]

Currently, there's no check if an invalid buffer range is passed. However, while testing DVB memory mapped apps, I got this:

videobuf2_core: VB: num_buffers -2143943680, buffer 33, index -2143943647 unable to handle kernel paging request at ffff888b773c0890
IP: __vb2_queue_alloc+0x134/0x4e0 [videobuf2_core]
PGD 4142c7067 P4D 4142c7067 PUD 0

   Oops: 0002 [#1] SMP
   Modules linked in: 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 ecdh_generic binfmt_misc rc_dvbsky sp2 ts2020 intel_rapl x86_pkg_temp_thermal dvb_usb_dvbsky intel_powerclamp dvb_usb_v2 coretemp m88ds3103 kvm_intel i2c_mux dvb_core snd_hda_codec_hdmi crct10dif_pclmul crc32_pclmul videobuf2_vmalloc videobuf2_memops snd_hda_intel ghash_clmulni_intel videobuf2_core snd_hda_codec rc_core mei_me intel_cstate snd_hwdep snd_hda_core videodev intel_uncore snd_pcm mei media tpm_tis tpm_tis_core intel_rapl_perf tpm snd_timer lpc_ich snd soundcore kvm irqbypass libcrc32c i915 i2c_algo_bit drm_kms_helper
   e1000e ptp drm crc32c_intel video pps_core
   CPU: 3 PID: 1776 Comm: dvbv5-zap Not tainted 4.14.0+ #78
   Hardware name:                  /NUC5i7RYB, BIOS RYBDWi35.86A.0364.2017.0511.0949 05/11/2017
   task: ffff88877c73bc80 task.stack: ffffb7c402418000
   RIP: 0010:__vb2_queue_alloc+0x134/0x4e0 [videobuf2_core]
   RSP: 0018:ffffb7c40241bc60 EFLAGS: 00010246
   RAX: 0000000080360421 RBX: 0000000000000021 RCX: 000000000000000a
   RDX: ffffb7c40241bcf4 RSI: ffff888780362c60 RDI: ffff888796d8e130
   RBP: ffffb7c40241bcc8 R08: 0000000000000316 R09: 0000000000000004
   R10: ffff888780362c00 R11: 0000000000000001 R12: 000000000002f000
   R13: ffff8887758be700 R14: 0000000000021000 R15: 0000000000000001
   FS:  00007f2849024740(0000) GS:ffff888796d80000(0000) knlGS:0000000000000000
   CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
   CR2: ffff888b773c0890 CR3: 000000043beb2005 CR4: 00000000003606e0
   Call Trace:
    vb2_core_reqbufs+0x226/0x420 [videobuf2_core]
    dvb_vb2_reqbufs+0x2d/0xc0 [dvb_core]
    dvb_dvr_do_ioctl+0x98/0x1d0 [dvb_core]
    dvb_usercopy+0x53/0x1b0 [dvb_core]
    ? dvb_demux_ioctl+0x20/0x20 [dvb_core]
    ? tty_ldisc_deref+0x16/0x20
    ? tty_write+0x1f9/0x310
    ? process_echoes+0x70/0x70
    dvb_dvr_ioctl+0x15/0x20 [dvb_core]
    do_vfs_ioctl+0xa5/0x600
    SyS_ioctl+0x79/0x90
    entry_SYSCALL_64_fastpath+0x1a/0xa5
   RIP: 0033:0x7f28486f7ea7
   RSP: 002b:00007ffc13b2db18 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
   RAX: ffffffffffffffda RBX: 000055b10fc06130 RCX: 00007f28486f7ea7
   RDX: 00007ffc13b2db48 RSI: 00000000c0086f3c RDI: 0000000000000007
   RBP: 0000000000000203 R08: 000055b10df1e02c R09: 000000000000002e
   R10: 0036b42415108357 R11: 0000000000000246 R12: 0000000000000000
   R13: 00007f2849062f60 R14: 00000000000001f1 R15: 00007ffc13b2da54
   Code: 74 0a 60 8b 0a 48 83 c0 30 48 83 c2 04 89 48 d0 89 48 d4 48 39 f0 75 eb 41 8b 42 08 83 7d d4 01 41 c7 82 ec 01 00 00 ff ff ff ff <4d> 89 94 c5 88 00 00 00 74 14 83 c3 01 41 39 dc 0f 85 f1 fe ff
   RIP: __vb2_queue_alloc+0x134/0x4e0 [videobuf2_core] RSP: ffffb7c40241bc60
   CR2: ffff888b773c0890

So, add a sanity check in order to prevent going past array.

Signed-off-by Mauro Carvalho Chehab <[email protected]>

Acked-by Sakari Ailus <[email protected]>

Signed-off-by Mauro Carvalho Chehab <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/media/v4l2-core/videobuf2-core.c |    4 ++++
 1 file changed, 4 insertions(+)

drivers/media/v4l2-core/videobuf2-core.c +4 -0

@@ -334,6 +334,10 @@ static int __vb2_queue_alloc(struct vb2_
 	struct vb2_buffer *vb;
 	int ret;
 
+	/* Ensure that q->num_buffers+num_buffers is below VB2_MAX_FRAME */
+	num_buffers = min_t(unsigned int, num_buffers,
+			    VB2_MAX_FRAME - q->num_buffers);
+
 	for (buffer = 0; buffer < num_buffers; ++buffer) {
 		/* Allocate videobuf buffer structures */
 		vb = kzalloc(q->buf_struct_size, GFP_KERNEL);

Greg Kroah-Hartman

author maintainer

2018-04-11 18:34 UTC #135 lore raw

PATCH 133/310 ASoC: Intel: cht_bsw_rt5645: Analog Mic support

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Hans de Goede <[email protected]>

[ Upstream commit b70b309950418437bbd2a30afd169c4f09dee3e5 ]

Various Cherry Trail boards with a rt5645 codec have an analog mic connected to IN2P + IN2N. The mic on this boards also needs micbias to be enabled, on some boards micbias1 is used and on others micbias2, so we enable both.

This commit adds a new "Int Analog Mic" DAPM widget for this, so that we do not end up enabling micbias on boards with a digital mic which uses the already present "Int Mic" widget. Some existing UCM files already refer to "Int Mic" for their "Internal Analog Microphones" SectionDevice, but these don't work anyways since they enable the RECMIX BST1 Switch instead of the BST2 switch.

Signed-off-by Mark Brown <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 sound/soc/intel/boards/cht_bsw_rt5645.c |    7 +++++++
 1 file changed, 7 insertions(+)

sound/soc/intel/boards/cht_bsw_rt5645.c +7 -0

@@ -111,6 +111,7 @@ static const struct snd_soc_dapm_widget
 	SND_SOC_DAPM_HP("Headphone", NULL),
 	SND_SOC_DAPM_MIC("Headset Mic", NULL),
 	SND_SOC_DAPM_MIC("Int Mic", NULL),
+	SND_SOC_DAPM_MIC("Int Analog Mic", NULL),
 	SND_SOC_DAPM_SPK("Ext Spk", NULL),
 	SND_SOC_DAPM_SUPPLY("Platform Clock", SND_SOC_NOPM, 0, 0,
 			platform_clock_control, SND_SOC_DAPM_PRE_PMU | SND_SOC_DAPM_POST_PMD),

@@ -121,6 +122,8 @@ static const struct snd_soc_dapm_route c
 	{"IN1N", NULL, "Headset Mic"},
 	{"DMIC L1", NULL, "Int Mic"},
 	{"DMIC R1", NULL, "Int Mic"},
+	{"IN2P", NULL, "Int Analog Mic"},
+	{"IN2N", NULL, "Int Analog Mic"},
 	{"Headphone", NULL, "HPOL"},
 	{"Headphone", NULL, "HPOR"},
 	{"Ext Spk", NULL, "SPOL"},

@@ -134,6 +137,9 @@ static const struct snd_soc_dapm_route c
 	{"Headphone", NULL, "Platform Clock"},
 	{"Headset Mic", NULL, "Platform Clock"},
 	{"Int Mic", NULL, "Platform Clock"},
+	{"Int Analog Mic", NULL, "Platform Clock"},
+	{"Int Analog Mic", NULL, "micbias1"},
+	{"Int Analog Mic", NULL, "micbias2"},
 	{"Ext Spk", NULL, "Platform Clock"},
 };

@@ -162,6 +168,7 @@ static const struct snd_kcontrol_new cht
 	SOC_DAPM_PIN_SWITCH("Headphone"),
 	SOC_DAPM_PIN_SWITCH("Headset Mic"),
 	SOC_DAPM_PIN_SWITCH("Int Mic"),
+	SOC_DAPM_PIN_SWITCH("Int Analog Mic"),
 	SOC_DAPM_PIN_SWITCH("Ext Spk"),
 };

Greg Kroah-Hartman

author maintainer

2018-04-11 18:34 UTC #138 lore raw

PATCH 136/310 irqchip/gic-v3: Fix the driver probe() fail due to disabled GICC entry

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Shanker Donthineni <[email protected]>

[ Upstream commit ebe2f8718007d5a1238bb3cb8141b5bb2b4d5773 ]

The ACPI specification says OS shouldn't attempt to use GICC configuration parameters if the flag ACPI_MADT_ENABLED is cleared. The ARM64-SMP code skips the disabled GICC entries but not causing any issue. However the current GICv3 driver probe bails out causing kernel panic() instead of skipping the disabled GICC interfaces. This issue happens on systems where redistributor regions are not in the always-on power domain and one of GICC interface marked with ACPI_MADT_ENABLED=0.

This patch does the two things to fix the panic.
- Don't return an error in gic_acpi_match_gicc() for disabled GICC entry.
- No need to keep GICR region information for disabled GICC entry.

Observed kernel crash on QDF2400 platform GICC entry is disabled. Kernel crash traces:

  Kernel panic - not syncing: No interrupt controller found.
  CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.13.5 #26
  [<ffff000008087770>] dump_backtrace+0x0/0x218
  [<ffff0000080879dc>] show_stack+0x14/0x20
  [<ffff00000883b078>] dump_stack+0x98/0xb8
  [<ffff0000080c5c14>] panic+0x118/0x26c
  [<ffff000008b62348>] init_IRQ+0x24/0x2c
  [<ffff000008b609fc>] start_kernel+0x230/0x394
  [<ffff000008b601e4>] __primary_switched+0x64/0x6c
  ---[ end Kernel panic - not syncing: No interrupt controller found.

Disabled GICC subtable example:

                   Subtable Type : 0B [Generic Interrupt Controller]
                          Length : 50
                        Reserved : 0000
            CPU Interface Number : 0000003D
                   Processor UID : 0000003D
           Flags (decoded below) : 00000000
               Processor Enabled : 0
 Performance Interrupt Trig Mode : 0
 Virtual GIC Interrupt Trig Mode : 0
        Parking Protocol Version : 00000000
           Performance Interrupt : 00000017
                  Parked Address : 0000000000000000
                    Base Address : 0000000000000000
        Virtual GIC Base Address : 0000000000000000
     Hypervisor GIC Base Address : 0000000000000000
           Virtual GIC Interrupt : 00000019
      Redistributor Base Address : 0000FFFF88F40000
                       ARM MPIDR : 000000000000000D
                Efficiency Class : 00
                        Reserved : 000000

Signed-off-by Shanker Donthineni <[email protected]>

Signed-off-by Marc Zyngier <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/irqchip/irq-gic-v3.c |   11 +++++++++++
 1 file changed, 11 insertions(+)

drivers/irqchip/irq-gic-v3.c +11 -0

@@ -1250,6 +1250,10 @@ gic_acpi_parse_madt_gicc(struct acpi_sub
 	u32 size = reg == GIC_PIDR2_ARCH_GICv4 ? SZ_64K * 4 : SZ_64K * 2;
 	void __iomem *redist_base;
 
+	/* GICC entry which has !ACPI_MADT_ENABLED is not unusable so skip */
+	if (!(gicc->flags & ACPI_MADT_ENABLED))
+		return 0;
+
 	redist_base = ioremap(gicc->gicr_base_address, size);
 	if (!redist_base)
 		return -ENOMEM;

@@ -1299,6 +1303,13 @@ static int __init gic_acpi_match_gicc(st
 	if ((gicc->flags & ACPI_MADT_ENABLED) && gicc->gicr_base_address)
 		return 0;
 
+	/*
+	 * It's perfectly valid firmware can pass disabled GICC entry, driver
+	 * should not treat as errors, skip the entry instead of probe fail.
+	 */
+	if (!(gicc->flags & ACPI_MADT_ENABLED))
+		return 0;
+
 	return -ENODEV;
 }

Greg Kroah-Hartman

author maintainer

2018-04-11 18:34 UTC #140 lore raw

PATCH 138/310 mac80211: Fix setting TX power on monitor interfaces

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: "Peter Gro�e" <[email protected]>

[ Upstream commit 3a3713ec360138f806c6fc368d1de570f692b347 ]

Instead of calling ieee80211_recalc_txpower on monitor interfaces directly, call it using the virtual monitor interface, if one exists.

In case of a single monitor interface given, reject setting TX power, if no virtual monitor interface exists.

That being checked, don't warn in ieee80211_bss_info_change_notify, after setting TX power on a monitor interface.

Fixes warning:

------------[ cut here ]------------
 WARNING: CPU: 0 PID: 2193 at net/mac80211/driver-ops.h:167
 ieee80211_bss_info_change_notify+0x111/0x190 Modules linked in: uvcvideo
 videobuf2_vmalloc videobuf2_memops videobuf2_v4l2 videobuf2_core

rndis_host cdc_ether usbnet mii tp_smapi(O) thinkpad_ec(O) ohci_hcd vboxpci(O)
vboxnetadp(O) vboxnetflt(O) v boxdrv(O) x86_pkg_temp_thermal kvm_intel kvm irqbypass iwldvm iwlwifi ehci_pci ehci_hcd tpm_tis tpm_tis_core tpm CPU: 0
PID: 2193 Comm: iw Tainted: G O 4.12.12-gentoo #2 task:
ffff880186fd5cc0 task.stack: ffffc90001b54000 RIP:
0010:ieee80211_bss_info_change_notify+0x111/0x190 RSP: 0018:ffffc90001b57a10
EFLAGS: 00010246 RAX: 0000000000000006 RBX: ffff8801052ce840 RCX:
0000000000000064 RDX: 00000000fffffffc RSI: 0000000000040000 RDI:
ffff8801052ce840 RBP: ffffc90001b57a38 R08: 0000000000000062 R09:
0000000000000000 R10: ffff8802144b5000 R11: ffff880049dc4614 R12:
0000000000040000 R13: 0000000000000064 R14: ffff8802105f0760 R15:
ffffc90001b57b48 FS: 00007f92644b4580(0000) GS:ffff88021e200000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f9263c109f0 CR3: 00000001df850000 CR4: 00000000000406f0

 Call Trace:
  ieee80211_recalc_txpower+0x33/0x40
  ieee80211_set_tx_power+0x40/0x180
  nl80211_set_wiphy+0x32e/0x950

Reported-by Peter Große <[email protected]>

Signed-off-by Peter Große <[email protected]>

Signed-off-by Johannes Berg <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 net/mac80211/cfg.c        |   28 +++++++++++++++++++++++++++-
 net/mac80211/driver-ops.h |    3 ++-
 2 files changed, 29 insertions(+), 2 deletions(-)

net/mac80211/cfg.c +27 -1

@@ -2341,10 +2341,17 @@ static int ieee80211_set_tx_power(struct
 	struct ieee80211_sub_if_data *sdata;
 	enum nl80211_tx_power_setting txp_type = type;
 	bool update_txp_type = false;
+	bool has_monitor = false;
 
 	if (wdev) {
 		sdata = IEEE80211_WDEV_TO_SUB_IF(wdev);
 
+		if (sdata->vif.type == NL80211_IFTYPE_MONITOR) {
+			sdata = rtnl_dereference(local->monitor_sdata);
+			if (!sdata)
+				return -EOPNOTSUPP;
+		}
+
 		switch (type) {
 		case NL80211_TX_POWER_AUTOMATIC:
 			sdata->user_power_level = IEEE80211_UNSET_POWER_LEVEL;

@@ -2383,15 +2390,34 @@ static int ieee80211_set_tx_power(struct
 
 	mutex_lock(&local->iflist_mtx);
 	list_for_each_entry(sdata, &local->interfaces, list) {
+		if (sdata->vif.type == NL80211_IFTYPE_MONITOR) {
+			has_monitor = true;
+			continue;
+		}
 		sdata->user_power_level = local->user_power_level;
 		if (txp_type != sdata->vif.bss_conf.txpower_type)
 			update_txp_type = true;
 		sdata->vif.bss_conf.txpower_type = txp_type;
 	}
-	list_for_each_entry(sdata, &local->interfaces, list)
+	list_for_each_entry(sdata, &local->interfaces, list) {
+		if (sdata->vif.type == NL80211_IFTYPE_MONITOR)
+			continue;
 		ieee80211_recalc_txpower(sdata, update_txp_type);
+	}
 	mutex_unlock(&local->iflist_mtx);
 
+	if (has_monitor) {
+		sdata = rtnl_dereference(local->monitor_sdata);
+		if (sdata) {
+			sdata->user_power_level = local->user_power_level;
+			if (txp_type != sdata->vif.bss_conf.txpower_type)
+				update_txp_type = true;
+			sdata->vif.bss_conf.txpower_type = txp_type;
+
+			ieee80211_recalc_txpower(sdata, update_txp_type);
+		}
+	}
+
 	return 0;
 }

net/mac80211/driver-ops.h +2 -1

@@ -164,7 +164,8 @@ static inline void drv_bss_info_changed(
 	if (WARN_ON_ONCE(sdata->vif.type == NL80211_IFTYPE_P2P_DEVICE ||
 			 sdata->vif.type == NL80211_IFTYPE_NAN ||
 			 (sdata->vif.type == NL80211_IFTYPE_MONITOR &&
-			  !sdata->vif.mu_mimo_owner)))
+			  !sdata->vif.mu_mimo_owner &&
+			  !(changed & BSS_CHANGED_TXPOWER))))
 		return;
 
 	if (!check_sdata_in_driver(sdata))

Greg Kroah-Hartman

author maintainer

2018-04-11 18:34 UTC #141 lore raw

PATCH 139/310 vfb: fix video mode and line_length being set when loaded

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: "Pieter \\\"PoroCYon\\\" Sluys" <[email protected]>

[ Upstream commit 7b9faf5df0ac495a1a3d7cdb64921c179f9008ac ]

Currently, when loading the vfb module, the newly created fbdev has a line_length of 0, and its video mode would be PSEUDOCOLOR regardless of color depth. (The former could be worked around by calling the FBIOPUT_VSCREENINFO ioctl with having the FBACTIVIATE_FORCE flag set.) This patch automatically sets the line_length correctly, and the video mode is derived from the bit depth now as well.

Thanks to Geert Uytterhoeven for confirming the bug and helping me with the patch.

Output of `fbset -i' before the patch:
mode "1366x768-60"

    # D: 72.432 MHz, H: 47.403 kHz, V: 60.004 Hz
    geometry 1366 768 1366 768 32
    timings 13806 120 10 14 3 32 5
    rgba 8/0,8/8,8/16,8/24

endmode

Frame buffer device information:

    Name        : Virtual FB
    Address     : 0xffffaa1405d85000
    Size        : 4196352
    Type        : PACKED PIXELS
    Visual      : PSEUDOCOLOR
    XPanStep    : 1
    YPanStep    : 1
    YWrapStep   : 1
    LineLength  : 0                    <-- note this

Accelerator : No

After:
mode "1366x768-60"

    # D: 72.432 MHz, H: 47.403 kHz, V: 60.004 Hz
    geometry 1366 768 1366 768 32
    timings 13806 120 10 14 3 32 5
    rgba 8/0,8/8,8/16,8/24

endmode

Frame buffer device information:

    Name        : Virtual FB
    Address     : 0xffffaa1405d85000
    Size        : 4196352
    Type        : PACKED PIXELS
    Visual      : TRUECOLOR
    XPanStep    : 1
    YPanStep    : 1
    YWrapStep   : 1
    LineLength  : 5464

Accelerator : No

Signed-off-by "Pieter \"PoroCYon\" Sluys" <[email protected]>

Reviewed-by Geert Uytterhoeven <[email protected]>

[b.zolnierkie: minor fixups]

Signed-off-by Bartlomiej Zolnierkiewicz <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/video/fbdev/vfb.c |   17 +++++++++++++++++
 1 file changed, 17 insertions(+)

drivers/video/fbdev/vfb.c +17 -0

@@ -239,8 +239,23 @@ static int vfb_check_var(struct fb_var_s
  */
 static int vfb_set_par(struct fb_info *info)
 {
+	switch (info->var.bits_per_pixel) {
+	case 1:
+		info->fix.visual = FB_VISUAL_MONO01;
+		break;
+	case 8:
+		info->fix.visual = FB_VISUAL_PSEUDOCOLOR;
+		break;
+	case 16:
+	case 24:
+	case 32:
+		info->fix.visual = FB_VISUAL_TRUECOLOR;
+		break;
+	}
+
 	info->fix.line_length = get_line_length(info->var.xres_virtual,
 						info->var.bits_per_pixel);
+
 	return 0;
 }

@@ -450,6 +465,8 @@ static int vfb_probe(struct platform_dev
 		goto err2;
 	platform_set_drvdata(dev, info);
 
+	vfb_set_par(info);
+
 	fb_info(info, "Virtual frame buffer device, using %ldK of video memory\n",
 		videomemorysize >> 10);
 	return 0;

Greg Kroah-Hartman

author maintainer

2018-04-11 18:34 UTC #142 lore raw

PATCH 140/310 gpio: label descriptors using the device name

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Linus Walleij <[email protected]>

[ Upstream commit 24e78079bf2250874e33da2e7cfbb6db72d3caf4 ]

Some GPIO lines appear named "?" in the lsgpio dump due to their requesting drivers not passing a reasonable label.

Most typically this happens if a device tree node just defines gpios = <...> and not foo-gpios = <...>, the former gets named "foo" and the latter gets named "?".

However the struct device passed in is always valid so let's just label the GPIO with dev_name() on the device if no proper label was passed.

Cc Reported-by: Jason Kridner <[email protected]>

Reported-by Jason Kridner <[email protected]>

Signed-off-by Linus Walleij <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/gpio/gpiolib.c |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

drivers/gpio/gpiolib.c +2 -1

@@ -3231,7 +3231,8 @@ struct gpio_desc *__must_check gpiod_get
 		return desc;
 	}
 
-	status = gpiod_request(desc, con_id);
+	/* If a connection label was passed use that, else use the device name as label */
+	status = gpiod_request(desc, con_id ? con_id : dev_name(dev));
 	if (status < 0)
 		return ERR_PTR(status);

Greg Kroah-Hartman

author maintainer

2018-04-11 18:34 UTC #143 lore raw

PATCH 141/310 IB/rdmavt: Allocate CQ memory on the correct node

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Mike Marciniszyn <[email protected]>

[ Upstream commit db9a2c6f9b6196b889b98e961cb9a37617b11ccf ]

CQ allocation does not ensure that completion queue entries and the completion queue structure are allocated on the correct numa node.

Fix by allocating the rvt_cq and kernel CQ entries on the device node, leaving the user CQ entries on the default local node. Also ensure CQ resizes use the correct allocator when extending a CQ.

Reviewed-by Sebastian Sanchez <[email protected]>

Signed-off-by Mike Marciniszyn <[email protected]>

Signed-off-by Dennis Dalessandro <[email protected]>

Signed-off-by Doug Ledford <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/infiniband/sw/rdmavt/cq.c |   10 +++++++---
 1 file changed, 7 insertions(+), 3 deletions(-)

drivers/infiniband/sw/rdmavt/cq.c +7 -3

@@ -197,7 +197,7 @@ struct ib_cq *rvt_create_cq(struct ib_de
 		return ERR_PTR(-EINVAL);
 
 	/* Allocate the completion queue structure. */
-	cq = kzalloc(sizeof(*cq), GFP_KERNEL);
+	cq = kzalloc_node(sizeof(*cq), GFP_KERNEL, rdi->dparms.node);
 	if (!cq)
 		return ERR_PTR(-ENOMEM);

@@ -213,7 +213,9 @@ struct ib_cq *rvt_create_cq(struct ib_de
 		sz += sizeof(struct ib_uverbs_wc) * (entries + 1);
 	else
 		sz += sizeof(struct ib_wc) * (entries + 1);
-	wc = vmalloc_user(sz);
+	wc = udata ?
+		vmalloc_user(sz) :
+		vzalloc_node(sz, rdi->dparms.node);
 	if (!wc) {
 		ret = ERR_PTR(-ENOMEM);
 		goto bail_cq;

@@ -368,7 +370,9 @@ int rvt_resize_cq(struct ib_cq *ibcq, in
 		sz += sizeof(struct ib_uverbs_wc) * (cqe + 1);
 	else
 		sz += sizeof(struct ib_wc) * (cqe + 1);
-	wc = vmalloc_user(sz);
+	wc = udata ?
+		vmalloc_user(sz) :
+		vzalloc_node(sz, rdi->dparms.node);
 	if (!wc)
 		return -ENOMEM;

Greg Kroah-Hartman

author maintainer

2018-04-11 18:34 UTC #144 lore raw

PATCH 142/310 blk-mq: fix race between updating nr_hw_queues and switching io sched

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Ming Lei <[email protected]>

[ Upstream commit fb350e0ad99359768e1e80b4784692031ec340e4 ]

In both elevator_switch_mq() and blk_mq_update_nr_hw_queues(), sched tags can be allocated, and q->nr_hw_queue is used, and race is inevitable, for
example: blk_mq_init_sched() may trigger use-after-free on hctx, which is freed in blk_mq_realloc_hw_ctxs() when nr_hw_queues is decreased.

This patch fixes the race be holding q->sysfs_lock.

Reviewed-by Christoph Hellwig <[email protected]>

Reported-by Yi Zhang <[email protected]>

Tested-by Yi Zhang <[email protected]>

Signed-off-by Ming Lei <[email protected]>

Signed-off-by Jens Axboe <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 block/blk-mq.c |    4 ++++
 1 file changed, 4 insertions(+)

block/blk-mq.c +4 -0

@@ -1907,6 +1907,9 @@ static void blk_mq_realloc_hw_ctxs(struc
 	struct blk_mq_hw_ctx **hctxs = q->queue_hw_ctx;
 
 	blk_mq_sysfs_unregister(q);
+
+	/* protect against switching io scheduler  */
+	mutex_lock(&q->sysfs_lock);
 	for (i = 0; i < set->nr_hw_queues; i++) {
 		int node;

@@ -1956,6 +1959,7 @@ static void blk_mq_realloc_hw_ctxs(struc
 		}
 	}
 	q->nr_hw_queues = i;
+	mutex_unlock(&q->sysfs_lock);
 	blk_mq_sysfs_register(q);
 }

Greg Kroah-Hartman

author maintainer

2018-04-11 18:34 UTC #145 lore raw

PATCH 143/310 backlight: tdo24m: Fix the SPI CS between transfers

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Robert Jarzmik <[email protected]>

[ Upstream commit 2023b0524a6310e9ea80daf085f51c71bff9289f ]

Currently the LCD display (TD035S) on the cm-x300 platform is broken and remains blank.

The TD0245S specification requires that the chipselect is toggled between commands sent to the panel. This was also the purpose of the former patch of commit f64dcac0b124 ("backlight: tdo24m: ensure chip select changes between transfers").

Unfortunately, the "cs_change" field of a SPI transfer is misleading. Its true meaning is that for a SPI message holding multiple transfers, the chip select is toggled between each transfer, but for the last transfer it remains asserted.

In this driver, all the SPI messages contain exactly one transfer, which means that each transfer is the last of its message, and as a consequence the chip select is never toggled.

Actually, there was a second bug hidding the first one, hence the problem was not seen until v4.6. This problem was fixed by commit a52db659c79c ("spi: pxa2xx: Fix cs_change management") for PXA based boards.

This fix makes the TD035S work again on a cm-x300 board. The same applies to other PXA boards, ie. corgi and tosa.

Fixes a52db659c79c ("spi: pxa2xx: Fix cs_change management")

Reported-by Andrea Adami <[email protected]>

Signed-off-by Robert Jarzmik <[email protected]>

Acked-by Daniel Thompson <[email protected]>

Signed-off-by Lee Jones <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/video/backlight/corgi_lcd.c |    2 +-
 drivers/video/backlight/tdo24m.c    |    2 +-
 drivers/video/backlight/tosa_lcd.c  |    2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

drivers/video/backlight/corgi_lcd.c +1 -1

@@ -177,7 +177,7 @@ static int corgi_ssp_lcdtg_send(struct c
 	struct spi_message msg;
 	struct spi_transfer xfer = {
 		.len		= 1,
-		.cs_change	= 1,
+		.cs_change	= 0,
 		.tx_buf		= lcd->buf,
 	};

drivers/video/backlight/tdo24m.c +1 -1

@@ -369,7 +369,7 @@ static int tdo24m_probe(struct spi_devic
 
 	spi_message_init(m);
 
-	x->cs_change = 1;
+	x->cs_change = 0;
 	x->tx_buf = &lcd->buf[0];
 	spi_message_add_tail(x, m);

drivers/video/backlight/tosa_lcd.c +1 -1

@@ -49,7 +49,7 @@ static int tosa_tg_send(struct spi_devic
 	struct spi_message msg;
 	struct spi_transfer xfer = {
 		.len		= 1,
-		.cs_change	= 1,
+		.cs_change	= 0,
 		.tx_buf		= buf,
 	};

Greg Kroah-Hartman

author maintainer

2018-04-11 18:34 UTC #146 lore raw

PATCH 144/310 pinctrl: baytrail: Enable glitch filter for GPIOs used as interrupts

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Hans de Goede <[email protected]>

[ Upstream commit 9291c65b01d1c67ebd56644cb19317ad665c44b3 ]

On some systems, some PCB traces attached to GpioInts are routed in such a way that they pick up enough interference to constantly (many times per second) trigger.

Enabling glitch-filtering fixes this.

Acked-by Mika Westerberg <[email protected]>

Signed-off-by Linus Walleij <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/pinctrl/intel/pinctrl-baytrail.c |    6 ++++++
 1 file changed, 6 insertions(+)

drivers/pinctrl/intel/pinctrl-baytrail.c +6 -0

@@ -46,6 +46,9 @@
 #define BYT_TRIG_POS		BIT(25)
 #define BYT_TRIG_LVL		BIT(24)
 #define BYT_DEBOUNCE_EN		BIT(20)
+#define BYT_GLITCH_FILTER_EN	BIT(19)
+#define BYT_GLITCH_F_SLOW_CLK	BIT(17)
+#define BYT_GLITCH_F_FAST_CLK	BIT(16)
 #define BYT_PULL_STR_SHIFT	9
 #define BYT_PULL_STR_MASK	(3 << BYT_PULL_STR_SHIFT)
 #define BYT_PULL_STR_2K		(0 << BYT_PULL_STR_SHIFT)

@@ -1579,6 +1582,9 @@ static int byt_irq_type(struct irq_data
 	 */
 	value &= ~(BYT_DIRECT_IRQ_EN | BYT_TRIG_POS | BYT_TRIG_NEG |
 		   BYT_TRIG_LVL);
+	/* Enable glitch filtering */
+	value |= BYT_GLITCH_FILTER_EN | BYT_GLITCH_F_SLOW_CLK |
+		 BYT_GLITCH_F_FAST_CLK;
 
 	writel(value, reg);

Greg Kroah-Hartman

author maintainer

2018-04-11 18:34 UTC #147 lore raw

PATCH 145/310 ASoC: Intel: sst: Fix the return value of sst_send_byte_stream_mrfld()

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Christophe JAILLET <[email protected]>

[ Upstream commit eaadb1caa966a91128297b754e90b7c92b350a00 ]

In some error handling paths, an error code is assiegned to 'ret'. However, the function always return 0.

Fix it and return the error code if such an error paths is taken.

Fixes 3d9ff34622ba ("ASoC: Intel: sst: add stream operations")

Signed-off-by Christophe JAILLET <[email protected]>

Signed-off-by Mark Brown <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 sound/soc/intel/atom/sst/sst_stream.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

sound/soc/intel/atom/sst/sst_stream.c +1 -1

@@ -221,7 +221,7 @@ int sst_send_byte_stream_mrfld(struct in
 		sst_free_block(sst_drv_ctx, block);
 out:
 	test_and_clear_bit(pvt_id, &sst_drv_ctx->pvt_id);
-	return 0;
+	return ret;
 }
 
 /*

Greg Kroah-Hartman

author maintainer

2018-04-11 18:34 UTC #148 lore raw

PATCH 146/310 rt2x00: do not pause queue unconditionally on error path

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Stanislaw Gruszka <[email protected]>

[ Upstream commit 6dd80efd75ce7c2dbd9f117cf585ee2b33a42ee1 ]

Pausing queue without checking threshold is racy with txdone path. Moreover we do not need pause queue on any error, but only if queue is full - in case when we send RTS frame ( other cases of almost full queue are already handled in rt2x00queue_write_tx_frame() ).

Patch fixes of theoretically possible problem of pausing empty queue.

Signed-off-by Stanislaw Gruszka <[email protected]>

Tested-by Enrico Mioso <[email protected]>

Signed-off-by Kalle Valo <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/net/wireless/ralink/rt2x00/rt2x00mac.c |   22 ++++++++++++++--------
 1 file changed, 14 insertions(+), 8 deletions(-)

drivers/net/wireless/ralink/rt2x00/rt2x00mac.c +14 -8

@@ -142,15 +142,25 @@ void rt2x00mac_tx(struct ieee80211_hw *h
 	if (!rt2x00dev->ops->hw->set_rts_threshold &&
 	    (tx_info->control.rates[0].flags & (IEEE80211_TX_RC_USE_RTS_CTS |
 						IEEE80211_TX_RC_USE_CTS_PROTECT))) {
-		if (rt2x00queue_available(queue) <= 1)
-			goto exit_fail;
+		if (rt2x00queue_available(queue) <= 1) {
+			/*
+			 * Recheck for full queue under lock to avoid race
+			 * conditions with rt2x00lib_txdone().
+			 */
+			spin_lock(&queue->tx_lock);
+			if (rt2x00queue_threshold(queue))
+				rt2x00queue_pause_queue(queue);
+			spin_unlock(&queue->tx_lock);
+
+			goto exit_free_skb;
+		}
 
 		if (rt2x00mac_tx_rts_cts(rt2x00dev, queue, skb))
-			goto exit_fail;
+			goto exit_free_skb;
 	}
 
 	if (unlikely(rt2x00queue_write_tx_frame(queue, skb, control->sta, false)))
-		goto exit_fail;
+		goto exit_free_skb;
 
 	/*
 	 * Pausing queue has to be serialized with rt2x00lib_txdone(). Note

@@ -164,10 +174,6 @@ void rt2x00mac_tx(struct ieee80211_hw *h
 
 	return;
 
- exit_fail:
-	spin_lock(&queue->tx_lock);
-	rt2x00queue_pause_queue(queue);
-	spin_unlock(&queue->tx_lock);
  exit_free_skb:
 	ieee80211_free_txskb(hw, skb);
 }

Greg Kroah-Hartman

author maintainer

2018-04-11 18:34 UTC #151 lore raw

PATCH 149/310 x86/efi: Disable runtime services on kexec kernel if booted with efi=old_map

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Sai Praneeth <[email protected]>

[ Upstream commit 4e52797d2efefac3271abdc54439a3435abd77b9 ]

Booting kexec kernel with "efi=old_map" in kernel command line hits kernel panic as shown below.

 BUG: unable to handle kernel paging request at ffff88007fe78070
 IP: virt_efi_set_variable.part.7+0x63/0x1b0
 PGD 7ea28067
 PUD 7ea2b067
 PMD 7ea2d067
 PTE 0
 [...]
 Call Trace:
  virt_efi_set_variable()
  efi_delete_dummy_variable()
  efi_enter_virtual_mode()
  start_kernel()
  x86_64_start_reservations()
  x86_64_start_kernel()
  start_cpu()

[ efi=old_map was never intended to work with kexec. The problem with
using efi=old_map is that the virtual addresses are assigned from the memory region used by other kernel mappings; vmalloc() space. Potentially there could be collisions when booting kexec if something else is mapped at the virtual address we allocated for runtime service regions in the initial boot - Matt Fleming ]

Since kexec was never intended to work with efi=old_map, disable runtime services in kexec if booted with efi=old_map, so that we don't panic.

Tested-by Lee Chun-Yi <[email protected]>

Signed-off-by Sai Praneeth Prakhya <[email protected]>

Signed-off-by Matt Fleming <[email protected]>

Acked-by Dave Young <[email protected]>

Cc Ard Biesheuvel <[email protected]>

Cc Borislav Petkov <[email protected]>

Cc Linus Torvalds <[email protected]>

Cc Peter Zijlstra <[email protected]>

Cc Ravi Shankar <[email protected]>

Cc Ricardo Neri <[email protected]>

Cc Thomas Gleixner <[email protected]>

Link http://lkml.kernel.org/r/[email protected] open here

Signed-off-by Ingo Molnar <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 arch/x86/platform/efi/efi.c |    6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

arch/x86/platform/efi/efi.c +4 -2

@@ -832,9 +832,11 @@ static void __init kexec_enter_virtual_m
 
 	/*
 	 * We don't do virtual mode, since we don't do runtime services, on
-	 * non-native EFI
+	 * non-native EFI. With efi=old_map, we don't do runtime services in
+	 * kexec kernel because in the initial boot something else might
+	 * have been mapped at these virtual addresses.
 	 */
-	if (!efi_is_native()) {
+	if (!efi_is_native() || efi_enabled(EFI_OLD_MEMMAP)) {
 		efi_memmap_unmap();
 		clear_bit(EFI_RUNTIME_SERVICES, &efi.flags);
 		return;

Greg Kroah-Hartman

author maintainer

2018-04-11 18:34 UTC #152 lore raw

PATCH 150/310 netfilter: conntrack: dont call iter for non-confirmed conntracks

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Florian Westphal <[email protected]>

[ Upstream commit b0feacaad13a0aa9657c37ed80991575981e2e3b ]

nf_ct_iterate_cleanup_net currently calls iter() callback also for conntracks on the unconfirmed list, but this is unsafe.

Acesses to nf_conn are fine, but some users access the extension area in the iter() callback, but that does only work reliably for confirmed conntracks (ct->ext can be reallocated at any time for unconfirmed conntrack).

The seond issue is that there is a short window where a conntrack entry is neither on the list nor in the table: To confirm an entry, it is first removed from the unconfirmed list, then insert into the table.

Fix this by iterating the unconfirmed list first and marking all entries as dying, then wait for rcu grace period.

This makes sure all entries that were about to be confirmed either are in the main table, or will be dropped soon.

Signed-off-by Florian Westphal <[email protected]>

Signed-off-by Pablo Neira Ayuso <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 net/netfilter/nf_conntrack_core.c |   39 ++++++++++++++++++++++++++++----------
 1 file changed, 29 insertions(+), 10 deletions(-)

net/netfilter/nf_conntrack_core.c +29 ~~-10~~

@@ -1542,7 +1542,6 @@ get_next_corpse(struct net *net, int (*i
 	struct nf_conntrack_tuple_hash *h;
 	struct nf_conn *ct;
 	struct hlist_nulls_node *n;
-	int cpu;
 	spinlock_t *lockp;
 
 	for (; *bucket < nf_conntrack_htable_size; (*bucket)++) {

@@ -1564,24 +1563,40 @@ get_next_corpse(struct net *net, int (*i
 		cond_resched();
 	}
 
+	return NULL;
+found:
+	atomic_inc(&ct->ct_general.use);
+	spin_unlock(lockp);
+	local_bh_enable();
+	return ct;
+}
+
+static void
+__nf_ct_unconfirmed_destroy(struct net *net)
+{
+	int cpu;
+
 	for_each_possible_cpu(cpu) {
-		struct ct_pcpu *pcpu = per_cpu_ptr(net->ct.pcpu_lists, cpu);
+		struct nf_conntrack_tuple_hash *h;
+		struct hlist_nulls_node *n;
+		struct ct_pcpu *pcpu;
+
+		pcpu = per_cpu_ptr(net->ct.pcpu_lists, cpu);
 
 		spin_lock_bh(&pcpu->lock);
 		hlist_nulls_for_each_entry(h, n, &pcpu->unconfirmed, hnnode) {
+			struct nf_conn *ct;
+
 			ct = nf_ct_tuplehash_to_ctrack(h);
-			if (iter(ct, data))
-				set_bit(IPS_DYING_BIT, &ct->status);
+
+			/* we cannot call iter() on unconfirmed list, the
+			 * owning cpu can reallocate ct->ext at any time.
+			 */
+			set_bit(IPS_DYING_BIT, &ct->status);
 		}
 		spin_unlock_bh(&pcpu->lock);
 		cond_resched();
 	}
-	return NULL;
-found:
-	atomic_inc(&ct->ct_general.use);
-	spin_unlock(lockp);
-	local_bh_enable();
-	return ct;
 }
 
 void nf_ct_iterate_cleanup(struct net *net,

@@ -1596,6 +1611,10 @@ void nf_ct_iterate_cleanup(struct net *n
 	if (atomic_read(&net->ct.count) == 0)
 		return;
 
+	__nf_ct_unconfirmed_destroy(net);
+
+	synchronize_net();
+
 	while ((ct = get_next_corpse(net, iter, data, &bucket)) != NULL) {
 		/* Time to push up daises... */

Greg Kroah-Hartman

author maintainer

2018-04-11 18:34 UTC #153 lore raw

PATCH 151/310 HID: i2c: Call acpi_device_fix_up_power for ACPI-enumerated devices

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Hans de Goede <[email protected]>

[ Upstream commit f3d3eab667de62572376abb1aa26316191c39929 ]

For ACPI devices which do not have a _PSC method, the ACPI subsys cannot query their initial state at boot, so these devices are assumed to have been put in D0 by the BIOS, but for touchscreens that is not always true.

This commit adds a call to acpi_device_fix_up_power to explicitly put devices without a _PSC method into D0 state (for devices with a _PSC method it is a nop). Note we only need to do this on probe, after a resume the ACPI subsys knows the device is in D3 and will properly put it in D0.

This fixes the SIS0817 i2c-hid touchscreen on a Peaq C1010 2-in-1 device failing to probe with a "hid_descr_cmd failed" error.

Acked-by Benjamin Tissoires <[email protected]>

Signed-off-by Jiri Kosina <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/hid/i2c-hid/i2c-hid.c |   13 +++++++++++++
 1 file changed, 13 insertions(+)

drivers/hid/i2c-hid/i2c-hid.c +13 -0

@@ -968,6 +968,15 @@ static int i2c_hid_acpi_pdata(struct i2c
 	return ret < 0 && ret != -ENXIO ? ret : 0;
 }
 
+static void i2c_hid_acpi_fix_up_power(struct device *dev)
+{
+	acpi_handle handle = ACPI_HANDLE(dev);
+	struct acpi_device *adev;
+
+	if (handle && acpi_bus_get_device(handle, &adev) == 0)
+		acpi_device_fix_up_power(adev);
+}
+
 static const struct acpi_device_id i2c_hid_acpi_match[] = {
 	{"ACPI0C50", 0 },
 	{"PNP0C50", 0 },

@@ -980,6 +989,8 @@ static inline int i2c_hid_acpi_pdata(str
 {
 	return -ENODEV;
 }
+
+static inline void i2c_hid_acpi_fix_up_power(struct device *dev) {}
 #endif
 
 #ifdef CONFIG_OF

@@ -1082,6 +1093,8 @@ static int i2c_hid_probe(struct i2c_clie
 	if (ret < 0)
 		goto err;
 
+	i2c_hid_acpi_fix_up_power(&client->dev);
+
 	pm_runtime_get_noresume(&client->dev);
 	pm_runtime_set_active(&client->dev);
 	pm_runtime_enable(&client->dev);

Greg Kroah-Hartman

author maintainer

2018-04-11 18:34 UTC #154 lore raw

PATCH 152/310 ovl: filter trusted xattr for non-admin

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Miklos Szeredi <[email protected]>

[ Upstream commit a082c6f680da298cf075886ff032f32ccb7c5e1a ]

Filesystems filter out extended attributes in the "trusted." domain for unprivlieged callers.

Overlay calls underlying filesystem's method with elevated privs, so need to do the filtering in overlayfs too.

Signed-off-by Miklos Szeredi <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 fs/overlayfs/inode.c |   12 +++++++++++-
 1 file changed, 11 insertions(+), 1 deletion(-)

fs/overlayfs/inode.c +11 -1

@@ -227,6 +227,16 @@ int ovl_xattr_get(struct dentry *dentry,
 	return res;
 }
 
+static bool ovl_can_list(const char *s)
+{
+	/* List all non-trusted xatts */
+	if (strncmp(s, XATTR_TRUSTED_PREFIX, XATTR_TRUSTED_PREFIX_LEN) != 0)
+		return true;
+
+	/* Never list trusted.overlay, list other trusted for superuser only */
+	return !ovl_is_private_xattr(s) && capable(CAP_SYS_ADMIN);
+}
+
 ssize_t ovl_listxattr(struct dentry *dentry, char *list, size_t size)
 {
 	struct dentry *realdentry = ovl_dentry_real(dentry);

@@ -250,7 +260,7 @@ ssize_t ovl_listxattr(struct dentry *den
 			return -EIO;
 
 		len -= slen;
-		if (ovl_is_private_xattr(s)) {
+		if (!ovl_can_list(s)) {
 			res -= slen;
 			memmove(s, s + slen, len);
 		} else {

Greg Kroah-Hartman

author maintainer

2018-04-11 18:34 UTC #155 lore raw

PATCH 153/310 powerpc/[booke|4xx]: Dont clobber TCR[WP] when setting TCR[DIE]

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Ivan Mikhaylov <[email protected]>

[ Upstream commit 6e2f03e292ef46eed2b31b0a344a91d514f9cd81 ]

Prevent a kernel panic caused by unintentionally clearing TCR watchdog bits. At this point in the kernel boot, the watchdog may have already been enabled by u-boot. The original code's attempt to write to the TCR register results in an inadvertent clearing of the watchdog configuration bits, causing the 476 to reset.

Signed-off-by Ivan Mikhaylov <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 arch/powerpc/kernel/time.c |   14 +++++++++++---
 1 file changed, 11 insertions(+), 3 deletions(-)

arch/powerpc/kernel/time.c +11 -3

@@ -719,12 +719,20 @@ static int __init get_freq(char *name, i
 static void start_cpu_decrementer(void)
 {
 #if defined(CONFIG_BOOKE) || defined(CONFIG_40x)
+	unsigned int tcr;
+
 	/* Clear any pending timer interrupts */
 	mtspr(SPRN_TSR, TSR_ENW | TSR_WIS | TSR_DIS | TSR_FIS);
 
-	/* Enable decrementer interrupt */
-	mtspr(SPRN_TCR, TCR_DIE);
-#endif /* defined(CONFIG_BOOKE) || defined(CONFIG_40x) */
+	tcr = mfspr(SPRN_TCR);
+	/*
+	 * The watchdog may have already been enabled by u-boot. So leave
+	 * TRC[WP] (Watchdog Period) alone.
+	 */
+	tcr &= TCR_WP_MASK;	/* Clear all bits except for TCR[WP] */
+	tcr |= TCR_DIE;		/* Enable decrementer */
+	mtspr(SPRN_TCR, tcr);
+#endif
 }
 
 void __init generic_calibrate_decr(void)

Greg Kroah-Hartman

author maintainer

2018-04-11 18:34 UTC #156 lore raw

PATCH 154/310 dmaengine: imx-sdma: Handle return value of clk_prepare_enable

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Arvind Yadav <[email protected]>

[ Upstream commit fb9caf370f4d0457789d13a1a1b110a8db846e5e ]

clk_prepare_enable() can fail here and we must check its return value.

Signed-off-by Arvind Yadav <[email protected]>

Signed-off-by Vinod Koul <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/dma/imx-sdma.c |   23 ++++++++++++++++++-----
 1 file changed, 18 insertions(+), 5 deletions(-)

drivers/dma/imx-sdma.c +18 -5

@@ -1755,19 +1755,26 @@ static int sdma_probe(struct platform_de
 	if (IS_ERR(sdma->clk_ahb))
 		return PTR_ERR(sdma->clk_ahb);
 
-	clk_prepare(sdma->clk_ipg);
-	clk_prepare(sdma->clk_ahb);
+	ret = clk_prepare(sdma->clk_ipg);
+	if (ret)
+		return ret;
+
+	ret = clk_prepare(sdma->clk_ahb);
+	if (ret)
+		goto err_clk;
 
 	ret = devm_request_irq(&pdev->dev, irq, sdma_int_handler, 0, "sdma",
 			       sdma);
 	if (ret)
-		return ret;
+		goto err_irq;
 
 	sdma->irq = irq;
 
 	sdma->script_addrs = kzalloc(sizeof(*sdma->script_addrs), GFP_KERNEL);
-	if (!sdma->script_addrs)
-		return -ENOMEM;
+	if (!sdma->script_addrs) {
+		ret = -ENOMEM;
+		goto err_irq;
+	}
 
 	/* initially no scripts available */
 	saddr_arr = (s32 *)sdma->script_addrs;

@@ -1882,6 +1889,10 @@ err_register:
 	dma_async_device_unregister(&sdma->dma_device);
 err_init:
 	kfree(sdma->script_addrs);
+err_irq:
+	clk_unprepare(sdma->clk_ahb);
+err_clk:
+	clk_unprepare(sdma->clk_ipg);
 	return ret;
 }

@@ -1893,6 +1904,8 @@ static int sdma_remove(struct platform_d
 	devm_free_irq(&pdev->dev, sdma->irq, sdma);
 	dma_async_device_unregister(&sdma->dma_device);
 	kfree(sdma->script_addrs);
+	clk_unprepare(sdma->clk_ahb);
+	clk_unprepare(sdma->clk_ipg);
 	/* Kill the tasklet */
 	for (i = 0; i < MAX_DMA_CHANNELS; i++) {
 		struct sdma_channel *sdmac = &sdma->channel[i];

Greg Kroah-Hartman

author maintainer

2018-04-11 18:34 UTC #157 lore raw

PATCH 155/310 backlight: Report error on failure

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Sudip Mukherjee <[email protected]>

[ Upstream commit 7e715c2d9c27c23f3187454157c58cf292ed103e ]

It is possible to update the backlight power and the brightness using the sysfs and on writing it either returns the count or if the callback function does not exist then returns the error code 'ENXIO'.

We have a situation where the userspace client is writing to the sysfs to update the power and since the callback function exists the client receives the return value as count and considers the operation to be successful. That is correct as the write to the sysfs was successful. But there is no way to know if the actual operation was done or not.

backlight_update_status() returns the error code if it fails. Pass that to the userspace client who is trying to update the power so that the client knows that the operation failed.

Signed-off-by Sudip Mukherjee <[email protected]>

Acked-by Daniel Thompson <[email protected]>

Signed-off-by Lee Jones <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/video/backlight/backlight.c |   15 ++++++++++-----
 1 file changed, 10 insertions(+), 5 deletions(-)

drivers/video/backlight/backlight.c +10 -5

@@ -134,7 +134,7 @@ static ssize_t bl_power_store(struct dev
 {
 	int rc;
 	struct backlight_device *bd = to_backlight_device(dev);
-	unsigned long power;
+	unsigned long power, old_power;
 
 	rc = kstrtoul(buf, 0, &power);
 	if (rc)

@@ -145,10 +145,16 @@ static ssize_t bl_power_store(struct dev
 	if (bd->ops) {
 		pr_debug("set power to %lu\n", power);
 		if (bd->props.power != power) {
+			old_power = bd->props.power;
 			bd->props.power = power;
-			backlight_update_status(bd);
+			rc = backlight_update_status(bd);
+			if (rc)
+				bd->props.power = old_power;
+			else
+				rc = count;
+		} else {
+			rc = count;
 		}
-		rc = count;
 	}
 	mutex_unlock(&bd->ops_lock);

@@ -176,8 +182,7 @@ int backlight_device_set_brightness(stru
 		else {
 			pr_debug("set brightness to %lu\n", brightness);
 			bd->props.brightness = brightness;
-			backlight_update_status(bd);
-			rc = 0;
+			rc = backlight_update_status(bd);
 		}
 	}
 	mutex_unlock(&bd->ops_lock);

Greg Kroah-Hartman

author maintainer

2018-04-11 18:34 UTC #158 lore raw

PATCH 156/310 arm64: futex: Fix undefined behaviour with FUTEX_OP_OPARG_SHIFT usage

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Will Deacon <[email protected]>

[ Upstream commit 5f16a046f8e144c294ef98cd29d9458b5f8273e5 ]

FUTEX_OP_OPARG_SHIFT instructs the futex code to treat the 12-bit oparg field as a shift value, potentially leading to a left shift value that is negative or with an absolute value that is significantly larger then the size of the type. UBSAN chokes with:

================================================================================

UBSAN: Undefined behaviour in ./arch/arm64/include/asm/futex.h:60:13
shift exponent -1 is negative
CPU: 1 PID: 1449 Comm: syz-executor0 Not tainted 4.11.0-rc4-00005-g977eb52-dirty #11
Hardware name: linux,dummy-virt (DT)
Call trace:
[<ffff200008094778>] dump_backtrace+0x0/0x538 arch/arm64/kernel/traps.c:73
[<ffff200008094cd0>] show_stack+0x20/0x30 arch/arm64/kernel/traps.c:228
[<ffff200008c194a8>] __dump_stack lib/dump_stack.c:16 [inline]
[<ffff200008c194a8>] dump_stack+0x120/0x188 lib/dump_stack.c:52
[<ffff200008cc24b8>] ubsan_epilogue+0x18/0x98 lib/ubsan.c:164
[<ffff200008cc3098>] __ubsan_handle_shift_out_of_bounds+0x250/0x294 lib/ubsan.c:421
[<ffff20000832002c>] futex_atomic_op_inuser arch/arm64/include/asm/futex.h:60 [inline]
[<ffff20000832002c>] futex_wake_op kernel/futex.c:1489 [inline]
[<ffff20000832002c>] do_futex+0x137c/0x1740 kernel/futex.c:3231
[<ffff200008320504>] SYSC_futex kernel/futex.c:3281 [inline]
[<ffff200008320504>] SyS_futex+0x114/0x268 kernel/futex.c:3249
[<ffff200008084770>] el0_svc_naked+0x24/0x28
================================================================================

syz-executor1 uses obsolete (PF_INET,SOCK_PACKET)
sock: process `syz-executor0' is using obsolete setsockopt SO_BSDCOMPAT

This patch attempts to fix some of this by:

* Making encoded_op an unsigned type, so we can shift it left even if the top bit is set.

* Casting to signed prior to shifting right when extracting oparg and cmparg

* Consider only the bottom 5 bits of oparg when using it as a left-shift value.

Whilst I think this catches all of the issues, I'd much prefer to remove this stuff, as I think it's unused and the bugs are copy-pasted between a bunch of architectures.

Reviewed-by Robin Murphy <[email protected]>

Signed-off-by Will Deacon <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 arch/arm64/include/asm/futex.h |    8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

arch/arm64/include/asm/futex.h +4 -4

@@ -51,16 +51,16 @@
 	: "memory")
 
 static inline int
-futex_atomic_op_inuser (int encoded_op, u32 __user *uaddr)
+futex_atomic_op_inuser(unsigned int encoded_op, u32 __user *uaddr)
 {
 	int op = (encoded_op >> 28) & 7;
 	int cmp = (encoded_op >> 24) & 15;
-	int oparg = (encoded_op << 8) >> 20;
-	int cmparg = (encoded_op << 20) >> 20;
+	int oparg = (int)(encoded_op << 8) >> 20;
+	int cmparg = (int)(encoded_op << 20) >> 20;
 	int oldval = 0, ret, tmp;
 
 	if (encoded_op & (FUTEX_OP_OPARG_SHIFT << 28))
-		oparg = 1 << oparg;
+		oparg = 1U << (oparg & 0x1f);
 
 	if (!access_ok(VERIFY_WRITE, uaddr, sizeof(u32)))
 		return -EFAULT;

Greg Kroah-Hartman

author maintainer

2018-04-11 18:34 UTC #159 lore raw

PATCH 157/310 net/mlx5: avoid build warning for uniprocessor

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Arnd Bergmann <[email protected]>

[ Upstream commit f0d7ae95fff4ab444b8433f07afc4b077ef1a285 ]

Building the driver with CONFIG_SMP disabled results in a harmless warning:

ethernet/mellanox/mlx5/core/main.c: In function 'mlx5_irq_set_affinity_hint':
ethernet/mellanox/mlx5/core/main.c:615:6: error: unused variable 'irq' [-Werror=unused-variable]

It's better to express the conditional compilation using IS_ENABLED() here, as that lets the compiler see what the intented use for the variable is, and that it can be silently discarded.

Fixes b665d98edc9a ("net/mlx5: Tolerate irq_set_affinity_hint() failures")

Signed-off-by Arnd Bergmann <[email protected]>

Acked-by Saeed Mahameed <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/net/ethernet/mellanox/mlx5/core/main.c |    5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

drivers/net/ethernet/mellanox/mlx5/core/main.c +2 -3

@@ -557,10 +557,9 @@ static int mlx5_irq_set_affinity_hint(st
 	cpumask_set_cpu(cpumask_local_spread(i, priv->numa_node),
 			priv->irq_info[i].mask);
 
-#ifdef CONFIG_SMP
-	if (irq_set_affinity_hint(irq, priv->irq_info[i].mask))
+	if (IS_ENABLED(CONFIG_SMP) &&
+	    irq_set_affinity_hint(irq, priv->irq_info[i].mask))
 		mlx5_core_warn(mdev, "irq_set_affinity_hint failed, irq 0x%.4x", irq);
-#endif
 
 	return 0;
 }

Greg Kroah-Hartman

author maintainer

2018-04-11 18:34 UTC #161 lore raw

PATCH 159/310 cxgb4: Fix netdev_features flag

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Arjun Vynipadath <[email protected]>

[ Upstream commit 90592b9a35836bacd34d92a3aba7958756b6a7c0 ]

GRO is not supported by Chelsio HW when rx_csum is disabled. Update the netdev features flag when rx_csum is modified.

Signed-off-by Arjun Vynipadath <[email protected]>

Signed-off-by Steve Wise <[email protected]>

Signed-off-by Ganesh Goudar <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c |   11 +++++++++++
 1 file changed, 11 insertions(+)

drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c +11 -0

@@ -2742,6 +2742,16 @@ static int cxgb_setup_tc(struct net_devi
 	return -EOPNOTSUPP;
 }
 
+static netdev_features_t cxgb_fix_features(struct net_device *dev,
+					   netdev_features_t features)
+{
+	/* Disable GRO, if RX_CSUM is disabled */
+	if (!(features & NETIF_F_RXCSUM))
+		features &= ~NETIF_F_GRO;
+
+	return features;
+}
+
 static const struct net_device_ops cxgb4_netdev_ops = {
 	.ndo_open             = cxgb_open,
 	.ndo_stop             = cxgb_close,

@@ -2766,6 +2776,7 @@ static const struct net_device_ops cxgb4
 #endif
 	.ndo_set_tx_maxrate   = cxgb_set_tx_maxrate,
 	.ndo_setup_tc         = cxgb_setup_tc,
+	.ndo_fix_features     = cxgb_fix_features,
 };
 
 #ifdef CONFIG_PCI_IOV

Greg Kroah-Hartman

author maintainer

2018-04-11 18:34 UTC #162 lore raw

PATCH 160/310 rtc: m41t80: fix SQW dividers override when setting a date

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Gary Bisson <[email protected]>

[ Upstream commit 0f546b058b86ea2f661cc7a6e931cee5a29959ef ]

This patch is only relevant for RTC with the SQ_ALT feature which means the clock output frequency divider is stored in the weekday register.

Current implementation discards the previous dividers value and clear them as soon as the time is set.

Signed-off-by Gary Bisson <[email protected]>

Signed-off-by Alexandre Belloni <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/rtc/rtc-m41t80.c |   12 ++++++++++++
 1 file changed, 12 insertions(+)

drivers/rtc/rtc-m41t80.c +12 -0

@@ -168,6 +168,7 @@ static int m41t80_get_datetime(struct i2
 /* Sets the given date and time to the real time clock. */
 static int m41t80_set_datetime(struct i2c_client *client, struct rtc_time *tm)
 {
+	struct m41t80_data *clientdata = i2c_get_clientdata(client);
 	unsigned char buf[8];
 	int err, flags;

@@ -183,6 +184,17 @@ static int m41t80_set_datetime(struct i2
 	buf[M41T80_REG_YEAR] = bin2bcd(tm->tm_year - 100);
 	buf[M41T80_REG_WDAY] = tm->tm_wday;
 
+	/* If the square wave output is controlled in the weekday register */
+	if (clientdata->features & M41T80_FEATURE_SQ_ALT) {
+		int val;
+
+		val = i2c_smbus_read_byte_data(client, M41T80_REG_WDAY);
+		if (val < 0)
+			return val;
+
+		buf[M41T80_REG_WDAY] |= (val & 0xf0);
+	}
+
 	err = i2c_smbus_write_i2c_block_data(client, M41T80_REG_SSEC,
 					     sizeof(buf), buf);
 	if (err < 0) {

Greg Kroah-Hartman

author maintainer

2018-04-11 18:35 UTC #163 lore raw

PATCH 161/310 i40evf: fix merge error in older patch

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Jesse Brandeburg <[email protected]>

[ Upstream commit 155b0f690051345deefc653774b739c786067d61 ]

This patch fixes a missing line that was missed while merging, which results in a driver feature in the VF not working to enable RSS as a negotiated feature.

Fixes 43a3d9ba34c9c ("i40evf: Allow PF driver to configure RSS")

Signed-off-by Jesse Brandeburg <[email protected]>

Tested-by Andrew Bowers <[email protected]>

Signed-off-by Jeff Kirsher <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/net/ethernet/intel/i40evf/i40evf_virtchnl.c |    1 +
 1 file changed, 1 insertion(+)

drivers/net/ethernet/intel/i40evf/i40evf_virtchnl.c +1 -0

@@ -154,6 +154,7 @@ int i40evf_send_vf_config_msg(struct i40
 	adapter->current_op = I40E_VIRTCHNL_OP_GET_VF_RESOURCES;
 	adapter->aq_required &= ~I40EVF_FLAG_AQ_GET_CONFIG;
 	caps = I40E_VIRTCHNL_VF_OFFLOAD_L2 |
+	       I40E_VIRTCHNL_VF_OFFLOAD_RSS_PF |
 	       I40E_VIRTCHNL_VF_OFFLOAD_RSS_AQ |
 	       I40E_VIRTCHNL_VF_OFFLOAD_RSS_REG |
 	       I40E_VIRTCHNL_VF_OFFLOAD_VLAN |

Greg Kroah-Hartman

author maintainer

2018-04-11 18:35 UTC #164 lore raw

PATCH 162/310 rtc: opal: Handle disabled TPO in opal_get_tpo_time()

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Vaibhav Jain <[email protected]>

[ Upstream commit 6dc1cf6f932bb0ea4d8f5e913a0a401ecacd2f03 ]

On PowerNV platform when Timed-Power-On(TPO) is disabled, read of stored TPO yields value with all date components set to '0' inside opal_get_tpo_time(). The function opal_to_tm() then converts it to an offset from year 1900 yielding alarm-time == "1900-00-01 00:00:00". This causes problems with __rtc_read_alarm() that expecting an offset from "1970-00-01 00:00:00" and returned alarm-time results in a -ve value for time64_t. Which ultimately results in this error reported in kernel logs with a seemingly garbage value:

"rtc rtc0: invalid alarm value: -2-1--1041528741
2005511117:71582844:32"

We fix this by explicitly handling the case of all alarm date-time components being '0' inside opal_get_tpo_time() and returning -ENOENT in such a case. This signals generic rtc that no alarm is set and it bails out from the alarm initialization flow without reporting the above error.

Signed-off-by Vaibhav Jain <[email protected]>

Reported-by Steve Best <[email protected]>

Signed-off-by Alexandre Belloni <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/rtc/rtc-opal.c |   10 ++++++++++
 1 file changed, 10 insertions(+)

drivers/rtc/rtc-opal.c +10 -0

@@ -150,6 +150,16 @@ static int opal_get_tpo_time(struct devi
 
 	y_m_d = be32_to_cpu(__y_m_d);
 	h_m_s_ms = ((u64)be32_to_cpu(__h_m) << 32);
+
+	/* check if no alarm is set */
+	if (y_m_d == 0 && h_m_s_ms == 0) {
+		pr_debug("No alarm is set\n");
+		rc = -ENOENT;
+		goto exit;
+	} else {
+		pr_debug("Alarm set to %x %llx\n", y_m_d, h_m_s_ms);
+	}
+
 	opal_to_tm(y_m_d, h_m_s_ms, &alarm->time);
 
 exit:

Greg Kroah-Hartman

author maintainer

2018-04-11 18:35 UTC #166 lore raw

PATCH 164/310 SUNRPC: ensure correct error is reported by xs_tcp_setup_socket()

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: NeilBrown <[email protected]>

[ Upstream commit 6ea44adce91526700535b3150f77f8639ae8c82d ]

If you attempt a TCP mount from an host that is unreachable in a way that triggers an immediate error from kernel_connect(), that error does not propagate up, instead EAGAIN is reported.

This results in call_connect_status receiving the wrong error.

A case that it easy to demonstrate is to attempt to mount from an address that results in ENETUNREACH, but first deleting any default route.
Without this patch, the mount.nfs process is persistently runnable and is hard to kill. With this patch it exits as it should.

The problem is caused by the fact that xs_tcp_force_close() eventually calls

      xprt_wake_pending_tasks(xprt, -EAGAIN);
which causes an error return of -EAGAIN.  so when xs_tcp_setup_sock()
calls
      xprt_wake_pending_tasks(xprt, status);

the status is ignored.

Fixes 4efdd92c9211 ("SUNRPC: Remove TCP client connection reset hack")

Signed-off-by NeilBrown <[email protected]>

Signed-off-by Trond Myklebust <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 net/sunrpc/xprtsock.c |    7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

net/sunrpc/xprtsock.c +6 -1

@@ -2384,7 +2384,12 @@ static void xs_tcp_setup_socket(struct w
 	case -EHOSTUNREACH:
 	case -EADDRINUSE:
 	case -ENOBUFS:
-		/* retry with existing socket, after a delay */
+		/*
+		 * xs_tcp_force_close() wakes tasks with -EIO.
+		 * We need to wake them first to ensure the
+		 * correct error code.
+		 */
+		xprt_wake_pending_tasks(xprt, status);
 		xs_tcp_force_close(xprt);
 		goto out;
 	}

Greg Kroah-Hartman

author maintainer

2018-04-11 18:35 UTC #167 lore raw

PATCH 165/310 net: freescale: fix potential null pointer dereference

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: "Gustavo A. R. Silva" <[email protected]>

[ Upstream commit 06d2d6431bc8d41ef5ffd8bd4b52cea9f72aed22 ]

Add NULL check before dereferencing pointer _id_ in order to avoid a potential NULL pointer dereference.

Addresses-Coverity-ID: 1397995

Signed-off-by Gustavo A. R. Silva <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/net/ethernet/freescale/fsl_pq_mdio.c |    9 ++++++++-
 1 file changed, 8 insertions(+), 1 deletion(-)

drivers/net/ethernet/freescale/fsl_pq_mdio.c +8 -1

@@ -381,7 +381,7 @@ static int fsl_pq_mdio_probe(struct plat
 {
 	const struct of_device_id *id =
 		of_match_device(fsl_pq_mdio_match, &pdev->dev);
-	const struct fsl_pq_mdio_data *data = id->data;
+	const struct fsl_pq_mdio_data *data;
 	struct device_node *np = pdev->dev.of_node;
 	struct resource res;
 	struct device_node *tbi;

@@ -389,6 +389,13 @@ static int fsl_pq_mdio_probe(struct plat
 	struct mii_bus *new_bus;
 	int err;
 
+	if (!id) {
+		dev_err(&pdev->dev, "Failed to match device\n");
+		return -ENODEV;
+	}
+
+	data = id->data;
+
 	dev_dbg(&pdev->dev, "found %s compatible node\n", id->compatible);
 
 	new_bus = mdiobus_alloc_size(sizeof(*priv));

Greg Kroah-Hartman

author maintainer

2018-04-11 18:35 UTC #168 lore raw

PATCH 166/310 clk: at91: fix clk-generated parenting

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Alexandre Belloni <[email protected]>

[ Upstream commit 8e56133e5c7b7a7a97f6a92d92f664d5ecd30745 ]

clk_generated_startup is called after clk_hw_register. So the first call to get_parent will not have the correct value (i.e. 0) and because this is cached, it may never be updated.

Signed-off-by Alexandre Belloni <[email protected]>

Fixes df70aeef6083 ("clk: at91: add generated clock driver")

Signed-off-by Stephen Boyd <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/clk/at91/clk-generated.c |    3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

drivers/clk/at91/clk-generated.c +1 -2

@@ -260,13 +260,12 @@ at91_clk_register_generated(struct regma
 	gck->lock = lock;
 	gck->range = *range;
 
+	clk_generated_startup(gck);
 	hw = &gck->hw;
 	ret = clk_hw_register(NULL, &gck->hw);
 	if (ret) {
 		kfree(gck);
 		hw = ERR_PTR(ret);
-	} else
-		clk_generated_startup(gck);
 
 	return hw;
 }

Greg Kroah-Hartman

author maintainer

2018-04-11 18:35 UTC #169 lore raw

PATCH 167/310 drm/sun4i: Ignore the generic connectors for components

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Maxime Ripard <[email protected]>

[ Upstream commit 49baeb074783f5bdf770dc9fac5fbb2837190583 ]

The generic connectors such as hdmi-connector doesn't have any driver in, so if they are added to the component list, we will be waiting forever for a non-existing driver to probe.

Add a list of the connectors we want to ignore when building our component list.

Reviewed-by Chen-Yu Tsai <[email protected]>

Signed-off-by Maxime Ripard <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/gpu/drm/sun4i/sun4i_drv.c |   12 ++++++++++++
 1 file changed, 12 insertions(+)

drivers/gpu/drm/sun4i/sun4i_drv.c +12 -0

@@ -212,6 +212,11 @@ static const struct component_master_ops
 	.unbind	= sun4i_drv_unbind,
 };
 
+static bool sun4i_drv_node_is_connector(struct device_node *node)
+{
+	return of_device_is_compatible(node, "hdmi-connector");
+}
+
 static bool sun4i_drv_node_is_frontend(struct device_node *node)
 {
 	return of_device_is_compatible(node, "allwinner,sun5i-a13-display-frontend") ||

@@ -252,6 +257,13 @@ static int sun4i_drv_add_endpoints(struc
 	    !of_device_is_available(node))
 		return 0;
 
+	/*
+	 * The connectors will be the last nodes in our pipeline, we
+	 * can just bail out.
+	 */
+	if (sun4i_drv_node_is_connector(node))
+		return 0;
+
 	if (!sun4i_drv_node_is_frontend(node)) {
 		/* Add current component */
 		DRM_DEBUG_DRIVER("Adding component %s\n",

Greg Kroah-Hartman

author maintainer

2018-04-11 18:35 UTC #170 lore raw

PATCH 168/310 dt-bindings: display: sun4i: Add allwinner,tcon-channel property

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Maxime Ripard <[email protected]>

[ Upstream commit 22662f12768f971809b478386d9cc4947d00497a ]

The Allwinner Timings Controller has two, mutually exclusive, channels. When the binding has been introduced, it was assumed that there would be only a single user per channel in the system.

While this is likely for the channel 0 which only connects to LCD displays, it turns out that the channel 1 can be connected to multiple controllers in the SoC (HDMI and TV encoders for example). And while the simultaneous use of HDMI and TV outputs cannot be achieved, switching from one to the other at runtime definitely sounds plausible.

Add an extra property, allwinner,tcon-channel, to specify for a given endpoint which TCON channel it is connected to, while falling back to the previous mechanism if that property is missing.

Acked-by Chen-Yu Tsai <[email protected]>

Acked-by Rob Herring <[email protected]>

Signed-off-by Maxime Ripard <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt |   11 ++++++----
 1 file changed, 7 insertions(+), 4 deletions(-)

Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt +7 -4

@@ -47,10 +47,13 @@ Required properties:
   Documentation/devicetree/bindings/media/video-interfaces.txt. The
   first port should be the input endpoint, the second one the output
 
-  The output should have two endpoints. The first is the block
-  connected to the TCON channel 0 (usually a panel or a bridge), the
-  second the block connected to the TCON channel 1 (usually the TV
-  encoder)
+  The output may have multiple endpoints. The TCON has two channels,
+  usually with the first channel being used for the panels interfaces
+  (RGB, LVDS, etc.), and the second being used for the outputs that
+  require another controller (TV Encoder, HDMI, etc.). The endpoints
+  will take an extra property, allwinner,tcon-channel, to specify the
+  channel the endpoint is associated to. If that property is not
+  present, the endpoint number will be used as the channel number.
 
 On SoCs other than the A33, there is one more clock required:
    - 'tcon-ch1': The clock driving the TCON channel 1

Greg Kroah-Hartman

author maintainer

2018-04-11 18:35 UTC #171 lore raw

PATCH 169/310 mtd: nand: gpmi: Fix gpmi_nand_init() error path

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Boris Brezillon <[email protected]>

[ Upstream commit 4d02423e9afe6c46142ce98bbcaf5167316dbfbf ]

The GPMI driver is wrongly assuming that nand_release() can safely be called on an uninitialized/unregistered NAND device.

Add a new err_nand_cleanup label in the error path and only execute if nand_scan_tail() succeeded.

Note that we now call nand_cleanup() instead of nand_release() (nand_release() is actually grouping the mtd_device_unregister() and nand_cleanup() in one call) because there's no point in trying to unregister a device that has never been registered.

Signed-off-by Boris Brezillon <[email protected]>

Reviewed-by Marek Vasut <[email protected]>

Acked-by Han Xu <[email protected]>

Reviewed-by Marek Vasut <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/mtd/nand/gpmi-nand/gpmi-nand.c |   10 ++++++----
 1 file changed, 6 insertions(+), 4 deletions(-)

drivers/mtd/nand/gpmi-nand/gpmi-nand.c +6 -4

@@ -2047,18 +2047,20 @@ static int gpmi_nand_init(struct gpmi_na
 
 	ret = nand_boot_init(this);
 	if (ret)
-		goto err_out;
+		goto err_nand_cleanup;
 	ret = chip->scan_bbt(mtd);
 	if (ret)
-		goto err_out;
+		goto err_nand_cleanup;
 
 	ret = mtd_device_register(mtd, NULL, 0);
 	if (ret)
-		goto err_out;
+		goto err_nand_cleanup;
 	return 0;
 
+err_nand_cleanup:
+	nand_cleanup(chip);
 err_out:
-	gpmi_nand_exit(this);
+	gpmi_free_dma_buffer(this);
 	return ret;
 }

Greg Kroah-Hartman

author maintainer

2018-04-11 18:35 UTC #172 lore raw

PATCH 170/310 mtd: nand: check ecc->total sanity in nand_scan_tail

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Masahiro Yamada <[email protected]>

[ Upstream commit 79e0348c4e24fd1affdcf055e0269755580e0fcc ]

Drivers are supposed to set correct ecc->{size,strength,bytes} before calling nand_scan_tail(), but it does not complain about ecc->total bigger than oobsize.

In this case, chip->scan_bbt() crashes due to memory corruption, but it is hard to debug. It would be kind to fail it earlier with a clear message.

Signed-off-by Masahiro Yamada <[email protected]>

Signed-off-by Boris Brezillon <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/mtd/nand/nand_base.c |    5 +++++
 1 file changed, 5 insertions(+)

drivers/mtd/nand/nand_base.c +5 -0

@@ -4785,6 +4785,11 @@ int nand_scan_tail(struct mtd_info *mtd)
 		goto err_free;
 	}
 	ecc->total = ecc->steps * ecc->bytes;
+	if (ecc->total > mtd->oobsize) {
+		WARN(1, "Total number of ECC bytes exceeded oobsize\n");
+		ret = -EINVAL;
+		goto err_free;
+	}
 
 	/*
 	 * The number of bytes available for a client to place data into

Greg Kroah-Hartman

author maintainer

2018-04-11 18:35 UTC #173 lore raw

PATCH 171/310 KVM: SVM: do not zero out segment attributes if segment is unusable or not present

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Roman Pen <[email protected]>

[ Upstream commit d9c1b5431d5f0e07575db785a022bce91051ac1d ]

This is a fix for the problem [1], where VMCB.CPL was set to 0 and interrupt was taken on userspace stack. The root cause lies in the specific AMD CPU behaviour which manifests itself as unusable segment attributes on SYSRET. The corresponding work around for the kernel is the following:

61f01dd941ba ("x86_64, asm: Work around AMD SYSRET SS descriptor attribute issue")

In other turn virtualization side treated unusable segment incorrectly and restored CPL from SS attributes, which were zeroed out few lines above.

In current patch it is assured only that P bit is cleared in VMCB.save state and segment attributes are not zeroed out if segment is not presented or is unusable, therefore CPL can be safely restored from DPL field.

This is only one part of the fix, since QEMU side should be fixed accordingly not to zero out attributes on its side. Corresponding patch will follow.

[1] Message id: CAJrWOzD6Xq==b-zYCDdFLgSRMPM-NkNuTSDFEtX=7MreT45i7Q@mail.gmail.com

Signed-off-by Roman Pen <[email protected]>

Signed-off-by Mikhail Sennikovskii <[email protected]>

Cc Paolo Bonzini <[email protected]>

Cc Radim KrÄmÃ¡Å™ <[email protected]>

Signed-off-by Paolo Bonzini <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 arch/x86/kvm/svm.c |   24 +++++++++++-------------
 1 file changed, 11 insertions(+), 13 deletions(-)

arch/x86/kvm/svm.c +11 ~~-13~~

@@ -1879,6 +1879,7 @@ static void svm_get_segment(struct kvm_v
 		 */
 		if (var->unusable)
 			var->db = 0;
+		/* This is symmetric with svm_set_segment() */
 		var->dpl = to_svm(vcpu)->vmcb->save.cpl;
 		break;
 	}

@@ -2024,18 +2025,14 @@ static void svm_set_segment(struct kvm_v
 	s->base = var->base;
 	s->limit = var->limit;
 	s->selector = var->selector;
-	if (var->unusable)
-		s->attrib = 0;
-	else {
-		s->attrib = (var->type & SVM_SELECTOR_TYPE_MASK);
-		s->attrib |= (var->s & 1) << SVM_SELECTOR_S_SHIFT;
-		s->attrib |= (var->dpl & 3) << SVM_SELECTOR_DPL_SHIFT;
-		s->attrib |= (var->present & 1) << SVM_SELECTOR_P_SHIFT;
-		s->attrib |= (var->avl & 1) << SVM_SELECTOR_AVL_SHIFT;
-		s->attrib |= (var->l & 1) << SVM_SELECTOR_L_SHIFT;
-		s->attrib |= (var->db & 1) << SVM_SELECTOR_DB_SHIFT;
-		s->attrib |= (var->g & 1) << SVM_SELECTOR_G_SHIFT;
-	}
+	s->attrib = (var->type & SVM_SELECTOR_TYPE_MASK);
+	s->attrib |= (var->s & 1) << SVM_SELECTOR_S_SHIFT;
+	s->attrib |= (var->dpl & 3) << SVM_SELECTOR_DPL_SHIFT;
+	s->attrib |= ((var->present & 1) && !var->unusable) << SVM_SELECTOR_P_SHIFT;
+	s->attrib |= (var->avl & 1) << SVM_SELECTOR_AVL_SHIFT;
+	s->attrib |= (var->l & 1) << SVM_SELECTOR_L_SHIFT;
+	s->attrib |= (var->db & 1) << SVM_SELECTOR_DB_SHIFT;
+	s->attrib |= (var->g & 1) << SVM_SELECTOR_G_SHIFT;
 
 	/*
 	 * This is always accurate, except if SYSRET returned to a segment

@@ -2044,7 +2041,8 @@ static void svm_set_segment(struct kvm_v
 	 * would entail passing the CPL to userspace and back.
 	 */
 	if (seg == VCPU_SREG_SS)
-		svm->vmcb->save.cpl = (s->attrib >> SVM_SELECTOR_DPL_SHIFT) & 3;
+		/* This is symmetric with svm_get_segment() */
+		svm->vmcb->save.cpl = (var->dpl & 3);
 
 	mark_dirty(svm->vmcb, VMCB_SEG);
 }

Greg Kroah-Hartman

author maintainer

2018-04-11 18:35 UTC #174 lore raw

PATCH 172/310 clk: scpi: fix return type of __scpi_dvfs_round_rate

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Sudeep Holla <[email protected]>

[ Upstream commit 7374aec95636ca39409545eba4ef5ff3125c2346 ]

The frequencies above the maximum value of signed integer(i.e. 2^31 -1) will overflow with the current code.

This patch fixes the return type of __scpi_dvfs_round_rate from 'int' to 'unsigned long'.

Fixes cd52c2a4b5c4 ("clk: add support for clocks provided by SCP(System Control Processor)")

Cc Michael Turquette <[email protected]>

Cc Stephen Boyd <[email protected]>

Signed-off-by Sudeep Holla <[email protected]>

Signed-off-by Stephen Boyd <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/clk/clk-scpi.c |    6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

drivers/clk/clk-scpi.c +3 -3

@@ -71,15 +71,15 @@ static const struct clk_ops scpi_clk_ops
 };
 
 /* find closest match to given frequency in OPP table */
-static int __scpi_dvfs_round_rate(struct scpi_clk *clk, unsigned long rate)
+static long __scpi_dvfs_round_rate(struct scpi_clk *clk, unsigned long rate)
 {
 	int idx;
-	u32 fmin = 0, fmax = ~0, ftmp;
+	unsigned long fmin = 0, fmax = ~0, ftmp;
 	const struct scpi_opp *opp = clk->info->opps;
 
 	for (idx = 0; idx < clk->info->count; idx++, opp++) {
 		ftmp = opp->freq;
-		if (ftmp >= (u32)rate) {
+		if (ftmp >= rate) {
 			if (ftmp <= fmax)
 				fmax = ftmp;
 			break;

Greg Kroah-Hartman

author maintainer

2018-04-11 18:35 UTC #175 lore raw

PATCH 173/310 clk: Fix __set_clk_rates error print-string

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Bryan O'Donoghue <[email protected]>

[ Upstream commit ee177c5d6369f8e5d3e4793dce501cf4431313a1 ]

When failing to set a clock the printout emitted is incorrect. "u32 rate" is formatted as %d and should be %u whereas "unsigned long clk_set_rate()" is formatted as %ld and should be %lu as per Documentation/printk-formats.txt.

Fixes 2885c3b2a3da ("clk: Show correct information when fail to set clock rate")

Signed-off-by Bryan O'Donoghue <[email protected]>

Signed-off-by Stephen Boyd <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/clk/clk-conf.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

drivers/clk/clk-conf.c +1 -1

@@ -106,7 +106,7 @@ static int __set_clk_rates(struct device
 
 			rc = clk_set_rate(clk, rate);
 			if (rc < 0)
-				pr_err("clk: couldn't set %s clk rate to %d (%d), current rate: %ld\n",
+				pr_err("clk: couldn't set %s clk rate to %u (%d), current rate: %lu\n",
 				       __clk_get_name(clk), rate, rc,
 				       clk_get_rate(clk));
 			clk_put(clk);

Greg Kroah-Hartman

author maintainer

2018-04-11 18:35 UTC #176 lore raw

PATCH 174/310 powerpc/spufs: Fix coredump of SPU contexts

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Michael Ellerman <[email protected]>

[ Upstream commit 99acc9bede06bbb2662aafff51f5b9e529fa845e ]

If a process dumps core while it has SPU contexts active then we have code to also dump information about the SPU contexts.

Unfortunately it's been broken for 3 1/2 years, and we didn't notice. In commit 7b1f4020d0d1 ("spufs: get rid of dump_emit() wrappers") the nread variable was removed and rc used instead. That means when the loop exits successfully, rc has the number of bytes read, but it's then used as the return value for the function, which should return 0 on success.

So fix it by setting rc = 0 before returning in the success case.

Fixes 7b1f4020d0d1 ("spufs: get rid of dump_emit() wrappers")

Acked-by Jeremy Kerr <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 arch/powerpc/platforms/cell/spufs/coredump.c |    2 ++
 1 file changed, 2 insertions(+)

arch/powerpc/platforms/cell/spufs/coredump.c +2 -0

@@ -175,6 +175,8 @@ static int spufs_arch_write_note(struct
 	skip = roundup(cprm->pos - total + sz, 4) - cprm->pos;
 	if (!dump_skip(cprm, skip))
 		goto Eio;
+
+	rc = 0;
 out:
 	free_page((unsigned long)buf);
 	return rc;

Greg Kroah-Hartman

author maintainer

2018-04-11 18:35 UTC #177 lore raw

PATCH 175/310 drm/amdkfd: NULL dereference involving create_process()

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Dan Carpenter <[email protected]>

[ Upstream commit b312b2b25b6ac9e2eb03f4ca651b33108752de3a ]

We accidentally return ERR_PTR(0) which is NULL. The caller is not expecting that and it leads to an Oops.

Fixes dd59239a9862 ("amdkfd: init aperture once per process")

Reviewed-by Felix Kuehling <[email protected]>

Signed-off-by Oded Gabbay <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/gpu/drm/amd/amdkfd/kfd_process.c |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

drivers/gpu/drm/amd/amdkfd/kfd_process.c +2 -1

@@ -317,7 +317,8 @@ static struct kfd_process *create_proces
 
 	/* init process apertures*/
 	process->is_32bit_user_mode = in_compat_syscall();
-	if (kfd_init_apertures(process) != 0)
+	err = kfd_init_apertures(process);
+	if (err != 0)
 		goto err_init_apretures;
 
 	return process;

Greg Kroah-Hartman

author maintainer

2018-04-11 18:35 UTC #178 lore raw

PATCH 176/310 ath10k: add BMI parameters to fix calibration from DT/pre-cal

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Anilkumar Kolli <[email protected]>

[ Upstream commit a9f5f287fa1d47d61dfa8b60f94831174b2ea4d0 ]

QCA99X0, QCA9888, QCA9984 supports calibration data in either OTP or DT/pre-cal file. Current ath10k supports Calibration data from OTP only.

If caldata is loaded from DT/pre-cal file, fetching board id and applying calibration parameters like tx power gets failed.

error log:

[   15.733663] ath10k_pci 0000:01:00.0: failed to fetch board file: -2
[   15.741474] ath10k_pci 0000:01:00.0: could not probe fw (-2)

This patch adds calibration data support from DT/pre-cal file. Below parameters are used to get board id and applying calibration parameters from cal data.

EEPROM[OTP] FLASH[DT/pre-cal file]
Cal param 0x700 0x10000
Board id 0x10 0x8000

Tested on QCA9888 with pre-cal file.

Signed-off-by Anilkumar Kolli <[email protected]>

Signed-off-by Kalle Valo <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/net/wireless/ath/ath10k/bmi.h  |    2 ++
 drivers/net/wireless/ath/ath10k/core.c |   16 +++++++++++++---
 2 files changed, 15 insertions(+), 3 deletions(-)

drivers/net/wireless/ath/ath10k/bmi.h +2 -0

@@ -83,6 +83,8 @@ enum bmi_cmd_id {
 #define BMI_NVRAM_SEG_NAME_SZ 16
 
 #define BMI_PARAM_GET_EEPROM_BOARD_ID 0x10
+#define BMI_PARAM_GET_FLASH_BOARD_ID 0x8000
+#define BMI_PARAM_FLASH_SECTION_ALL 0x10000
 
 #define ATH10K_BMI_BOARD_ID_FROM_OTP_MASK   0x7c00
 #define ATH10K_BMI_BOARD_ID_FROM_OTP_LSB    10

drivers/net/wireless/ath/ath10k/core.c +13 -3

@@ -652,7 +652,7 @@ static int ath10k_core_get_board_id_from
 {
 	u32 result, address;
 	u8 board_id, chip_id;
-	int ret;
+	int ret, bmi_board_id_param;
 
 	address = ar->hw_params.patch_load_addr;

@@ -676,8 +676,13 @@ static int ath10k_core_get_board_id_from
 		return ret;
 	}
 
-	ret = ath10k_bmi_execute(ar, address, BMI_PARAM_GET_EEPROM_BOARD_ID,
-				 &result);
+	if (ar->cal_mode == ATH10K_PRE_CAL_MODE_DT ||
+	    ar->cal_mode == ATH10K_PRE_CAL_MODE_FILE)
+		bmi_board_id_param = BMI_PARAM_GET_FLASH_BOARD_ID;
+	else
+		bmi_board_id_param = BMI_PARAM_GET_EEPROM_BOARD_ID;
+
+	ret = ath10k_bmi_execute(ar, address, bmi_board_id_param, &result);
 	if (ret) {
 		ath10k_err(ar, "could not execute otp for board id check: %d\n",
 			   ret);

@@ -739,6 +744,11 @@ static int ath10k_download_and_run_otp(s
 		return ret;
 	}
 
+	/* As of now pre-cal is valid for 10_4 variants */
+	if (ar->cal_mode == ATH10K_PRE_CAL_MODE_DT ||
+	    ar->cal_mode == ATH10K_PRE_CAL_MODE_FILE)
+		bmi_otp_exe_param = BMI_PARAM_FLASH_SECTION_ALL;
+
 	ret = ath10k_bmi_execute(ar, address, bmi_otp_exe_param, &result);
 	if (ret) {
 		ath10k_err(ar, "could not execute otp (%d)\n", ret);

Greg Kroah-Hartman

author maintainer

2018-04-11 18:35 UTC #179 lore raw

PATCH 177/310 perf trace: Add mmap alias for s390

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Jiri Olsa <[email protected]>

[ Upstream commit 54265664c15a68905d8d67d19205e9a767636434 ]

The s390 architecture maps sys_mmap (nr 90) into sys_old_mmap. For this reason perf trace can't find the proper syscall event to get args format from and displays it wrongly as 'continued'.

To fix that fill the "alias" field with "old_mmap" for trace's mmap record to get the correct translation.

Before:

     0.042 ( 0.011 ms): vest/43052 fstat(statbuf: 0x3ffff89fd90                ) = 0
     0.042 ( 0.028 ms): vest/43052  ... [continued]: mmap()) = 0x3fffd6e2000
     0.072 ( 0.025 ms): vest/43052 read(buf: 0x3fffd6e2000, count: 4096        ) = 6

After:

     0.045 ( 0.011 ms): fstat(statbuf: 0x3ffff8a0930                           ) = 0
     0.057 ( 0.018 ms): mmap(arg: 0x3ffff8a0858                                ) = 0x3fffd14a000
     0.076 ( 0.025 ms): read(buf: 0x3fffd14a000, count: 4096                   ) = 6

Signed-off-by Jiri Olsa <[email protected]>

Cc David Ahern <[email protected]>

Cc Namhyung Kim <[email protected]>

Cc Peter Zijlstra <[email protected]>

Link http://lkml.kernel.org/r/[email protected] open here

Signed-off-by Arnaldo Carvalho de Melo <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 tools/perf/builtin-trace.c |    4 ++++
 1 file changed, 4 insertions(+)

tools/perf/builtin-trace.c +4 -0

@@ -679,6 +679,10 @@ static struct syscall_fmt {
 	{ .name	    = "mlockall",   .errmsg = true,
 	  .arg_scnprintf = { [0] = SCA_HEX, /* addr */ }, },
 	{ .name	    = "mmap",	    .hexret = true,
+/* The standard mmap maps to old_mmap on s390x */
+#if defined(__s390x__)
+	.alias = "old_mmap",
+#endif
 	  .arg_scnprintf = { [0] = SCA_HEX,	  /* addr */
 			     [2] = SCA_MMAP_PROT, /* prot */
 			     [3] = SCA_MMAP_FLAGS, /* flags */ }, },

Greg Kroah-Hartman

author maintainer

2018-04-11 18:35 UTC #180 lore raw

PATCH 178/310 qlcnic: Fix a sleep-in-atomic bug in qlcnic_82xx_hw_write_wx_2M and qlcnic_82xx_hw_read_wx_2M

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Jia-Ju Bai <[email protected]>

[ Upstream commit 5ea6d691aac6c93b790f0905e3460d44cc4c449b ]

The driver may sleep under a write spin lock, and the function call path is:
qlcnic_82xx_hw_write_wx_2M (acquire the lock by write_lock_irqsave)
crb_win_lock
qlcnic_pcie_sem_lock
usleep_range
qlcnic_82xx_hw_read_wx_2M (acquire the lock by write_lock_irqsave)
crb_win_lock
qlcnic_pcie_sem_lock
usleep_range

To fix it, the usleep_range is replaced with udelay.

Signed-off-by Jia-Ju Bai <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/net/ethernet/qlogic/qlcnic/qlcnic_hw.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

drivers/net/ethernet/qlogic/qlcnic/qlcnic_hw.c +1 -1

@@ -341,7 +341,7 @@ qlcnic_pcie_sem_lock(struct qlcnic_adapt
 			}
 			return -EIO;
 		}
-		usleep_range(1000, 1500);
+		udelay(1200);
 	}
 
 	if (id_reg)

Greg Kroah-Hartman

author maintainer

2018-04-11 18:35 UTC #181 lore raw

PATCH 179/310 arm64: kernel: restrict /dev/mem read() calls to linear region

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Ard Biesheuvel <[email protected]>

[ Upstream commit 1151f838cb626005f4d69bf675dacaaa5ea909d6 ]

When running lscpu on an AArch64 system that has SMBIOS version 2.0 tables, it will segfault in the following way:

  Unable to handle kernel paging request at virtual address ffff8000bfff0000
  pgd = ffff8000f9615000
  [ffff8000bfff0000] *pgd=0000000000000000
  Internal error: Oops: 96000007 [#1] PREEMPT SMP
  Modules linked in:
  CPU: 0 PID: 1284 Comm: lscpu Not tainted 4.11.0-rc3+ #103
  Hardware name: QEMU QEMU Virtual Machine, BIOS 0.0.0 02/06/2015
  task: ffff8000fa78e800 task.stack: ffff8000f9780000
  PC is at __arch_copy_to_user+0x90/0x220
  LR is at read_mem+0xcc/0x140

This is caused by the fact that lspci issues a read() on /dev/mem at the offset where it expects to find the SMBIOS structure array. However, this region is classified as EFI_RUNTIME_SERVICE_DATA (as per the UEFI spec), and so it is omitted from the linear mapping.

So let's restrict /dev/mem read/write access to those areas that are covered by the linear region.

Reported-by Alexander Graf <[email protected]>

Fixes 4dffbfc48d65 ("arm64/efi: mark UEFI reserved regions as MEMBLOCK_NOMAP")

Signed-off-by Ard Biesheuvel <[email protected]>

Signed-off-by Will Deacon <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 arch/arm64/mm/mmap.c |   19 +++++++++++++------
 1 file changed, 13 insertions(+), 6 deletions(-)

arch/arm64/mm/mmap.c +13 -6

@@ -18,6 +18,7 @@
 
 #include <linux/elf.h>
 #include <linux/fs.h>
+#include <linux/memblock.h>
 #include <linux/mm.h>
 #include <linux/mman.h>
 #include <linux/export.h>

@@ -102,12 +103,18 @@ void arch_pick_mmap_layout(struct mm_str
  */
 int valid_phys_addr_range(phys_addr_t addr, size_t size)
 {
-	if (addr < PHYS_OFFSET)
-		return 0;
-	if (addr + size > __pa(high_memory - 1) + 1)
-		return 0;
-
-	return 1;
+	/*
+	 * Check whether addr is covered by a memory region without the
+	 * MEMBLOCK_NOMAP attribute, and whether that region covers the
+	 * entire range. In theory, this could lead to false negatives
+	 * if the range is covered by distinct but adjacent memory regions
+	 * that only differ in other attributes. However, few of such
+	 * attributes have been defined, and it is debatable whether it
+	 * follows that /dev/mem read() calls should be able traverse
+	 * such boundaries.
+	 */
+	return memblock_is_region_memory(addr, size) &&
+	       memblock_is_map_memory(addr);
 }
 
 /*

Greg Kroah-Hartman

author maintainer

2018-04-11 18:35 UTC #182 lore raw

PATCH 180/310 mISDN: Fix a sleep-in-atomic bug

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Jia-Ju Bai <[email protected]>

[ Upstream commit 93818da5eed63fbc17b64080406ea53b86b23309 ]

The driver may sleep under a read spin lock, and the function call path is:
send_socklist (acquire the lock by read_lock)
skb_copy(GFP_KERNEL) --> may sleep

To fix it, the "GFP_KERNEL" is replaced with "GFP_ATOMIC".

Signed-off-by Jia-Ju Bai <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/isdn/mISDN/stack.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

drivers/isdn/mISDN/stack.c +1 -1

@@ -72,7 +72,7 @@ send_socklist(struct mISDN_sock_list *sl
 		if (sk->sk_state != MISDN_BOUND)
 			continue;
 		if (!cskb)
-			cskb = skb_copy(skb, GFP_KERNEL);
+			cskb = skb_copy(skb, GFP_ATOMIC);
 		if (!cskb) {
 			printk(KERN_WARNING "%s no skb\n", __func__);
 			break;

Greg Kroah-Hartman

author maintainer

2018-04-11 18:35 UTC #183 lore raw

PATCH 181/310 net: phy: micrel: Restore led_mode and clk_sel on resume

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Leonard Crestez <[email protected]>

[ Upstream commit 79e498a9c7da0737829ff864aae44df434105676 ]

These bits seem to be lost after a suspend/resume cycle so just set them again. Do this by splitting the handling of these bits into a function that is also called on resume.

This patch fixes ethernet suspend/resume on imx6ul-14x14-evk boards.

Signed-off-by Leonard Crestez <[email protected]>

Reviewed-by Florian Fainelli <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/net/phy/micrel.c |   42 ++++++++++++++++++++++++++++--------------
 1 file changed, 28 insertions(+), 14 deletions(-)

drivers/net/phy/micrel.c +28 ~~-14~~

@@ -268,23 +268,12 @@ out:
 	return ret;
 }
 
-static int kszphy_config_init(struct phy_device *phydev)
+/* Some config bits need to be set again on resume, handle them here. */
+static int kszphy_config_reset(struct phy_device *phydev)
 {
 	struct kszphy_priv *priv = phydev->priv;
-	const struct kszphy_type *type;
 	int ret;
 
-	if (!priv)
-		return 0;
-
-	type = priv->type;
-
-	if (type->has_broadcast_disable)
-		kszphy_broadcast_disable(phydev);
-
-	if (type->has_nand_tree_disable)
-		kszphy_nand_tree_disable(phydev);
-
 	if (priv->rmii_ref_clk_sel) {
 		ret = kszphy_rmii_clk_sel(phydev, priv->rmii_ref_clk_sel_val);
 		if (ret) {

@@ -295,7 +284,7 @@ static int kszphy_config_init(struct phy
 	}
 
 	if (priv->led_mode >= 0)
-		kszphy_setup_led(phydev, type->led_mode_reg, priv->led_mode);
+		kszphy_setup_led(phydev, priv->type->led_mode_reg, priv->led_mode);
 
 	if (phy_interrupt_is_valid(phydev)) {
 		int ctl = phy_read(phydev, MII_BMCR);

@@ -311,6 +300,25 @@ static int kszphy_config_init(struct phy
 	return 0;
 }
 
+static int kszphy_config_init(struct phy_device *phydev)
+{
+	struct kszphy_priv *priv = phydev->priv;
+	const struct kszphy_type *type;
+
+	if (!priv)
+		return 0;
+
+	type = priv->type;
+
+	if (type->has_broadcast_disable)
+		kszphy_broadcast_disable(phydev);
+
+	if (type->has_nand_tree_disable)
+		kszphy_nand_tree_disable(phydev);
+
+	return kszphy_config_reset(phydev);
+}
+
 static int ksz8041_config_init(struct phy_device *phydev)
 {
 	struct device_node *of_node = phydev->mdio.dev.of_node;

@@ -715,8 +723,14 @@ static int kszphy_suspend(struct phy_dev
 
 static int kszphy_resume(struct phy_device *phydev)
 {
+	int ret;
+
 	genphy_resume(phydev);
 
+	ret = kszphy_config_reset(phydev);
+	if (ret)
+		return ret;
+
 	/* Enable PHY Interrupts */
 	if (phy_interrupt_is_valid(phydev)) {
 		phydev->interrupts = PHY_INTERRUPT_ENABLED;

Greg Kroah-Hartman

author maintainer

2018-04-11 18:35 UTC #191 lore raw

PATCH 182/310 RDMA/iw_cxgb4: Avoid touch after free error in ARP failure handlers

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Raju Rangoju <[email protected]>

[ Upstream commit 1dad0ebeea1cd890b8892523f736916e245b0aef ]

The patch 761e19a504af (RDMA/iw_cxgb4: Handle return value of c4iw_ofld_send() in abort_arp_failure()) from May 6, 2016 leads to the following static checker warning:
drivers/infiniband/hw/cxgb4/cm.c:575 abort_arp_failure()
warn: passing freed memory 'skb'

Also fixes skb leak when l2t resolution fails

Fixes 761e19a504afa55 (RDMA/iw_cxgb4: Handle return value of

c4iw_ofld_send() in abort_arp_failure())

Reported-by Dan Carpenter <[email protected]>

Cc Dan Carpenter <[email protected]>

Signed-off-by Raju Rangoju <[email protected]>

Reviewed-by Steve Wise <[email protected]>

Signed-off-by Doug Ledford <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/infiniband/hw/cxgb4/cm.c |    6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

drivers/infiniband/hw/cxgb4/cm.c +5 -1

@@ -488,6 +488,7 @@ static int _put_ep_safe(struct c4iw_dev
 
 	ep = *((struct c4iw_ep **)(skb->cb + 2 * sizeof(void *)));
 	release_ep_resources(ep);
+	kfree_skb(skb);
 	return 0;
 }

@@ -498,6 +499,7 @@ static int _put_pass_ep_safe(struct c4iw
 	ep = *((struct c4iw_ep **)(skb->cb + 2 * sizeof(void *)));
 	c4iw_put_ep(&ep->parent_ep->com);
 	release_ep_resources(ep);
+	kfree_skb(skb);
 	return 0;
 }

@@ -569,11 +571,13 @@ static void abort_arp_failure(void *hand
 
 	PDBG("%s rdev %p\n", __func__, rdev);
 	req->cmd = CPL_ABORT_NO_RST;
+	skb_get(skb);
 	ret = c4iw_ofld_send(rdev, skb);
 	if (ret) {
 		__state_set(&ep->com, DEAD);
 		queue_arp_failure_cpl(ep, skb, FAKE_CPL_PUT_EP_SAFE);
-	}
+	} else
+		kfree_skb(skb);
 }
 
 static int send_flowc(struct c4iw_ep *ep)

Greg Kroah-Hartman

author maintainer

2018-04-11 18:35 UTC #192 lore raw

PATCH 183/310 RDMA/hfi1: fix array termination by appending NULL to attr array

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: "Steven L. Roberts" <[email protected]>

[ Upstream commit c4dd4b69f55abcc8dd079f8de55d9d8c2ddbefce ]

This fixes a kernel panic when loading the hfi driver as a dynamic module.

Signed-off-by Steven L Roberts <[email protected]>

Reviewed-by Leon Romanovsky <[email protected]>

Acked-by Dennis Dalessandro <[email protected]>

Signed-off-by Doug Ledford <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/infiniband/hw/hfi1/sysfs.c |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

drivers/infiniband/hw/hfi1/sysfs.c +2 -1

@@ -196,7 +196,8 @@ static const struct sysfs_ops port_cc_sy
 };
 
 static struct attribute *port_cc_default_attributes[] = {
-	&cc_prescan_attr.attr
+	&cc_prescan_attr.attr,
+	NULL
 };
 
 static struct kobj_type port_cc_ktype = {

Greg Kroah-Hartman

author maintainer

2018-04-11 18:35 UTC #193 lore raw

PATCH 184/310 drm/omap: fix tiled buffer stride calculations

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Tomi Valkeinen <[email protected]>

[ Upstream commit cc8dd7661ccc2d8dc88921da8e6cc7c2fcdb0341 ]

omap_gem uses page alignment for buffer stride. The related calculations are a bit off, though, as byte stride of 4096 gets aligned to 8192, instead of 4096.

This patch changes the code to use DIV_ROUND_UP(), which fixes those calculations and makes them more readable.

Signed-off-by Tomi Valkeinen <[email protected]>

Reviewed-by Laurent Pinchart <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/gpu/drm/omapdrm/omap_gem.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

drivers/gpu/drm/omapdrm/omap_gem.c +2 -2

@@ -195,7 +195,7 @@ static void evict_entry(struct drm_gem_o
 	size_t size = PAGE_SIZE * n;
 	loff_t off = mmap_offset(obj) +
 			(entry->obj_pgoff << PAGE_SHIFT);
-	const int m = 1 + ((omap_obj->width << fmt) / PAGE_SIZE);
+	const int m = DIV_ROUND_UP(omap_obj->width << fmt, PAGE_SIZE);
 
 	if (m > 1) {
 		int i;

@@ -442,7 +442,7 @@ static int fault_2d(struct drm_gem_objec
 	 * into account in some of the math, so figure out virtual stride
 	 * in pages
 	 */
-	const int m = 1 + ((omap_obj->width << fmt) / PAGE_SIZE);
+	const int m = DIV_ROUND_UP(omap_obj->width << fmt, PAGE_SIZE);
 
 	/* We don't use vmf->pgoff since that has the fake offset: */
 	pgoff = ((unsigned long)vmf->virtual_address -

Greg Kroah-Hartman

author maintainer

2018-04-11 18:35 UTC #194 lore raw

PATCH 185/310 powerpc/8xx: fix mpc8xx_get_irq() return on no irq

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Christophe Leroy <[email protected]>

[ Upstream commit 3c29b6038828c1f4c9ecbfec14d4fc5e25f1c947 ]

IRQ 0 is a valid HW interrupt. So get_irq() shall return 0 when there is no irq, instead of returning irq_linear_revmap(... ,0)

Fixes f2a0bd3753dad ("[POWERPC] 8xx: powerpc port of core CPM PIC")

Signed-off-by Christophe Leroy <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 arch/powerpc/sysdev/mpc8xx_pic.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

arch/powerpc/sysdev/mpc8xx_pic.c +1 -1

@@ -79,7 +79,7 @@ unsigned int mpc8xx_get_irq(void)
 	irq = in_be32(&siu_reg->sc_sivec) >> 26;
 
 	if (irq == PIC_VEC_SPURRIOUS)
-		irq = 0;
+		return 0;
 
         return irq_linear_revmap(mpc8xx_pic_host, irq);

Greg Kroah-Hartman

author maintainer

2018-04-11 18:35 UTC #195 lore raw

PATCH 186/310 cxgb4: fix incorrect cim_la output for T6

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Ganesh Goudar <[email protected]>

[ Upstream commit a97051f4553551d13e586ab3cb6ae13093a44a81 ]

take care of UpDbgLaRdPtr[0-3] restriction for T6.

Signed-off-by Ganesh Goudar <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/net/ethernet/chelsio/cxgb4/t4_hw.c |   11 ++++++++++-
 1 file changed, 10 insertions(+), 1 deletion(-)

drivers/net/ethernet/chelsio/cxgb4/t4_hw.c +10 -1

@@ -8088,7 +8088,16 @@ int t4_cim_read_la(struct adapter *adap,
 		ret = t4_cim_read(adap, UP_UP_DBG_LA_DATA_A, 1, &la_buf[i]);
 		if (ret)
 			break;
-		idx = (idx + 1) & UPDBGLARDPTR_M;
+
+		/* Bits 0-3 of UpDbgLaRdPtr can be between 0000 to 1001 to
+		 * identify the 32-bit portion of the full 312-bit data
+		 */
+		if (is_t6(adap->params.chip) && (idx & 0xf) >= 9)
+			idx = (idx & 0xff0) + 0x10;
+		else
+			idx++;
+		/* address can't exceed 0xfff */
+		idx &= UPDBGLARDPTR_M;
 	}
 restart:
 	if (cfg & UPDBGLAEN_F) {

Greg Kroah-Hartman

author maintainer

2018-04-11 18:35 UTC #196 lore raw

PATCH 187/310 Fix serial console on SNI RM400 machines

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Thomas Bogendoerfer <[email protected]>

[ Upstream commit e279e6d98e0cf2c2fe008b3c29042b92f0e17b1d ]

sccnxp driver doesn't get the correct uart clock rate, if CONFIG_HAVE_CLOCK is disabled. Correct usage of clk API to make it work with/without it.

Fixes 90efa75f7ab0 (serial: sccnxp: Using CLK API for getting UART clock)

Signed-off-by Thomas Bogendoerfer <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/tty/serial/sccnxp.c |   15 ++++++++++-----
 1 file changed, 10 insertions(+), 5 deletions(-)

drivers/tty/serial/sccnxp.c +10 -5

@@ -884,14 +884,19 @@ static int sccnxp_probe(struct platform_
 
 	clk = devm_clk_get(&pdev->dev, NULL);
 	if (IS_ERR(clk)) {
-		if (PTR_ERR(clk) == -EPROBE_DEFER) {
-			ret = -EPROBE_DEFER;
+		ret = PTR_ERR(clk);
+		if (ret == -EPROBE_DEFER)
 			goto err_out;
-		}
+		uartclk = 0;
+	} else {
+		clk_prepare_enable(clk);
+		uartclk = clk_get_rate(clk);
+	}
+
+	if (!uartclk) {
 		dev_notice(&pdev->dev, "Using default clock frequency\n");
 		uartclk = s->chip->freq_std;
-	} else
-		uartclk = clk_get_rate(clk);
+	}
 
 	/* Check input frequency */
 	if ((uartclk < s->chip->freq_min) || (uartclk > s->chip->freq_max)) {

Greg Kroah-Hartman

author maintainer

2018-04-11 18:35 UTC #197 lore raw

PATCH 188/310 bio-integrity: Do not allocate integrity context for bio w/o data

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Dmitry Monakhov <[email protected]>

[ Upstream commit 3116a23bb30272d74ea81baf5d0ee23f602dd15b ]

If bio has no data, such as ones from blkdev_issue_flush(), then we have nothing to protect.

This patch prevent bugon like follows:

kfree_debugcheck: out of range ptr ac1fa1d106742a5ah kernel BUG at mm/slab.c:2773!
invalid opcode: 0000 [#1] SMP

Modules linked in: bcache
CPU: 0 PID: 4428 Comm: xfs_io Tainted: G        W       4.11.0-rc4-ext4-00041-g2ef0043-dirty #43
Hardware name: Virtuozzo KVM, BIOS seabios-1.7.5-11.vz7.4 04/01/2014
task: ffff880137786440 task.stack: ffffc90000ba8000
RIP: 0010:kfree_debugcheck+0x25/0x2a
RSP: 0018:ffffc90000babde0 EFLAGS: 00010082
RAX: 0000000000000034 RBX: ac1fa1d106742a5a RCX: 0000000000000007
RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff88013f3ccb40
RBP: ffffc90000babde8 R08: 0000000000000000 R09: 0000000000000000
R10: 00000000fcb76420 R11: 00000000725172ed R12: 0000000000000282
R13: ffffffff8150e766 R14: ffff88013a145e00 R15: 0000000000000001
FS:  00007fb09384bf40(0000) GS:ffff88013f200000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007fd0172f9e40 CR3: 0000000137fa9000 CR4: 00000000000006f0
Call Trace:
 kfree+0xc8/0x1b3
 bio_integrity_free+0xc3/0x16b
 bio_free+0x25/0x66
 bio_put+0x14/0x26
 blkdev_issue_flush+0x7a/0x85
 blkdev_fsync+0x35/0x42
 vfs_fsync_range+0x8e/0x9f
 vfs_fsync+0x1c/0x1e
 do_fsync+0x31/0x4a
 SyS_fsync+0x10/0x14
 entry_SYSCALL_64_fastpath+0x1f/0xc2

Reviewed-by Christoph Hellwig <[email protected]>

Reviewed-by Hannes Reinecke <[email protected]>

Reviewed-by Martin K. Petersen <[email protected]>

Signed-off-by Dmitry Monakhov <[email protected]>

Signed-off-by Jens Axboe <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 block/bio-integrity.c |    3 +++
 1 file changed, 3 insertions(+)

block/bio-integrity.c +3 -0

@@ -175,6 +175,9 @@ bool bio_integrity_enabled(struct bio *b
 	if (!bio_is_rw(bio))
 		return false;
 
+	if (!bio_sectors(bio))
+		return false;
+
 	/* Already protected? */
 	if (bio_integrity(bio))
 		return false;

Greg Kroah-Hartman

author maintainer

2018-04-11 18:35 UTC #198 lore raw

PATCH 189/310 ip6_tunnel: fix traffic class routing for tunnels

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Liam McBirnie <[email protected]>

[ Upstream commit 5f733ee68f9a4df94775299ac6a7ab260704f6ed ]

ip6_route_output() requires that the flowlabel contains the traffic class for policy routing.

Commit 0e9a709560db ("ip6_tunnel, ip6_gre: fix setting of DSCP on encapsulated packets") removed the code which previously added the traffic class to the flowlabel.

The traffic class is added here because only route lookup needs the flowlabel to contain the traffic class.

Fixes 0e9a709560db ("ip6_tunnel, ip6_gre: fix setting of DSCP on encapsulated packets")

Signed-off-by Liam McBirnie <[email protected]>

Acked-by Peter Dawson <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 net/ipv6/ip6_tunnel.c |    3 +++
 1 file changed, 3 insertions(+)

net/ipv6/ip6_tunnel.c +3 -0

@@ -1097,6 +1097,9 @@ int ip6_tnl_xmit(struct sk_buff *skb, st
 
 	if (!dst) {
 route_lookup:
+		/* add dsfield to flowlabel for route lookup */
+		fl6->flowlabel = ip6_make_flowinfo(dsfield, fl6->flowlabel);
+
 		dst = ip6_route_output(net, NULL, fl6);
 
 		if (dst->error)

Greg Kroah-Hartman

author maintainer

2018-04-11 18:35 UTC #199 lore raw

PATCH 190/310 skbuff: return -EMSGSIZE in skb_to_sgvec to prevent overflow

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: "Jason A. Donenfeld" <[email protected]>

[ Upstream commit 48a1df65334b74bd7531f932cca5928932abf769 ]

This is a defense-in-depth measure in response to bugs like 4d6fa57b4dab ("macsec: avoid heap overflow in skb_to_sgvec"). There's not only a potential overflow of sglist items, but also a stack overflow potential, so we fix this by limiting the amount of recursion this function is allowed to do. Not actually providing a bounded base case is a future disaster that we can easily avoid here.

As a small matter of house keeping, we take this opportunity to move the documentation comment over the actual function the documentation is for.

While this could be implemented by using an explicit stack of skbuffs, when implementing this, the function complexity increased considerably, and I don't think such complexity and bloat is actually worth it. So, instead I built this and tested it on x86, x86_64, ARM, ARM64, and MIPS, and measured the stack usage there. I also reverted the recent MIPS changes that give it a separate IRQ stack, so that I could experience some worst-case situations. I found that limiting it to 24 layers deep yielded a good stack usage with room for safety, as well as being much deeper than any driver actually ever creates.

Signed-off-by Jason A. Donenfeld <[email protected]>

Cc Steffen Klassert <[email protected]>

Cc Herbert Xu <[email protected]>

Cc "David S. Miller" <[email protected]>

Cc David Howells <[email protected]>

Cc Sabrina Dubroca <[email protected]>

Cc "Michael S. Tsirkin" <[email protected]>

Cc Jason Wang <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 include/linux/skbuff.h |    8 +++---
 net/core/skbuff.c      |   65 +++++++++++++++++++++++++++++++------------------
 2 files changed, 46 insertions(+), 27 deletions(-)

include/linux/skbuff.h +4 -4

@@ -984,10 +984,10 @@ struct sk_buff *skb_realloc_headroom(str
 				     unsigned int headroom);
 struct sk_buff *skb_copy_expand(const struct sk_buff *skb, int newheadroom,
 				int newtailroom, gfp_t priority);
-int skb_to_sgvec_nomark(struct sk_buff *skb, struct scatterlist *sg,
-			int offset, int len);
-int skb_to_sgvec(struct sk_buff *skb, struct scatterlist *sg, int offset,
-		 int len);
+int __must_check skb_to_sgvec_nomark(struct sk_buff *skb, struct scatterlist *sg,
+				     int offset, int len);
+int __must_check skb_to_sgvec(struct sk_buff *skb, struct scatterlist *sg,
+			      int offset, int len);
 int skb_cow_data(struct sk_buff *skb, int tailbits, struct sk_buff **trailer);
 int skb_pad(struct sk_buff *skb, int pad);
 #define dev_kfree_skb(a)	consume_skb(a)

net/core/skbuff.c +42 ~~-23~~

113 lines not on this page · raw message

Greg Kroah-Hartman

author maintainer

2018-04-11 18:35 UTC #200 lore raw

PATCH 191/310 macsec: check return value of skb_to_sgvec always

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: "Jason A. Donenfeld" <[email protected]>

[ Upstream commit cda7ea6903502af34015000e16be290a79f07638 ]

Signed-off-by Jason A. Donenfeld <[email protected]>

Cc Sabrina Dubroca <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/net/macsec.c |   13 +++++++++++--
 1 file changed, 11 insertions(+), 2 deletions(-)

drivers/net/macsec.c +11 -2

@@ -742,7 +742,12 @@ static struct sk_buff *macsec_encrypt(st
 	macsec_fill_iv(iv, secy->sci, pn);
 
 	sg_init_table(sg, ret);
-	skb_to_sgvec(skb, sg, 0, skb->len);
+	ret = skb_to_sgvec(skb, sg, 0, skb->len);
+	if (unlikely(ret < 0)) {
+		macsec_txsa_put(tx_sa);
+		kfree_skb(skb);
+		return ERR_PTR(ret);
+	}
 
 	if (tx_sc->encrypt) {
 		int len = skb->len - macsec_hdr_len(sci_present) -

@@ -949,7 +954,11 @@ static struct sk_buff *macsec_decrypt(st
 	macsec_fill_iv(iv, sci, ntohl(hdr->packet_number));
 
 	sg_init_table(sg, ret);
-	skb_to_sgvec(skb, sg, 0, skb->len);
+	ret = skb_to_sgvec(skb, sg, 0, skb->len);
+	if (unlikely(ret < 0)) {
+		kfree_skb(skb);
+		return ERR_PTR(ret);
+	}
 
 	if (hdr->tci_an & MACSEC_TCI_E) {
 		/* confidentiality: ethernet + macsec header

Greg Kroah-Hartman

author maintainer

2018-04-11 18:35 UTC #201 lore raw

PATCH 192/310 sit: reload iphdr in ipip6_rcv

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Haishuang Yan <[email protected]>

[ Upstream commit b699d0035836f6712917a41e7ae58d84359b8ff9 ]

Since iptunnel_pull_header() can call pskb_may_pull(), we must reload any pointer that was related to skb->head.

Fixes a09a4c8dd1ec ("tunnels: Remove encapsulation offloads on decap")

Signed-off-by Haishuang Yan <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 net/ipv6/sit.c |    1 +
 1 file changed, 1 insertion(+)

net/ipv6/sit.c +1 -0

@@ -657,6 +657,7 @@ static int ipip6_rcv(struct sk_buff *skb
 		if (iptunnel_pull_header(skb, 0, htons(ETH_P_IPV6),
 		    !net_eq(tunnel->net, dev_net(tunnel->dev))))
 			goto out;
+		iph = ip_hdr(skb);
 
 		err = IP_ECN_decapsulate(iph, skb);
 		if (unlikely(err)) {

Greg Kroah-Hartman

author maintainer

2018-04-11 18:35 UTC #202 lore raw

PATCH 193/310 net/mlx4: Fix the check in attaching steering rules

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Talat Batheesh <[email protected]>

[ Upstream commit 6dc06c08bef1c746ff8da33dab677cfbacdcad32 ]

Our previous patch (cited below) introduced a regression for RAW Eth QPs.

Fix it by checking if the QP number provided by user-space exists, hence allowing steering rules to be added for valid QPs only.

Fixes 89c557687a32 ("net/mlx4_en: Avoid adding steering rules with invalid ring")

Reported-by Or Gerlitz <[email protected]>

Signed-off-by Talat Batheesh <[email protected]>

Signed-off-by Tariq Toukan <[email protected]>

Acked-by Or Gerlitz <[email protected]>

Reviewed-by Leon Romanovsky <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/net/ethernet/mellanox/mlx4/en_ethtool.c |    5 -----
 drivers/net/ethernet/mellanox/mlx4/mcg.c        |   15 +++++++++++----
 drivers/net/ethernet/mellanox/mlx4/qp.c         |   13 +++++++++++++
 include/linux/mlx4/qp.h                         |    1 +
 4 files changed, 25 insertions(+), 9 deletions(-)

drivers/net/ethernet/mellanox/mlx4/en_ethtool.c +0 -5

@@ -1520,11 +1520,6 @@ static int mlx4_en_flow_replace(struct n
 		qpn = priv->drop_qp.qpn;
 	else if (cmd->fs.ring_cookie & EN_ETHTOOL_QP_ATTACH) {
 		qpn = cmd->fs.ring_cookie & (EN_ETHTOOL_QP_ATTACH - 1);
-		if (qpn < priv->rss_map.base_qpn ||
-		    qpn >= priv->rss_map.base_qpn + priv->rx_ring_num) {
-			en_warn(priv, "rxnfc: QP (0x%x) doesn't exist\n", qpn);
-			return -EINVAL;
-		}
 	} else {
 		if (cmd->fs.ring_cookie >= priv->rx_ring_num) {
 			en_warn(priv, "rxnfc: RX ring (%llu) doesn't exist\n",

drivers/net/ethernet/mellanox/mlx4/mcg.c +11 -4

@@ -35,6 +35,7 @@
 #include <linux/etherdevice.h>
 
 #include <linux/mlx4/cmd.h>
+#include <linux/mlx4/qp.h>
 #include <linux/export.h>
 
 #include "mlx4.h"

@@ -985,16 +986,21 @@ int mlx4_flow_attach(struct mlx4_dev *de
 	if (IS_ERR(mailbox))
 		return PTR_ERR(mailbox);
 
+	if (!mlx4_qp_lookup(dev, rule->qpn)) {
+		mlx4_err_rule(dev, "QP doesn't exist\n", rule);
+		ret = -EINVAL;
+		goto out;
+	}
+
 	trans_rule_ctrl_to_hw(rule, mailbox->buf);
 
 	size += sizeof(struct mlx4_net_trans_rule_hw_ctrl);
 
 	list_for_each_entry(cur, &rule->list, list) {
 		ret = parse_trans_rule(dev, cur, mailbox->buf + size);
-		if (ret < 0) {
-			mlx4_free_cmd_mailbox(dev, mailbox);
-			return ret;
-		}
+		if (ret < 0)
+			goto out;
+
 		size += ret;
 	}

@@ -1021,6 +1027,7 @@ int mlx4_flow_attach(struct mlx4_dev *de
 		}
 	}
 
+out:
 	mlx4_free_cmd_mailbox(dev, mailbox);
 
 	return ret;

drivers/net/ethernet/mellanox/mlx4/qp.c +13 -0

@@ -387,6 +387,19 @@ static void mlx4_qp_free_icm(struct mlx4
 		__mlx4_qp_free_icm(dev, qpn);
 }
 
+struct mlx4_qp *mlx4_qp_lookup(struct mlx4_dev *dev, u32 qpn)
+{
+	struct mlx4_qp_table *qp_table = &mlx4_priv(dev)->qp_table;
+	struct mlx4_qp *qp;
+
+	spin_lock(&qp_table->lock);
+
+	qp = __mlx4_qp_lookup(dev, qpn);
+
+	spin_unlock(&qp_table->lock);
+	return qp;
+}
+
 int mlx4_qp_alloc(struct mlx4_dev *dev, int qpn, struct mlx4_qp *qp, gfp_t gfp)
 {
 	struct mlx4_priv *priv = mlx4_priv(dev);

include/linux/mlx4/qp.h +1 -0

@@ -470,6 +470,7 @@ struct mlx4_update_qp_params {
 	u16	rate_val;
 };
 
+struct mlx4_qp *mlx4_qp_lookup(struct mlx4_dev *dev, u32 qpn);
 int mlx4_update_qp(struct mlx4_dev *dev, u32 qpn,
 		   enum mlx4_update_qp_attr attr,
 		   struct mlx4_update_qp_params *params);

Greg Kroah-Hartman

author maintainer

2018-04-11 18:35 UTC #203 lore raw

PATCH 194/310 net/mlx4: Check if Granular QoS per VF has been enabled before updating QP qos_vport

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Ido Shamay <[email protected]>

[ Upstream commit 269f9883fe254d109afdfc657875c456d6fabb08 ]

The Granular QoS per VF feature must be enabled in FW before it can be used.

Thus, the driver cannot modify a QP's qos_vport value (via the UPDATE_QP FW command) if the feature has not been enabled -- the FW returns an error if this is attempted.

Fixes 08068cd5683f ("net/mlx4: Added qos_vport QP configuration in VST mode")

Signed-off-by Ido Shamay <[email protected]>

Signed-off-by Jack Morgenstein <[email protected]>

Signed-off-by Tariq Toukan <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/net/ethernet/mellanox/mlx4/qp.c               |    6 ++++++
 drivers/net/ethernet/mellanox/mlx4/resource_tracker.c |   16 +++++++++++-----
 2 files changed, 17 insertions(+), 5 deletions(-)

drivers/net/ethernet/mellanox/mlx4/qp.c +6 -0

@@ -487,6 +487,12 @@ int mlx4_update_qp(struct mlx4_dev *dev,
 	}
 
 	if (attr & MLX4_UPDATE_QP_QOS_VPORT) {
+		if (!(dev->caps.flags2 & MLX4_DEV_CAP_FLAG2_QOS_VPP)) {
+			mlx4_warn(dev, "Granular QoS per VF is not enabled\n");
+			err = -EOPNOTSUPP;
+			goto out;
+		}
+
 		qp_mask |= 1ULL << MLX4_UPD_QP_MASK_QOS_VPP;
 		cmd->qp_context.qos_vport = params->qos_vport;
 	}

drivers/net/ethernet/mellanox/mlx4/resource_tracker.c +11 -5

@@ -5214,6 +5214,13 @@ void mlx4_delete_all_resources_for_slave
 	mutex_unlock(&priv->mfunc.master.res_tracker.slave_list[slave].mutex);
 }
 
+static void update_qos_vpp(struct mlx4_update_qp_context *ctx,
+			   struct mlx4_vf_immed_vlan_work *work)
+{
+	ctx->qp_mask |= cpu_to_be64(1ULL << MLX4_UPD_QP_MASK_QOS_VPP);
+	ctx->qp_context.qos_vport = work->qos_vport;
+}
+
 void mlx4_vf_immed_vlan_work_handler(struct work_struct *_work)
 {
 	struct mlx4_vf_immed_vlan_work *work =

@@ -5328,11 +5335,10 @@ void mlx4_vf_immed_vlan_work_handler(str
 					qp->sched_queue & 0xC7;
 				upd_context->qp_context.pri_path.sched_queue |=
 					((work->qos & 0x7) << 3);
-				upd_context->qp_mask |=
-					cpu_to_be64(1ULL <<
-						    MLX4_UPD_QP_MASK_QOS_VPP);
-				upd_context->qp_context.qos_vport =
-					work->qos_vport;
+
+				if (dev->caps.flags2 &
+				    MLX4_DEV_CAP_FLAG2_QOS_VPP)
+					update_qos_vpp(upd_context, work);
 			}
 
 			err = mlx4_cmd(dev, mailbox->dma,

Greg Kroah-Hartman

author maintainer

2018-04-11 18:35 UTC #205 lore raw

PATCH 196/310 perf report: Ensure the perf DSO mapping matches what libdw sees

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Milian Wolff <[email protected]>

[ Upstream commit 2538b9e2450ae255337c04356e9e0f8cb9ec48d9 ]

In some situations the libdw unwinder stopped working properly. I.e. with libunwind we see:

~~~~~
heaptrack_gui 2228 135073.400112: 641314 cycles:

	            e8ed _dl_fixup (/usr/lib/ld-2.25.so)
	           15f06 _dl_runtime_resolve_sse_vex (/usr/lib/ld-2.25.so)
	           ed94c KDynamicJobTracker::KDynamicJobTracker (/home/milian/projects/compiled/kf5/lib64/libKF5KIOWidgets.so.5.35.0)
	           608f3 _GLOBAL__sub_I_kdynamicjobtracker.cpp (/home/milian/projects/compiled/kf5/lib64/libKF5KIOWidgets.so.5.35.0)
	            f199 call_init.part.0 (/usr/lib/ld-2.25.so)
	            f2a5 _dl_init (/usr/lib/ld-2.25.so)
	             db9 _dl_start_user (/usr/lib/ld-2.25.so)

~~~~~

But with libdw and without this patch this sample is not properly unwound:

~~~~~
heaptrack_gui 2228 135073.400112: 641314 cycles:

	            e8ed _dl_fixup (/usr/lib/ld-2.25.so)
	           15f06 _dl_runtime_resolve_sse_vex (/usr/lib/ld-2.25.so)
	           ed94c KDynamicJobTracker::KDynamicJobTracker (/home/milian/projects/compiled/kf5/lib64/libKF5KIOWidgets.so.5.35.0)

~~~~~

Debug output showed me that libdw found a module for the last frame address, but it thinks it belongs to /usr/lib/ld-2.25.so. This patch double-checks what libdw sees and what perf knows. If the mappings mismatch, we now report the elf known to perf. This fixes the situation above, and the libdw unwinder produces the same stack as libunwind.

Signed-off-by Milian Wolff <[email protected]>

Cc Jiri Olsa <[email protected]>

Cc Namhyung Kim <[email protected]>

Link http://lkml.kernel.org/r/[email protected] open here

Signed-off-by Arnaldo Carvalho de Melo <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 tools/perf/util/unwind-libdw.c |    8 ++++++++
 1 file changed, 8 insertions(+)

tools/perf/util/unwind-libdw.c +8 -0

@@ -38,6 +38,14 @@ static int __report_module(struct addr_l
 		return 0;
 
 	mod = dwfl_addrmodule(ui->dwfl, ip);
+	if (mod) {
+		Dwarf_Addr s;
+
+		dwfl_module_info(mod, NULL, &s, NULL, NULL, NULL, NULL, NULL);
+		if (s != al->map->start)
+			mod = 0;
+	}
+
 	if (!mod)
 		mod = dwfl_report_elf(ui->dwfl, dso->short_name,
 				      dso->long_name, -1, al->map->start,

Greg Kroah-Hartman

author maintainer

2018-04-11 18:35 UTC #206 lore raw

PATCH 197/310 iwlwifi: mvm: fix firmware debug restart recording

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Emmanuel Grumbach <[email protected]>

[ Upstream commit addce854f164a68da9cb158e2e7e447705068549 ]

When we want to stop the recording of the firmware debug and restart it later without reloading the firmware we don't need to resend the configuration that comes with host commands.
Sending those commands confused the hardware and led to an NMI 0x66.

Change the flow as following:
* read the relevant registers (DBGC_IN_SAMPLE, DBGC_OUT_CTRL)
* clear those registers
* wait for the hardware to complete its write to the buffer
* get the data
* restore the value of those registers (to restart the recording)

For early start (where the configuration is already compiled in the firmware), we don't need to set those registers after the firmware has been loaded, but only when we want to restart the recording without having restarted the firmware.

Signed-off-by Emmanuel Grumbach <[email protected]>

Signed-off-by Luca Coelho <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/net/wireless/intel/iwlwifi/iwl-prph.h   |    1 
 drivers/net/wireless/intel/iwlwifi/mvm/fw-dbg.c |   12 ---------
 drivers/net/wireless/intel/iwlwifi/mvm/mvm.h    |    1 
 drivers/net/wireless/intel/iwlwifi/mvm/ops.c    |   32 ++++++++++++++++++------
 4 files changed, 27 insertions(+), 19 deletions(-)

drivers/net/wireless/intel/iwlwifi/iwl-prph.h +1 -0

@@ -369,6 +369,7 @@
 #define MON_DMARB_RD_DATA_ADDR		(0xa03c5c)
 
 #define DBGC_IN_SAMPLE			(0xa03c00)
+#define DBGC_OUT_CTRL			(0xa03c0c)
 
 /* enable the ID buf for read */
 #define WFPM_PS_CTL_CLR			0xA0300C

drivers/net/wireless/intel/iwlwifi/mvm/fw-dbg.c +1 ~~-11~~

@@ -914,14 +914,6 @@ int iwl_mvm_fw_dbg_collect_trig(struct i
 	return 0;
 }
 
-static inline void iwl_mvm_restart_early_start(struct iwl_mvm *mvm)
-{
-	if (mvm->cfg->device_family == IWL_DEVICE_FAMILY_7000)
-		iwl_clear_bits_prph(mvm->trans, MON_BUFF_SAMPLE_CTL, 0x100);
-	else
-		iwl_write_prph(mvm->trans, DBGC_IN_SAMPLE, 1);
-}
-
 int iwl_mvm_start_fw_dbg_conf(struct iwl_mvm *mvm, u8 conf_id)
 {
 	u8 *ptr;

@@ -935,10 +927,8 @@ int iwl_mvm_start_fw_dbg_conf(struct iwl
 	/* EARLY START - firmware's configuration is hard coded */
 	if ((!mvm->fw->dbg_conf_tlv[conf_id] ||
 	     !mvm->fw->dbg_conf_tlv[conf_id]->num_of_hcmds) &&
-	    conf_id == FW_DBG_START_FROM_ALIVE) {
-		iwl_mvm_restart_early_start(mvm);
+	    conf_id == FW_DBG_START_FROM_ALIVE)
 		return 0;
-	}
 
 	if (!mvm->fw->dbg_conf_tlv[conf_id])
 		return -EINVAL;

drivers/net/wireless/intel/iwlwifi/mvm/mvm.h +1 -0

@@ -1687,6 +1687,7 @@ void iwl_mvm_enable_ac_txq(struct iwl_mv
 static inline void iwl_mvm_stop_device(struct iwl_mvm *mvm)
 {
 	mvm->ucode_loaded = false;
+	mvm->fw_dbg_conf = FW_DBG_INVALID;
 	iwl_trans_stop_device(mvm->trans);
 }

drivers/net/wireless/intel/iwlwifi/mvm/ops.c +24 -8

@@ -1118,21 +1118,37 @@ static void iwl_mvm_fw_error_dump_wk(str
 
 	mutex_lock(&mvm->mutex);
 
-	/* stop recording */
 	if (mvm->cfg->device_family == IWL_DEVICE_FAMILY_7000) {
+		/* stop recording */
 		iwl_set_bits_prph(mvm->trans, MON_BUFF_SAMPLE_CTL, 0x100);
+
+		iwl_mvm_fw_error_dump(mvm);
+
+		/* start recording again if the firmware is not crashed */
+		if (!test_bit(STATUS_FW_ERROR, &mvm->trans->status) &&
+		    mvm->fw->dbg_dest_tlv)
+			iwl_clear_bits_prph(mvm->trans,
+					    MON_BUFF_SAMPLE_CTL, 0x100);
 	} else {
+		u32 in_sample = iwl_read_prph(mvm->trans, DBGC_IN_SAMPLE);
+		u32 out_ctrl = iwl_read_prph(mvm->trans, DBGC_OUT_CTRL);
+
+		/* stop recording */
 		iwl_write_prph(mvm->trans, DBGC_IN_SAMPLE, 0);
-		/* wait before we collect the data till the DBGC stop */
 		udelay(100);
-	}
+		iwl_write_prph(mvm->trans, DBGC_OUT_CTRL, 0);
+		/* wait before we collect the data till the DBGC stop */
+		udelay(500);
 
-	iwl_mvm_fw_error_dump(mvm);
+		iwl_mvm_fw_error_dump(mvm);
 
-	/* start recording again if the firmware is not crashed */
-	WARN_ON_ONCE((!test_bit(STATUS_FW_ERROR, &mvm->trans->status)) &&
-		     mvm->fw->dbg_dest_tlv &&
-		     iwl_mvm_start_fw_dbg_conf(mvm, mvm->fw_dbg_conf));
+		/* start recording again if the firmware is not crashed */
+		if (!test_bit(STATUS_FW_ERROR, &mvm->trans->status) &&
+		    mvm->fw->dbg_dest_tlv) {
+			iwl_write_prph(mvm->trans, DBGC_IN_SAMPLE, in_sample);
+			iwl_write_prph(mvm->trans, DBGC_OUT_CTRL, out_ctrl);
+		}
+	}
 
 	mutex_unlock(&mvm->mutex);

Greg Kroah-Hartman

author maintainer

2018-04-11 18:35 UTC #207 lore raw

PATCH 198/310 watchdog: f71808e_wdt: Add F71868 support

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: "Maciej S. Szmigiero" <[email protected]>

[ Upstream commit 166fbcf88fdafa02f784ec25ac64745c716b2de0 ]

This adds support for watchdog part of Fintek F71868 Super I/O chip to f71808e_wdt driver.

The F71868 chip is, in general, very similar to a F71869, however it has slightly different set of available reset pulse widths.

Tested on MSI A55M-P33 motherboard.

Signed-off-by Maciej S. Szmigiero <[email protected]>

Reviewed-by Guenter Roeck <[email protected]>

Signed-off-by Guenter Roeck <[email protected]>

Signed-off-by Wim Van Sebroeck <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/watchdog/Kconfig       |    7 ++++---
 drivers/watchdog/f71808e_wdt.c |   27 ++++++++++++++++++++-------
 2 files changed, 24 insertions(+), 10 deletions(-)

drivers/watchdog/Kconfig +4 -3

@@ -799,11 +799,12 @@ config EBC_C384_WDT
 	  the timeout module parameter.
 
 config F71808E_WDT
-	tristate "Fintek F71808E, F71862FG, F71869, F71882FG and F71889FG Watchdog"
+	tristate "Fintek F718xx, F818xx Super I/O Watchdog"
 	depends on X86
 	help
-	  This is the driver for the hardware watchdog on the Fintek
-	  F71808E, F71862FG, F71869, F71882FG and F71889FG Super I/O controllers.
+	  This is the driver for the hardware watchdog on the Fintek F71808E,
+	  F71862FG, F71868, F71869, F71882FG, F71889FG, F81865 and F81866
+	  Super I/O controllers.
 
 	  You can compile this driver directly into the kernel, or use
 	  it as a module.  The module will be called f71808e_wdt.

drivers/watchdog/f71808e_wdt.c +20 -7

@@ -57,6 +57,7 @@
 #define SIO_F71808_ID		0x0901	/* Chipset ID */
 #define SIO_F71858_ID		0x0507	/* Chipset ID */
 #define SIO_F71862_ID		0x0601	/* Chipset ID */
+#define SIO_F71868_ID		0x1106	/* Chipset ID */
 #define SIO_F71869_ID		0x0814	/* Chipset ID */
 #define SIO_F71869A_ID		0x1007	/* Chipset ID */
 #define SIO_F71882_ID		0x0541	/* Chipset ID */

@@ -101,7 +102,7 @@ MODULE_PARM_DESC(timeout,
 static unsigned int pulse_width = WATCHDOG_PULSE_WIDTH;
 module_param(pulse_width, uint, 0);
 MODULE_PARM_DESC(pulse_width,
-	"Watchdog signal pulse width. 0(=level), 1 ms, 25 ms, 125 ms or 5000 ms"
+	"Watchdog signal pulse width. 0(=level), 1, 25, 30, 125, 150, 5000 or 6000 ms"
 			" (default=" __MODULE_STRING(WATCHDOG_PULSE_WIDTH) ")");
 
 static unsigned int f71862fg_pin = WATCHDOG_F71862FG_PIN;

@@ -119,13 +120,14 @@ module_param(start_withtimeout, uint, 0)
 MODULE_PARM_DESC(start_withtimeout, "Start watchdog timer on module load with"
 	" given initial timeout. Zero (default) disables this feature.");
 
-enum chips { f71808fg, f71858fg, f71862fg, f71869, f71882fg, f71889fg, f81865,
-	     f81866};
+enum chips { f71808fg, f71858fg, f71862fg, f71868, f71869, f71882fg, f71889fg,
+	     f81865, f81866};
 
 static const char *f71808e_names[] = {
 	"f71808fg",
 	"f71858fg",
 	"f71862fg",
+	"f71868",
 	"f71869",
 	"f71882fg",
 	"f71889fg",

@@ -252,16 +254,23 @@ static int watchdog_set_timeout(int time
 static int watchdog_set_pulse_width(unsigned int pw)
 {
 	int err = 0;
+	unsigned int t1 = 25, t2 = 125, t3 = 5000;
+
+	if (watchdog.type == f71868) {
+		t1 = 30;
+		t2 = 150;
+		t3 = 6000;
+	}
 
 	mutex_lock(&watchdog.lock);
 
-	if        (pw <=    1) {
+	if        (pw <=  1) {
 		watchdog.pulse_val = 0;
-	} else if (pw <=   25) {
+	} else if (pw <= t1) {
 		watchdog.pulse_val = 1;
-	} else if (pw <=  125) {
+	} else if (pw <= t2) {
 		watchdog.pulse_val = 2;
-	} else if (pw <= 5000) {
+	} else if (pw <= t3) {
 		watchdog.pulse_val = 3;
 	} else {
 		pr_err("pulse width out of range\n");

@@ -354,6 +363,7 @@ static int watchdog_start(void)
 			goto exit_superio;
 		break;
 
+	case f71868:
 	case f71869:
 		/* GPIO14 --> WDTRST# */
 		superio_clear_bit(watchdog.sioaddr, SIO_REG_MFUNCT1, 4);

@@ -792,6 +802,9 @@ static int __init f71808e_find(int sioad
 		watchdog.type = f71862fg;
 		err = f71862fg_pin_configure(0); /* validate module parameter */
 		break;
+	case SIO_F71868_ID:
+		watchdog.type = f71868;
+		break;
 	case SIO_F71869_ID:
 	case SIO_F71869A_ID:
 		watchdog.type = f71869;

Greg Kroah-Hartman

author maintainer

2018-04-11 18:35 UTC #208 lore raw

PATCH 199/310 iwlwifi: mvm: Fix command queue number on d0i3 flow

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Haim Dreyfuss <[email protected]>

[ Upstream commit c72c37b7f392ad7edc10b6092fa48c632ba6f4ed ]

During d0i3 flow we flush all the queue except from the command queue. Currently, in this flow the command queue is hard coded to 9. In DQA the command queue number has changed from 9 to 0. Fix that.

This fixes a problem in runtime PM resume flow.

Fixes 097129c9e625 ("iwlwifi: mvm: move cmd queue to be #0 in dqa mode")

Signed-off-by Haim Dreyfuss <[email protected]>

Signed-off-by Luca Coelho <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/net/wireless/intel/iwlwifi/mvm/mvm.h |    5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

drivers/net/wireless/intel/iwlwifi/mvm/mvm.h +4 -1

@@ -1666,8 +1666,11 @@ int iwl_mvm_find_free_queue(struct iwl_m
  */
 static inline u32 iwl_mvm_flushable_queues(struct iwl_mvm *mvm)
 {
+	u32 cmd_queue = iwl_mvm_is_dqa_supported(mvm) ? IWL_MVM_DQA_CMD_QUEUE :
+		IWL_MVM_CMD_QUEUE;
+
 	return ((BIT(mvm->cfg->base_params->num_of_queues) - 1) &
-		~BIT(IWL_MVM_CMD_QUEUE));
+		~BIT(cmd_queue));
 }
 
 static inline

Greg Kroah-Hartman

author maintainer

2018-04-11 18:35 UTC #209 lore raw

PATCH 200/310 iwlwifi: tt: move ucode_loaded check under mutex

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Johannes Berg <[email protected]>

[ Upstream commit d9954405758a0cbbe258d9b4d4dc12a06fa48a28 ]

The ucode_loaded check should be under the mutex, since it can otherwise change state after we looked at it and before we got the mutex. Fix that.

Fixes 5c89e7bc557e ("iwlwifi: mvm: add registration to cooling device")

Signed-off-by Johannes Berg <[email protected]>

Signed-off-by Luca Coelho <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/net/wireless/intel/iwlwifi/mvm/tt.c |    8 +++++---
 1 file changed, 5 insertions(+), 3 deletions(-)

drivers/net/wireless/intel/iwlwifi/mvm/tt.c +5 -3

@@ -790,11 +790,13 @@ static int iwl_mvm_tcool_set_cur_state(s
 	struct iwl_mvm *mvm = (struct iwl_mvm *)(cdev->devdata);
 	int ret;
 
-	if (!mvm->ucode_loaded || !(mvm->cur_ucode == IWL_UCODE_REGULAR))
-		return -EIO;
-
 	mutex_lock(&mvm->mutex);
 
+	if (!mvm->ucode_loaded || !(mvm->cur_ucode == IWL_UCODE_REGULAR)) {
+		ret = -EIO;
+		goto unlock;
+	}
+
 	if (new_state >= ARRAY_SIZE(iwl_mvm_cdev_budgets)) {
 		ret = -EINVAL;
 		goto unlock;

Greg Kroah-Hartman

author maintainer

2018-04-11 18:35 UTC #210 lore raw

PATCH 201/310 iwlwifi: pcie: only use d0i3 in suspend/resume if system_pm is set to d0i3

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Luca Coelho <[email protected]>

[ Upstream commit e4c49c4937951de1cdbe35572ade40c948dec1e1 ]

We only need to handle d0i3 entry and exit during suspend resume if system_pm is set to IWL_PLAT_PM_MODE_D0I3, otherwise d0i3 entry failures will cause suspend to fail.

This fixes https://bugzilla.kernel.org/show_bug.cgi?id=194791

Signed-off-by Luca Coelho <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/net/wireless/intel/iwlwifi/pcie/trans.c |    6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

drivers/net/wireless/intel/iwlwifi/pcie/trans.c +4 -2

@@ -2824,7 +2824,8 @@ static struct iwl_trans_dump_data
 #ifdef CONFIG_PM_SLEEP
 static int iwl_trans_pcie_suspend(struct iwl_trans *trans)
 {
-	if (trans->runtime_pm_mode == IWL_PLAT_PM_MODE_D0I3)
+	if (trans->runtime_pm_mode == IWL_PLAT_PM_MODE_D0I3 &&
+	    (trans->system_pm_mode == IWL_PLAT_PM_MODE_D0I3))
 		return iwl_pci_fw_enter_d0i3(trans);
 
 	return 0;

@@ -2832,7 +2833,8 @@ static int iwl_trans_pcie_suspend(struct
 
 static void iwl_trans_pcie_resume(struct iwl_trans *trans)
 {
-	if (trans->runtime_pm_mode == IWL_PLAT_PM_MODE_D0I3)
+	if (trans->runtime_pm_mode == IWL_PLAT_PM_MODE_D0I3 &&
+	    (trans->system_pm_mode == IWL_PLAT_PM_MODE_D0I3))
 		iwl_pci_fw_exit_d0i3(trans);
 }
 #endif /* CONFIG_PM_SLEEP */

Greg Kroah-Hartman

author maintainer

2018-04-11 18:35 UTC #211 lore raw

PATCH 202/310 iwlwifi: fix min API version for 7265D, 3168, 8000 and 8265

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Luca Coelho <[email protected]>

[ Upstream commit 15098803d38778070b8edfa5a3d5fc4fef10d0a1 ]

In a previous commit, we removed support for API versions earlier than 22 for these NICs. By mistake, the *_UCODE_API_MIN definitions were set to 17. Fix that.

Fixes 4b87e5af638b ("iwlwifi: remove support for fw older than -17 and -22")

Signed-off-by Luca Coelho <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/net/wireless/intel/iwlwifi/iwl-7000.c |    4 ++--
 drivers/net/wireless/intel/iwlwifi/iwl-8000.c |    4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)

drivers/net/wireless/intel/iwlwifi/iwl-7000.c +2 -2

@@ -79,8 +79,8 @@
 /* Lowest firmware API version supported */
 #define IWL7260_UCODE_API_MIN	17
 #define IWL7265_UCODE_API_MIN	17
-#define IWL7265D_UCODE_API_MIN	17
-#define IWL3168_UCODE_API_MIN	20
+#define IWL7265D_UCODE_API_MIN	22
+#define IWL3168_UCODE_API_MIN	22
 
 /* NVM versions */
 #define IWL7260_NVM_VERSION		0x0a1d

drivers/net/wireless/intel/iwlwifi/iwl-8000.c +2 -2

@@ -74,8 +74,8 @@
 #define IWL8265_UCODE_API_MAX	26
 
 /* Lowest firmware API version supported */
-#define IWL8000_UCODE_API_MIN	17
-#define IWL8265_UCODE_API_MIN	20
+#define IWL8000_UCODE_API_MIN	22
+#define IWL8265_UCODE_API_MIN	22
 
 /* NVM versions */
 #define IWL8000_NVM_VERSION		0x0a1d

Greg Kroah-Hartman

author maintainer

2018-04-11 18:35 UTC #212 lore raw

PATCH 203/310 tags: honor COMPILED_SOURCE with apart output directory

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Robert Jarzmik <[email protected]>

[ Upstream commit cbf52a3e6a8a92beec6e0c70abf4111cd8f8faf7 ]

When the kernel is compiled with an "O=" argument, the object files are not in the source tree, but in the build tree.

This patch fixes O= build by looking for object files in the build tree.

Fixes 923e02ecf3f8 ("scripts/tags.sh: Support compiled source")

Signed-off-by Robert Jarzmik <[email protected]>

Signed-off-by Masahiro Yamada <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 scripts/tags.sh |    1 +
 1 file changed, 1 insertion(+)

scripts/tags.sh +1 -0

@@ -106,6 +106,7 @@ all_compiled_sources()
 		case "$i" in
 			*.[cS])
 				j=${i/\.[cS]/\.o}
+				j="${j#$tree}"
 				if [ -e $j ]; then
 					echo $i
 				fi

Greg Kroah-Hartman

author maintainer

2018-04-11 18:35 UTC #213 lore raw

PATCH 204/310 ARM: dts: qcom: ipq4019: fix i2c_0 node

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Christian Lamparter <[email protected]>

[ Upstream commit 650df439cfb96c303328935559b2d06127a5a0b0 ]

This patch fixes two typos in the i2c_0 node for the ipq4019. The reg property length is just 0x600. The core clock is GCC_BLSP1_QUP1_I2C_APPS_CLK. GCC_BLSP1_QUP2_I2C_APPS_CLK is used by the second i2c.

Fixes e76b4284b520ba3 ("qcom: ipq4019: add i2c node to ipq4019 SoC and DK01 device tree")

Signed-off-by Christian Lamparter <[email protected]>

Signed-off-by Andy Gross <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 arch/arm/boot/dts/qcom-ipq4019.dtsi |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

arch/arm/boot/dts/qcom-ipq4019.dtsi +2 -2

@@ -154,10 +154,10 @@
 
 		i2c_0: i2c@78b7000 {
 			compatible = "qcom,i2c-qup-v2.2.1";
-			reg = <0x78b7000 0x6000>;
+			reg = <0x78b7000 0x600>;
 			interrupts = <GIC_SPI 97 IRQ_TYPE_LEVEL_HIGH>;
 			clocks = <&gcc GCC_BLSP1_AHB_CLK>,
-				 <&gcc GCC_BLSP1_QUP2_I2C_APPS_CLK>;
+				 <&gcc GCC_BLSP1_QUP1_I2C_APPS_CLK>;
 			clock-names = "iface", "core";
 			#address-cells = <1>;
 			#size-cells = <0>;

Greg Kroah-Hartman

author maintainer

2018-04-11 18:35 UTC #214 lore raw

PATCH 205/310 e1000e: fix race condition around skb_tstamp_tx()

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Jacob Keller <[email protected]>

[ Upstream commit 5012863b7347866764c4a4e58b62fb05346b0d06 ]

The e1000e driver and related hardware has a limitation on Tx PTP packets which requires we limit to timestamping a single packet at once. We do this by verifying that we never request a new Tx timestamp while we still have a tx_hwtstamp_skb pointer.

Unfortunately the driver suffers from a race condition around this. The tx_hwtstamp_skb pointer is not set to NULL until after skb_tstamp_tx() is called. This function notifies the stack and applications of a new timestamp. Even a well behaved application that only sends a new request when the first one is finished might be woken up and possibly send a packet before we can free the timestamp in the driver again. The result is that we needlessly ignore some Tx timestamp requests in this corner case.

Fix this by assigning the tx_hwtstamp_skb pointer prior to calling skb_tstamp_tx() and use a temporary pointer to hold the timestamped skb until that function finishes. This ensures that the application is not woken up until the driver is ready to begin timestamping a new packet.

This ensures that well behaved applications do not accidentally race with condition to skip Tx timestamps. Obviously an application which sends multiple Tx timestamp requests at once will still only timestamp one packet at a time. Unfortunately there is nothing we can do about this.

Reported-by David Mirabito <[email protected]>

Signed-off-by Jacob Keller <[email protected]>

Tested-by Aaron Brown <[email protected]>

Signed-off-by Jeff Kirsher <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/net/ethernet/intel/e1000e/netdev.c |   10 ++++++++--
 1 file changed, 8 insertions(+), 2 deletions(-)

drivers/net/ethernet/intel/e1000e/netdev.c +8 -2

@@ -1182,6 +1182,7 @@ static void e1000e_tx_hwtstamp_work(stru
 	struct e1000_hw *hw = &adapter->hw;
 
 	if (er32(TSYNCTXCTL) & E1000_TSYNCTXCTL_VALID) {
+		struct sk_buff *skb = adapter->tx_hwtstamp_skb;
 		struct skb_shared_hwtstamps shhwtstamps;
 		u64 txstmp;

@@ -1190,9 +1191,14 @@ static void e1000e_tx_hwtstamp_work(stru
 
 		e1000e_systim_to_hwtstamp(adapter, &shhwtstamps, txstmp);
 
-		skb_tstamp_tx(adapter->tx_hwtstamp_skb, &shhwtstamps);
-		dev_kfree_skb_any(adapter->tx_hwtstamp_skb);
+		/* Clear the global tx_hwtstamp_skb pointer and force writes
+		 * prior to notifying the stack of a Tx timestamp.
+		 */
 		adapter->tx_hwtstamp_skb = NULL;
+		wmb(); /* force write prior to skb_tstamp_tx */
+
+		skb_tstamp_tx(skb, &shhwtstamps);
+		dev_kfree_skb_any(skb);
 	} else if (time_after(jiffies, adapter->tx_hwtstamp_start
 			      + adapter->tx_timeout_factor * HZ)) {
 		dev_kfree_skb_any(adapter->tx_hwtstamp_skb);

Greg Kroah-Hartman

author maintainer

2018-04-11 18:35 UTC #216 lore raw

PATCH 207/310 cxl: Unlock on error in probe

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Dan Carpenter <[email protected]>

[ Upstream commit 58d876fa7181f2f393190c1d32c056b5a9d34aa2 ]

We should unlock if get_cxl_adapter() fails.

Fixes 594ff7d067ca ("cxl: Support to flash a new image on the adapter from a guest")

Acked-by Frederic Barrat <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/misc/cxl/flash.c |    8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)

drivers/misc/cxl/flash.c +6 -2

@@ -401,8 +401,10 @@ static int device_open(struct inode *ino
 	if (down_interruptible(&sem) != 0)
 		return -EPERM;
 
-	if (!(adapter = get_cxl_adapter(adapter_num)))
-		return -ENODEV;
+	if (!(adapter = get_cxl_adapter(adapter_num))) {
+		rc = -ENODEV;
+		goto err_unlock;
+	}
 
 	file->private_data = adapter;
 	continue_token = 0;

@@ -446,6 +448,8 @@ err1:
 		free_page((unsigned long) le);
 err:
 	put_device(&adapter->dev);
+err_unlock:
+	up(&sem);
 
 	return rc;
 }

Greg Kroah-Hartman

author maintainer

2018-04-11 18:35 UTC #217 lore raw

PATCH 208/310 cx25840: fix unchecked return values

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Pan Bian <[email protected]>

[ Upstream commit 35378ce143071c2a6bad4b59a000e9b9f8f6ea67 ]

In functions cx25840_initialize(), cx231xx_initialize(), and cx23885_initialize(), the return value of create_singlethread_workqueue() is used without validation. This may result in NULL dereference and cause kernel crash. This patch fixes it.

Signed-off-by Pan Bian <[email protected]>

Signed-off-by Hans Verkuil <[email protected]>

Signed-off-by Mauro Carvalho Chehab <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/media/i2c/cx25840/cx25840-core.c |   36 ++++++++++++++++++-------------
 1 file changed, 21 insertions(+), 15 deletions(-)

drivers/media/i2c/cx25840/cx25840-core.c +21 ~~-15~~

@@ -420,11 +420,13 @@ static void cx25840_initialize(struct i2
 	INIT_WORK(&state->fw_work, cx25840_work_handler);
 	init_waitqueue_head(&state->fw_wait);
 	q = create_singlethread_workqueue("cx25840_fw");
-	prepare_to_wait(&state->fw_wait, &wait, TASK_UNINTERRUPTIBLE);
-	queue_work(q, &state->fw_work);
-	schedule();
-	finish_wait(&state->fw_wait, &wait);
-	destroy_workqueue(q);
+	if (q) {
+		prepare_to_wait(&state->fw_wait, &wait, TASK_UNINTERRUPTIBLE);
+		queue_work(q, &state->fw_work);
+		schedule();
+		finish_wait(&state->fw_wait, &wait);
+		destroy_workqueue(q);
+	}
 
 	/* 6. */
 	cx25840_write(client, 0x115, 0x8c);

@@ -634,11 +636,13 @@ static void cx23885_initialize(struct i2
 	INIT_WORK(&state->fw_work, cx25840_work_handler);
 	init_waitqueue_head(&state->fw_wait);
 	q = create_singlethread_workqueue("cx25840_fw");
-	prepare_to_wait(&state->fw_wait, &wait, TASK_UNINTERRUPTIBLE);
-	queue_work(q, &state->fw_work);
-	schedule();
-	finish_wait(&state->fw_wait, &wait);
-	destroy_workqueue(q);
+	if (q) {
+		prepare_to_wait(&state->fw_wait, &wait, TASK_UNINTERRUPTIBLE);
+		queue_work(q, &state->fw_work);
+		schedule();
+		finish_wait(&state->fw_wait, &wait);
+		destroy_workqueue(q);
+	}
 
 	/* Call the cx23888 specific std setup func, we no longer rely on
 	 * the generic cx24840 func.

@@ -752,11 +756,13 @@ static void cx231xx_initialize(struct i2
 	INIT_WORK(&state->fw_work, cx25840_work_handler);
 	init_waitqueue_head(&state->fw_wait);
 	q = create_singlethread_workqueue("cx25840_fw");
-	prepare_to_wait(&state->fw_wait, &wait, TASK_UNINTERRUPTIBLE);
-	queue_work(q, &state->fw_work);
-	schedule();
-	finish_wait(&state->fw_wait, &wait);
-	destroy_workqueue(q);
+	if (q) {
+		prepare_to_wait(&state->fw_wait, &wait, TASK_UNINTERRUPTIBLE);
+		queue_work(q, &state->fw_work);
+		schedule();
+		finish_wait(&state->fw_wait, &wait);
+		destroy_workqueue(q);
+	}
 
 	cx25840_std_setup(client);

Greg Kroah-Hartman

author maintainer

2018-04-11 18:35 UTC #218 lore raw

PATCH 209/310 mceusb: sporadic RX truncation corruption fix

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: A Sun <[email protected]>

[ Upstream commit 8e175b22e8640bf3a58e071af54190b909e4a944 ]

Intermittent RX truncation and loss of IR received data. This resulted in receive stream synchronization errors where driver attempted to incorrectly parse IR data (eg 0x90 below) as command response.

[ 3969.139898] mceusb 1-1.2:1.0: processed IR data
[ 3969.151315] mceusb 1-1.2:1.0: rx data: 00 90 (length=2)
[ 3969.151321] mceusb 1-1.2:1.0: Unknown command 0x00 0x90
[ 3969.151336] mceusb 1-1.2:1.0: rx data: 98 0a 8d 0a 8e 0a 8e 0a 8e 0a 8e 0a 9a 0a 8e 0a 0b 3a 8e 00 80 41 59 00 00 (length=25)
[ 3969.151341] mceusb 1-1.2:1.0: Raw IR data, 24 pulse/space samples
[ 3969.151348] mceusb 1-1.2:1.0: Storing space with duration 500000

Bug trigger appears to be normal, but heavy, IR receiver use.

Signed-off-by A Sun <[email protected]>

Signed-off-by Sean Young <[email protected]>

Signed-off-by Mauro Carvalho Chehab <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/media/rc/mceusb.c |    9 +++++++--
 1 file changed, 7 insertions(+), 2 deletions(-)

drivers/media/rc/mceusb.c +7 -2

@@ -1381,8 +1381,13 @@ static int mceusb_dev_probe(struct usb_i
 		goto rc_dev_fail;
 
 	/* wire up inbound data handler */
-	usb_fill_int_urb(ir->urb_in, dev, pipe, ir->buf_in, maxp,
-				mceusb_dev_recv, ir, ep_in->bInterval);
+	if (usb_endpoint_xfer_int(ep_in))
+		usb_fill_int_urb(ir->urb_in, dev, pipe, ir->buf_in, maxp,
+				 mceusb_dev_recv, ir, ep_in->bInterval);
+	else
+		usb_fill_bulk_urb(ir->urb_in, dev, pipe, ir->buf_in, maxp,
+				  mceusb_dev_recv, ir);
+
 	ir->urb_in->transfer_dma = ir->dma_in;
 	ir->urb_in->transfer_flags |= URB_NO_TRANSFER_DMA_MAP;

Greg Kroah-Hartman

author maintainer

2018-04-11 18:35 UTC #219 lore raw

PATCH 210/310 net: phy: avoid genphy_aneg_done() for PHYs without clause 22 support

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Russell King <[email protected]>

[ Upstream commit 41408ad519f7a2a1c5229e61f2a97f4df1b61adc ]

Avoid calling genphy_aneg_done() for PHYs that do not implement the Clause 22 register set.

Clause 45 PHYs may implement the Clause 22 register set along with the Clause 22 extension MMD. Hence, we can't simply block access to the Clause 22 functions based on the PHY being a Clause 45 PHY.

Signed-off-by Russell King <[email protected]>

Reviewed-by Andrew Lunn <[email protected]>

Reviewed-by Florian Fainelli <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/net/phy/phy.c |    6 ++++++
 1 file changed, 6 insertions(+)

drivers/net/phy/phy.c +6 -0

@@ -148,6 +148,12 @@ static inline int phy_aneg_done(struct p
 	if (phydev->drv->aneg_done)
 		return phydev->drv->aneg_done(phydev);
 
+	/* Avoid genphy_aneg_done() if the Clause 45 PHY does not
+	 * implement Clause 22 registers
+	 */
+	if (phydev->is_c45 && !(phydev->c45_ids.devices_in_package & BIT(0)))
+		return -EINVAL;
+
 	return genphy_aneg_done(phydev);
 }

Greg Kroah-Hartman

author maintainer

2018-04-11 18:35 UTC #220 lore raw

PATCH 211/310 ARM: imx: Add MXC_CPU_IMX6ULL and cpu_is_imx6ull

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Leonard Crestez <[email protected]>

[ Upstream commit b3ea575770c7eeb259c77b6861cd14d00eb309df ]

Support for imx6ull is already present but it's based on of_machine_is_compatible("fsl,imx6ull") checks. Add it to the MXC_CPU_* enumeration as well.

This also fixes /sys/devices/soc0/soc_id reading "Unknown".

Signed-off-by Leonard Crestez <[email protected]>

Reviewed-by Fabio Estevam <[email protected]>

Signed-off-by Shawn Guo <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 arch/arm/mach-imx/cpu.c |    3 +++
 arch/arm/mach-imx/mxc.h |    6 ++++++
 2 files changed, 9 insertions(+)

arch/arm/mach-imx/cpu.c +3 -0

@@ -131,6 +131,9 @@ struct device * __init imx_soc_device_in
 	case MXC_CPU_IMX6UL:
 		soc_id = "i.MX6UL";
 		break;
+	case MXC_CPU_IMX6ULL:
+		soc_id = "i.MX6ULL";
+		break;
 	case MXC_CPU_IMX7D:
 		soc_id = "i.MX7D";
 		break;

arch/arm/mach-imx/mxc.h +6 -0

@@ -39,6 +39,7 @@
 #define MXC_CPU_IMX6SX		0x62
 #define MXC_CPU_IMX6Q		0x63
 #define MXC_CPU_IMX6UL		0x64
+#define MXC_CPU_IMX6ULL		0x65
 #define MXC_CPU_IMX7D		0x72
 
 #define IMX_DDR_TYPE_LPDDR2		1

@@ -73,6 +74,11 @@ static inline bool cpu_is_imx6ul(void)
 	return __mxc_cpu_type == MXC_CPU_IMX6UL;
 }
 
+static inline bool cpu_is_imx6ull(void)
+{
+	return __mxc_cpu_type == MXC_CPU_IMX6ULL;
+}
+
 static inline bool cpu_is_imx6q(void)
 {
 	return __mxc_cpu_type == MXC_CPU_IMX6Q;

Greg Kroah-Hartman

author maintainer

2018-04-11 18:35 UTC #221 lore raw

PATCH 212/310 nvme-pci: fix multiple ctrl removal scheduling

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Rakesh Pandit <[email protected]>

[ Upstream commit 82b057caefaff2a891f821a617d939f46e03e844 ]

Commit c5f6ce97c1210 tries to address multiple resets but fails as work_busy doesn't involve any synchronization and can fail. This is reproducible easily as can be seen by WARNING below which is triggered with line:

WARN_ON(dev->ctrl.state == NVME_CTRL_RESETTING)

Allowing multiple resets can result in multiple controller removal as well if different conditions inside nvme_reset_work fail and which might deadlock on device_release_driver.

[  480.327007] WARNING: CPU: 3 PID: 150 at drivers/nvme/host/pci.c:1900 nvme_reset_work+0x36c/0xec0
[  480.327008] Modules linked in: rfcomm fuse nf_conntrack_netbios_ns nf_conntrack_broadcast...
[  480.327044]  btusb videobuf2_core ghash_clmulni_intel snd_hwdep cfg80211 acer_wmi hci_uart..
[  480.327065] CPU: 3 PID: 150 Comm: kworker/u16:2 Not tainted 4.12.0-rc1+ #13
[  480.327065] Hardware name: Acer Predator G9-591/Mustang_SLS, BIOS V1.10 03/03/2016
[  480.327066] Workqueue: nvme nvme_reset_work
[  480.327067] task: ffff880498ad8000 task.stack: ffffc90002218000
[  480.327068] RIP: 0010:nvme_reset_work+0x36c/0xec0
[  480.327069] RSP: 0018:ffffc9000221bdb8 EFLAGS: 00010246
[  480.327070] RAX: 0000000000460000 RBX: ffff880498a98128 RCX: dead000000000200
[  480.327070] RDX: 0000000000000001 RSI: ffff8804b1028020 RDI: ffff880498a98128
[  480.327071] RBP: ffffc9000221be50 R08: 0000000000000000 R09: 0000000000000000
[  480.327071] R10: ffffc90001963ce8 R11: 000000000000020d R12: ffff880498a98000
[  480.327072] R13: ffff880498a53500 R14: ffff880498a98130 R15: ffff880498a98128
[  480.327072] FS:  0000000000000000(0000) GS:ffff8804c1cc0000(0000) knlGS:0000000000000000
[  480.327073] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[  480.327074] CR2: 00007ffcf3c37f78 CR3: 0000000001e09000 CR4: 00000000003406e0
[  480.327074] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[  480.327075] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[  480.327075] Call Trace:
[  480.327079]  ? __switch_to+0x227/0x400
[  480.327081]  process_one_work+0x18c/0x3a0
[  480.327082]  worker_thread+0x4e/0x3b0
[  480.327084]  kthread+0x109/0x140
[  480.327085]  ? process_one_work+0x3a0/0x3a0
[  480.327087]  ? kthread_park+0x60/0x60
[  480.327102]  ret_from_fork+0x2c/0x40
[  480.327103] Code: e8 5a dc ff ff 85 c0 41 89 c1 0f.....

This patch addresses the problem by using state of controller to decide whether reset should be queued or not as state change is synchronizated using controller spinlock. Also cancel_work_sync is used to make sure remove cancels the reset_work and waits for it to finish. This patch also changes return value from -ENODEV to more appropriate -EBUSY if nvme_reset fails to change state.

Fixes c5f6ce97c1210 ("nvme: don't schedule multiple resets")

Signed-off-by Rakesh Pandit <[email protected]>

Reviewed-by Sagi Grimberg <[email protected]>

Signed-off-by Christoph Hellwig <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/nvme/host/pci.c |   13 ++++++-------
 1 file changed, 6 insertions(+), 7 deletions(-)

drivers/nvme/host/pci.c +6 -7

@@ -1263,7 +1263,7 @@ static bool nvme_should_reset(struct nvm
 	bool nssro = dev->subsystem && (csts & NVME_CSTS_NSSRO);
 
 	/* If there is a reset ongoing, we shouldn't reset again. */
-	if (work_busy(&dev->reset_work))
+	if (dev->ctrl.state == NVME_CTRL_RESETTING)
 		return false;
 
 	/* We shouldn't reset unless the controller is on fatal error state

@@ -1755,7 +1755,7 @@ static void nvme_reset_work(struct work_
 	struct nvme_dev *dev = container_of(work, struct nvme_dev, reset_work);
 	int result = -ENODEV;
 
-	if (WARN_ON(dev->ctrl.state == NVME_CTRL_RESETTING))
+	if (WARN_ON(dev->ctrl.state != NVME_CTRL_RESETTING))
 		goto out;
 
 	/*

@@ -1765,9 +1765,6 @@ static void nvme_reset_work(struct work_
 	if (dev->ctrl.ctrl_config & NVME_CC_ENABLE)
 		nvme_dev_disable(dev, false);
 
-	if (!nvme_change_ctrl_state(&dev->ctrl, NVME_CTRL_RESETTING))
-		goto out;
-
 	result = nvme_pci_enable(dev);
 	if (result)
 		goto out;

@@ -1841,8 +1838,8 @@ static int nvme_reset(struct nvme_dev *d
 {
 	if (!dev->ctrl.admin_q || blk_queue_dying(dev->ctrl.admin_q))
 		return -ENODEV;
-	if (work_busy(&dev->reset_work))
-		return -ENODEV;
+	if (!nvme_change_ctrl_state(&dev->ctrl, NVME_CTRL_RESETTING))
+		return -EBUSY;
 	if (!queue_work(nvme_workq, &dev->reset_work))
 		return -EBUSY;
 	return 0;

@@ -1944,6 +1941,7 @@ static int nvme_probe(struct pci_dev *pd
 	if (result)
 		goto release_pools;
 
+	nvme_change_ctrl_state(&dev->ctrl, NVME_CTRL_RESETTING);
 	dev_info(dev->ctrl.device, "pci function %s\n", dev_name(&pdev->dev));
 
 	queue_work(nvme_workq, &dev->reset_work);

@@ -1987,6 +1985,7 @@ static void nvme_remove(struct pci_dev *
 
 	nvme_change_ctrl_state(&dev->ctrl, NVME_CTRL_DELETING);
 
+	cancel_work_sync(&dev->reset_work);
 	pci_set_drvdata(pdev, NULL);
 
 	if (!pci_device_is_present(pdev)) {

Greg Kroah-Hartman

author maintainer

2018-04-11 18:35 UTC #222 lore raw

PATCH 213/310 nvme: fix hang in remove path

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Ming Lei <[email protected]>

[ Upstream commit 82654b6b8ef8b93ee87a97fc562f87f081fc2f91 ]

We need to start admin queues too in nvme_kill_queues() for avoiding hang in remove path[1].

This patch is very similar with 806f026f9b901eaf(nvme: use blk_mq_start_hw_queues() in nvme_kill_queues()).

[1] hang stack trace

[<ffffffff813c9716>] blk_execute_rq+0x56/0x80
[<ffffffff815cb6e9>] __nvme_submit_sync_cmd+0x89/0xf0
[<ffffffff815ce7be>] nvme_set_features+0x5e/0x90
[<ffffffff815ce9f6>] nvme_configure_apst+0x166/0x200
[<ffffffff815cef45>] nvme_set_latency_tolerance+0x35/0x50
[<ffffffff8157bd11>] apply_constraint+0xb1/0xc0
[<ffffffff8157cbb4>] dev_pm_qos_constraints_destroy+0xf4/0x1f0
[<ffffffff8157b44a>] dpm_sysfs_remove+0x2a/0x60
[<ffffffff8156d951>] device_del+0x101/0x320
[<ffffffff8156db8a>] device_unregister+0x1a/0x60
[<ffffffff8156dc4c>] device_destroy+0x3c/0x50
[<ffffffff815cd295>] nvme_uninit_ctrl+0x45/0xa0
[<ffffffff815d4858>] nvme_remove+0x78/0x110
[<ffffffff81452b69>] pci_device_remove+0x39/0xb0
[<ffffffff81572935>] device_release_driver_internal+0x155/0x210
[<ffffffff81572a02>] device_release_driver+0x12/0x20
[<ffffffff815d36fb>] nvme_remove_dead_ctrl_work+0x6b/0x70
[<ffffffff810bf3bc>] process_one_work+0x18c/0x3a0
[<ffffffff810bf61e>] worker_thread+0x4e/0x3b0
[<ffffffff810c5ac9>] kthread+0x109/0x140
[<ffffffff8185800c>] ret_from_fork+0x2c/0x40

[<ffffffffffffffff>] 0xffffffffffffffff

Fixes c5552fde102fc("nvme: Enable autonomous power state transitions")

Reported-by Rakesh Pandit <[email protected]>

Tested-by Rakesh Pandit <[email protected]>

Reviewed-by Sagi Grimberg <[email protected]>

Signed-off-by Ming Lei <[email protected]>

Signed-off-by Christoph Hellwig <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/nvme/host/core.c |    4 ++++
 1 file changed, 4 insertions(+)

drivers/nvme/host/core.c +4 -0

@@ -2040,6 +2040,10 @@ void nvme_kill_queues(struct nvme_ctrl *
 	struct nvme_ns *ns;
 
 	mutex_lock(&ctrl->namespaces_mutex);
+
+	/* Forcibly start all queues to avoid having stuck requests */
+	blk_mq_start_hw_queues(ctrl->admin_q);
+
 	list_for_each_entry(ns, &ctrl->namespaces, list) {
 		/*
 		 * Revalidating a dead namespace sets capacity to 0. This will

Greg Kroah-Hartman

author maintainer

2018-04-11 18:35 UTC #223 lore raw

PATCH 214/310 KVM: nVMX: Update vmcs12->guest_linear_address on nested VM-exit

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Jim Mattson <[email protected]>

[ Upstream commit d281e13b0bfe745a21061a194e386a949784393f ]

The guest-linear address field is set for VM exits due to attempts to execute LMSW with a memory operand and VM exits due to attempts to execute INS or OUTS for which the relevant segment is usable, regardless of whether or not EPT is in use.

Fixes 119a9c01a5922 ("KVM: nVMX: pass valid guest linear-address to the L1")

Signed-off-by Jim Mattson <[email protected]>

Signed-off-by Radim Krčmář <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 arch/x86/kvm/vmx.c |    3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

arch/x86/kvm/vmx.c +1 -2

@@ -10664,8 +10664,7 @@ static void prepare_vmcs12(struct kvm_vc
 		vmcs12->guest_pdptr3 = vmcs_read64(GUEST_PDPTR3);
 	}
 
-	if (nested_cpu_has_ept(vmcs12))
-		vmcs12->guest_linear_address = vmcs_readl(GUEST_LINEAR_ADDRESS);
+	vmcs12->guest_linear_address = vmcs_readl(GUEST_LINEAR_ADDRESS);
 
 	if (nested_cpu_has_vid(vmcs12))
 		vmcs12->guest_intr_status = vmcs_read16(GUEST_INTR_STATUS);

Greg Kroah-Hartman

author maintainer

2018-04-11 18:35 UTC #224 lore raw

PATCH 215/310 e1000e: Undo e1000e_pm_freeze if __e1000_shutdown fails

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Chris Wilson <[email protected]>

[ Upstream commit 833521ebc65b1c3092e5c0d8a97092f98eec595d ]

An error during suspend (e100e_pm_suspend),

[  429.994338] ACPI : EC: event blocked
[  429.994633] e1000e: EEE TX LPI TIMER: 00000011
[  430.955451] pci_pm_suspend(): e1000e_pm_suspend+0x0/0x30 [e1000e] returns -2
[  430.955454] dpm_run_callback(): pci_pm_suspend+0x0/0x140 returns -2
[  430.955458] PM: Device 0000:00:19.0 failed to suspend async: error -2
[  430.955581] PM: Some devices failed to suspend, or early wake event detected
[  430.957709] ACPI : EC: event unblocked

lead to complete failure:

[  432.585002] ------------[ cut here ]------------
[  432.585013] WARNING: CPU: 3 PID: 8372 at kernel/irq/manage.c:1478 __free_irq+0x9f/0x280
[  432.585015] Trying to free already-free IRQ 20
[  432.585016] Modules linked in: cdc_ncm usbnet x86_pkg_temp_thermal intel_powerclamp coretemp mii crct10dif_pclmul crc32_pclmul ghash_clmulni_intel snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic snd_hda_intel snd_hda_codec snd_hwdep lpc_ich snd_hda_core snd_pcm mei_me mei sdhci_pci sdhci i915 mmc_core e1000e ptp pps_core prime_numbers
[  432.585042] CPU: 3 PID: 8372 Comm: kworker/u16:40 Tainted: G     U          4.10.0-rc8-CI-Patchwork_3870+ #1
[  432.585044] Hardware name: LENOVO 2356GCG/2356GCG, BIOS G7ET31WW (1.13 ) 07/02/2012
[  432.585050] Workqueue: events_unbound async_run_entry_fn
[  432.585051] Call Trace:
[  432.585058]  dump_stack+0x67/0x92
[  432.585062]  __warn+0xc6/0xe0
[  432.585065]  warn_slowpath_fmt+0x4a/0x50
[  432.585070]  ? _raw_spin_lock_irqsave+0x49/0x60
[  432.585072]  __free_irq+0x9f/0x280
[  432.585075]  free_irq+0x34/0x80
[  432.585089]  e1000_free_irq+0x65/0x70 [e1000e]
[  432.585098]  e1000e_pm_freeze+0x7a/0xb0 [e1000e]
[  432.585106]  e1000e_pm_suspend+0x21/0x30 [e1000e]
[  432.585113]  pci_pm_suspend+0x71/0x140
[  432.585118]  dpm_run_callback+0x6f/0x330
[  432.585122]  ? pci_pm_freeze+0xe0/0xe0
[  432.585125]  __device_suspend+0xea/0x330
[  432.585128]  async_suspend+0x1a/0x90
[  432.585132]  async_run_entry_fn+0x34/0x160
[  432.585137]  process_one_work+0x1f4/0x6d0
[  432.585140]  ? process_one_work+0x16e/0x6d0
[  432.585143]  worker_thread+0x49/0x4a0
[  432.585145]  kthread+0x107/0x140
[  432.585148]  ? process_one_work+0x6d0/0x6d0
[  432.585150]  ? kthread_create_on_node+0x40/0x40
[  432.585154]  ret_from_fork+0x2e/0x40
[  432.585156] ---[ end trace 6712df7f8c4b9124 ]---

The unwind failures stems from commit 2800209994f8 ("e1000e: Refactor PM flows"), but it may be a later patch that introduced the non-recoverable behaviour.

Fixes 2800209994f8 ("e1000e: Refactor PM flows")

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99847

Signed-off-by Chris Wilson <[email protected]>

Signed-off-by Jani Nikula <[email protected]>

Tested-by Aaron Brown <[email protected]>

Signed-off-by Jeff Kirsher <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/net/ethernet/intel/e1000e/netdev.c |    7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

drivers/net/ethernet/intel/e1000e/netdev.c +6 -1

@@ -6651,12 +6651,17 @@ static int e1000e_pm_thaw(struct device
 static int e1000e_pm_suspend(struct device *dev)
 {
 	struct pci_dev *pdev = to_pci_dev(dev);
+	int rc;
 
 	e1000e_flush_lpic(pdev);
 
 	e1000e_pm_freeze(dev);
 
-	return __e1000_shutdown(pdev, false);
+	rc = __e1000_shutdown(pdev, false);
+	if (rc)
+		e1000e_pm_thaw(dev);
+
+	return rc;
 }
 
 static int e1000e_pm_resume(struct device *dev)

Greg Kroah-Hartman

author maintainer

2018-04-11 18:35 UTC #225 lore raw

PATCH 216/310 perf/core: Correct event creation with PERF_FORMAT_GROUP

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Peter Zijlstra <[email protected]>

[ Upstream commit ba5213ae6b88fb170c4771fef6553f759c7d8cdd ]

Andi was asking about PERF_FORMAT_GROUP vs inherited events, which led to the discovery of a bug from commit:

3dab77fb1bf8 ("perf: Rework/fix the whole read vs group stuff")

 -       PERF_SAMPLE_GROUP                       = 1U << 4,
 +       PERF_SAMPLE_READ                        = 1U << 4,

- if (attr->inherit && (attr->sample_type & PERF_SAMPLE_GROUP))
+ if (attr->inherit && (attr->read_format & PERF_FORMAT_GROUP))

is a clear fail :/

While this changes user visible behaviour; it was previously possible to create an inherited event with PERF_SAMPLE_READ; this is deemed acceptible because its results were always incorrect.

Reported-by Andi Kleen <[email protected]>

Signed-off-by Peter Zijlstra (Intel) <[email protected]>

Cc Alexander Shishkin <[email protected]>

Cc Arnaldo Carvalho de Melo <[email protected]>

Cc Jiri Olsa <[email protected]>

Cc Linus Torvalds <[email protected]>

Cc Peter Zijlstra <[email protected]>

Cc Stephane Eranian <[email protected]>

Cc Thomas Gleixner <[email protected]>

Cc Vince Weaver <[email protected]>

Fixes 3dab77fb1bf8 ("perf: Rework/fix the whole read vs group stuff")

Link http://lkml.kernel.org/r/[email protected] open here

Signed-off-by Ingo Molnar <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 kernel/events/core.c |   15 ++++++++++-----
 1 file changed, 10 insertions(+), 5 deletions(-)

kernel/events/core.c +10 -5

@@ -5669,9 +5669,6 @@ static void perf_output_read_one(struct
 	__output_copy(handle, values, n * sizeof(u64));
 }
 
-/*
- * XXX PERF_FORMAT_GROUP vs inherited events seems difficult.
- */
 static void perf_output_read_group(struct perf_output_handle *handle,
 			    struct perf_event *event,
 			    u64 enabled, u64 running)

@@ -5716,6 +5713,13 @@ static void perf_output_read_group(struc
 #define PERF_FORMAT_TOTAL_TIMES (PERF_FORMAT_TOTAL_TIME_ENABLED|\
 				 PERF_FORMAT_TOTAL_TIME_RUNNING)
 
+/*
+ * XXX PERF_SAMPLE_READ vs inherited events seems difficult.
+ *
+ * The problem is that its both hard and excessively expensive to iterate the
+ * child list, not to mention that its impossible to IPI the children running
+ * on another CPU, from interrupt/NMI context.
+ */
 static void perf_output_read(struct perf_output_handle *handle,
 			     struct perf_event *event)
 {

@@ -9259,9 +9263,10 @@ perf_event_alloc(struct perf_event_attr
 	local64_set(&hwc->period_left, hwc->sample_period);
 
 	/*
-	 * we currently do not support PERF_FORMAT_GROUP on inherited events
+	 * We currently do not support PERF_SAMPLE_READ on inherited events.
+	 * See perf_output_read().
 	 */
-	if (attr->inherit && (attr->read_format & PERF_FORMAT_GROUP))
+	if (attr->inherit && (attr->sample_type & PERF_SAMPLE_READ))
 		goto err_ns;
 
 	if (!has_branch_stack(event))

Greg Kroah-Hartman

author maintainer

2018-04-11 18:35 UTC #226 lore raw

PATCH 217/310 sched/deadline: Use the revised wakeup rule for suspending constrained dl tasks

Link http://lkml.kernel.org/r/5c800ab3a74a168a84ee5f3f84d12a02e11383be.1495803804.git.bristot@redhat.com open here

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Daniel Bristot de Oliveira <[email protected]>

[ Upstream commit 3effcb4247e74a51f5d8b775a1ee4abf87cc089a ]

We have been facing some problems with self-suspending constrained deadline tasks. The main reason is that the original CBS was not designed for such sort of tasks.

One problem reported by Xunlei Pang takes place when a task suspends, and then is awakened before the deadline, but so close to the deadline that its remaining runtime can cause the task to have an absolute density higher than allowed. In such situation, the original CBS assumes that the task is facing an early activation, and so it replenishes the task and set another deadline, one deadline in the future. This rule works fine for implicit deadline tasks. Moreover, it allows the system to adapt the period of a task in which the external event source suffered from a clock drift.

However, this opens the window for bandwidth leakage for constrained deadline tasks. For instance, a task with the following parameters:

runtime = 5 ms
deadline = 7 ms
[density] = 5 / 7 = 0.71
period = 1000 ms

If the task runs for 1 ms, and then suspends for another 1ms, it will be awakened with the following parameters:

remaining runtime = 4
laxity = 5

presenting a absolute density of 4 / 5 = 0.80.

In this case, the original CBS would assume the task had an early wakeup. Then, CBS will reset the runtime, and the absolute deadline will be postponed by one relative deadline, allowing the task to run.

The problem is that, if the task runs this pattern forever, it will keep receiving bandwidth, being able to run 1ms every 2ms. Following this behavior, the task would be able to run 500 ms in 1 sec. Thus running more than the 5 ms / 1 sec the admission control allowed it to run.

Trying to address the self-suspending case, Luca Abeni, Giuseppe Lipari, and Juri Lelli [1] revisited the CBS in order to deal with self-suspending tasks. In the new approach, rather than replenishing/postponing the absolute deadline, the revised wakeup rule adjusts the remaining runtime, reducing it to fit into the allowed density.

A revised version of the idea is:

At a given time t, the maximum absolute density of a task cannot be higher than its relative density, that is:

runtime / (deadline - t) <= dl_runtime / dl_deadline

Knowing the laxity of a task (deadline - t), it is possible to move it to the other side of the equality, thus enabling to define max remaining runtime a task can use within the absolute deadline, without over-running the allowed density:

runtime = (dl_runtime / dl_deadline) * (deadline - t)

For instance, in our previous example, the task could still run:

runtime = ( 5 / 7 ) * 5
runtime = 3.57 ms

Without causing damage for other deadline tasks. It is note worthy that the laxity cannot be negative because that would cause a negative runtime. Thus, this patch depends on the patch:

df8eac8cafce ("sched/deadline: Throttle a constrained deadline task activated after the deadline")

Which throttles a constrained deadline task activated after the deadline.

Finally, it is also possible to use the revised wakeup rule for all other tasks, but that would require some more discussions about pros and cons.

Reported-by Xunlei Pang <[email protected]>

Signed-off-by Daniel Bristot de Oliveira <[email protected]>

[peterz: replaced dl_is_constrained with dl_is_implicit]

Signed-off-by Peter Zijlstra (Intel) <[email protected]>

Cc Juri Lelli <[email protected]>

Cc Linus Torvalds <[email protected]>

Cc Luca Abeni <[email protected]>

Cc Mike Galbraith <[email protected]>

Cc Peter Zijlstra <[email protected]>

Cc Romulo Silva de Oliveira <[email protected]>

Cc Steven Rostedt <[email protected]>

Cc Thomas Gleixner <[email protected]>

Cc Tommaso Cucinotta <[email protected]>

Signed-off-by Ingo Molnar <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 include/linux/sched.h   |    1 
 kernel/sched/core.c     |    2 
 kernel/sched/deadline.c |   98 ++++++++++++++++++++++++++++++++++++++++++------
 3 files changed, 89 insertions(+), 12 deletions(-)

include/linux/sched.h +1 -0

@@ -1412,6 +1412,7 @@ struct sched_dl_entity {
 	u64 dl_deadline;	/* relative deadline of each instance	*/
 	u64 dl_period;		/* separation of two instances (period) */
 	u64 dl_bw;		/* dl_runtime / dl_deadline		*/
+	u64 dl_density;		/* dl_runtime / dl_deadline		*/
 
 	/*
 	 * Actual scheduling parameters. Initialized with the values above,

kernel/sched/core.c +2 -0

@@ -2184,6 +2184,7 @@ void __dl_clear_params(struct task_struc
 	dl_se->dl_period = 0;
 	dl_se->flags = 0;
 	dl_se->dl_bw = 0;
+	dl_se->dl_density = 0;
 
 	dl_se->dl_throttled = 0;
 	dl_se->dl_yielded = 0;

@@ -3912,6 +3913,7 @@ __setparam_dl(struct task_struct *p, con
 	dl_se->dl_period = attr->sched_period ?: dl_se->dl_deadline;
 	dl_se->flags = attr->sched_flags;
 	dl_se->dl_bw = to_ratio(dl_se->dl_period, dl_se->dl_runtime);
+	dl_se->dl_density = to_ratio(dl_se->dl_deadline, dl_se->dl_runtime);
 
 	/*
 	 * Changing the parameters of a task is 'tricky' and we're not doing

kernel/sched/deadline.c +86 ~~-12~~

123 lines not on this page · raw message

Greg Kroah-Hartman

author maintainer

2018-04-11 18:35 UTC #227 lore raw

PATCH 218/310 MIPS: mm: fixed mappings: correct initialisation

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Marcin Nowakowski <[email protected]>

[ Upstream commit 71eb989ab5a110df8bcbb9609bacde73feacbedd ]

fixrange_init operates at PMD-granularity and expects the addresses to be PMD-size aligned, but currently that might not be the case for PKMAP_BASE unless it is defined properly, so ensure a correct alignment is used before passing the address to fixrange_init.

fixed mappings: only align the start address that is passed to fixrange_init rather than the value before adding the size, as we may end up with uninitialised upper part of the range.

Signed-off-by Marcin Nowakowski <[email protected]>

Patchwork: https://patchwork.linux-mips.org/patch/15948/

Signed-off-by Ralf Baechle <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 arch/mips/mm/pgtable-32.c |    6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

arch/mips/mm/pgtable-32.c +3 -3

@@ -51,15 +51,15 @@ void __init pagetable_init(void)
 	/*
 	 * Fixed mappings:
 	 */
-	vaddr = __fix_to_virt(__end_of_fixed_addresses - 1) & PMD_MASK;
-	fixrange_init(vaddr, vaddr + FIXADDR_SIZE, pgd_base);
+	vaddr = __fix_to_virt(__end_of_fixed_addresses - 1);
+	fixrange_init(vaddr & PMD_MASK, vaddr + FIXADDR_SIZE, pgd_base);
 
 #ifdef CONFIG_HIGHMEM
 	/*
 	 * Permanent kmaps:
 	 */
 	vaddr = PKMAP_BASE;
-	fixrange_init(vaddr, vaddr + PAGE_SIZE*LAST_PKMAP, pgd_base);
+	fixrange_init(vaddr & PMD_MASK, vaddr + PAGE_SIZE*LAST_PKMAP, pgd_base);
 
 	pgd = swapper_pg_dir + __pgd_offset(vaddr);
 	pud = pud_offset(pgd, vaddr);

Greg Kroah-Hartman

author maintainer

2018-04-11 18:35 UTC #228 lore raw

PATCH 219/310 MIPS: mm: adjust PKMAP location

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Marcin Nowakowski <[email protected]>

[ Upstream commit c56e7a4c3e77f6fbd9b55c06c14eda65aae58958 ]

Space reserved for PKMap should span from PKMAP_BASE to FIXADDR_START. For large page sizes this is not the case as eg. for 64k pages the range currently defined is from 0xfe000000 to 0x102000000(!!) which obviously isn't right.
Remove the hardcoded location and set the BASE address as an offset from FIXADDR_START.

Since all PKMAP ptes have to be placed in a contiguous memory, ensure that this is the case by placing them all in a single page. This is achieved by aligning the end address to pkmap pages count pages.

Signed-off-by Marcin Nowakowski <[email protected]>

Patchwork: https://patchwork.linux-mips.org/patch/15950/

Signed-off-by Ralf Baechle <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 arch/mips/include/asm/pgtable-32.h |    7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

arch/mips/include/asm/pgtable-32.h +6 -1

@@ -18,6 +18,10 @@
 
 #include <asm-generic/pgtable-nopmd.h>
 
+#ifdef CONFIG_HIGHMEM
+#include <asm/highmem.h>
+#endif
+
 extern int temp_tlb_entry;
 
 /*

@@ -61,7 +65,8 @@ extern int add_temporary_entry(unsigned
 
 #define VMALLOC_START	  MAP_BASE
 
-#define PKMAP_BASE		(0xfe000000UL)
+#define PKMAP_END	((FIXADDR_START) & ~((LAST_PKMAP << PAGE_SHIFT)-1))
+#define PKMAP_BASE	(PKMAP_END - PAGE_SIZE * LAST_PKMAP)
 
 #ifdef CONFIG_HIGHMEM
 # define VMALLOC_END	(PKMAP_BASE-2*PAGE_SIZE)

Greg Kroah-Hartman

author maintainer

2018-04-11 18:35 UTC #229 lore raw

PATCH 220/310 MIPS: kprobes: flush_insn_slot should flush only if probe initialised

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Marcin Nowakowski <[email protected]>

[ Upstream commit 698b851073ddf5a894910d63ca04605e0473414e ]

When ftrace is used with kprobes, it is possible for a kprobe to contain an invalid location (ie. only initialised to 0 and not to a specific location in the code). Trying to perform a cache flush on such location leads to a crash r4k_flush_icache_range().

Fixes c1bf207d6ee1 ("MIPS: kprobe: Add support.")

Signed-off-by Marcin Nowakowski <[email protected]>

Patchwork: https://patchwork.linux-mips.org/patch/16296/

Signed-off-by Ralf Baechle <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 arch/mips/include/asm/kprobes.h |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

arch/mips/include/asm/kprobes.h +2 -1

@@ -40,7 +40,8 @@ typedef union mips_instruction kprobe_op
 
 #define flush_insn_slot(p)						\
 do {									\
-	flush_icache_range((unsigned long)p->addr,			\
+	if (p->addr)							\
+		flush_icache_range((unsigned long)p->addr,		\
 			   (unsigned long)p->addr +			\
 			   (MAX_INSN_SIZE * sizeof(kprobe_opcode_t)));	\
 } while (0)

Greg Kroah-Hartman

author maintainer

2018-04-11 18:36 UTC #230 lore raw

PATCH 221/310 ARM: dts: armadillo800eva: Split LCD mux and gpio

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Geert Uytterhoeven <[email protected]>

[ Upstream commit 13132b3f44d3600983aceb7e9920b8ebb55a7cf8 ]

Configuration of the lcd0 pinmux group and GPIO hog for the external GPIO mux are done using a single device node, causing the "output-high" property to be applied to both. This will fail for the pinmux group, but doesn't cause any harm, as the failure is ignored silently.

However, after "pinctrl: sh-pfc: propagate errors on group config", the failure will become fatal, leading to a broken display:

sh-pfc e6050000.pin-controller: pin_config_group_set op failed for group 102 sh-pfc e6050000.pin-controller: Error applying setting, reverse things back sh-pfc e6050000.pin-controller: failed to select default state

Move the GPIO hog to its own node to fix this.

Fixes ffd2f9a5afb730b9 ("ARM: shmobile: armadillo800eva dts: Add pinctrl and gpio-hog for lcdc0")

Signed-off-by Geert Uytterhoeven <[email protected]>

Acked-by Laurent Pinchart <[email protected]>

Signed-off-by Simon Horman <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 arch/arm/boot/dts/r8a7740-armadillo800eva.dts |    2 ++
 1 file changed, 2 insertions(+)

arch/arm/boot/dts/r8a7740-armadillo800eva.dts +2 -0

@@ -266,7 +266,9 @@
 	lcd0_pins: lcd0 {
 		groups = "lcd0_data24_0", "lcd0_lclk_1", "lcd0_sync";
 		function = "lcd0";
+	};
 
+	lcd0_mux {
 		/* DBGMD/LCDC0/FSIA MUX */
 		gpio-hog;
 		gpios = <176 0>;

Greg Kroah-Hartman

author maintainer

2018-04-11 18:36 UTC #231 lore raw

PATCH 222/310 Fix loop device flush before configure v3

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: James Wang <[email protected]>

[ Upstream commit 6460495709aeb651896bc8e5c134b2e4ca7d34a8 ]

While installing SLES-12 (based on v4.4), I found that the installer will stall for 60+ seconds during LVM disk scan. The root cause was determined to be the removal of a bound device check in loop_flush() by commit b5dd2f6047ca ("block: loop: improve performance via blk-mq").

Restoring this check, examining ->lo_state as set by loop_set_fd() eliminates the bad behavior.

Test method:
modprobe loop max_loop=64
dd if=/dev/zero of=disk bs=512 count=200K for((i=0;i<4;i++))do losetup -f disk; done mkfs.ext4 -F /dev/loop0
for((i=0;i<4;i++))do mkdir t$i; mount /dev/loop$i t$i;done

for f in `ls /dev/loop[0-9]*|sort`; do \
	echo $f; dd if=$f of=/dev/null  bs=512 count=1; \
	done

Test output:  stock          patched
/dev/loop0    18.1217e-05    8.3842e-05
/dev/loop1     6.1114e-05    0.000147979
/dev/loop10    0.414701      0.000116564
/dev/loop11    0.7474        6.7942e-05
/dev/loop12    0.747986      8.9082e-05
/dev/loop13    0.746532      7.4799e-05
/dev/loop14    0.480041      9.3926e-05
/dev/loop15    1.26453       7.2522e-05

Note that from loop10 onward, the device is not mounted, yet the stock kernel consumes several orders of magnitude more wall time than it does for a mounted device.
(Thanks for Mike Galbraith <[email protected]>, give a changelog review.)

Reviewed-by Hannes Reinecke <[email protected]>

Reviewed-by Ming Lei <[email protected]>

Signed-off-by James Wang <[email protected]>

Fixes b5dd2f6047ca ("block: loop: improve performance via blk-mq")

Signed-off-by Jens Axboe <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/block/loop.c |    3 +++
 1 file changed, 3 insertions(+)

drivers/block/loop.c +3 -0

@@ -612,6 +612,9 @@ static int loop_switch(struct loop_devic
  */
 static int loop_flush(struct loop_device *lo)
 {
+	/* loop not yet configured, no running thread, nothing to flush */
+	if (lo->lo_state != Lo_bound)
+		return 0;
 	return loop_switch(lo, NULL);
 }

Greg Kroah-Hartman

author maintainer

2018-04-11 18:36 UTC #232 lore raw

PATCH 223/310 net: emac: fix reset timeout with AR8035 phy

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Christian Lamparter <[email protected]>

[ Upstream commit 19d90ece81da802207a9b91ce95a29fbdc40626e ]

This patch fixes a problem where the AR8035 PHY can't be detected on an Cisco Meraki MR24, if the ethernet cable is not connected on boot.

Russell Senior provided steps to reproduce the issue:

|Disconnect ethernet cable, apply power, wait until device has booted,
|plug in ethernet, check for interfaces, no eth0 is listed.
|
|This appears to be a problem during probing of the AR8035 Phy chip.
|When ethernet has no link, the phy detection fails, and eth0 is not
|created. Plugging ethernet later has no effect, because there is no
|interface as far as the kernel is concerned. The relevant part of
|the boot log looks like this:
|this is the failing case:
|
|[    0.876611] /plb/opb/emac-rgmii@ef601500: input 0 in RGMII mode
|[    0.882532] /plb/opb/ethernet@ef600c00: reset timeout
|[    0.888546] /plb/opb/ethernet@ef600c00: can't find PHY!
|and the succeeding case:
|
|[    0.876672] /plb/opb/emac-rgmii@ef601500: input 0 in RGMII mode
|[    0.883952] eth0: EMAC-0 /plb/opb/ethernet@ef600c00, MAC 00:01:..
|[    0.890822] eth0: found Atheros 8035 Gigabit Ethernet PHY (0x01)

Based on the comment and the commit message of commit 23fbb5a87c56 ("emac: Fix EMAC soft reset on 460EX/GT"). This is because the AR8035 PHY doesn't provide the TX Clock, if the ethernet cable is not attached. This causes the reset to timeout and the PHY detection code in emac_init_phy() is unable to detect the AR8035 PHY. As a result, the emac driver bails out early and the user left with no ethernet.

In order to stay compatible with existing configurations, the driver tries the current reset approach at first. Only if the first attempt timed out, it does perform one more retry with the clock temporarily switched to the internal source for just the duration of the reset.

LEDE-Bug: #687 <https://bugs.lede-project.org/index.php?do=details&task_id=687>

Cc Chris Blake <[email protected]>

Reported-by Russell Senior <[email protected]>

Fixes 23fbb5a87c56e98 ("emac: Fix EMAC soft reset on 460EX/GT")

Signed-off-by Christian Lamparter <[email protected]>

Reviewed-by Andrew Lunn <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/net/ethernet/ibm/emac/core.c |   26 ++++++++++++++++++++++----
 1 file changed, 22 insertions(+), 4 deletions(-)

drivers/net/ethernet/ibm/emac/core.c +22 -4

@@ -342,6 +342,7 @@ static int emac_reset(struct emac_instan
 {
 	struct emac_regs __iomem *p = dev->emacp;
 	int n = 20;
+	bool __maybe_unused try_internal_clock = false;
 
 	DBG(dev, "reset" NL);

@@ -354,6 +355,7 @@ static int emac_reset(struct emac_instan
 	}
 
 #ifdef CONFIG_PPC_DCR_NATIVE
+do_retry:
 	/*
 	 * PPC460EX/GT Embedded Processor Advanced User's Manual
 	 * section 28.10.1 Mode Register 0 (EMACx_MR0) states:

@@ -361,10 +363,19 @@ static int emac_reset(struct emac_instan
 	 * of the EMAC. If none is present, select the internal clock
 	 * (SDR0_ETH_CFG[EMACx_PHY_CLK] = 1).
 	 * After a soft reset, select the external clock.
+	 *
+	 * The AR8035-A PHY Meraki MR24 does not provide a TX Clk if the
+	 * ethernet cable is not attached. This causes the reset to timeout
+	 * and the PHY detection code in emac_init_phy() is unable to
+	 * communicate and detect the AR8035-A PHY. As a result, the emac
+	 * driver bails out early and the user has no ethernet.
+	 * In order to stay compatible with existing configurations, the
+	 * driver will temporarily switch to the internal clock, after
+	 * the first reset fails.
 	 */
 	if (emac_has_feature(dev, EMAC_FTR_460EX_PHY_CLK_FIX)) {
-		if (dev->phy_address == 0xffffffff &&
-		    dev->phy_map == 0xffffffff) {
+		if (try_internal_clock || (dev->phy_address == 0xffffffff &&
+					   dev->phy_map == 0xffffffff)) {
 			/* No PHY: select internal loop clock before reset */
 			dcri_clrset(SDR0, SDR0_ETH_CFG,
 				    0, SDR0_ETH_CFG_ECS << dev->cell_index);

@@ -382,8 +393,15 @@ static int emac_reset(struct emac_instan
 
 #ifdef CONFIG_PPC_DCR_NATIVE
 	if (emac_has_feature(dev, EMAC_FTR_460EX_PHY_CLK_FIX)) {
-		if (dev->phy_address == 0xffffffff &&
-		    dev->phy_map == 0xffffffff) {
+		if (!n && !try_internal_clock) {
+			/* first attempt has timed out. */
+			n = 20;
+			try_internal_clock = true;
+			goto do_retry;
+		}
+
+		if (try_internal_clock || (dev->phy_address == 0xffffffff &&
+					   dev->phy_map == 0xffffffff)) {
 			/* No PHY: restore external clock source after reset */
 			dcri_clrset(SDR0, SDR0_ETH_CFG,
 				    SDR0_ETH_CFG_ECS << dev->cell_index, 0);

Greg Kroah-Hartman

author maintainer

2018-04-11 18:36 UTC #233 lore raw

PATCH 224/310 perf tools: Decompress kernel module when reading DSO data

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Namhyung Kim <[email protected]>

[ Upstream commit 1d6b3c9ba756a5134fd7ad1959acac776d17404b ]

Currently perf decompresses kernel modules when loading the symbol table but it missed to do it when reading raw data.

Signed-off-by Namhyung Kim <[email protected]>

Acked-by Jiri Olsa <[email protected]>

Cc Adrian Hunter <[email protected]>

Cc David Ahern <[email protected]>

Cc Peter Zijlstra <[email protected]>

Cc Wang Nan <[email protected]>

Link http://lkml.kernel.org/r/[email protected] open here

Signed-off-by Arnaldo Carvalho de Melo <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 tools/perf/util/dso.c |   16 ++++++++++++++++
 1 file changed, 16 insertions(+)

tools/perf/util/dso.c +16 -0

@@ -366,7 +366,23 @@ static int __open_dso(struct dso *dso, s
 	if (!is_regular_file(name))
 		return -EINVAL;
 
+	if (dso__needs_decompress(dso)) {
+		char newpath[KMOD_DECOMP_LEN];
+		size_t len = sizeof(newpath);
+
+		if (dso__decompress_kmodule_path(dso, name, newpath, len) < 0) {
+			free(name);
+			return -dso->load_errno;
+		}
+
+		strcpy(name, newpath);
+	}
+
 	fd = do_open(name);
+
+	if (dso__needs_decompress(dso))
+		unlink(name);
+
 	free(name);
 	return fd;
 }

Greg Kroah-Hartman

author maintainer

2018-04-11 18:36 UTC #234 lore raw

PATCH 225/310 perf tests: Decompress kernel module before objdump

4.9-stable review patch. If anyone has any objections, please let me know.

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

From: Namhyung Kim <[email protected]>

[ Upstream commit 94df1040b1e6aacd8dec0ba3c61d7e77cd695f26 ]

If a kernel modules is compressed, it should be decompressed before running objdump to parse binary data correctly. This fixes a failure of object code reading test for me.

Signed-off-by Namhyung Kim <[email protected]>

Acked-by Adrian Hunter <[email protected]>

Acked-by Jiri Olsa <[email protected]>

Cc David Ahern <[email protected]>

Cc Peter Zijlstra <[email protected]>

Cc Wang Nan <[email protected]>

Link http://lkml.kernel.org/r/[email protected] open here

Signed-off-by Arnaldo Carvalho de Melo <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 tools/perf/tests/code-reading.c |   20 +++++++++++++++++++-
 1 file changed, 19 insertions(+), 1 deletion(-)

tools/perf/tests/code-reading.c +19 -1

@@ -224,6 +224,8 @@ static int read_object_code(u64 addr, si
 	unsigned char buf2[BUFSZ];
 	size_t ret_len;
 	u64 objdump_addr;
+	const char *objdump_name;
+	char decomp_name[KMOD_DECOMP_LEN];
 	int ret;
 
 	pr_debug("Reading object code for memory address: %#"PRIx64"\n", addr);

@@ -284,9 +286,25 @@ static int read_object_code(u64 addr, si
 		state->done[state->done_cnt++] = al.map->start;
 	}
 
+	objdump_name = al.map->dso->long_name;
+	if (dso__needs_decompress(al.map->dso)) {
+		if (dso__decompress_kmodule_path(al.map->dso, objdump_name,
+						 decomp_name,
+						 sizeof(decomp_name)) < 0) {
+			pr_debug("decompression failed\n");
+			return -1;
+		}
+
+		objdump_name = decomp_name;
+	}
+
 	/* Read the object code using objdump */
 	objdump_addr = map__rip_2objdump(al.map, al.addr);
-	ret = read_via_objdump(al.map->dso->long_name, objdump_addr, buf2, len);
+	ret = read_via_objdump(objdump_name, objdump_addr, buf2, len);
+
+	if (dso__needs_decompress(al.map->dso))
+		unlink(objdump_name);
+
 	if (ret > 0) {
 		/*
 		 * The kernel maps are inaccurate - assume objdump is right in

Greg Kroah-Hartman

author maintainer

2018-04-11 18:36 UTC #236 lore raw

PATCH 227/310 xen: avoid type warning in xchg_xen_ulong