Skip to contentSkip to conversation

4.8.15-stable review

PATCH In review Greg Kroah-Hartman 3 participants 36 messages Dec 13, 2016 – Dec 14, 2016

Subsystems (3)
lore
Share & tools
lore

Greg Kroah-Hartman

author maintainer
#0 lore raw

cover 4.8.15-stable review

This is the start of the stable review cycle for the 4.8.15 release. There are 33 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 Dec 15 17:15:24 UTC 2016. 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.8.15-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.8.y
and the diffstat can be found below.

thanks,

greg k-h

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

Greg Kroah-Hartman <[email protected]>

    Linux 4.8.15-rc1

David Michael <[email protected]>
crypto: rsa - Add Makefile dependencies to fix parallel builds

Michal Hocko <[email protected]>
hotplug: Make register and unregister notifier API symmetric

Sven Eckelmann <[email protected]>
batman-adv: Check for alloc errors when preparing TT local data

Boris Brezillon <[email protected]>
m68k: Fix ndelay() macro

Jeff Layton <[email protected]>

    ceph: don't set req->r_locked_dir in ceph_d_revalidate

Stefan Agner <[email protected]>
ARM: dts: imx7d: fix LCDIF clock assignment

Roger Shimizu <[email protected]>
ARM: dts: orion5x: fix number of sata port for linkstation ls-gl

Rafael J. Wysocki <[email protected]>
Revert "ACPI: Execute _PTS before system reboot"

추지호 <[email protected]>
can: peak: fix bad memory access and free sequence

Marc Kleine-Budde <[email protected]>
can: raw: raw_setsockopt: limit number of can_filter that can be set

Romain Perier <[email protected]>
crypto: marvell - Don't corrupt state of an STD req for re-stepped ahash

tim <[email protected]>
crypto: mcryptd - Check mcryptd algorithm compatibility

Horia Geantă <[email protected]>
crypto: caam - fix pointer size for AArch64 boot loader, AArch32 kernel

Romain Perier <[email protected]>
crypto: marvell - Don't copy hash operation twice into the SRAM

Dan Williams <[email protected]>
acpi, nfit: fix bus vs dimm confusion in xlat_status

Dan Williams <[email protected]>
acpi, nfit: validate ars_status output buffer size

Dan Williams <[email protected]>
acpi, nfit, libnvdimm: fix / harden ars_status output length handling

Vishal Verma <[email protected]>
acpi, nfit: fix extended status translations for ACPI DSMs

Peter Zijlstra (Intel) <[email protected]>
perf/x86: Fix full width counter, counter overflow

Peng Tao <[email protected]>
vhost-vsock: fix orphan connection reset

Mike Galbraith <[email protected]>
sched/autogroup: Fix 64-bit kernel nice level adjustment

Mauricio Faria de Oliveira <[email protected]>
scsi: lpfc: fix oops/BUG in lpfc_sli_ringtxcmpl_put()

Dan Williams <[email protected]>
device-dax: fix private mapping restriction, permit read-only

Thomas Gleixner <[email protected]>
locking/rtmutex: Use READ_ONCE() in rt_mutex_owner()

Thomas Gleixner <[email protected]>
locking/rtmutex: Prevent dequeue vs. unlock race

Sergey Senozhatsky <[email protected]>
zram: restrict add/remove attributes to root only

Helge Deller <[email protected]>
parisc: Fix TLB related boot crash on SMP machines

John David Anglin <[email protected]>
parisc: Remove unnecessary TLB purges from flush_dcache_page_asm and flush_icache_page_asm

John David Anglin <[email protected]>
parisc: Purge TLB before setting PTE

Miklos Szeredi <[email protected]>
fuse: fix clearing suid, sgid for chown()

Ben Hutchings <[email protected]>
powerpc/boot: Fix build failure in 32-bit boot wrapper

Benjamin Herrenschmidt <[email protected]>
powerpc/mm: Fix lazy icache flush on pre-POWER5

Andrew Donnellan <[email protected]>
powerpc/eeh: Fix deadlock when PE frozen state can't be cleared

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

Diffstat:

 Makefile                                       |  4 +-
 arch/arm/boot/dts/imx7s.dtsi                   |  5 +-
 arch/arm/boot/dts/orion5x-linkstation-lsgl.dts |  4 ++
 arch/m68k/include/asm/delay.h                  |  2 +-
 arch/parisc/include/asm/pgtable.h              |  8 +--
 arch/parisc/kernel/cache.c                     | 11 +++++
 arch/parisc/kernel/pacache.S                   | 22 +--------
 arch/powerpc/boot/Makefile                     |  3 +-
 arch/powerpc/boot/opal.c                       |  2 +-
 arch/powerpc/kernel/eeh_driver.c               |  4 +-
 arch/powerpc/mm/hash64_4k.c                    |  2 +-
 arch/powerpc/mm/hash64_64k.c                   |  4 +-
 arch/x86/events/core.c                         |  2 +-
 arch/x86/events/intel/core.c                   |  2 +-
 crypto/Makefile                                |  1 +
 crypto/mcryptd.c                               | 19 ++++---
 drivers/acpi/nfit/core.c                       | 49 ++++++++++++++-----
 drivers/acpi/sleep.c                           | 29 +++--------
 drivers/block/zram/zram_drv.c                  |  8 ++-
 drivers/crypto/caam/ctrl.c                     |  5 +-
 drivers/crypto/marvell/hash.c                  | 11 ++---
 drivers/dax/dax.c                              |  2 +-
 drivers/net/can/usb/peak_usb/pcan_usb_core.c   |  6 ++-
 drivers/nvdimm/bus.c                           | 25 ++++++++--
 drivers/scsi/lpfc/lpfc_sli.c                   | 14 +++---
 drivers/vhost/vsock.c                          |  2 +-
 fs/ceph/dir.c                                  | 24 +++++----
 fs/fuse/dir.c                                  |  7 +--
 include/linux/cpu.h                            | 15 ++----
 include/linux/libnvdimm.h                      |  2 +-
 include/uapi/linux/can.h                       |  1 +
 kernel/cpu.c                                   |  2 +-
 kernel/locking/rtmutex.c                       | 68 +++++++++++++++++++++++++-
 kernel/locking/rtmutex_common.h                |  5 +-
 kernel/sched/auto_group.c                      |  4 +-
 net/batman-adv/translation-table.c             |  4 +-
 net/can/raw.c                                  |  3 ++
 37 files changed, 241 insertions(+), 140 deletions(-)
author maintainer
#1 lore raw

PATCH 1/33 powerpc/eeh: Fix deadlock when PE frozen state cant be cleared

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

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

From: Andrew Donnellan <[email protected]>

commit 409bf7f8a02ef88db5a0f2cdcf9489914f4b8508 upstream.

In eeh_reset_device(), we take the pci_rescan_remove_lock immediately after after we call eeh_reset_pe() to reset the PCI controller. We then call eeh_clear_pe_frozen_state(), which can return an error. In this case, we bail out of eeh_reset_device() without calling pci_unlock_rescan_remove().

Add a call to pci_unlock_rescan_remove() in the eeh_clear_pe_frozen_state() error path so that we don't cause a deadlock later on.

Fixes 78954700631f ("powerpc/eeh: Avoid I/O access during PE reset")
---
 arch/powerpc/kernel/eeh_driver.c |    4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)
arch/powerpc/kernel/eeh_driver.c +3 -1
@@ -671,8 +671,10 @@ static int eeh_reset_device(struct eeh_p
 
 	/* Clear frozen state */
 	rc = eeh_clear_pe_frozen_state(pe, false);
-	if (rc)
+	if (rc) {
+		pci_unlock_rescan_remove();
 		return rc;
+	}
 
 	/* Give the system 5 seconds to finish running the user-space
 	 * hotplug shutdown scripts, e.g. ifdown for ethernet.  Yes,
author maintainer
#2 lore raw

PATCH 2/33 powerpc/mm: Fix lazy icache flush on pre-POWER5

In reply to Greg Kroah-Hartman

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

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

From: Benjamin Herrenschmidt <[email protected]>

commit dd7b2f035ec41a409f7a7cec7aabc0ec0eacf476 upstream.

On 64-bit CPUs with no-execute support and non-snooping icache, such as 970 or POWER4, we have a software mechanism to ensure coherency of the cache (using exec faults when needed).

This was broken due to a logic error when the code was rewritten from assembly to C, previously the assembly code did:

BEGIN_FTR_SECTION

         mr      r4,r30
         mr      r5,r7
         bl      hash_page_do_lazy_icache

END_FTR_SECTION(CPU_FTR_NOEXECUTE|CPU_FTR_COHERENT_ICACHE, CPU_FTR_NOEXECUTE)

Which tests that:
(cpu_features & (NOEXECUTE | COHERENT_ICACHE)) == NOEXECUTE

Which says that the current cpu does have NOEXECUTE, but does not have COHERENT_ICACHE.

Fixes 91f1da99792a ("powerpc/mm: Convert 4k hash insert to C")
Fixes 89ff725051d1 ("powerpc/mm: Convert __hash_page_64K to C")
Fixes a43c0eb8364c ("powerpc/mm: Convert 4k insert from asm to C")
[mpe: Change log verbosification]
---
 arch/powerpc/mm/hash64_4k.c  |    2 +-
 arch/powerpc/mm/hash64_64k.c |    4 ++--
 2 files changed, 3 insertions(+), 3 deletions(-)
arch/powerpc/mm/hash64_4k.c +1 -1
@@ -55,7 +55,7 @@ int __hash_page_4K(unsigned long ea, uns
 	 */
 	rflags = htab_convert_pte_flags(new_pte);
 
-	if (!cpu_has_feature(CPU_FTR_NOEXECUTE) &&
+	if (cpu_has_feature(CPU_FTR_NOEXECUTE) &&
 	    !cpu_has_feature(CPU_FTR_COHERENT_ICACHE))
 		rflags = hash_page_do_lazy_icache(rflags, __pte(old_pte), trap);
 
arch/powerpc/mm/hash64_64k.c +2 -2
@@ -87,7 +87,7 @@ int __hash_page_4K(unsigned long ea, uns
 	subpg_pte = new_pte & ~subpg_prot;
 	rflags = htab_convert_pte_flags(subpg_pte);
 
-	if (!cpu_has_feature(CPU_FTR_NOEXECUTE) &&
+	if (cpu_has_feature(CPU_FTR_NOEXECUTE) &&
 	    !cpu_has_feature(CPU_FTR_COHERENT_ICACHE)) {
 
 		/*
@@ -258,7 +258,7 @@ int __hash_page_64K(unsigned long ea, un
 
 	rflags = htab_convert_pte_flags(new_pte);
 
-	if (!cpu_has_feature(CPU_FTR_NOEXECUTE) &&
+	if (cpu_has_feature(CPU_FTR_NOEXECUTE) &&
 	    !cpu_has_feature(CPU_FTR_COHERENT_ICACHE))
 		rflags = hash_page_do_lazy_icache(rflags, __pte(old_pte), trap);
 
author maintainer
#3 lore raw

PATCH 3/33 powerpc/boot: Fix build failure in 32-bit boot wrapper

In reply to Greg Kroah-Hartman

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

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

From: Ben Hutchings <[email protected]>

commit 10c77dba40ff58fc03587b3b60725bb7fd723183 upstream.

OPAL is not callable from 32-bit mode and the assembly code for it may not even build (depending on how binutils was configured).

References: https://buildd.debian.org/status/fetch.php?pkg=linux&arch=powerpcspe&ver=4.8.7-1&stamp=1479203712

Fixes 656ad58ef19e ("powerpc/boot: Add OPAL console to epapr wrappers")
---
 arch/powerpc/boot/Makefile |    3 ++-
 arch/powerpc/boot/opal.c   |    2 +-
 2 files changed, 3 insertions(+), 2 deletions(-)
arch/powerpc/boot/Makefile +2 -1
@@ -78,7 +78,8 @@ src-wlib-y := string.S crt0.S crtsavres.
 		ns16550.c serial.c simple_alloc.c div64.S util.S \
 		gunzip_util.c elf_util.c $(zlib) devtree.c stdlib.c \
 		oflib.c ofconsole.c cuboot.c mpsc.c cpm-serial.c \
-		uartlite.c mpc52xx-psc.c opal.c opal-calls.S
+		uartlite.c mpc52xx-psc.c opal.c
+src-wlib-$(CONFIG_PPC64_BOOT_WRAPPER) +=  opal-calls.S
 src-wlib-$(CONFIG_40x) += 4xx.c planetcore.c
 src-wlib-$(CONFIG_44x) += 4xx.c ebony.c bamboo.c
 src-wlib-$(CONFIG_8xx) += mpc8xx.c planetcore.c fsl-soc.c
arch/powerpc/boot/opal.c +1 -1
@@ -13,7 +13,7 @@
 #include <libfdt.h>
 #include "../include/asm/opal-api.h"
 
-#ifdef __powerpc64__
+#ifdef CONFIG_PPC64_BOOT_WRAPPER
 
 /* Global OPAL struct used by opal-call.S */
 struct opal {
author maintainer
#4 lore raw

PATCH 4/33 fuse: fix clearing suid, sgid for chown()

In reply to Greg Kroah-Hartman

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

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

From: Miklos Szeredi <[email protected]>

commit c01638f5d919728f565bf8b5e0a6a159642df0d9 upstream.

Basically, the pjdfstests set the ownership of a file to 06555, and then chowns it (as root) to a new uid/gid. Prior to commit a09f99eddef4 ("fuse:
fix killing s[ug]id in setattr"), fuse would send down a setattr with both the uid/gid change and a new mode. Now, it just sends down the uid/gid change.

Technically this is NOTABUG, since POSIX doesn't _require_ that we clear these bits for a privileged process, but Linux (wisely) has done that and I think we don't want to change that behavior here.

This is caused by the use of should_remove_suid(), which will always return 0 when the process has CAP_FSETID.

In fact we really don't need to be calling should_remove_suid() at all, since we've already been indicated that we should remove the suid, we just don't want to use a (very) stale mode for that.

This patch should fix the above as well as simplify the logic.

Fixes a09f99eddef4 ("fuse: fix killing s[ug]id in setattr")
---
 fs/fuse/dir.c |    7 ++-----
 1 file changed, 2 insertions(+), 5 deletions(-)
fs/fuse/dir.c +2 -5
@@ -1709,8 +1709,6 @@ static int fuse_setattr(struct dentry *e
 		return -EACCES;
 
 	if (attr->ia_valid & (ATTR_KILL_SUID | ATTR_KILL_SGID)) {
-		int kill;
-
 		attr->ia_valid &= ~(ATTR_KILL_SUID | ATTR_KILL_SGID |
 				    ATTR_MODE);
 		/*
@@ -1722,12 +1720,11 @@ static int fuse_setattr(struct dentry *e
 			return ret;
 
 		attr->ia_mode = inode->i_mode;
-		kill = should_remove_suid(entry);
-		if (kill & ATTR_KILL_SUID) {
+		if (inode->i_mode & S_ISUID) {
 			attr->ia_valid |= ATTR_MODE;
 			attr->ia_mode &= ~S_ISUID;
 		}
-		if (kill & ATTR_KILL_SGID) {
+		if ((inode->i_mode & (S_ISGID | S_IXGRP)) == (S_ISGID | S_IXGRP)) {
 			attr->ia_valid |= ATTR_MODE;
 			attr->ia_mode &= ~S_ISGID;
 		}
author maintainer
#5 lore raw

PATCH 5/33 parisc: Purge TLB before setting PTE

In reply to Greg Kroah-Hartman

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

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

From: John David Anglin <[email protected]>

commit c78e710c1c9fbeff43dddc0aa3d0ff458e70b0cc upstream.

The attached change interchanges the order of purging the TLB and setting the corresponding page table entry. TLB purges are strongly ordered. It occurred to me one night that setting the PTE first might have subtle ordering issues on SMP machines and cause random memory corruption.

A TLB lock guards the insertion of user TLB entries. So after the TLB is purged, a new entry can't be inserted until the lock is released. This ensures that the new PTE value is used when the lock is released.

Since making this change, no random segmentation faults have been observed on the Debian hppa buildd servers.

---
 arch/parisc/include/asm/pgtable.h |    8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)
arch/parisc/include/asm/pgtable.h +4 -4
@@ -65,9 +65,9 @@ static inline void purge_tlb_entries(str
 		unsigned long flags;				\
 		spin_lock_irqsave(&pa_tlb_lock, flags);		\
 		old_pte = *ptep;				\
-		set_pte(ptep, pteval);				\
 		if (pte_inserted(old_pte))			\
 			purge_tlb_entries(mm, addr);		\
+		set_pte(ptep, pteval);				\
 		spin_unlock_irqrestore(&pa_tlb_lock, flags);	\
 	} while (0)
 
@@ -478,8 +478,8 @@ static inline int ptep_test_and_clear_yo
 		spin_unlock_irqrestore(&pa_tlb_lock, flags);
 		return 0;
 	}
-	set_pte(ptep, pte_mkold(pte));
 	purge_tlb_entries(vma->vm_mm, addr);
+	set_pte(ptep, pte_mkold(pte));
 	spin_unlock_irqrestore(&pa_tlb_lock, flags);
 	return 1;
 }
@@ -492,9 +492,9 @@ static inline pte_t ptep_get_and_clear(s
 
 	spin_lock_irqsave(&pa_tlb_lock, flags);
 	old_pte = *ptep;
-	set_pte(ptep, __pte(0));
 	if (pte_inserted(old_pte))
 		purge_tlb_entries(mm, addr);
+	set_pte(ptep, __pte(0));
 	spin_unlock_irqrestore(&pa_tlb_lock, flags);
 
 	return old_pte;
@@ -504,8 +504,8 @@ static inline void ptep_set_wrprotect(st
 {
 	unsigned long flags;
 	spin_lock_irqsave(&pa_tlb_lock, flags);
-	set_pte(ptep, pte_wrprotect(*ptep));
 	purge_tlb_entries(mm, addr);
+	set_pte(ptep, pte_wrprotect(*ptep));
 	spin_unlock_irqrestore(&pa_tlb_lock, flags);
 }
 
author maintainer
#6 lore raw

PATCH 6/33 parisc: Remove unnecessary TLB purges from flush_dcache_page_asm and flush_icache_page_asm

In reply to Greg Kroah-Hartman

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

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

From: John David Anglin <[email protected]>

commit febe42964fe182281859b3d43d844bb25ca49367 upstream.

We have four routines in pacache.S that use temporary alias pages:
copy_user_page_asm(), clear_user_page_asm(), flush_dcache_page_asm() and flush_icache_page_asm(). copy_user_page_asm() and clear_user_page_asm() don't purge the TLB entry used for the operation. flush_dcache_page_asm() and flush_icache_page_asm do purge the entry.

Presumably, this was thought to optimize TLB use. However, the operation is quite heavy weight on PA 1.X processors as we need to take the TLB lock and a TLB broadcast is sent to all processors.

This patch removes the purges from flush_dcache_page_asm() and flush_icache_page_asm.

---
 arch/parisc/kernel/pacache.S |   22 +---------------------
 1 file changed, 1 insertion(+), 21 deletions(-)
arch/parisc/kernel/pacache.S +1 -21
@@ -886,19 +886,10 @@ ENTRY(flush_dcache_page_asm)
 	fdc,m		r31(%r28)
 	fdc,m		r31(%r28)
 	fdc,m		r31(%r28)
-	cmpb,COND(<<)		%r28, %r25,1b
+	cmpb,COND(<<)	%r28, %r25,1b
 	fdc,m		r31(%r28)
 
 	sync
-
-#ifdef CONFIG_PA20
-	pdtlb,l		%r0(%r25)
-#else
-	tlb_lock	%r20,%r21,%r22
-	pdtlb		%r0(%r25)
-	tlb_unlock	%r20,%r21,%r22
-#endif
-
 	bv		%r0(%r2)
 	nop
 	.exit
@@ -973,17 +964,6 @@ ENTRY(flush_icache_page_asm)
 	fic,m		%r31(%sr4,%r28)
 
 	sync
-
-#ifdef CONFIG_PA20
-	pdtlb,l		%r0(%r28)
-	pitlb,l         %r0(%sr4,%r25)
-#else
-	tlb_lock        %r20,%r21,%r22
-	pdtlb		%r0(%r28)
-	pitlb           %r0(%sr4,%r25)
-	tlb_unlock      %r20,%r21,%r22
-#endif
-
 	bv		%r0(%r2)
 	nop
 	.exit
author maintainer
#7 lore raw

PATCH 7/33 parisc: Fix TLB related boot crash on SMP machines

In reply to Greg Kroah-Hartman

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

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

From: Helge Deller <[email protected]>

commit 24d0492b7d5d321a9c5846c8c974eba9823ffaa0 upstream.

At bootup we run measurements to calculate the best threshold for when we should be using full TLB flushes instead of just flushing a specific amount of TLB entries. This performance test is run over the kernel text segment.

But running this TLB performance test on the kernel text segment turned out to crash some SMP machines when the kernel text pages were mapped as huge pages.

To avoid those crashes this patch simply skips this test on some SMP machines and calculates an optimal threshold based on the maximum number of available TLB entries and number of online CPUs.

On a technical side, this seems to happen:
The TLB measurement code uses flush_tlb_kernel_range() to flush specific TLB entries with a page size of 4k (pdtlb 0(sr1,addr)). On UP systems this purge instruction seems to work without problems even if the pages were mapped as huge pages. But on SMP systems the TLB purge instruction is broadcasted to other CPUs. Those CPUs then crash the machine because the page size is not as expected. C8000 machines with PA8800/PA8900 CPUs were not affected by this problem, because the required cache coherency prohibits to use huge pages at all. Sadly I didn't found any documentation about this behaviour, so this finding is purely based on testing with phyiscal SMP machines (A500-44 and J5000, both were 2-way boxes).

---
 arch/parisc/kernel/cache.c |   11 +++++++++++
 1 file changed, 11 insertions(+)
arch/parisc/kernel/cache.c +11 -0
@@ -393,6 +393,15 @@ void __init parisc_setup_cache_timing(vo
 
 	/* calculate TLB flush threshold */
 
+	/* On SMP machines, skip the TLB measure of kernel text which
+	 * has been mapped as huge pages. */
+	if (num_online_cpus() > 1 && !parisc_requires_coherency()) {
+		threshold = max(cache_info.it_size, cache_info.dt_size);
+		threshold *= PAGE_SIZE;
+		threshold /= num_online_cpus();
+		goto set_tlb_threshold;
+	}
+
 	alltime = mfctl(16);
 	flush_tlb_all();
 	alltime = mfctl(16) - alltime;
@@ -411,6 +420,8 @@ void __init parisc_setup_cache_timing(vo
 		alltime, size, rangetime);
 
 	threshold = PAGE_ALIGN(num_online_cpus() * size * alltime / rangetime);
+
+set_tlb_threshold:
 	if (threshold)
 		parisc_tlb_flush_threshold = threshold;
 	printk(KERN_INFO "TLB flush threshold set to %lu KiB\n",
author maintainer
#8 lore raw

PATCH 8/33 zram: restrict add/remove attributes to root only

In reply to Greg Kroah-Hartman

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

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

From: Sergey Senozhatsky <[email protected]>

commit 5c7e9ccd91b90d87029261f8856294ee51934cab upstream.

zram hot_add sysfs attribute is a very 'special' attribute - reading from it creates a new uninitialized zram device. This file, by a mistake, can be read by a 'normal' user at the moment, while only root must be able to create a new zram device, therefore hot_add attribute must have S_IRUSR mode, not S_IRUGO.

[[email protected]: s/sence/sense/, reflow comment to use 80 cols]
Fixes 6566d1a32bf72 ("zram: add dynamic device add/remove functionality")
Cc Minchan Kim <[email protected]>
---
 drivers/block/zram/zram_drv.c |    8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)
drivers/block/zram/zram_drv.c +7 -1
@@ -1413,8 +1413,14 @@ static ssize_t hot_remove_store(struct c
 	return ret ? ret : count;
 }
 
+/*
+ * NOTE: hot_add attribute is not the usual read-only sysfs attribute. In a
+ * sense that reading from this file does alter the state of your system -- it
+ * creates a new un-initialized zram device and returns back this device's
+ * device_id (or an error code if it fails to create a new device).
+ */
 static struct class_attribute zram_control_class_attrs[] = {
-	__ATTR_RO(hot_add),
+	__ATTR(hot_add, 0400, hot_add_show, NULL),
 	__ATTR_WO(hot_remove),
 	__ATTR_NULL,
 };
author maintainer
#9 lore raw

PATCH 9/33 locking/rtmutex: Prevent dequeue vs. unlock race

In reply to Greg Kroah-Hartman

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

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

From: Thomas Gleixner <[email protected]>

commit dbb26055defd03d59f678cb5f2c992abe05b064a upstream.

David reported a futex/rtmutex state corruption. It's caused by the following problem:

CPU0 CPU1 CPU2

l->owner=T1

		rt_mutex_lock(l)
		lock(l->wait_lock)
		l->owner = T1 | HAS_WAITERS;
		enqueue(T2)
		boost()
		  unlock(l->wait_lock)
		schedule()

				rt_mutex_lock(l)
				lock(l->wait_lock)
				l->owner = T1 | HAS_WAITERS;
				enqueue(T3)
				boost()
				  unlock(l->wait_lock)
				schedule()
		signal(->T2)	signal(->T3)
		lock(l->wait_lock)
		dequeue(T2)
		deboost()
		  unlock(l->wait_lock)
				lock(l->wait_lock)
				dequeue(T3)
				  ===> wait list is now empty
				deboost()
				 unlock(l->wait_lock)
		lock(l->wait_lock)
		fixup_rt_mutex_waiters()
		  if (wait_list_empty(l)) {
		    owner = l->owner & ~HAS_WAITERS;
		    l->owner = owner
		     ==> l->owner = T1
		  }

				lock(l->wait_lock)
rt_mutex_unlock(l)		fixup_rt_mutex_waiters()
				  if (wait_list_empty(l)) {
				    owner = l->owner & ~HAS_WAITERS;
cmpxchg(l->owner, T1, NULL)
 ===> Success (l->owner = NULL)
				    l->owner = owner
				     ==> l->owner = T1
				  }

That means the problem is caused by fixup_rt_mutex_waiters() which does the RMW to clear the waiters bit unconditionally when there are no waiters in the rtmutexes rbtree.

This can be fatal: A concurrent unlock can release the rtmutex in the fastpath because the waiters bit is not set. If the cmpxchg() gets in the middle of the RMW operation then the previous owner, which just unlocked the rtmutex is set as the owner again when the write takes place after the successfull cmpxchg().

The solution is rather trivial: verify that the owner member of the rtmutex has the waiters bit set before clearing it. This does not require a cmpxchg() or other atomic operations because the waiters bit can only be set and cleared with the rtmutex wait_lock held. It's also safe against the fast path unlock attempt. The unlock attempt via cmpxchg() will either see the bit set and take the slowpath or see the bit cleared and release it atomically in the fastpath.

It's remarkable that the test program provided by David triggers on ARM64 and MIPS64 really quick, but it refuses to reproduce on x86-64, while the problem exists there as well. That refusal might explain that this got not discovered earlier despite the bug existing from day one of the rtmutex implementation more than 10 years ago.

Thanks to David for meticulously instrumenting the code and providing the information which allowed to decode this subtle problem.

---
 kernel/locking/rtmutex.c |   68 +++++++++++++++++++++++++++++++++++++++++++++--
 1 file changed, 66 insertions(+), 2 deletions(-)
kernel/locking/rtmutex.c +66 -2
@@ -65,8 +65,72 @@ static inline void clear_rt_mutex_waiter
 
 static void fixup_rt_mutex_waiters(struct rt_mutex *lock)
 {
-	if (!rt_mutex_has_waiters(lock))
-		clear_rt_mutex_waiters(lock);
+	unsigned long owner, *p = (unsigned long *) &lock->owner;
+
+	if (rt_mutex_has_waiters(lock))
+		return;
+
+	/*
+	 * The rbtree has no waiters enqueued, now make sure that the
+	 * lock->owner still has the waiters bit set, otherwise the
+	 * following can happen:
+	 *
+	 * CPU 0	CPU 1		CPU2
+	 * l->owner=T1
+	 *		rt_mutex_lock(l)
+	 *		lock(l->lock)
+	 *		l->owner = T1 | HAS_WAITERS;
+	 *		enqueue(T2)
+	 *		boost()
+	 *		  unlock(l->lock)
+	 *		block()
+	 *
+	 *				rt_mutex_lock(l)
+	 *				lock(l->lock)
+	 *				l->owner = T1 | HAS_WAITERS;
+	 *				enqueue(T3)
+	 *				boost()
+	 *				  unlock(l->lock)
+	 *				block()
+	 *		signal(->T2)	signal(->T3)
+	 *		lock(l->lock)
+	 *		dequeue(T2)
+	 *		deboost()
+	 *		  unlock(l->lock)
+	 *				lock(l->lock)
+	 *				dequeue(T3)
+	 *				 ==> wait list is empty
+	 *				deboost()
+	 *				 unlock(l->lock)
+	 *		lock(l->lock)
+	 *		fixup_rt_mutex_waiters()
+	 *		  if (wait_list_empty(l) {
+	 *		    l->owner = owner
+	 *		    owner = l->owner & ~HAS_WAITERS;
+	 *		      ==> l->owner = T1
+	 *		  }
+	 *				lock(l->lock)
+	 * rt_mutex_unlock(l)		fixup_rt_mutex_waiters()
+	 *				  if (wait_list_empty(l) {
+	 *				    owner = l->owner & ~HAS_WAITERS;
+	 * cmpxchg(l->owner, T1, NULL)
+	 *  ===> Success (l->owner = NULL)
+	 *
+	 *				    l->owner = owner
+	 *				      ==> l->owner = T1
+	 *				  }
+	 *
+	 * With the check for the waiter bit in place T3 on CPU2 will not
+	 * overwrite. All tasks fiddling with the waiters bit are
+	 * serialized by l->lock, so nothing else can modify the waiters
+	 * bit. If the bit is set then nothing can change l->owner either
+	 * so the simple RMW is safe. The cmpxchg() will simply fail if it
+	 * happens in the middle of the RMW because the waiters bit is
+	 * still set.
+	 */
+	owner = READ_ONCE(*p);
+	if (owner & RT_MUTEX_HAS_WAITERS)
+		WRITE_ONCE(*p, owner & ~RT_MUTEX_HAS_WAITERS);
 }
 
 /*
author maintainer
#10 lore raw

PATCH 10/33 locking/rtmutex: Use READ_ONCE() in rt_mutex_owner()

In reply to Greg Kroah-Hartman

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

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

From: Thomas Gleixner <[email protected]>

commit 1be5d4fa0af34fb7bafa205aeb59f5c7cc7a089d upstream.

While debugging the rtmutex unlock vs. dequeue race Will suggested to use READ_ONCE() in rt_mutex_owner() as it might race against the cmpxchg_release() in unlock_rt_mutex_safe().

Will: "It's a minor thing which will most likely not matter in practice"

Careful search did not unearth an actual problem in todays code, but it's better to be safe than surprised.

---
 kernel/locking/rtmutex_common.h |    5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)
kernel/locking/rtmutex_common.h +3 -2
@@ -75,8 +75,9 @@ task_top_pi_waiter(struct task_struct *p
 
 static inline struct task_struct *rt_mutex_owner(struct rt_mutex *lock)
 {
-	return (struct task_struct *)
-		((unsigned long)lock->owner & ~RT_MUTEX_OWNER_MASKALL);
+	unsigned long owner = (unsigned long) READ_ONCE(lock->owner);
+
+	return (struct task_struct *) (owner & ~RT_MUTEX_OWNER_MASKALL);
 }
 
 /*
author maintainer
#11 lore raw

PATCH 11/33 device-dax: fix private mapping restriction, permit read-only

In reply to Greg Kroah-Hartman

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

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

From: Dan Williams <[email protected]>

commit 325896ffdf90f7cbd59fb873b7ba20d60d1ddf3c upstream.

Hugh notes in response to commit 4cb19355ea19 "device-dax: fail all private mapping attempts":

"I think that is more restrictive than you intended: haven't tried, but I believe it rejects a PROT_READ, MAP_SHARED, O_RDONLY fd mmap, leaving no way to mmap /dev/dax without write permission to it."

Indeed it does restrict read-only mappings, switch to checking VM_MAYSHARE, not VM_SHARED.

Cc Dave Hansen <[email protected]>
Cc Pawel Lebioda <[email protected]>
Fixes 4cb19355ea19 ("device-dax: fail all private mapping attempts")
---
 drivers/dax/dax.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/dax/dax.c +1 -1
@@ -324,7 +324,7 @@ static int check_vma(struct dax_dev *dax
 		return -ENXIO;
 
 	/* prevent private mappings from being established */
-	if ((vma->vm_flags & VM_SHARED) != VM_SHARED) {
+	if ((vma->vm_flags & VM_MAYSHARE) != VM_MAYSHARE) {
 		dev_info(dev, "%s: %s: fail, attempted private mapping\n",
 				current->comm, func);
 		return -EINVAL;
author maintainer
#12 lore raw

PATCH 12/33 scsi: lpfc: fix oops/BUG in lpfc_sli_ringtxcmpl_put()

In reply to Greg Kroah-Hartman

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

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

From: Mauricio Faria de Oliveira <[email protected]>

commit 2319f847a8910cff1d46c9b66aa1dd7cc3e836a9 upstream.

The BUG_ON() recently introduced in lpfc_sli_ringtxcmpl_put() is hit in the lpfc_els_abort() > lpfc_sli_issue_abort_iotag() > lpfc_sli_abort_iotag_issue() function path [similar names], due to 'piocb->vport == NULL':

	BUG_ON(!piocb || !piocb->vport);

This happens because lpfc_sli_abort_iotag_issue() doesn't set the 'abtsiocbp->vport' pointer -- but this is not the problem.

Previously, lpfc_sli_ringtxcmpl_put() accessed 'piocb->vport' only if 'piocb->iocb.ulpCommand' is neither CMD_ABORT_XRI_CN nor CMD_CLOSE_XRI_CN, which are the only possible values for lpfc_sli_abort_iotag_issue():

    lpfc_sli_ringtxcmpl_put():

        if ((unlikely(pring->ringno == LPFC_ELS_RING)) &&
           (piocb->iocb.ulpCommand != CMD_ABORT_XRI_CN) &&
           (piocb->iocb.ulpCommand != CMD_CLOSE_XRI_CN) &&
            (!(piocb->vport->load_flag & FC_UNLOADING)))

    lpfc_sli_abort_iotag_issue():

        if (phba->link_state >= LPFC_LINK_UP)
                iabt->ulpCommand = CMD_ABORT_XRI_CN;
        else
                iabt->ulpCommand = CMD_CLOSE_XRI_CN;

So, this function path would not have hit this possible NULL pointer dereference before.

In order to fix this regression, move the second part of the BUG_ON() check prior to the pointer dereference that it does check for.

For reference, this is the stack trace observed. The problem happened because an unsolicited event was received - a PLOGI was received after our PLOGI was issued but not yet complete, so the discovery state machine goes on to sw-abort our PLOGI.

    kernel BUG at drivers/scsi/lpfc/lpfc_sli.c:1326!
    Oops: Exception in kernel mode, sig: 5 [#1]
    <...>
    NIP [...] lpfc_sli_ringtxcmpl_put+0x1c/0xf0 [lpfc]
    LR  [...] __lpfc_sli_issue_iocb_s4+0x188/0x200 [lpfc]
    Call Trace:
    [...] [...] __lpfc_sli_issue_iocb_s4+0xb0/0x200 [lpfc] (unreliable)
    [...] [...] lpfc_sli_issue_abort_iotag+0x2b4/0x350 [lpfc]
    [...] [...] lpfc_els_abort+0x1a8/0x4a0 [lpfc]
    [...] [...] lpfc_rcv_plogi+0x6d4/0x700 [lpfc]
    [...] [...] lpfc_rcv_plogi_plogi_issue+0xd8/0x1d0 [lpfc]
    [...] [...] lpfc_disc_state_machine+0xc0/0x2b0 [lpfc]
    [...] [...] lpfc_els_unsol_buffer+0xcc0/0x26c0 [lpfc]
    [...] [...] lpfc_els_unsol_event+0xa8/0x220 [lpfc]
    [...] [...] lpfc_complete_unsol_iocb+0xb8/0x138 [lpfc]
    [...] [...] lpfc_sli4_handle_received_buffer+0x6a0/0xec0 [lpfc]
    [...] [...] lpfc_sli_handle_slow_ring_event_s4+0x1c4/0x240 [lpfc]
    [...] [...] lpfc_sli_handle_slow_ring_event+0x24/0x40 [lpfc]
    [...] [...] lpfc_do_work+0xd88/0x1970 [lpfc]
    [...] [...] kthread+0x108/0x130
    [...] [...] ret_from_kernel_thread+0x5c/0xbc
    <...>
---
 drivers/scsi/lpfc/lpfc_sli.c |   14 ++++++++------
 1 file changed, 8 insertions(+), 6 deletions(-)
drivers/scsi/lpfc/lpfc_sli.c +8 -6
@@ -1323,18 +1323,20 @@ lpfc_sli_ringtxcmpl_put(struct lpfc_hba
 {
 	lockdep_assert_held(&phba->hbalock);
 
-	BUG_ON(!piocb || !piocb->vport);
+	BUG_ON(!piocb);
 
 	list_add_tail(&piocb->list, &pring->txcmplq);
 	piocb->iocb_flag |= LPFC_IO_ON_TXCMPLQ;
 
 	if ((unlikely(pring->ringno == LPFC_ELS_RING)) &&
 	   (piocb->iocb.ulpCommand != CMD_ABORT_XRI_CN) &&
-	   (piocb->iocb.ulpCommand != CMD_CLOSE_XRI_CN) &&
-	    (!(piocb->vport->load_flag & FC_UNLOADING)))
-		mod_timer(&piocb->vport->els_tmofunc,
-			  jiffies +
-			  msecs_to_jiffies(1000 * (phba->fc_ratov << 1)));
+	   (piocb->iocb.ulpCommand != CMD_CLOSE_XRI_CN)) {
+		BUG_ON(!piocb->vport);
+		if (!(piocb->vport->load_flag & FC_UNLOADING))
+			mod_timer(&piocb->vport->els_tmofunc,
+				  jiffies +
+				  msecs_to_jiffies(1000 * (phba->fc_ratov << 1)));
+	}
 
 	return 0;
 }
author maintainer
#13 lore raw

PATCH 13/33 sched/autogroup: Fix 64-bit kernel nice level adjustment

In reply to Greg Kroah-Hartman

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

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

From: Mike Galbraith <[email protected]>

commit 83929cce95251cc77e5659bf493bd424ae0e7a67 upstream.

Michael Kerrisk reported:

Quoted 3 lines

Regarding the previous paragraph... My tests indicate that writing *any* value to the autogroup [nice priority level] file causes the task group to get a lower priority.

Because autogroup didn't call the then meaningless scale_load()...

Autogroup nice level adjustment has been broken ever since load resolution was increased for 64-bit kernels. Use scale_load() to scale group weight.

Michael Kerrisk tested this patch to fix the problem:

Quoted 7 lines

Applied and tested against 4.9-rc6 on an Intel u7 (4 cores). Test setup:

Terminal window 1: running 40 CPU burner jobs
Terminal window 2: running 40 CPU burner jobs
Terminal window 1: running 1 CPU burner job

Quoted 8 lines

Demonstrated that:
* Writing "0" to the autogroup file for TW1 now causes no change to the rate at which the process on the terminal consume CPU.
* Writing -20 to the autogroup file for TW1 caused those processes to get the lion's share of CPU while TW2 TW3 get a tiny amount.
* Writing -20 to the autogroup files for TW1 and TW3 allowed the process on TW3 to get as much CPU as it was getting as when the autogroup nice values for both terminals were 0.

---
 kernel/sched/auto_group.c |    4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)
kernel/sched/auto_group.c +3 -1
@@ -192,6 +192,7 @@ int proc_sched_autogroup_set_nice(struct
 {
 	static unsigned long next = INITIAL_JIFFIES;
 	struct autogroup *ag;
+	unsigned long shares;
 	int err;
 
 	if (nice < MIN_NICE || nice > MAX_NICE)
@@ -210,9 +211,10 @@ int proc_sched_autogroup_set_nice(struct
 
 	next = HZ / 10 + jiffies;
 	ag = autogroup_task_get(p);
+	shares = scale_load(sched_prio_to_weight[nice + 20]);
 
 	down_write(&ag->lock);
-	err = sched_group_set_shares(ag->tg, sched_prio_to_weight[nice + 20]);
+	err = sched_group_set_shares(ag->tg, shares);
 	if (!err)
 		ag->nice = nice;
 	up_write(&ag->lock);
author maintainer
#14 lore raw

PATCH 14/33 vhost-vsock: fix orphan connection reset

In reply to Greg Kroah-Hartman

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

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

From: Peng Tao <[email protected]>

commit c4587631c7bad47c045e081d1553cd73a23be59a upstream.

local_addr.svm_cid is host cid. We should check guest cid instead, which is remote_addr.svm_cid. Otherwise we end up resetting all connections to all guests.

---
 drivers/vhost/vsock.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/vhost/vsock.c +1 -1
@@ -506,7 +506,7 @@ static void vhost_vsock_reset_orphans(st
 	 * executing.
 	 */
 
-	if (!vhost_vsock_get(vsk->local_addr.svm_cid)) {
+	if (!vhost_vsock_get(vsk->remote_addr.svm_cid)) {
 		sock_set_flag(sk, SOCK_DONE);
 		vsk->peer_shutdown = SHUTDOWN_MASK;
 		sk->sk_state = SS_UNCONNECTED;
author maintainer
#15 lore raw

PATCH 15/33 perf/x86: Fix full width counter, counter overflow

In reply to Greg Kroah-Hartman

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

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

From: Peter Zijlstra (Intel) <[email protected]>

commit 7f612a7f0bc13a2361a152862435b7941156b6af upstream.

Lukasz reported that perf stat counters overflow handling is broken on KNL/SLM.

Both these parts have full_width_write set, and that does indeed have a problem. In order to deal with counter wrap, we must sample the counter at at least half the counter period (see also the sampling theorem) such that we can unambiguously reconstruct the count.

However commit:

069e0c3c4058 ("perf/x86/intel: Support full width counting")

sets the sampling interval to the full period, not half.

Fixing that exposes another issue, in that we must not sign extend the delta value when we shift it right; the counter cannot have decremented after all.

With both these issues fixed, counter overflow functions correctly again.

Cc Alexander Shishkin <[email protected]>
Cc Arnaldo Carvalho de Melo <[email protected]>
Cc Jiri Olsa <[email protected]>
Cc Linus Torvalds <[email protected]>
Cc Peter Zijlstra <[email protected]>
Cc Stephane Eranian <[email protected]>
Cc Thomas Gleixner <[email protected]>
Cc Vince Weaver <[email protected]>
Fixes 069e0c3c4058 ("perf/x86/intel: Support full width counting")
---
 arch/x86/events/core.c       |    2 +-
 arch/x86/events/intel/core.c |    2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)
arch/x86/events/core.c +1 -1
@@ -68,7 +68,7 @@ u64 x86_perf_event_update(struct perf_ev
 	int shift = 64 - x86_pmu.cntval_bits;
 	u64 prev_raw_count, new_raw_count;
 	int idx = hwc->idx;
-	s64 delta;
+	u64 delta;
 
 	if (idx == INTEL_PMC_IDX_FIXED_BTS)
 		return 0;
arch/x86/events/intel/core.c +1 -1
@@ -4024,7 +4024,7 @@ __init int intel_pmu_init(void)
 
 	/* Support full width counters using alternative MSR range */
 	if (x86_pmu.intel_cap.full_width_write) {
-		x86_pmu.max_period = x86_pmu.cntval_mask;
+		x86_pmu.max_period = x86_pmu.cntval_mask >> 1;
 		x86_pmu.perfctr = MSR_IA32_PMC0;
 		pr_cont("full-width counters, ");
 	}
author maintainer
#16 lore raw

PATCH 16/33 acpi, nfit: fix extended status translations for ACPI DSMs

In reply to Greg Kroah-Hartman

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

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

From: Vishal Verma <[email protected]>

commit 9a901f5495e26e691c7d0ea7b6057a2f3e6330ed upstream.

ACPI DSMs can have an 'extended' status which can be non-zero to convey additional information about the command. In the xlat_status routine, where we translate the command statuses, we were returning an error for a non-zero extended status, even if the primary status indicated success.

Return from each command's 'case' once we have verified both its status and extend status are good.

Fixes 11294d63ac91 ("nfit: fail DSMs that return non-zero status by default")
---
 drivers/acpi/nfit/core.c |    8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)
drivers/acpi/nfit/core.c +4 -4
@@ -113,7 +113,7 @@ static int xlat_status(void *buf, unsign
 		flags = ND_ARS_PERSISTENT | ND_ARS_VOLATILE;
 		if ((status >> 16 & flags) == 0)
 			return -ENOTTY;
-		break;
+		return 0;
 	case ND_CMD_ARS_START:
 		/* ARS is in progress */
 		if ((status & 0xffff) == NFIT_ARS_START_BUSY)
@@ -122,7 +122,7 @@ static int xlat_status(void *buf, unsign
 		/* Command failed */
 		if (status & 0xffff)
 			return -EIO;
-		break;
+		return 0;
 	case ND_CMD_ARS_STATUS:
 		ars_status = buf;
 		/* Command failed */
@@ -154,7 +154,7 @@ static int xlat_status(void *buf, unsign
 		/* Unknown status */
 		if (status >> 16)
 			return -EIO;
-		break;
+		return 0;
 	case ND_CMD_CLEAR_ERROR:
 		clear_err = buf;
 		if (status & 0xffff)
@@ -163,7 +163,7 @@ static int xlat_status(void *buf, unsign
 			return -EIO;
 		if (clear_err->length > clear_err->cleared)
 			return clear_err->cleared;
-		break;
+		return 0;
 	default:
 		break;
 	}
author maintainer
#17 lore raw

PATCH 17/33 acpi, nfit, libnvdimm: fix / harden ars_status output length handling

In reply to Greg Kroah-Hartman

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

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

From: Dan Williams <[email protected]>

commit efda1b5d87cbc3d8816f94a3815b413f1868e10d upstream.

Given ambiguities in the ACPI 6.1 definition of the "Output (Size)" field of the ARS (Address Range Scrub) Status command, a firmware implementation may in practice return 0, 4, or 8 to indicate that there is no output payload to process.

The specification states "Size of Output Buffer in bytes, including this field.". However, 'Output Buffer' is also the name of the entire payload, and earlier in the specification it states "Max Query ARS Status Output Buffer Size: Maximum size of buffer (including the Status and Extended Status fields)".

Without this fix if the BIOS happens to return 0 it causes memory corruption as evidenced by this result from the acpi_nfit_ctl() unit test.

ars_status00000000: 00020000 00000000 ........

 BUG: stack guard page was hit at ffffc90001750000 (stack is ffffc9000174c000..ffffc9000174ffff)
 kernel stack overflow (page fault): 0000 [#1] SMP DEBUG_PAGEALLOC
 task: ffff8803332d2ec0 task.stack: ffffc9000174c000
 RIP: 0010:[<ffffffff814cfe72>]  [<ffffffff814cfe72>] __memcpy+0x12/0x20
 RSP: 0018:ffffc9000174f9a8  EFLAGS: 00010246
 RAX: ffffc9000174fab8 RBX: 0000000000000000 RCX: 000000001fffff56
 RDX: 0000000000000000 RSI: ffff8803231f5a08 RDI: ffffc90001750000
 RBP: ffffc9000174fa88 R08: ffffc9000174fab0 R09: ffff8803231f54b8
 R10: 0000000000000008 R11: 0000000000000001 R12: 0000000000000000
 R13: 0000000000000000 R14: 0000000000000003 R15: ffff8803231f54a0
 FS:  00007f3a611af640(0000) GS:ffff88033ed00000(0000) knlGS:0000000000000000
 CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
 CR2: ffffc90001750000 CR3: 0000000325b20000 CR4: 00000000000406e0
 Stack:
  ffffffffa00bc60d 0000000000000008 ffffc90000000001 ffffc9000174faac
  0000000000000292 ffffffffa00c24e4 ffffffffa00c2914 0000000000000000
  0000000000000000 ffffffff00000003 ffff880331ae8ad0 0000000800000246
 Call Trace:
  [<ffffffffa00bc60d>] ? acpi_nfit_ctl+0x49d/0x750 [nfit]
  [<ffffffffa01f4fe0>] nfit_test_probe+0x670/0xb1b [nfit_test]
Fixes 747ffe11b440 ("libnvdimm, tools/testing/nvdimm: fix 'ars_status' output buffer sizing")
---
 drivers/acpi/nfit/core.c  |    3 ++-
 drivers/nvdimm/bus.c      |   25 ++++++++++++++++++++-----
 include/linux/libnvdimm.h |    2 +-
 3 files changed, 23 insertions(+), 7 deletions(-)
drivers/acpi/nfit/core.c +2 -1
@@ -298,7 +298,8 @@ static int acpi_nfit_ctl(struct nvdimm_b
 
 	for (i = 0, offset = 0; i < desc->out_num; i++) {
 		u32 out_size = nd_cmd_out_size(nvdimm, cmd, desc, i, buf,
-				(u32 *) out_obj->buffer.pointer);
+				(u32 *) out_obj->buffer.pointer,
+				out_obj->buffer.length - offset);
 
 		if (offset + out_size > out_obj->buffer.length) {
 			dev_dbg(dev, "%s:%s output object underflow cmd: %s field: %d\n",
drivers/nvdimm/bus.c +20 -5
@@ -715,7 +715,7 @@ EXPORT_SYMBOL_GPL(nd_cmd_in_size);
 
 u32 nd_cmd_out_size(struct nvdimm *nvdimm, int cmd,
 		const struct nd_cmd_desc *desc, int idx, const u32 *in_field,
-		const u32 *out_field)
+		const u32 *out_field, unsigned long remainder)
 {
 	if (idx >= desc->out_num)
 		return UINT_MAX;
@@ -727,9 +727,24 @@ u32 nd_cmd_out_size(struct nvdimm *nvdim
 		return in_field[1];
 	else if (nvdimm && cmd == ND_CMD_VENDOR && idx == 2)
 		return out_field[1];
-	else if (!nvdimm && cmd == ND_CMD_ARS_STATUS && idx == 2)
-		return out_field[1] - 8;
-	else if (cmd == ND_CMD_CALL) {
+	else if (!nvdimm && cmd == ND_CMD_ARS_STATUS && idx == 2) {
+		/*
+		 * Per table 9-276 ARS Data in ACPI 6.1, out_field[1] is
+		 * "Size of Output Buffer in bytes, including this
+		 * field."
+		 */
+		if (out_field[1] < 4)
+			return 0;
+		/*
+		 * ACPI 6.1 is ambiguous if 'status' is included in the
+		 * output size. If we encounter an output size that
+		 * overshoots the remainder by 4 bytes, assume it was
+		 * including 'status'.
+		 */
+		if (out_field[1] - 8 == remainder)
+			return remainder;
+		return out_field[1] - 4;
+	} else if (cmd == ND_CMD_CALL) {
 		struct nd_cmd_pkg *pkg = (struct nd_cmd_pkg *) in_field;
 
 		return pkg->nd_size_out;
@@ -876,7 +891,7 @@ static int __nd_ioctl(struct nvdimm_bus
 	/* process an output envelope */
 	for (i = 0; i < desc->out_num; i++) {
 		u32 out_size = nd_cmd_out_size(nvdimm, cmd, desc, i,
-				(u32 *) in_env, (u32 *) out_env);
+				(u32 *) in_env, (u32 *) out_env, 0);
 		u32 copy;
 
 		if (out_size == UINT_MAX) {
include/linux/libnvdimm.h +1 -1
@@ -153,7 +153,7 @@ u32 nd_cmd_in_size(struct nvdimm *nvdimm
 		const struct nd_cmd_desc *desc, int idx, void *buf);
 u32 nd_cmd_out_size(struct nvdimm *nvdimm, int cmd,
 		const struct nd_cmd_desc *desc, int idx, const u32 *in_field,
-		const u32 *out_field);
+		const u32 *out_field, unsigned long remainder);
 int nvdimm_bus_check_dimm_count(struct nvdimm_bus *nvdimm_bus, int dimm_count);
 struct nd_region *nvdimm_pmem_region_create(struct nvdimm_bus *nvdimm_bus,
 		struct nd_region_desc *ndr_desc);
author maintainer
#18 lore raw

PATCH 18/33 acpi, nfit: validate ars_status output buffer size

In reply to Greg Kroah-Hartman

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

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

From: Dan Williams <[email protected]>

commit 82aa37cf09867c5e2c0326649d570e5b25c1189a upstream.

If an ARS Status command returns truncated output, do not process partial records or otherwise consume non-status fields.

Fixes 0caeef63e6d2 ("libnvdimm: Add a poison list and export badblocks")
---
 drivers/acpi/nfit/core.c |   21 +++++++++++++++++----
 1 file changed, 17 insertions(+), 4 deletions(-)
drivers/acpi/nfit/core.c +17 -4
@@ -146,7 +146,8 @@ static int xlat_status(void *buf, unsign
 		 * then just continue with the returned results.
 		 */
 		if (status == NFIT_ARS_STATUS_INTR) {
-			if (ars_status->flags & NFIT_ARS_F_OVERFLOW)
+			if (ars_status->out_length >= 40 && (ars_status->flags
+						& NFIT_ARS_F_OVERFLOW))
 				return -ENOSPC;
 			return 0;
 		}
@@ -1858,19 +1859,32 @@ static int ars_get_status(struct acpi_nf
 	return cmd_rc;
 }
 
-static int ars_status_process_records(struct nvdimm_bus *nvdimm_bus,
+static int ars_status_process_records(struct acpi_nfit_desc *acpi_desc,
 		struct nd_cmd_ars_status *ars_status)
 {
+	struct nvdimm_bus *nvdimm_bus = acpi_desc->nvdimm_bus;
 	int rc;
 	u32 i;
 
+	/*
+	 * First record starts at 44 byte offset from the start of the
+	 * payload.
+	 */
+	if (ars_status->out_length < 44)
+		return 0;
 	for (i = 0; i < ars_status->num_records; i++) {
+		/* only process full records */
+		if (ars_status->out_length
+				< 44 + sizeof(struct nd_ars_record) * (i + 1))
+			break;
 		rc = nvdimm_bus_add_poison(nvdimm_bus,
 				ars_status->records[i].err_address,
 				ars_status->records[i].length);
 		if (rc)
 			return rc;
 	}
+	if (i < ars_status->num_records)
+		dev_warn(acpi_desc->dev, "detected truncated ars results\n");
 
 	return 0;
 }
@@ -2123,8 +2137,7 @@ static int acpi_nfit_query_poison(struct
 	if (rc < 0 && rc != -ENOSPC)
 		return rc;
 
-	if (ars_status_process_records(acpi_desc->nvdimm_bus,
-				acpi_desc->ars_status))
+	if (ars_status_process_records(acpi_desc, acpi_desc->ars_status))
 		return -ENOMEM;
 
 	return 0;
author maintainer
#19 lore raw

PATCH 19/33 acpi, nfit: fix bus vs dimm confusion in xlat_status

In reply to Greg Kroah-Hartman

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

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

From: Dan Williams <[email protected]>

commit d6eb270c57fef35798525004ddf2ac5dcdadd43b upstream.

Given dimms and bus commands share the same command number space we need to be careful that we are translating status in the correct context. Otherwise we can, for example, fail an ND_CMD_GET_CONFIG_SIZE command because max_xfer is zero. It fails because that condition erroneously correlates with the 'cleared == 0' failure of ND_CMD_CLEAR_ERROR.

Fixes aef253382266 ("libnvdimm, nfit: centralize command status translation")
---
 drivers/acpi/nfit/core.c |   17 ++++++++++++++---
 1 file changed, 14 insertions(+), 3 deletions(-)
drivers/acpi/nfit/core.c +14 -3
@@ -94,7 +94,7 @@ static struct acpi_device *to_acpi_dev(s
 	return to_acpi_device(acpi_desc->dev);
 }
 
-static int xlat_status(void *buf, unsigned int cmd, u32 status)
+static int xlat_bus_status(void *buf, unsigned int cmd, u32 status)
 {
 	struct nd_cmd_clear_error *clear_err;
 	struct nd_cmd_ars_status *ars_status;
@@ -175,6 +175,16 @@ static int xlat_status(void *buf, unsign
 	return 0;
 }
 
+static int xlat_status(struct nvdimm *nvdimm, void *buf, unsigned int cmd,
+		u32 status)
+{
+	if (!nvdimm)
+		return xlat_bus_status(buf, cmd, status);
+	if (status)
+		return -EIO;
+	return 0;
+}
+
 static int acpi_nfit_ctl(struct nvdimm_bus_descriptor *nd_desc,
 		struct nvdimm *nvdimm, unsigned int cmd, void *buf,
 		unsigned int buf_len, int *cmd_rc)
@@ -335,7 +345,8 @@ static int acpi_nfit_ctl(struct nvdimm_b
 			 */
 			rc = buf_len - offset - in_buf.buffer.length;
 			if (cmd_rc)
-				*cmd_rc = xlat_status(buf, cmd, fw_status);
+				*cmd_rc = xlat_status(nvdimm, buf, cmd,
+						fw_status);
 		} else {
 			dev_err(dev, "%s:%s underrun cmd: %s buf_len: %d out_len: %d\n",
 					__func__, dimm_name, cmd_name, buf_len,
@@ -345,7 +356,7 @@ static int acpi_nfit_ctl(struct nvdimm_b
 	} else {
 		rc = 0;
 		if (cmd_rc)
-			*cmd_rc = xlat_status(buf, cmd, fw_status);
+			*cmd_rc = xlat_status(nvdimm, buf, cmd, fw_status);
 	}
 
  out:
author maintainer
#20 lore raw

PATCH 20/33 crypto: marvell - Dont copy hash operation twice into the SRAM

In reply to Greg Kroah-Hartman

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

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

From: Romain Perier <[email protected]>

commit 68c7f8c1c4e9b06e6b153fa3e9e0cda2ef5aaed8 upstream.

No need to copy the template of an hash operation twice into the SRAM from the step function.

Fixes commit 85030c5168f1 ("crypto: marvell - Add support for chai...")
---
 drivers/crypto/marvell/hash.c |    3 ---
 1 file changed, 3 deletions(-)
drivers/crypto/marvell/hash.c +0 -3
@@ -172,9 +172,6 @@ static void mv_cesa_ahash_std_step(struc
 	for (i = 0; i < digsize / 4; i++)
 		writel_relaxed(creq->state[i], engine->regs + CESA_IVDIG(i));
 
-	mv_cesa_adjust_op(engine, &creq->op_tmpl);
-	memcpy_toio(engine->sram, &creq->op_tmpl, sizeof(creq->op_tmpl));
-
 	if (creq->cache_ptr)
 		memcpy_toio(engine->sram + CESA_SA_DATA_SRAM_OFFSET,
 			    creq->cache, creq->cache_ptr);
author maintainer
#21 lore raw

PATCH 22/33 crypto: mcryptd - Check mcryptd algorithm compatibility

In reply to Greg Kroah-Hartman

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

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

From: tim <[email protected]>

commit 48a992727d82cb7db076fa15d372178743b1f4cd upstream.

Algorithms not compatible with mcryptd could be spawned by mcryptd with a direct crypto_alloc_tfm invocation using a "mcryptd(alg)" name construct. This causes mcryptd to crash the kernel if an arbitrary "alg" is incompatible and not intended to be used with mcryptd. It is an issue if AF_ALG tries to spawn mcryptd(alg) to expose it externally. But such algorithms must be used internally and not be exposed.

We added a check to enforce that only internal algorithms are allowed with mcryptd at the time mcryptd is spawning an algorithm.

---
 crypto/mcryptd.c |   19 ++++++++++++-------
 1 file changed, 12 insertions(+), 7 deletions(-)
crypto/mcryptd.c +12 -7
@@ -254,18 +254,22 @@ out_free_inst:
 	goto out;
 }
 
-static inline void mcryptd_check_internal(struct rtattr **tb, u32 *type,
+static inline bool mcryptd_check_internal(struct rtattr **tb, u32 *type,
 					  u32 *mask)
 {
 	struct crypto_attr_type *algt;
 
 	algt = crypto_get_attr_type(tb);
 	if (IS_ERR(algt))
-		return;
-	if ((algt->type & CRYPTO_ALG_INTERNAL))
-		*type |= CRYPTO_ALG_INTERNAL;
-	if ((algt->mask & CRYPTO_ALG_INTERNAL))
-		*mask |= CRYPTO_ALG_INTERNAL;
+		return false;
+
+	*type |= algt->type & CRYPTO_ALG_INTERNAL;
+	*mask |= algt->mask & CRYPTO_ALG_INTERNAL;
+
+	if (*type & *mask & CRYPTO_ALG_INTERNAL)
+		return true;
+	else
+		return false;
 }
 
 static int mcryptd_hash_init_tfm(struct crypto_tfm *tfm)
@@ -492,7 +496,8 @@ static int mcryptd_create_hash(struct cr
 	u32 mask = 0;
 	int err;
 
-	mcryptd_check_internal(tb, &type, &mask);
+	if (!mcryptd_check_internal(tb, &type, &mask))
+		return -EINVAL;
 
 	halg = ahash_attr_alg(tb[1], type, mask);
 	if (IS_ERR(halg))
author maintainer
#22 lore raw

PATCH 23/33 crypto: marvell - Dont corrupt state of an STD req for re-stepped ahash

In reply to Greg Kroah-Hartman

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

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

From: Romain Perier <[email protected]>

commit 9e5f7a149e00d211177f6de8be427ebc72a1c363 upstream.

mv_cesa_hash_std_step() copies the creq->state into the SRAM at each step, but this is only required on the first one. By doing that, we overwrite the engine state, and get erroneous results when the crypto request is split in several chunks to fit in the internal SRAM.

This commit changes the function to copy the state only on the first step.

Fixes commit 2786cee8e50b ("crypto: marvell - Move SRAM I/O op...")
---
 drivers/crypto/marvell/hash.c |    8 +++++---
 1 file changed, 5 insertions(+), 3 deletions(-)
drivers/crypto/marvell/hash.c +5 -3
@@ -168,9 +168,11 @@ static void mv_cesa_ahash_std_step(struc
 	mv_cesa_adjust_op(engine, &creq->op_tmpl);
 	memcpy_toio(engine->sram, &creq->op_tmpl, sizeof(creq->op_tmpl));
 
-	digsize = crypto_ahash_digestsize(crypto_ahash_reqtfm(req));
-	for (i = 0; i < digsize / 4; i++)
-		writel_relaxed(creq->state[i], engine->regs + CESA_IVDIG(i));
+	if (!sreq->offset) {
+		digsize = crypto_ahash_digestsize(crypto_ahash_reqtfm(req));
+		for (i = 0; i < digsize / 4; i++)
+			writel_relaxed(creq->state[i], engine->regs + CESA_IVDIG(i));
+	}
 
 	if (creq->cache_ptr)
 		memcpy_toio(engine->sram + CESA_SA_DATA_SRAM_OFFSET,
author maintainer
#23 lore raw

PATCH 24/33 can: raw: raw_setsockopt: limit number of can_filter that can be set

In reply to Greg Kroah-Hartman

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

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

From: Marc Kleine-Budde <[email protected]>

commit 332b05ca7a438f857c61a3c21a88489a21532364 upstream.

This patch adds a check to limit the number of can_filters that can be set via setsockopt on CAN_RAW sockets. Otherwise allocations > MAX_ORDER are not prevented resulting in a warning.

Reference: https://lkml.org/lkml/2016/12/2/230

---
 include/uapi/linux/can.h |    1 +
 net/can/raw.c            |    3 +++
 2 files changed, 4 insertions(+)
include/uapi/linux/can.h +1 -0
@@ -196,5 +196,6 @@ struct can_filter {
 };
 
 #define CAN_INV_FILTER 0x20000000U /* to be set in can_filter.can_id */
+#define CAN_RAW_FILTER_MAX 512 /* maximum number of can_filter set via setsockopt() */
 
 #endif /* !_UAPI_CAN_H */
net/can/raw.c +3 -0
@@ -499,6 +499,9 @@ static int raw_setsockopt(struct socket
 		if (optlen % sizeof(struct can_filter) != 0)
 			return -EINVAL;
 
+		if (optlen > CAN_RAW_FILTER_MAX * sizeof(struct can_filter))
+			return -EINVAL;
+
 		count = optlen / sizeof(struct can_filter);
 
 		if (count > 1) {
author maintainer
#24 lore raw

PATCH 26/33 Revert "ACPI: Execute _PTS before system reboot"

In reply to Greg Kroah-Hartman

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

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

From: Rafael J. Wysocki <[email protected]>

commit 9713adc2a1a5488f4889c657a0c0ce0c16056d3c upstream.

Revert commit 2c85025c75df (ACPI: Execute _PTS before system reboot) as it is reported to cause poweroff and reboot to hang on Dell Latitude E7250.

---
 drivers/acpi/sleep.c |   29 ++++++-----------------------
 1 file changed, 6 insertions(+), 23 deletions(-)
drivers/acpi/sleep.c +6 -23
@@ -47,32 +47,15 @@ static void acpi_sleep_tts_switch(u32 ac
 	}
 }
 
-static void acpi_sleep_pts_switch(u32 acpi_state)
-{
-	acpi_status status;
-
-	status = acpi_execute_simple_method(NULL, "\\_PTS", acpi_state);
-	if (ACPI_FAILURE(status) && status != AE_NOT_FOUND) {
-		/*
-		 * OS can't evaluate the _PTS object correctly. Some warning
-		 * message will be printed. But it won't break anything.
-		 */
-		printk(KERN_NOTICE "Failure in evaluating _PTS object\n");
-	}
-}
-
-static int sleep_notify_reboot(struct notifier_block *this,
+static int tts_notify_reboot(struct notifier_block *this,
 			unsigned long code, void *x)
 {
 	acpi_sleep_tts_switch(ACPI_STATE_S5);
-
-	acpi_sleep_pts_switch(ACPI_STATE_S5);
-
 	return NOTIFY_DONE;
 }
 
-static struct notifier_block sleep_notifier = {
-	.notifier_call	= sleep_notify_reboot,
+static struct notifier_block tts_notifier = {
+	.notifier_call	= tts_notify_reboot,
 	.next		= NULL,
 	.priority	= 0,
 };
@@ -916,9 +899,9 @@ int __init acpi_sleep_init(void)
 	pr_info(PREFIX "(supports%s)\n", supported);
 
 	/*
-	 * Register the sleep_notifier to reboot notifier list so that the _TTS
-	 * and _PTS object can also be evaluated when the system enters S5.
+	 * Register the tts_notifier to reboot notifier list so that the _TTS
+	 * object can also be evaluated when the system enters S5.
 	 */
-	register_reboot_notifier(&sleep_notifier);
+	register_reboot_notifier(&tts_notifier);
 	return 0;
 }
author maintainer
#25 lore raw

PATCH 27/33 ARM: dts: orion5x: fix number of sata port for linkstation ls-gl

In reply to Greg Kroah-Hartman

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

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

From: Roger Shimizu <[email protected]>

commit 038ccb3e8cee52e07dc118ff99f47eaebc1d0746 upstream.

Bug report from Debian [0] shows there's minor changed model of Linkstation LS-GL that uses the 2nd SATA port of the SoC. So it's necessary to enable two SATA ports, though for that specific model only the 2nd one is used.

[0] https://bugs.debian.org/845611

Fixes b1742ffa9ddb ("ARM: dts: orion5x: add device tree for buffalo linkstation ls-gl")
---
 arch/arm/boot/dts/orion5x-linkstation-lsgl.dts |    4 ++++
 1 file changed, 4 insertions(+)
arch/arm/boot/dts/orion5x-linkstation-lsgl.dts +4 -0
@@ -82,6 +82,10 @@
 	gpios = <&gpio0 9 GPIO_ACTIVE_HIGH>;
 };
 
+&sata {
+	nr-ports = <2>;
+};
+
 &ehci1 {
 	status = "okay";
 };
author maintainer
#26 lore raw

PATCH 28/33 ARM: dts: imx7d: fix LCDIF clock assignment

In reply to Greg Kroah-Hartman

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

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

From: Stefan Agner <[email protected]>

commit 4b707fa00a80b19b80bc8df6f1cbf4bdd9c91402 upstream.

The eLCDIF IP of the i.MX 7 SoC knows multiple clocks and lists them separately:

Clock      Clock Root              Description
apb_clk    MAIN_AXI_CLK_ROOT       AXI clock
pix_clk    LCDIF_PIXEL_CLK_ROOT    Pixel clock
ipg_clk_s  MAIN_AXI_CLK_ROOT       Peripheral access clock

All of them are switched by a single gate, which is part of the IMX7D_LCDIF_PIXEL_ROOT_CLK clock. Hence using that clock also for the AXI bus clock (clock-name "axi") makes sure the gate gets enabled when accessing registers.

There seem to be no separate AXI display clock, and the clock is optional. Hence remove the dummy clock.

This fixes kernel freezes when starting the X-Server (which disables/re-enables the display controller).

Fixes e8ed73f691bd ("ARM: dts: imx7d: add lcdif support")
---
 arch/arm/boot/dts/imx7s.dtsi |    5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)
arch/arm/boot/dts/imx7s.dtsi +2 -3
@@ -640,9 +640,8 @@
 				reg = <0x30730000 0x10000>;
 				interrupts = <GIC_SPI 5 IRQ_TYPE_LEVEL_HIGH>;
 				clocks = <&clks IMX7D_LCDIF_PIXEL_ROOT_CLK>,
-					<&clks IMX7D_CLK_DUMMY>,
-					<&clks IMX7D_CLK_DUMMY>;
-				clock-names = "pix", "axi", "disp_axi";
+					<&clks IMX7D_LCDIF_PIXEL_ROOT_CLK>;
+				clock-names = "pix", "axi";
 				status = "disabled";
 			};
 		};
author maintainer
#27 lore raw

PATCH 29/33 ceph: dont set req->r_locked_dir in ceph_d_revalidate

In reply to Greg Kroah-Hartman

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

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

From: Jeff Layton <[email protected]>

commit c3f4688a08fd86f1bf8e055724c84b7a40a09733 upstream.

This function sets req->r_locked_dir which is supposed to indicate to ceph_fill_trace that the parent's i_rwsem is locked for write. Unfortunately, there is no guarantee that the dir will be locked when d_revalidate is called, so we really don't want ceph_fill_trace to do any dcache manipulation from this context. Clear req->r_locked_dir since it's clearly not safe to do that.

What we really want to know with d_revalidate is whether the dentry still points to the same inode. ceph_fill_trace installs a pointer to the inode in req->r_target_inode, so we can just compare that to d_inode(dentry) to see if it's the same one after the lookup.

Also, since we aren't generally interested in the parent here, we can switch to using a GETATTR to hint that to the MDS, which also means that we only need to reserve one cap.

Finally, just remove the d_unhashed check. That's really outside the purview of a filesystem's d_revalidate. If the thing became unhashed while we're checking it, then that's up to the VFS to handle anyway.

---
 fs/ceph/dir.c |   24 ++++++++++++++----------
 1 file changed, 14 insertions(+), 10 deletions(-)
fs/ceph/dir.c +14 -10
@@ -1257,26 +1257,30 @@ static int ceph_d_revalidate(struct dent
 			return -ECHILD;
 
 		op = ceph_snap(dir) == CEPH_SNAPDIR ?
-			CEPH_MDS_OP_LOOKUPSNAP : CEPH_MDS_OP_LOOKUP;
+			CEPH_MDS_OP_LOOKUPSNAP : CEPH_MDS_OP_GETATTR;
 		req = ceph_mdsc_create_request(mdsc, op, USE_ANY_MDS);
 		if (!IS_ERR(req)) {
 			req->r_dentry = dget(dentry);
-			req->r_num_caps = 2;
+			req->r_num_caps = op == CEPH_MDS_OP_GETATTR ? 1 : 2;
 
 			mask = CEPH_STAT_CAP_INODE | CEPH_CAP_AUTH_SHARED;
 			if (ceph_security_xattr_wanted(dir))
 				mask |= CEPH_CAP_XATTR_SHARED;
 			req->r_args.getattr.mask = mask;
 
-			req->r_locked_dir = dir;
 			err = ceph_mdsc_do_request(mdsc, NULL, req);
-			if (err == 0 || err == -ENOENT) {
-				if (dentry == req->r_dentry) {
-					valid = !d_unhashed(dentry);
-				} else {
-					d_invalidate(req->r_dentry);
-					err = -EAGAIN;
-				}
+			switch (err) {
+			case 0:
+				if (d_really_is_positive(dentry) &&
+				    d_inode(dentry) == req->r_target_inode)
+					valid = 1;
+				break;
+			case -ENOENT:
+				if (d_really_is_negative(dentry))
+					valid = 1;
+				/* Fallthrough */
+			default:
+				break;
 			}
 			ceph_mdsc_put_request(req);
 			dout("d_revalidate %p lookup result=%d\n",
author maintainer
#28 lore raw

PATCH 30/33 m68k: Fix ndelay() macro

In reply to Greg Kroah-Hartman

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

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

From: Boris Brezillon <[email protected]>

commit 7e251bb21ae08ca2e4fb28cc0981fac2685a8efa upstream.

The current ndelay() macro definition has an extra semi-colon at the end of the line thus leading to a compilation error when ndelay is used in a conditional block without curly braces like this one:

	if (cond)
		ndelay(t);
	else
		...

which, after the preprocessor pass gives:

	if (cond)
		m68k_ndelay(t);;
	else
		...

thus leading to the following gcc error:

error: 'else' without a previous 'if'

Remove this extra semi-colon.

Fixes c8ee038bd1488 ("m68k: Implement ndelay() based on the existing udelay() logic")
---
 arch/m68k/include/asm/delay.h |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
arch/m68k/include/asm/delay.h +1 -1
@@ -114,6 +114,6 @@ static inline void __udelay(unsigned lon
  */
 #define	HZSCALE		(268435456 / (1000000 / HZ))
 
-#define ndelay(n) __delay(DIV_ROUND_UP((n) * ((((HZSCALE) >> 11) * (loops_per_jiffy >> 11)) >> 6), 1000));
+#define ndelay(n) __delay(DIV_ROUND_UP((n) * ((((HZSCALE) >> 11) * (loops_per_jiffy >> 11)) >> 6), 1000))
 
 #endif /* defined(_M68K_DELAY_H) */
author maintainer
#29 lore raw

PATCH 31/33 batman-adv: Check for alloc errors when preparing TT local data

In reply to Greg Kroah-Hartman

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

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

From: Sven Eckelmann <[email protected]>

commit c2d0f48a13e53b4747704c9e692f5e765e52041a upstream.

batadv_tt_prepare_tvlv_local_data can fail to allocate the memory for the new TVLV block. The caller is informed about this problem with the returned length of 0. Not checking this value results in an invalid memory access when either tt_data or tt_change is accessed.

Fixes 7ea7b4a14275 ("batman-adv: make the TT CRC logic VLAN specific")
---
 net/batman-adv/translation-table.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
net/batman-adv/translation-table.c +2 -2
@@ -2849,7 +2849,7 @@ static bool batadv_send_my_tt_response(s
 							     &tvlv_tt_data,
 							     &tt_change,
 							     &tt_len);
-		if (!tt_len)
+		if (!tt_len || !tvlv_len)
 			goto unlock;
 
 		/* Copy the last orig_node's OGM buffer */
@@ -2867,7 +2867,7 @@ static bool batadv_send_my_tt_response(s
 							     &tvlv_tt_data,
 							     &tt_change,
 							     &tt_len);
-		if (!tt_len)
+		if (!tt_len || !tvlv_len)
 			goto out;
 
 		/* fill the rest of the tvlv with the real TT entries */
author maintainer
#30 lore raw

PATCH 32/33 hotplug: Make register and unregister notifier API symmetric

In reply to Greg Kroah-Hartman

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

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

From: Michal Hocko <[email protected]>

commit 777c6e0daebb3fcefbbd6f620410a946b07ef6d0 upstream.

Yu Zhao has noticed that __unregister_cpu_notifier only unregisters its notifiers when HOTPLUG_CPU=y while the registration might succeed even when HOTPLUG_CPU=n if MODULE is enabled. This means that e.g. zswap might keep a stale notifier on the list on the manual clean up during the pool tear down and thus corrupt the list. Resulting in the following

[  144.964346] BUG: unable to handle kernel paging request at ffff880658a2be78
[  144.971337] IP: [<ffffffffa290b00b>] raw_notifier_chain_register+0x1b/0x40
<snipped>
[  145.122628] Call Trace:
[  145.125086]  [<ffffffffa28e5cf8>] __register_cpu_notifier+0x18/0x20
[  145.131350]  [<ffffffffa2a5dd73>] zswap_pool_create+0x273/0x400
[  145.137268]  [<ffffffffa2a5e0fc>] __zswap_param_set+0x1fc/0x300
[  145.143188]  [<ffffffffa2944c1d>] ? trace_hardirqs_on+0xd/0x10
[  145.149018]  [<ffffffffa2908798>] ? kernel_param_lock+0x28/0x30
[  145.154940]  [<ffffffffa2a3e8cf>] ? __might_fault+0x4f/0xa0
[  145.160511]  [<ffffffffa2a5e237>] zswap_compressor_param_set+0x17/0x20
[  145.167035]  [<ffffffffa2908d3c>] param_attr_store+0x5c/0xb0
[  145.172694]  [<ffffffffa290848d>] module_attr_store+0x1d/0x30
[  145.178443]  [<ffffffffa2b2b41f>] sysfs_kf_write+0x4f/0x70
[  145.183925]  [<ffffffffa2b2a5b9>] kernfs_fop_write+0x149/0x180
[  145.189761]  [<ffffffffa2a99248>] __vfs_write+0x18/0x40
[  145.194982]  [<ffffffffa2a9a412>] vfs_write+0xb2/0x1a0
[  145.200122]  [<ffffffffa2a9a732>] SyS_write+0x52/0xa0
[  145.205177]  [<ffffffffa2ff4d97>] entry_SYSCALL_64_fastpath+0x12/0x17

This can be even triggered manually by changing /sys/module/zswap/parameters/compressor multiple times.

Fix this issue by making unregister APIs symmetric to the register so there are no surprises.

Fixes 47e627bc8c9a ("[PATCH] hotplug: Allow modules to use the cpu hotplug notifiers even if !CONFIG_HOTPLUG_CPU")
Reported-and-tested-by Yu Zhao <[email protected]>
Cc Andrew Morton <[email protected]>
Cc Dan Streetman <[email protected]>
---
 include/linux/cpu.h |   15 ++++-----------
 kernel/cpu.c        |    2 +-
 2 files changed, 5 insertions(+), 12 deletions(-)
include/linux/cpu.h +4 -11
@@ -105,22 +105,16 @@ extern bool cpuhp_tasks_frozen;
 		{ .notifier_call = fn, .priority = pri };	\
 	__register_cpu_notifier(&fn##_nb);			\
 }
-#else /* #if defined(CONFIG_HOTPLUG_CPU) || !defined(MODULE) */
-#define cpu_notifier(fn, pri)	do { (void)(fn); } while (0)
-#define __cpu_notifier(fn, pri)	do { (void)(fn); } while (0)
-#endif /* #else #if defined(CONFIG_HOTPLUG_CPU) || !defined(MODULE) */
 
-#ifdef CONFIG_HOTPLUG_CPU
 extern int register_cpu_notifier(struct notifier_block *nb);
 extern int __register_cpu_notifier(struct notifier_block *nb);
 extern void unregister_cpu_notifier(struct notifier_block *nb);
 extern void __unregister_cpu_notifier(struct notifier_block *nb);
-#else
 
-#ifndef MODULE
-extern int register_cpu_notifier(struct notifier_block *nb);
-extern int __register_cpu_notifier(struct notifier_block *nb);
-#else
+#else /* #if defined(CONFIG_HOTPLUG_CPU) || !defined(MODULE) */
+#define cpu_notifier(fn, pri)	do { (void)(fn); } while (0)
+#define __cpu_notifier(fn, pri)	do { (void)(fn); } while (0)
+
 static inline int register_cpu_notifier(struct notifier_block *nb)
 {
 	return 0;
@@ -130,7 +124,6 @@ static inline int __register_cpu_notifie
 {
 	return 0;
 }
-#endif
 
 static inline void unregister_cpu_notifier(struct notifier_block *nb)
 {
kernel/cpu.c +1 -1
@@ -578,7 +578,6 @@ void __init cpuhp_threads_init(void)
 	kthread_unpark(this_cpu_read(cpuhp_state.thread));
 }
 
-#ifdef CONFIG_HOTPLUG_CPU
 EXPORT_SYMBOL(register_cpu_notifier);
 EXPORT_SYMBOL(__register_cpu_notifier);
 void unregister_cpu_notifier(struct notifier_block *nb)
@@ -595,6 +594,7 @@ void __unregister_cpu_notifier(struct no
 }
 EXPORT_SYMBOL(__unregister_cpu_notifier);
 
+#ifdef CONFIG_HOTPLUG_CPU
 /**
  * clear_tasks_mm_cpumask - Safely clear tasks' mm_cpumask for a CPU
  * @cpu: a CPU id

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

author maintainer
#31 lore raw

PATCH 33/33 crypto: rsa - Add Makefile dependencies to fix parallel builds

In reply to Greg Kroah-Hartman

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

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

From: David Michael <[email protected]>

commit 57891633eeef60e732e045731cf20e50ee80acb4 upstream.

Both asn1 headers are included by rsa_helper.c, so rsa_helper.o should explicitly depend on them.

---
 crypto/Makefile |    1 +
 1 file changed, 1 insertion(+)
crypto/Makefile +1 -0
@@ -40,6 +40,7 @@ obj-$(CONFIG_CRYPTO_ECDH) += ecdh_generi
 
 $(obj)/rsapubkey-asn1.o: $(obj)/rsapubkey-asn1.c $(obj)/rsapubkey-asn1.h
 $(obj)/rsaprivkey-asn1.o: $(obj)/rsaprivkey-asn1.c $(obj)/rsaprivkey-asn1.h
+$(obj)/rsa_helper.o: $(obj)/rsapubkey-asn1.h $(obj)/rsaprivkey-asn1.h
 clean-files += rsapubkey-asn1.c rsapubkey-asn1.h
 clean-files += rsaprivkey-asn1.c rsaprivkey-asn1.h
 
#32 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.8.15 release. There are 33 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 Dec 15 17:15:24 UTC 2016. 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.8.15-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.8.y
and the diffstat can be found below.

thanks,

greg k-h

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

thanks,
-- Shuah

Signature · 5 lines
Shuah Khan
Sr. Linux Kernel Developer
Open Source Innovation Group
Samsung Research America(Silicon Valley)
[email protected]
author maintainer
#33 lore raw
Quoted 15 lines · Shuah Khan
Quoted 14 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 4.8.15 release. There are 33 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 Dec 15 17:15:24 UTC 2016. 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.8.15-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.8.y
and the diffstat can be found below.

Quoted 6 lines
Quoted 4 lines

thanks,

greg k-h

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

Thanks for testing both of these and letting me know.

greg k-h

#34 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.8.15 release. There are 33 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 Dec 15 17:15:24 UTC 2016. Anything received after that time might be too late.

Build results:

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

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

Guenter

author maintainer
#35 lore raw
Quoted 10 lines · Guenter Roeck
Quoted 8 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 4.8.15 release. There are 33 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 Dec 15 17:15:24 UTC 2016. Anything received after that time might be too late.

Quoted 6 lines

Build results:

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

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

Great, thanks for testing these and letting me know.

greg k-h