Skip to contentSkip to conversation

4.10.2-stable review

PATCH In review Greg Kroah-Hartman 7 participants 181 messages Mar 10, 2017 – Mar 28, 2017 2 messages not in the archive Page 2 of 2

Subsystems (5)
lore
Share & tools
lore
author maintainer
#160 lore raw

PATCH 155/167 dmaengine: ipu: Make sure the interrupt routine checks all interrupts.

In reply to Greg Kroah-Hartman

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

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

From: Magnus Lilja <[email protected]>

commit adee40b265d7568296e218f079f478197ffa15bf upstream.

Commit 3d8cc00073d6 ("dmaengine: ipu: Consolidate duplicated irq handlers") consolidated the two interrupts routines into one, but the remaining interrupt routine only checks the status of the error interrupts, not the normal interrupts.

This patch fixes that problem (tested on i.MX31 PDK board).

Fixes 3d8cc00073d6 ("dmaengine: ipu: Consolidate duplicated irq handlers")
Cc Vinod Koul <[email protected]>
---
 drivers/dma/ipu/ipu_irq.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/dma/ipu/ipu_irq.c +1 -1
@@ -272,7 +272,7 @@ static void ipu_irq_handler(struct irq_d
 	u32 status;
 	int i, line;
 
-	for (i = IPU_IRQ_NR_FN_BANKS; i < IPU_IRQ_NR_BANKS; i++) {
+	for (i = 0; i < IPU_IRQ_NR_BANKS; i++) {
 		struct ipu_irq_bank *bank = irq_bank + i;
 
 		raw_spin_lock(&bank_lock);
author maintainer
#161 lore raw

PATCH 156/167 xprtrdma: Fix Read chunk padding

In reply to Greg Kroah-Hartman

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

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

From: Chuck Lever <[email protected]>

commit 24abdf1be15c478e2821d6fc903a4a4440beff02 upstream.

When pad optimization is disabled, rpcrdma_convert_iovs still does not add explicit XDR round-up padding to a Read chunk.

Commit 677eb17e94ed ("xprtrdma: Fix XDR tail buffer marshalling") incorrectly short-circuited the test for whether round-up padding is needed that appears later in rpcrdma_convert_iovs.

However, if this is indeed a regular Read chunk (and not a Position-Zero Read chunk), the tail iovec _always_ contains the chunk's padding, and never anything else.

So, it's easy to just skip the tail when padding optimization is enabled, and add the tail in a subsequent Read chunk segment, if disabled.

Fixes 677eb17e94ed ("xprtrdma: Fix XDR tail buffer marshalling")
---
 net/sunrpc/xprtrdma/rpc_rdma.c |   10 ++++------
 1 file changed, 4 insertions(+), 6 deletions(-)
net/sunrpc/xprtrdma/rpc_rdma.c +4 -6
@@ -226,8 +226,10 @@ rpcrdma_convert_iovs(struct xdr_buf *xdr
 	if (len && n == RPCRDMA_MAX_SEGS)
 		goto out_overflow;
 
-	/* When encoding the read list, the tail is always sent inline */
-	if (type == rpcrdma_readch)
+	/* When encoding a Read chunk, the tail iovec contains an
+	 * XDR pad and may be omitted.
+	 */
+	if (type == rpcrdma_readch && xprt_rdma_pad_optimize)
 		return n;
 
 	/* When encoding the Write list, some servers need to see an extra
@@ -238,10 +240,6 @@ rpcrdma_convert_iovs(struct xdr_buf *xdr
 		return n;
 
 	if (xdrbuf->tail[0].iov_len) {
-		/* the rpcrdma protocol allows us to omit any trailing
-		 * xdr pad bytes, saving the server an RDMA operation. */
-		if (xdrbuf->tail[0].iov_len < 4 && xprt_rdma_pad_optimize)
-			return n;
 		n = rpcrdma_convert_kvec(&xdrbuf->tail[0], seg, n);
 		if (n == RPCRDMA_MAX_SEGS)
 			goto out_overflow;
author maintainer
#162 lore raw

PATCH 157/167 xprtrdma: Per-connection pad optimization

In reply to Greg Kroah-Hartman

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

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

From: Chuck Lever <[email protected]>

commit b5f0afbea4f2ea52c613ac2b06cb6de2ea18cb6d upstream.

Pad optimization is changed by echoing into /proc/sys/sunrpc/rdma_pad_optimize. This is a global setting, affecting all RPC-over-RDMA connections to all servers.

The marshaling code picks up that value and uses it for decisions about how to construct each RPC-over-RDMA frame. Having it change suddenly in mid-operation can result in unexpected failures. And some servers a client mounts might need chunk round-up, while others don't.

So instead, copy the pad_optimize setting into each connection's rpcrdma_ia when the transport is created, and use the copy, which can't change during the life of the connection, instead.

This also removes a hack: rpcrdma_convert_iovs was using the remote-invalidation-expected flag to predict when it could leave out Write chunk padding. This is because the Linux server handles implicit XDR padding on Write chunks correctly, and only Linux servers can set the connection's remote-invalidation-expected flag.

It's more sensible to use the pad optimization setting instead.

Fixes 677eb17e94ed ("xprtrdma: Fix XDR tail buffer marshalling")
---
 net/sunrpc/xprtrdma/rpc_rdma.c  |   28 ++++++++++++++--------------
 net/sunrpc/xprtrdma/verbs.c     |    1 +
 net/sunrpc/xprtrdma/xprt_rdma.h |    1 +
 3 files changed, 16 insertions(+), 14 deletions(-)
net/sunrpc/xprtrdma/rpc_rdma.c +14 -14
@@ -186,9 +186,9 @@ rpcrdma_convert_kvec(struct kvec *vec, s
  */
 
 static int
-rpcrdma_convert_iovs(struct xdr_buf *xdrbuf, unsigned int pos,
-	enum rpcrdma_chunktype type, struct rpcrdma_mr_seg *seg,
-	bool reminv_expected)
+rpcrdma_convert_iovs(struct rpcrdma_xprt *r_xprt, struct xdr_buf *xdrbuf,
+		     unsigned int pos, enum rpcrdma_chunktype type,
+		     struct rpcrdma_mr_seg *seg)
 {
 	int len, n, p, page_base;
 	struct page **ppages;
@@ -229,14 +229,15 @@ rpcrdma_convert_iovs(struct xdr_buf *xdr
 	/* When encoding a Read chunk, the tail iovec contains an
 	 * XDR pad and may be omitted.
 	 */
-	if (type == rpcrdma_readch && xprt_rdma_pad_optimize)
+	if (type == rpcrdma_readch && r_xprt->rx_ia.ri_implicit_roundup)
 		return n;
 
-	/* When encoding the Write list, some servers need to see an extra
-	 * segment for odd-length Write chunks. The upper layer provides
-	 * space in the tail iovec for this purpose.
+	/* When encoding a Write chunk, some servers need to see an
+	 * extra segment for non-XDR-aligned Write chunks. The upper
+	 * layer provides space in the tail iovec that may be used
+	 * for this purpose.
 	 */
-	if (type == rpcrdma_writech && reminv_expected)
+	if (type == rpcrdma_writech && r_xprt->rx_ia.ri_implicit_roundup)
 		return n;
 
 	if (xdrbuf->tail[0].iov_len) {
@@ -291,7 +292,8 @@ rpcrdma_encode_read_list(struct rpcrdma_
 	if (rtype == rpcrdma_areadch)
 		pos = 0;
 	seg = req->rl_segments;
-	nsegs = rpcrdma_convert_iovs(&rqst->rq_snd_buf, pos, rtype, seg, false);
+	nsegs = rpcrdma_convert_iovs(r_xprt, &rqst->rq_snd_buf, pos,
+				     rtype, seg);
 	if (nsegs < 0)
 		return ERR_PTR(nsegs);
 
@@ -353,10 +355,9 @@ rpcrdma_encode_write_list(struct rpcrdma
 	}
 
 	seg = req->rl_segments;
-	nsegs = rpcrdma_convert_iovs(&rqst->rq_rcv_buf,
+	nsegs = rpcrdma_convert_iovs(r_xprt, &rqst->rq_rcv_buf,
 				     rqst->rq_rcv_buf.head[0].iov_len,
-				     wtype, seg,
-				     r_xprt->rx_ia.ri_reminv_expected);
+				     wtype, seg);
 	if (nsegs < 0)
 		return ERR_PTR(nsegs);
 
@@ -421,8 +422,7 @@ rpcrdma_encode_reply_chunk(struct rpcrdm
 	}
 
 	seg = req->rl_segments;
-	nsegs = rpcrdma_convert_iovs(&rqst->rq_rcv_buf, 0, wtype, seg,
-				     r_xprt->rx_ia.ri_reminv_expected);
+	nsegs = rpcrdma_convert_iovs(r_xprt, &rqst->rq_rcv_buf, 0, wtype, seg);
 	if (nsegs < 0)
 		return ERR_PTR(nsegs);
 
net/sunrpc/xprtrdma/verbs.c +1 -0
@@ -208,6 +208,7 @@ rpcrdma_update_connect_private(struct rp
 
 	/* Default settings for RPC-over-RDMA Version One */
 	r_xprt->rx_ia.ri_reminv_expected = false;
+	r_xprt->rx_ia.ri_implicit_roundup = xprt_rdma_pad_optimize;
 	rsize = RPCRDMA_V1_DEF_INLINE_SIZE;
 	wsize = RPCRDMA_V1_DEF_INLINE_SIZE;
 
net/sunrpc/xprtrdma/xprt_rdma.h +1 -0
@@ -75,6 +75,7 @@ struct rpcrdma_ia {
 	unsigned int		ri_max_inline_write;
 	unsigned int		ri_max_inline_read;
 	bool			ri_reminv_expected;
+	bool			ri_implicit_roundup;
 	enum ib_mr_type		ri_mrtype;
 	struct ib_qp_attr	ri_qp_attr;
 	struct ib_qp_init_attr	ri_qp_init_attr;
author maintainer
#163 lore raw

PATCH 158/167 xprtrdma: Disable pad optimization by default

In reply to Greg Kroah-Hartman

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

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

From: Chuck Lever <[email protected]>

commit c95a3c6b88658bcb8f77f85f31a0b9d9036e8016 upstream.

Commit d5440e27d3e5 ("xprtrdma: Enable pad optimization") made the Linux client omit XDR round-up padding in normal Read and Write chunks so that the client doesn't have to register and invalidate 3-byte memory regions that contain no real data.

Unfortunately, my cheery 2014 assessment that this optimization "is supported now by both Linux and Solaris servers" was premature. We've found bugs in Solaris in this area since commit d5440e27d3e5 ("xprtrdma: Enable pad optimization") was merged (SYMLINK is the main offender).

So for maximum interoperability, I'm disabling this optimization again. If a CM private message is exchanged when connecting, the client recognizes that the server is Linux, and enables the optimization for that connection.

Until now the Solaris server bugs did not impact common operations, and were thus largely benign. Soon, less capable devices on Linux NFS/RDMA clients will make use of Read chunks more often, and these Solaris bugs will prevent interoperation in more cases.

Fixes 677eb17e94ed ("xprtrdma: Fix XDR tail buffer marshalling")
---
 net/sunrpc/xprtrdma/transport.c |    2 +-
 net/sunrpc/xprtrdma/verbs.c     |    1 +
 2 files changed, 2 insertions(+), 1 deletion(-)
net/sunrpc/xprtrdma/transport.c +1 -1
@@ -67,7 +67,7 @@ unsigned int xprt_rdma_max_inline_read =
 static unsigned int xprt_rdma_max_inline_write = RPCRDMA_DEF_INLINE;
 static unsigned int xprt_rdma_inline_write_padding;
 static unsigned int xprt_rdma_memreg_strategy = RPCRDMA_FRMR;
-		int xprt_rdma_pad_optimize = 1;
+		int xprt_rdma_pad_optimize = 0;
 
 #if IS_ENABLED(CONFIG_SUNRPC_DEBUG)
 
net/sunrpc/xprtrdma/verbs.c +1 -0
@@ -216,6 +216,7 @@ rpcrdma_update_connect_private(struct rp
 	    pmsg->cp_magic == rpcrdma_cmp_magic &&
 	    pmsg->cp_version == RPCRDMA_CMP_VERSION) {
 		r_xprt->rx_ia.ri_reminv_expected = true;
+		r_xprt->rx_ia.ri_implicit_roundup = true;
 		rsize = rpcrdma_decode_buffer_size(pmsg->cp_send_size);
 		wsize = rpcrdma_decode_buffer_size(pmsg->cp_recv_size);
 	}
author maintainer
#164 lore raw

PATCH 159/167 xprtrdma: Reduce required number of send SGEs

In reply to Greg Kroah-Hartman

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

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

From: Chuck Lever <[email protected]>

commit 16f906d66cd76fb9895cbc628f447532a7ac1faa upstream.

The MAX_SEND_SGES check introduced in commit 655fec6987be ("xprtrdma: Use gathered Send for large inline messages") fails for devices that have a small max_sge.

Instead of checking for a large fixed maximum number of SGEs, check for a minimum small number. RPC-over-RDMA will switch to using a Read chunk if an xdr_buf has more pages than can fit in the device's max_sge limit. This is considerably better than failing all together to mount the server.

This fix supports devices that have as few as three send SGEs available.

---
 net/sunrpc/xprtrdma/rpc_rdma.c  |   26 +++++++++++++++++++++++---
 net/sunrpc/xprtrdma/verbs.c     |   13 +++++++------
 net/sunrpc/xprtrdma/xprt_rdma.h |    2 ++
 3 files changed, 32 insertions(+), 9 deletions(-)
net/sunrpc/xprtrdma/rpc_rdma.c +23 -3
@@ -125,14 +125,34 @@ void rpcrdma_set_max_header_sizes(struct
 /* The client can send a request inline as long as the RPCRDMA header
  * plus the RPC call fit under the transport's inline limit. If the
  * combined call message size exceeds that limit, the client must use
- * the read chunk list for this operation.
+ * a Read chunk for this operation.
+ *
+ * A Read chunk is also required if sending the RPC call inline would
+ * exceed this device's max_sge limit.
  */
 static bool rpcrdma_args_inline(struct rpcrdma_xprt *r_xprt,
 				struct rpc_rqst *rqst)
 {
-	struct rpcrdma_ia *ia = &r_xprt->rx_ia;
+	struct xdr_buf *xdr = &rqst->rq_snd_buf;
+	unsigned int count, remaining, offset;
 
-	return rqst->rq_snd_buf.len <= ia->ri_max_inline_write;
+	if (xdr->len > r_xprt->rx_ia.ri_max_inline_write)
+		return false;
+
+	if (xdr->page_len) {
+		remaining = xdr->page_len;
+		offset = xdr->page_base & ~PAGE_MASK;
+		count = 0;
+		while (remaining) {
+			remaining -= min_t(unsigned int,
+					   PAGE_SIZE - offset, remaining);
+			offset = 0;
+			if (++count > r_xprt->rx_ia.ri_max_send_sges)
+				return false;
+		}
+	}
+
+	return true;
 }
 
 /* The client can't know how large the actual reply will be. Thus it
net/sunrpc/xprtrdma/verbs.c +7 -6
@@ -488,18 +488,19 @@ rpcrdma_ia_close(struct rpcrdma_ia *ia)
  */
 int
 rpcrdma_ep_create(struct rpcrdma_ep *ep, struct rpcrdma_ia *ia,
-				struct rpcrdma_create_data_internal *cdata)
+		  struct rpcrdma_create_data_internal *cdata)
 {
 	struct rpcrdma_connect_private *pmsg = &ep->rep_cm_private;
+	unsigned int max_qp_wr, max_sge;
 	struct ib_cq *sendcq, *recvcq;
-	unsigned int max_qp_wr;
 	int rc;
 
-	if (ia->ri_device->attrs.max_sge < RPCRDMA_MAX_SEND_SGES) {
-		dprintk("RPC:       %s: insufficient sge's available\n",
-			__func__);
+	max_sge = min(ia->ri_device->attrs.max_sge, RPCRDMA_MAX_SEND_SGES);
+	if (max_sge < RPCRDMA_MIN_SEND_SGES) {
+		pr_warn("rpcrdma: HCA provides only %d send SGEs\n", max_sge);
 		return -ENOMEM;
 	}
+	ia->ri_max_send_sges = max_sge - RPCRDMA_MIN_SEND_SGES;
 
 	if (ia->ri_device->attrs.max_qp_wr <= RPCRDMA_BACKWARD_WRS) {
 		dprintk("RPC:       %s: insufficient wqe's available\n",
@@ -524,7 +525,7 @@ rpcrdma_ep_create(struct rpcrdma_ep *ep,
 	ep->rep_attr.cap.max_recv_wr = cdata->max_requests;
 	ep->rep_attr.cap.max_recv_wr += RPCRDMA_BACKWARD_WRS;
 	ep->rep_attr.cap.max_recv_wr += 1;	/* drain cqe */
-	ep->rep_attr.cap.max_send_sge = RPCRDMA_MAX_SEND_SGES;
+	ep->rep_attr.cap.max_send_sge = max_sge;
 	ep->rep_attr.cap.max_recv_sge = 1;
 	ep->rep_attr.cap.max_inline_data = 0;
 	ep->rep_attr.sq_sig_type = IB_SIGNAL_REQ_WR;
net/sunrpc/xprtrdma/xprt_rdma.h +2 -0
@@ -74,6 +74,7 @@ struct rpcrdma_ia {
 	unsigned int		ri_max_frmr_depth;
 	unsigned int		ri_max_inline_write;
 	unsigned int		ri_max_inline_read;
+	unsigned int		ri_max_send_sges;
 	bool			ri_reminv_expected;
 	bool			ri_implicit_roundup;
 	enum ib_mr_type		ri_mrtype;
@@ -311,6 +312,7 @@ struct rpcrdma_mr_seg {		/* chunk descri
  * - xdr_buf tail iovec
  */
 enum {
+	RPCRDMA_MIN_SEND_SGES = 3,
 	RPCRDMA_MAX_SEND_PAGES = PAGE_SIZE + RPCRDMA_MAX_INLINE - 1,
 	RPCRDMA_MAX_PAGE_SGES = (RPCRDMA_MAX_SEND_PAGES >> PAGE_SHIFT) + 1,
 	RPCRDMA_MAX_SEND_SGES = 1 + 1 + RPCRDMA_MAX_PAGE_SGES + 1,
author maintainer
#165 lore raw

PATCH 160/167 powerpc/xmon: Fix data-breakpoint

In reply to Greg Kroah-Hartman

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

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

From: Ravi Bangoria <[email protected]>

commit c21a493a2b44650707d06741601894329486f2ad upstream.

Currently xmon data-breakpoint feature is broken.

Whenever there is a watchpoint match occurs, hw_breakpoint_handler will be called by do_break via notifier chains mechanism. If watchpoint is registered by xmon, hw_breakpoint_handler won't find any associated perf_event and returns immediately with NOTIFY_STOP. Similarly, do_break also returns without notifying to xmon.

Solve this by returning NOTIFY_DONE when hw_breakpoint_handler does not find any perf_event associated with matched watchpoint, rather than NOTIFY_STOP, which tells the core code to continue calling the other breakpoint handlers including the xmon one.

---
 arch/powerpc/kernel/hw_breakpoint.c |    4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)
arch/powerpc/kernel/hw_breakpoint.c +3 -1
@@ -228,8 +228,10 @@ int hw_breakpoint_handler(struct die_arg
 	rcu_read_lock();
 
 	bp = __this_cpu_read(bp_per_reg);
-	if (!bp)
+	if (!bp) {
+		rc = NOTIFY_DONE;
 		goto out;
+	}
 	info = counter_arch_bp(bp);
 
 	/*
author maintainer
#166 lore raw

PATCH 161/167 powerpc/mm: Add MMU_FTR_KERNEL_RO to possible feature mask

In reply to Greg Kroah-Hartman

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

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

From: Aneesh Kumar K.V <[email protected]>

commit a5ecdad4847897007399d7a14c9109b65ce4c9b7 upstream.

Without this we will always find the feature disabled.

Fixes 984d7a1ec6 ("powerpc/mm: Fixup kernel read only mapping")
---
 arch/powerpc/include/asm/mmu.h |    1 +
 1 file changed, 1 insertion(+)
arch/powerpc/include/asm/mmu.h +1 -0
@@ -136,6 +136,7 @@ enum {
 		MMU_FTR_NO_SLBIE_B | MMU_FTR_16M_PAGE | MMU_FTR_TLBIEL |
 		MMU_FTR_LOCKLESS_TLBIE | MMU_FTR_CI_LARGE_PAGE |
 		MMU_FTR_1T_SEGMENT | MMU_FTR_TLBIE_CROP_VA |
+		MMU_FTR_KERNEL_RO |
 #ifdef CONFIG_PPC_RADIX_MMU
 		MMU_FTR_TYPE_RADIX |
 #endif
author maintainer
#167 lore raw

PATCH 162/167 powerpc/mm/hash: Always clear UPRT and Host Radix bits when setting up CPU

In reply to Greg Kroah-Hartman

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

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

From: Aneesh Kumar K.V <[email protected]>

commit fda2d27db6eae5c2468f9e4657539b72bbc238bb upstream.

We will set LPCR with correct value for radix during int. This make sure we start with a sanitized value of LPCR. In case of kexec, cpus can have LPCR value based on the previous translation mode we were running.

Fixes fe036a0605d60 ("powerpc/64/kexec: Fix MMU cleanup on radix")
---
 arch/powerpc/kernel/cpu_setup_power.S |    4 ++++
 1 file changed, 4 insertions(+)
arch/powerpc/kernel/cpu_setup_power.S +4 -0
@@ -101,6 +101,8 @@ _GLOBAL(__setup_cpu_power9)
 	mfspr	r3,SPRN_LPCR
 	LOAD_REG_IMMEDIATE(r4, LPCR_PECEDH | LPCR_PECE_HVEE | LPCR_HVICE)
 	or	r3, r3, r4
+	LOAD_REG_IMMEDIATE(r4, LPCR_UPRT | LPCR_HR)
+	andc	r3, r3, r4
 	bl	__init_LPCR
 	bl	__init_HFSCR
 	bl	__init_tlb_power9
@@ -122,6 +124,8 @@ _GLOBAL(__restore_cpu_power9)
 	mfspr   r3,SPRN_LPCR
 	LOAD_REG_IMMEDIATE(r4, LPCR_PECEDH | LPCR_PECE_HVEE | LPCR_HVICE)
 	or	r3, r3, r4
+	LOAD_REG_IMMEDIATE(r4, LPCR_UPRT | LPCR_HR)
+	andc	r3, r3, r4
 	bl	__init_LPCR
 	bl	__init_HFSCR
 	bl	__init_tlb_power9
author maintainer
#168 lore raw

PATCH 163/167 module: fix memory leak on early load_module() failures

In reply to Greg Kroah-Hartman

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

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

From: Luis R. Rodriguez <[email protected]>

commit a5544880aff90baf1bd4443ac7ff65182213ffcd upstream.

While looking for early possible module loading failures I was able to reproduce a memory leak possible with kmemleak. There are a few rare ways to trigger a failure:

o we've run into a failure while processing kernel parameters (parse_args() returns an error)
o mod_sysfs_setup() fails
o we're a live patch module and copy_module_elf() fails

Chances of running into this issue is really low.

kmemleak splat:

unreferenced object 0xffff9f2c4ada1b00 (size 32):
comm "kworker/u16:4", pid 82, jiffies 4294897636 (age 681.816s) hex dump (first 32 bytes):

    6d 65 6d 73 74 69 63 6b 30 00 00 00 00 00 00 00  memstick0.......
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
  backtrace:
    [<ffffffff8c6cfeba>] kmemleak_alloc+0x4a/0xa0
    [<ffffffff8c200046>] __kmalloc_track_caller+0x126/0x230
    [<ffffffff8c1bc581>] kstrdup+0x31/0x60
    [<ffffffff8c1bc5d4>] kstrdup_const+0x24/0x30
    [<ffffffff8c3c23aa>] kvasprintf_const+0x7a/0x90
    [<ffffffff8c3b5481>] kobject_set_name_vargs+0x21/0x90
    [<ffffffff8c4fbdd7>] dev_set_name+0x47/0x50
    [<ffffffffc07819e5>] memstick_check+0x95/0x33c [memstick]
    [<ffffffff8c09c893>] process_one_work+0x1f3/0x4b0
    [<ffffffff8c09cb98>] worker_thread+0x48/0x4e0
    [<ffffffff8c0a2b79>] kthread+0xc9/0xe0
    [<ffffffff8c6dab5f>] ret_from_fork+0x1f/0x40
    [<ffffffffffffffff>] 0xffffffffffffffff
---
 kernel/module.c |    1 +
 1 file changed, 1 insertion(+)
kernel/module.c +1 -0
@@ -3719,6 +3719,7 @@ static int load_module(struct load_info
 	mod_sysfs_teardown(mod);
  coming_cleanup:
 	mod->state = MODULE_STATE_GOING;
+	destroy_params(mod->kp, mod->num_kp);
 	blocking_notifier_call_chain(&module_notify_list,
 				     MODULE_STATE_GOING, mod);
 	klp_module_going(mod);
author maintainer
#169 lore raw

PATCH 164/167 MIPS: IP22: Reformat inline assembler code to modern standards.

In reply to Greg Kroah-Hartman

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

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

From: Ralf Baechle <[email protected]>

commit f9f1c8db1c37253805eaa32265e1e1af3ae7d0a4 upstream.

---
 arch/mips/mm/sc-ip22.c |   43 +++++++++++++++++++++++--------------------
 1 file changed, 23 insertions(+), 20 deletions(-)
arch/mips/mm/sc-ip22.c +23 -20
@@ -31,26 +31,29 @@ static inline void indy_sc_wipe(unsigned
 	unsigned long tmp;
 
 	__asm__ __volatile__(
-	".set\tpush\t\t\t# indy_sc_wipe\n\t"
-	".set\tnoreorder\n\t"
-	".set\tmips3\n\t"
-	".set\tnoat\n\t"
-	"mfc0\t%2, $12\n\t"
-	"li\t$1, 0x80\t\t\t# Go 64 bit\n\t"
-	"mtc0\t$1, $12\n\t"
-
-	"dli\t$1, 0x9000000080000000\n\t"
-	"or\t%0, $1\t\t\t# first line to flush\n\t"
-	"or\t%1, $1\t\t\t# last line to flush\n\t"
-	".set\tat\n\t"
-
-	"1:\tsw\t$0, 0(%0)\n\t"
-	"bne\t%0, %1, 1b\n\t"
-	" daddu\t%0, 32\n\t"
-
-	"mtc0\t%2, $12\t\t\t# Back to 32 bit\n\t"
-	"nop; nop; nop; nop;\n\t"
-	".set\tpop"
+	"	.set	push			# indy_sc_wipe		\n"
+	"	.set	noreorder					\n"
+	"	.set	mips3						\n"
+	"	.set	noat						\n"
+	"	mfc0	%2, $12						\n"
+	"	li	$1, 0x80		# Go 64 bit		\n"
+	"	mtc0	$1, $12						\n"
+	"								\n"
+	"	dli	$1, 0x9000000080000000				\n"
+	"	or	%0, $1			# first line to flush	\n"
+	"	or	%1, $1			# last line to flush	\n"
+	"	.set	at						\n"
+	"								\n"
+	"1:	sw	$0, 0(%0)					\n"
+	"	bne	%0, %1, 1b					\n"
+	"	 daddu	%0, 32						\n"
+	"								\n"
+	"	mtc0	%2, $12			# Back to 32 bit	\n"
+	"	nop				# pipeline hazard	\n"
+	"	nop							\n"
+	"	nop							\n"
+	"	nop							\n"
+	"	.set	pop						\n"
 	: "=r" (first), "=r" (last), "=&r" (tmp)
 	: "0" (first), "1" (last));
 }
author maintainer
#170 lore raw

PATCH 165/167 MIPS: IP22: Fix build error due to binutils 2.25 uselessnes.

In reply to Greg Kroah-Hartman

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

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

From: Ralf Baechle <[email protected]>

commit ae2f5e5ed04a17c1aa1f0a3714c725e12c21d2a9 upstream.

Fix the following build error with binutils 2.25.

CC arch/mips/mm/sc-ip22.o
{standard input}: Assembler messages:
{standard input}:132: Error: number (0x9000000080000000) larger than 32 bits {standard input}:159: Error: number (0x9000000080000000) larger than 32 bits {standard input}:200: Error: number (0x9000000080000000) larger than 32 bits scripts/Makefile.build:293: recipe for target 'arch/mips/mm/sc-ip22.o' failed make[1]: *** [arch/mips/mm/sc-ip22.o] Error 1

MIPS has used .set mips3 to temporarily switch the assembler to 64 bit mode in 64 bit kernels virtually forever. Binutils 2.25 broke this behavious partially by happily accepting 64 bit instructions in .set mips3 mode but puking on 64 bit constants when generating 32 bit ELF. Binutils 2.26 restored the old behaviour again.

Fix build with binutils 2.25 by open coding the offending

	dli $1, 0x9000000080000000

as

	li	$1, 0x9000
	dsll	$1, $1, 48

which is ugly be the only thing that will build on all binutils vintages.

---
 arch/mips/mm/sc-ip22.c |   13 ++++++++++++-
 1 file changed, 12 insertions(+), 1 deletion(-)
arch/mips/mm/sc-ip22.c +12 -1
@@ -39,7 +39,18 @@ static inline void indy_sc_wipe(unsigned
 	"	li	$1, 0x80		# Go 64 bit		\n"
 	"	mtc0	$1, $12						\n"
 	"								\n"
-	"	dli	$1, 0x9000000080000000				\n"
+	"	#							\n"
+	"	# Open code a dli $1, 0x9000000080000000		\n"
+	"	#							\n"
+	"	# Required because binutils 2.25 will happily accept	\n"
+	"	# 64 bit instructions in .set mips3 mode but puke on	\n"
+	"	# 64 bit constants when generating 32 bit ELF		\n"
+	"	#							\n"
+	"	lui	$1,0x9000					\n"
+	"	dsll	$1,$1,0x10					\n"
+	"	ori	$1,$1,0x8000					\n"
+	"	dsll	$1,$1,0x10					\n"
+	"								\n"
 	"	or	%0, $1			# first line to flush	\n"
 	"	or	%1, $1			# last line to flush	\n"
 	"	.set	at						\n"
author maintainer
#171 lore raw

PATCH 166/167 scsi: lpfc: Correct WQ creation for pagesize

In reply to Greg Kroah-Hartman

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

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

From: James Smart <[email protected]>

commit 8ea73db486cda442f0671f4bc9c03a76be398a28 upstream.

Correct WQ creation for pagesize

The driver was calculating the adapter command pagesize indicator from the system pagesize. However, the buffers the driver allocates are only one size (SLI4_PAGE_SIZE), so no calculation was necessary.

---
 drivers/scsi/lpfc/lpfc_hw4.h |    2 ++
 drivers/scsi/lpfc/lpfc_sli.c |    9 +++++----
 2 files changed, 7 insertions(+), 4 deletions(-)
drivers/scsi/lpfc/lpfc_hw4.h +2 -0
@@ -1186,6 +1186,7 @@ struct lpfc_mbx_wq_create {
 #define lpfc_mbx_wq_create_page_size_SHIFT	0
 #define lpfc_mbx_wq_create_page_size_MASK	0x000000FF
 #define lpfc_mbx_wq_create_page_size_WORD	word1
+#define LPFC_WQ_PAGE_SIZE_4096	0x1
 #define lpfc_mbx_wq_create_wqe_size_SHIFT	8
 #define lpfc_mbx_wq_create_wqe_size_MASK	0x0000000F
 #define lpfc_mbx_wq_create_wqe_size_WORD	word1
@@ -1257,6 +1258,7 @@ struct rq_context {
 #define lpfc_rq_context_page_size_SHIFT	0		/* Version 1 Only */
 #define lpfc_rq_context_page_size_MASK	0x000000FF
 #define lpfc_rq_context_page_size_WORD	word0
+#define	LPFC_RQ_PAGE_SIZE_4096	0x1
 	uint32_t reserved1;
 	uint32_t word2;
 #define lpfc_rq_context_cq_id_SHIFT	16
drivers/scsi/lpfc/lpfc_sli.c +5 -4
@@ -13718,7 +13718,7 @@ lpfc_wq_create(struct lpfc_hba *phba, st
 			       LPFC_WQ_WQE_SIZE_128);
 			bf_set(lpfc_mbx_wq_create_page_size,
 			       &wq_create->u.request_1,
-			       (PAGE_SIZE/SLI4_PAGE_SIZE));
+			       LPFC_WQ_PAGE_SIZE_4096);
 			page = wq_create->u.request_1.page;
 			break;
 		}
@@ -13744,8 +13744,9 @@ lpfc_wq_create(struct lpfc_hba *phba, st
 			       LPFC_WQ_WQE_SIZE_128);
 			break;
 		}
-		bf_set(lpfc_mbx_wq_create_page_size, &wq_create->u.request_1,
-		       (PAGE_SIZE/SLI4_PAGE_SIZE));
+		bf_set(lpfc_mbx_wq_create_page_size,
+		       &wq_create->u.request_1,
+		       LPFC_WQ_PAGE_SIZE_4096);
 		page = wq_create->u.request_1.page;
 		break;
 	default:
@@ -13931,7 +13932,7 @@ lpfc_rq_create(struct lpfc_hba *phba, st
 		       LPFC_RQE_SIZE_8);
 		bf_set(lpfc_rq_context_page_size,
 		       &rq_create->u.request.context,
-		       (PAGE_SIZE/SLI4_PAGE_SIZE));
+		       LPFC_RQ_PAGE_SIZE_4096);
 	} else {
 		switch (hrq->entry_count) {
 		default:
author maintainer
#172 lore raw

PATCH 167/167 ceph: update readpages osd request according to size of pages

In reply to Greg Kroah-Hartman

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

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

From: Yan, Zheng <[email protected]>

commit d641df819db8b80198fd85d9de91137e8a823b07 upstream.

add_to_page_cache_lru() can fails, so the actual pages to read can be smaller than the initial size of osd request. We need to update osd request size in that case.

---
 fs/ceph/addr.c        |    1 +
 net/ceph/osd_client.c |    3 ++-
 2 files changed, 3 insertions(+), 1 deletion(-)
fs/ceph/addr.c +1 -0
@@ -391,6 +391,7 @@ static int start_read(struct inode *inod
 			nr_pages = i;
 			if (nr_pages > 0) {
 				len = nr_pages << PAGE_SHIFT;
+				osd_req_op_extent_update(req, 0, len);
 				break;
 			}
 			goto out_pages;
net/ceph/osd_client.c +2 -1
@@ -672,7 +672,8 @@ void osd_req_op_extent_update(struct cep
 	BUG_ON(length > previous);
 
 	op->extent.length = length;
-	op->indata_len -= previous - length;
+	if (op->op == CEPH_OSD_OP_WRITE || op->op == CEPH_OSD_OP_WRITEFULL)
+		op->indata_len -= previous - length;
 }
 EXPORT_SYMBOL(osd_req_op_extent_update);
 
#173 lore raw
In reply to Greg Kroah-Hartman
Quoted 8 lines · Greg Kroah-Hartman

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

Responses should be made by Sun Mar 12 08:39:21 UTC 2017. Anything received after that time might be too late.

Build results:

	total: 149 pass: 149 fail: 0
Qemu test results:
	total: 122 pass: 122 fail: 0

Details are available at http://kerneltests.org/builders.

Guenter

author maintainer
#174 lore raw
Quoted 9 lines · Guenter Roeck
Quoted 8 lines · Greg Kroah-Hartman

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

Responses should be made by Sun Mar 12 08:39:21 UTC 2017. Anything received after that time might be too late.

Quoted 6 lines

Build results:

	total: 149 pass: 149 fail: 0
Qemu test results:
	total: 122 pass: 122 fail: 0

Details are available at http://kerneltests.org/builders.

Thanks for testing all of these and letting me know.

greg k-h

#175 lore raw
In reply to Greg Kroah-Hartman
Quoted 9 lines · Greg Kroah-Hartman

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

Responses should be made by Sun Mar 12 08:39:21 UTC 2017. Anything received after that time might be too late.

The whole patch series can be found in one patch at:

Quoted 9 lines
	kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.10.2-rc1.gz

or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.10.y
and the diffstat can be found below.

thanks,

greg k-h

Compiled and booted on my test system. No dmesg regressions.

thanks,
-- Shuah

author maintainer
#176 lore raw
Quoted 15 lines · Shuah Khan
Quoted 14 lines · Greg Kroah-Hartman

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

Responses should be made by Sun Mar 12 08:39:21 UTC 2017. Anything received after that time might be too late.

The whole patch series can be found in one patch at:

	kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.10.2-rc1.gz

or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.10.y
and the diffstat can be found below.

Quoted 6 lines
Quoted 4 lines

thanks,

greg k-h

Compiled and booted on my test system. No dmesg regressions.

Thanks for testing all of these and letting me know.

greg k-h

A message that is not in the archive (sent off-list or not yet received): [email protected]

A message that is not in the archive (sent off-list or not yet received): [email protected]

#179 lore raw
Quoted 16 lines · Kevin Hilman
Quoted 14 lines · kernelci.org bot

stable-rc boot: 541 boots: 6 failed, 500 passed with 34 offline, 1 conflict (v4.10.1-168-gcdc1f9d24aac)

Full Boot Summary: https://kernelci.org/boot/all/job/stable-rc/kernel/v4.10.1-168-gcdc1f9d24aac/
Full Build Summary: https://kernelci.org/build/stable-rc/kernel/v4.10.1-168-gcdc1f9d24aac/

Tree: stable-rc
Branch: local/linux-4.10.y
Git Describe: v4.10.1-168-gcdc1f9d24aac
Git Commit: cdc1f9d24aac385a7fe4611d7b42f51e20f49cdb
Git URL: http://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
Tested: 101 unique boards, 25 SoC families, 30 builds out of 204

Boot Regressions Detected:

Quoted 8 lines
Quoted 5 lines

arm:

    multi_v7_defconfig+CONFIG_PROVE_LOCKING=y:
        am335x-pepper:
            lab-baylibre-seattle: new failure (last pass: v4.10-21-gd23a9821d397)

This one is a new regression, and a first attempt at bisect was inconclusive.

Bisect fingered the commit below. I confirmed that reverting that commit on top of stable-rc/linux-4.10.y gets this am335x-pepper
platform booting again. What's rather strange is that this boot test
is using a .cpio.gz initramfs, and not using any ext4 filesystem.

04992982b8f8caf6c54531a23d3f9c2bc4d0a7d8 is the first bad commit commit 04992982b8f8caf6c54531a23d3f9c2bc4d0a7d8

Author: Theodore Ts'o <[email protected]>
Date:   Sat Feb 4 23:04:00 2017 -0500

ext4: fix inline data error paths

commit eb5efbcb762aee4b454b04f7115f73ccbcf8f0ef upstream.

The write_end() function must always unlock the page and drop its ref count, even on an error.

Kevin

#180 lore raw
Quoted 23 lines · Kevin Hilman
Quoted 22 lines · Kevin Hilman
Quoted 19 lines · kernelci.org bot

stable-rc boot: 541 boots: 6 failed, 500 passed with 34 offline, 1 conflict (v4.10.1-168-gcdc1f9d24aac)

Full Boot Summary: https://kernelci.org/boot/all/job/stable-rc/kernel/v4.10.1-168-gcdc1f9d24aac/
Full Build Summary: https://kernelci.org/build/stable-rc/kernel/v4.10.1-168-gcdc1f9d24aac/

Tree: stable-rc
Branch: local/linux-4.10.y
Git Describe: v4.10.1-168-gcdc1f9d24aac
Git Commit: cdc1f9d24aac385a7fe4611d7b42f51e20f49cdb
Git URL: http://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
Tested: 101 unique boards, 25 SoC families, 30 builds out of 204

Boot Regressions Detected:

arm:

    multi_v7_defconfig+CONFIG_PROVE_LOCKING=y:
        am335x-pepper:
            lab-baylibre-seattle: new failure (last pass: v4.10-21-gd23a9821d397)
Quoted 8 lines
Quoted 2 lines

This one is a new regression, and a first attempt at bisect was inconclusive.

Bisect fingered the commit below. I confirmed that reverting that commit on top of stable-rc/linux-4.10.y gets this am335x-pepper
platform booting again. What's rather strange is that this boot test
is using a .cpio.gz initramfs, and not using any ext4 filesystem.

Does that even make sense ? Just wondering, after the problems we are currently experiencing with nios2. Those "bisected" as well to a commit associated with code which never executed. It turned out that the change in code size caused completely unrelated memory overwrites to be observed. Reverting the patch in question also seemed to "fix" the problem. Only, of course, that wasn't true.

Maybe something similar is happening here ?

Guenter

Quoted 18 lines

04992982b8f8caf6c54531a23d3f9c2bc4d0a7d8 is the first bad commit commit 04992982b8f8caf6c54531a23d3f9c2bc4d0a7d8

Author: Theodore Ts'o <[email protected]>
Date:   Sat Feb 4 23:04:00 2017 -0500

ext4: fix inline data error paths

commit eb5efbcb762aee4b454b04f7115f73ccbcf8f0ef upstream.

The write_end() function must always unlock the page and drop its ref count, even on an error.

Kevin

#181 lore raw
Quoted 53 lines · Guenter Roeck
Quoted 32 lines · Kevin Hilman
Quoted 29 lines · Kevin Hilman
Quoted 24 lines · kernelci.org bot

stable-rc boot: 541 boots: 6 failed, 500 passed with 34 offline, 1 conflict (v4.10.1-168-gcdc1f9d24aac)

Full Boot Summary:
https://kernelci.org/boot/all/job/stable-rc/kernel/v4.10.1-168-gcdc1f9d24aac/
Full Build Summary:
https://kernelci.org/build/stable-rc/kernel/v4.10.1-168-gcdc1f9d24aac/

Tree: stable-rc
Branch: local/linux-4.10.y
Git Describe: v4.10.1-168-gcdc1f9d24aac
Git Commit: cdc1f9d24aac385a7fe4611d7b42f51e20f49cdb Git URL:
http://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
Tested: 101 unique boards, 25 SoC families, 30 builds out of 204

Boot Regressions Detected:

arm:

multi_v7_defconfig+CONFIG_PROVE_LOCKING=y:
am335x-pepper:
lab-baylibre-seattle: new failure (last pass:
v4.10-21-gd23a9821d397)

Quoted 9 lines
Quoted 2 lines

This one is a new regression, and a first attempt at bisect was inconclusive.

Bisect fingered the commit below. I confirmed that reverting that commit on top of stable-rc/linux-4.10.y gets this am335x-pepper
platform booting again. What's rather strange is that this boot test
is using a .cpio.gz initramfs, and not using any ext4 filesystem.

Does that even make sense ? Just wondering, after the problems we are currently
experiencing with nios2. Those "bisected" as well to a commit associated with
code which never executed. It turned out that the change in code size caused completely unrelated memory overwrites to be observed. Reverting the patch in
question also seemed to "fix" the problem. Only, of course, that wasn't true.

Quoted 1 line

Maybe something similar is happening here ?

Right, I'm not confident at all in what's actually going wrong here, but I ran out of time to keep digging, so I thought I'd at least report the results.

Kevin

author maintainer
#182 lore raw
In reply to a message not in the archive
Quoted 44 lines · Kevin Hilman
Quoted 12 lines · kernelci.org bot

stable-rc boot: 541 boots: 6 failed, 500 passed with 34 offline, 1 conflict (v4.10.1-168-gcdc1f9d24aac)

Full Boot Summary: https://kernelci.org/boot/all/job/stable-rc/kernel/v4.10.1-168-gcdc1f9d24aac/
Full Build Summary: https://kernelci.org/build/stable-rc/kernel/v4.10.1-168-gcdc1f9d24aac/

Tree: stable-rc
Branch: local/linux-4.10.y
Git Describe: v4.10.1-168-gcdc1f9d24aac
Git Commit: cdc1f9d24aac385a7fe4611d7b42f51e20f49cdb
Git URL: http://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
Tested: 101 unique boards, 25 SoC families, 30 builds out of 204

Quoted 7 lines

Boot Regressions Detected:

arm:

    multi_v7_defconfig+CONFIG_PROVE_LOCKING=y:
        am335x-pepper:
            lab-baylibre-seattle: new failure (last pass: v4.10-21-gd23a9821d397)

This one is a new regression, and a first attempt at bisect was inconclusive.

Quoted 6 lines

Boot Failures Detected:

arm64:

defconfig+CONFIG_RANDOMIZE_BASE=y
alpine-v2-evp: 1 failed lab

This one appears to be a new board in the Free Electrons lab, which doesn't have a history of passing.

Quentin, Antoine: blacklist or fix?

Quoted 2 lines

apm-mustang: 1 failed lab
juno: 1 failed lab

These aren't new and have to do with broken boot firmware/UEFI that cannot cope with bigger kernels. The folks in the Linaro Cambridge lab are looking into upgrading the firmware.

Quoted 7 lines
Quoted 4 lines

arm:

    qcom_defconfig
        qcom-apq8064-cm-qs600: 1 failed lab
        qcom-apq8064-ifc6410: 1 failed lab

These also exist in v4.10 mainline and have been reported to qcom maintainer Andy Gross (cc'd).

Thanks for the analysis of all of these, much appreciated.

greg k-h