4.4.46-stable review
Greg Kroah-Hartman
maintainercover 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(-)
Greg Kroah-Hartman
maintainerPATCH 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 *cmaint 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 *fint 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);
Greg Kroah-Hartman
maintainerPATCH 2/23 tile/ptrace: Preserve previous registers for short regset write
In reply to Greg Kroah-Hartman4.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, ®s,0 ,sizeof (regs));
Greg Kroah-Hartman
maintainerPATCH 4/23 mm/mempolicy.c: do not put mempolicy before using its nodemask
In reply to Greg Kroah-Hartman4.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;
Greg Kroah-Hartman
maintainerPATCH 5/23 sysctl: fix proc_doulongvec_ms_jiffies_minmax()
In reply to Greg Kroah-Hartman4.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(vbreak ;if (neg)continue ; + val = convmul * val / convdiv;if ((min && val < *min) || (max && val > *max))continue ; *i = val;
Greg Kroah-Hartman
maintainerPATCH 6/23 ISDN: eicon: silence misleading array-bounds warning
In reply to Greg Kroah-Hartman4.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)
Greg Kroah-Hartman
maintainerPATCH 7/23 RDMA/cma: Fix unknown symbol when CONFIG_IPV6 is not enabled
In reply to Greg Kroah-Hartman4.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().
--- 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;
Greg Kroah-Hartman
maintainerPATCH 8/23 s390/ptrace: Preserve previous registers for short regset write
In reply to Greg Kroah-Hartman4.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_sif (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 taskif (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++)
Greg Kroah-Hartman
maintainerPATCH 10/23 can: ti_hecc: add missing prepare and unprepare of the clock
In reply to Greg Kroah-Hartman4.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 platformnetif_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 platforstruct 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 platfohecc_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 ;
Greg Kroah-Hartman
maintainerPATCH 11/23 ARC: udelay: fix inline assembler by adding LP_COUNT to clobber list
In reply to Greg Kroah-Hartman4.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
--- 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 );
Greg Kroah-Hartman
maintainerPATCH 12/23 ARC: [arcompact] handle unaligned access delay slot corner case
In reply to Greg Kroah-Hartman4.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 addreif (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;
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
9aed02feae57bf7a40cb04ea0e3017cb7a998db4upstream.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
Signed-off-by Vineet Gupta <[email protected]>Signed-off-by Greg Kroah-Hartman <[email protected]>---
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.
Greg Kroah-Hartman
maintainerRe: [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
9aed02feae57bf7a40cb04ea0e3017cb7a998db4upstream.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
Signed-off-by Vineet Gupta <[email protected]>Signed-off-by Greg Kroah-Hartman <[email protected]>---
�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
Greg Kroah-Hartman
maintainerRe: [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
9aed02feae57bf7a40cb04ea0e3017cb7a998db4upstream.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
Signed-off-by Vineet Gupta <[email protected]>Signed-off-by Greg Kroah-Hartman <[email protected]>---
�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
Greg Kroah-Hartman
maintainerPATCH 13/23 parisc: Dont use BITS_PER_LONG in userspace-exported swab.h header
In reply to Greg Kroah-Hartman4.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__ __u64return x; }#define __arch_swab64 __arch_swab64 -#endif /* BITS_PER_LONG > 32 */ +#endif /* __BITS_PER_LONG > 32 */ #endif /* _PARISC_SWAB_H */
Greg Kroah-Hartman
maintainerPATCH 14/23 nfs: Dont increment lock sequence ID after NFS4ERR_MOVED
In reply to Greg Kroah-Hartman4.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(u3case NFS4ERR_BADXDR :case NFS4ERR_RESOURCE :case NFS4ERR_NOFILEHANDLE : +case NFS4ERR_MOVED :return false; };return true;
Greg Kroah-Hartman
maintainerPATCH 15/23 NFSv4.0: always send mode in SETATTR after EXCLUSIVE4
In reply to Greg Kroah-Hartman4.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.
--- 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 )
Greg Kroah-Hartman
maintainerPATCH 16/23 SUNRPC: cleanup ida information when removing sunrpc module
In reply to Greg Kroah-Hartman4.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>] 0xffffffffffffffffI found, the ida information (dynamic memory) isn't cleanup.
--- 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 __exitcleanup_sunrpc (void ) { +rpc_cleanup_clids ();rpcauth_remove_module ();cleanup_socket_xprt ();svc_cleanup_xprt_sock ();
Greg Kroah-Hartman
maintainerPATCH 17/23 drm/i915: Dont leak edid in intel_crt_detect_ddc()
In reply to Greg Kroah-Hartman4.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.
--- 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(structstruct 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
Greg Kroah-Hartman
maintainerPATCH 18/23 IB/ipoib: move back IB LL address into the hard header
In reply to Greg Kroah-Hartman4.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
--- 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_rxstruct 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_deif (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(structskb_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); }
Greg Kroah-Hartman
maintainerPATCH 19/23 IB/umem: Release pid in error and ODP flow
In reply to Greg Kroah-Hartman4.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
--- 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 ); }
Greg Kroah-Hartman
maintainerPATCH 20/23 s5k4ecgx: select CRC32 helper
In reply to Greg Kroah-Hartman4.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.
--- 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.
Greg Kroah-Hartman
maintainerPATCH 21/23 pinctrl: broxton: Use correct PADCFGLOCK offset
In reply to Greg Kroah-Hartman4.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) \
Greg Kroah-Hartman
maintainerPATCH 22/23 platform/x86: intel_mid_powerbtn: Set IRQ_ONESHOT
In reply to Greg Kroah-Hartman4.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.
--- 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 platforminput_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"
Greg Kroah-Hartman
maintainerPATCH 23/23 mm, memcg: do not retry precharge charges
In reply to Greg Kroah-Hartman4.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.
--- 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(unsigreturn 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++;
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
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.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-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