Skip to contentSkip to conversation

4.4.46-stable review

PATCH In review Greg Kroah-Hartman 4 participants 27 messages Jan 31, 2017 – Feb 10, 2017 Stable branch

lore
Share & tools
lore

Greg Kroah-Hartman

author maintainer
#0 lore raw

cover 4.4.46-stable review

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

Responses should be made by Thu Feb 2 05:36:16 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.4.46-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.4.y
and the diffstat can be found below.

thanks,

greg k-h

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

Greg Kroah-Hartman <[email protected]>

    Linux 4.4.46-rc1

David Rientjes <[email protected]>
mm, memcg: do not retry precharge charges

Andy Shevchenko <[email protected]>
platform/x86: intel_mid_powerbtn: Set IRQ_ONESHOT

Mika Westerberg <[email protected]>
pinctrl: broxton: Use correct PADCFGLOCK offset

Arnd Bergmann <[email protected]>
s5k4ecgx: select CRC32 helper

Kenneth Lee <[email protected]>
IB/umem: Release pid in error and ODP flow

Paolo Abeni <[email protected]>
IB/ipoib: move back IB LL address into the hard header

Ander Conselvan de Oliveira <[email protected]>
drm/i915: Don't leak edid in intel_crt_detect_ddc()

Kinglong Mee <[email protected]>
SUNRPC: cleanup ida information when removing sunrpc module

Benjamin Coddington <[email protected]>
NFSv4.0: always send mode in SETATTR after EXCLUSIVE4

Chuck Lever <[email protected]>
nfs: Don't increment lock sequence ID after NFS4ERR_MOVED

Helge Deller <[email protected]>
parisc: Don't use BITS_PER_LONG in userspace-exported swab.h header

Vineet Gupta <[email protected]>
ARC: [arcompact] handle unaligned access delay slot corner case

Vineet Gupta <[email protected]>
ARC: udelay: fix inline assembler by adding LP_COUNT to clobber list

Yegor Yefremov <[email protected]>
can: ti_hecc: add missing prepare and unprepare of the clock

Einar Jón <[email protected]>
can: c_can_pci: fix null-pointer-deref in c_can_start() - set device pointer

Martin Schwidefsky <[email protected]>
s390/ptrace: Preserve previous registers for short regset write

Jack Morgenstein <[email protected]>
RDMA/cma: Fix unknown symbol when CONFIG_IPV6 is not enabled

Arnd Bergmann <[email protected]>
ISDN: eicon: silence misleading array-bounds warning

Eric Dumazet <[email protected]>
sysctl: fix proc_doulongvec_ms_jiffies_minmax()

Vlastimil Babka <[email protected]>
mm/mempolicy.c: do not put mempolicy before using its nodemask

Takashi Iwai <[email protected]>
drm: Fix broken VT switch with video=1366x768 option

Dave Martin <[email protected]>
tile/ptrace: Preserve previous registers for short regset write

Kees Cook <[email protected]>
fbdev: color map copying bounds checking

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

Diffstat:

 Makefile                                       |  4 +-
 arch/arc/include/asm/delay.h                   |  4 +-
 arch/arc/kernel/unaligned.c                    |  3 +-
 arch/parisc/include/asm/bitops.h               |  8 +++-
 arch/parisc/include/uapi/asm/bitsperlong.h     |  2 -
 arch/parisc/include/uapi/asm/swab.h            |  5 ++-
 arch/s390/kernel/ptrace.c                      |  8 ++++
 arch/tile/kernel/ptrace.c                      |  2 +-
 drivers/gpu/drm/drm_modes.c                    |  7 ++++
 drivers/gpu/drm/i915/intel_crt.c               |  9 +++--
 drivers/infiniband/core/cma.c                  |  3 +-
 drivers/infiniband/core/umem.c                 |  2 +
 drivers/infiniband/ulp/ipoib/ipoib.h           | 20 +++++++---
 drivers/infiniband/ulp/ipoib/ipoib_cm.c        | 15 +++----
 drivers/infiniband/ulp/ipoib/ipoib_ib.c        | 12 +++---
 drivers/infiniband/ulp/ipoib/ipoib_main.c      | 54 ++++++++++++++++----------
 drivers/infiniband/ulp/ipoib/ipoib_multicast.c |  6 ++-
 drivers/isdn/hardware/eicon/message.c          |  3 +-
 drivers/media/i2c/Kconfig                      |  1 +
 drivers/net/can/c_can/c_can_pci.c              |  1 +
 drivers/net/can/ti_hecc.c                      | 16 ++++++--
 drivers/pinctrl/intel/pinctrl-broxton.c        |  2 +-
 drivers/platform/x86/intel_mid_powerbtn.c      |  2 +-
 drivers/video/fbdev/core/fbcmap.c              | 26 +++++++------
 fs/nfs/nfs4proc.c                              |  3 +-
 include/linux/nfs4.h                           |  3 +-
 include/linux/sunrpc/clnt.h                    |  1 +
 kernel/sysctl.c                                |  1 +
 mm/memcontrol.c                                |  4 +-
 mm/mempolicy.c                                 |  2 +-
 net/sunrpc/clnt.c                              |  5 +++
 net/sunrpc/sunrpc_syms.c                       |  1 +
 32 files changed, 153 insertions(+), 82 deletions(-)
author maintainer
#1 lore raw

PATCH 1/23 fbdev: color map copying bounds checking

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

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

From: Kees Cook <[email protected]>

commit 2dc705a9930b4806250fbf5a76e55266e59389f2 upstream.

Copying color maps to userspace doesn't check the value of to->start, which will cause kernel heap buffer OOB read due to signedness wraps.

CVE-2016-8405

---
 drivers/video/fbdev/core/fbcmap.c |   26 ++++++++++++++------------
 1 file changed, 14 insertions(+), 12 deletions(-)
drivers/video/fbdev/core/fbcmap.c +14 -12
@@ -163,17 +163,18 @@ void fb_dealloc_cmap(struct fb_cmap *cma
 
 int fb_copy_cmap(const struct fb_cmap *from, struct fb_cmap *to)
 {
-	int tooff = 0, fromoff = 0;
-	int size;
+	unsigned int tooff = 0, fromoff = 0;
+	size_t size;
 
 	if (to->start > from->start)
 		fromoff = to->start - from->start;
 	else
 		tooff = from->start - to->start;
-	size = to->len - tooff;
-	if (size > (int) (from->len - fromoff))
-		size = from->len - fromoff;
-	if (size <= 0)
+	if (fromoff >= from->len || tooff >= to->len)
+		return -EINVAL;
+
+	size = min_t(size_t, to->len - tooff, from->len - fromoff);
+	if (size == 0)
 		return -EINVAL;
 	size *= sizeof(u16);
 
@@ -187,17 +188,18 @@ int fb_copy_cmap(const struct fb_cmap *f
 
 int fb_cmap_to_user(const struct fb_cmap *from, struct fb_cmap_user *to)
 {
-	int tooff = 0, fromoff = 0;
-	int size;
+	unsigned int tooff = 0, fromoff = 0;
+	size_t size;
 
 	if (to->start > from->start)
 		fromoff = to->start - from->start;
 	else
 		tooff = from->start - to->start;
-	size = to->len - tooff;
-	if (size > (int) (from->len - fromoff))
-		size = from->len - fromoff;
-	if (size <= 0)
+	if (fromoff >= from->len || tooff >= to->len)
+		return -EINVAL;
+
+	size = min_t(size_t, to->len - tooff, from->len - fromoff);
+	if (size == 0)
 		return -EINVAL;
 	size *= sizeof(u16);
 
author maintainer
#2 lore raw

PATCH 2/23 tile/ptrace: Preserve previous registers for short regset write

In reply to Greg Kroah-Hartman

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

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

From: Dave Martin <[email protected]>

commit fd7c99142d77dc4a851879a66715abf12a3193fb upstream.

Ensure that if userspace supplies insufficient data to PTRACE_SETREGSET to fill all the registers, the thread's old registers are preserved.

---
 arch/tile/kernel/ptrace.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
arch/tile/kernel/ptrace.c +1 -1
@@ -111,7 +111,7 @@ static int tile_gpr_set(struct task_stru
 			  const void *kbuf, const void __user *ubuf)
 {
 	int ret;
-	struct pt_regs regs;
+	struct pt_regs regs = *task_pt_regs(target);
 
 	ret = user_regset_copyin(&pos, &count, &kbuf, &ubuf, &regs, 0,
 				 sizeof(regs));
author maintainer
#3 lore raw

PATCH 4/23 mm/mempolicy.c: do not put mempolicy before using its nodemask

In reply to Greg Kroah-Hartman

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

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

From: Vlastimil Babka <[email protected]>

commit d51e9894d27492783fc6d1b489070b4ba66ce969 upstream.

Since commit be97a41b291e ("mm/mempolicy.c: merge alloc_hugepage_vma to alloc_pages_vma") alloc_pages_vma() can potentially free a mempolicy by mpol_cond_put() before accessing the embedded nodemask by __alloc_pages_nodemask(). The commit log says it's so "we can use a single exit path within the function" but that's clearly wrong. We can still do that when doing mpol_cond_put() after the allocation attempt.

Make sure the mempolicy is not freed prematurely, otherwise __alloc_pages_nodemask() can end up using a bogus nodemask, which could lead e.g. to premature OOM.

---
 mm/mempolicy.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
mm/mempolicy.c +1 -1
@@ -2006,8 +2006,8 @@ retry_cpuset:
 
 	nmask = policy_nodemask(gfp, pol);
 	zl = policy_zonelist(gfp, pol, node);
-	mpol_cond_put(pol);
 	page = __alloc_pages_nodemask(gfp, order, zl, nmask);
+	mpol_cond_put(pol);
 out:
 	if (unlikely(!page && read_mems_allowed_retry(cpuset_mems_cookie)))
 		goto retry_cpuset;
author maintainer
#4 lore raw

PATCH 5/23 sysctl: fix proc_doulongvec_ms_jiffies_minmax()

In reply to Greg Kroah-Hartman

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

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

From: Eric Dumazet <[email protected]>

commit ff9f8a7cf935468a94d9927c68b00daae701667e upstream.

We perform the conversion between kernel jiffies and ms only when exporting kernel value to user space.

We need to do the opposite operation when value is written by user.

Only matters when HZ != 1000

---
 kernel/sysctl.c |    1 +
 1 file changed, 1 insertion(+)
kernel/sysctl.c +1 -0
@@ -2414,6 +2414,7 @@ static int __do_proc_doulongvec_minmax(v
 				break;
 			if (neg)
 				continue;
+			val = convmul * val / convdiv;
 			if ((min && val < *min) || (max && val > *max))
 				continue;
 			*i = val;
author maintainer
#5 lore raw

PATCH 6/23 ISDN: eicon: silence misleading array-bounds warning

In reply to Greg Kroah-Hartman

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

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

From: Arnd Bergmann <[email protected]>

commit 950eabbd6ddedc1b08350b9169a6a51b130ebaaf upstream.

With some gcc versions, we get a warning about the eicon driver, and that currently shows up as the only remaining warning in one of the build bots:

In file included from ../drivers/isdn/hardware/eicon/message.c:30:0:
eicon/message.c: In function 'mixer_notify_update':
eicon/platform.h:333:18: warning: array subscript is above array bounds [-Warray-bounds]

The code is easily changed to open-code the unusual PUT_WORD() line causing this to avoid the warning.

---
 drivers/isdn/hardware/eicon/message.c |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)
drivers/isdn/hardware/eicon/message.c +2 -1
@@ -11304,7 +11304,8 @@ static void mixer_notify_update(PLCI *pl
 				((CAPI_MSG *) msg)->header.ncci = 0;
 				((CAPI_MSG *) msg)->info.facility_req.Selector = SELECTOR_LINE_INTERCONNECT;
 				((CAPI_MSG *) msg)->info.facility_req.structs[0] = 3;
-				PUT_WORD(&(((CAPI_MSG *) msg)->info.facility_req.structs[1]), LI_REQ_SILENT_UPDATE);
+				((CAPI_MSG *) msg)->info.facility_req.structs[1] = LI_REQ_SILENT_UPDATE & 0xff;
+				((CAPI_MSG *) msg)->info.facility_req.structs[2] = LI_REQ_SILENT_UPDATE >> 8;
 				((CAPI_MSG *) msg)->info.facility_req.structs[3] = 0;
 				w = api_put(notify_plci->appl, (CAPI_MSG *) msg);
 				if (w != _QUEUE_FULL)
author maintainer
#6 lore raw

PATCH 7/23 RDMA/cma: Fix unknown symbol when CONFIG_IPV6 is not enabled

In reply to Greg Kroah-Hartman

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

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

From: Jack Morgenstein <[email protected]>

commit b4cfe3971f6eab542dd7ecc398bfa1aeec889934 upstream.

If IPV6 has not been enabled in the underlying kernel, we must avoid calling IPV6 procedures in rdma_cm.ko.

This requires using "IS_ENABLED(CONFIG_IPV6)" in "if" statements surrounding any code which calls external IPV6 procedures.

In the instance fixed here, procedure cma_bind_addr() called ipv6_addr_type() -- which resulted in calling external procedure __ipv6_addr_type().

Fixes 6c26a77124ff ("RDMA/cma: fix IPv6 address resolution")
Cc Spencer Baugh <[email protected]>
---
 drivers/infiniband/core/cma.c |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)
drivers/infiniband/core/cma.c +2 -1
@@ -2578,7 +2578,8 @@ static int cma_bind_addr(struct rdma_cm_
 	if (!src_addr || !src_addr->sa_family) {
 		src_addr = (struct sockaddr *) &id->route.addr.src_addr;
 		src_addr->sa_family = dst_addr->sa_family;
-		if (dst_addr->sa_family == AF_INET6) {
+		if (IS_ENABLED(CONFIG_IPV6) &&
+		    dst_addr->sa_family == AF_INET6) {
 			struct sockaddr_in6 *src_addr6 = (struct sockaddr_in6 *) src_addr;
 			struct sockaddr_in6 *dst_addr6 = (struct sockaddr_in6 *) dst_addr;
 			src_addr6->sin6_scope_id = dst_addr6->sin6_scope_id;
author maintainer
#7 lore raw

PATCH 8/23 s390/ptrace: Preserve previous registers for short regset write

In reply to Greg Kroah-Hartman

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

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

From: Martin Schwidefsky <[email protected]>

commit 9dce990d2cf57b5ed4e71a9cdbd7eae4335111ff upstream.

Ensure that if userspace supplies insufficient data to PTRACE_SETREGSET to fill all the registers, the thread's old registers are preserved.

convert_vx_to_fp() is adapted to handle only a specified number of registers rather than unconditionally handling all of them: other callers of this function are adapted appropriately.

Based on an initial patch by Dave Martin.

---
 arch/s390/kernel/ptrace.c |    8 ++++++++
 1 file changed, 8 insertions(+)
arch/s390/kernel/ptrace.c +8 -0
@@ -963,6 +963,11 @@ static int s390_fpregs_set(struct task_s
 	if (target == current)
 		save_fpu_regs();
 
+	if (MACHINE_HAS_VX)
+		convert_vx_to_fp(fprs, target->thread.fpu.vxrs);
+	else
+		memcpy(&fprs, target->thread.fpu.fprs, sizeof(fprs));
+
 	/* If setting FPC, must validate it first. */
 	if (count > 0 && pos < offsetof(s390_fp_regs, fprs)) {
 		u32 ufpc[2] = { target->thread.fpu.fpc, 0 };
@@ -1067,6 +1072,9 @@ static int s390_vxrs_low_set(struct task
 	if (target == current)
 		save_fpu_regs();
 
+	for (i = 0; i < __NUM_VXRS_LOW; i++)
+		vxrs[i] = *((__u64 *)(target->thread.fpu.vxrs + i) + 1);
+
 	rc = user_regset_copyin(&pos, &count, &kbuf, &ubuf, vxrs, 0, -1);
 	if (rc == 0)
 		for (i = 0; i < __NUM_VXRS_LOW; i++)
author maintainer
#8 lore raw

PATCH 10/23 can: ti_hecc: add missing prepare and unprepare of the clock

In reply to Greg Kroah-Hartman

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

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

From: Yegor Yefremov <[email protected]>

commit befa60113ce7ea270cb51eada28443ca2756f480 upstream.

In order to make the driver work with the common clock framework, this patch converts the clk_enable()/clk_disable() to clk_prepare_enable()/clk_disable_unprepare().

Also add error checking for clk_prepare_enable().

---
 drivers/net/can/ti_hecc.c |   16 ++++++++++++----
 1 file changed, 12 insertions(+), 4 deletions(-)
drivers/net/can/ti_hecc.c +12 -4
@@ -948,7 +948,12 @@ static int ti_hecc_probe(struct platform
 	netif_napi_add(ndev, &priv->napi, ti_hecc_rx_poll,
 		HECC_DEF_NAPI_WEIGHT);
 
-	clk_enable(priv->clk);
+	err = clk_prepare_enable(priv->clk);
+	if (err) {
+		dev_err(&pdev->dev, "clk_prepare_enable() failed\n");
+		goto probe_exit_clk;
+	}
+
 	err = register_candev(ndev);
 	if (err) {
 		dev_err(&pdev->dev, "register_candev() failed\n");
@@ -981,7 +986,7 @@ static int ti_hecc_remove(struct platfor
 	struct ti_hecc_priv *priv = netdev_priv(ndev);
 
 	unregister_candev(ndev);
-	clk_disable(priv->clk);
+	clk_disable_unprepare(priv->clk);
 	clk_put(priv->clk);
 	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
 	iounmap(priv->base);
@@ -1006,7 +1011,7 @@ static int ti_hecc_suspend(struct platfo
 	hecc_set_bit(priv, HECC_CANMC, HECC_CANMC_PDR);
 	priv->can.state = CAN_STATE_SLEEPING;
 
-	clk_disable(priv->clk);
+	clk_disable_unprepare(priv->clk);
 
 	return 0;
 }
@@ -1015,8 +1020,11 @@ static int ti_hecc_resume(struct platfor
 {
 	struct net_device *dev = platform_get_drvdata(pdev);
 	struct ti_hecc_priv *priv = netdev_priv(dev);
+	int err;
 
-	clk_enable(priv->clk);
+	err = clk_prepare_enable(priv->clk);
+	if (err)
+		return err;
 
 	hecc_clear_bit(priv, HECC_CANMC, HECC_CANMC_PDR);
 	priv->can.state = CAN_STATE_ERROR_ACTIVE;
author maintainer
#9 lore raw

PATCH 11/23 ARC: udelay: fix inline assembler by adding LP_COUNT to clobber list

In reply to Greg Kroah-Hartman

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

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

From: Vineet Gupta <[email protected]>

commit 36425cd67052e3becf325fd4d3ba5691791ef7e4 upstream.

commit 3c7c7a2fc8811bc ("ARC: Don't use "+l" inline asm constraint") modified the inline assembly to setup LP_COUNT register manually and NOT rely on gcc to do it (with the +l inline assembler contraint hint, now being retired in the compiler)

However the fix was flawed as we didn't add LP_COUNT to asm clobber list, meaning gcc doesn't know that LP_COUNT or zero-delay-loops are in action in the inline asm.

This resulted in some fun - as nested ZOL loops were being generared

| mov lp_count,250000 ;16 # tmp235,
| lp .L__GCC__LP14 #		<======= OUTER LOOP (gcc generated)
|   .L14:
|   ld r2, [r5] # MEM[(volatile u32 *)prephitmp_43], w
|   dmb 1
|   breq r2, -1, @.L21 #, w,,
|   bbit0 r2,1,@.L13 # w,,
|   ld r4,[r7] ;25 # loops_per_jiffy, loops_per_jiffy
|   mpymu r3,r4,r6 #, loops_per_jiffy, tmp234
|
|   mov lp_count, r3 #		 <====== INNER LOOP (from inline asm)
|   lp 1f
| 	 nop
|   1:
|   nop_s
| .L__GCC__LP14: ; loop end, start is @.L14 #,

This caused issues with drivers relying on sane behaviour of udelay friends.

With LP_COUNT added to clobber list, gcc doesn't generate the outer loop in say above case.

Addresses STAR 9001146134

Fixes 3c7c7a2fc8811bc ("ARC: Don't use "+l" inline asm constraint")
---
 arch/arc/include/asm/delay.h |    4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)
arch/arc/include/asm/delay.h +3 -1
@@ -26,7 +26,9 @@ static inline void __delay(unsigned long
 	"	lp  1f			\n"
 	"	nop			\n"
 	"1:				\n"
-	: : "r"(loops));
+	:
+        : "r"(loops)
+        : "lp_count");
 }
 
 extern void __bad_udelay(void);
author maintainer
#10 lore raw

PATCH 12/23 ARC: [arcompact] handle unaligned access delay slot corner case

In reply to Greg Kroah-Hartman

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

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

From: Vineet Gupta <[email protected]>

commit 9aed02feae57bf7a40cb04ea0e3017cb7a998db4 upstream.

After emulating an unaligned access in delay slot of a branch, we pretend as the delay slot never happened - so return back to actual branch target (or next PC if branch was not taken).

Curently we did this by handling STATUS32.DE, we also need to clear the BTA.T bit, which is disregarded when returning from original misaligned exception, but could cause weirdness if it took the interrupt return path (in case interrupt was acive too)

One ARC700 customer ran into this when enabling unaligned access fixup for kernel mode accesses as well

---
 arch/arc/kernel/unaligned.c |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)
arch/arc/kernel/unaligned.c +2 -1
@@ -241,8 +241,9 @@ int misaligned_fixup(unsigned long addre
 	if (state.fault)
 		goto fault;
 
+	/* clear any remanants of delay slot */
 	if (delay_mode(regs)) {
-		regs->ret = regs->bta;
+		regs->ret = regs->bta ~1U;
 		regs->status32 &= ~STATUS_DE_MASK;
 	} else {
 		regs->ret += state.instr_len;
#11 lore raw

Re: [PATCH 4.4 12/23] ARC: [arcompact] handle unaligned access delay slot corner case

Quoted 35 lines · Greg Kroah-Hartman

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

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

From: Vineet Gupta <[email protected]>

commit 9aed02feae57bf7a40cb04ea0e3017cb7a998db4 upstream.

After emulating an unaligned access in delay slot of a branch, we pretend as the delay slot never happened - so return back to actual branch target (or next PC if branch was not taken).

Curently we did this by handling STATUS32.DE, we also need to clear the BTA.T bit, which is disregarded when returning from original misaligned exception, but could cause weirdness if it took the interrupt return path (in case interrupt was acive too)

One ARC700 customer ran into this when enabling unaligned access fixup for kernel mode accesses as well

---
 arch/arc/kernel/unaligned.c |    3 ++-

 1 file changed, 2 insertions(+), 1 deletion(-)
arch/arc/kernel/unaligned.c +0 -0
@@ -241,8 +241,9 @@ int misaligned_fixup(unsigned long addre
  	if (state.fault)
  		goto fault;

arch/arc/kernel/unaligned.c +1 -0
+	/* clear any remanants of delay slot */

  if (delay_mode(regs)) {

arch/arc/kernel/unaligned.c int misaligned_fixup(unsigned long addre · line 246

Quoted 2 lines
arch/arc/kernel/unaligned.c +1 -1
-		regs->ret = regs->bta;
+		regs->ret = regs->bta ~1U;

Unless you're doing something terrible with macros, this is missing an & operator. I doubt this even compiled (looks like it's only used in some ARC configurations).

Ben.

Quoted 3 lines

  regs->status32 &= ~STATUS_DE_MASK; } else {
  regs->ret += state.instr_len;

Signature · 2 lines
Ben Hutchings
It's easier to fight for one's principles than to live up to them.
author maintainer
#12 lore raw

Re: [PATCH 4.4 12/23] ARC: [arcompact] handle unaligned access delay slot corner case

Quoted 28 lines · Ben Hutchings
Quoted 27 lines · Greg Kroah-Hartman

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

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

From: Vineet Gupta <[email protected]>

commit 9aed02feae57bf7a40cb04ea0e3017cb7a998db4 upstream.

After emulating an unaligned access in delay slot of a branch, we pretend as the delay slot never happened - so return back to actual branch target (or next PC if branch was not taken).

Curently we did this by handling STATUS32.DE, we also need to clear the BTA.T bit, which is disregarded when returning from original misaligned exception, but could cause weirdness if it took the interrupt return path (in case interrupt was acive too)

One ARC700 customer ran into this when enabling unaligned access fixup for kernel mode accesses as well

---
�arch/arc/kernel/unaligned.c |����3 ++-
�1 file changed, 2 insertions(+), 1 deletion(-)

Quoted 14 lines

arch/arc/kernel/unaligned.c int misaligned_fixup(unsigned long addre · line 246

Quoted 10 lines
arch/arc/kernel/unaligned.c +0 -0
@@ -241,8 +241,9 @@ int misaligned_fixup(unsigned long addre
 �	if (state.fault)
 �		goto fault;

�

arch/arc/kernel/unaligned.c +1 -0
+	/* clear any remanants of delay slot */

� if (delay_mode(regs)) {

arch/arc/kernel/unaligned.c +1 -1
-		regs->ret = regs->bta;
+		regs->ret = regs->bta ~1U;

Unless you're doing something terrible with macros, this is missing an & operator. I doubt this even compiled (looks like it's only used in some ARC configurations).

Hah, that's funny, it's obvious it isn't part of anyone's build tests, so I guess it must be just fine :)

thanks,

greg k-h

author maintainer
#13 lore raw

Re: [PATCH 4.4 12/23] ARC: [arcompact] handle unaligned access delay slot corner case

Quoted 44 lines · Greg Kroah-Hartman
Quoted 28 lines · Ben Hutchings
Quoted 27 lines · Greg Kroah-Hartman

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

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

From: Vineet Gupta <[email protected]>

commit 9aed02feae57bf7a40cb04ea0e3017cb7a998db4 upstream.

After emulating an unaligned access in delay slot of a branch, we pretend as the delay slot never happened - so return back to actual branch target (or next PC if branch was not taken).

Curently we did this by handling STATUS32.DE, we also need to clear the BTA.T bit, which is disregarded when returning from original misaligned exception, but could cause weirdness if it took the interrupt return path (in case interrupt was acive too)

One ARC700 customer ran into this when enabling unaligned access fixup for kernel mode accesses as well

---
�arch/arc/kernel/unaligned.c |����3 ++-
�1 file changed, 2 insertions(+), 1 deletion(-)

Quoted 14 lines

arch/arc/kernel/unaligned.c int misaligned_fixup(unsigned long addre · line 246

Quoted 10 lines
arch/arc/kernel/unaligned.c +0 -0
@@ -241,8 +241,9 @@ int misaligned_fixup(unsigned long addre
 �	if (state.fault)
 �		goto fault;

�

arch/arc/kernel/unaligned.c +1 -0
+	/* clear any remanants of delay slot */

� if (delay_mode(regs)) {

arch/arc/kernel/unaligned.c +1 -1
-		regs->ret = regs->bta;
+		regs->ret = regs->bta ~1U;

Unless you're doing something terrible with macros, this is missing an & operator. I doubt this even compiled (looks like it's only used in some ARC configurations).

Quoted 2 lines

Hah, that's funny, it's obvious it isn't part of anyone's build tests, so I guess it must be just fine :)

Ah, nevermind, commit a524c218bc94c705886a0e0fedeee45d1931da32 that just went into Linus's tree this week fixes this...

greg k-h

author maintainer
#14 lore raw

PATCH 13/23 parisc: Dont use BITS_PER_LONG in userspace-exported swab.h header

In reply to Greg Kroah-Hartman

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

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

From: Helge Deller <[email protected]>

commit 2ad5d52d42810bed95100a3d912679d8864421ec upstream.

In swab.h the "#if BITS_PER_LONG > 32" breaks compiling userspace programs if BITS_PER_LONG is #defined by userspace with the sizeof() compiler builtin.

Solve this problem by using __BITS_PER_LONG instead. Since we now #include asm/bitsperlong.h avoid further potential userspace pollution by moving the #define of SHIFT_PER_LONG to bitops.h which is not exported to userspace.

This patch unbreaks compiling qemu on hppa/parisc.

---
 arch/parisc/include/asm/bitops.h           |    8 +++++++-
 arch/parisc/include/uapi/asm/bitsperlong.h |    2 --
 arch/parisc/include/uapi/asm/swab.h        |    5 +++--
 3 files changed, 10 insertions(+), 5 deletions(-)
arch/parisc/include/asm/bitops.h +7 -1
@@ -6,7 +6,7 @@
 #endif
 
 #include <linux/compiler.h>
-#include <asm/types.h>		/* for BITS_PER_LONG/SHIFT_PER_LONG */
+#include <asm/types.h>
 #include <asm/byteorder.h>
 #include <asm/barrier.h>
 #include <linux/atomic.h>
@@ -17,6 +17,12 @@
  * to include/asm-i386/bitops.h or kerneldoc
  */
 
+#if __BITS_PER_LONG == 64
+#define SHIFT_PER_LONG 6
+#else
+#define SHIFT_PER_LONG 5
+#endif
+
 #define CHOP_SHIFTCOUNT(x) (((unsigned long) (x)) & (BITS_PER_LONG - 1))
 
 
arch/parisc/include/uapi/asm/bitsperlong.h +0 -2
@@ -3,10 +3,8 @@
 
 #if defined(__LP64__)
 #define __BITS_PER_LONG 64
-#define SHIFT_PER_LONG 6
 #else
 #define __BITS_PER_LONG 32
-#define SHIFT_PER_LONG 5
 #endif
 
 #include <asm-generic/bitsperlong.h>
arch/parisc/include/uapi/asm/swab.h +3 -2
@@ -1,6 +1,7 @@
 #ifndef _PARISC_SWAB_H
 #define _PARISC_SWAB_H
 
+#include <asm/bitsperlong.h>
 #include <linux/types.h>
 #include <linux/compiler.h>
 
@@ -38,7 +39,7 @@ static inline __attribute_const__ __u32
 }
 #define __arch_swab32 __arch_swab32
 
-#if BITS_PER_LONG > 32
+#if __BITS_PER_LONG > 32
 /*
 ** From "PA-RISC 2.0 Architecture", HP Professional Books.
 ** See Appendix I page 8 , "Endian Byte Swapping".
@@ -61,6 +62,6 @@ static inline __attribute_const__ __u64
 	return x;
 }
 #define __arch_swab64 __arch_swab64
-#endif /* BITS_PER_LONG > 32 */
+#endif /* __BITS_PER_LONG > 32 */
 
 #endif /* _PARISC_SWAB_H */
author maintainer
#15 lore raw

PATCH 14/23 nfs: Dont increment lock sequence ID after NFS4ERR_MOVED

In reply to Greg Kroah-Hartman

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

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

From: Chuck Lever <[email protected]>

commit 059aa734824165507c65fd30a55ff000afd14983 upstream.

Xuan Qi reports that the Linux NFSv4 client failed to lock a file that was migrated. The steps he observed on the wire:

1. The client sent a LOCK request to the source server
2. The source server replied NFS4ERR_MOVED
3. The client switched to the destination server
4. The client sent the same LOCK request to the destination server with a bumped lock sequence ID
5. The destination server rejected the LOCK request with NFS4ERR_BAD_SEQID

RFC 3530 section 8.1.5 provides a list of NFS errors which do not bump a lock sequence ID.

However, RFC 3530 is now obsoleted by RFC 7530. In RFC 7530 section 9.1.7, this list has been updated by the addition of NFS4ERR_MOVED.

---
 include/linux/nfs4.h |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)
include/linux/nfs4.h +2 -1
@@ -266,7 +266,7 @@ enum nfsstat4 {
 
 static inline bool seqid_mutating_err(u32 err)
 {
-	/* rfc 3530 section 8.1.5: */
+	/* See RFC 7530, section 9.1.7 */
 	switch (err) {
 	case NFS4ERR_STALE_CLIENTID:
 	case NFS4ERR_STALE_STATEID:
@@ -275,6 +275,7 @@ static inline bool seqid_mutating_err(u3
 	case NFS4ERR_BADXDR:
 	case NFS4ERR_RESOURCE:
 	case NFS4ERR_NOFILEHANDLE:
+	case NFS4ERR_MOVED:
 		return false;
 	};
 	return true;
author maintainer
#16 lore raw

PATCH 15/23 NFSv4.0: always send mode in SETATTR after EXCLUSIVE4

In reply to Greg Kroah-Hartman

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

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

From: Benjamin Coddington <[email protected]>

commit a430607b2ef7c3be090f88c71cfcb1b3988aa7c0 upstream.

Some nfsv4.0 servers may return a mode for the verifier following an open with EXCLUSIVE4 createmode, but this does not mean the client should skip setting the mode in the following SETATTR. It should only do that for EXCLUSIVE4_1 or UNGAURDED createmode.

Fixes 5334c5bdac92 ("NFS: Send attributes in OPEN request for NFS4_CREATE_EXCLUSIVE4_1")
---
 fs/nfs/nfs4proc.c |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)
fs/nfs/nfs4proc.c +2 -1
@@ -2422,7 +2422,8 @@ static inline void nfs4_exclusive_attrse
 		sattr->ia_valid |= ATTR_MTIME;
 
 	/* Except MODE, it seems harmless of setting twice. */
-	if ((attrset[1] & FATTR4_WORD1_MODE))
+	if (opendata->o_arg.createmode != NFS4_CREATE_EXCLUSIVE &&
+		attrset[1] & FATTR4_WORD1_MODE)
 		sattr->ia_valid &= ~ATTR_MODE;
 
 	if (attrset[2] & FATTR4_WORD2_SECURITY_LABEL)
author maintainer
#17 lore raw

PATCH 16/23 SUNRPC: cleanup ida information when removing sunrpc module

In reply to Greg Kroah-Hartman

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

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

From: Kinglong Mee <[email protected]>

commit c929ea0b910355e1876c64431f3d5802f95b3d75 upstream.

After removing sunrpc module, I get many kmemleak information as, unreferenced object 0xffff88003316b1e0 (size 544):
comm "gssproxy", pid 2148, jiffies 4294794465 (age 4200.081s) hex dump (first 32 bytes):

    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
  backtrace:
    [<ffffffffb0cfb58a>] kmemleak_alloc+0x4a/0xa0
    [<ffffffffb03507fe>] kmem_cache_alloc+0x15e/0x1f0
    [<ffffffffb0639baa>] ida_pre_get+0xaa/0x150
    [<ffffffffb0639cfd>] ida_simple_get+0xad/0x180
    [<ffffffffc06054fb>] nlmsvc_lookup_host+0x4ab/0x7f0 [lockd]
    [<ffffffffc0605e1d>] lockd+0x4d/0x270 [lockd]
    [<ffffffffc06061e5>] param_set_timeout+0x55/0x100 [lockd]
    [<ffffffffc06cba24>] svc_defer+0x114/0x3f0 [sunrpc]
    [<ffffffffc06cbbe7>] svc_defer+0x2d7/0x3f0 [sunrpc]
    [<ffffffffc06c71da>] rpc_show_info+0x8a/0x110 [sunrpc]
    [<ffffffffb044a33f>] proc_reg_write+0x7f/0xc0
    [<ffffffffb038e41f>] __vfs_write+0xdf/0x3c0
    [<ffffffffb0390f1f>] vfs_write+0xef/0x240
    [<ffffffffb0392fbd>] SyS_write+0xad/0x130
    [<ffffffffb0d06c37>] entry_SYSCALL_64_fastpath+0x1a/0xa9
    [<ffffffffffffffff>] 0xffffffffffffffff

I found, the ida information (dynamic memory) isn't cleanup.

Fixes 2f048db4680a ("SUNRPC: Add an identifier for struct rpc_clnt")
---
 include/linux/sunrpc/clnt.h |    1 +
 net/sunrpc/clnt.c           |    5 +++++
 net/sunrpc/sunrpc_syms.c    |    1 +
 3 files changed, 7 insertions(+)
include/linux/sunrpc/clnt.h +1 -0
@@ -180,5 +180,6 @@ const char	*rpc_peeraddr2str(struct rpc_
 int		rpc_localaddr(struct rpc_clnt *, struct sockaddr *, size_t);
 
 const char *rpc_proc_name(const struct rpc_task *task);
+void rpc_cleanup_clids(void);
 #endif /* __KERNEL__ */
 #endif /* _LINUX_SUNRPC_CLNT_H */
net/sunrpc/clnt.c +5 -0
@@ -337,6 +337,11 @@ out:
 
 static DEFINE_IDA(rpc_clids);
 
+void rpc_cleanup_clids(void)
+{
+	ida_destroy(&rpc_clids);
+}
+
 static int rpc_alloc_clid(struct rpc_clnt *clnt)
 {
 	int clid;
net/sunrpc/sunrpc_syms.c +1 -0
@@ -119,6 +119,7 @@ out:
 static void __exit
 cleanup_sunrpc(void)
 {
+	rpc_cleanup_clids();
 	rpcauth_remove_module();
 	cleanup_socket_xprt();
 	svc_cleanup_xprt_sock();
author maintainer
#18 lore raw

PATCH 17/23 drm/i915: Dont leak edid in intel_crt_detect_ddc()

In reply to Greg Kroah-Hartman

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

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

From: Ander Conselvan de Oliveira <[email protected]>

commit c34f078675f505c4437919bb1897b1351f16a050 upstream.

In the path where intel_crt_detect_ddc() detects a CRT, if would return true without freeing the edid.

Fixes a2bd1f541f19 ("drm/i915: check whether we actually received an edid in detect_ddc")
Cc Chris Wilson <[email protected]>
Cc Daniel Vetter <[email protected]>
Cc Daniel Vetter <[email protected]>
Cc Jani Nikula <[email protected]>
(cherry picked from commit c96b63a6a7ac4bd670ec2e663793a9a31418b790)
---
 drivers/gpu/drm/i915/intel_crt.c |    9 +++++----
 1 file changed, 5 insertions(+), 4 deletions(-)
drivers/gpu/drm/i915/intel_crt.c +5 -4
@@ -445,6 +445,7 @@ static bool intel_crt_detect_ddc(struct
 	struct drm_i915_private *dev_priv = crt->base.base.dev->dev_private;
 	struct edid *edid;
 	struct i2c_adapter *i2c;
+	bool ret = false;
 
 	BUG_ON(crt->base.type != INTEL_OUTPUT_ANALOG);
 
@@ -461,17 +462,17 @@ static bool intel_crt_detect_ddc(struct
 		 */
 		if (!is_digital) {
 			DRM_DEBUG_KMS("CRT detected via DDC:0x50 [EDID]\n");
-			return true;
+			ret = true;
+		} else {
+			DRM_DEBUG_KMS("CRT not detected via DDC:0x50 [EDID reports a digital panel]\n");
 		}
-
-		DRM_DEBUG_KMS("CRT not detected via DDC:0x50 [EDID reports a digital panel]\n");
 	} else {
 		DRM_DEBUG_KMS("CRT not detected via DDC:0x50 [no valid EDID found]\n");
 	}
 
 	kfree(edid);
 
-	return false;
+	return ret;
 }
 
 static enum drm_connector_status

_______________________________________________
Intel-gfx mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

author maintainer
#19 lore raw

PATCH 18/23 IB/ipoib: move back IB LL address into the hard header

In reply to Greg Kroah-Hartman

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

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

From: Paolo Abeni <[email protected]>

commit fc791b6335152c5278dc4a4991bcb2d329f806f9 upstream.

After the commit 9207f9d45b0a ("net: preserve IP control block during GSO segmentation"), the GSO CB and the IPoIB CB conflict. That destroy the IPoIB address information cached there, causing a severe performance regression, as better described here:

http://marc.info/?l=linux-kernel&m=146787279825501&w=2

This change moves the data cached by the IPoIB driver from the skb control lock into the IPoIB hard header, as done before the commit 936d7de3d736 ("IPoIB: Stop lying about hard_header_len and use skb->cb to stash LL addresses").
In order to avoid GRO issue, on packet reception, the IPoIB driver stash into the skb a dummy pseudo header, so that the received packets have actually a hard header matching the declared length. To avoid changing the connected mode maximum mtu, the allocated head buffer size is increased by the pseudo header length.

After this commit, IPoIB performances are back to pre-regression value.

v2 -> v3: rebased
v1 -> v2: avoid changing the max mtu, increasing the head buf size

Fixes 9207f9d45b0a ("net: preserve IP control block during GSO segmentation")
Cc Vasiliy Tolstov <[email protected]>
Cc Nikolay Borisov <[email protected]>
Cc Doug Ledford <[email protected]>
---
 drivers/infiniband/ulp/ipoib/ipoib.h           |   20 ++++++---
 drivers/infiniband/ulp/ipoib/ipoib_cm.c        |   15 +++---
 drivers/infiniband/ulp/ipoib/ipoib_ib.c        |   12 ++---
 drivers/infiniband/ulp/ipoib/ipoib_main.c      |   54 +++++++++++++++----------
 drivers/infiniband/ulp/ipoib/ipoib_multicast.c |    6 +-
 5 files changed, 64 insertions(+), 43 deletions(-)
drivers/infiniband/ulp/ipoib/ipoib.h +14 -6
@@ -63,6 +63,8 @@ enum ipoib_flush_level {
 
 enum {
 	IPOIB_ENCAP_LEN		  = 4,
+	IPOIB_PSEUDO_LEN	  = 20,
+	IPOIB_HARD_LEN		  = IPOIB_ENCAP_LEN + IPOIB_PSEUDO_LEN,
 
 	IPOIB_UD_HEAD_SIZE	  = IB_GRH_BYTES + IPOIB_ENCAP_LEN,
 	IPOIB_UD_RX_SG		  = 2, /* max buffer needed for 4K mtu */
@@ -131,15 +133,21 @@ struct ipoib_header {
 	u16	reserved;
 };
 
-struct ipoib_cb {
-	struct qdisc_skb_cb	qdisc_cb;
-	u8			hwaddr[INFINIBAND_ALEN];
+struct ipoib_pseudo_header {
+	u8	hwaddr[INFINIBAND_ALEN];
 };
 
-static inline struct ipoib_cb *ipoib_skb_cb(const struct sk_buff *skb)
+static inline void skb_add_pseudo_hdr(struct sk_buff *skb)
 {
-	BUILD_BUG_ON(sizeof(skb->cb) < sizeof(struct ipoib_cb));
-	return (struct ipoib_cb *)skb->cb;
+	char *data = skb_push(skb, IPOIB_PSEUDO_LEN);
+
+	/*
+	 * only the ipoib header is present now, make room for a dummy
+	 * pseudo header and set skb field accordingly
+	 */
+	memset(data, 0, IPOIB_PSEUDO_LEN);
+	skb_reset_mac_header(skb);
+	skb_pull(skb, IPOIB_HARD_LEN);
 }
 
 /* Used for all multicast joins (broadcast, IPv4 mcast and IPv6 mcast) */
drivers/infiniband/ulp/ipoib/ipoib_cm.c +8 -7
@@ -63,6 +63,8 @@ MODULE_PARM_DESC(cm_data_debug_level,
 #define IPOIB_CM_RX_DELAY       (3 * 256 * HZ)
 #define IPOIB_CM_RX_UPDATE_MASK (0x3)
 
+#define IPOIB_CM_RX_RESERVE     (ALIGN(IPOIB_HARD_LEN, 16) - IPOIB_ENCAP_LEN)
+
 static struct ib_qp_attr ipoib_cm_err_attr = {
 	.qp_state = IB_QPS_ERR
 };
@@ -147,15 +149,15 @@ static struct sk_buff *ipoib_cm_alloc_rx
 	struct sk_buff *skb;
 	int i;
 
-	skb = dev_alloc_skb(IPOIB_CM_HEAD_SIZE + 12);
+	skb = dev_alloc_skb(ALIGN(IPOIB_CM_HEAD_SIZE + IPOIB_PSEUDO_LEN, 16));
 	if (unlikely(!skb))
 		return NULL;
 
 	/*
-	 * IPoIB adds a 4 byte header. So we need 12 more bytes to align the
+	 * IPoIB adds a IPOIB_ENCAP_LEN byte header, this will align the
 	 * IP header to a multiple of 16.
 	 */
-	skb_reserve(skb, 12);
+	skb_reserve(skb, IPOIB_CM_RX_RESERVE);
 
 	mapping[0] = ib_dma_map_single(priv->ca, skb->data, IPOIB_CM_HEAD_SIZE,
 				       DMA_FROM_DEVICE);
@@ -624,9 +626,9 @@ void ipoib_cm_handle_rx_wc(struct net_de
 	if (wc->byte_len < IPOIB_CM_COPYBREAK) {
 		int dlen = wc->byte_len;
 
-		small_skb = dev_alloc_skb(dlen + 12);
+		small_skb = dev_alloc_skb(dlen + IPOIB_CM_RX_RESERVE);
 		if (small_skb) {
-			skb_reserve(small_skb, 12);
+			skb_reserve(small_skb, IPOIB_CM_RX_RESERVE);
 			ib_dma_sync_single_for_cpu(priv->ca, rx_ring[wr_id].mapping[0],
 						   dlen, DMA_FROM_DEVICE);
 			skb_copy_from_linear_data(skb, small_skb->data, dlen);
@@ -663,8 +665,7 @@ void ipoib_cm_handle_rx_wc(struct net_de
 
 copied:
 	skb->protocol = ((struct ipoib_header *) skb->data)->proto;
-	skb_reset_mac_header(skb);
-	skb_pull(skb, IPOIB_ENCAP_LEN);
+	skb_add_pseudo_hdr(skb);
 
 	++dev->stats.rx_packets;
 	dev->stats.rx_bytes += skb->len;
drivers/infiniband/ulp/ipoib/ipoib_ib.c +5 -7
@@ -130,16 +130,15 @@ static struct sk_buff *ipoib_alloc_rx_sk
 
 	buf_size = IPOIB_UD_BUF_SIZE(priv->max_ib_mtu);
 
-	skb = dev_alloc_skb(buf_size + IPOIB_ENCAP_LEN);
+	skb = dev_alloc_skb(buf_size + IPOIB_HARD_LEN);
 	if (unlikely(!skb))
 		return NULL;
 
 	/*
-	 * IB will leave a 40 byte gap for a GRH and IPoIB adds a 4 byte
-	 * header.  So we need 4 more bytes to get to 48 and align the
-	 * IP header to a multiple of 16.
+	 * the IP header will be at IPOIP_HARD_LEN + IB_GRH_BYTES, that is
+	 * 64 bytes aligned
 	 */
-	skb_reserve(skb, 4);
+	skb_reserve(skb, sizeof(struct ipoib_pseudo_header));
 
 	mapping = priv->rx_ring[id].mapping;
 	mapping[0] = ib_dma_map_single(priv->ca, skb->data, buf_size,
@@ -242,8 +241,7 @@ static void ipoib_ib_handle_rx_wc(struct
 	skb_pull(skb, IB_GRH_BYTES);
 
 	skb->protocol = ((struct ipoib_header *) skb->data)->proto;
-	skb_reset_mac_header(skb);
-	skb_pull(skb, IPOIB_ENCAP_LEN);
+	skb_add_pseudo_hdr(skb);
 
 	++dev->stats.rx_packets;
 	dev->stats.rx_bytes += skb->len;
drivers/infiniband/ulp/ipoib/ipoib_main.c +33 -21

155 lines not on this page · raw message

drivers/infiniband/ulp/ipoib/ipoib_multicast.c +4 -2
@@ -756,9 +756,11 @@ void ipoib_mcast_send(struct net_device
 			__ipoib_mcast_add(dev, mcast);
 			list_add_tail(&mcast->list, &priv->multicast_list);
 		}
-		if (skb_queue_len(&mcast->pkt_queue) < IPOIB_MAX_MCAST_QUEUE)
+		if (skb_queue_len(&mcast->pkt_queue) < IPOIB_MAX_MCAST_QUEUE) {
+			/* put pseudoheader back on for next time */
+			skb_push(skb, sizeof(struct ipoib_pseudo_header));
 			skb_queue_tail(&mcast->pkt_queue, skb);
-		else {
+		} else {
 			++dev->stats.tx_dropped;
 			dev_kfree_skb_any(skb);
 		}
author maintainer
#20 lore raw

PATCH 19/23 IB/umem: Release pid in error and ODP flow

In reply to Greg Kroah-Hartman

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

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

From: Kenneth Lee <[email protected]>

commit 828f6fa65ce7e80f77f5ab12942e44eb3d9d174e upstream.

1. Release pid before enter odp flow
2. Release pid when fail to allocate memory

Fixes 87773dd56d54 ("IB: ib_umem_release() should decrement mm->pinned_vm from ib_umem_get")
Fixes 8ada2c1c0c1d ("IB/core: Add support for on demand paging regions")
---
 drivers/infiniband/core/umem.c |    2 ++
 1 file changed, 2 insertions(+)
drivers/infiniband/core/umem.c +2 -0
@@ -134,6 +134,7 @@ struct ib_umem *ib_umem_get(struct ib_uc
 		 IB_ACCESS_REMOTE_ATOMIC | IB_ACCESS_MW_BIND));
 
 	if (access & IB_ACCESS_ON_DEMAND) {
+		put_pid(umem->pid);
 		ret = ib_umem_odp_get(context, umem);
 		if (ret) {
 			kfree(umem);
@@ -149,6 +150,7 @@ struct ib_umem *ib_umem_get(struct ib_uc
 
 	page_list = (struct page **) __get_free_page(GFP_KERNEL);
 	if (!page_list) {
+		put_pid(umem->pid);
 		kfree(umem);
 		return ERR_PTR(-ENOMEM);
 	}
author maintainer
#21 lore raw

PATCH 20/23 s5k4ecgx: select CRC32 helper

In reply to Greg Kroah-Hartman

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

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

From: Arnd Bergmann <[email protected]>

commit c739c0a7c3c2472d7562b8f802cdce44d2597c8b upstream.

A rare randconfig build failure shows up in this driver when the CRC32 helper is not there:

drivers/media/built-in.o: In function `s5k4ecgx_s_power':
s5k4ecgx.c:(.text+0x9eb4): undefined reference to `crc32_le'

This adds the 'select' that all other users of this function have.

Fixes 8b99312b7214 ("[media] Add v4l2 subdev driver for S5K4ECGX sensor")
---
 drivers/media/i2c/Kconfig |    1 +
 1 file changed, 1 insertion(+)
drivers/media/i2c/Kconfig +1 -0
@@ -607,6 +607,7 @@ config VIDEO_S5K6A3
 config VIDEO_S5K4ECGX
         tristate "Samsung S5K4ECGX sensor support"
         depends on I2C && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
+	select CRC32
         ---help---
           This is a V4L2 sensor-level driver for Samsung S5K4ECGX 5M
           camera sensor with an embedded SoC image signal processor.
author maintainer
#22 lore raw

PATCH 21/23 pinctrl: broxton: Use correct PADCFGLOCK offset

In reply to Greg Kroah-Hartman

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

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

From: Mika Westerberg <[email protected]>

commit ecc8995363ee6231b32dad61c955b371b79cc4cf upstream.

PADCFGLOCK (and PADCFGLOCK_TX) offset in Broxton actually starts at 0x060 and not 0x090 as used in the driver. Fix it to use the correct offset.

---
 drivers/pinctrl/intel/pinctrl-broxton.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/pinctrl/intel/pinctrl-broxton.c +1 -1
@@ -19,7 +19,7 @@
 
 #define BXT_PAD_OWN	0x020
 #define BXT_HOSTSW_OWN	0x080
-#define BXT_PADCFGLOCK	0x090
+#define BXT_PADCFGLOCK	0x060
 #define BXT_GPI_IE	0x110
 
 #define BXT_COMMUNITY(s, e)				\
author maintainer
#23 lore raw

PATCH 22/23 platform/x86: intel_mid_powerbtn: Set IRQ_ONESHOT

In reply to Greg Kroah-Hartman

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

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

From: Andy Shevchenko <[email protected]>

commit 5a00b6c2438460b870a451f14593fc40d3c7edf6 upstream.

The commit 1c6c69525b40 ("genirq: Reject bogus threaded irq requests") starts refusing misconfigured interrupt handlers. This makes intel_mid_powerbtn not working anymore.

Add a mandatory flag to a threaded IRQ request in the driver.

Fixes 1c6c69525b40 ("genirq: Reject bogus threaded irq requests")
---
 drivers/platform/x86/intel_mid_powerbtn.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/platform/x86/intel_mid_powerbtn.c +1 -1
@@ -77,7 +77,7 @@ static int mfld_pb_probe(struct platform
 
 	input_set_capability(input, EV_KEY, KEY_POWER);
 
-	error = request_threaded_irq(irq, NULL, mfld_pb_isr, 0,
+	error = request_threaded_irq(irq, NULL, mfld_pb_isr, IRQF_ONESHOT,
 				     DRIVER_NAME, input);
 	if (error) {
 		dev_err(&pdev->dev, "Unable to request irq %d for mfld power"
author maintainer
#24 lore raw

PATCH 23/23 mm, memcg: do not retry precharge charges

In reply to Greg Kroah-Hartman

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

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

From: David Rientjes <[email protected]>

commit 3674534b775354516e5c148ea48f51d4d1909a78 upstream.

When memory.move_charge_at_immigrate is enabled and precharges are depleted during move, mem_cgroup_move_charge_pte_range() will attempt to increase the size of the precharge.

Prevent precharges from ever looping by setting __GFP_NORETRY. This was probably the intention of the GFP_KERNEL & ~__GFP_NORETRY, which is pointless as written.

Fixes 0029e19ebf84 ("mm: memcontrol: remove explicit OOM parameter in charge path")
Cc Johannes Weiner <[email protected]>
Cc Vladimir Davydov <[email protected]>
---
 mm/memcontrol.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
mm/memcontrol.c +2 -2
@@ -4496,9 +4496,9 @@ static int mem_cgroup_do_precharge(unsig
 		return ret;
 	}
 
-	/* Try charges one by one with reclaim */
+	/* Try charges one by one with reclaim, but do not retry */
 	while (count--) {
-		ret = try_charge(mc.to, GFP_KERNEL & ~__GFP_NORETRY, 1);
+		ret = try_charge(mc.to, GFP_KERNEL | __GFP_NORETRY, 1);
 		if (ret)
 			return ret;
 		mc.precharge++;
#25 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.4.46 release. There are 23 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.

Responses should be made by Thu Feb 2 05:36:16 UTC 2017. Anything received after that time might be too late.

Build results:

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

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

Guenter

#26 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.4.46 release. There are 23 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.

Responses should be made by Thu Feb 2 05:36:16 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.4.46-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.4.y
and the diffstat can be found below.

thanks,

greg k-h

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

thanks,
-- Shuah