Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1561518 > unrolled thread

[PATCH 4.9 000/120] 4.9.5-stable review

Back to article view | Back to linux.kernel

Contents

  [PATCH 4.9 000/120] 4.9.5-stable review Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-01-18 12:00 +0100
    [PATCH 4.9 109/120] bq24190_charger: Fix PM runtime use for bq24190_battery_set_property Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-01-18 12:00 +0100
    [PATCH 4.9 087/120] pinctrl: meson: fix gpio request disabling other modes Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-01-18 12:00 +0100
    [PATCH 4.9 021/120] mm/slab.c: fix SLAB freelist randomization duplicate entries Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-01-18 12:00 +0100
    [PATCH 4.9 022/120] mm/hugetlb.c: fix reservation race when freeing surplus pages Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-01-18 12:00 +0100
    [PATCH 4.9 073/120] net/af_iucv: dont use paged skbs for TX on HiperSockets Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-01-18 12:00 +0100
    [PATCH 4.9 078/120] drm/amdgpu: update si kicker smc firmware Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-01-18 12:00 +0100
    [PATCH 4.9 002/120] Input: i8042 - add Pegatron touchpad to noloop table Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-01-18 12:00 +0100
    [PATCH 4.9 097/120] drm: Initialise drm_mm.head_node.allocated Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-01-18 12:00 +0100
    [PATCH 4.9 114/120] powerpc/ibmebus: Fix further device reference leaks Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-01-18 12:00 +0100
    [PATCH 4.9 048/120] USB: serial: ch341: fix open error handling Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-01-18 12:00 +0100
    [PATCH 4.9 047/120] USB: serial: ch341: fix resume after reset Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-01-18 12:00 +0100
    [PATCH 4.9 107/120] powercap/intel_rapl: fix and tidy up error handling Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-01-18 12:00 +0100
    [PATCH 4.9 026/120] KVM: x86: flush pending lapic jump label updates on module unload Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-01-18 12:10 +0100
    [PATCH 4.9 077/120] drm/radeon: drop verde dpm quirks Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-01-18 12:10 +0100
    [PATCH 4.9 023/120] KVM: x86: fix emulation of "MOV SS, null selector" Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-01-18 12:10 +0100
    [PATCH 4.9 082/120] i2c: piix4: Avoid race conditions with IMC Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-01-18 12:10 +0100
    [PATCH 4.9 070/120] extcon: return error code on failure Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-01-18 12:10 +0100
    [PATCH 4.9 049/120] USB: serial: ch341: fix control-message error handling Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-01-18 12:10 +0100
    [PATCH 4.9 007/120] regulator: axp20x: Fix axp809 ldo_io registration error on cold boot Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-01-18 12:10 +0100
    [PATCH 4.9 079/120] drm/amdgpu: drop verde dpm quirks Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-01-18 12:10 +0100
    [PATCH 4.9 116/120] powerpc/powernv: Dont warn on PE init if unfreeze is unsupported Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-01-18 12:10 +0100
    [PATCH 4.9 052/120] i2c: print correct device invalid address Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-01-18 12:10 +0100
    [PATCH 4.9 113/120] powerpc/mm: Correct process and partition table max size Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-01-18 12:10 +0100
    [PATCH 4.9 094/120] drm: avoid uninitialized timestamp use in wait_vblank Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-01-18 12:10 +0100
    [PATCH 4.9 080/120] USB: serial: ch341: fix modem-control and B0 handling Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-01-18 12:10 +0100
    [PATCH 4.9 084/120] nvme: apply DELAY_BEFORE_CHK_RDY quirk at probe time too Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-01-18 12:10 +0100
    [PATCH 4.9 119/120] arm64: hugetlb: fix the wrong return value for huge_ptep_set_access_flags Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-01-18 12:10 +0100
    [PATCH 4.9 074/120] drm/i915/gen9: Fix PCODE polling timeout in stable backport Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-01-18 12:10 +0100
    [PATCH 4.9 111/120] blk-mq: Always schedule hctx->next_cpu Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-01-18 12:10 +0100
    [PATCH 4.9 051/120] Input: elants_i2c - avoid divide by 0 errors on bad touchscreen data Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-01-18 12:10 +0100
    [PATCH 4.9 083/120] x86/cpu: Fix bootup crashes by sanitizing the argument of the clearcpuid= command-line option Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-01-18 12:10 +0100
    [PATCH 4.9 025/120] jump_labels: API for flushing deferred jump label updates Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-01-18 12:10 +0100
    [PATCH 4.9 043/120] wusbcore: Fix one more crypto-on-the-stack bug Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-01-18 12:10 +0100
    [PATCH 4.9 068/120] orinoco: Use shash instead of ahash for MIC calculations Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-01-18 12:10 +0100
    [PATCH 4.9 050/120] USB: serial: ch341: fix open and resume after B0 Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-01-18 12:10 +0100
    [PATCH 4.9 085/120] btrfs: fix locking when we put back a delayed ref thats too new Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-01-18 12:10 +0100
    [PATCH 4.9 118/120] arm64: hugetlb: remove the wrong pmd check in find_num_contig() Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-01-18 12:10 +0100
    [PATCH 4.9 064/120] virtio_blk: avoid DMA to stack for the sense buffer Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-01-18 12:10 +0100
    [PATCH 4.9 117/120] arm64: hugetlb: fix the wrong address for several functions Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-01-18 12:20 +0100
    [PATCH 4.9 010/120] drm/savage: dereferencing an error pointer Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-01-18 12:20 +0100
    [PATCH 4.9 115/120] powerpc/ibmebus: Fix device reference leaks in sysfs interface Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-01-18 12:20 +0100
    [PATCH 4.9 092/120] i2c: mux: pca954x: fix i2c mux selection caching Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-01-18 12:20 +0100
    [PATCH 4.9 039/120] bridge: netfilter: Fix dropping packets that moving through bridge interface Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-01-18 12:20 +0100
    [PATCH 4.9 090/120] NFS: Fix a performance regression in readdir Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-01-18 12:20 +0100
    [PATCH 4.9 071/120] Clearing FIFOs in RS485 emulation mode causes subsequent transmits to break Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-01-18 12:20 +0100
    [PATCH 4.9 008/120] drm/tegra: dpaux: Fix error handling Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-01-18 12:20 +0100
    [PATCH 4.9 012/120] selftests: do not require bash for the generated test Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-01-18 12:20 +0100
    [PATCH 4.9 013/120] zram: revalidate disk under init_lock Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-01-18 12:20 +0100
    [PATCH 4.9 054/120] fix a fencepost error in pipe_advance() Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-01-18 12:20 +0100
    [PATCH 4.9 032/120] efi/libstub/arm*: Pass latest memory map to the kernel Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-01-18 12:20 +0100
    [PATCH 4.9 040/120] x86/cpu/AMD: Clean up cpu_llc_id assignment per topology feature Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-01-18 12:20 +0100
    [PATCH 4.9 061/120] mnt: Protect the mountpoint hashtable with mount_lock Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-01-18 12:20 +0100
    [PATCH 4.9 063/120] dmaengine: omap-dma: Fix dynamic lch_map allocation Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-01-18 12:20 +0100
    [PATCH 4.9 056/120] btrfs: fix crash when tracepoint arguments are freed by wq callbacks Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-01-18 12:20 +0100
    [PATCH 4.9 055/120] xhci: fix deadlock at host remove by running watchdog correctly Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-01-18 12:20 +0100
    [PATCH 4.9 014/120] zram: support BDI_CAP_STABLE_WRITES Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-01-18 12:20 +0100
    [PATCH 4.9 066/120] tty/serial: atmel_serial: BUG: stop DMA from transmitting in stop_tx Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-01-18 12:20 +0100
    [PATCH 4.9 072/120] sysctl: Drop reference added by grab_header in proc_sys_readdir Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-01-18 12:20 +0100
    [PATCH 4.9 058/120] Revert "tty: serial: 8250: add CON_CONSDEV to flags" Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-01-18 12:20 +0100
    [PATCH 4.9 041/120] x86/bugs: Separate AMD E400 erratum and C1E bug Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-01-18 12:20 +0100
    [PATCH 4.9 062/120] drivers: char: mem: Fix thinkos in kmem address checks Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-01-18 12:20 +0100
    [PATCH 4.9 091/120] NFSv4.1: nfs4_fl_prepare_ds must be careful about reporting success. Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-01-18 12:20 +0100
    [PATCH 4.9 044/120] usb: musb: fix runtime PM in debugfs Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-01-18 12:20 +0100
    [PATCH 4.9 053/120] i2c: fix kernel memory disclosure in dev interface Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-01-18 12:20 +0100
    [PATCH 4.9 089/120] pNFS: Fix race in pnfs_wait_on_layoutreturn Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-01-18 12:20 +0100
    [PATCH 4.9 057/120] ASoC: hdmi-codec: use unsigned type to structure members with bit-field Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-01-18 12:20 +0100
    [PATCH 4.9 034/120] efi/x86: Prune invalid memory map entries and fix boot regression Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-01-18 12:20 +0100
    [PATCH 4.9 046/120] USB: serial: ch341: fix initial modem-control state Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-01-18 12:20 +0100
    [PATCH 4.9 009/120] drm/vc4: Fix a couple error codes in vc4_cl_lookup_bos() Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-01-18 12:30 +0100
    [PATCH 4.9 006/120] regulator: tps65086: Fix 25mV ranges for BUCK regulators Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-01-18 12:30 +0100
    [PATCH 4.9 017/120] mm: fix devm_memremap_pages crash, use mem_hotplug_{begin, done} Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-01-18 12:30 +0100
    [PATCH 4.9 015/120] dax: fix deadlock with DAX 4k holes Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-01-18 12:30 +0100
    [PATCH 4.9 031/120] KVM: x86: Introduce segmented_write_std Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-01-18 12:30 +0100
    [PATCH 4.9 033/120] perf/x86/intel/uncore: Fix hardcoded socket 0 assumption in the Haswell init code Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-01-18 12:30 +0100
      Re: [PATCH 4.9 033/120] perf/x86/intel/uncore: Fix hardcoded socket  0 assumption in the Haswell init code Prarit Bhargava <prarit@redhat.com> - 2017-01-18 15:40 +0100
        Re: [PATCH 4.9 033/120] perf/x86/intel/uncore: Fix hardcoded socket  0 assumption in the Haswell init code Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-01-18 17:50 +0100
          Re: [PATCH 4.9 033/120] perf/x86/intel/uncore: Fix hardcoded socket  0 assumption in the Haswell init code Prarit Bhargava <prarit@redhat.com> - 2017-01-18 18:00 +0100
            Re: [PATCH 4.9 033/120] perf/x86/intel/uncore: Fix hardcoded socket  0 assumption in the Haswell init code Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-01-18 18:30 +0100
              Re: [PATCH 4.9 033/120] perf/x86/intel/uncore: Fix hardcoded socket  0 assumption in the Haswell init code Prarit Bhargava <prarit@redhat.com> - 2017-01-19 13:20 +0100
            Re: [PATCH 4.9 033/120] perf/x86/intel/uncore: Fix hardcoded socket  0 assumption in the Haswell init code Ingo Molnar <mingo@kernel.org> - 2017-01-18 23:30 +0100
              Re: [PATCH 4.9 033/120] perf/x86/intel/uncore: Fix hardcoded socket  0 assumption in the Haswell init code Prarit Bhargava <prarit@redhat.com> - 2017-01-19 11:40 +0100
                Re: [PATCH 4.9 033/120] perf/x86/intel/uncore: Fix hardcoded socket  0 assumption in the Haswell init code Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-01-19 13:00 +0100
                  Re: [PATCH 4.9 033/120] perf/x86/intel/uncore: Fix hardcoded socket  0 assumption in the Haswell init code Prarit Bhargava <prarit@redhat.com> - 2017-01-19 13:40 +0100
                    Re: [PATCH 4.9 033/120] perf/x86/intel/uncore: Fix hardcoded socket  0 assumption in the Haswell init code Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-01-19 15:00 +0100
                  Re: [PATCH 4.9 033/120] perf/x86/intel/uncore: Fix hardcoded socket  0 assumption in the Haswell init code Ingo Molnar <mingo@kernel.org> - 2017-01-19 14:50 +0100
                    Re: [PATCH 4.9 033/120] perf/x86/intel/uncore: Fix hardcoded socket  0 assumption in the Haswell init code Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-01-19 15:00 +0100
    [PATCH 4.9 036/120] nl80211: fix sched scan netlink socket owner destruction Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-01-18 12:30 +0100
    [PATCH 4.9 042/120] x86/CPU/AMD: Fix Bulldozer topology Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-01-18 12:30 +0100
    [PATCH 4.9 016/120] mm: pmd dirty emulation in page fault handler Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-01-18 12:30 +0100
    Re: [PATCH 4.9 000/120] 4.9.5-stable review Guenter Roeck <linux@roeck-us.net> - 2017-01-18 20:20 +0100
      Re: [PATCH 4.9 000/120] 4.9.5-stable review Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-01-18 21:40 +0100
    Re: [PATCH 4.9 000/120] 4.9.5-stable review Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-01-19 19:20 +0100
    Re: [PATCH 4.9 000/120] 4.9.5-stable review Shuah Khan <shuah.kh@samsung.com> - 2017-01-19 19:20 +0100
    Re: [PATCH 4.9 000/120] 4.9.5-stable review Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-01-21 10:00 +0100

Page 4 of 5 — ← Prev page 1 2 3 [4] 5  Next page →

#1561603 — [PATCH 4.9 041/120] x86/bugs: Separate AMD E400 erratum and C1E bug

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

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

From: Thomas Gleixner <tglx@linutronix.de>

commit 3344ed30791af66dbbad5f375008f3d1863b6c99 upstream.

The workaround for the AMD Erratum E400 (Local APIC timer stops in C1E
state) is a two step process:

 - Selection of the E400 aware idle routine

 - Detection whether the platform is affected

The idle routine selection happens for possibly affected CPUs depending on
family/model/stepping information. These range of CPUs is not necessarily
affected as the decision whether to enable the C1E feature is made by the
firmware. Unfortunately there is no way to query this at early boot.

The current implementation polls a MSR in the E400 aware idle routine to
detect whether the CPU is affected. This is inefficient on non affected
CPUs because every idle entry has to do the MSR read.

There is a better way to detect this before going idle for the first time
which requires to seperate the bug flags:

  X86_BUG_AMD_E400 	- Selects the E400 aware idle routine and
  			  enables the detection

  X86_BUG_AMD_APIC_C1E  - Set when the platform is affected by E400

Replace the current X86_BUG_AMD_APIC_C1E usage by the new X86_BUG_AMD_E400
bug bit to select the idle routine which currently does an unconditional
detection poll. X86_BUG_AMD_APIC_C1E is going to be used in later patches
to remove the MSR polling and simplify the handling of this misfeature.

Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Borislav Petkov <bp@suse.de>
Cc: Jiri Olsa <jolsa@redhat.com>
Link: http://lkml.kernel.org/r/20161209182912.2726-3-bp@alien8.de
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 arch/x86/include/asm/cpufeatures.h |    2 ++
 arch/x86/kernel/cpu/amd.c          |   20 +++++++++++++-------
 arch/x86/kernel/process.c          |    3 +--
 3 files changed, 16 insertions(+), 9 deletions(-)

--- a/arch/x86/include/asm/cpufeatures.h
+++ b/arch/x86/include/asm/cpufeatures.h
@@ -311,4 +311,6 @@
 #define X86_BUG_NULL_SEG	X86_BUG(10) /* Nulling a selector preserves the base */
 #define X86_BUG_SWAPGS_FENCE	X86_BUG(11) /* SWAPGS without input dep on GS */
 #define X86_BUG_MONITOR		X86_BUG(12) /* IPI required to wake up remote CPU */
+#define X86_BUG_AMD_E400	X86_BUG(13) /* CPU is among the affected by Erratum 400 */
+
 #endif /* _ASM_X86_CPUFEATURES_H */
--- a/arch/x86/kernel/cpu/amd.c
+++ b/arch/x86/kernel/cpu/amd.c
@@ -20,6 +20,10 @@
 
 #include "cpu.h"
 
+static const int amd_erratum_383[];
+static const int amd_erratum_400[];
+static bool cpu_has_amd_erratum(struct cpuinfo_x86 *cpu, const int *erratum);
+
 /*
  * nodes_per_socket: Stores the number of nodes per socket.
  * Refer to Fam15h Models 00-0fh BKDG - CPUID Fn8000_001E_ECX
@@ -592,11 +596,16 @@ static void early_init_amd(struct cpuinf
 	/* F16h erratum 793, CVE-2013-6885 */
 	if (c->x86 == 0x16 && c->x86_model <= 0xf)
 		msr_set_bit(MSR_AMD64_LS_CFG, 15);
-}
 
-static const int amd_erratum_383[];
-static const int amd_erratum_400[];
-static bool cpu_has_amd_erratum(struct cpuinfo_x86 *cpu, const int *erratum);
+	/*
+	 * Check whether the machine is affected by erratum 400. This is
+	 * used to select the proper idle routine and to enable the check
+	 * whether the machine is affected in arch_post_acpi_init(), which
+	 * sets the X86_BUG_AMD_APIC_C1E bug depending on the MSR check.
+	 */
+	if (cpu_has_amd_erratum(c, amd_erratum_400))
+		set_cpu_bug(c, X86_BUG_AMD_E400);
+}
 
 static void init_amd_k8(struct cpuinfo_x86 *c)
 {
@@ -777,9 +786,6 @@ static void init_amd(struct cpuinfo_x86
 	if (c->x86 > 0x11)
 		set_cpu_cap(c, X86_FEATURE_ARAT);
 
-	if (cpu_has_amd_erratum(c, amd_erratum_400))
-		set_cpu_bug(c, X86_BUG_AMD_APIC_C1E);
-
 	rdmsr_safe(MSR_AMD64_PATCH_LEVEL, &c->microcode, &dummy);
 
 	/* 3DNow or LM implies PREFETCHW */
--- a/arch/x86/kernel/process.c
+++ b/arch/x86/kernel/process.c
@@ -448,8 +448,7 @@ void select_idle_routine(const struct cp
 	if (x86_idle || boot_option_idle_override == IDLE_POLL)
 		return;
 
-	if (cpu_has_bug(c, X86_BUG_AMD_APIC_C1E)) {
-		/* E400: APIC timer interrupt does not wake up CPU from C1e */
+	if (boot_cpu_has_bug(X86_BUG_AMD_E400)) {
 		pr_info("using AMD E400 aware idle routine\n");
 		x86_idle = amd_e400_idle;
 	} else if (prefer_mwait_c1_over_halt(c)) {

[toc] | [prev] | [next] | [standalone]

#1561605 — [PATCH 4.9 062/120] drivers: char: mem: Fix thinkos in kmem address checks

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

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

From: Robin Murphy <robin.murphy@arm.com>

commit 488debb9971bc7d0edd6d8080ba78ca02a04f6c4 upstream.

When borrowing the pfn_valid() check from mmap_kmem(), somebody managed
to get physical and virtual addresses spectacularly muddled up, such
that we've ended up with checks for one being the other. Whilst this
does indeed prevent out-of-bounds accesses crashing, on most systems
it also prevents the more desirable use-case of working at all ever.

Check the *virtual* offset correctly for what it is. Furthermore, do
so in the right place - a read or write may span multiple pages, so a
single up-front check is insufficient. High memory accesses already
have a similar validity check just before the copy_to_user() call, so
just make the low memory path fully consistent with that.

Reported-by: Jason A. Donenfeld <Jason@zx2c4.com>
Fixes: 148a1bc84398 ("drivers: char: mem: Check {read,write}_kmem() addresses")
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/char/mem.c |   10 ++++------
 1 file changed, 4 insertions(+), 6 deletions(-)

--- a/drivers/char/mem.c
+++ b/drivers/char/mem.c
@@ -381,9 +381,6 @@ static ssize_t read_kmem(struct file *fi
 	char *kbuf; /* k-addr because vread() takes vmlist_lock rwlock */
 	int err = 0;
 
-	if (!pfn_valid(PFN_DOWN(p)))
-		return -EIO;
-
 	read = 0;
 	if (p < (unsigned long) high_memory) {
 		low_count = count;
@@ -412,6 +409,8 @@ static ssize_t read_kmem(struct file *fi
 			 * by the kernel or data corruption may occur
 			 */
 			kbuf = xlate_dev_kmem_ptr((void *)p);
+			if (!virt_addr_valid(kbuf))
+				return -ENXIO;
 
 			if (copy_to_user(buf, kbuf, sz))
 				return -EFAULT;
@@ -482,6 +481,8 @@ static ssize_t do_write_kmem(unsigned lo
 		 * corruption may occur.
 		 */
 		ptr = xlate_dev_kmem_ptr((void *)p);
+		if (!virt_addr_valid(ptr))
+			return -ENXIO;
 
 		copied = copy_from_user(ptr, buf, sz);
 		if (copied) {
@@ -512,9 +513,6 @@ static ssize_t write_kmem(struct file *f
 	char *kbuf; /* k-addr because vwrite() takes vmlist_lock rwlock */
 	int err = 0;
 
-	if (!pfn_valid(PFN_DOWN(p)))
-		return -EIO;
-
 	if (p < (unsigned long) high_memory) {
 		unsigned long to_write = min_t(unsigned long, count,
 					       (unsigned long)high_memory - p);

[toc] | [prev] | [next] | [standalone]

#1561606 — [PATCH 4.9 091/120] NFSv4.1: nfs4_fl_prepare_ds must be careful about reporting success.

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

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

From: NeilBrown <neilb@suse.com>

commit cfd278c280f997cf2fe4662e0acab0fe465f637b upstream.

Various places assume that if nfs4_fl_prepare_ds() turns a non-NULL 'ds',
then ds->ds_clp will also be non-NULL.

This is not necessasrily true in the case when the process received a fatal signal
while nfs4_pnfs_ds_connect is waiting in nfs4_wait_ds_connect().
In that case ->ds_clp may not be set, and the devid may not recently have been marked
unavailable.

So add a test for ds_clp == NULL and return NULL in that case.

Fixes: c23266d532b4 ("NFS4.1 Fix data server connection race")
Signed-off-by: NeilBrown <neilb@suse.com>
Acked-by: Olga Kornievskaia <aglo@umich.edu>
Acked-by: Adamson, Andy <William.Adamson@netapp.com>
Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 fs/nfs/filelayout/filelayoutdev.c |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

--- a/fs/nfs/filelayout/filelayoutdev.c
+++ b/fs/nfs/filelayout/filelayoutdev.c
@@ -283,7 +283,8 @@ nfs4_fl_prepare_ds(struct pnfs_layout_se
 			     s->nfs_client->cl_rpcclient->cl_auth->au_flavor);
 
 out_test_devid:
-	if (filelayout_test_devid_unavailable(devid))
+	if (ret->ds_clp == NULL ||
+	    filelayout_test_devid_unavailable(devid))
 		ret = NULL;
 out:
 	return ret;

[toc] | [prev] | [next] | [standalone]

#1561608 — [PATCH 4.9 044/120] usb: musb: fix runtime PM in debugfs

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

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

From: Bin Liu <b-liu@ti.com>

commit 7b6c1b4c0e1e44544aa18161dba6a741c080a7ef upstream.

MUSB driver now has runtime PM support, but the debugfs driver misses
the PM _get/_put() calls, which could cause MUSB register access
failure.

Acked-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Bin Liu <b-liu@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/usb/musb/musb_debugfs.c |   20 +++++++++++++++++++-
 1 file changed, 19 insertions(+), 1 deletion(-)

--- a/drivers/usb/musb/musb_debugfs.c
+++ b/drivers/usb/musb/musb_debugfs.c
@@ -114,6 +114,7 @@ static int musb_regdump_show(struct seq_
 	unsigned		i;
 
 	seq_printf(s, "MUSB (M)HDRC Register Dump\n");
+	pm_runtime_get_sync(musb->controller);
 
 	for (i = 0; i < ARRAY_SIZE(musb_regmap); i++) {
 		switch (musb_regmap[i].size) {
@@ -132,6 +133,8 @@ static int musb_regdump_show(struct seq_
 		}
 	}
 
+	pm_runtime_mark_last_busy(musb->controller);
+	pm_runtime_put_autosuspend(musb->controller);
 	return 0;
 }
 
@@ -145,7 +148,10 @@ static int musb_test_mode_show(struct se
 	struct musb		*musb = s->private;
 	unsigned		test;
 
+	pm_runtime_get_sync(musb->controller);
 	test = musb_readb(musb->mregs, MUSB_TESTMODE);
+	pm_runtime_mark_last_busy(musb->controller);
+	pm_runtime_put_autosuspend(musb->controller);
 
 	if (test & MUSB_TEST_FORCE_HOST)
 		seq_printf(s, "force host\n");
@@ -194,11 +200,12 @@ static ssize_t musb_test_mode_write(stru
 	u8			test;
 	char			buf[18];
 
+	pm_runtime_get_sync(musb->controller);
 	test = musb_readb(musb->mregs, MUSB_TESTMODE);
 	if (test) {
 		dev_err(musb->controller, "Error: test mode is already set. "
 			"Please do USB Bus Reset to start a new test.\n");
-		return count;
+		goto ret;
 	}
 
 	memset(buf, 0x00, sizeof(buf));
@@ -234,6 +241,9 @@ static ssize_t musb_test_mode_write(stru
 
 	musb_writeb(musb->mregs, MUSB_TESTMODE, test);
 
+ret:
+	pm_runtime_mark_last_busy(musb->controller);
+	pm_runtime_put_autosuspend(musb->controller);
 	return count;
 }
 
@@ -254,8 +264,13 @@ static int musb_softconnect_show(struct
 	switch (musb->xceiv->otg->state) {
 	case OTG_STATE_A_HOST:
 	case OTG_STATE_A_WAIT_BCON:
+		pm_runtime_get_sync(musb->controller);
+
 		reg = musb_readb(musb->mregs, MUSB_DEVCTL);
 		connect = reg & MUSB_DEVCTL_SESSION ? 1 : 0;
+
+		pm_runtime_mark_last_busy(musb->controller);
+		pm_runtime_put_autosuspend(musb->controller);
 		break;
 	default:
 		connect = -1;
@@ -284,6 +299,7 @@ static ssize_t musb_softconnect_write(st
 	if (copy_from_user(&buf, ubuf, min_t(size_t, sizeof(buf) - 1, count)))
 		return -EFAULT;
 
+	pm_runtime_get_sync(musb->controller);
 	if (!strncmp(buf, "0", 1)) {
 		switch (musb->xceiv->otg->state) {
 		case OTG_STATE_A_HOST:
@@ -314,6 +330,8 @@ static ssize_t musb_softconnect_write(st
 		}
 	}
 
+	pm_runtime_mark_last_busy(musb->controller);
+	pm_runtime_put_autosuspend(musb->controller);
 	return count;
 }
 

[toc] | [prev] | [next] | [standalone]

#1561610 — [PATCH 4.9 053/120] i2c: fix kernel memory disclosure in dev interface

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

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

From: Vlad Tsyrklevich <vlad@tsyrklevich.net>

commit 30f939feaeee23e21391cfc7b484f012eb189c3c upstream.

i2c_smbus_xfer() does not always fill an entire block, allowing
kernel stack memory disclosure through the temp variable. Clear
it before it's read to.

Signed-off-by: Vlad Tsyrklevich <vlad@tsyrklevich.net>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/i2c/i2c-dev.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/i2c/i2c-dev.c
+++ b/drivers/i2c/i2c-dev.c
@@ -331,7 +331,7 @@ static noinline int i2cdev_ioctl_smbus(s
 		unsigned long arg)
 {
 	struct i2c_smbus_ioctl_data data_arg;
-	union i2c_smbus_data temp;
+	union i2c_smbus_data temp = {};
 	int datasize, res;
 
 	if (copy_from_user(&data_arg,

[toc] | [prev] | [next] | [standalone]

#1561611 — [PATCH 4.9 089/120] pNFS: Fix race in pnfs_wait_on_layoutreturn

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

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

From: Trond Myklebust <trond.myklebust@primarydata.com>

commit ee284e35d8c71bf5d4d807eaff6f67a17134b359 upstream.

We must put the task to sleep while holding the inode->i_lock in order
to ensure atomicity with the test for NFS_LAYOUT_RETURN.

Fixes: 500d701f336b ("NFS41: make close wait for layoutreturn")
Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 fs/nfs/pnfs.c |    8 +++-----
 1 file changed, 3 insertions(+), 5 deletions(-)

--- a/fs/nfs/pnfs.c
+++ b/fs/nfs/pnfs.c
@@ -1257,13 +1257,11 @@ bool pnfs_wait_on_layoutreturn(struct in
 	 * i_lock */
         spin_lock(&ino->i_lock);
         lo = nfsi->layout;
-        if (lo && test_bit(NFS_LAYOUT_RETURN, &lo->plh_flags))
+        if (lo && test_bit(NFS_LAYOUT_RETURN, &lo->plh_flags)) {
+                rpc_sleep_on(&NFS_SERVER(ino)->roc_rpcwaitq, task, NULL);
                 sleep = true;
+	}
         spin_unlock(&ino->i_lock);
-
-        if (sleep)
-                rpc_sleep_on(&NFS_SERVER(ino)->roc_rpcwaitq, task, NULL);
-
         return sleep;
 }
 

[toc] | [prev] | [next] | [standalone]

#1561612 — [PATCH 4.9 057/120] ASoC: hdmi-codec: use unsigned type to structure members with bit-field

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

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

From: Takashi Sakamoto <o-takashi@sakamocchi.jp>

commit 9e4d59ada4d602e78eee9fb5f898ce61fdddb446 upstream.

This is a fix for Linux 4.10-rc1.

In C language specification, a bit-field is interpreted as a signed or
unsigned integer type consisting of the specified number of bits.

In GCC manual, the range of a signed bit field of N bits is from
-(2^N) / 2 to ((2^N) / 2) - 1
https://www.gnu.org/software/gnu-c-manual/gnu-c-manual.html#Bit-Fields

Therefore, when defined as 1 bit-field with signed type, variables can
represents -1 and 0.

The snd-soc-hdmi-codec module includes a structure which has signed type
members with bit-fields. Codes of this module assign 0 and 1 to the
members. This seems to result in implementation-dependent behaviours.

As of v4.10-rc1 merge window, outside of sound subsystem, this structure
is referred by below GPU modules.
 - tda998x
 - sti-drm
 - mediatek-drm-hdmi
 - msm

As long as I review their codes relevant to the structure, the structure
members are used just for condition statements and printk formats.
My proposal of change is a bit intrusive to the printk formats but this
may be acceptable.

Totally, it's reasonable to use unsigned type for the structure members.
This bug is detected by Sparse, static code analyzer with below warnings.

./include/sound/hdmi-codec.h:39:26: error: dubious one-bit signed bitfield
./include/sound/hdmi-codec.h:40:28: error: dubious one-bit signed bitfield
./include/sound/hdmi-codec.h:41:29: error: dubious one-bit signed bitfield
./include/sound/hdmi-codec.h:42:31: error: dubious one-bit signed bitfield

Fixes: 09184118a8ab ("ASoC: hdmi-codec: Add hdmi-codec for external HDMI-encoders")
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Acked-by: Arnaud Pouliquen <arnaud.pouliquen@st.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 include/sound/hdmi-codec.h |    8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

--- a/include/sound/hdmi-codec.h
+++ b/include/sound/hdmi-codec.h
@@ -36,10 +36,10 @@ struct hdmi_codec_daifmt {
 		HDMI_AC97,
 		HDMI_SPDIF,
 	} fmt;
-	int bit_clk_inv:1;
-	int frame_clk_inv:1;
-	int bit_clk_master:1;
-	int frame_clk_master:1;
+	unsigned int bit_clk_inv:1;
+	unsigned int frame_clk_inv:1;
+	unsigned int bit_clk_master:1;
+	unsigned int frame_clk_master:1;
 };
 
 /*

[toc] | [prev] | [next] | [standalone]

#1561613 — [PATCH 4.9 034/120] efi/x86: Prune invalid memory map entries and fix boot regression

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

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

From: Peter Jones <pjones@redhat.com>

commit 0100a3e67a9cef64d72cd3a1da86f3ddbee50363 upstream.

Some machines, such as the Lenovo ThinkPad W541 with firmware GNET80WW
(2.28), include memory map entries with phys_addr=0x0 and num_pages=0.

These machines fail to boot after the following commit,

  commit 8e80632fb23f ("efi/esrt: Use efi_mem_reserve() and avoid a kmalloc()")

Fix this by removing such bogus entries from the memory map.

Furthermore, currently the log output for this case (with efi=debug)
looks like:

 [    0.000000] efi: mem45: [Reserved           |   |  |  |  |  |  |  |  |  |  |  |  ] range=[0x0000000000000000-0xffffffffffffffff] (0MB)

This is clearly wrong, and also not as informative as it could be.  This
patch changes it so that if we find obviously invalid memory map
entries, we print an error and skip those entries.  It also detects the
display of the address range calculation overflow, so the new output is:

 [    0.000000] efi: [Firmware Bug]: Invalid EFI memory map entries:
 [    0.000000] efi: mem45: [Reserved           |   |  |  |  |  |  |  |   |  |  |  |  ] range=[0x0000000000000000-0x0000000000000000] (invalid)

It also detects memory map sizes that would overflow the physical
address, for example phys_addr=0xfffffffffffff000 and
num_pages=0x0200000000000001, and prints:

 [    0.000000] efi: [Firmware Bug]: Invalid EFI memory map entries:
 [    0.000000] efi: mem45: [Reserved           |   |  |  |  |  |  |  |   |  |  |  |  ] range=[phys_addr=0xfffffffffffff000-0x20ffffffffffffffff] (invalid)

It then removes these entries from the memory map.

Signed-off-by: Peter Jones <pjones@redhat.com>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
[ardb: refactor for clarity with no functional changes, avoid PAGE_SHIFT]
Signed-off-by: Matt Fleming <matt@codeblueprint.co.uk>
[Matt: Include bugzilla info in commit log]
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Link: https://bugzilla.kernel.org/show_bug.cgi?id=191121
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 arch/x86/platform/efi/efi.c |   66 ++++++++++++++++++++++++++++++++++++++++++++
 include/linux/efi.h         |    1 
 2 files changed, 67 insertions(+)

--- a/arch/x86/platform/efi/efi.c
+++ b/arch/x86/platform/efi/efi.c
@@ -210,6 +210,70 @@ int __init efi_memblock_x86_reserve_rang
 	return 0;
 }
 
+#define OVERFLOW_ADDR_SHIFT	(64 - EFI_PAGE_SHIFT)
+#define OVERFLOW_ADDR_MASK	(U64_MAX << OVERFLOW_ADDR_SHIFT)
+#define U64_HIGH_BIT		(~(U64_MAX >> 1))
+
+static bool __init efi_memmap_entry_valid(const efi_memory_desc_t *md, int i)
+{
+	u64 end = (md->num_pages << EFI_PAGE_SHIFT) + md->phys_addr - 1;
+	u64 end_hi = 0;
+	char buf[64];
+
+	if (md->num_pages == 0) {
+		end = 0;
+	} else if (md->num_pages > EFI_PAGES_MAX ||
+		   EFI_PAGES_MAX - md->num_pages <
+		   (md->phys_addr >> EFI_PAGE_SHIFT)) {
+		end_hi = (md->num_pages & OVERFLOW_ADDR_MASK)
+			>> OVERFLOW_ADDR_SHIFT;
+
+		if ((md->phys_addr & U64_HIGH_BIT) && !(end & U64_HIGH_BIT))
+			end_hi += 1;
+	} else {
+		return true;
+	}
+
+	pr_warn_once(FW_BUG "Invalid EFI memory map entries:\n");
+
+	if (end_hi) {
+		pr_warn("mem%02u: %s range=[0x%016llx-0x%llx%016llx] (invalid)\n",
+			i, efi_md_typeattr_format(buf, sizeof(buf), md),
+			md->phys_addr, end_hi, end);
+	} else {
+		pr_warn("mem%02u: %s range=[0x%016llx-0x%016llx] (invalid)\n",
+			i, efi_md_typeattr_format(buf, sizeof(buf), md),
+			md->phys_addr, end);
+	}
+	return false;
+}
+
+static void __init efi_clean_memmap(void)
+{
+	efi_memory_desc_t *out = efi.memmap.map;
+	const efi_memory_desc_t *in = out;
+	const efi_memory_desc_t *end = efi.memmap.map_end;
+	int i, n_removal;
+
+	for (i = n_removal = 0; in < end; i++) {
+		if (efi_memmap_entry_valid(in, i)) {
+			if (out != in)
+				memcpy(out, in, efi.memmap.desc_size);
+			out = (void *)out + efi.memmap.desc_size;
+		} else {
+			n_removal++;
+		}
+		in = (void *)in + efi.memmap.desc_size;
+	}
+
+	if (n_removal > 0) {
+		u64 size = efi.memmap.nr_map - n_removal;
+
+		pr_warn("Removing %d invalid memory map entries.\n", n_removal);
+		efi_memmap_install(efi.memmap.phys_map, size);
+	}
+}
+
 void __init efi_print_memmap(void)
 {
 	efi_memory_desc_t *md;
@@ -472,6 +536,8 @@ void __init efi_init(void)
 		}
 	}
 
+	efi_clean_memmap();
+
 	if (efi_enabled(EFI_DBG))
 		efi_print_memmap();
 }
--- a/include/linux/efi.h
+++ b/include/linux/efi.h
@@ -103,6 +103,7 @@ typedef	struct {
 
 #define EFI_PAGE_SHIFT		12
 #define EFI_PAGE_SIZE		(1UL << EFI_PAGE_SHIFT)
+#define EFI_PAGES_MAX		(U64_MAX >> EFI_PAGE_SHIFT)
 
 typedef struct {
 	u32 type;

[toc] | [prev] | [next] | [standalone]

#1561614 — [PATCH 4.9 046/120] USB: serial: ch341: fix initial modem-control state

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

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

From: Johan Hovold <johan@kernel.org>

commit 4e2da44691cffbfffb1535f478d19bc2dca3e62b upstream.

DTR and RTS will be asserted by the tty-layer when the port is opened
and deasserted on close (if HUPCL is set). Make sure the initial state
is not-asserted before the port is first opened as well.

Fixes: 664d5df92e88 ("USB: usb-serial ch341: support for DTR/RTS/CTS")
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/usb/serial/ch341.c |    1 -
 1 file changed, 1 deletion(-)

--- a/drivers/usb/serial/ch341.c
+++ b/drivers/usb/serial/ch341.c
@@ -253,7 +253,6 @@ static int ch341_port_probe(struct usb_s
 
 	spin_lock_init(&priv->lock);
 	priv->baud_rate = DEFAULT_BAUD_RATE;
-	priv->line_control = CH341_BIT_RTS | CH341_BIT_DTR;
 
 	r = ch341_configure(port->serial->dev, priv);
 	if (r < 0)

[toc] | [prev] | [next] | [standalone]

#1561619 — [PATCH 4.9 009/120] drm/vc4: Fix a couple error codes in vc4_cl_lookup_bos()

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

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

From: Dan Carpenter <dan.carpenter@oracle.com>

commit b2cdeb19f16ad984eb5bb9193f793d05a8101511 upstream.

If the allocation fails the current code returns success.  If
copy_from_user() fails it returns the number of bytes remaining instead
of -EFAULT.

Fixes: d5b1a78a772f ("drm/vc4: Add support for drawing 3D frames.")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/gpu/drm/vc4/vc4_gem.c |    9 +++++----
 1 file changed, 5 insertions(+), 4 deletions(-)

--- a/drivers/gpu/drm/vc4/vc4_gem.c
+++ b/drivers/gpu/drm/vc4/vc4_gem.c
@@ -544,14 +544,15 @@ vc4_cl_lookup_bos(struct drm_device *dev
 
 	handles = drm_malloc_ab(exec->bo_count, sizeof(uint32_t));
 	if (!handles) {
+		ret = -ENOMEM;
 		DRM_ERROR("Failed to allocate incoming GEM handles\n");
 		goto fail;
 	}
 
-	ret = copy_from_user(handles,
-			     (void __user *)(uintptr_t)args->bo_handles,
-			     exec->bo_count * sizeof(uint32_t));
-	if (ret) {
+	if (copy_from_user(handles,
+			   (void __user *)(uintptr_t)args->bo_handles,
+			   exec->bo_count * sizeof(uint32_t))) {
+		ret = -EFAULT;
 		DRM_ERROR("Failed to copy in GEM handles\n");
 		goto fail;
 	}

[toc] | [prev] | [next] | [standalone]

#1561622 — [PATCH 4.9 006/120] regulator: tps65086: Fix 25mV ranges for BUCK regulators

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

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

From: Andrew F. Davis <afd@ti.com>

commit d8ca5bd158f738c4fa6974ee388c381f64db7905 upstream.

The BUCK regulators 3, 4, and 5 also have a 10mV step mode,
adjust the tables and logic to reflect the data-sheet for
these regulators.

fixes: d2a2e729a666 ("regulator: tps65086: Add regulator driver for the TPS65086 PMIC")
Signed-off-by: Andrew F. Davis <afd@ti.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 Documentation/devicetree/bindings/mfd/tps65086.txt |    2 
 drivers/regulator/tps65086-regulator.c             |   54 ++++++++++-----------
 2 files changed, 29 insertions(+), 27 deletions(-)

--- a/Documentation/devicetree/bindings/mfd/tps65086.txt
+++ b/Documentation/devicetree/bindings/mfd/tps65086.txt
@@ -23,7 +23,7 @@ Required properties:
                             defined below.
 
 Optional regulator properties:
- - ti,regulator-step-size-25mv	: This is applicable for buck[1,2,6], set this
+ - ti,regulator-step-size-25mv	: This is applicable for buck[1-6], set this
 				    if the regulator is factory set with a 25mv
 				    step voltage mapping.
  - ti,regulator-decay		: This is applicable for buck[1-6], set this if
--- a/drivers/regulator/tps65086-regulator.c
+++ b/drivers/regulator/tps65086-regulator.c
@@ -71,18 +71,17 @@ struct tps65086_regulator {
 	unsigned int decay_mask;
 };
 
-static const struct regulator_linear_range tps65086_buck126_10mv_ranges[] = {
+static const struct regulator_linear_range tps65086_10mv_ranges[] = {
 	REGULATOR_LINEAR_RANGE(0, 0x0, 0x0, 0),
 	REGULATOR_LINEAR_RANGE(410000, 0x1, 0x7F, 10000),
 };
 
 static const struct regulator_linear_range tps65086_buck126_25mv_ranges[] = {
-	REGULATOR_LINEAR_RANGE(0, 0x0, 0x0, 0),
-	REGULATOR_LINEAR_RANGE(1000000, 0x1, 0x18, 0),
+	REGULATOR_LINEAR_RANGE(1000000, 0x0, 0x18, 0),
 	REGULATOR_LINEAR_RANGE(1025000, 0x19, 0x7F, 25000),
 };
 
-static const struct regulator_linear_range tps65086_buck345_ranges[] = {
+static const struct regulator_linear_range tps65086_buck345_25mv_ranges[] = {
 	REGULATOR_LINEAR_RANGE(0, 0x0, 0x0, 0),
 	REGULATOR_LINEAR_RANGE(425000, 0x1, 0x7F, 25000),
 };
@@ -125,27 +124,27 @@ static int tps65086_of_parse_cb(struct d
 static struct tps65086_regulator regulators[] = {
 	TPS65086_REGULATOR("BUCK1", "buck1", BUCK1, 0x80, TPS65086_BUCK1CTRL,
 			   BUCK_VID_MASK, TPS65086_BUCK123CTRL, BIT(0),
-			   tps65086_buck126_10mv_ranges, TPS65086_BUCK1CTRL,
+			   tps65086_10mv_ranges, TPS65086_BUCK1CTRL,
 			   BIT(0)),
 	TPS65086_REGULATOR("BUCK2", "buck2", BUCK2, 0x80, TPS65086_BUCK2CTRL,
 			   BUCK_VID_MASK, TPS65086_BUCK123CTRL, BIT(1),
-			   tps65086_buck126_10mv_ranges, TPS65086_BUCK2CTRL,
+			   tps65086_10mv_ranges, TPS65086_BUCK2CTRL,
 			   BIT(0)),
 	TPS65086_REGULATOR("BUCK3", "buck3", BUCK3, 0x80, TPS65086_BUCK3VID,
 			   BUCK_VID_MASK, TPS65086_BUCK123CTRL, BIT(2),
-			   tps65086_buck345_ranges, TPS65086_BUCK3DECAY,
+			   tps65086_10mv_ranges, TPS65086_BUCK3DECAY,
 			   BIT(0)),
 	TPS65086_REGULATOR("BUCK4", "buck4", BUCK4, 0x80, TPS65086_BUCK4VID,
 			   BUCK_VID_MASK, TPS65086_BUCK4CTRL, BIT(0),
-			   tps65086_buck345_ranges, TPS65086_BUCK4VID,
+			   tps65086_10mv_ranges, TPS65086_BUCK4VID,
 			   BIT(0)),
 	TPS65086_REGULATOR("BUCK5", "buck5", BUCK5, 0x80, TPS65086_BUCK5VID,
 			   BUCK_VID_MASK, TPS65086_BUCK5CTRL, BIT(0),
-			   tps65086_buck345_ranges, TPS65086_BUCK5CTRL,
+			   tps65086_10mv_ranges, TPS65086_BUCK5CTRL,
 			   BIT(0)),
 	TPS65086_REGULATOR("BUCK6", "buck6", BUCK6, 0x80, TPS65086_BUCK6VID,
 			   BUCK_VID_MASK, TPS65086_BUCK6CTRL, BIT(0),
-			   tps65086_buck126_10mv_ranges, TPS65086_BUCK6CTRL,
+			   tps65086_10mv_ranges, TPS65086_BUCK6CTRL,
 			   BIT(0)),
 	TPS65086_REGULATOR("LDOA1", "ldoa1", LDOA1, 0xF, TPS65086_LDOA1CTRL,
 			   VDOA1_VID_MASK, TPS65086_LDOA1CTRL, BIT(0),
@@ -162,18 +161,6 @@ static struct tps65086_regulator regulat
 	TPS65086_SWITCH("VTT", "vtt", VTT, TPS65086_SWVTT_EN, BIT(4)),
 };
 
-static inline bool has_25mv_mode(int id)
-{
-	switch (id) {
-	case BUCK1:
-	case BUCK2:
-	case BUCK6:
-		return true;
-	default:
-		return false;
-	}
-}
-
 static int tps65086_of_parse_cb(struct device_node *dev,
 				const struct regulator_desc *desc,
 				struct regulator_config *config)
@@ -181,12 +168,27 @@ static int tps65086_of_parse_cb(struct d
 	int ret;
 
 	/* Check for 25mV step mode */
-	if (has_25mv_mode(desc->id) &&
-			of_property_read_bool(config->of_node, "ti,regulator-step-size-25mv")) {
-		regulators[desc->id].desc.linear_ranges =
+	if (of_property_read_bool(config->of_node, "ti,regulator-step-size-25mv")) {
+		switch (desc->id) {
+		case BUCK1:
+		case BUCK2:
+		case BUCK6:
+			regulators[desc->id].desc.linear_ranges =
 				tps65086_buck126_25mv_ranges;
-		regulators[desc->id].desc.n_linear_ranges =
+			regulators[desc->id].desc.n_linear_ranges =
 				ARRAY_SIZE(tps65086_buck126_25mv_ranges);
+			break;
+		case BUCK3:
+		case BUCK4:
+		case BUCK5:
+			regulators[desc->id].desc.linear_ranges =
+				tps65086_buck345_25mv_ranges;
+			regulators[desc->id].desc.n_linear_ranges =
+				ARRAY_SIZE(tps65086_buck345_25mv_ranges);
+			break;
+		default:
+			dev_warn(config->dev, "25mV step mode only valid for BUCK regulators\n");
+		}
 	}
 
 	/* Check for decay mode */

[toc] | [prev] | [next] | [standalone]

#1561623 — [PATCH 4.9 017/120] mm: fix devm_memremap_pages crash, use mem_hotplug_{begin, done}

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

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

From: Dan Williams <dan.j.williams@intel.com>

commit f931ab479dd24cf7a2c6e2df19778406892591fb upstream.

Both arch_add_memory() and arch_remove_memory() expect a single threaded
context.

For example, arch/x86/mm/init_64.c::kernel_physical_mapping_init() does
not hold any locks over this check and branch:

    if (pgd_val(*pgd)) {
    	pud = (pud_t *)pgd_page_vaddr(*pgd);
    	paddr_last = phys_pud_init(pud, __pa(vaddr),
    				   __pa(vaddr_end),
    				   page_size_mask);
    	continue;
    }

    pud = alloc_low_page();
    paddr_last = phys_pud_init(pud, __pa(vaddr), __pa(vaddr_end),
    			   page_size_mask);

The result is that two threads calling devm_memremap_pages()
simultaneously can end up colliding on pgd initialization.  This leads
to crash signatures like the following where the loser of the race
initializes the wrong pgd entry:

    BUG: unable to handle kernel paging request at ffff888ebfff0000
    IP: memcpy_erms+0x6/0x10
    PGD 2f8e8fc067 PUD 0 /* <---- Invalid PUD */
    Oops: 0000 [#1] SMP DEBUG_PAGEALLOC
    CPU: 54 PID: 3818 Comm: systemd-udevd Not tainted 4.6.7+ #13
    task: ffff882fac290040 ti: ffff882f887a4000 task.ti: ffff882f887a4000
    RIP: memcpy_erms+0x6/0x10
    [..]
    Call Trace:
      ? pmem_do_bvec+0x205/0x370 [nd_pmem]
      ? blk_queue_enter+0x3a/0x280
      pmem_rw_page+0x38/0x80 [nd_pmem]
      bdev_read_page+0x84/0xb0

Hold the standard memory hotplug mutex over calls to
arch_{add,remove}_memory().

Fixes: 41e94a851304 ("add devm_memremap_pages")
Link: http://lkml.kernel.org/r/148357647831.9498.12606007370121652979.stgit@dwillia2-desk3.amr.corp.intel.com
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Cc: Christoph Hellwig <hch@lst.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 kernel/memremap.c |    4 ++++
 1 file changed, 4 insertions(+)

--- a/kernel/memremap.c
+++ b/kernel/memremap.c
@@ -246,7 +246,9 @@ static void devm_memremap_pages_release(
 	/* pages are dead and unused, undo the arch mapping */
 	align_start = res->start & ~(SECTION_SIZE - 1);
 	align_size = ALIGN(resource_size(res), SECTION_SIZE);
+	mem_hotplug_begin();
 	arch_remove_memory(align_start, align_size);
+	mem_hotplug_done();
 	untrack_pfn(NULL, PHYS_PFN(align_start), align_size);
 	pgmap_radix_release(res);
 	dev_WARN_ONCE(dev, pgmap->altmap && pgmap->altmap->alloc,
@@ -358,7 +360,9 @@ void *devm_memremap_pages(struct device
 	if (error)
 		goto err_pfn_remap;
 
+	mem_hotplug_begin();
 	error = arch_add_memory(nid, align_start, align_size, true);
+	mem_hotplug_done();
 	if (error)
 		goto err_add_memory;
 

[toc] | [prev] | [next] | [standalone]

#1561624 — [PATCH 4.9 015/120] dax: fix deadlock with DAX 4k holes

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

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

From: Ross Zwisler <ross.zwisler@linux.intel.com>

commit 965d004af54088d138f806d04d803fb60d441986 upstream.

Currently in DAX if we have three read faults on the same hole address we
can end up with the following:

Thread 0		Thread 1		Thread 2
--------		--------		--------
dax_iomap_fault
 grab_mapping_entry
  lock_slot
   <locks empty DAX entry>

  			dax_iomap_fault
			 grab_mapping_entry
			  get_unlocked_mapping_entry
			   <sleeps on empty DAX entry>

						dax_iomap_fault
						 grab_mapping_entry
						  get_unlocked_mapping_entry
						   <sleeps on empty DAX entry>
  dax_load_hole
   find_or_create_page
   ...
    page_cache_tree_insert
     dax_wake_mapping_entry_waiter
      <wakes one sleeper>
     __radix_tree_replace
      <swaps empty DAX entry with 4k zero page>

			<wakes>
			get_page
			lock_page
			...
			put_locked_mapping_entry
			unlock_page
			put_page

						<sleeps forever on the DAX
						 wait queue>

The crux of the problem is that once we insert a 4k zero page, all
locking from then on is done in terms of that 4k zero page and any
additional threads sleeping on the empty DAX entry will never be woken.

Fix this by waking all sleepers when we replace the DAX radix tree entry
with a 4k zero page.  This will allow all sleeping threads to
successfully transition from locking based on the DAX empty entry to
locking on the 4k zero page.

With the test case reported by Xiong this happens very regularly in my
test setup, with some runs resulting in 9+ threads in this deadlocked
state.  With this fix I've been able to run that same test dozens of
times in a loop without issue.

Fixes: ac401cc78242 ("dax: New fault locking")
Link: http://lkml.kernel.org/r/1483479365-13607-1-git-send-email-ross.zwisler@linux.intel.com
Signed-off-by: Ross Zwisler <ross.zwisler@linux.intel.com>
Reported-by: Xiong Zhou <xzhou@redhat.com>
Reviewed-by: Jan Kara <jack@suse.cz>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 mm/filemap.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/mm/filemap.c
+++ b/mm/filemap.c
@@ -144,7 +144,7 @@ static int page_cache_tree_insert(struct
 				workingset_node_pages_dec(node);
 			/* Wakeup waiters for exceptional entry lock */
 			dax_wake_mapping_entry_waiter(mapping, page->index,
-						      false);
+						      true);
 		}
 	}
 	radix_tree_replace_slot(slot, page);

[toc] | [prev] | [next] | [standalone]

#1561626 — [PATCH 4.9 031/120] KVM: x86: Introduce segmented_write_std

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

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

From: Steve Rutherford <srutherford@google.com>

commit 129a72a0d3c8e139a04512325384fe5ac119e74d upstream.

Introduces segemented_write_std.

Switches from emulated reads/writes to standard read/writes in fxsave,
fxrstor, sgdt, and sidt.  This fixes CVE-2017-2584, a longstanding
kernel memory leak.

Since commit 283c95d0e389 ("KVM: x86: emulate FXSAVE and FXRSTOR",
2016-11-09), which is luckily not yet in any final release, this would
also be an exploitable kernel memory *write*!

Reported-by: Dmitry Vyukov <dvyukov@google.com>
Fixes: 96051572c819194c37a8367624b285be10297eca
Fixes: 283c95d0e3891b64087706b344a4b545d04a6e62
Suggested-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Steve Rutherford <srutherford@google.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 arch/x86/kvm/emulate.c |   22 ++++++++++++++++++----
 1 file changed, 18 insertions(+), 4 deletions(-)

--- a/arch/x86/kvm/emulate.c
+++ b/arch/x86/kvm/emulate.c
@@ -815,6 +815,20 @@ static int segmented_read_std(struct x86
 	return ctxt->ops->read_std(ctxt, linear, data, size, &ctxt->exception);
 }
 
+static int segmented_write_std(struct x86_emulate_ctxt *ctxt,
+			       struct segmented_address addr,
+			       void *data,
+			       unsigned int size)
+{
+	int rc;
+	ulong linear;
+
+	rc = linearize(ctxt, addr, size, true, &linear);
+	if (rc != X86EMUL_CONTINUE)
+		return rc;
+	return ctxt->ops->write_std(ctxt, linear, data, size, &ctxt->exception);
+}
+
 /*
  * Prefetch the remaining bytes of the instruction without crossing page
  * boundary if they are not in fetch_cache yet.
@@ -3710,8 +3724,8 @@ static int emulate_store_desc_ptr(struct
 	}
 	/* Disable writeback. */
 	ctxt->dst.type = OP_NONE;
-	return segmented_write(ctxt, ctxt->dst.addr.mem,
-			       &desc_ptr, 2 + ctxt->op_bytes);
+	return segmented_write_std(ctxt, ctxt->dst.addr.mem,
+				   &desc_ptr, 2 + ctxt->op_bytes);
 }
 
 static int em_sgdt(struct x86_emulate_ctxt *ctxt)
@@ -3957,7 +3971,7 @@ static int em_fxsave(struct x86_emulate_
 	else
 		size = offsetof(struct fxregs_state, xmm_space[0]);
 
-	return segmented_write(ctxt, ctxt->memop.addr.mem, &fx_state, size);
+	return segmented_write_std(ctxt, ctxt->memop.addr.mem, &fx_state, size);
 }
 
 static int fxrstor_fixup(struct x86_emulate_ctxt *ctxt,
@@ -3999,7 +4013,7 @@ static int em_fxrstor(struct x86_emulate
 	if (rc != X86EMUL_CONTINUE)
 		return rc;
 
-	rc = segmented_read(ctxt, ctxt->memop.addr.mem, &fx_state, 512);
+	rc = segmented_read_std(ctxt, ctxt->memop.addr.mem, &fx_state, 512);
 	if (rc != X86EMUL_CONTINUE)
 		return rc;
 

[toc] | [prev] | [next] | [standalone]

#1561633 — [PATCH 4.9 033/120] perf/x86/intel/uncore: Fix hardcoded socket 0 assumption in the Haswell init code

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

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

From: Prarit Bhargava <prarit@redhat.com>

commit 6d6daa20945f3f598e56e18d1f926c08754f5801 upstream.

hswep_uncore_cpu_init() uses a hardcoded physical package id 0 for the boot
cpu. This works as long as the boot CPU is actually on the physical package
0, which is normaly the case after power on / reboot.

But it fails with a NULL pointer dereference when a kdump kernel is started
on a secondary socket which has a different physical package id because the
locigal package translation for physical package 0 does not exist.

Use the logical package id of the boot cpu instead of hard coded 0.

[ tglx: Rewrote changelog once more ]

Fixes: cf6d445f6897 ("perf/x86/uncore: Track packages, not per CPU data")
Signed-off-by: Prarit Bhargava <prarit@redhat.com>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Borislav Petkov <bp@suse.de>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Harish Chegondi <harish.chegondi@intel.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Kan Liang <kan.liang@intel.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Stephane Eranian <eranian@google.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Vince Weaver <vincent.weaver@maine.edu>
Link: http://lkml.kernel.org/r/1483628965-2890-1-git-send-email-prarit@redhat.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 arch/x86/events/intel/uncore_snbep.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/arch/x86/events/intel/uncore_snbep.c
+++ b/arch/x86/events/intel/uncore_snbep.c
@@ -2686,7 +2686,7 @@ static struct intel_uncore_type *hswep_m
 
 void hswep_uncore_cpu_init(void)
 {
-	int pkg = topology_phys_to_logical_pkg(0);
+	int pkg = boot_cpu_data.logical_proc_id;
 
 	if (hswep_uncore_cbox.num_boxes > boot_cpu_data.x86_max_cores)
 		hswep_uncore_cbox.num_boxes = boot_cpu_data.x86_max_cores;

[toc] | [prev] | [next] | [standalone]

#1561861 — Re: [PATCH 4.9 033/120] perf/x86/intel/uncore: Fix hardcoded socket 0 assumption in the Haswell init code

On 01/18/2017 05:45 AM, Greg Kroah-Hartman wrote:
> 4.9-stable review patch.  If anyone has any objections, please let me know.
> 

Nack.

The value of boot_cpu_data.logical_proc_id may be uninitialized and set to
default -1 on systems that pick a random core as boot cpu.  This was
inadvertently fixed by 9d85eb9119f4 ("x86/smpboot: Make logical package
management more robust") which is in 4.10-rc1.

Before 9d85eb9119f4:

[    3.971539] hswep_uncore_cpu_init: cpu 5 pkg 0 boot_cpu_data.logical_proc_id
65535
[    3.976504] hswep_uncore_cpu_init: cpu 5 pkg 0 cpu_data(0).logical_proc_id 0

After 9d85eb9119f4:

[    3.919112] hswep_uncore_cpu_init: cpu 5 pkg 0 boot_cpu_data.logical_proc_id 0
[    3.923391] hswep_uncore_cpu_init: cpu 5 pkg 0 cpu_data(0).logical_proc_id 0

This patch should not be applied to any stable branch.

P.


> ------------------
> 
> From: Prarit Bhargava <prarit@redhat.com>
> 
> commit 6d6daa20945f3f598e56e18d1f926c08754f5801 upstream.
> 
> hswep_uncore_cpu_init() uses a hardcoded physical package id 0 for the boot
> cpu. This works as long as the boot CPU is actually on the physical package
> 0, which is normaly the case after power on / reboot.
> 
> But it fails with a NULL pointer dereference when a kdump kernel is started
> on a secondary socket which has a different physical package id because the
> locigal package translation for physical package 0 does not exist.
> 
> Use the logical package id of the boot cpu instead of hard coded 0.
> 
> [ tglx: Rewrote changelog once more ]
> 
> Fixes: cf6d445f6897 ("perf/x86/uncore: Track packages, not per CPU data")
> Signed-off-by: Prarit Bhargava <prarit@redhat.com>
> Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
> Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
> Cc: Borislav Petkov <bp@suse.de>
> Cc: H. Peter Anvin <hpa@zytor.com>
> Cc: Harish Chegondi <harish.chegondi@intel.com>
> Cc: Jiri Olsa <jolsa@redhat.com>
> Cc: Kan Liang <kan.liang@intel.com>
> Cc: Linus Torvalds <torvalds@linux-foundation.org>
> Cc: Peter Zijlstra <peterz@infradead.org>
> Cc: Stephane Eranian <eranian@google.com>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Cc: Vince Weaver <vincent.weaver@maine.edu>
> Link: http://lkml.kernel.org/r/1483628965-2890-1-git-send-email-prarit@redhat.com
> Signed-off-by: Ingo Molnar <mingo@kernel.org>
> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> 
> ---
>  arch/x86/events/intel/uncore_snbep.c |    2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> --- a/arch/x86/events/intel/uncore_snbep.c
> +++ b/arch/x86/events/intel/uncore_snbep.c
> @@ -2686,7 +2686,7 @@ static struct intel_uncore_type *hswep_m
>  
>  void hswep_uncore_cpu_init(void)
>  {
> -	int pkg = topology_phys_to_logical_pkg(0);
> +	int pkg = boot_cpu_data.logical_proc_id;
>  
>  	if (hswep_uncore_cbox.num_boxes > boot_cpu_data.x86_max_cores)
>  		hswep_uncore_cbox.num_boxes = boot_cpu_data.x86_max_cores;
> 
> 

[toc] | [prev] | [next] | [standalone]

#1561951 — Re: [PATCH 4.9 033/120] perf/x86/intel/uncore: Fix hardcoded socket 0 assumption in the Haswell init code

On Wed, Jan 18, 2017 at 09:38:07AM -0500, Prarit Bhargava wrote:
> 
> 
> On 01/18/2017 05:45 AM, Greg Kroah-Hartman wrote:
> > 4.9-stable review patch.  If anyone has any objections, please let me know.
> > 
> 
> Nack.
> 
> The value of boot_cpu_data.logical_proc_id may be uninitialized and set to
> default -1 on systems that pick a random core as boot cpu.  This was
> inadvertently fixed by 9d85eb9119f4 ("x86/smpboot: Make logical package
> management more robust") which is in 4.10-rc1.
> 
> Before 9d85eb9119f4:
> 
> [    3.971539] hswep_uncore_cpu_init: cpu 5 pkg 0 boot_cpu_data.logical_proc_id
> 65535
> [    3.976504] hswep_uncore_cpu_init: cpu 5 pkg 0 cpu_data(0).logical_proc_id 0
> 
> After 9d85eb9119f4:
> 
> [    3.919112] hswep_uncore_cpu_init: cpu 5 pkg 0 boot_cpu_data.logical_proc_id 0
> [    3.923391] hswep_uncore_cpu_init: cpu 5 pkg 0 cpu_data(0).logical_proc_id 0
> 
> This patch should not be applied to any stable branch.

So the fixes: line lies?  This isn't needed at all for 4.9?

confused,

greg k-h

[toc] | [prev] | [next] | [standalone]

#1561968 — Re: [PATCH 4.9 033/120] perf/x86/intel/uncore: Fix hardcoded socket 0 assumption in the Haswell init code

On 01/18/2017 11:33 AM, Greg Kroah-Hartman wrote:
> On Wed, Jan 18, 2017 at 09:38:07AM -0500, Prarit Bhargava wrote:
>>
>>
>> On 01/18/2017 05:45 AM, Greg Kroah-Hartman wrote:
>>> 4.9-stable review patch.  If anyone has any objections, please let me know.
>>>
>>
>> Nack.
>>
>> The value of boot_cpu_data.logical_proc_id may be uninitialized and set to
>> default -1 on systems that pick a random core as boot cpu.  This was
>> inadvertently fixed by 9d85eb9119f4 ("x86/smpboot: Make logical package
>> management more robust") which is in 4.10-rc1.
>>
>> Before 9d85eb9119f4:
>>
>> [    3.971539] hswep_uncore_cpu_init: cpu 5 pkg 0 boot_cpu_data.logical_proc_id
>> 65535
>> [    3.976504] hswep_uncore_cpu_init: cpu 5 pkg 0 cpu_data(0).logical_proc_id 0
>>
>> After 9d85eb9119f4:
>>
>> [    3.919112] hswep_uncore_cpu_init: cpu 5 pkg 0 boot_cpu_data.logical_proc_id 0
>> [    3.923391] hswep_uncore_cpu_init: cpu 5 pkg 0 cpu_data(0).logical_proc_id 0
>>
>> This patch should not be applied to any stable branch.
> 
> So the fixes: line lies?  This isn't needed at all for 4.9?

No, the fixes: line does not lie.  This patch is not needed at all for 4.9.
Other patches are required beyond this patch in order for 4.9 to remain stable.

This patch is 6d6daa20945f ("perf/x86/intel/uncore: Fix hardcoded socket 0
assumption in the Haswell init code") which was tested on and applied to
4.10-rc3 IIRC.  This patch was applied to 4.10-rc4.

[prarit@prarit linux]$ git describe --contains 6d6daa20945f
v4.10-rc4~9^2~5

4.9 is broken and requires additional patches beyond this patch.  Applying this
patch to 4.9 stable without those additional fixes will result in kernel panics
on some Haswell systems that boot on random cores.

P.

> 
> confused,
> 
> greg k-h
> 

[toc] | [prev] | [next] | [standalone]

#1561987 — Re: [PATCH 4.9 033/120] perf/x86/intel/uncore: Fix hardcoded socket 0 assumption in the Haswell init code

On Wed, Jan 18, 2017 at 11:55:58AM -0500, Prarit Bhargava wrote:
> 
> 
> On 01/18/2017 11:33 AM, Greg Kroah-Hartman wrote:
> > On Wed, Jan 18, 2017 at 09:38:07AM -0500, Prarit Bhargava wrote:
> >>
> >>
> >> On 01/18/2017 05:45 AM, Greg Kroah-Hartman wrote:
> >>> 4.9-stable review patch.  If anyone has any objections, please let me know.
> >>>
> >>
> >> Nack.
> >>
> >> The value of boot_cpu_data.logical_proc_id may be uninitialized and set to
> >> default -1 on systems that pick a random core as boot cpu.  This was
> >> inadvertently fixed by 9d85eb9119f4 ("x86/smpboot: Make logical package
> >> management more robust") which is in 4.10-rc1.
> >>
> >> Before 9d85eb9119f4:
> >>
> >> [    3.971539] hswep_uncore_cpu_init: cpu 5 pkg 0 boot_cpu_data.logical_proc_id
> >> 65535
> >> [    3.976504] hswep_uncore_cpu_init: cpu 5 pkg 0 cpu_data(0).logical_proc_id 0
> >>
> >> After 9d85eb9119f4:
> >>
> >> [    3.919112] hswep_uncore_cpu_init: cpu 5 pkg 0 boot_cpu_data.logical_proc_id 0
> >> [    3.923391] hswep_uncore_cpu_init: cpu 5 pkg 0 cpu_data(0).logical_proc_id 0
> >>
> >> This patch should not be applied to any stable branch.
> > 
> > So the fixes: line lies?  This isn't needed at all for 4.9?
> 
> No, the fixes: line does not lie.  This patch is not needed at all for 4.9.
> Other patches are required beyond this patch in order for 4.9 to remain stable.
> 
> This patch is 6d6daa20945f ("perf/x86/intel/uncore: Fix hardcoded socket 0
> assumption in the Haswell init code") which was tested on and applied to
> 4.10-rc3 IIRC.  This patch was applied to 4.10-rc4.
> 
> [prarit@prarit linux]$ git describe --contains 6d6daa20945f
> v4.10-rc4~9^2~5

Yes, but the patch says it is fixing a bug since 4.6-rc1.  The fixes
line says:
	    Fixes: cf6d445f6897 ("perf/x86/uncore: Track packages, not per CPU data")

$ git dc cf6d445f6897
v4.6-rc1~165^2~28

(dc is my git alias for "describe --contains" as I type it so often...)

> 4.9 is broken and requires additional patches beyond this patch.  Applying this
> patch to 4.9 stable without those additional fixes will result in kernel panics
> on some Haswell systems that boot on random cores.

So, does 4.9 on its own work properly on these systems?  If not, what
are the commits that are needed to fix it?

If 4.9 is fine as-is, great, we should drop this patch then, correct?
But then that fixes: line lied :(

still confused,

greg k-h

[toc] | [prev] | [next] | [standalone]

#1562664 — Re: [PATCH 4.9 033/120] perf/x86/intel/uncore: Fix hardcoded socket 0 assumption in the Haswell init code

On 01/18/2017 12:20 PM, Greg Kroah-Hartman wrote:
> On Wed, Jan 18, 2017 at 11:55:58AM -0500, Prarit Bhargava wrote:
>>
>>
>> On 01/18/2017 11:33 AM, Greg Kroah-Hartman wrote:
>>> On Wed, Jan 18, 2017 at 09:38:07AM -0500, Prarit Bhargava wrote:
>>>>
>>>>
>>>> On 01/18/2017 05:45 AM, Greg Kroah-Hartman wrote:
>>>>> 4.9-stable review patch.  If anyone has any objections, please let me know.
>>>>>
>>>>
>>>> Nack.
>>>>
>>>> The value of boot_cpu_data.logical_proc_id may be uninitialized and set to
>>>> default -1 on systems that pick a random core as boot cpu.  This was
>>>> inadvertently fixed by 9d85eb9119f4 ("x86/smpboot: Make logical package
>>>> management more robust") which is in 4.10-rc1.
>>>>
>>>> Before 9d85eb9119f4:
>>>>
>>>> [    3.971539] hswep_uncore_cpu_init: cpu 5 pkg 0 boot_cpu_data.logical_proc_id
>>>> 65535
>>>> [    3.976504] hswep_uncore_cpu_init: cpu 5 pkg 0 cpu_data(0).logical_proc_id 0
>>>>
>>>> After 9d85eb9119f4:
>>>>
>>>> [    3.919112] hswep_uncore_cpu_init: cpu 5 pkg 0 boot_cpu_data.logical_proc_id 0
>>>> [    3.923391] hswep_uncore_cpu_init: cpu 5 pkg 0 cpu_data(0).logical_proc_id 0
>>>>
>>>> This patch should not be applied to any stable branch.
>>>
>>> So the fixes: line lies?  This isn't needed at all for 4.9?
>>
>> No, the fixes: line does not lie.  This patch is not needed at all for 4.9.
>> Other patches are required beyond this patch in order for 4.9 to remain stable.
>>
>> This patch is 6d6daa20945f ("perf/x86/intel/uncore: Fix hardcoded socket 0
>> assumption in the Haswell init code") which was tested on and applied to
>> 4.10-rc3 IIRC.  This patch was applied to 4.10-rc4.
>>
>> [prarit@prarit linux]$ git describe --contains 6d6daa20945f
>> v4.10-rc4~9^2~5
> 
> Yes, but the patch says it is fixing a bug since 4.6-rc1.  The fixes
> line says:
> 	    Fixes: cf6d445f6897 ("perf/x86/uncore: Track packages, not per CPU data")
> 
> $ git dc cf6d445f6897
> v4.6-rc1~165^2~28
> 
> (dc is my git alias for "describe --contains" as I type it so often...)
> 
>> 4.9 is broken and requires additional patches beyond this patch.  Applying this
>> patch to 4.9 stable without those additional fixes will result in kernel panics
>> on some Haswell systems that boot on random cores.
> 
> So, does 4.9 on its own work properly on these systems?  If not, what
> are the commits that are needed to fix it?

The system is being used by someone else atm.  I know of at least two commits
that are required but I have not tested them on 4.9 or 4.9 stable.  I do know
that 4.10-rc2-ish was broken on these systems when booting on any other cpu than
cpu 0.

> 
> If 4.9 is fine as-is, great, we should drop this patch then, correct?
> But then that fixes: line lied :(

Let me see if I can explain it this way:

(The commits are displayed as commit hash, version that contains commit, and my
own description)

cf6d445f6897 v4.6-rc1~165^2~28 <- what my commit "Fixes:"

d49597fd3bc v4.9-rc6~33^2 <- required for 9d85eb9119f, causes
boot_cpu_data.logical_proc_id is -1.

9d85eb9119f v4.10-rc1~51^2~8 <- This patch unintentionally fixes code so that
boot_cpu_data.logical_proc_id is greater than or equal to 0.

6d6daa20945f v4.10-rc4~9^2~5 <- my commit, expects boot_cpu_data.logical_proc_id
greater than or equal to 0.



cf6d445f6897 v4.6-rc1~165^2~28 caused the bug to happen.

When I found the bug the upstream tree was at 4.10-rc2-ish.  My fix for the bug
is 6d6daa20945f v4.10-rc4~9^2~5 which has "Fixes: cf6d445f6897" because that
commit causes this to happen.

If my commit 6d6daa20945f v4.10-rc4~9^2~5 is applied to 4.9 stable without
9d85eb9119f v4.10-rc1~51^2~8 things will be *worse* because
boot_cpu_data.logical_proc_id is -1, and this will result in a NULL pointer
panic during boot on *all* Haswell systems.

If we take d49597fd3bc, 9d85eb9119f, and 6d6daa20945f things should work but as
I said above, I have not built or tested that.  I can test this combination of
patches if you think it is worthwhile for 4.9 stable.

I think the fixes: line is correct.  The git bisect points at that commit.  The
problem with backporting my patch to 4.9 is that my fix requires other patches
that are not in 4.9.

P.

[toc] | [prev] | [next] | [standalone]

Page 4 of 5 — ← Prev page 1 2 3 [4] 5  Next page →

Back to top | Article view | linux.kernel

csiph-web