4.10.2-stable review
Subsystems (5)
Greg Kroah-Hartman
maintainerPATCH 155/167 dmaengine: ipu: Make sure the interrupt routine checks all interrupts.
In reply to Greg Kroah-Hartman4.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).
--- 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_du32 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);
Greg Kroah-Hartman
maintainerPATCH 156/167 xprtrdma: Fix Read chunk padding
In reply to Greg Kroah-Hartman4.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.
--- 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 *xdrif (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 *xdrreturn 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;
Greg Kroah-Hartman
maintainerPATCH 157/167 xprtrdma: Per-connection pad optimization
In reply to Greg Kroah-Hartman4.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.
--- 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;
Greg Kroah-Hartman
maintainerPATCH 158/167 xprtrdma: Disable pad optimization by default
In reply to Greg Kroah-Hartman4.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.
--- 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); }
Greg Kroah-Hartman
maintainerPATCH 159/167 xprtrdma: Reduce required number of send SGEs
In reply to Greg Kroah-Hartman4.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 ,
Greg Kroah-Hartman
maintainerPATCH 160/167 powerpc/xmon: Fix data-breakpoint
In reply to Greg Kroah-Hartman4.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_argrcu_read_lock (); bp =__this_cpu_read (bp_per_reg); -if (!bp) +if (!bp) { + rc =NOTIFY_DONE ; goto out; + } info =counter_arch_bp (bp);/*
Greg Kroah-Hartman
maintainerPATCH 161/167 powerpc/mm: Add MMU_FTR_KERNEL_RO to possible feature mask
In reply to Greg Kroah-Hartman4.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.
--- 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
Greg Kroah-Hartman
maintainerPATCH 162/167 powerpc/mm/hash: Always clear UPRT and Host Radix bits when setting up CPU
In reply to Greg Kroah-Hartman4.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.
--- 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
Greg Kroah-Hartman
maintainerPATCH 163/167 module: fix memory leak on early load_module() failures
In reply to Greg Kroah-Hartman4.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_infomod_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);
Greg Kroah-Hartman
maintainerPATCH 164/167 MIPS: IP22: Reformat inline assembler code to modern standards.
In reply to Greg Kroah-Hartman4.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(unsignedunsigned 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)); }
Greg Kroah-Hartman
maintainerPATCH 165/167 MIPS: IP22: Fix build error due to binutils 2.25 uselessnes.
In reply to Greg Kroah-Hartman4.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"
Greg Kroah-Hartman
maintainerPATCH 166/167 scsi: lpfc: Correct WQ creation for pagesize
In reply to Greg Kroah-Hartman4.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 0x1uint32_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 :
Greg Kroah-Hartman
maintainerPATCH 167/167 ceph: update readpages osd request according to size of pages
In reply to Greg Kroah-Hartman4.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 cepBUG_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);
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
Greg Kroah-Hartman
maintainerQuoted 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: 0Details are available at http://kerneltests.org/builders.
Thanks for testing all of these and letting me know.
greg k-h
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.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-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
Greg Kroah-Hartman
maintainerQuoted 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.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-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]
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 204Boot 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
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 204Boot 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
04992982b8f8caf6c54531a23d3f9c2bc4d0a7d8is the first bad commit commit04992982b8f8caf6c54531a23d3f9c2bc4d0a7d8Author: Theodore Ts'o <[email protected]> Date: Sat Feb 4 23:04:00 2017 -0500ext4: fix inline data error paths
commit
eb5efbcb762aee4b454b04f7115f73ccbcf8f0efupstream.The
write_end()function must always unlock the page and drop its ref count, even on an error.Signed-off-by Theodore Ts'o <[email protected]>Signed-off-by Greg Kroah-Hartman <[email protected]>Kevin
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:cdc1f9d24aac385a7fe4611d7b42f51e20f49cdbGit 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 204Boot 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
Greg Kroah-Hartman
maintainerQuoted 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 204Quoted 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 labThis 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 labThese aren't new and have to do with broken boot
firmware/UEFIthat 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 labThese 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