- Linux-stable-mirror - lists.linaro.org

Patch "arm: spear13xx: Fix spics gpio controller's warning" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled arm: spear13xx: Fix spics gpio controller's warning to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: arm-spear13xx-fix-spics-gpio-controller-s-warning.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From f8975cb1b8a36d0839b6365235778dd9df1d04ca Mon Sep 17 00:00:00 2001 From: Viresh Kumar <viresh.kumar(a)linaro.org> Date: Thu, 11 Jan 2018 11:28:53 +0530 Subject: arm: spear13xx: Fix spics gpio controller's warning From: Viresh Kumar <viresh.kumar(a)linaro.org> commit f8975cb1b8a36d0839b6365235778dd9df1d04ca upstream. This fixes the following warning by also sending the flags argument for gpio controllers: Property 'cs-gpios', cell 6 is not a phandle reference in /ahb/apb/spi@e0100000 Fixes: 8113ba917dfa ("ARM: SPEAr: DT: Update device nodes") Cc: stable(a)vger.kernel.org # v3.8+ Reported-by: Arnd Bergmann <arnd(a)arndb.de> Signed-off-by: Viresh Kumar <viresh.kumar(a)linaro.org> Signed-off-by: Olof Johansson <olof(a)lixom.net> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/arm/boot/dts/spear1310-evb.dts | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/arch/arm/boot/dts/spear1310-evb.dts +++ b/arch/arm/boot/dts/spear1310-evb.dts @@ -349,7 +349,7 @@ spi0: spi@e0100000 { status = "okay"; num-cs = <3>; - cs-gpios = <&gpio1 7 0>, <&spics 0>, <&spics 1>; + cs-gpios = <&gpio1 7 0>, <&spics 0 0>, <&spics 1 0>; stmpe610@0 { compatible = "st,stmpe610"; Patches currently in stable-queue which might be from viresh.kumar(a)linaro.org are queue-4.4/arm-spear600-add-missing-interrupt-parent-of-rtc.patch queue-4.4/arm-spear13xx-fix-spics-gpio-controller-s-warning.patch queue-4.4/arm-spear13xx-fix-dmas-cells.patch

7 years, 7 months

1
0
0 0

Patch "arm: spear13xx: Fix dmas cells" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled arm: spear13xx: Fix dmas cells to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: arm-spear13xx-fix-dmas-cells.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From cdd10409914184c7eee5ae3e11beb890c9c16c61 Mon Sep 17 00:00:00 2001 From: Viresh Kumar <viresh.kumar(a)linaro.org> Date: Thu, 11 Jan 2018 11:28:52 +0530 Subject: arm: spear13xx: Fix dmas cells From: Viresh Kumar <viresh.kumar(a)linaro.org> commit cdd10409914184c7eee5ae3e11beb890c9c16c61 upstream. The "dmas" cells for the designware DMA controller need to have only 3 properties apart from the phandle: request line, src master and destination master. But the commit 6e8887f60f60 updated it incorrectly while moving from platform code to DT. Fix it. Cc: stable(a)vger.kernel.org # v3.10+ Fixes: 6e8887f60f60 ("ARM: SPEAr13xx: Pass generic DW DMAC platform data from DT") Reported-by: Arnd Bergmann <arnd(a)arndb.de> Signed-off-by: Viresh Kumar <viresh.kumar(a)linaro.org> Signed-off-by: Olof Johansson <olof(a)lixom.net> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- Documentation/devicetree/bindings/dma/snps-dma.txt | 2 +- arch/arm/boot/dts/spear1340.dtsi | 4 ++-- arch/arm/boot/dts/spear13xx.dtsi | 6 +++--- 3 files changed, 6 insertions(+), 6 deletions(-) --- a/Documentation/devicetree/bindings/dma/snps-dma.txt +++ b/Documentation/devicetree/bindings/dma/snps-dma.txt @@ -58,6 +58,6 @@ Example: interrupts = <0 35 0x4>; status = "disabled"; dmas = <&dmahost 12 0 1>, - <&dmahost 13 0 1 0>; + <&dmahost 13 1 0>; dma-names = "rx", "rx"; }; --- a/arch/arm/boot/dts/spear1340.dtsi +++ b/arch/arm/boot/dts/spear1340.dtsi @@ -141,8 +141,8 @@ reg = <0xb4100000 0x1000>; interrupts = <0 105 0x4>; status = "disabled"; - dmas = <&dwdma0 0x600 0 0 1>, /* 0xC << 11 */ - <&dwdma0 0x680 0 1 0>; /* 0xD << 7 */ + dmas = <&dwdma0 12 0 1>, + <&dwdma0 13 1 0>; dma-names = "tx", "rx"; }; --- a/arch/arm/boot/dts/spear13xx.dtsi +++ b/arch/arm/boot/dts/spear13xx.dtsi @@ -100,7 +100,7 @@ reg = <0xb2800000 0x1000>; interrupts = <0 29 0x4>; status = "disabled"; - dmas = <&dwdma0 0 0 0 0>; + dmas = <&dwdma0 0 0 0>; dma-names = "data"; }; @@ -288,8 +288,8 @@ #size-cells = <0>; interrupts = <0 31 0x4>; status = "disabled"; - dmas = <&dwdma0 0x2000 0 0 0>, /* 0x4 << 11 */ - <&dwdma0 0x0280 0 0 0>; /* 0x5 << 7 */ + dmas = <&dwdma0 4 0 0>, + <&dwdma0 5 0 0>; dma-names = "tx", "rx"; }; Patches currently in stable-queue which might be from viresh.kumar(a)linaro.org are queue-4.4/arm-spear600-add-missing-interrupt-parent-of-rtc.patch queue-4.4/arm-spear13xx-fix-spics-gpio-controller-s-warning.patch queue-4.4/arm-spear13xx-fix-dmas-cells.patch

7 years, 7 months

1
0
0 0

Patch "ARM: dts: STi: Add gpio polarity for "hdmi, hpd-gpio" property" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled ARM: dts: STi: Add gpio polarity for "hdmi,hpd-gpio" property to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: arm-dts-sti-add-gpio-polarity-for-hdmi-hpd-gpio-property.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 7ac1f59c09a61e6af6622df6809e003b0af07f3d Mon Sep 17 00:00:00 2001 From: Patrice Chotard <patrice.chotard(a)st.com> Date: Wed, 10 Jan 2018 09:21:02 +0100 Subject: ARM: dts: STi: Add gpio polarity for "hdmi,hpd-gpio" property From: Patrice Chotard <patrice.chotard(a)st.com> commit 7ac1f59c09a61e6af6622df6809e003b0af07f3d upstream. The GPIO polarity is missing in the hdmi,hpd-gpio property, this fixes the following DT warnings: arch/arm/boot/dts/stih410-b2120.dtb: Warning (gpios_property): hdmi,hpd-gpio property size (8) too small for cell size 2 in /soc/sti-display-subsystem/sti-hdmi@8d04000 arch/arm/boot/dts/stih407-b2120.dtb: Warning (gpios_property): hdmi,hpd-gpio property size (8) too small for cell size 2 in /soc/sti-display-subsystem/sti-hdmi@8d04000 arch/arm/boot/dts/stih410-b2260.dtb: Warning (gpios_property): hdmi,hpd-gpio property size (8) too small for cell size 2 in /soc/sti-display-subsystem/sti-hdmi@8d04000 [arnd: marked Cc:stable since this warning shows up with the latest dtc by default, and is more likely to actually cause problems than the other patches from this series] Cc: stable(a)vger.kernel.org Signed-off-by: Patrice Chotard <patrice.chotard(a)st.com> Signed-off-by: Arnd Bergmann <arnd(a)arndb.de> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/arm/boot/dts/stih407.dtsi | 3 ++- arch/arm/boot/dts/stih410.dtsi | 3 ++- 2 files changed, 4 insertions(+), 2 deletions(-) --- a/arch/arm/boot/dts/stih407.dtsi +++ b/arch/arm/boot/dts/stih407.dtsi @@ -8,6 +8,7 @@ */ #include "stih407-clock.dtsi" #include "stih407-family.dtsi" +#include <dt-bindings/gpio/gpio.h> / { soc { sti-display-subsystem { @@ -112,7 +113,7 @@ <&clk_s_d2_quadfs 0>, <&clk_s_d2_quadfs 1>; - hdmi,hpd-gpio = <&pio5 3>; + hdmi,hpd-gpio = <&pio5 3 GPIO_ACTIVE_LOW>; reset-names = "hdmi"; resets = <&softreset STIH407_HDMI_TX_PHY_SOFTRESET>; ddc = <&hdmiddc>; --- a/arch/arm/boot/dts/stih410.dtsi +++ b/arch/arm/boot/dts/stih410.dtsi @@ -9,6 +9,7 @@ #include "stih410-clock.dtsi" #include "stih407-family.dtsi" #include "stih410-pinctrl.dtsi" +#include <dt-bindings/gpio/gpio.h> / { aliases { bdisp0 = &bdisp0; @@ -203,7 +204,7 @@ <&clk_s_d2_quadfs 0>, <&clk_s_d2_quadfs 1>; - hdmi,hpd-gpio = <&pio5 3>; + hdmi,hpd-gpio = <&pio5 3 GPIO_ACTIVE_LOW>; reset-names = "hdmi"; resets = <&softreset STIH407_HDMI_TX_PHY_SOFTRESET>; ddc = <&hdmiddc>; Patches currently in stable-queue which might be from patrice.chotard(a)st.com are queue-4.4/arm-dts-sti-add-gpio-polarity-for-hdmi-hpd-gpio-property.patch

7 years, 7 months

1
0
0 0

Patch "x86/xen: init %gs very early to avoid page faults with stack protector" has been added to the 4.15-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled x86/xen: init %gs very early to avoid page faults with stack protector to the 4.15-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: x86-xen-init-gs-very-early-to-avoid-page-faults-with-stack-protector.patch and it can be found in the queue-4.15 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 4f277295e54c5b7340e48efea3fc5cc21a2872b7 Mon Sep 17 00:00:00 2001 From: Juergen Gross <jgross(a)suse.com> Date: Thu, 1 Feb 2018 13:40:19 +0100 Subject: x86/xen: init %gs very early to avoid page faults with stack protector From: Juergen Gross <jgross(a)suse.com> commit 4f277295e54c5b7340e48efea3fc5cc21a2872b7 upstream. When running as Xen pv guest %gs is initialized some time after C code is started. Depending on stack protector usage this might be too late, resulting in page faults. So setup %gs and MSR_GS_BASE in assembly code already. Cc: stable(a)vger.kernel.org Signed-off-by: Juergen Gross <jgross(a)suse.com> Reviewed-by: Boris Ostrovsky <boris.ostrovsky(a)oracle.com> Tested-by: Chris Patterson <cjp256(a)gmail.com> Signed-off-by: Juergen Gross <jgross(a)suse.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/x86/xen/xen-head.S | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) --- a/arch/x86/xen/xen-head.S +++ b/arch/x86/xen/xen-head.S @@ -9,7 +9,9 @@ #include <asm/boot.h> #include <asm/asm.h> +#include <asm/msr.h> #include <asm/page_types.h> +#include <asm/percpu.h> #include <asm/unwind_hints.h> #include <xen/interface/elfnote.h> @@ -35,6 +37,20 @@ ENTRY(startup_xen) mov %_ASM_SI, xen_start_info mov $init_thread_union+THREAD_SIZE, %_ASM_SP +#ifdef CONFIG_X86_64 + /* Set up %gs. + * + * The base of %gs always points to the bottom of the irqstack + * union. If the stack protector canary is enabled, it is + * located at %gs:40. Note that, on SMP, the boot cpu uses + * init data section till per cpu areas are set up. + */ + movl $MSR_GS_BASE,%ecx + movq $INIT_PER_CPU_VAR(irq_stack_union),%rax + cdq + wrmsr +#endif + jmp xen_start_kernel END(startup_xen) __FINIT Patches currently in stable-queue which might be from jgross(a)suse.com are queue-4.15/x86-xen-init-gs-very-early-to-avoid-page-faults-with-stack-protector.patch

7 years, 7 months

1
0
0 0

Patch "x86/kexec: Make kexec (mostly) work in 5-level paging mode" has been added to the 4.15-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled x86/kexec: Make kexec (mostly) work in 5-level paging mode to the 4.15-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: x86-kexec-make-kexec-mostly-work-in-5-level-paging-mode.patch and it can be found in the queue-4.15 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 5bf30316991d5bcda046343ee77d823cf16fdd03 Mon Sep 17 00:00:00 2001 From: "Kirill A. Shutemov" <kirill.shutemov(a)linux.intel.com> Date: Mon, 29 Jan 2018 14:08:45 +0300 Subject: x86/kexec: Make kexec (mostly) work in 5-level paging mode From: Kirill A. Shutemov <kirill.shutemov(a)linux.intel.com> commit 5bf30316991d5bcda046343ee77d823cf16fdd03 upstream. Currently kexec() will crash when switching into a 5-level paging enabled kernel. I missed that we need to change relocate_kernel() to set CR4.LA57 flag if the kernel has 5-level paging enabled. I avoided using #ifdef CONFIG_X86_5LEVEL here and inferred if we need to enable 5-level paging from previous CR4 value. This way the code is ready for boot-time switching between paging modes. With this patch applied, in addition to kexec 4-to-4 which always worked, we can kexec 4-to-5 and 5-to-5 - while 5-to-4 will need more work. Reported-by: Baoquan He <bhe(a)redhat.com> Signed-off-by: Kirill A. Shutemov <kirill.shutemov(a)linux.intel.com> Tested-by: Baoquan He <bhe(a)redhat.com> Cc: <stable(a)vger.kernel.org> # v4.14+ Cc: Borislav Petkov <bp(a)suse.de> Cc: Linus Torvalds <torvalds(a)linux-foundation.org> Cc: Peter Zijlstra <peterz(a)infradead.org> Cc: Thomas Gleixner <tglx(a)linutronix.de> Cc: linux-mm(a)kvack.org Fixes: 77ef56e4f0fb ("x86: Enable 5-level paging support via CONFIG_X86_5LEVEL=y") Link: http://lkml.kernel.org/r/20180129110845.26633-1-kirill.shutemov@linux.intel… Signed-off-by: Ingo Molnar <mingo(a)kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/x86/kernel/relocate_kernel_64.S | 8 ++++++++ 1 file changed, 8 insertions(+) --- a/arch/x86/kernel/relocate_kernel_64.S +++ b/arch/x86/kernel/relocate_kernel_64.S @@ -68,6 +68,9 @@ relocate_kernel: movq %cr4, %rax movq %rax, CR4(%r11) + /* Save CR4. Required to enable the right paging mode later. */ + movq %rax, %r13 + /* zero out flags, and disable interrupts */ pushq $0 popfq @@ -126,8 +129,13 @@ identity_mapped: /* * Set cr4 to a known state: * - physical address extension enabled + * - 5-level paging, if it was enabled before */ movl $X86_CR4_PAE, %eax + testq $X86_CR4_LA57, %r13 + jz 1f + orl $X86_CR4_LA57, %eax +1: movq %rax, %cr4 jmp 1f Patches currently in stable-queue which might be from kirill.shutemov(a)linux.intel.com are queue-4.15/x86-kexec-make-kexec-mostly-work-in-5-level-paging-mode.patch

7 years, 7 months

1
0
0 0

Patch "x86/gpu: add CFL to early quirks" has been added to the 4.15-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled x86/gpu: add CFL to early quirks to the 4.15-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: x86-gpu-add-cfl-to-early-quirks.patch and it can be found in the queue-4.15 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 33aa69ed8aacd92dea12671e52eb3ca6ac2d7a49 Mon Sep 17 00:00:00 2001 From: Lucas De Marchi <lucas.demarchi(a)intel.com> Date: Wed, 13 Dec 2017 12:04:25 -0800 Subject: x86/gpu: add CFL to early quirks From: Lucas De Marchi <lucas.demarchi(a)intel.com> commit 33aa69ed8aacd92dea12671e52eb3ca6ac2d7a49 upstream. CFL was missing from intel_early_ids[]. The PCI ID needs to be there to allow the memory region to be stolen, otherwise we could have RAM being arbitrarily overwritten if for example we keep using the UEFI framebuffer, depending on how BIOS has set up the e820 map. Fixes: b056f8f3d6b9 ("drm/i915/cfl: Add Coffee Lake PCI IDs for S Skus.") Signed-off-by: Lucas De Marchi <lucas.demarchi(a)intel.com> Cc: Rodrigo Vivi <rodrigo.vivi(a)intel.com> Cc: Anusha Srivatsa <anusha.srivatsa(a)intel.com> Cc: Jani Nikula <jani.nikula(a)linux.intel.com> Cc: Joonas Lahtinen <joonas.lahtinen(a)linux.intel.com> Cc: David Airlie <airlied(a)linux.ie> Cc: intel-gfx(a)lists.freedesktop.org Cc: dri-devel(a)lists.freedesktop.org Cc: Ingo Molnar <mingo(a)kernel.org> Cc: H. Peter Anvin <hpa(a)zytor.com> Cc: Thomas Gleixner <tglx(a)linutronix.de> Cc: x86(a)kernel.org Cc: <stable(a)vger.kernel.org> # v4.13+ 0890540e21cf drm/i915: add GT number to intel_device_info Cc: <stable(a)vger.kernel.org> # v4.13+ 41693fd52373 drm/i915/kbl: Change a KBL pci id to GT2 from GT1.5 Cc: <stable(a)vger.kernel.org> # v4.13+ Reviewed-by: Rodrigo Vivi <rodrigo.vivi(a)intel.com> Acked-by: Jani Nikula <jani.nikula(a)intel.com> Acked-by: Ingo Molnar <mingo(a)kernel.org> Signed-off-by: Rodrigo Vivi <rodrigo.vivi(a)intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171213200425.2954-1-lucas.d… Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/x86/kernel/early-quirks.c | 1 + include/drm/i915_pciids.h | 6 ++++++ 2 files changed, 7 insertions(+) --- a/arch/x86/kernel/early-quirks.c +++ b/arch/x86/kernel/early-quirks.c @@ -527,6 +527,7 @@ static const struct pci_device_id intel_ INTEL_SKL_IDS(&gen9_early_ops), INTEL_BXT_IDS(&gen9_early_ops), INTEL_KBL_IDS(&gen9_early_ops), + INTEL_CFL_IDS(&gen9_early_ops), INTEL_GLK_IDS(&gen9_early_ops), INTEL_CNL_IDS(&gen9_early_ops), }; --- a/include/drm/i915_pciids.h +++ b/include/drm/i915_pciids.h @@ -392,6 +392,12 @@ INTEL_VGA_DEVICE(0x3EA8, info), /* ULT GT3 */ \ INTEL_VGA_DEVICE(0x3EA5, info) /* ULT GT3 */ +#define INTEL_CFL_IDS(info) \ + INTEL_CFL_S_GT1_IDS(info), \ + INTEL_CFL_S_GT2_IDS(info), \ + INTEL_CFL_H_GT2_IDS(info), \ + INTEL_CFL_U_GT3_IDS(info) + /* CNL U 2+2 */ #define INTEL_CNL_U_GT2_IDS(info) \ INTEL_VGA_DEVICE(0x5A52, info), \ Patches currently in stable-queue which might be from lucas.demarchi(a)intel.com are queue-4.15/x86-gpu-add-cfl-to-early-quirks.patch

7 years, 7 months

1
0
0 0

Patch "trace_uprobe: Display correct offset in uprobe_events" has been added to the 4.15-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled trace_uprobe: Display correct offset in uprobe_events to the 4.15-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: trace_uprobe-display-correct-offset-in-uprobe_events.patch and it can be found in the queue-4.15 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 0e4d819d0893dc043ea7b7cb6baf4be1e310bd96 Mon Sep 17 00:00:00 2001 From: Ravi Bangoria <ravi.bangoria(a)linux.vnet.ibm.com> Date: Sat, 6 Jan 2018 11:12:46 +0530 Subject: trace_uprobe: Display correct offset in uprobe_events From: Ravi Bangoria <ravi.bangoria(a)linux.vnet.ibm.com> commit 0e4d819d0893dc043ea7b7cb6baf4be1e310bd96 upstream. Recently, how the pointers being printed with %p has been changed by commit ad67b74d2469 ("printk: hash addresses printed with %p"). This is causing a regression while showing offset in the uprobe_events file. Instead of %p, use %px to display offset. Before patch: # perf probe -vv -x /tmp/a.out main Opening /sys/kernel/debug/tracing//uprobe_events write=1 Writing event: p:probe_a/main /tmp/a.out:0x58c # cat /sys/kernel/debug/tracing/uprobe_events p:probe_a/main /tmp/a.out:0x0000000049a0f352 After patch: # cat /sys/kernel/debug/tracing/uprobe_events p:probe_a/main /tmp/a.out:0x000000000000058c Link: http://lkml.kernel.org/r/20180106054246.15375-1-ravi.bangoria@linux.vnet.ib… Cc: stable(a)vger.kernel.org Fixes: ad67b74d2469 ("printk: hash addresses printed with %p") Acked-by: Srikar Dronamraju <srikar(a)linux.vnet.ibm.com> Signed-off-by: Ravi Bangoria <ravi.bangoria(a)linux.vnet.ibm.com> Signed-off-by: Steven Rostedt (VMware) <rostedt(a)goodmis.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- kernel/trace/trace_uprobe.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/kernel/trace/trace_uprobe.c +++ b/kernel/trace/trace_uprobe.c @@ -608,7 +608,7 @@ static int probes_seq_show(struct seq_fi /* Don't print "0x (null)" when offset is 0 */ if (tu->offset) { - seq_printf(m, "0x%p", (void *)tu->offset); + seq_printf(m, "0x%px", (void *)tu->offset); } else { switch (sizeof(void *)) { case 4: Patches currently in stable-queue which might be from ravi.bangoria(a)linux.vnet.ibm.com are queue-4.15/trace_uprobe-display-correct-offset-in-uprobe_events.patch

7 years, 7 months

1
0
0 0

Patch "swiotlb: suppress warning when __GFP_NOWARN is set" has been added to the 4.15-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled swiotlb: suppress warning when __GFP_NOWARN is set to the 4.15-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: swiotlb-suppress-warning-when-__gfp_nowarn-is-set.patch and it can be found in the queue-4.15 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From d0bc0c2a31c95002d37c3cc511ffdcab851b3256 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Christian=20K=C3=B6nig?= <ckoenig.leichtzumerken(a)gmail.com> Date: Thu, 4 Jan 2018 14:24:19 +0100 Subject: swiotlb: suppress warning when __GFP_NOWARN is set MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Christian König <ckoenig.leichtzumerken(a)gmail.com> commit d0bc0c2a31c95002d37c3cc511ffdcab851b3256 upstream. TTM tries to allocate coherent memory in chunks of 2MB first to improve TLB efficiency and falls back to allocating 4K pages if that fails. Suppress the warning when the 2MB allocations fails since there is a valid fall back path. Signed-off-by: Christian König <christian.koenig(a)amd.com> Reported-by: Mike Galbraith <efault(a)gmx.de> Acked-by: Konrad Rzeszutek Wilk <konrad.wilk(a)oracle.com> Bug: https://bugs.freedesktop.org/show_bug.cgi?id=104082 Signed-off-by: Christoph Hellwig <hch(a)lst.de> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- lib/swiotlb.c | 15 +++++++++------ 1 file changed, 9 insertions(+), 6 deletions(-) --- a/lib/swiotlb.c +++ b/lib/swiotlb.c @@ -586,7 +586,7 @@ phys_addr_t swiotlb_tbl_map_single(struc not_found: spin_unlock_irqrestore(&io_tlb_lock, flags); - if (printk_ratelimit()) + if (!(attrs & DMA_ATTR_NO_WARN) && printk_ratelimit()) dev_warn(hwdev, "swiotlb buffer is full (sz: %zd bytes)\n", size); return SWIOTLB_MAP_ERROR; found: @@ -713,6 +713,7 @@ void * swiotlb_alloc_coherent(struct device *hwdev, size_t size, dma_addr_t *dma_handle, gfp_t flags) { + bool warn = !(flags & __GFP_NOWARN); dma_addr_t dev_addr; void *ret; int order = get_order(size); @@ -738,8 +739,8 @@ swiotlb_alloc_coherent(struct device *hw * GFP_DMA memory; fall back on map_single(), which * will grab memory from the lowest available address range. */ - phys_addr_t paddr = map_single(hwdev, 0, size, - DMA_FROM_DEVICE, 0); + phys_addr_t paddr = map_single(hwdev, 0, size, DMA_FROM_DEVICE, + warn ? 0 : DMA_ATTR_NO_WARN); if (paddr == SWIOTLB_MAP_ERROR) goto err_warn; @@ -769,9 +770,11 @@ swiotlb_alloc_coherent(struct device *hw return ret; err_warn: - pr_warn("swiotlb: coherent allocation failed for device %s size=%zu\n", - dev_name(hwdev), size); - dump_stack(); + if (warn && printk_ratelimit()) { + pr_warn("swiotlb: coherent allocation failed for device %s size=%zu\n", + dev_name(hwdev), size); + dump_stack(); + } return NULL; } Patches currently in stable-queue which might be from ckoenig.leichtzumerken(a)gmail.com are queue-4.15/dma-buf-fix-reservation_object_wait_timeout_rcu-once-more-v2.patch queue-4.15/swiotlb-suppress-warning-when-__gfp_nowarn-is-set.patch

7 years, 7 months

1
0
0 0

Patch "s390: fix handling of -1 in set{, fs}[gu]id16 syscalls" has been added to the 4.15-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled s390: fix handling of -1 in set{,fs}[gu]id16 syscalls to the 4.15-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: s390-fix-handling-of-1-in-set-fs-id16-syscalls.patch and it can be found in the queue-4.15 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 6dd0d2d22aa363fec075cb2577ba273ac8462e94 Mon Sep 17 00:00:00 2001 From: Eugene Syromiatnikov <esyr(a)redhat.com> Date: Mon, 15 Jan 2018 20:38:17 +0100 Subject: s390: fix handling of -1 in set{,fs}[gu]id16 syscalls From: Eugene Syromiatnikov <esyr(a)redhat.com> commit 6dd0d2d22aa363fec075cb2577ba273ac8462e94 upstream. For some reason, the implementation of some 16-bit ID system calls (namely, setuid16/setgid16 and setfsuid16/setfsgid16) used type cast instead of low2highgid/low2highuid macros for converting [GU]IDs, which led to incorrect handling of value of -1 (which ought to be considered invalid). Discovered by strace test suite. Cc: stable(a)vger.kernel.org Signed-off-by: Eugene Syromiatnikov <esyr(a)redhat.com> Signed-off-by: Heiko Carstens <heiko.carstens(a)de.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky(a)de.ibm.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/s390/kernel/compat_linux.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) --- a/arch/s390/kernel/compat_linux.c +++ b/arch/s390/kernel/compat_linux.c @@ -110,7 +110,7 @@ COMPAT_SYSCALL_DEFINE2(s390_setregid16, COMPAT_SYSCALL_DEFINE1(s390_setgid16, u16, gid) { - return sys_setgid((gid_t)gid); + return sys_setgid(low2highgid(gid)); } COMPAT_SYSCALL_DEFINE2(s390_setreuid16, u16, ruid, u16, euid) @@ -120,7 +120,7 @@ COMPAT_SYSCALL_DEFINE2(s390_setreuid16, COMPAT_SYSCALL_DEFINE1(s390_setuid16, u16, uid) { - return sys_setuid((uid_t)uid); + return sys_setuid(low2highuid(uid)); } COMPAT_SYSCALL_DEFINE3(s390_setresuid16, u16, ruid, u16, euid, u16, suid) @@ -173,12 +173,12 @@ COMPAT_SYSCALL_DEFINE3(s390_getresgid16, COMPAT_SYSCALL_DEFINE1(s390_setfsuid16, u16, uid) { - return sys_setfsuid((uid_t)uid); + return sys_setfsuid(low2highuid(uid)); } COMPAT_SYSCALL_DEFINE1(s390_setfsgid16, u16, gid) { - return sys_setfsgid((gid_t)gid); + return sys_setfsgid(low2highgid(gid)); } static int groups16_to_user(u16 __user *grouplist, struct group_info *group_info) Patches currently in stable-queue which might be from esyr(a)redhat.com are queue-4.15/s390-fix-handling-of-1-in-set-fs-id16-syscalls.patch

7 years, 7 months

1
0
0 0

Patch "powerpc/xive: Use hw CPU ids when configuring the CPU queues" has been added to the 4.15-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled powerpc/xive: Use hw CPU ids when configuring the CPU queues to the 4.15-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: powerpc-xive-use-hw-cpu-ids-when-configuring-the-cpu-queues.patch and it can be found in the queue-4.15 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 8e036c8d30a2cd9d8fc7442fbf6824e0a3e986e7 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?C=C3=A9dric=20Le=20Goater?= <clg(a)kaod.org> Date: Tue, 13 Feb 2018 09:47:12 +0100 Subject: powerpc/xive: Use hw CPU ids when configuring the CPU queues MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Cédric Le Goater <clg(a)kaod.org> commit 8e036c8d30a2cd9d8fc7442fbf6824e0a3e986e7 upstream. The CPU event notification queues on sPAPR should be configured using a hardware CPU identifier. The problem did not show up on the Power Hypervisor because pHyp supports 8 threads per core which keeps CPU number contiguous. This is not the case on all sPAPR virtual machines, some use SMT=1. Also improve error logging by adding the CPU number. Fixes: eac1e731b59e ("powerpc/xive: guest exploitation of the XIVE interrupt controller") Cc: stable(a)vger.kernel.org # v4.14+ Signed-off-by: Cédric Le Goater <clg(a)kaod.org> Signed-off-by: Michael Ellerman <mpe(a)ellerman.id.au> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/powerpc/sysdev/xive/spapr.c | 16 ++++++++++------ 1 file changed, 10 insertions(+), 6 deletions(-) --- a/arch/powerpc/sysdev/xive/spapr.c +++ b/arch/powerpc/sysdev/xive/spapr.c @@ -356,7 +356,8 @@ static int xive_spapr_configure_queue(u3 rc = plpar_int_get_queue_info(0, target, prio, &esn_page, &esn_size); if (rc) { - pr_err("Error %lld getting queue info prio %d\n", rc, prio); + pr_err("Error %lld getting queue info CPU %d prio %d\n", rc, + target, prio); rc = -EIO; goto fail; } @@ -370,7 +371,8 @@ static int xive_spapr_configure_queue(u3 /* Configure and enable the queue in HW */ rc = plpar_int_set_queue_config(flags, target, prio, qpage_phys, order); if (rc) { - pr_err("Error %lld setting queue for prio %d\n", rc, prio); + pr_err("Error %lld setting queue for CPU %d prio %d\n", rc, + target, prio); rc = -EIO; } else { q->qpage = qpage; @@ -389,8 +391,8 @@ static int xive_spapr_setup_queue(unsign if (IS_ERR(qpage)) return PTR_ERR(qpage); - return xive_spapr_configure_queue(cpu, q, prio, qpage, - xive_queue_shift); + return xive_spapr_configure_queue(get_hard_smp_processor_id(cpu), + q, prio, qpage, xive_queue_shift); } static void xive_spapr_cleanup_queue(unsigned int cpu, struct xive_cpu *xc, @@ -399,10 +401,12 @@ static void xive_spapr_cleanup_queue(uns struct xive_q *q = &xc->queue[prio]; unsigned int alloc_order; long rc; + int hw_cpu = get_hard_smp_processor_id(cpu); - rc = plpar_int_set_queue_config(0, cpu, prio, 0, 0); + rc = plpar_int_set_queue_config(0, hw_cpu, prio, 0, 0); if (rc) - pr_err("Error %ld setting queue for prio %d\n", rc, prio); + pr_err("Error %ld setting queue for CPU %d prio %d\n", rc, + hw_cpu, prio); alloc_order = xive_alloc_order(xive_queue_shift); free_pages((unsigned long)q->qpage, alloc_order); Patches currently in stable-queue which might be from clg(a)kaod.org are queue-4.15/powerpc-xive-use-hw-cpu-ids-when-configuring-the-cpu-queues.patch

7 years, 7 months

1
0
0 0

Patch "powerpc/vas: Don't set uses_vas for kernel windows" has been added to the 4.15-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled powerpc/vas: Don't set uses_vas for kernel windows to the 4.15-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: powerpc-vas-don-t-set-uses_vas-for-kernel-windows.patch and it can be found in the queue-4.15 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From b00b62898631b756c3e123542bbb0487aa343dd9 Mon Sep 17 00:00:00 2001 From: Nicholas Piggin <npiggin(a)gmail.com> Date: Thu, 8 Feb 2018 19:18:38 +1000 Subject: powerpc/vas: Don't set uses_vas for kernel windows From: Nicholas Piggin <npiggin(a)gmail.com> commit b00b62898631b756c3e123542bbb0487aa343dd9 upstream. cp_abort is only required for user windows, because kernel context must not be preempted between a copy/paste pair. Without this patch, the init task gets used_vas set when it runs the nx842_powernv_init initcall, which opens windows for kernel usage. used_vas is then never cleared anywhere, so it gets propagated into all other tasks. It's a property of the address space, so it should really be cleared when a new mm is created (or in dup_mmap if the mmaps are marked as VM_DONTCOPY). For now we seem to have no such driver, so leave that for another patch. Fixes: 6c8e6bb2a52d ("powerpc/vas: Add support for user receive window") Cc: stable(a)vger.kernel.org # v4.15+ Signed-off-by: Nicholas Piggin <npiggin(a)gmail.com> Reviewed-by: Sukadev Bhattiprolu <sukadev(a)linux.vnet.ibm.com> Signed-off-by: Michael Ellerman <mpe(a)ellerman.id.au> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/powerpc/platforms/powernv/vas-window.c | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) --- a/arch/powerpc/platforms/powernv/vas-window.c +++ b/arch/powerpc/platforms/powernv/vas-window.c @@ -1063,16 +1063,16 @@ struct vas_window *vas_tx_win_open(int v rc = PTR_ERR(txwin->paste_kaddr); goto free_window; } + } else { + /* + * A user mapping must ensure that context switch issues + * CP_ABORT for this thread. + */ + rc = set_thread_uses_vas(); + if (rc) + goto free_window; } - /* - * Now that we have a send window, ensure context switch issues - * CP_ABORT for this thread. - */ - rc = -EINVAL; - if (set_thread_uses_vas() < 0) - goto free_window; - set_vinst_win(vinst, txwin); return txwin; Patches currently in stable-queue which might be from npiggin(a)gmail.com are queue-4.15/powerpc-vas-don-t-set-uses_vas-for-kernel-windows.patch

7 years, 7 months

1
0
0 0

Patch "powerpc/radix: Remove trace_tlbie call from radix__flush_tlb_all" has been added to the 4.15-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled powerpc/radix: Remove trace_tlbie call from radix__flush_tlb_all to the 4.15-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: powerpc-radix-remove-trace_tlbie-call-from-radix__flush_tlb_all.patch and it can be found in the queue-4.15 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 8d81296cfcce89013a714feb8d25004a156f8181 Mon Sep 17 00:00:00 2001 From: Mahesh Salgaonkar <mahesh(a)linux.vnet.ibm.com> Date: Thu, 30 Nov 2017 14:35:54 +0530 Subject: powerpc/radix: Remove trace_tlbie call from radix__flush_tlb_all From: Mahesh Salgaonkar <mahesh(a)linux.vnet.ibm.com> commit 8d81296cfcce89013a714feb8d25004a156f8181 upstream. radix__flush_tlb_all() is called only in kexec path in real mode and any tracepoints at this stage will make kexec to fail if enabled. To verify enable tlbie trace before kexec. $ echo 1 > /sys/kernel/debug/tracing/events/powerpc/tlbie/enable == kexec into new kernel and kexec fails. Fix this by not calling trace_tlbie from radix__flush_tlb_all(). Fixes: 0428491cba92 ("powerpc/mm: Trace tlbie(l) instructions") Cc: stable(a)vger.kernel.org # v4.13+ Signed-off-by: Mahesh Salgaonkar <mahesh(a)linux.vnet.ibm.com> Acked-by: Balbir Singh <bsingharora(a)gmail.com> Signed-off-by: Michael Ellerman <mpe(a)ellerman.id.au> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/powerpc/mm/tlb-radix.c | 2 -- 1 file changed, 2 deletions(-) --- a/arch/powerpc/mm/tlb-radix.c +++ b/arch/powerpc/mm/tlb-radix.c @@ -600,14 +600,12 @@ void radix__flush_tlb_all(void) */ asm volatile(PPC_TLBIE_5(%0, %4, %3, %2, %1) : : "r"(rb), "i"(r), "i"(1), "i"(ric), "r"(rs) : "memory"); - trace_tlbie(0, 0, rb, rs, ric, prs, r); /* * now flush host entires by passing PRS = 0 and LPID == 0 */ asm volatile(PPC_TLBIE_5(%0, %4, %3, %2, %1) : : "r"(rb), "i"(r), "i"(prs), "i"(ric), "r"(0) : "memory"); asm volatile("eieio; tlbsync; ptesync": : :"memory"); - trace_tlbie(0, 0, rb, 0, ric, prs, r); } void radix__flush_tlb_pte_p9_dd1(unsigned long old_pte, struct mm_struct *mm, Patches currently in stable-queue which might be from mahesh(a)linux.vnet.ibm.com are queue-4.15/powerpc-radix-remove-trace_tlbie-call-from-radix__flush_tlb_all.patch

7 years, 7 months

1
0
0 0

Patch "powerpc/numa: Invalidate numa_cpu_lookup_table on cpu remove" has been added to the 4.15-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled powerpc/numa: Invalidate numa_cpu_lookup_table on cpu remove to the 4.15-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: powerpc-numa-invalidate-numa_cpu_lookup_table-on-cpu-remove.patch and it can be found in the queue-4.15 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 1d9a090783bef19fe8cdec878620d22f05191316 Mon Sep 17 00:00:00 2001 From: Nathan Fontenot <nfont(a)linux.vnet.ibm.com> Date: Fri, 26 Jan 2018 13:41:59 -0600 Subject: powerpc/numa: Invalidate numa_cpu_lookup_table on cpu remove From: Nathan Fontenot <nfont(a)linux.vnet.ibm.com> commit 1d9a090783bef19fe8cdec878620d22f05191316 upstream. When DLPAR removing a CPU, the unmapping of the cpu from a node in unmap_cpu_from_node() should also invalidate the CPUs entry in the numa_cpu_lookup_table. There is not a guarantee that on a subsequent DLPAR add of the CPU the associativity will be the same and thus could be in a different node. Invalidating the entry in the numa_cpu_lookup_table causes the associativity to be read from the device tree at the time of the add. The current behavior of not invalidating the CPUs entry in the numa_cpu_lookup_table can result in scenarios where the the topology layout of CPUs in the partition does not match the device tree or the topology reported by the HMC. This bug looks like it was introduced in 2004 in the commit titled "ppc64: cpu hotplug notifier for numa", which is 6b15e4e87e32 in the linux-fullhist tree. Hence tag it for all stable releases. Cc: stable(a)vger.kernel.org Signed-off-by: Nathan Fontenot <nfont(a)linux.vnet.ibm.com> Reviewed-by: Tyrel Datwyler <tyreld(a)linux.vnet.ibm.com> Signed-off-by: Michael Ellerman <mpe(a)ellerman.id.au> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/powerpc/include/asm/topology.h | 5 +++++ arch/powerpc/mm/numa.c | 5 ----- arch/powerpc/platforms/pseries/hotplug-cpu.c | 2 ++ 3 files changed, 7 insertions(+), 5 deletions(-) --- a/arch/powerpc/include/asm/topology.h +++ b/arch/powerpc/include/asm/topology.h @@ -44,6 +44,11 @@ extern int sysfs_add_device_to_node(stru extern void sysfs_remove_device_from_node(struct device *dev, int nid); extern int numa_update_cpu_topology(bool cpus_locked); +static inline void update_numa_cpu_lookup_table(unsigned int cpu, int node) +{ + numa_cpu_lookup_table[cpu] = node; +} + static inline int early_cpu_to_node(int cpu) { int nid; --- a/arch/powerpc/mm/numa.c +++ b/arch/powerpc/mm/numa.c @@ -142,11 +142,6 @@ static void reset_numa_cpu_lookup_table( numa_cpu_lookup_table[cpu] = -1; } -static void update_numa_cpu_lookup_table(unsigned int cpu, int node) -{ - numa_cpu_lookup_table[cpu] = node; -} - static void map_cpu_to_node(int cpu, int node) { update_numa_cpu_lookup_table(cpu, node); --- a/arch/powerpc/platforms/pseries/hotplug-cpu.c +++ b/arch/powerpc/platforms/pseries/hotplug-cpu.c @@ -36,6 +36,7 @@ #include <asm/xics.h> #include <asm/xive.h> #include <asm/plpar_wrappers.h> +#include <asm/topology.h> #include "pseries.h" #include "offline_states.h" @@ -331,6 +332,7 @@ static void pseries_remove_processor(str BUG_ON(cpu_online(cpu)); set_cpu_present(cpu, false); set_hard_smp_processor_id(cpu, -1); + update_numa_cpu_lookup_table(cpu, -1); break; } if (cpu >= nr_cpu_ids) Patches currently in stable-queue which might be from nfont(a)linux.vnet.ibm.com are queue-4.15/powerpc-numa-invalidate-numa_cpu_lookup_table-on-cpu-remove.patch

7 years, 7 months

1
0
0 0

Patch "powerpc/mm: Flush radix process translations when setting MMU type" has been added to the 4.15-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled powerpc/mm: Flush radix process translations when setting MMU type to the 4.15-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: powerpc-mm-flush-radix-process-translations-when-setting-mmu-type.patch and it can be found in the queue-4.15 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 62e984ddfd6b056d399e24113f5e6a7145e579d8 Mon Sep 17 00:00:00 2001 From: Alexey Kardashevskiy <aik(a)ozlabs.ru> Date: Thu, 1 Feb 2018 16:09:44 +1100 Subject: powerpc/mm: Flush radix process translations when setting MMU type From: Alexey Kardashevskiy <aik(a)ozlabs.ru> commit 62e984ddfd6b056d399e24113f5e6a7145e579d8 upstream. Radix guests do normally invalidate process-scoped translations when a new pid is allocated but migrated guests do not invalidate these so migrated guests crash sometime, especially easy to reproduce with migration happening within first 10 seconds after the guest boot start on the same machine. This adds the "Invalidate process-scoped translations" flush to fix radix guests migration. Fixes: 2ee13be34b13 ("KVM: PPC: Book3S HV: Update kvmppc_set_arch_compat() for ISA v3.00") Cc: stable(a)vger.kernel.org # v4.10+ Signed-off-by: Alexey Kardashevskiy <aik(a)ozlabs.ru> Tested-by: Laurent Vivier <lvivier(a)redhat.com> Tested-by: Daniel Henrique Barboza <danielhb(a)linux.vnet.ibm.com> Signed-off-by: Michael Ellerman <mpe(a)ellerman.id.au> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/powerpc/mm/pgtable_64.c | 2 ++ 1 file changed, 2 insertions(+) --- a/arch/powerpc/mm/pgtable_64.c +++ b/arch/powerpc/mm/pgtable_64.c @@ -483,6 +483,8 @@ void mmu_partition_table_set_entry(unsig if (old & PATB_HR) { asm volatile(PPC_TLBIE_5(%0,%1,2,0,1) : : "r" (TLBIEL_INVAL_SET_LPID), "r" (lpid)); + asm volatile(PPC_TLBIE_5(%0,%1,2,1,1) : : + "r" (TLBIEL_INVAL_SET_LPID), "r" (lpid)); trace_tlbie(lpid, 0, TLBIEL_INVAL_SET_LPID, lpid, 2, 0, 1); } else { asm volatile(PPC_TLBIE_5(%0,%1,2,0,0) : : Patches currently in stable-queue which might be from aik(a)ozlabs.ru are queue-4.15/powerpc-mm-flush-radix-process-translations-when-setting-mmu-type.patch

7 years, 7 months

1
0
0 0

Patch "powerpc/kernel: Block interrupts when updating TIDR" has been added to the 4.15-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled powerpc/kernel: Block interrupts when updating TIDR to the 4.15-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: powerpc-kernel-block-interrupts-when-updating-tidr.patch and it can be found in the queue-4.15 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 384dfd627f1ee67d028e6f14c6e9bf5a1e2a7a24 Mon Sep 17 00:00:00 2001 From: Sukadev Bhattiprolu <sukadev(a)linux.vnet.ibm.com> Date: Tue, 28 Nov 2017 13:39:43 -0600 Subject: powerpc/kernel: Block interrupts when updating TIDR From: Sukadev Bhattiprolu <sukadev(a)linux.vnet.ibm.com> commit 384dfd627f1ee67d028e6f14c6e9bf5a1e2a7a24 upstream. clear_thread_tidr() is called in interrupt context as a part of delayed put of the task structure (i.e as a part of timer interrupt). To prevent a deadlock, block interrupts when holding vas_thread_id_lock to set/ clear TIDR for a task. Fixes: ec233ede4c86 ("powerpc: Add support for setting SPRN_TIDR") Cc: stable(a)vger.kernel.org # v4.15+ Signed-off-by: Sukadev Bhattiprolu <sukadev(a)linux.vnet.ibm.com> Signed-off-by: Michael Ellerman <mpe(a)ellerman.id.au> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/powerpc/kernel/process.c | 15 +++++++++------ 1 file changed, 9 insertions(+), 6 deletions(-) --- a/arch/powerpc/kernel/process.c +++ b/arch/powerpc/kernel/process.c @@ -1509,14 +1509,15 @@ static int assign_thread_tidr(void) { int index; int err; + unsigned long flags; again: if (!ida_pre_get(&vas_thread_ida, GFP_KERNEL)) return -ENOMEM; - spin_lock(&vas_thread_id_lock); + spin_lock_irqsave(&vas_thread_id_lock, flags); err = ida_get_new_above(&vas_thread_ida, 1, &index); - spin_unlock(&vas_thread_id_lock); + spin_unlock_irqrestore(&vas_thread_id_lock, flags); if (err == -EAGAIN) goto again; @@ -1524,9 +1525,9 @@ again: return err; if (index > MAX_THREAD_CONTEXT) { - spin_lock(&vas_thread_id_lock); + spin_lock_irqsave(&vas_thread_id_lock, flags); ida_remove(&vas_thread_ida, index); - spin_unlock(&vas_thread_id_lock); + spin_unlock_irqrestore(&vas_thread_id_lock, flags); return -ENOMEM; } @@ -1535,9 +1536,11 @@ again: static void free_thread_tidr(int id) { - spin_lock(&vas_thread_id_lock); + unsigned long flags; + + spin_lock_irqsave(&vas_thread_id_lock, flags); ida_remove(&vas_thread_ida, id); - spin_unlock(&vas_thread_id_lock); + spin_unlock_irqrestore(&vas_thread_id_lock, flags); } /* Patches currently in stable-queue which might be from sukadev(a)linux.vnet.ibm.com are queue-4.15/powerpc-kernel-block-interrupts-when-updating-tidr.patch queue-4.15/powerpc-vas-don-t-set-uses_vas-for-kernel-windows.patch

7 years, 7 months

1
0
0 0

Patch "PM / devfreq: Propagate error from devfreq_add_device()" has been added to the 4.15-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled PM / devfreq: Propagate error from devfreq_add_device() to the 4.15-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: pm-devfreq-propagate-error-from-devfreq_add_device.patch and it can be found in the queue-4.15 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From d1bf2d30728f310f72296b54f0651ecdb09cbb12 Mon Sep 17 00:00:00 2001 From: Bjorn Andersson <bjorn.andersson(a)linaro.org> Date: Sun, 5 Nov 2017 21:27:41 -0800 Subject: PM / devfreq: Propagate error from devfreq_add_device() From: Bjorn Andersson <bjorn.andersson(a)linaro.org> commit d1bf2d30728f310f72296b54f0651ecdb09cbb12 upstream. Propagate the error of devfreq_add_device() in devm_devfreq_add_device() rather than statically returning ENOMEM. This makes it slightly faster to pinpoint the cause of a returned error. Fixes: 8cd84092d35e ("PM / devfreq: Add resource-managed function for devfreq device") Cc: stable(a)vger.kernel.org Acked-by: Chanwoo Choi <cw00.choi(a)samsung.com> Signed-off-by: Bjorn Andersson <bjorn.andersson(a)linaro.org> Signed-off-by: MyungJoo Ham <myungjoo.ham(a)samsung.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/devfreq/devfreq.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/devfreq/devfreq.c +++ b/drivers/devfreq/devfreq.c @@ -737,7 +737,7 @@ struct devfreq *devm_devfreq_add_device( devfreq = devfreq_add_device(dev, profile, governor_name, data); if (IS_ERR(devfreq)) { devres_free(ptr); - return ERR_PTR(-ENOMEM); + return devfreq; } *ptr = devfreq; Patches currently in stable-queue which might be from bjorn.andersson(a)linaro.org are queue-4.15/pm-devfreq-propagate-error-from-devfreq_add_device.patch queue-4.15/arm64-dts-msm8916-correct-ipc-references-for-smsm.patch

7 years, 7 months

1
0
0 0

Patch "ocfs2: try a blocking lock before return AOP_TRUNCATED_PAGE" has been added to the 4.15-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled ocfs2: try a blocking lock before return AOP_TRUNCATED_PAGE to the 4.15-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: ocfs2-try-a-blocking-lock-before-return-aop_truncated_page.patch and it can be found in the queue-4.15 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From ff26cc10aec128c3f86b5611fd5f59c71d49c0e3 Mon Sep 17 00:00:00 2001 From: Gang He <ghe(a)suse.com> Date: Wed, 31 Jan 2018 16:14:48 -0800 Subject: ocfs2: try a blocking lock before return AOP_TRUNCATED_PAGE From: Gang He <ghe(a)suse.com> commit ff26cc10aec128c3f86b5611fd5f59c71d49c0e3 upstream. If we can't get inode lock immediately in the function ocfs2_inode_lock_with_page() when reading a page, we should not return directly here, since this will lead to a softlockup problem when the kernel is configured with CONFIG_PREEMPT is not set. The method is to get a blocking lock and immediately unlock before returning, this can avoid CPU resource waste due to lots of retries, and benefits fairness in getting lock among multiple nodes, increase efficiency in case modifying the same file frequently from multiple nodes. The softlockup crash (when set /proc/sys/kernel/softlockup_panic to 1) looks like: Kernel panic - not syncing: softlockup: hung tasks CPU: 0 PID: 885 Comm: multi_mmap Tainted: G L 4.12.14-6.1-default #1 Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 Call Trace: <IRQ> dump_stack+0x5c/0x82 panic+0xd5/0x21e watchdog_timer_fn+0x208/0x210 __hrtimer_run_queues+0xcc/0x200 hrtimer_interrupt+0xa6/0x1f0 smp_apic_timer_interrupt+0x34/0x50 apic_timer_interrupt+0x96/0xa0 </IRQ> RIP: 0010:unlock_page+0x17/0x30 RSP: 0000:ffffaf154080bc88 EFLAGS: 00000246 ORIG_RAX: ffffffffffffff10 RAX: dead000000000100 RBX: fffff21e009f5300 RCX: 0000000000000004 RDX: dead0000000000ff RSI: 0000000000000202 RDI: fffff21e009f5300 RBP: 0000000000000000 R08: 0000000000000000 R09: ffffaf154080bb00 R10: ffffaf154080bc30 R11: 0000000000000040 R12: ffff993749a39518 R13: 0000000000000000 R14: fffff21e009f5300 R15: fffff21e009f5300 ocfs2_inode_lock_with_page+0x25/0x30 [ocfs2] ocfs2_readpage+0x41/0x2d0 [ocfs2] filemap_fault+0x12b/0x5c0 ocfs2_fault+0x29/0xb0 [ocfs2] __do_fault+0x1a/0xa0 __handle_mm_fault+0xbe8/0x1090 handle_mm_fault+0xaa/0x1f0 __do_page_fault+0x235/0x4b0 trace_do_page_fault+0x3c/0x110 async_page_fault+0x28/0x30 RIP: 0033:0x7fa75ded638e RSP: 002b:00007ffd6657db18 EFLAGS: 00010287 RAX: 000055c7662fb700 RBX: 0000000000000001 RCX: 000055c7662fb700 RDX: 0000000000001770 RSI: 00007fa75e909000 RDI: 000055c7662fb700 RBP: 0000000000000003 R08: 000000000000000e R09: 0000000000000000 R10: 0000000000000483 R11: 00007fa75ded61b0 R12: 00007fa75e90a770 R13: 000000000000000e R14: 0000000000001770 R15: 0000000000000000 About performance improvement, we can see the testing time is reduced, and CPU utilization decreases, the detailed data is as follows. I ran multi_mmap test case in ocfs2-test package in a three nodes cluster. Before applying this patch: PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 2754 ocfs2te+ 20 0 170248 6980 4856 D 80.73 0.341 0:18.71 multi_mmap 1505 root rt 0 222236 123060 97224 S 2.658 6.015 0:01.44 corosync 5 root 20 0 0 0 0 S 1.329 0.000 0:00.19 kworker/u8:0 95 root 20 0 0 0 0 S 1.329 0.000 0:00.25 kworker/u8:1 2728 root 20 0 0 0 0 S 0.997 0.000 0:00.24 jbd2/sda1-33 2721 root 20 0 0 0 0 S 0.664 0.000 0:00.07 ocfs2dc-3C8CFD4 2750 ocfs2te+ 20 0 142976 4652 3532 S 0.664 0.227 0:00.28 mpirun ocfs2test@tb-node2:~>multiple_run.sh -i ens3 -k ~/linux-4.4.21-69.tar.gz -o ~/ocfs2mullog -C hacluster -s pcmk -n tb-node2,tb-node1,tb-node3 -d /dev/sda1 -b 4096 -c 32768 -t multi_mmap /mnt/shared Tests with "-b 4096 -C 32768" Thu Dec 28 14:44:52 CST 2017 multi_mmap..................................................Passed. Runtime 783 seconds. After apply this patch: PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 2508 ocfs2te+ 20 0 170248 6804 4680 R 54.00 0.333 0:55.37 multi_mmap 155 root 20 0 0 0 0 S 2.667 0.000 0:01.20 kworker/u8:3 95 root 20 0 0 0 0 S 2.000 0.000 0:01.58 kworker/u8:1 2504 ocfs2te+ 20 0 142976 4604 3480 R 1.667 0.225 0:01.65 mpirun 5 root 20 0 0 0 0 S 1.000 0.000 0:01.36 kworker/u8:0 2482 root 20 0 0 0 0 S 1.000 0.000 0:00.86 jbd2/sda1-33 299 root 0 -20 0 0 0 S 0.333 0.000 0:00.13 kworker/2:1H 335 root 0 -20 0 0 0 S 0.333 0.000 0:00.17 kworker/1:1H 535 root 20 0 12140 7268 1456 S 0.333 0.355 0:00.34 haveged 1282 root rt 0 222284 123108 97224 S 0.333 6.017 0:01.33 corosync ocfs2test@tb-node2:~>multiple_run.sh -i ens3 -k ~/linux-4.4.21-69.tar.gz -o ~/ocfs2mullog -C hacluster -s pcmk -n tb-node2,tb-node1,tb-node3 -d /dev/sda1 -b 4096 -c 32768 -t multi_mmap /mnt/shared Tests with "-b 4096 -C 32768" Thu Dec 28 15:04:12 CST 2017 multi_mmap..................................................Passed. Runtime 487 seconds. Link: http://lkml.kernel.org/r/1514447305-30814-1-git-send-email-ghe@suse.com Fixes: 1cce4df04f37 ("ocfs2: do not lock/unlock() inode DLM lock") Signed-off-by: Gang He <ghe(a)suse.com> Reviewed-by: Eric Ren <zren(a)suse.com> Acked-by: alex chen <alex.chen(a)huawei.com> Acked-by: piaojun <piaojun(a)huawei.com> Cc: Mark Fasheh <mfasheh(a)versity.com> Cc: Joel Becker <jlbec(a)evilplan.org> Cc: Junxiao Bi <junxiao.bi(a)oracle.com> Cc: Joseph Qi <jiangqi903(a)gmail.com> Cc: Changwei Ge <ge.changwei(a)h3c.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- fs/ocfs2/dlmglue.c | 9 +++++++++ 1 file changed, 9 insertions(+) --- a/fs/ocfs2/dlmglue.c +++ b/fs/ocfs2/dlmglue.c @@ -2486,6 +2486,15 @@ int ocfs2_inode_lock_with_page(struct in ret = ocfs2_inode_lock_full(inode, ret_bh, ex, OCFS2_LOCK_NONBLOCK); if (ret == -EAGAIN) { unlock_page(page); + /* + * If we can't get inode lock immediately, we should not return + * directly here, since this will lead to a softlockup problem. + * The method is to get a blocking lock and immediately unlock + * before returning, this can avoid CPU resource waste due to + * lots of retries, and benefits fairness in getting lock. + */ + if (ocfs2_inode_lock(inode, ret_bh, ex) == 0) + ocfs2_inode_unlock(inode, ex); ret = AOP_TRUNCATED_PAGE; } Patches currently in stable-queue which might be from ghe(a)suse.com are queue-4.15/ocfs2-try-a-blocking-lock-before-return-aop_truncated_page.patch

7 years, 7 months

1
0
0 0

Patch "mwifiex: resolve reset vs. remove()/shutdown() deadlocks" has been added to the 4.15-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled mwifiex: resolve reset vs. remove()/shutdown() deadlocks to the 4.15-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: mwifiex-resolve-reset-vs.-remove-shutdown-deadlocks.patch and it can be found in the queue-4.15 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From a64e7a79dd6030479caad603c8d78e6c9c14904f Mon Sep 17 00:00:00 2001 From: Brian Norris <briannorris(a)chromium.org> Date: Fri, 12 Jan 2018 13:08:37 -0800 Subject: mwifiex: resolve reset vs. remove()/shutdown() deadlocks From: Brian Norris <briannorris(a)chromium.org> commit a64e7a79dd6030479caad603c8d78e6c9c14904f upstream. Commit b014e96d1abb ("PCI: Protect pci_error_handlers->reset_notify() usage with device_lock()") resolves races between driver reset and removal, but it introduces some new deadlock problems. If we see a timeout while we've already started suspending, removing, or shutting down the driver, we might see: (a) a worker thread, running mwifiex_pcie_work() -> mwifiex_pcie_card_reset_work() -> pci_reset_function() (b) a removal thread, running mwifiex_pcie_remove() -> mwifiex_free_adapter() -> mwifiex_unregister() -> mwifiex_cleanup_pcie() -> cancel_work_sync(&card->work) Unfortunately, mwifiex_pcie_remove() already holds the device lock that pci_reset_function() is now requesting, and so we see a deadlock. It's necessary to cancel and synchronize our outstanding work before tearing down the driver, so we can't have this work wait indefinitely for the lock. It's reasonable to only "try" to reset here, since this will mostly happen for cases where it's already difficult to reset the firmware anyway (e.g., while we're suspending or powering off the system). And if reset *really* needs to happen, we can always try again later. Fixes: b014e96d1abb ("PCI: Protect pci_error_handlers->reset_notify() usage with device_lock()") Cc: <stable(a)vger.kernel.org> Cc: Xinming Hu <huxm(a)marvell.com> Signed-off-by: Brian Norris <briannorris(a)chromium.org> Signed-off-by: Kalle Valo <kvalo(a)codeaurora.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/wireless/marvell/mwifiex/pcie.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) --- a/drivers/net/wireless/marvell/mwifiex/pcie.c +++ b/drivers/net/wireless/marvell/mwifiex/pcie.c @@ -2781,7 +2781,10 @@ static void mwifiex_pcie_card_reset_work { struct pcie_service_card *card = adapter->card; - pci_reset_function(card->dev); + /* We can't afford to wait here; remove() might be waiting on us. If we + * can't grab the device lock, maybe we'll get another chance later. + */ + pci_try_reset_function(card->dev); } static void mwifiex_pcie_work(struct work_struct *work) Patches currently in stable-queue which might be from briannorris(a)chromium.org are queue-4.15/mwifiex-resolve-reset-vs.-remove-shutdown-deadlocks.patch

7 years, 7 months

1
0
0 0

Patch "dma-buf: fix reservation_object_wait_timeout_rcu once more v2" has been added to the 4.15-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled dma-buf: fix reservation_object_wait_timeout_rcu once more v2 to the 4.15-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: dma-buf-fix-reservation_object_wait_timeout_rcu-once-more-v2.patch and it can be found in the queue-4.15 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 5bffee867df7494ecd32c1e6ec4e8fc934c521b7 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Christian=20K=C3=B6nig?= <ckoenig.leichtzumerken(a)gmail.com> Date: Mon, 22 Jan 2018 21:00:03 +0100 Subject: dma-buf: fix reservation_object_wait_timeout_rcu once more v2 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Christian König <ckoenig.leichtzumerken(a)gmail.com> commit 5bffee867df7494ecd32c1e6ec4e8fc934c521b7 upstream. We need to set shared_count even if we already have a fence to wait for. v2: init i to -1 as well Signed-off-by: Christian König <christian.koenig(a)amd.com> Cc: stable(a)vger.kernel.org Tested-by: Lyude Paul <lyude(a)redhat.com> Reviewed-by: Lyude Paul <lyude(a)redhat.com> Reviewed-by: Chris Wilson <chris(a)chris-wilson.co.uk> Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180122200003.6665-1-christi… Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/dma-buf/reservation.c | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) --- a/drivers/dma-buf/reservation.c +++ b/drivers/dma-buf/reservation.c @@ -455,13 +455,15 @@ long reservation_object_wait_timeout_rcu unsigned long timeout) { struct dma_fence *fence; - unsigned seq, shared_count, i = 0; + unsigned seq, shared_count; long ret = timeout ? timeout : 1; + int i; retry: shared_count = 0; seq = read_seqcount_begin(&obj->seq); rcu_read_lock(); + i = -1; fence = rcu_dereference(obj->fence_excl); if (fence && !test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, &fence->flags)) { @@ -477,14 +479,14 @@ retry: fence = NULL; } - if (!fence && wait_all) { + if (wait_all) { struct reservation_object_list *fobj = rcu_dereference(obj->fence); if (fobj) shared_count = fobj->shared_count; - for (i = 0; i < shared_count; ++i) { + for (i = 0; !fence && i < shared_count; ++i) { struct dma_fence *lfence = rcu_dereference(fobj->shared[i]); if (test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, Patches currently in stable-queue which might be from ckoenig.leichtzumerken(a)gmail.com are queue-4.15/dma-buf-fix-reservation_object_wait_timeout_rcu-once-more-v2.patch queue-4.15/swiotlb-suppress-warning-when-__gfp_nowarn-is-set.patch

7 years, 7 months

1
0
0 0

Patch "cpufreq: powernv: Dont assume distinct pstate values for nominal and pmin" has been added to the 4.15-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled cpufreq: powernv: Dont assume distinct pstate values for nominal and pmin to the 4.15-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: cpufreq-powernv-dont-assume-distinct-pstate-values-for-nominal-and-pmin.patch and it can be found in the queue-4.15 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 3fa4680b860bf48b437d6a2c039789c4abe202ae Mon Sep 17 00:00:00 2001 From: Shilpasri G Bhat <shilpa.bhat(a)linux.vnet.ibm.com> Date: Fri, 12 Jan 2018 12:43:53 +0530 Subject: cpufreq: powernv: Dont assume distinct pstate values for nominal and pmin From: Shilpasri G Bhat <shilpa.bhat(a)linux.vnet.ibm.com> commit 3fa4680b860bf48b437d6a2c039789c4abe202ae upstream. Some OpenPOWER boxes can have same pstate values for nominal and pmin pstates. In these boxes the current code will not initialize 'powernv_pstate_info.min' variable and result in erroneous CPU frequency reporting. This patch fixes this problem. Fixes: 09ca4c9b5958 (cpufreq: powernv: Replacing pstate_id with frequency table index) Reported-by: Alvin Wang <wangat(a)tw.ibm.com> Signed-off-by: Shilpasri G Bhat <shilpa.bhat(a)linux.vnet.ibm.com> Acked-by: Viresh Kumar <viresh.kumar(a)linaro.org> Cc: 4.8+ <stable(a)vger.kernel.org> # 4.8+ Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki(a)intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/cpufreq/powernv-cpufreq.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) --- a/drivers/cpufreq/powernv-cpufreq.c +++ b/drivers/cpufreq/powernv-cpufreq.c @@ -288,9 +288,9 @@ next: if (id == pstate_max) powernv_pstate_info.max = i; - else if (id == pstate_nominal) + if (id == pstate_nominal) powernv_pstate_info.nominal = i; - else if (id == pstate_min) + if (id == pstate_min) powernv_pstate_info.min = i; if (powernv_pstate_info.wof_enabled && id == pstate_turbo) { Patches currently in stable-queue which might be from shilpa.bhat(a)linux.vnet.ibm.com are queue-4.15/cpufreq-powernv-dont-assume-distinct-pstate-values-for-nominal-and-pmin.patch

7 years, 7 months

1
0
0 0

Patch "arm64: dts: msm8916: Correct ipc references for smsm" has been added to the 4.15-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled arm64: dts: msm8916: Correct ipc references for smsm to the 4.15-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: arm64-dts-msm8916-correct-ipc-references-for-smsm.patch and it can be found in the queue-4.15 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 566bd8902e7fa20bd412ed753e09e89c1c96939c Mon Sep 17 00:00:00 2001 From: Bjorn Andersson <bjorn.andersson(a)linaro.org> Date: Thu, 30 Nov 2017 21:27:32 -0800 Subject: arm64: dts: msm8916: Correct ipc references for smsm From: Bjorn Andersson <bjorn.andersson(a)linaro.org> commit 566bd8902e7fa20bd412ed753e09e89c1c96939c upstream. SMSM is not symmetrical, the incoming bits from WCNSS are available at index 6, but the outgoing host id for WCNSS is 3. Further more, upstream references the base of APCS (in contrast to downstream), so the register offset of 8 must be included. Fixes: 1fb47e0a9ba4 ("arm64: dts: qcom: msm8916: Add smsm and smp2p nodes") Cc: stable(a)vger.kernel.org Reported-by: Ramon Fried <rfried(a)codeaurora.org> Signed-off-by: Bjorn Andersson <bjorn.andersson(a)linaro.org> Signed-off-by: Andy Gross <andy.gross(a)linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/arm64/boot/dts/qcom/msm8916.dtsi | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) --- a/arch/arm64/boot/dts/qcom/msm8916.dtsi +++ b/arch/arm64/boot/dts/qcom/msm8916.dtsi @@ -1435,8 +1435,8 @@ #address-cells = <1>; #size-cells = <0>; - qcom,ipc-1 = <&apcs 0 13>; - qcom,ipc-6 = <&apcs 0 19>; + qcom,ipc-1 = <&apcs 8 13>; + qcom,ipc-3 = <&apcs 8 19>; apps_smsm: apps@0 { reg = <0>; Patches currently in stable-queue which might be from bjorn.andersson(a)linaro.org are queue-4.15/pm-devfreq-propagate-error-from-devfreq_add_device.patch queue-4.15/arm64-dts-msm8916-correct-ipc-references-for-smsm.patch

7 years, 7 months

1
0
0 0

Patch "arm: spear600: Add missing interrupt-parent of rtc" has been added to the 4.15-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled arm: spear600: Add missing interrupt-parent of rtc to the 4.15-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: arm-spear600-add-missing-interrupt-parent-of-rtc.patch and it can be found in the queue-4.15 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 6ffb5b4f248fe53e0361b8cbc2a523b432566442 Mon Sep 17 00:00:00 2001 From: Viresh Kumar <viresh.kumar(a)linaro.org> Date: Thu, 11 Jan 2018 11:28:51 +0530 Subject: arm: spear600: Add missing interrupt-parent of rtc From: Viresh Kumar <viresh.kumar(a)linaro.org> commit 6ffb5b4f248fe53e0361b8cbc2a523b432566442 upstream. The interrupt-parent of rtc was missing, add it. Fixes: 8113ba917dfa ("ARM: SPEAr: DT: Update device nodes") Cc: stable(a)vger.kernel.org # v3.8+ Reported-by: Arnd Bergmann <arnd(a)arndb.de> Signed-off-by: Viresh Kumar <viresh.kumar(a)linaro.org> Signed-off-by: Olof Johansson <olof(a)lixom.net> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/arm/boot/dts/spear600.dtsi | 1 + 1 file changed, 1 insertion(+) --- a/arch/arm/boot/dts/spear600.dtsi +++ b/arch/arm/boot/dts/spear600.dtsi @@ -194,6 +194,7 @@ rtc: rtc@fc900000 { compatible = "st,spear600-rtc"; reg = <0xfc900000 0x1000>; + interrupt-parent = <&vic0>; interrupts = <10>; status = "disabled"; }; Patches currently in stable-queue which might be from viresh.kumar(a)linaro.org are queue-4.15/arm-spear600-add-missing-interrupt-parent-of-rtc.patch queue-4.15/arm-spear13xx-fix-spics-gpio-controller-s-warning.patch queue-4.15/cpufreq-powernv-dont-assume-distinct-pstate-values-for-nominal-and-pmin.patch queue-4.15/arm-spear13xx-fix-dmas-cells.patch

7 years, 7 months

1
0
0 0

Patch "arm: spear13xx: Fix spics gpio controller's warning" has been added to the 4.15-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled arm: spear13xx: Fix spics gpio controller's warning to the 4.15-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: arm-spear13xx-fix-spics-gpio-controller-s-warning.patch and it can be found in the queue-4.15 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From f8975cb1b8a36d0839b6365235778dd9df1d04ca Mon Sep 17 00:00:00 2001 From: Viresh Kumar <viresh.kumar(a)linaro.org> Date: Thu, 11 Jan 2018 11:28:53 +0530 Subject: arm: spear13xx: Fix spics gpio controller's warning From: Viresh Kumar <viresh.kumar(a)linaro.org> commit f8975cb1b8a36d0839b6365235778dd9df1d04ca upstream. This fixes the following warning by also sending the flags argument for gpio controllers: Property 'cs-gpios', cell 6 is not a phandle reference in /ahb/apb/spi@e0100000 Fixes: 8113ba917dfa ("ARM: SPEAr: DT: Update device nodes") Cc: stable(a)vger.kernel.org # v3.8+ Reported-by: Arnd Bergmann <arnd(a)arndb.de> Signed-off-by: Viresh Kumar <viresh.kumar(a)linaro.org> Signed-off-by: Olof Johansson <olof(a)lixom.net> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/arm/boot/dts/spear1310-evb.dts | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/arch/arm/boot/dts/spear1310-evb.dts +++ b/arch/arm/boot/dts/spear1310-evb.dts @@ -349,7 +349,7 @@ spi0: spi@e0100000 { status = "okay"; num-cs = <3>; - cs-gpios = <&gpio1 7 0>, <&spics 0>, <&spics 1>; + cs-gpios = <&gpio1 7 0>, <&spics 0 0>, <&spics 1 0>; stmpe610@0 { compatible = "st,stmpe610"; Patches currently in stable-queue which might be from viresh.kumar(a)linaro.org are queue-4.15/arm-spear600-add-missing-interrupt-parent-of-rtc.patch queue-4.15/arm-spear13xx-fix-spics-gpio-controller-s-warning.patch queue-4.15/cpufreq-powernv-dont-assume-distinct-pstate-values-for-nominal-and-pmin.patch queue-4.15/arm-spear13xx-fix-dmas-cells.patch

7 years, 7 months

1
0
0 0

Patch "arm: spear13xx: Fix dmas cells" has been added to the 4.15-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled arm: spear13xx: Fix dmas cells to the 4.15-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: arm-spear13xx-fix-dmas-cells.patch and it can be found in the queue-4.15 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From cdd10409914184c7eee5ae3e11beb890c9c16c61 Mon Sep 17 00:00:00 2001 From: Viresh Kumar <viresh.kumar(a)linaro.org> Date: Thu, 11 Jan 2018 11:28:52 +0530 Subject: arm: spear13xx: Fix dmas cells From: Viresh Kumar <viresh.kumar(a)linaro.org> commit cdd10409914184c7eee5ae3e11beb890c9c16c61 upstream. The "dmas" cells for the designware DMA controller need to have only 3 properties apart from the phandle: request line, src master and destination master. But the commit 6e8887f60f60 updated it incorrectly while moving from platform code to DT. Fix it. Cc: stable(a)vger.kernel.org # v3.10+ Fixes: 6e8887f60f60 ("ARM: SPEAr13xx: Pass generic DW DMAC platform data from DT") Reported-by: Arnd Bergmann <arnd(a)arndb.de> Signed-off-by: Viresh Kumar <viresh.kumar(a)linaro.org> Signed-off-by: Olof Johansson <olof(a)lixom.net> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- Documentation/devicetree/bindings/dma/snps-dma.txt | 2 +- arch/arm/boot/dts/spear1340.dtsi | 4 ++-- arch/arm/boot/dts/spear13xx.dtsi | 6 +++--- 3 files changed, 6 insertions(+), 6 deletions(-) --- a/Documentation/devicetree/bindings/dma/snps-dma.txt +++ b/Documentation/devicetree/bindings/dma/snps-dma.txt @@ -64,6 +64,6 @@ Example: reg = <0xe0000000 0x1000>; interrupts = <0 35 0x4>; dmas = <&dmahost 12 0 1>, - <&dmahost 13 0 1 0>; + <&dmahost 13 1 0>; dma-names = "rx", "rx"; }; --- a/arch/arm/boot/dts/spear1340.dtsi +++ b/arch/arm/boot/dts/spear1340.dtsi @@ -142,8 +142,8 @@ reg = <0xb4100000 0x1000>; interrupts = <0 105 0x4>; status = "disabled"; - dmas = <&dwdma0 0x600 0 0 1>, /* 0xC << 11 */ - <&dwdma0 0x680 0 1 0>; /* 0xD << 7 */ + dmas = <&dwdma0 12 0 1>, + <&dwdma0 13 1 0>; dma-names = "tx", "rx"; }; --- a/arch/arm/boot/dts/spear13xx.dtsi +++ b/arch/arm/boot/dts/spear13xx.dtsi @@ -100,7 +100,7 @@ reg = <0xb2800000 0x1000>; interrupts = <0 29 0x4>; status = "disabled"; - dmas = <&dwdma0 0 0 0 0>; + dmas = <&dwdma0 0 0 0>; dma-names = "data"; }; @@ -290,8 +290,8 @@ #size-cells = <0>; interrupts = <0 31 0x4>; status = "disabled"; - dmas = <&dwdma0 0x2000 0 0 0>, /* 0x4 << 11 */ - <&dwdma0 0x0280 0 0 0>; /* 0x5 << 7 */ + dmas = <&dwdma0 4 0 0>, + <&dwdma0 5 0 0>; dma-names = "tx", "rx"; }; Patches currently in stable-queue which might be from viresh.kumar(a)linaro.org are queue-4.15/arm-spear600-add-missing-interrupt-parent-of-rtc.patch queue-4.15/arm-spear13xx-fix-spics-gpio-controller-s-warning.patch queue-4.15/cpufreq-powernv-dont-assume-distinct-pstate-values-for-nominal-and-pmin.patch queue-4.15/arm-spear13xx-fix-dmas-cells.patch

7 years, 7 months

1
0
0 0

Patch "ARM: lpc3250: fix uda1380 gpio numbers" has been added to the 4.15-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled ARM: lpc3250: fix uda1380 gpio numbers to the 4.15-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: arm-lpc3250-fix-uda1380-gpio-numbers.patch and it can be found in the queue-4.15 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From ca32e0c4bf9ca4b87089c5a5ce945e5f2ec890da Mon Sep 17 00:00:00 2001 From: Arnd Bergmann <arnd(a)arndb.de> Date: Wed, 10 Jan 2018 17:22:00 +0100 Subject: ARM: lpc3250: fix uda1380 gpio numbers From: Arnd Bergmann <arnd(a)arndb.de> commit ca32e0c4bf9ca4b87089c5a5ce945e5f2ec890da upstream. dtc warns about obviously incorrect GPIO numbers for the audio codec on both lpc32xx boards: arch/arm/boot/dts/lpc3250-phy3250.dtb: Warning (gpios_property): reset-gpio property size (12) too small for cell size 3 in /ahb/apb/i2c@400A0000/uda1380@18 arch/arm/boot/dts/lpc3250-phy3250.dtb: Warning (gpios_property): power-gpio property size (12) too small for cell size 3 in /ahb/apb/i2c@400A0000/uda1380@18 arch/arm/boot/dts/lpc3250-ea3250.dtb: Warning (gpios_property): reset-gpio property size (12) too small for cell size 3 in /ahb/apb/i2c@400A0000/uda1380@18 arch/arm/boot/dts/lpc3250-ea3250.dtb: Warning (gpios_property): power-gpio property size (12) too small for cell size 3 in /ahb/apb/i2c@400A0000/uda1380@18 It looks like the nodes are written for a different binding that combines the GPIO number into a single number rather than a bank/number pair. I found the right numbers on stackexchange.com, so this patch fixes the warning and has a reasonable chance of getting things to actually work. Cc: stable(a)vger.kernel.org Link: https://unix.stackexchange.com/questions/59497/alsa-asoc-how-to-correctly-l… Signed-off-by: Arnd Bergmann <arnd(a)arndb.de> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/arm/boot/dts/lpc3250-ea3250.dts | 4 ++-- arch/arm/boot/dts/lpc3250-phy3250.dts | 4 ++-- 2 files changed, 4 insertions(+), 4 deletions(-) --- a/arch/arm/boot/dts/lpc3250-ea3250.dts +++ b/arch/arm/boot/dts/lpc3250-ea3250.dts @@ -156,8 +156,8 @@ uda1380: uda1380@18 { compatible = "nxp,uda1380"; reg = <0x18>; - power-gpio = <&gpio 0x59 0>; - reset-gpio = <&gpio 0x51 0>; + power-gpio = <&gpio 3 10 0>; + reset-gpio = <&gpio 3 2 0>; dac-clk = "wspll"; }; --- a/arch/arm/boot/dts/lpc3250-phy3250.dts +++ b/arch/arm/boot/dts/lpc3250-phy3250.dts @@ -81,8 +81,8 @@ uda1380: uda1380@18 { compatible = "nxp,uda1380"; reg = <0x18>; - power-gpio = <&gpio 0x59 0>; - reset-gpio = <&gpio 0x51 0>; + power-gpio = <&gpio 3 10 0>; + reset-gpio = <&gpio 3 2 0>; dac-clk = "wspll"; }; Patches currently in stable-queue which might be from arnd(a)arndb.de are queue-4.15/arm-spear600-add-missing-interrupt-parent-of-rtc.patch queue-4.15/arm-dts-sti-add-gpio-polarity-for-hdmi-hpd-gpio-property.patch queue-4.15/kselftest-fix-oom-in-memory-compaction-test.patch queue-4.15/arm-spear13xx-fix-spics-gpio-controller-s-warning.patch queue-4.15/arm-lpc3250-fix-uda1380-gpio-numbers.patch queue-4.15/arm-spear13xx-fix-dmas-cells.patch queue-4.15/arm-dts-nomadik-add-interrupt-parent-for-clcd.patch

7 years, 7 months

1
0
0 0

Patch "ARM: dts: STi: Add gpio polarity for "hdmi, hpd-gpio" property" has been added to the 4.15-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled ARM: dts: STi: Add gpio polarity for "hdmi,hpd-gpio" property to the 4.15-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: arm-dts-sti-add-gpio-polarity-for-hdmi-hpd-gpio-property.patch and it can be found in the queue-4.15 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 7ac1f59c09a61e6af6622df6809e003b0af07f3d Mon Sep 17 00:00:00 2001 From: Patrice Chotard <patrice.chotard(a)st.com> Date: Wed, 10 Jan 2018 09:21:02 +0100 Subject: ARM: dts: STi: Add gpio polarity for "hdmi,hpd-gpio" property From: Patrice Chotard <patrice.chotard(a)st.com> commit 7ac1f59c09a61e6af6622df6809e003b0af07f3d upstream. The GPIO polarity is missing in the hdmi,hpd-gpio property, this fixes the following DT warnings: arch/arm/boot/dts/stih410-b2120.dtb: Warning (gpios_property): hdmi,hpd-gpio property size (8) too small for cell size 2 in /soc/sti-display-subsystem/sti-hdmi@8d04000 arch/arm/boot/dts/stih407-b2120.dtb: Warning (gpios_property): hdmi,hpd-gpio property size (8) too small for cell size 2 in /soc/sti-display-subsystem/sti-hdmi@8d04000 arch/arm/boot/dts/stih410-b2260.dtb: Warning (gpios_property): hdmi,hpd-gpio property size (8) too small for cell size 2 in /soc/sti-display-subsystem/sti-hdmi@8d04000 [arnd: marked Cc:stable since this warning shows up with the latest dtc by default, and is more likely to actually cause problems than the other patches from this series] Cc: stable(a)vger.kernel.org Signed-off-by: Patrice Chotard <patrice.chotard(a)st.com> Signed-off-by: Arnd Bergmann <arnd(a)arndb.de> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/arm/boot/dts/stih407.dtsi | 3 ++- arch/arm/boot/dts/stih410.dtsi | 3 ++- 2 files changed, 4 insertions(+), 2 deletions(-) --- a/arch/arm/boot/dts/stih407.dtsi +++ b/arch/arm/boot/dts/stih407.dtsi @@ -8,6 +8,7 @@ */ #include "stih407-clock.dtsi" #include "stih407-family.dtsi" +#include <dt-bindings/gpio/gpio.h> / { soc { sti-display-subsystem { @@ -122,7 +123,7 @@ <&clk_s_d2_quadfs 0>, <&clk_s_d2_quadfs 1>; - hdmi,hpd-gpio = <&pio5 3>; + hdmi,hpd-gpio = <&pio5 3 GPIO_ACTIVE_LOW>; reset-names = "hdmi"; resets = <&softreset STIH407_HDMI_TX_PHY_SOFTRESET>; ddc = <&hdmiddc>; --- a/arch/arm/boot/dts/stih410.dtsi +++ b/arch/arm/boot/dts/stih410.dtsi @@ -9,6 +9,7 @@ #include "stih410-clock.dtsi" #include "stih407-family.dtsi" #include "stih410-pinctrl.dtsi" +#include <dt-bindings/gpio/gpio.h> / { aliases { bdisp0 = &bdisp0; @@ -213,7 +214,7 @@ <&clk_s_d2_quadfs 0>, <&clk_s_d2_quadfs 1>; - hdmi,hpd-gpio = <&pio5 3>; + hdmi,hpd-gpio = <&pio5 3 GPIO_ACTIVE_LOW>; reset-names = "hdmi"; resets = <&softreset STIH407_HDMI_TX_PHY_SOFTRESET>; ddc = <&hdmiddc>; Patches currently in stable-queue which might be from patrice.chotard(a)st.com are queue-4.15/arm-dts-sti-add-gpio-polarity-for-hdmi-hpd-gpio-property.patch

7 years, 7 months

1
0
0 0

Patch "ARM: dts: nomadik: add interrupt-parent for clcd" has been added to the 4.15-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled ARM: dts: nomadik: add interrupt-parent for clcd to the 4.15-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: arm-dts-nomadik-add-interrupt-parent-for-clcd.patch and it can be found in the queue-4.15 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From e8bfa0422469cdfc86be3f525f621b1d44d2481b Mon Sep 17 00:00:00 2001 From: Arnd Bergmann <arnd(a)arndb.de> Date: Mon, 15 Jan 2018 17:37:08 +0100 Subject: ARM: dts: nomadik: add interrupt-parent for clcd From: Arnd Bergmann <arnd(a)arndb.de> commit e8bfa0422469cdfc86be3f525f621b1d44d2481b upstream. The clcd device is lacking an interrupt-parent property, which makes the interrupt unusable and shows up as a warning with the latest dtc version: arch/arm/boot/dts/ste-nomadik-s8815.dtb: Warning (interrupts_property): Missing interrupt-parent for /amba/clcd@10120000 arch/arm/boot/dts/ste-nomadik-nhk15.dtb: Warning (interrupts_property): Missing interrupt-parent for /amba/clcd@10120000 I looked up the old board files and found that this interrupt has the same irqchip as all the other on-chip device, it just needs one extra line. Fixes: 17470b7da11c ("ARM: dts: add the CLCD LCD display to the NHK15") Reviewed-by: Linus Walleij <linus.walleij(a)linaro.org> Cc: stable(a)vger.kernel.org Signed-off-by: Arnd Bergmann <arnd(a)arndb.de> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/arm/boot/dts/ste-nomadik-stn8815.dtsi | 1 + 1 file changed, 1 insertion(+) --- a/arch/arm/boot/dts/ste-nomadik-stn8815.dtsi +++ b/arch/arm/boot/dts/ste-nomadik-stn8815.dtsi @@ -750,6 +750,7 @@ reg = <0x10120000 0x1000>; interrupt-names = "combined"; interrupts = <14>; + interrupt-parent = <&vica>; clocks = <&clcdclk>, <&hclkclcd>; clock-names = "clcdclk", "apb_pclk"; status = "disabled"; Patches currently in stable-queue which might be from arnd(a)arndb.de are queue-4.15/arm-spear600-add-missing-interrupt-parent-of-rtc.patch queue-4.15/arm-dts-sti-add-gpio-polarity-for-hdmi-hpd-gpio-property.patch queue-4.15/kselftest-fix-oom-in-memory-compaction-test.patch queue-4.15/arm-spear13xx-fix-spics-gpio-controller-s-warning.patch queue-4.15/arm-lpc3250-fix-uda1380-gpio-numbers.patch queue-4.15/arm-spear13xx-fix-dmas-cells.patch queue-4.15/arm-dts-nomadik-add-interrupt-parent-for-clcd.patch

7 years, 7 months

1
0
0 0

Patch "arm: dts: mt7623: fix card detection issue on bananapi-r2" has been added to the 4.15-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled arm: dts: mt7623: fix card detection issue on bananapi-r2 to the 4.15-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: arm-dts-mt7623-fix-card-detection-issue-on-bananapi-r2.patch and it can be found in the queue-4.15 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From b96a696fb2a8dd1ee4e6cfee48dcac270fc53287 Mon Sep 17 00:00:00 2001 From: Sean Wang <sean.wang(a)mediatek.com> Date: Thu, 7 Dec 2017 14:43:24 +0800 Subject: arm: dts: mt7623: fix card detection issue on bananapi-r2 From: Sean Wang <sean.wang(a)mediatek.com> commit b96a696fb2a8dd1ee4e6cfee48dcac270fc53287 upstream. Fix that bananapi-r2 booting from SD-card would fail since incorrect polarity is applied to the previous setup with GPIO_ACTIVE_HIGH. Cc: stable(a)vger.kernel.org Fixes: 0eed8d097612 ("arm: dts: mt7623: Add SD-card and EMMC to bananapi-r2") Signed-off-by: Sean Wang <sean.wang(a)mediatek.com> Tested-by: Matthias Brugger <matthias.bgg(a)gmail.com> Signed-off-by: Matthias Brugger <matthias.bgg(a)gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts +++ b/arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts @@ -204,7 +204,7 @@ bus-width = <4>; max-frequency = <50000000>; cap-sd-highspeed; - cd-gpios = <&pio 261 0>; + cd-gpios = <&pio 261 GPIO_ACTIVE_LOW>; vmmc-supply = <&mt6323_vmch_reg>; vqmmc-supply = <&mt6323_vio18_reg>; }; Patches currently in stable-queue which might be from sean.wang(a)mediatek.com are queue-4.15/arm-dts-mt7623-fix-card-detection-issue-on-bananapi-r2.patch

7 years, 7 months

1
0
0 0

Patch "x86/xen: init %gs very early to avoid page faults with stack protector" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled x86/xen: init %gs very early to avoid page faults with stack protector to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: x86-xen-init-gs-very-early-to-avoid-page-faults-with-stack-protector.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 4f277295e54c5b7340e48efea3fc5cc21a2872b7 Mon Sep 17 00:00:00 2001 From: Juergen Gross <jgross(a)suse.com> Date: Thu, 1 Feb 2018 13:40:19 +0100 Subject: x86/xen: init %gs very early to avoid page faults with stack protector From: Juergen Gross <jgross(a)suse.com> commit 4f277295e54c5b7340e48efea3fc5cc21a2872b7 upstream. When running as Xen pv guest %gs is initialized some time after C code is started. Depending on stack protector usage this might be too late, resulting in page faults. So setup %gs and MSR_GS_BASE in assembly code already. Cc: stable(a)vger.kernel.org Signed-off-by: Juergen Gross <jgross(a)suse.com> Reviewed-by: Boris Ostrovsky <boris.ostrovsky(a)oracle.com> Tested-by: Chris Patterson <cjp256(a)gmail.com> Signed-off-by: Juergen Gross <jgross(a)suse.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/x86/xen/xen-head.S | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) --- a/arch/x86/xen/xen-head.S +++ b/arch/x86/xen/xen-head.S @@ -9,7 +9,9 @@ #include <asm/boot.h> #include <asm/asm.h> +#include <asm/msr.h> #include <asm/page_types.h> +#include <asm/percpu.h> #include <asm/unwind_hints.h> #include <xen/interface/elfnote.h> @@ -35,6 +37,20 @@ ENTRY(startup_xen) mov %_ASM_SI, xen_start_info mov $init_thread_union+THREAD_SIZE, %_ASM_SP +#ifdef CONFIG_X86_64 + /* Set up %gs. + * + * The base of %gs always points to the bottom of the irqstack + * union. If the stack protector canary is enabled, it is + * located at %gs:40. Note that, on SMP, the boot cpu uses + * init data section till per cpu areas are set up. + */ + movl $MSR_GS_BASE,%ecx + movq $INIT_PER_CPU_VAR(irq_stack_union),%rax + cdq + wrmsr +#endif + jmp xen_start_kernel END(startup_xen) __FINIT Patches currently in stable-queue which might be from jgross(a)suse.com are queue-4.14/x86-xen-init-gs-very-early-to-avoid-page-faults-with-stack-protector.patch

7 years, 7 months

1
0
0 0

Patch "x86/kexec: Make kexec (mostly) work in 5-level paging mode" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled x86/kexec: Make kexec (mostly) work in 5-level paging mode to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: x86-kexec-make-kexec-mostly-work-in-5-level-paging-mode.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 5bf30316991d5bcda046343ee77d823cf16fdd03 Mon Sep 17 00:00:00 2001 From: "Kirill A. Shutemov" <kirill.shutemov(a)linux.intel.com> Date: Mon, 29 Jan 2018 14:08:45 +0300 Subject: x86/kexec: Make kexec (mostly) work in 5-level paging mode From: Kirill A. Shutemov <kirill.shutemov(a)linux.intel.com> commit 5bf30316991d5bcda046343ee77d823cf16fdd03 upstream. Currently kexec() will crash when switching into a 5-level paging enabled kernel. I missed that we need to change relocate_kernel() to set CR4.LA57 flag if the kernel has 5-level paging enabled. I avoided using #ifdef CONFIG_X86_5LEVEL here and inferred if we need to enable 5-level paging from previous CR4 value. This way the code is ready for boot-time switching between paging modes. With this patch applied, in addition to kexec 4-to-4 which always worked, we can kexec 4-to-5 and 5-to-5 - while 5-to-4 will need more work. Reported-by: Baoquan He <bhe(a)redhat.com> Signed-off-by: Kirill A. Shutemov <kirill.shutemov(a)linux.intel.com> Tested-by: Baoquan He <bhe(a)redhat.com> Cc: <stable(a)vger.kernel.org> # v4.14+ Cc: Borislav Petkov <bp(a)suse.de> Cc: Linus Torvalds <torvalds(a)linux-foundation.org> Cc: Peter Zijlstra <peterz(a)infradead.org> Cc: Thomas Gleixner <tglx(a)linutronix.de> Cc: linux-mm(a)kvack.org Fixes: 77ef56e4f0fb ("x86: Enable 5-level paging support via CONFIG_X86_5LEVEL=y") Link: http://lkml.kernel.org/r/20180129110845.26633-1-kirill.shutemov@linux.intel… Signed-off-by: Ingo Molnar <mingo(a)kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/x86/kernel/relocate_kernel_64.S | 8 ++++++++ 1 file changed, 8 insertions(+) --- a/arch/x86/kernel/relocate_kernel_64.S +++ b/arch/x86/kernel/relocate_kernel_64.S @@ -68,6 +68,9 @@ relocate_kernel: movq %cr4, %rax movq %rax, CR4(%r11) + /* Save CR4. Required to enable the right paging mode later. */ + movq %rax, %r13 + /* zero out flags, and disable interrupts */ pushq $0 popfq @@ -126,8 +129,13 @@ identity_mapped: /* * Set cr4 to a known state: * - physical address extension enabled + * - 5-level paging, if it was enabled before */ movl $X86_CR4_PAE, %eax + testq $X86_CR4_LA57, %r13 + jz 1f + orl $X86_CR4_LA57, %eax +1: movq %rax, %cr4 jmp 1f Patches currently in stable-queue which might be from kirill.shutemov(a)linux.intel.com are queue-4.14/x86-kexec-make-kexec-mostly-work-in-5-level-paging-mode.patch

7 years, 7 months

1
0
0 0

Patch "x86/gpu: add CFL to early quirks" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled x86/gpu: add CFL to early quirks to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: x86-gpu-add-cfl-to-early-quirks.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 33aa69ed8aacd92dea12671e52eb3ca6ac2d7a49 Mon Sep 17 00:00:00 2001 From: Lucas De Marchi <lucas.demarchi(a)intel.com> Date: Wed, 13 Dec 2017 12:04:25 -0800 Subject: x86/gpu: add CFL to early quirks From: Lucas De Marchi <lucas.demarchi(a)intel.com> commit 33aa69ed8aacd92dea12671e52eb3ca6ac2d7a49 upstream. CFL was missing from intel_early_ids[]. The PCI ID needs to be there to allow the memory region to be stolen, otherwise we could have RAM being arbitrarily overwritten if for example we keep using the UEFI framebuffer, depending on how BIOS has set up the e820 map. Fixes: b056f8f3d6b9 ("drm/i915/cfl: Add Coffee Lake PCI IDs for S Skus.") Signed-off-by: Lucas De Marchi <lucas.demarchi(a)intel.com> Cc: Rodrigo Vivi <rodrigo.vivi(a)intel.com> Cc: Anusha Srivatsa <anusha.srivatsa(a)intel.com> Cc: Jani Nikula <jani.nikula(a)linux.intel.com> Cc: Joonas Lahtinen <joonas.lahtinen(a)linux.intel.com> Cc: David Airlie <airlied(a)linux.ie> Cc: intel-gfx(a)lists.freedesktop.org Cc: dri-devel(a)lists.freedesktop.org Cc: Ingo Molnar <mingo(a)kernel.org> Cc: H. Peter Anvin <hpa(a)zytor.com> Cc: Thomas Gleixner <tglx(a)linutronix.de> Cc: x86(a)kernel.org Cc: <stable(a)vger.kernel.org> # v4.13+ 0890540e21cf drm/i915: add GT number to intel_device_info Cc: <stable(a)vger.kernel.org> # v4.13+ 41693fd52373 drm/i915/kbl: Change a KBL pci id to GT2 from GT1.5 Cc: <stable(a)vger.kernel.org> # v4.13+ Reviewed-by: Rodrigo Vivi <rodrigo.vivi(a)intel.com> Acked-by: Jani Nikula <jani.nikula(a)intel.com> Acked-by: Ingo Molnar <mingo(a)kernel.org> Signed-off-by: Rodrigo Vivi <rodrigo.vivi(a)intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171213200425.2954-1-lucas.d… Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/x86/kernel/early-quirks.c | 1 + include/drm/i915_pciids.h | 6 ++++++ 2 files changed, 7 insertions(+) --- a/arch/x86/kernel/early-quirks.c +++ b/arch/x86/kernel/early-quirks.c @@ -527,6 +527,7 @@ static const struct pci_device_id intel_ INTEL_SKL_IDS(&gen9_early_ops), INTEL_BXT_IDS(&gen9_early_ops), INTEL_KBL_IDS(&gen9_early_ops), + INTEL_CFL_IDS(&gen9_early_ops), INTEL_GLK_IDS(&gen9_early_ops), INTEL_CNL_IDS(&gen9_early_ops), }; --- a/include/drm/i915_pciids.h +++ b/include/drm/i915_pciids.h @@ -354,6 +354,12 @@ INTEL_VGA_DEVICE(0x3EA8, info), /* ULT GT3 */ \ INTEL_VGA_DEVICE(0x3EA5, info) /* ULT GT3 */ +#define INTEL_CFL_IDS(info) \ + INTEL_CFL_S_GT1_IDS(info), \ + INTEL_CFL_S_GT2_IDS(info), \ + INTEL_CFL_H_GT2_IDS(info), \ + INTEL_CFL_U_GT3_IDS(info) + /* CNL U 2+2 */ #define INTEL_CNL_U_GT2_IDS(info) \ INTEL_VGA_DEVICE(0x5A52, info), \ Patches currently in stable-queue which might be from lucas.demarchi(a)intel.com are queue-4.14/x86-gpu-add-cfl-to-early-quirks.patch

7 years, 7 months

1
0
0 0

Patch "swiotlb: suppress warning when __GFP_NOWARN is set" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled swiotlb: suppress warning when __GFP_NOWARN is set to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: swiotlb-suppress-warning-when-__gfp_nowarn-is-set.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From d0bc0c2a31c95002d37c3cc511ffdcab851b3256 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Christian=20K=C3=B6nig?= <ckoenig.leichtzumerken(a)gmail.com> Date: Thu, 4 Jan 2018 14:24:19 +0100 Subject: swiotlb: suppress warning when __GFP_NOWARN is set MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Christian König <ckoenig.leichtzumerken(a)gmail.com> commit d0bc0c2a31c95002d37c3cc511ffdcab851b3256 upstream. TTM tries to allocate coherent memory in chunks of 2MB first to improve TLB efficiency and falls back to allocating 4K pages if that fails. Suppress the warning when the 2MB allocations fails since there is a valid fall back path. Signed-off-by: Christian König <christian.koenig(a)amd.com> Reported-by: Mike Galbraith <efault(a)gmx.de> Acked-by: Konrad Rzeszutek Wilk <konrad.wilk(a)oracle.com> Bug: https://bugs.freedesktop.org/show_bug.cgi?id=104082 Signed-off-by: Christoph Hellwig <hch(a)lst.de> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- lib/swiotlb.c | 15 +++++++++------ 1 file changed, 9 insertions(+), 6 deletions(-) --- a/lib/swiotlb.c +++ b/lib/swiotlb.c @@ -585,7 +585,7 @@ phys_addr_t swiotlb_tbl_map_single(struc not_found: spin_unlock_irqrestore(&io_tlb_lock, flags); - if (printk_ratelimit()) + if (!(attrs & DMA_ATTR_NO_WARN) && printk_ratelimit()) dev_warn(hwdev, "swiotlb buffer is full (sz: %zd bytes)\n", size); return SWIOTLB_MAP_ERROR; found: @@ -712,6 +712,7 @@ void * swiotlb_alloc_coherent(struct device *hwdev, size_t size, dma_addr_t *dma_handle, gfp_t flags) { + bool warn = !(flags & __GFP_NOWARN); dma_addr_t dev_addr; void *ret; int order = get_order(size); @@ -737,8 +738,8 @@ swiotlb_alloc_coherent(struct device *hw * GFP_DMA memory; fall back on map_single(), which * will grab memory from the lowest available address range. */ - phys_addr_t paddr = map_single(hwdev, 0, size, - DMA_FROM_DEVICE, 0); + phys_addr_t paddr = map_single(hwdev, 0, size, DMA_FROM_DEVICE, + warn ? 0 : DMA_ATTR_NO_WARN); if (paddr == SWIOTLB_MAP_ERROR) goto err_warn; @@ -768,9 +769,11 @@ swiotlb_alloc_coherent(struct device *hw return ret; err_warn: - pr_warn("swiotlb: coherent allocation failed for device %s size=%zu\n", - dev_name(hwdev), size); - dump_stack(); + if (warn && printk_ratelimit()) { + pr_warn("swiotlb: coherent allocation failed for device %s size=%zu\n", + dev_name(hwdev), size); + dump_stack(); + } return NULL; } Patches currently in stable-queue which might be from ckoenig.leichtzumerken(a)gmail.com are queue-4.14/dma-buf-fix-reservation_object_wait_timeout_rcu-once-more-v2.patch queue-4.14/swiotlb-suppress-warning-when-__gfp_nowarn-is-set.patch

7 years, 7 months

1
0
0 0

Patch "powerpc/xive: Use hw CPU ids when configuring the CPU queues" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled powerpc/xive: Use hw CPU ids when configuring the CPU queues to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: powerpc-xive-use-hw-cpu-ids-when-configuring-the-cpu-queues.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 8e036c8d30a2cd9d8fc7442fbf6824e0a3e986e7 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?C=C3=A9dric=20Le=20Goater?= <clg(a)kaod.org> Date: Tue, 13 Feb 2018 09:47:12 +0100 Subject: powerpc/xive: Use hw CPU ids when configuring the CPU queues MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Cédric Le Goater <clg(a)kaod.org> commit 8e036c8d30a2cd9d8fc7442fbf6824e0a3e986e7 upstream. The CPU event notification queues on sPAPR should be configured using a hardware CPU identifier. The problem did not show up on the Power Hypervisor because pHyp supports 8 threads per core which keeps CPU number contiguous. This is not the case on all sPAPR virtual machines, some use SMT=1. Also improve error logging by adding the CPU number. Fixes: eac1e731b59e ("powerpc/xive: guest exploitation of the XIVE interrupt controller") Cc: stable(a)vger.kernel.org # v4.14+ Signed-off-by: Cédric Le Goater <clg(a)kaod.org> Signed-off-by: Michael Ellerman <mpe(a)ellerman.id.au> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/powerpc/sysdev/xive/spapr.c | 16 ++++++++++------ 1 file changed, 10 insertions(+), 6 deletions(-) --- a/arch/powerpc/sysdev/xive/spapr.c +++ b/arch/powerpc/sysdev/xive/spapr.c @@ -356,7 +356,8 @@ static int xive_spapr_configure_queue(u3 rc = plpar_int_get_queue_info(0, target, prio, &esn_page, &esn_size); if (rc) { - pr_err("Error %lld getting queue info prio %d\n", rc, prio); + pr_err("Error %lld getting queue info CPU %d prio %d\n", rc, + target, prio); rc = -EIO; goto fail; } @@ -370,7 +371,8 @@ static int xive_spapr_configure_queue(u3 /* Configure and enable the queue in HW */ rc = plpar_int_set_queue_config(flags, target, prio, qpage_phys, order); if (rc) { - pr_err("Error %lld setting queue for prio %d\n", rc, prio); + pr_err("Error %lld setting queue for CPU %d prio %d\n", rc, + target, prio); rc = -EIO; } else { q->qpage = qpage; @@ -389,8 +391,8 @@ static int xive_spapr_setup_queue(unsign if (IS_ERR(qpage)) return PTR_ERR(qpage); - return xive_spapr_configure_queue(cpu, q, prio, qpage, - xive_queue_shift); + return xive_spapr_configure_queue(get_hard_smp_processor_id(cpu), + q, prio, qpage, xive_queue_shift); } static void xive_spapr_cleanup_queue(unsigned int cpu, struct xive_cpu *xc, @@ -399,10 +401,12 @@ static void xive_spapr_cleanup_queue(uns struct xive_q *q = &xc->queue[prio]; unsigned int alloc_order; long rc; + int hw_cpu = get_hard_smp_processor_id(cpu); - rc = plpar_int_set_queue_config(0, cpu, prio, 0, 0); + rc = plpar_int_set_queue_config(0, hw_cpu, prio, 0, 0); if (rc) - pr_err("Error %ld setting queue for prio %d\n", rc, prio); + pr_err("Error %ld setting queue for CPU %d prio %d\n", rc, + hw_cpu, prio); alloc_order = xive_alloc_order(xive_queue_shift); free_pages((unsigned long)q->qpage, alloc_order); Patches currently in stable-queue which might be from clg(a)kaod.org are queue-4.14/powerpc-xive-use-hw-cpu-ids-when-configuring-the-cpu-queues.patch

7 years, 7 months

1
0
0 0

Patch "s390: fix handling of -1 in set{, fs}[gu]id16 syscalls" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled s390: fix handling of -1 in set{,fs}[gu]id16 syscalls to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: s390-fix-handling-of-1-in-set-fs-id16-syscalls.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 6dd0d2d22aa363fec075cb2577ba273ac8462e94 Mon Sep 17 00:00:00 2001 From: Eugene Syromiatnikov <esyr(a)redhat.com> Date: Mon, 15 Jan 2018 20:38:17 +0100 Subject: s390: fix handling of -1 in set{,fs}[gu]id16 syscalls From: Eugene Syromiatnikov <esyr(a)redhat.com> commit 6dd0d2d22aa363fec075cb2577ba273ac8462e94 upstream. For some reason, the implementation of some 16-bit ID system calls (namely, setuid16/setgid16 and setfsuid16/setfsgid16) used type cast instead of low2highgid/low2highuid macros for converting [GU]IDs, which led to incorrect handling of value of -1 (which ought to be considered invalid). Discovered by strace test suite. Cc: stable(a)vger.kernel.org Signed-off-by: Eugene Syromiatnikov <esyr(a)redhat.com> Signed-off-by: Heiko Carstens <heiko.carstens(a)de.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky(a)de.ibm.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/s390/kernel/compat_linux.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) --- a/arch/s390/kernel/compat_linux.c +++ b/arch/s390/kernel/compat_linux.c @@ -110,7 +110,7 @@ COMPAT_SYSCALL_DEFINE2(s390_setregid16, COMPAT_SYSCALL_DEFINE1(s390_setgid16, u16, gid) { - return sys_setgid((gid_t)gid); + return sys_setgid(low2highgid(gid)); } COMPAT_SYSCALL_DEFINE2(s390_setreuid16, u16, ruid, u16, euid) @@ -120,7 +120,7 @@ COMPAT_SYSCALL_DEFINE2(s390_setreuid16, COMPAT_SYSCALL_DEFINE1(s390_setuid16, u16, uid) { - return sys_setuid((uid_t)uid); + return sys_setuid(low2highuid(uid)); } COMPAT_SYSCALL_DEFINE3(s390_setresuid16, u16, ruid, u16, euid, u16, suid) @@ -173,12 +173,12 @@ COMPAT_SYSCALL_DEFINE3(s390_getresgid16, COMPAT_SYSCALL_DEFINE1(s390_setfsuid16, u16, uid) { - return sys_setfsuid((uid_t)uid); + return sys_setfsuid(low2highuid(uid)); } COMPAT_SYSCALL_DEFINE1(s390_setfsgid16, u16, gid) { - return sys_setfsgid((gid_t)gid); + return sys_setfsgid(low2highgid(gid)); } static int groups16_to_user(u16 __user *grouplist, struct group_info *group_info) Patches currently in stable-queue which might be from esyr(a)redhat.com are queue-4.14/s390-fix-handling-of-1-in-set-fs-id16-syscalls.patch

7 years, 7 months

1
0
0 0

Patch "powerpc/numa: Invalidate numa_cpu_lookup_table on cpu remove" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled powerpc/numa: Invalidate numa_cpu_lookup_table on cpu remove to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: powerpc-numa-invalidate-numa_cpu_lookup_table-on-cpu-remove.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 1d9a090783bef19fe8cdec878620d22f05191316 Mon Sep 17 00:00:00 2001 From: Nathan Fontenot <nfont(a)linux.vnet.ibm.com> Date: Fri, 26 Jan 2018 13:41:59 -0600 Subject: powerpc/numa: Invalidate numa_cpu_lookup_table on cpu remove From: Nathan Fontenot <nfont(a)linux.vnet.ibm.com> commit 1d9a090783bef19fe8cdec878620d22f05191316 upstream. When DLPAR removing a CPU, the unmapping of the cpu from a node in unmap_cpu_from_node() should also invalidate the CPUs entry in the numa_cpu_lookup_table. There is not a guarantee that on a subsequent DLPAR add of the CPU the associativity will be the same and thus could be in a different node. Invalidating the entry in the numa_cpu_lookup_table causes the associativity to be read from the device tree at the time of the add. The current behavior of not invalidating the CPUs entry in the numa_cpu_lookup_table can result in scenarios where the the topology layout of CPUs in the partition does not match the device tree or the topology reported by the HMC. This bug looks like it was introduced in 2004 in the commit titled "ppc64: cpu hotplug notifier for numa", which is 6b15e4e87e32 in the linux-fullhist tree. Hence tag it for all stable releases. Cc: stable(a)vger.kernel.org Signed-off-by: Nathan Fontenot <nfont(a)linux.vnet.ibm.com> Reviewed-by: Tyrel Datwyler <tyreld(a)linux.vnet.ibm.com> Signed-off-by: Michael Ellerman <mpe(a)ellerman.id.au> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/powerpc/include/asm/topology.h | 5 +++++ arch/powerpc/mm/numa.c | 5 ----- arch/powerpc/platforms/pseries/hotplug-cpu.c | 2 ++ 3 files changed, 7 insertions(+), 5 deletions(-) --- a/arch/powerpc/include/asm/topology.h +++ b/arch/powerpc/include/asm/topology.h @@ -44,6 +44,11 @@ extern int sysfs_add_device_to_node(stru extern void sysfs_remove_device_from_node(struct device *dev, int nid); extern int numa_update_cpu_topology(bool cpus_locked); +static inline void update_numa_cpu_lookup_table(unsigned int cpu, int node) +{ + numa_cpu_lookup_table[cpu] = node; +} + static inline int early_cpu_to_node(int cpu) { int nid; --- a/arch/powerpc/mm/numa.c +++ b/arch/powerpc/mm/numa.c @@ -142,11 +142,6 @@ static void reset_numa_cpu_lookup_table( numa_cpu_lookup_table[cpu] = -1; } -static void update_numa_cpu_lookup_table(unsigned int cpu, int node) -{ - numa_cpu_lookup_table[cpu] = node; -} - static void map_cpu_to_node(int cpu, int node) { update_numa_cpu_lookup_table(cpu, node); --- a/arch/powerpc/platforms/pseries/hotplug-cpu.c +++ b/arch/powerpc/platforms/pseries/hotplug-cpu.c @@ -36,6 +36,7 @@ #include <asm/xics.h> #include <asm/xive.h> #include <asm/plpar_wrappers.h> +#include <asm/topology.h> #include "pseries.h" #include "offline_states.h" @@ -331,6 +332,7 @@ static void pseries_remove_processor(str BUG_ON(cpu_online(cpu)); set_cpu_present(cpu, false); set_hard_smp_processor_id(cpu, -1); + update_numa_cpu_lookup_table(cpu, -1); break; } if (cpu >= nr_cpu_ids) Patches currently in stable-queue which might be from nfont(a)linux.vnet.ibm.com are queue-4.14/powerpc-numa-invalidate-numa_cpu_lookup_table-on-cpu-remove.patch

7 years, 7 months

1
0
0 0

Patch "powerpc/radix: Remove trace_tlbie call from radix__flush_tlb_all" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled powerpc/radix: Remove trace_tlbie call from radix__flush_tlb_all to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: powerpc-radix-remove-trace_tlbie-call-from-radix__flush_tlb_all.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 8d81296cfcce89013a714feb8d25004a156f8181 Mon Sep 17 00:00:00 2001 From: Mahesh Salgaonkar <mahesh(a)linux.vnet.ibm.com> Date: Thu, 30 Nov 2017 14:35:54 +0530 Subject: powerpc/radix: Remove trace_tlbie call from radix__flush_tlb_all From: Mahesh Salgaonkar <mahesh(a)linux.vnet.ibm.com> commit 8d81296cfcce89013a714feb8d25004a156f8181 upstream. radix__flush_tlb_all() is called only in kexec path in real mode and any tracepoints at this stage will make kexec to fail if enabled. To verify enable tlbie trace before kexec. $ echo 1 > /sys/kernel/debug/tracing/events/powerpc/tlbie/enable == kexec into new kernel and kexec fails. Fix this by not calling trace_tlbie from radix__flush_tlb_all(). Fixes: 0428491cba92 ("powerpc/mm: Trace tlbie(l) instructions") Cc: stable(a)vger.kernel.org # v4.13+ Signed-off-by: Mahesh Salgaonkar <mahesh(a)linux.vnet.ibm.com> Acked-by: Balbir Singh <bsingharora(a)gmail.com> Signed-off-by: Michael Ellerman <mpe(a)ellerman.id.au> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/powerpc/mm/tlb-radix.c | 2 -- 1 file changed, 2 deletions(-) --- a/arch/powerpc/mm/tlb-radix.c +++ b/arch/powerpc/mm/tlb-radix.c @@ -453,14 +453,12 @@ void radix__flush_tlb_all(void) */ asm volatile(PPC_TLBIE_5(%0, %4, %3, %2, %1) : : "r"(rb), "i"(r), "i"(1), "i"(ric), "r"(rs) : "memory"); - trace_tlbie(0, 0, rb, rs, ric, prs, r); /* * now flush host entires by passing PRS = 0 and LPID == 0 */ asm volatile(PPC_TLBIE_5(%0, %4, %3, %2, %1) : : "r"(rb), "i"(r), "i"(prs), "i"(ric), "r"(0) : "memory"); asm volatile("eieio; tlbsync; ptesync": : :"memory"); - trace_tlbie(0, 0, rb, 0, ric, prs, r); } void radix__flush_tlb_pte_p9_dd1(unsigned long old_pte, struct mm_struct *mm, Patches currently in stable-queue which might be from mahesh(a)linux.vnet.ibm.com are queue-4.14/powerpc-radix-remove-trace_tlbie-call-from-radix__flush_tlb_all.patch

7 years, 7 months

1
0
0 0

Patch "powerpc/mm: Flush radix process translations when setting MMU type" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled powerpc/mm: Flush radix process translations when setting MMU type to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: powerpc-mm-flush-radix-process-translations-when-setting-mmu-type.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 62e984ddfd6b056d399e24113f5e6a7145e579d8 Mon Sep 17 00:00:00 2001 From: Alexey Kardashevskiy <aik(a)ozlabs.ru> Date: Thu, 1 Feb 2018 16:09:44 +1100 Subject: powerpc/mm: Flush radix process translations when setting MMU type From: Alexey Kardashevskiy <aik(a)ozlabs.ru> commit 62e984ddfd6b056d399e24113f5e6a7145e579d8 upstream. Radix guests do normally invalidate process-scoped translations when a new pid is allocated but migrated guests do not invalidate these so migrated guests crash sometime, especially easy to reproduce with migration happening within first 10 seconds after the guest boot start on the same machine. This adds the "Invalidate process-scoped translations" flush to fix radix guests migration. Fixes: 2ee13be34b13 ("KVM: PPC: Book3S HV: Update kvmppc_set_arch_compat() for ISA v3.00") Cc: stable(a)vger.kernel.org # v4.10+ Signed-off-by: Alexey Kardashevskiy <aik(a)ozlabs.ru> Tested-by: Laurent Vivier <lvivier(a)redhat.com> Tested-by: Daniel Henrique Barboza <danielhb(a)linux.vnet.ibm.com> Signed-off-by: Michael Ellerman <mpe(a)ellerman.id.au> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/powerpc/mm/pgtable_64.c | 2 ++ 1 file changed, 2 insertions(+) --- a/arch/powerpc/mm/pgtable_64.c +++ b/arch/powerpc/mm/pgtable_64.c @@ -483,6 +483,8 @@ void mmu_partition_table_set_entry(unsig if (old & PATB_HR) { asm volatile(PPC_TLBIE_5(%0,%1,2,0,1) : : "r" (TLBIEL_INVAL_SET_LPID), "r" (lpid)); + asm volatile(PPC_TLBIE_5(%0,%1,2,1,1) : : + "r" (TLBIEL_INVAL_SET_LPID), "r" (lpid)); trace_tlbie(lpid, 0, TLBIEL_INVAL_SET_LPID, lpid, 2, 0, 1); } else { asm volatile(PPC_TLBIE_5(%0,%1,2,0,0) : : Patches currently in stable-queue which might be from aik(a)ozlabs.ru are queue-4.14/powerpc-mm-flush-radix-process-translations-when-setting-mmu-type.patch

7 years, 7 months

1
0
0 0

Patch "PM / devfreq: Propagate error from devfreq_add_device()" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled PM / devfreq: Propagate error from devfreq_add_device() to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: pm-devfreq-propagate-error-from-devfreq_add_device.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From d1bf2d30728f310f72296b54f0651ecdb09cbb12 Mon Sep 17 00:00:00 2001 From: Bjorn Andersson <bjorn.andersson(a)linaro.org> Date: Sun, 5 Nov 2017 21:27:41 -0800 Subject: PM / devfreq: Propagate error from devfreq_add_device() From: Bjorn Andersson <bjorn.andersson(a)linaro.org> commit d1bf2d30728f310f72296b54f0651ecdb09cbb12 upstream. Propagate the error of devfreq_add_device() in devm_devfreq_add_device() rather than statically returning ENOMEM. This makes it slightly faster to pinpoint the cause of a returned error. Fixes: 8cd84092d35e ("PM / devfreq: Add resource-managed function for devfreq device") Cc: stable(a)vger.kernel.org Acked-by: Chanwoo Choi <cw00.choi(a)samsung.com> Signed-off-by: Bjorn Andersson <bjorn.andersson(a)linaro.org> Signed-off-by: MyungJoo Ham <myungjoo.ham(a)samsung.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/devfreq/devfreq.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/devfreq/devfreq.c +++ b/drivers/devfreq/devfreq.c @@ -676,7 +676,7 @@ struct devfreq *devm_devfreq_add_device( devfreq = devfreq_add_device(dev, profile, governor_name, data); if (IS_ERR(devfreq)) { devres_free(ptr); - return ERR_PTR(-ENOMEM); + return devfreq; } *ptr = devfreq; Patches currently in stable-queue which might be from bjorn.andersson(a)linaro.org are queue-4.14/pm-devfreq-propagate-error-from-devfreq_add_device.patch queue-4.14/arm64-dts-msm8916-correct-ipc-references-for-smsm.patch

7 years, 7 months

1
0
0 0

Patch "powerpc: Fix DABR match on hash based systems" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled powerpc: Fix DABR match on hash based systems to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: powerpc-fix-dabr-match-on-hash-based-systems.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From f23ab3efb1b30cc5c5ef5ae4ef294ed467f30675 Mon Sep 17 00:00:00 2001 From: Benjamin Herrenschmidt <benh(a)kernel.crashing.org> Date: Fri, 10 Nov 2017 12:15:00 +1100 Subject: powerpc: Fix DABR match on hash based systems From: Benjamin Herrenschmidt <benh(a)kernel.crashing.org> commit f23ab3efb1b30cc5c5ef5ae4ef294ed467f30675 upstream. Commit 398a719d34a1 ("powerpc/mm: Update bits used to skip hash_page") mistakenly dropped the DSISR_DABRMATCH bit from the mask of bit tested to skip trying to hash a page. As a result, the DABR matches would no longer be detected. This adds it back. We open code it in the 2 places where it matters rather than fold it into DSISR_BAD_FAULT_32S/64S because this isn't technically a bad fault and while we would never hit it with the current code, I prefer if page_fault_is_bad() didn't trigger on these. Fixes: 398a719d34a1 ("powerpc/mm: Update bits used to skip hash_page") Cc: stable(a)vger.kernel.org # v4.14 Tested-by: Pedro Miraglia Franco de Carvalho <pedromfc(a)br.ibm.com> Signed-off-by: Benjamin Herrenschmidt <benh(a)kernel.crashing.org> Signed-off-by: Naveen N. Rao <naveen.n.rao(a)linux.vnet.ibm.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/powerpc/kernel/exceptions-64s.S | 2 +- arch/powerpc/kernel/head_32.S | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) --- a/arch/powerpc/kernel/exceptions-64s.S +++ b/arch/powerpc/kernel/exceptions-64s.S @@ -1617,7 +1617,7 @@ USE_TEXT_SECTION() .balign IFETCH_ALIGN_BYTES do_hash_page: #ifdef CONFIG_PPC_STD_MMU_64 - lis r0,DSISR_BAD_FAULT_64S@h + lis r0,(DSISR_BAD_FAULT_64S|DSISR_DABRMATCH)@h ori r0,r0,DSISR_BAD_FAULT_64S@l and. r0,r4,r0 /* weird error? */ bne- handle_page_fault /* if not, try to insert a HPTE */ --- a/arch/powerpc/kernel/head_32.S +++ b/arch/powerpc/kernel/head_32.S @@ -388,7 +388,7 @@ DataAccess: EXCEPTION_PROLOG mfspr r10,SPRN_DSISR stw r10,_DSISR(r11) - andis. r0,r10,DSISR_BAD_FAULT_32S@h + andis. r0,r10,(DSISR_BAD_FAULT_32S|DSISR_DABRMATCH)@h bne 1f /* if not, try to put a PTE */ mfspr r4,SPRN_DAR /* into the hash table */ rlwinm r3,r10,32-15,21,21 /* DSISR_STORE -> _PAGE_RW */ Patches currently in stable-queue which might be from benh(a)kernel.crashing.org are queue-4.14/powerpc-fix-dabr-match-on-hash-based-systems.patch

7 years, 7 months

1
0
0 0

Patch "ocfs2: try a blocking lock before return AOP_TRUNCATED_PAGE" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled ocfs2: try a blocking lock before return AOP_TRUNCATED_PAGE to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: ocfs2-try-a-blocking-lock-before-return-aop_truncated_page.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From ff26cc10aec128c3f86b5611fd5f59c71d49c0e3 Mon Sep 17 00:00:00 2001 From: Gang He <ghe(a)suse.com> Date: Wed, 31 Jan 2018 16:14:48 -0800 Subject: ocfs2: try a blocking lock before return AOP_TRUNCATED_PAGE From: Gang He <ghe(a)suse.com> commit ff26cc10aec128c3f86b5611fd5f59c71d49c0e3 upstream. If we can't get inode lock immediately in the function ocfs2_inode_lock_with_page() when reading a page, we should not return directly here, since this will lead to a softlockup problem when the kernel is configured with CONFIG_PREEMPT is not set. The method is to get a blocking lock and immediately unlock before returning, this can avoid CPU resource waste due to lots of retries, and benefits fairness in getting lock among multiple nodes, increase efficiency in case modifying the same file frequently from multiple nodes. The softlockup crash (when set /proc/sys/kernel/softlockup_panic to 1) looks like: Kernel panic - not syncing: softlockup: hung tasks CPU: 0 PID: 885 Comm: multi_mmap Tainted: G L 4.12.14-6.1-default #1 Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 Call Trace: <IRQ> dump_stack+0x5c/0x82 panic+0xd5/0x21e watchdog_timer_fn+0x208/0x210 __hrtimer_run_queues+0xcc/0x200 hrtimer_interrupt+0xa6/0x1f0 smp_apic_timer_interrupt+0x34/0x50 apic_timer_interrupt+0x96/0xa0 </IRQ> RIP: 0010:unlock_page+0x17/0x30 RSP: 0000:ffffaf154080bc88 EFLAGS: 00000246 ORIG_RAX: ffffffffffffff10 RAX: dead000000000100 RBX: fffff21e009f5300 RCX: 0000000000000004 RDX: dead0000000000ff RSI: 0000000000000202 RDI: fffff21e009f5300 RBP: 0000000000000000 R08: 0000000000000000 R09: ffffaf154080bb00 R10: ffffaf154080bc30 R11: 0000000000000040 R12: ffff993749a39518 R13: 0000000000000000 R14: fffff21e009f5300 R15: fffff21e009f5300 ocfs2_inode_lock_with_page+0x25/0x30 [ocfs2] ocfs2_readpage+0x41/0x2d0 [ocfs2] filemap_fault+0x12b/0x5c0 ocfs2_fault+0x29/0xb0 [ocfs2] __do_fault+0x1a/0xa0 __handle_mm_fault+0xbe8/0x1090 handle_mm_fault+0xaa/0x1f0 __do_page_fault+0x235/0x4b0 trace_do_page_fault+0x3c/0x110 async_page_fault+0x28/0x30 RIP: 0033:0x7fa75ded638e RSP: 002b:00007ffd6657db18 EFLAGS: 00010287 RAX: 000055c7662fb700 RBX: 0000000000000001 RCX: 000055c7662fb700 RDX: 0000000000001770 RSI: 00007fa75e909000 RDI: 000055c7662fb700 RBP: 0000000000000003 R08: 000000000000000e R09: 0000000000000000 R10: 0000000000000483 R11: 00007fa75ded61b0 R12: 00007fa75e90a770 R13: 000000000000000e R14: 0000000000001770 R15: 0000000000000000 About performance improvement, we can see the testing time is reduced, and CPU utilization decreases, the detailed data is as follows. I ran multi_mmap test case in ocfs2-test package in a three nodes cluster. Before applying this patch: PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 2754 ocfs2te+ 20 0 170248 6980 4856 D 80.73 0.341 0:18.71 multi_mmap 1505 root rt 0 222236 123060 97224 S 2.658 6.015 0:01.44 corosync 5 root 20 0 0 0 0 S 1.329 0.000 0:00.19 kworker/u8:0 95 root 20 0 0 0 0 S 1.329 0.000 0:00.25 kworker/u8:1 2728 root 20 0 0 0 0 S 0.997 0.000 0:00.24 jbd2/sda1-33 2721 root 20 0 0 0 0 S 0.664 0.000 0:00.07 ocfs2dc-3C8CFD4 2750 ocfs2te+ 20 0 142976 4652 3532 S 0.664 0.227 0:00.28 mpirun ocfs2test@tb-node2:~>multiple_run.sh -i ens3 -k ~/linux-4.4.21-69.tar.gz -o ~/ocfs2mullog -C hacluster -s pcmk -n tb-node2,tb-node1,tb-node3 -d /dev/sda1 -b 4096 -c 32768 -t multi_mmap /mnt/shared Tests with "-b 4096 -C 32768" Thu Dec 28 14:44:52 CST 2017 multi_mmap..................................................Passed. Runtime 783 seconds. After apply this patch: PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 2508 ocfs2te+ 20 0 170248 6804 4680 R 54.00 0.333 0:55.37 multi_mmap 155 root 20 0 0 0 0 S 2.667 0.000 0:01.20 kworker/u8:3 95 root 20 0 0 0 0 S 2.000 0.000 0:01.58 kworker/u8:1 2504 ocfs2te+ 20 0 142976 4604 3480 R 1.667 0.225 0:01.65 mpirun 5 root 20 0 0 0 0 S 1.000 0.000 0:01.36 kworker/u8:0 2482 root 20 0 0 0 0 S 1.000 0.000 0:00.86 jbd2/sda1-33 299 root 0 -20 0 0 0 S 0.333 0.000 0:00.13 kworker/2:1H 335 root 0 -20 0 0 0 S 0.333 0.000 0:00.17 kworker/1:1H 535 root 20 0 12140 7268 1456 S 0.333 0.355 0:00.34 haveged 1282 root rt 0 222284 123108 97224 S 0.333 6.017 0:01.33 corosync ocfs2test@tb-node2:~>multiple_run.sh -i ens3 -k ~/linux-4.4.21-69.tar.gz -o ~/ocfs2mullog -C hacluster -s pcmk -n tb-node2,tb-node1,tb-node3 -d /dev/sda1 -b 4096 -c 32768 -t multi_mmap /mnt/shared Tests with "-b 4096 -C 32768" Thu Dec 28 15:04:12 CST 2017 multi_mmap..................................................Passed. Runtime 487 seconds. Link: http://lkml.kernel.org/r/1514447305-30814-1-git-send-email-ghe@suse.com Fixes: 1cce4df04f37 ("ocfs2: do not lock/unlock() inode DLM lock") Signed-off-by: Gang He <ghe(a)suse.com> Reviewed-by: Eric Ren <zren(a)suse.com> Acked-by: alex chen <alex.chen(a)huawei.com> Acked-by: piaojun <piaojun(a)huawei.com> Cc: Mark Fasheh <mfasheh(a)versity.com> Cc: Joel Becker <jlbec(a)evilplan.org> Cc: Junxiao Bi <junxiao.bi(a)oracle.com> Cc: Joseph Qi <jiangqi903(a)gmail.com> Cc: Changwei Ge <ge.changwei(a)h3c.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- fs/ocfs2/dlmglue.c | 9 +++++++++ 1 file changed, 9 insertions(+) --- a/fs/ocfs2/dlmglue.c +++ b/fs/ocfs2/dlmglue.c @@ -2486,6 +2486,15 @@ int ocfs2_inode_lock_with_page(struct in ret = ocfs2_inode_lock_full(inode, ret_bh, ex, OCFS2_LOCK_NONBLOCK); if (ret == -EAGAIN) { unlock_page(page); + /* + * If we can't get inode lock immediately, we should not return + * directly here, since this will lead to a softlockup problem. + * The method is to get a blocking lock and immediately unlock + * before returning, this can avoid CPU resource waste due to + * lots of retries, and benefits fairness in getting lock. + */ + if (ocfs2_inode_lock(inode, ret_bh, ex) == 0) + ocfs2_inode_unlock(inode, ex); ret = AOP_TRUNCATED_PAGE; } Patches currently in stable-queue which might be from ghe(a)suse.com are queue-4.14/ocfs2-try-a-blocking-lock-before-return-aop_truncated_page.patch

7 years, 7 months

1
0
0 0

Patch "mwifiex: resolve reset vs. remove()/shutdown() deadlocks" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled mwifiex: resolve reset vs. remove()/shutdown() deadlocks to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: mwifiex-resolve-reset-vs.-remove-shutdown-deadlocks.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From a64e7a79dd6030479caad603c8d78e6c9c14904f Mon Sep 17 00:00:00 2001 From: Brian Norris <briannorris(a)chromium.org> Date: Fri, 12 Jan 2018 13:08:37 -0800 Subject: mwifiex: resolve reset vs. remove()/shutdown() deadlocks From: Brian Norris <briannorris(a)chromium.org> commit a64e7a79dd6030479caad603c8d78e6c9c14904f upstream. Commit b014e96d1abb ("PCI: Protect pci_error_handlers->reset_notify() usage with device_lock()") resolves races between driver reset and removal, but it introduces some new deadlock problems. If we see a timeout while we've already started suspending, removing, or shutting down the driver, we might see: (a) a worker thread, running mwifiex_pcie_work() -> mwifiex_pcie_card_reset_work() -> pci_reset_function() (b) a removal thread, running mwifiex_pcie_remove() -> mwifiex_free_adapter() -> mwifiex_unregister() -> mwifiex_cleanup_pcie() -> cancel_work_sync(&card->work) Unfortunately, mwifiex_pcie_remove() already holds the device lock that pci_reset_function() is now requesting, and so we see a deadlock. It's necessary to cancel and synchronize our outstanding work before tearing down the driver, so we can't have this work wait indefinitely for the lock. It's reasonable to only "try" to reset here, since this will mostly happen for cases where it's already difficult to reset the firmware anyway (e.g., while we're suspending or powering off the system). And if reset *really* needs to happen, we can always try again later. Fixes: b014e96d1abb ("PCI: Protect pci_error_handlers->reset_notify() usage with device_lock()") Cc: <stable(a)vger.kernel.org> Cc: Xinming Hu <huxm(a)marvell.com> Signed-off-by: Brian Norris <briannorris(a)chromium.org> Signed-off-by: Kalle Valo <kvalo(a)codeaurora.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/wireless/marvell/mwifiex/pcie.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) --- a/drivers/net/wireless/marvell/mwifiex/pcie.c +++ b/drivers/net/wireless/marvell/mwifiex/pcie.c @@ -2781,7 +2781,10 @@ static void mwifiex_pcie_card_reset_work { struct pcie_service_card *card = adapter->card; - pci_reset_function(card->dev); + /* We can't afford to wait here; remove() might be waiting on us. If we + * can't grab the device lock, maybe we'll get another chance later. + */ + pci_try_reset_function(card->dev); } static void mwifiex_pcie_work(struct work_struct *work) Patches currently in stable-queue which might be from briannorris(a)chromium.org are queue-4.14/mwifiex-resolve-reset-vs.-remove-shutdown-deadlocks.patch

7 years, 7 months

1
0
0 0

Patch "cpufreq: powernv: Dont assume distinct pstate values for nominal and pmin" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled cpufreq: powernv: Dont assume distinct pstate values for nominal and pmin to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: cpufreq-powernv-dont-assume-distinct-pstate-values-for-nominal-and-pmin.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 3fa4680b860bf48b437d6a2c039789c4abe202ae Mon Sep 17 00:00:00 2001 From: Shilpasri G Bhat <shilpa.bhat(a)linux.vnet.ibm.com> Date: Fri, 12 Jan 2018 12:43:53 +0530 Subject: cpufreq: powernv: Dont assume distinct pstate values for nominal and pmin From: Shilpasri G Bhat <shilpa.bhat(a)linux.vnet.ibm.com> commit 3fa4680b860bf48b437d6a2c039789c4abe202ae upstream. Some OpenPOWER boxes can have same pstate values for nominal and pmin pstates. In these boxes the current code will not initialize 'powernv_pstate_info.min' variable and result in erroneous CPU frequency reporting. This patch fixes this problem. Fixes: 09ca4c9b5958 (cpufreq: powernv: Replacing pstate_id with frequency table index) Reported-by: Alvin Wang <wangat(a)tw.ibm.com> Signed-off-by: Shilpasri G Bhat <shilpa.bhat(a)linux.vnet.ibm.com> Acked-by: Viresh Kumar <viresh.kumar(a)linaro.org> Cc: 4.8+ <stable(a)vger.kernel.org> # 4.8+ Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki(a)intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/cpufreq/powernv-cpufreq.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) --- a/drivers/cpufreq/powernv-cpufreq.c +++ b/drivers/cpufreq/powernv-cpufreq.c @@ -287,9 +287,9 @@ next: if (id == pstate_max) powernv_pstate_info.max = i; - else if (id == pstate_nominal) + if (id == pstate_nominal) powernv_pstate_info.nominal = i; - else if (id == pstate_min) + if (id == pstate_min) powernv_pstate_info.min = i; if (powernv_pstate_info.wof_enabled && id == pstate_turbo) { Patches currently in stable-queue which might be from shilpa.bhat(a)linux.vnet.ibm.com are queue-4.14/cpufreq-powernv-dont-assume-distinct-pstate-values-for-nominal-and-pmin.patch

7 years, 7 months

1
0
0 0

Patch "dma-buf: fix reservation_object_wait_timeout_rcu once more v2" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled dma-buf: fix reservation_object_wait_timeout_rcu once more v2 to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: dma-buf-fix-reservation_object_wait_timeout_rcu-once-more-v2.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 5bffee867df7494ecd32c1e6ec4e8fc934c521b7 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Christian=20K=C3=B6nig?= <ckoenig.leichtzumerken(a)gmail.com> Date: Mon, 22 Jan 2018 21:00:03 +0100 Subject: dma-buf: fix reservation_object_wait_timeout_rcu once more v2 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Christian König <ckoenig.leichtzumerken(a)gmail.com> commit 5bffee867df7494ecd32c1e6ec4e8fc934c521b7 upstream. We need to set shared_count even if we already have a fence to wait for. v2: init i to -1 as well Signed-off-by: Christian König <christian.koenig(a)amd.com> Cc: stable(a)vger.kernel.org Tested-by: Lyude Paul <lyude(a)redhat.com> Reviewed-by: Lyude Paul <lyude(a)redhat.com> Reviewed-by: Chris Wilson <chris(a)chris-wilson.co.uk> Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180122200003.6665-1-christi… Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/dma-buf/reservation.c | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) --- a/drivers/dma-buf/reservation.c +++ b/drivers/dma-buf/reservation.c @@ -455,13 +455,15 @@ long reservation_object_wait_timeout_rcu unsigned long timeout) { struct dma_fence *fence; - unsigned seq, shared_count, i = 0; + unsigned seq, shared_count; long ret = timeout ? timeout : 1; + int i; retry: shared_count = 0; seq = read_seqcount_begin(&obj->seq); rcu_read_lock(); + i = -1; fence = rcu_dereference(obj->fence_excl); if (fence && !test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, &fence->flags)) { @@ -477,14 +479,14 @@ retry: fence = NULL; } - if (!fence && wait_all) { + if (wait_all) { struct reservation_object_list *fobj = rcu_dereference(obj->fence); if (fobj) shared_count = fobj->shared_count; - for (i = 0; i < shared_count; ++i) { + for (i = 0; !fence && i < shared_count; ++i) { struct dma_fence *lfence = rcu_dereference(fobj->shared[i]); if (test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, Patches currently in stable-queue which might be from ckoenig.leichtzumerken(a)gmail.com are queue-4.14/dma-buf-fix-reservation_object_wait_timeout_rcu-once-more-v2.patch queue-4.14/swiotlb-suppress-warning-when-__gfp_nowarn-is-set.patch

7 years, 7 months

1
0
0 0

Patch "arm64: dts: msm8916: Correct ipc references for smsm" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled arm64: dts: msm8916: Correct ipc references for smsm to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: arm64-dts-msm8916-correct-ipc-references-for-smsm.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 566bd8902e7fa20bd412ed753e09e89c1c96939c Mon Sep 17 00:00:00 2001 From: Bjorn Andersson <bjorn.andersson(a)linaro.org> Date: Thu, 30 Nov 2017 21:27:32 -0800 Subject: arm64: dts: msm8916: Correct ipc references for smsm From: Bjorn Andersson <bjorn.andersson(a)linaro.org> commit 566bd8902e7fa20bd412ed753e09e89c1c96939c upstream. SMSM is not symmetrical, the incoming bits from WCNSS are available at index 6, but the outgoing host id for WCNSS is 3. Further more, upstream references the base of APCS (in contrast to downstream), so the register offset of 8 must be included. Fixes: 1fb47e0a9ba4 ("arm64: dts: qcom: msm8916: Add smsm and smp2p nodes") Cc: stable(a)vger.kernel.org Reported-by: Ramon Fried <rfried(a)codeaurora.org> Signed-off-by: Bjorn Andersson <bjorn.andersson(a)linaro.org> Signed-off-by: Andy Gross <andy.gross(a)linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/arm64/boot/dts/qcom/msm8916.dtsi | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) --- a/arch/arm64/boot/dts/qcom/msm8916.dtsi +++ b/arch/arm64/boot/dts/qcom/msm8916.dtsi @@ -1430,8 +1430,8 @@ #address-cells = <1>; #size-cells = <0>; - qcom,ipc-1 = <&apcs 0 13>; - qcom,ipc-6 = <&apcs 0 19>; + qcom,ipc-1 = <&apcs 8 13>; + qcom,ipc-3 = <&apcs 8 19>; apps_smsm: apps@0 { reg = <0>; Patches currently in stable-queue which might be from bjorn.andersson(a)linaro.org are queue-4.14/pm-devfreq-propagate-error-from-devfreq_add_device.patch queue-4.14/arm64-dts-msm8916-correct-ipc-references-for-smsm.patch

7 years, 7 months

1
0
0 0

Patch "arm: spear600: Add missing interrupt-parent of rtc" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled arm: spear600: Add missing interrupt-parent of rtc to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: arm-spear600-add-missing-interrupt-parent-of-rtc.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 6ffb5b4f248fe53e0361b8cbc2a523b432566442 Mon Sep 17 00:00:00 2001 From: Viresh Kumar <viresh.kumar(a)linaro.org> Date: Thu, 11 Jan 2018 11:28:51 +0530 Subject: arm: spear600: Add missing interrupt-parent of rtc From: Viresh Kumar <viresh.kumar(a)linaro.org> commit 6ffb5b4f248fe53e0361b8cbc2a523b432566442 upstream. The interrupt-parent of rtc was missing, add it. Fixes: 8113ba917dfa ("ARM: SPEAr: DT: Update device nodes") Cc: stable(a)vger.kernel.org # v3.8+ Reported-by: Arnd Bergmann <arnd(a)arndb.de> Signed-off-by: Viresh Kumar <viresh.kumar(a)linaro.org> Signed-off-by: Olof Johansson <olof(a)lixom.net> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/arm/boot/dts/spear600.dtsi | 1 + 1 file changed, 1 insertion(+) --- a/arch/arm/boot/dts/spear600.dtsi +++ b/arch/arm/boot/dts/spear600.dtsi @@ -194,6 +194,7 @@ rtc: rtc@fc900000 { compatible = "st,spear600-rtc"; reg = <0xfc900000 0x1000>; + interrupt-parent = <&vic0>; interrupts = <10>; status = "disabled"; }; Patches currently in stable-queue which might be from viresh.kumar(a)linaro.org are queue-4.14/arm-spear600-add-missing-interrupt-parent-of-rtc.patch queue-4.14/arm-spear13xx-fix-spics-gpio-controller-s-warning.patch queue-4.14/cpufreq-powernv-dont-assume-distinct-pstate-values-for-nominal-and-pmin.patch queue-4.14/arm-spear13xx-fix-dmas-cells.patch

7 years, 7 months

1
0
0 0

Patch "arm: spear13xx: Fix spics gpio controller's warning" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled arm: spear13xx: Fix spics gpio controller's warning to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: arm-spear13xx-fix-spics-gpio-controller-s-warning.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From f8975cb1b8a36d0839b6365235778dd9df1d04ca Mon Sep 17 00:00:00 2001 From: Viresh Kumar <viresh.kumar(a)linaro.org> Date: Thu, 11 Jan 2018 11:28:53 +0530 Subject: arm: spear13xx: Fix spics gpio controller's warning From: Viresh Kumar <viresh.kumar(a)linaro.org> commit f8975cb1b8a36d0839b6365235778dd9df1d04ca upstream. This fixes the following warning by also sending the flags argument for gpio controllers: Property 'cs-gpios', cell 6 is not a phandle reference in /ahb/apb/spi@e0100000 Fixes: 8113ba917dfa ("ARM: SPEAr: DT: Update device nodes") Cc: stable(a)vger.kernel.org # v3.8+ Reported-by: Arnd Bergmann <arnd(a)arndb.de> Signed-off-by: Viresh Kumar <viresh.kumar(a)linaro.org> Signed-off-by: Olof Johansson <olof(a)lixom.net> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/arm/boot/dts/spear1310-evb.dts | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/arch/arm/boot/dts/spear1310-evb.dts +++ b/arch/arm/boot/dts/spear1310-evb.dts @@ -349,7 +349,7 @@ spi0: spi@e0100000 { status = "okay"; num-cs = <3>; - cs-gpios = <&gpio1 7 0>, <&spics 0>, <&spics 1>; + cs-gpios = <&gpio1 7 0>, <&spics 0 0>, <&spics 1 0>; stmpe610@0 { compatible = "st,stmpe610"; Patches currently in stable-queue which might be from viresh.kumar(a)linaro.org are queue-4.14/arm-spear600-add-missing-interrupt-parent-of-rtc.patch queue-4.14/arm-spear13xx-fix-spics-gpio-controller-s-warning.patch queue-4.14/cpufreq-powernv-dont-assume-distinct-pstate-values-for-nominal-and-pmin.patch queue-4.14/arm-spear13xx-fix-dmas-cells.patch

7 years, 7 months

1
0
0 0

Patch "ARM: lpc3250: fix uda1380 gpio numbers" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled ARM: lpc3250: fix uda1380 gpio numbers to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: arm-lpc3250-fix-uda1380-gpio-numbers.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From ca32e0c4bf9ca4b87089c5a5ce945e5f2ec890da Mon Sep 17 00:00:00 2001 From: Arnd Bergmann <arnd(a)arndb.de> Date: Wed, 10 Jan 2018 17:22:00 +0100 Subject: ARM: lpc3250: fix uda1380 gpio numbers From: Arnd Bergmann <arnd(a)arndb.de> commit ca32e0c4bf9ca4b87089c5a5ce945e5f2ec890da upstream. dtc warns about obviously incorrect GPIO numbers for the audio codec on both lpc32xx boards: arch/arm/boot/dts/lpc3250-phy3250.dtb: Warning (gpios_property): reset-gpio property size (12) too small for cell size 3 in /ahb/apb/i2c@400A0000/uda1380@18 arch/arm/boot/dts/lpc3250-phy3250.dtb: Warning (gpios_property): power-gpio property size (12) too small for cell size 3 in /ahb/apb/i2c@400A0000/uda1380@18 arch/arm/boot/dts/lpc3250-ea3250.dtb: Warning (gpios_property): reset-gpio property size (12) too small for cell size 3 in /ahb/apb/i2c@400A0000/uda1380@18 arch/arm/boot/dts/lpc3250-ea3250.dtb: Warning (gpios_property): power-gpio property size (12) too small for cell size 3 in /ahb/apb/i2c@400A0000/uda1380@18 It looks like the nodes are written for a different binding that combines the GPIO number into a single number rather than a bank/number pair. I found the right numbers on stackexchange.com, so this patch fixes the warning and has a reasonable chance of getting things to actually work. Cc: stable(a)vger.kernel.org Link: https://unix.stackexchange.com/questions/59497/alsa-asoc-how-to-correctly-l… Signed-off-by: Arnd Bergmann <arnd(a)arndb.de> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/arm/boot/dts/lpc3250-ea3250.dts | 4 ++-- arch/arm/boot/dts/lpc3250-phy3250.dts | 4 ++-- 2 files changed, 4 insertions(+), 4 deletions(-) --- a/arch/arm/boot/dts/lpc3250-ea3250.dts +++ b/arch/arm/boot/dts/lpc3250-ea3250.dts @@ -156,8 +156,8 @@ uda1380: uda1380@18 { compatible = "nxp,uda1380"; reg = <0x18>; - power-gpio = <&gpio 0x59 0>; - reset-gpio = <&gpio 0x51 0>; + power-gpio = <&gpio 3 10 0>; + reset-gpio = <&gpio 3 2 0>; dac-clk = "wspll"; }; --- a/arch/arm/boot/dts/lpc3250-phy3250.dts +++ b/arch/arm/boot/dts/lpc3250-phy3250.dts @@ -81,8 +81,8 @@ uda1380: uda1380@18 { compatible = "nxp,uda1380"; reg = <0x18>; - power-gpio = <&gpio 0x59 0>; - reset-gpio = <&gpio 0x51 0>; + power-gpio = <&gpio 3 10 0>; + reset-gpio = <&gpio 3 2 0>; dac-clk = "wspll"; }; Patches currently in stable-queue which might be from arnd(a)arndb.de are queue-4.14/arm-spear600-add-missing-interrupt-parent-of-rtc.patch queue-4.14/arm-dts-sti-add-gpio-polarity-for-hdmi-hpd-gpio-property.patch queue-4.14/kselftest-fix-oom-in-memory-compaction-test.patch queue-4.14/arm-spear13xx-fix-spics-gpio-controller-s-warning.patch queue-4.14/tracing-prevent-profile_all_branches-when-fortify_source-y.patch queue-4.14/arm-lpc3250-fix-uda1380-gpio-numbers.patch queue-4.14/arm-spear13xx-fix-dmas-cells.patch queue-4.14/arm-dts-nomadik-add-interrupt-parent-for-clcd.patch

7 years, 7 months

1
0
0 0

Patch "arm: spear13xx: Fix dmas cells" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled arm: spear13xx: Fix dmas cells to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: arm-spear13xx-fix-dmas-cells.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From cdd10409914184c7eee5ae3e11beb890c9c16c61 Mon Sep 17 00:00:00 2001 From: Viresh Kumar <viresh.kumar(a)linaro.org> Date: Thu, 11 Jan 2018 11:28:52 +0530 Subject: arm: spear13xx: Fix dmas cells From: Viresh Kumar <viresh.kumar(a)linaro.org> commit cdd10409914184c7eee5ae3e11beb890c9c16c61 upstream. The "dmas" cells for the designware DMA controller need to have only 3 properties apart from the phandle: request line, src master and destination master. But the commit 6e8887f60f60 updated it incorrectly while moving from platform code to DT. Fix it. Cc: stable(a)vger.kernel.org # v3.10+ Fixes: 6e8887f60f60 ("ARM: SPEAr13xx: Pass generic DW DMAC platform data from DT") Reported-by: Arnd Bergmann <arnd(a)arndb.de> Signed-off-by: Viresh Kumar <viresh.kumar(a)linaro.org> Signed-off-by: Olof Johansson <olof(a)lixom.net> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- Documentation/devicetree/bindings/dma/snps-dma.txt | 2 +- arch/arm/boot/dts/spear1340.dtsi | 4 ++-- arch/arm/boot/dts/spear13xx.dtsi | 6 +++--- 3 files changed, 6 insertions(+), 6 deletions(-) --- a/Documentation/devicetree/bindings/dma/snps-dma.txt +++ b/Documentation/devicetree/bindings/dma/snps-dma.txt @@ -64,6 +64,6 @@ Example: reg = <0xe0000000 0x1000>; interrupts = <0 35 0x4>; dmas = <&dmahost 12 0 1>, - <&dmahost 13 0 1 0>; + <&dmahost 13 1 0>; dma-names = "rx", "rx"; }; --- a/arch/arm/boot/dts/spear1340.dtsi +++ b/arch/arm/boot/dts/spear1340.dtsi @@ -142,8 +142,8 @@ reg = <0xb4100000 0x1000>; interrupts = <0 105 0x4>; status = "disabled"; - dmas = <&dwdma0 0x600 0 0 1>, /* 0xC << 11 */ - <&dwdma0 0x680 0 1 0>; /* 0xD << 7 */ + dmas = <&dwdma0 12 0 1>, + <&dwdma0 13 1 0>; dma-names = "tx", "rx"; }; --- a/arch/arm/boot/dts/spear13xx.dtsi +++ b/arch/arm/boot/dts/spear13xx.dtsi @@ -100,7 +100,7 @@ reg = <0xb2800000 0x1000>; interrupts = <0 29 0x4>; status = "disabled"; - dmas = <&dwdma0 0 0 0 0>; + dmas = <&dwdma0 0 0 0>; dma-names = "data"; }; @@ -290,8 +290,8 @@ #size-cells = <0>; interrupts = <0 31 0x4>; status = "disabled"; - dmas = <&dwdma0 0x2000 0 0 0>, /* 0x4 << 11 */ - <&dwdma0 0x0280 0 0 0>; /* 0x5 << 7 */ + dmas = <&dwdma0 4 0 0>, + <&dwdma0 5 0 0>; dma-names = "tx", "rx"; }; Patches currently in stable-queue which might be from viresh.kumar(a)linaro.org are queue-4.14/arm-spear600-add-missing-interrupt-parent-of-rtc.patch queue-4.14/arm-spear13xx-fix-spics-gpio-controller-s-warning.patch queue-4.14/cpufreq-powernv-dont-assume-distinct-pstate-values-for-nominal-and-pmin.patch queue-4.14/arm-spear13xx-fix-dmas-cells.patch

7 years, 7 months

1
0
0 0

Patch "ARM: dts: STi: Add gpio polarity for "hdmi, hpd-gpio" property" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled ARM: dts: STi: Add gpio polarity for "hdmi,hpd-gpio" property to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: arm-dts-sti-add-gpio-polarity-for-hdmi-hpd-gpio-property.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 7ac1f59c09a61e6af6622df6809e003b0af07f3d Mon Sep 17 00:00:00 2001 From: Patrice Chotard <patrice.chotard(a)st.com> Date: Wed, 10 Jan 2018 09:21:02 +0100 Subject: ARM: dts: STi: Add gpio polarity for "hdmi,hpd-gpio" property From: Patrice Chotard <patrice.chotard(a)st.com> commit 7ac1f59c09a61e6af6622df6809e003b0af07f3d upstream. The GPIO polarity is missing in the hdmi,hpd-gpio property, this fixes the following DT warnings: arch/arm/boot/dts/stih410-b2120.dtb: Warning (gpios_property): hdmi,hpd-gpio property size (8) too small for cell size 2 in /soc/sti-display-subsystem/sti-hdmi@8d04000 arch/arm/boot/dts/stih407-b2120.dtb: Warning (gpios_property): hdmi,hpd-gpio property size (8) too small for cell size 2 in /soc/sti-display-subsystem/sti-hdmi@8d04000 arch/arm/boot/dts/stih410-b2260.dtb: Warning (gpios_property): hdmi,hpd-gpio property size (8) too small for cell size 2 in /soc/sti-display-subsystem/sti-hdmi@8d04000 [arnd: marked Cc:stable since this warning shows up with the latest dtc by default, and is more likely to actually cause problems than the other patches from this series] Cc: stable(a)vger.kernel.org Signed-off-by: Patrice Chotard <patrice.chotard(a)st.com> Signed-off-by: Arnd Bergmann <arnd(a)arndb.de> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/arm/boot/dts/stih407.dtsi | 3 ++- arch/arm/boot/dts/stih410.dtsi | 3 ++- 2 files changed, 4 insertions(+), 2 deletions(-) --- a/arch/arm/boot/dts/stih407.dtsi +++ b/arch/arm/boot/dts/stih407.dtsi @@ -8,6 +8,7 @@ */ #include "stih407-clock.dtsi" #include "stih407-family.dtsi" +#include <dt-bindings/gpio/gpio.h> / { soc { sti-display-subsystem { @@ -122,7 +123,7 @@ <&clk_s_d2_quadfs 0>, <&clk_s_d2_quadfs 1>; - hdmi,hpd-gpio = <&pio5 3>; + hdmi,hpd-gpio = <&pio5 3 GPIO_ACTIVE_LOW>; reset-names = "hdmi"; resets = <&softreset STIH407_HDMI_TX_PHY_SOFTRESET>; ddc = <&hdmiddc>; --- a/arch/arm/boot/dts/stih410.dtsi +++ b/arch/arm/boot/dts/stih410.dtsi @@ -9,6 +9,7 @@ #include "stih410-clock.dtsi" #include "stih407-family.dtsi" #include "stih410-pinctrl.dtsi" +#include <dt-bindings/gpio/gpio.h> / { aliases { bdisp0 = &bdisp0; @@ -213,7 +214,7 @@ <&clk_s_d2_quadfs 0>, <&clk_s_d2_quadfs 1>; - hdmi,hpd-gpio = <&pio5 3>; + hdmi,hpd-gpio = <&pio5 3 GPIO_ACTIVE_LOW>; reset-names = "hdmi"; resets = <&softreset STIH407_HDMI_TX_PHY_SOFTRESET>; ddc = <&hdmiddc>; Patches currently in stable-queue which might be from patrice.chotard(a)st.com are queue-4.14/arm-dts-sti-add-gpio-polarity-for-hdmi-hpd-gpio-property.patch

7 years, 7 months

1
0
0 0

Patch "ARM: dts: nomadik: add interrupt-parent for clcd" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled ARM: dts: nomadik: add interrupt-parent for clcd to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: arm-dts-nomadik-add-interrupt-parent-for-clcd.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From e8bfa0422469cdfc86be3f525f621b1d44d2481b Mon Sep 17 00:00:00 2001 From: Arnd Bergmann <arnd(a)arndb.de> Date: Mon, 15 Jan 2018 17:37:08 +0100 Subject: ARM: dts: nomadik: add interrupt-parent for clcd From: Arnd Bergmann <arnd(a)arndb.de> commit e8bfa0422469cdfc86be3f525f621b1d44d2481b upstream. The clcd device is lacking an interrupt-parent property, which makes the interrupt unusable and shows up as a warning with the latest dtc version: arch/arm/boot/dts/ste-nomadik-s8815.dtb: Warning (interrupts_property): Missing interrupt-parent for /amba/clcd@10120000 arch/arm/boot/dts/ste-nomadik-nhk15.dtb: Warning (interrupts_property): Missing interrupt-parent for /amba/clcd@10120000 I looked up the old board files and found that this interrupt has the same irqchip as all the other on-chip device, it just needs one extra line. Fixes: 17470b7da11c ("ARM: dts: add the CLCD LCD display to the NHK15") Reviewed-by: Linus Walleij <linus.walleij(a)linaro.org> Cc: stable(a)vger.kernel.org Signed-off-by: Arnd Bergmann <arnd(a)arndb.de> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/arm/boot/dts/ste-nomadik-stn8815.dtsi | 1 + 1 file changed, 1 insertion(+) --- a/arch/arm/boot/dts/ste-nomadik-stn8815.dtsi +++ b/arch/arm/boot/dts/ste-nomadik-stn8815.dtsi @@ -750,6 +750,7 @@ reg = <0x10120000 0x1000>; interrupt-names = "combined"; interrupts = <14>; + interrupt-parent = <&vica>; clocks = <&clcdclk>, <&hclkclcd>; clock-names = "clcdclk", "apb_pclk"; status = "disabled"; Patches currently in stable-queue which might be from arnd(a)arndb.de are queue-4.14/arm-spear600-add-missing-interrupt-parent-of-rtc.patch queue-4.14/arm-dts-sti-add-gpio-polarity-for-hdmi-hpd-gpio-property.patch queue-4.14/kselftest-fix-oom-in-memory-compaction-test.patch queue-4.14/arm-spear13xx-fix-spics-gpio-controller-s-warning.patch queue-4.14/tracing-prevent-profile_all_branches-when-fortify_source-y.patch queue-4.14/arm-lpc3250-fix-uda1380-gpio-numbers.patch queue-4.14/arm-spear13xx-fix-dmas-cells.patch queue-4.14/arm-dts-nomadik-add-interrupt-parent-for-clcd.patch

7 years, 7 months

1
0
0 0

Patch "arm: dts: mt7623: fix card detection issue on bananapi-r2" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled arm: dts: mt7623: fix card detection issue on bananapi-r2 to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: arm-dts-mt7623-fix-card-detection-issue-on-bananapi-r2.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From b96a696fb2a8dd1ee4e6cfee48dcac270fc53287 Mon Sep 17 00:00:00 2001 From: Sean Wang <sean.wang(a)mediatek.com> Date: Thu, 7 Dec 2017 14:43:24 +0800 Subject: arm: dts: mt7623: fix card detection issue on bananapi-r2 From: Sean Wang <sean.wang(a)mediatek.com> commit b96a696fb2a8dd1ee4e6cfee48dcac270fc53287 upstream. Fix that bananapi-r2 booting from SD-card would fail since incorrect polarity is applied to the previous setup with GPIO_ACTIVE_HIGH. Cc: stable(a)vger.kernel.org Fixes: 0eed8d097612 ("arm: dts: mt7623: Add SD-card and EMMC to bananapi-r2") Signed-off-by: Sean Wang <sean.wang(a)mediatek.com> Tested-by: Matthias Brugger <matthias.bgg(a)gmail.com> Signed-off-by: Matthias Brugger <matthias.bgg(a)gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts +++ b/arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts @@ -204,7 +204,7 @@ bus-width = <4>; max-frequency = <50000000>; cap-sd-highspeed; - cd-gpios = <&pio 261 0>; + cd-gpios = <&pio 261 GPIO_ACTIVE_LOW>; vmmc-supply = <&mt6323_vmch_reg>; vqmmc-supply = <&mt6323_vio18_reg>; }; Patches currently in stable-queue which might be from sean.wang(a)mediatek.com are queue-4.14/arm-dts-mt7623-fix-card-detection-issue-on-bananapi-r2.patch

7 years, 7 months

1
0
0 0

Patch "s390: fix handling of -1 in set{, fs}[gu]id16 syscalls" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled s390: fix handling of -1 in set{,fs}[gu]id16 syscalls to the 3.18-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: s390-fix-handling-of-1-in-set-fs-id16-syscalls.patch and it can be found in the queue-3.18 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 6dd0d2d22aa363fec075cb2577ba273ac8462e94 Mon Sep 17 00:00:00 2001 From: Eugene Syromiatnikov <esyr(a)redhat.com> Date: Mon, 15 Jan 2018 20:38:17 +0100 Subject: s390: fix handling of -1 in set{,fs}[gu]id16 syscalls From: Eugene Syromiatnikov <esyr(a)redhat.com> commit 6dd0d2d22aa363fec075cb2577ba273ac8462e94 upstream. For some reason, the implementation of some 16-bit ID system calls (namely, setuid16/setgid16 and setfsuid16/setfsgid16) used type cast instead of low2highgid/low2highuid macros for converting [GU]IDs, which led to incorrect handling of value of -1 (which ought to be considered invalid). Discovered by strace test suite. Cc: stable(a)vger.kernel.org Signed-off-by: Eugene Syromiatnikov <esyr(a)redhat.com> Signed-off-by: Heiko Carstens <heiko.carstens(a)de.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky(a)de.ibm.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/s390/kernel/compat_linux.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) --- a/arch/s390/kernel/compat_linux.c +++ b/arch/s390/kernel/compat_linux.c @@ -110,7 +110,7 @@ COMPAT_SYSCALL_DEFINE2(s390_setregid16, COMPAT_SYSCALL_DEFINE1(s390_setgid16, u16, gid) { - return sys_setgid((gid_t)gid); + return sys_setgid(low2highgid(gid)); } COMPAT_SYSCALL_DEFINE2(s390_setreuid16, u16, ruid, u16, euid) @@ -120,7 +120,7 @@ COMPAT_SYSCALL_DEFINE2(s390_setreuid16, COMPAT_SYSCALL_DEFINE1(s390_setuid16, u16, uid) { - return sys_setuid((uid_t)uid); + return sys_setuid(low2highuid(uid)); } COMPAT_SYSCALL_DEFINE3(s390_setresuid16, u16, ruid, u16, euid, u16, suid) @@ -173,12 +173,12 @@ COMPAT_SYSCALL_DEFINE3(s390_getresgid16, COMPAT_SYSCALL_DEFINE1(s390_setfsuid16, u16, uid) { - return sys_setfsuid((uid_t)uid); + return sys_setfsuid(low2highuid(uid)); } COMPAT_SYSCALL_DEFINE1(s390_setfsgid16, u16, gid) { - return sys_setfsgid((gid_t)gid); + return sys_setfsgid(low2highgid(gid)); } static int groups16_to_user(u16 __user *grouplist, struct group_info *group_info) Patches currently in stable-queue which might be from esyr(a)redhat.com are queue-3.18/s390-fix-handling-of-1-in-set-fs-id16-syscalls.patch

7 years, 7 months

1
0
0 0

Patch "PM / devfreq: Propagate error from devfreq_add_device()" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled PM / devfreq: Propagate error from devfreq_add_device() to the 3.18-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: pm-devfreq-propagate-error-from-devfreq_add_device.patch and it can be found in the queue-3.18 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From d1bf2d30728f310f72296b54f0651ecdb09cbb12 Mon Sep 17 00:00:00 2001 From: Bjorn Andersson <bjorn.andersson(a)linaro.org> Date: Sun, 5 Nov 2017 21:27:41 -0800 Subject: PM / devfreq: Propagate error from devfreq_add_device() From: Bjorn Andersson <bjorn.andersson(a)linaro.org> commit d1bf2d30728f310f72296b54f0651ecdb09cbb12 upstream. Propagate the error of devfreq_add_device() in devm_devfreq_add_device() rather than statically returning ENOMEM. This makes it slightly faster to pinpoint the cause of a returned error. Fixes: 8cd84092d35e ("PM / devfreq: Add resource-managed function for devfreq device") Cc: stable(a)vger.kernel.org Acked-by: Chanwoo Choi <cw00.choi(a)samsung.com> Signed-off-by: Bjorn Andersson <bjorn.andersson(a)linaro.org> Signed-off-by: MyungJoo Ham <myungjoo.ham(a)samsung.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/devfreq/devfreq.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/devfreq/devfreq.c +++ b/drivers/devfreq/devfreq.c @@ -585,7 +585,7 @@ struct devfreq *devm_devfreq_add_device( devfreq = devfreq_add_device(dev, profile, governor_name, data); if (IS_ERR(devfreq)) { devres_free(ptr); - return ERR_PTR(-ENOMEM); + return devfreq; } *ptr = devfreq; Patches currently in stable-queue which might be from bjorn.andersson(a)linaro.org are queue-3.18/pm-devfreq-propagate-error-from-devfreq_add_device.patch

7 years, 7 months

1
0
0 0

Patch "arm: spear600: Add missing interrupt-parent of rtc" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled arm: spear600: Add missing interrupt-parent of rtc to the 3.18-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: arm-spear600-add-missing-interrupt-parent-of-rtc.patch and it can be found in the queue-3.18 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 6ffb5b4f248fe53e0361b8cbc2a523b432566442 Mon Sep 17 00:00:00 2001 From: Viresh Kumar <viresh.kumar(a)linaro.org> Date: Thu, 11 Jan 2018 11:28:51 +0530 Subject: arm: spear600: Add missing interrupt-parent of rtc From: Viresh Kumar <viresh.kumar(a)linaro.org> commit 6ffb5b4f248fe53e0361b8cbc2a523b432566442 upstream. The interrupt-parent of rtc was missing, add it. Fixes: 8113ba917dfa ("ARM: SPEAr: DT: Update device nodes") Cc: stable(a)vger.kernel.org # v3.8+ Reported-by: Arnd Bergmann <arnd(a)arndb.de> Signed-off-by: Viresh Kumar <viresh.kumar(a)linaro.org> Signed-off-by: Olof Johansson <olof(a)lixom.net> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/arm/boot/dts/spear600.dtsi | 1 + 1 file changed, 1 insertion(+) --- a/arch/arm/boot/dts/spear600.dtsi +++ b/arch/arm/boot/dts/spear600.dtsi @@ -194,6 +194,7 @@ rtc@fc900000 { compatible = "st,spear600-rtc"; reg = <0xfc900000 0x1000>; + interrupt-parent = <&vic0>; interrupts = <10>; status = "disabled"; }; Patches currently in stable-queue which might be from viresh.kumar(a)linaro.org are queue-3.18/arm-spear600-add-missing-interrupt-parent-of-rtc.patch queue-3.18/arm-spear13xx-fix-spics-gpio-controller-s-warning.patch queue-3.18/arm-spear13xx-fix-dmas-cells.patch

7 years, 7 months

1
0
0 0

Patch "arm: spear13xx: Fix spics gpio controller's warning" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled arm: spear13xx: Fix spics gpio controller's warning to the 3.18-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: arm-spear13xx-fix-spics-gpio-controller-s-warning.patch and it can be found in the queue-3.18 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From f8975cb1b8a36d0839b6365235778dd9df1d04ca Mon Sep 17 00:00:00 2001 From: Viresh Kumar <viresh.kumar(a)linaro.org> Date: Thu, 11 Jan 2018 11:28:53 +0530 Subject: arm: spear13xx: Fix spics gpio controller's warning From: Viresh Kumar <viresh.kumar(a)linaro.org> commit f8975cb1b8a36d0839b6365235778dd9df1d04ca upstream. This fixes the following warning by also sending the flags argument for gpio controllers: Property 'cs-gpios', cell 6 is not a phandle reference in /ahb/apb/spi@e0100000 Fixes: 8113ba917dfa ("ARM: SPEAr: DT: Update device nodes") Cc: stable(a)vger.kernel.org # v3.8+ Reported-by: Arnd Bergmann <arnd(a)arndb.de> Signed-off-by: Viresh Kumar <viresh.kumar(a)linaro.org> Signed-off-by: Olof Johansson <olof(a)lixom.net> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/arm/boot/dts/spear1310-evb.dts | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/arch/arm/boot/dts/spear1310-evb.dts +++ b/arch/arm/boot/dts/spear1310-evb.dts @@ -349,7 +349,7 @@ spi0: spi@e0100000 { status = "okay"; num-cs = <3>; - cs-gpios = <&gpio1 7 0>, <&spics 0>, <&spics 1>; + cs-gpios = <&gpio1 7 0>, <&spics 0 0>, <&spics 1 0>; stmpe610@0 { compatible = "st,stmpe610"; Patches currently in stable-queue which might be from viresh.kumar(a)linaro.org are queue-3.18/arm-spear600-add-missing-interrupt-parent-of-rtc.patch queue-3.18/arm-spear13xx-fix-spics-gpio-controller-s-warning.patch queue-3.18/arm-spear13xx-fix-dmas-cells.patch

7 years, 7 months

1
0
0 0

Patch "arm: spear13xx: Fix dmas cells" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled arm: spear13xx: Fix dmas cells to the 3.18-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: arm-spear13xx-fix-dmas-cells.patch and it can be found in the queue-3.18 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From cdd10409914184c7eee5ae3e11beb890c9c16c61 Mon Sep 17 00:00:00 2001 From: Viresh Kumar <viresh.kumar(a)linaro.org> Date: Thu, 11 Jan 2018 11:28:52 +0530 Subject: arm: spear13xx: Fix dmas cells From: Viresh Kumar <viresh.kumar(a)linaro.org> commit cdd10409914184c7eee5ae3e11beb890c9c16c61 upstream. The "dmas" cells for the designware DMA controller need to have only 3 properties apart from the phandle: request line, src master and destination master. But the commit 6e8887f60f60 updated it incorrectly while moving from platform code to DT. Fix it. Cc: stable(a)vger.kernel.org # v3.10+ Fixes: 6e8887f60f60 ("ARM: SPEAr13xx: Pass generic DW DMAC platform data from DT") Reported-by: Arnd Bergmann <arnd(a)arndb.de> Signed-off-by: Viresh Kumar <viresh.kumar(a)linaro.org> Signed-off-by: Olof Johansson <olof(a)lixom.net> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- Documentation/devicetree/bindings/dma/snps-dma.txt | 2 +- arch/arm/boot/dts/spear1340.dtsi | 4 ++-- arch/arm/boot/dts/spear13xx.dtsi | 6 +++--- 3 files changed, 6 insertions(+), 6 deletions(-) --- a/Documentation/devicetree/bindings/dma/snps-dma.txt +++ b/Documentation/devicetree/bindings/dma/snps-dma.txt @@ -58,6 +58,6 @@ Example: interrupts = <0 35 0x4>; status = "disabled"; dmas = <&dmahost 12 0 1>, - <&dmahost 13 0 1 0>; + <&dmahost 13 1 0>; dma-names = "rx", "rx"; }; --- a/arch/arm/boot/dts/spear1340.dtsi +++ b/arch/arm/boot/dts/spear1340.dtsi @@ -141,8 +141,8 @@ reg = <0xb4100000 0x1000>; interrupts = <0 105 0x4>; status = "disabled"; - dmas = <&dwdma0 0x600 0 0 1>, /* 0xC << 11 */ - <&dwdma0 0x680 0 1 0>; /* 0xD << 7 */ + dmas = <&dwdma0 12 0 1>, + <&dwdma0 13 1 0>; dma-names = "tx", "rx"; }; --- a/arch/arm/boot/dts/spear13xx.dtsi +++ b/arch/arm/boot/dts/spear13xx.dtsi @@ -100,7 +100,7 @@ reg = <0xb2800000 0x1000>; interrupts = <0 29 0x4>; status = "disabled"; - dmas = <&dwdma0 0 0 0 0>; + dmas = <&dwdma0 0 0 0>; dma-names = "data"; }; @@ -288,8 +288,8 @@ #size-cells = <0>; interrupts = <0 31 0x4>; status = "disabled"; - dmas = <&dwdma0 0x2000 0 0 0>, /* 0x4 << 11 */ - <&dwdma0 0x0280 0 0 0>; /* 0x5 << 7 */ + dmas = <&dwdma0 4 0 0>, + <&dwdma0 5 0 0>; dma-names = "tx", "rx"; }; Patches currently in stable-queue which might be from viresh.kumar(a)linaro.org are queue-3.18/arm-spear600-add-missing-interrupt-parent-of-rtc.patch queue-3.18/arm-spear13xx-fix-spics-gpio-controller-s-warning.patch queue-3.18/arm-spear13xx-fix-dmas-cells.patch

7 years, 7 months

1
0
0 0

FAILED: patch "[PATCH] arm/arm64: smccc: Make function identifiers an unsigned" failed to apply to 4.15-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.15-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From ded4c39e93f3b72968fdb79baba27f3b83dad34c Mon Sep 17 00:00:00 2001 From: Marc Zyngier <marc.zyngier(a)arm.com> Date: Tue, 6 Feb 2018 17:56:18 +0000 Subject: [PATCH] arm/arm64: smccc: Make function identifiers an unsigned quantity Function identifiers are a 32bit, unsigned quantity. But we never tell so to the compiler, resulting in the following: 4ac: b26187e0 mov x0, #0xffffffff80000001 We thus rely on the firmware narrowing it for us, which is not always a reasonable expectation. Cc: stable(a)vger.kernel.org Reported-by: Ard Biesheuvel <ard.biesheuvel(a)linaro.org> Acked-by: Ard Biesheuvel <ard.biesheuvel(a)linaro.org> Reviewed-by: Robin Murphy <robin.murphy(a)arm.com> Tested-by: Ard Biesheuvel <ard.biesheuvel(a)linaro.org> Signed-off-by: Marc Zyngier <marc.zyngier(a)arm.com> Signed-off-by: Catalin Marinas <catalin.marinas(a)arm.com> diff --git a/include/linux/arm-smccc.h b/include/linux/arm-smccc.h index e1ef944ef1da..dd44d8458c04 100644 --- a/include/linux/arm-smccc.h +++ b/include/linux/arm-smccc.h @@ -14,14 +14,16 @@ #ifndef __LINUX_ARM_SMCCC_H #define __LINUX_ARM_SMCCC_H +#include <uapi/linux/const.h> + /* * This file provides common defines for ARM SMC Calling Convention as * specified in * http://infocenter.arm.com/help/topic/com.arm.doc.den0028a/index.html */ -#define ARM_SMCCC_STD_CALL 0 -#define ARM_SMCCC_FAST_CALL 1 +#define ARM_SMCCC_STD_CALL _AC(0,U) +#define ARM_SMCCC_FAST_CALL _AC(1,U) #define ARM_SMCCC_TYPE_SHIFT 31 #define ARM_SMCCC_SMC_32 0

7 years, 7 months

2
1
0 0

FAILED: patch "[PATCH] arm/arm64: smccc: Make function identifiers an unsigned" failed to apply to 4.14-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.14-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From ded4c39e93f3b72968fdb79baba27f3b83dad34c Mon Sep 17 00:00:00 2001 From: Marc Zyngier <marc.zyngier(a)arm.com> Date: Tue, 6 Feb 2018 17:56:18 +0000 Subject: [PATCH] arm/arm64: smccc: Make function identifiers an unsigned quantity Function identifiers are a 32bit, unsigned quantity. But we never tell so to the compiler, resulting in the following: 4ac: b26187e0 mov x0, #0xffffffff80000001 We thus rely on the firmware narrowing it for us, which is not always a reasonable expectation. Cc: stable(a)vger.kernel.org Reported-by: Ard Biesheuvel <ard.biesheuvel(a)linaro.org> Acked-by: Ard Biesheuvel <ard.biesheuvel(a)linaro.org> Reviewed-by: Robin Murphy <robin.murphy(a)arm.com> Tested-by: Ard Biesheuvel <ard.biesheuvel(a)linaro.org> Signed-off-by: Marc Zyngier <marc.zyngier(a)arm.com> Signed-off-by: Catalin Marinas <catalin.marinas(a)arm.com> diff --git a/include/linux/arm-smccc.h b/include/linux/arm-smccc.h index e1ef944ef1da..dd44d8458c04 100644 --- a/include/linux/arm-smccc.h +++ b/include/linux/arm-smccc.h @@ -14,14 +14,16 @@ #ifndef __LINUX_ARM_SMCCC_H #define __LINUX_ARM_SMCCC_H +#include <uapi/linux/const.h> + /* * This file provides common defines for ARM SMC Calling Convention as * specified in * http://infocenter.arm.com/help/topic/com.arm.doc.den0028a/index.html */ -#define ARM_SMCCC_STD_CALL 0 -#define ARM_SMCCC_FAST_CALL 1 +#define ARM_SMCCC_STD_CALL _AC(0,U) +#define ARM_SMCCC_FAST_CALL _AC(1,U) #define ARM_SMCCC_TYPE_SHIFT 31 #define ARM_SMCCC_SMC_32 0

7 years, 7 months

1
0
0 0

[PATCH v4.14 stable] powerpc: Fix DABR match on hash based

by Naveen N. Rao

From: Benjamin Herrenschmidt <benh(a)kernel.crashing.org> Commit 398a719d34a1 ("powerpc/mm: Update bits used to skip hash_page") mistakenly dropped the DSISR_DABRMATCH bit from the mask of bit tested to skip trying to hash a page. As a result, the DABR matches would no longer be detected. This adds it back. We open code it in the 2 places where it matters rather than fold it into DSISR_BAD_FAULT_32S/64S because this isn't technically a bad fault and while we would never hit it with the current code, I prefer if page_fault_is_bad() didn't trigger on these. Fixes: 398a719d34a1 ("powerpc/mm: Update bits used to skip hash_page") Cc: stable(a)vger.kernel.org # v4.14 Tested-by: Pedro Miraglia Franco de Carvalho <pedromfc(a)br.ibm.com> Signed-off-by: Benjamin Herrenschmidt <benh(a)kernel.crashing.org> --- Hi Greg, This is a backport of commit f23ab3efb1b30 ("powerpc: Fix DABR match on hash based systems") to v4.14. This wasn't applying on v4.14 due to commit 4e003747043d5 ("powerpc/64s: Replace CONFIG_PPC_STD_MMU_64 with CONFIG_PPC_BOOK3S_64"), which renamed CONFIG_PPC_STD_MMU_64. Kindly apply this for v4.14-stable. - Naveen arch/powerpc/kernel/exceptions-64s.S | 2 +- arch/powerpc/kernel/head_32.S | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/powerpc/kernel/exceptions-64s.S b/arch/powerpc/kernel/exceptions-64s.S index e9f72abc52b7..e91b40aa5417 100644 --- a/arch/powerpc/kernel/exceptions-64s.S +++ b/arch/powerpc/kernel/exceptions-64s.S @@ -1617,7 +1617,7 @@ USE_TEXT_SECTION() .balign IFETCH_ALIGN_BYTES do_hash_page: #ifdef CONFIG_PPC_STD_MMU_64 - lis r0,DSISR_BAD_FAULT_64S@h + lis r0,(DSISR_BAD_FAULT_64S|DSISR_DABRMATCH)@h ori r0,r0,DSISR_BAD_FAULT_64S@l and. r0,r4,r0 /* weird error? */ bne- handle_page_fault /* if not, try to insert a HPTE */ diff --git a/arch/powerpc/kernel/head_32.S b/arch/powerpc/kernel/head_32.S index 8c54166491e7..29b2fed93289 100644 --- a/arch/powerpc/kernel/head_32.S +++ b/arch/powerpc/kernel/head_32.S @@ -388,7 +388,7 @@ DataAccess: EXCEPTION_PROLOG mfspr r10,SPRN_DSISR stw r10,_DSISR(r11) - andis. r0,r10,DSISR_BAD_FAULT_32S@h + andis. r0,r10,(DSISR_BAD_FAULT_32S|DSISR_DABRMATCH)@h bne 1f /* if not, try to put a PTE */ mfspr r4,SPRN_DAR /* into the hash table */ rlwinm r3,r10,32-15,21,21 /* DSISR_STORE -> _PAGE_RW */ -- 2.16.1

7 years, 7 months

2
2
0 0

FAILED: patch "[PATCH] powerpc/numa: Invalidate numa_cpu_lookup_table on cpu remove" failed to apply to 4.4-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.4-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From 1d9a090783bef19fe8cdec878620d22f05191316 Mon Sep 17 00:00:00 2001 From: Nathan Fontenot <nfont(a)linux.vnet.ibm.com> Date: Fri, 26 Jan 2018 13:41:59 -0600 Subject: [PATCH] powerpc/numa: Invalidate numa_cpu_lookup_table on cpu remove When DLPAR removing a CPU, the unmapping of the cpu from a node in unmap_cpu_from_node() should also invalidate the CPUs entry in the numa_cpu_lookup_table. There is not a guarantee that on a subsequent DLPAR add of the CPU the associativity will be the same and thus could be in a different node. Invalidating the entry in the numa_cpu_lookup_table causes the associativity to be read from the device tree at the time of the add. The current behavior of not invalidating the CPUs entry in the numa_cpu_lookup_table can result in scenarios where the the topology layout of CPUs in the partition does not match the device tree or the topology reported by the HMC. This bug looks like it was introduced in 2004 in the commit titled "ppc64: cpu hotplug notifier for numa", which is 6b15e4e87e32 in the linux-fullhist tree. Hence tag it for all stable releases. Cc: stable(a)vger.kernel.org Signed-off-by: Nathan Fontenot <nfont(a)linux.vnet.ibm.com> Reviewed-by: Tyrel Datwyler <tyreld(a)linux.vnet.ibm.com> Signed-off-by: Michael Ellerman <mpe(a)ellerman.id.au> diff --git a/arch/powerpc/include/asm/topology.h b/arch/powerpc/include/asm/topology.h index 88187c285c70..1c02e6900f78 100644 --- a/arch/powerpc/include/asm/topology.h +++ b/arch/powerpc/include/asm/topology.h @@ -44,6 +44,11 @@ extern int sysfs_add_device_to_node(struct device *dev, int nid); extern void sysfs_remove_device_from_node(struct device *dev, int nid); extern int numa_update_cpu_topology(bool cpus_locked); +static inline void update_numa_cpu_lookup_table(unsigned int cpu, int node) +{ + numa_cpu_lookup_table[cpu] = node; +} + static inline int early_cpu_to_node(int cpu) { int nid; diff --git a/arch/powerpc/mm/numa.c b/arch/powerpc/mm/numa.c index 314d19ab9385..edd8d0bc9364 100644 --- a/arch/powerpc/mm/numa.c +++ b/arch/powerpc/mm/numa.c @@ -143,11 +143,6 @@ static void reset_numa_cpu_lookup_table(void) numa_cpu_lookup_table[cpu] = -1; } -static void update_numa_cpu_lookup_table(unsigned int cpu, int node) -{ - numa_cpu_lookup_table[cpu] = node; -} - static void map_cpu_to_node(int cpu, int node) { update_numa_cpu_lookup_table(cpu, node); diff --git a/arch/powerpc/platforms/pseries/hotplug-cpu.c b/arch/powerpc/platforms/pseries/hotplug-cpu.c index dceb51454d8d..f78fd2068d56 100644 --- a/arch/powerpc/platforms/pseries/hotplug-cpu.c +++ b/arch/powerpc/platforms/pseries/hotplug-cpu.c @@ -36,6 +36,7 @@ #include <asm/xics.h> #include <asm/xive.h> #include <asm/plpar_wrappers.h> +#include <asm/topology.h> #include "pseries.h" #include "offline_states.h" @@ -331,6 +332,7 @@ static void pseries_remove_processor(struct device_node *np) BUG_ON(cpu_online(cpu)); set_cpu_present(cpu, false); set_hard_smp_processor_id(cpu, -1); + update_numa_cpu_lookup_table(cpu, -1); break; } if (cpu >= nr_cpu_ids)

7 years, 7 months

1
0
0 0

FAILED: patch "[PATCH] powerpc/numa: Invalidate numa_cpu_lookup_table on cpu remove" failed to apply to 4.9-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.9-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From 1d9a090783bef19fe8cdec878620d22f05191316 Mon Sep 17 00:00:00 2001 From: Nathan Fontenot <nfont(a)linux.vnet.ibm.com> Date: Fri, 26 Jan 2018 13:41:59 -0600 Subject: [PATCH] powerpc/numa: Invalidate numa_cpu_lookup_table on cpu remove When DLPAR removing a CPU, the unmapping of the cpu from a node in unmap_cpu_from_node() should also invalidate the CPUs entry in the numa_cpu_lookup_table. There is not a guarantee that on a subsequent DLPAR add of the CPU the associativity will be the same and thus could be in a different node. Invalidating the entry in the numa_cpu_lookup_table causes the associativity to be read from the device tree at the time of the add. The current behavior of not invalidating the CPUs entry in the numa_cpu_lookup_table can result in scenarios where the the topology layout of CPUs in the partition does not match the device tree or the topology reported by the HMC. This bug looks like it was introduced in 2004 in the commit titled "ppc64: cpu hotplug notifier for numa", which is 6b15e4e87e32 in the linux-fullhist tree. Hence tag it for all stable releases. Cc: stable(a)vger.kernel.org Signed-off-by: Nathan Fontenot <nfont(a)linux.vnet.ibm.com> Reviewed-by: Tyrel Datwyler <tyreld(a)linux.vnet.ibm.com> Signed-off-by: Michael Ellerman <mpe(a)ellerman.id.au> diff --git a/arch/powerpc/include/asm/topology.h b/arch/powerpc/include/asm/topology.h index 88187c285c70..1c02e6900f78 100644 --- a/arch/powerpc/include/asm/topology.h +++ b/arch/powerpc/include/asm/topology.h @@ -44,6 +44,11 @@ extern int sysfs_add_device_to_node(struct device *dev, int nid); extern void sysfs_remove_device_from_node(struct device *dev, int nid); extern int numa_update_cpu_topology(bool cpus_locked); +static inline void update_numa_cpu_lookup_table(unsigned int cpu, int node) +{ + numa_cpu_lookup_table[cpu] = node; +} + static inline int early_cpu_to_node(int cpu) { int nid; diff --git a/arch/powerpc/mm/numa.c b/arch/powerpc/mm/numa.c index 314d19ab9385..edd8d0bc9364 100644 --- a/arch/powerpc/mm/numa.c +++ b/arch/powerpc/mm/numa.c @@ -143,11 +143,6 @@ static void reset_numa_cpu_lookup_table(void) numa_cpu_lookup_table[cpu] = -1; } -static void update_numa_cpu_lookup_table(unsigned int cpu, int node) -{ - numa_cpu_lookup_table[cpu] = node; -} - static void map_cpu_to_node(int cpu, int node) { update_numa_cpu_lookup_table(cpu, node); diff --git a/arch/powerpc/platforms/pseries/hotplug-cpu.c b/arch/powerpc/platforms/pseries/hotplug-cpu.c index dceb51454d8d..f78fd2068d56 100644 --- a/arch/powerpc/platforms/pseries/hotplug-cpu.c +++ b/arch/powerpc/platforms/pseries/hotplug-cpu.c @@ -36,6 +36,7 @@ #include <asm/xics.h> #include <asm/xive.h> #include <asm/plpar_wrappers.h> +#include <asm/topology.h> #include "pseries.h" #include "offline_states.h" @@ -331,6 +332,7 @@ static void pseries_remove_processor(struct device_node *np) BUG_ON(cpu_online(cpu)); set_cpu_present(cpu, false); set_hard_smp_processor_id(cpu, -1); + update_numa_cpu_lookup_table(cpu, -1); break; } if (cpu >= nr_cpu_ids)

7 years, 7 months

1
0
0 0

Re: Linux 3.16.54: suspend stops working.

by Takashi Iwai

On Mon, 19 Feb 2018 16:36:03 +0100, Andres Bertens wrote: > > Hi, > > Yes sir, supend works with the attached patch! > > As for using some sequencer audio stuff, I have enabled > CONFIG_SND_SEQUENCER and some others *SEQ* as modules in my kernel > config. Nothing else to my knowledge. Good to hear! Greg, could you revert the previous one and apply the new one instead? Below is with a more description explaining the difference. Or if you prefer an incremental patch instead of revert and re-apply, let me know. I'll cook it. thanks, Takashi -- 8< -- From: Takashi Iwai <tiwai(a)suse.de> Subject: [PATCH] ALSA: seq: Make ioctls race-free (revised) commit b3defb791b26ea0683a93a4f49c77ec45ec96f10 upstream. The ALSA sequencer ioctls have no protection against racy calls while the concurrent operations may lead to interfere with each other. As reported recently, for example, the concurrent calls of setting client pool with a combination of write calls may lead to either the unkillable dead-lock or UAF. As a slightly big hammer solution, this patch introduces the mutex to make each ioctl exclusive. Although this may reduce performance via parallel ioctl calls, usually it's not demanded for sequencer usages, hence it should be negligible. [ NOTE: this is the revised backport of the commit b3defb791b26. We had another backport (e.g. 623e5c8ae32b in 4.4.115), but it applies the new mutex also to the code paths via faked kernel-to-kernel ioctls, and it seems leading to a deadlock, as reported recently as a regression. This revised patch takes the mutex only in the code path invoked by user-space, just like the original fix patch does -- tiwai ] Reported-by: Luo Quan <a4651386(a)163.com> Reviewed-by: Kees Cook <keescook(a)chromium.org> Reviewed-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Cc: <stable(a)vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai(a)suse.de> --- sound/core/seq/seq_clientmgr.c | 7 ++++++- sound/core/seq/seq_clientmgr.h | 1 + 2 files changed, 7 insertions(+), 1 deletion(-) --- a/sound/core/seq/seq_clientmgr.c +++ b/sound/core/seq/seq_clientmgr.c @@ -236,6 +236,7 @@ static struct snd_seq_client *seq_create rwlock_init(&client->ports_lock); mutex_init(&client->ports_mutex); INIT_LIST_HEAD(&client->ports_list_head); + mutex_init(&client->ioctl_mutex); /* find free slot in the client table */ spin_lock_irqsave(&clients_lock, flags); @@ -2220,11 +2221,15 @@ static int snd_seq_do_ioctl(struct snd_s static long snd_seq_ioctl(struct file *file, unsigned int cmd, unsigned long arg) { struct snd_seq_client *client = file->private_data; + long ret; if (snd_BUG_ON(!client)) return -ENXIO; - return snd_seq_do_ioctl(client, cmd, (void __user *) arg); + mutex_lock(&client->ioctl_mutex); + ret = snd_seq_do_ioctl(client, cmd, (void __user *) arg); + mutex_unlock(&client->ioctl_mutex); + return ret; } #ifdef CONFIG_COMPAT --- a/sound/core/seq/seq_clientmgr.h +++ b/sound/core/seq/seq_clientmgr.h @@ -59,6 +59,7 @@ struct snd_seq_client { struct list_head ports_list_head; rwlock_t ports_lock; struct mutex ports_mutex; + struct mutex ioctl_mutex; int convert32; /* convert 32->64bit */ /* output pool */

7 years, 7 months

2
2
0 0

[PATCH] drm: Handle unexpected holes in color-eviction

by Chris Wilson

During eviction, the driver may free more than one hole in the drm_mm due to the side-effects in evicting the scanned nodes. However, drm_mm_scan_color_evict() expects that the scan result is the first available hole (in the mru freed hole_stack list): kernel BUG at drivers/gpu/drm/drm_mm.c:844! invalid opcode: 0000 [#1] PREEMPT SMP KASAN PTI Dumping ftrace buffer: (ftrace buffer empty) Modules linked in: i915 snd_hda_codec_analog snd_hda_codec_generic coretemp snd_hda_intel snd_hda_codec snd_hwdep snd_hda_core lpc_ich snd_pcm e1000e mei_me prime_numbers mei CPU: 1 PID: 1490 Comm: gem_userptr_bli Tainted: G U 4.16.0-rc1-g740f57c54ecf-kasan_6+ #1 Hardware name: Dell Inc. OptiPlex 755 /0PU052, BIOS A08 02/19/2008 RIP: 0010:drm_mm_scan_color_evict+0x2b8/0x3d0 RSP: 0018:ffff880057a573f8 EFLAGS: 00010287 RAX: ffff8800611f5980 RBX: ffff880057a575d0 RCX: dffffc0000000000 RDX: 00000000029d5000 RSI: 1ffff1000af4aec1 RDI: ffff8800611f5a10 RBP: ffff88005ab884d0 R08: ffff880057a57600 R09: 000000000afff000 R10: 1ffff1000b5710b5 R11: 0000000000001000 R12: 1ffff1000af4ae82 R13: ffff8800611f59b0 R14: ffff8800611f5980 R15: ffff880057a57608 FS: 00007f2de0c2e8c0(0000) GS:ffff88006ac40000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f2ddde1e000 CR3: 00000000609b2000 CR4: 00000000000006e0 Call Trace: ? drm_mm_scan_remove_block+0x330/0x330 ? drm_mm_scan_remove_block+0x151/0x330 i915_gem_evict_something+0x711/0xbd0 [i915] ? igt_evict_contexts+0x50/0x50 [i915] ? nop_clear_range+0x10/0x10 [i915] ? igt_evict_something+0x90/0x90 [i915] ? i915_gem_gtt_reserve+0x1a1/0x320 [i915] i915_gem_gtt_insert+0x237/0x400 [i915] __i915_vma_do_pin+0xc25/0x1a20 [i915] eb_lookup_vmas+0x1c63/0x3790 [i915] ? i915_gem_check_execbuffer+0x250/0x250 [i915] ? trace_hardirqs_on_caller+0x33f/0x590 ? _raw_spin_unlock_irqrestore+0x39/0x60 ? __pm_runtime_resume+0x7d/0xf0 i915_gem_do_execbuffer+0x86a/0x2ff0 [i915] ? __kmalloc+0x132/0x340 ? i915_gem_execbuffer2_ioctl+0x10f/0x760 [i915] ? drm_ioctl_kernel+0x12e/0x1c0 ? drm_ioctl+0x662/0x980 ? eb_relocate_slow+0xa90/0xa90 [i915] ? i915_gem_execbuffer2_ioctl+0x10f/0x760 [i915] ? __might_fault+0xea/0x1a0 i915_gem_execbuffer2_ioctl+0x3cc/0x760 [i915] ? i915_gem_execbuffer_ioctl+0xba0/0xba0 [i915] ? lock_acquire+0x3c0/0x3c0 ? i915_gem_execbuffer_ioctl+0xba0/0xba0 [i915] drm_ioctl_kernel+0x12e/0x1c0 drm_ioctl+0x662/0x980 ? i915_gem_execbuffer_ioctl+0xba0/0xba0 [i915] ? drm_getstats+0x20/0x20 ? debug_check_no_obj_freed+0x2a6/0x8c0 do_vfs_ioctl+0x170/0xe70 ? ioctl_preallocate+0x170/0x170 ? task_work_run+0xbe/0x160 ? lock_acquire+0x3c0/0x3c0 ? trace_hardirqs_on_caller+0x33f/0x590 ? _raw_spin_unlock_irq+0x2f/0x50 SyS_ioctl+0x36/0x70 ? do_vfs_ioctl+0xe70/0xe70 do_syscall_64+0x18c/0x5d0 entry_SYSCALL_64_after_hwframe+0x26/0x9b RIP: 0033:0x7f2ddf13b587 RSP: 002b:00007fff15c4f9d8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00007f2ddf13b587 RDX: 00007fff15c4fa20 RSI: 0000000040406469 RDI: 0000000000000003 RBP: 00007fff15c4fa20 R08: 0000000000000000 R09: 00007f2ddf3fe120 R10: 0000000000000073 R11: 0000000000000246 R12: 0000000040406469 R13: 0000000000000003 R14: 00007fff15c4fa20 R15: 00000000000000c7 Code: 00 00 00 4a c7 44 22 08 00 00 00 00 42 c7 44 22 10 00 00 00 00 48 81 c4 b8 00 00 00 5b 5d 41 5c 41 5d 41 5e 41 5f c3 0f 0b 0f 0b <0f> 0b 31 c0 eb c0 4c 89 ef e8 9a 09 41 ff e9 1e fe ff ff 4c 89 RIP: drm_mm_scan_color_evict+0x2b8/0x3d0 RSP: ffff880057a573f8 We can trivially relax this assumption, by searching the hole_stack for the scan result and warn instead if the driver called us without any result. Fixes: 3fa489dabea9 ("drm: Apply tight eviction scanning to color_adjust") Signed-off-by: Chris Wilson <chris(a)chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen(a)linux.intel.com> Cc: <stable(a)vger.kernel.org> # v4.11+ --- drivers/gpu/drm/drm_mm.c | 21 ++++++++++++++++++--- 1 file changed, 18 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/drm_mm.c b/drivers/gpu/drm/drm_mm.c index 186c4e90cc1c..89eef1bb4ddc 100644 --- a/drivers/gpu/drm/drm_mm.c +++ b/drivers/gpu/drm/drm_mm.c @@ -836,9 +836,24 @@ struct drm_mm_node *drm_mm_scan_color_evict(struct drm_mm_scan *scan) if (!mm->color_adjust) return NULL; - hole = list_first_entry(&mm->hole_stack, typeof(*hole), hole_stack); - hole_start = __drm_mm_hole_node_start(hole); - hole_end = hole_start + hole->hole_size; + /* + * The hole found during scanning should ideally be the first element + * in the hole_stack list, but due to side-effects in the driver it + * may not be. + */ + list_for_each_entry(hole, &mm->hole_stack, hole_stack) { + hole_start = __drm_mm_hole_node_start(hole); + hole_end = hole_start + hole->hole_size; + + if (hole_start <= scan->hit_start && + hole_end >= scan->hit_end) + break; + } + + /* We should only be called after we found the hole previously */ + DRM_MM_BUG_ON(&hole->hole_stack == &mm->hole_stack); + if (unlikely(&hole->hole_stack == &mm->hole_stack)) + return NULL; DRM_MM_BUG_ON(hole_start > scan->hit_start); DRM_MM_BUG_ON(hole_end < scan->hit_end); -- 2.16.1

7 years, 7 months

3
3
0 0

Re: Linux 3.16.54: suspend stops working.

by Takashi Iwai

On Mon, 19 Feb 2018 16:06:55 +0100, Andres Bertens wrote: > > Hi there! > > If of any interest to you, upgrading to linux 3.16.54 from 3.16.53, > suspend stops working. The same is for upgrading from linux 4.4.114 to > 4.4.115. > > Checking pm-utils log: > > /usr/lib/pm-utils/pm-functions: line 259: echo: write error: Resource > temporarily unavailable > > And line 259 is: > do_suspend() { echo -n "mem" >/sys/power/state; } > > > > Reverting patch: > commit 02cbce8576a31df8fca54aaec91ee081076bd79d > Author: Takashi Iwai <tiwai(a)suse.de> > Date: Tue Jan 9 23:11:03 2018 +0100 > > ALSA: seq: Make ioctls race-free > > commit b3defb791b26ea0683a93a4f49c77ec45ec96f10 upstream. > > makes it work again! Just a blind shot: could you try the patch below instead? And, are you using some sequencer audio stuff? thanks, Takashi -- 8< -- From: Takashi Iwai <tiwai(a)suse.de> Subject: [PATCH] ALSA: seq: Make ioctls race-free (revised) The ALSA sequencer ioctls have no protection against racy calls while the concurrent operations may lead to interfere with each other. As reported recently, for example, the concurrent calls of setting client pool with a combination of write calls may lead to either the unkillable dead-lock or UAF. As a slightly big hammer solution, this patch introduces the mutex to make each ioctl exclusive. Although this may reduce performance via parallel ioctl calls, usually it's not demanded for sequencer usages, hence it should be negligible. Reported-by: Luo Quan <a4651386(a)163.com> Reviewed-by: Kees Cook <keescook(a)chromium.org> Reviewed-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Cc: <stable(a)vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai(a)suse.de> --- sound/core/seq/seq_clientmgr.c | 7 ++++++- sound/core/seq/seq_clientmgr.h | 1 + 2 files changed, 7 insertions(+), 1 deletion(-) --- a/sound/core/seq/seq_clientmgr.c +++ b/sound/core/seq/seq_clientmgr.c @@ -236,6 +236,7 @@ static struct snd_seq_client *seq_create rwlock_init(&client->ports_lock); mutex_init(&client->ports_mutex); INIT_LIST_HEAD(&client->ports_list_head); + mutex_init(&client->ioctl_mutex); /* find free slot in the client table */ spin_lock_irqsave(&clients_lock, flags); @@ -2220,11 +2221,15 @@ static int snd_seq_do_ioctl(struct snd_s static long snd_seq_ioctl(struct file *file, unsigned int cmd, unsigned long arg) { struct snd_seq_client *client = file->private_data; + long ret; if (snd_BUG_ON(!client)) return -ENXIO; - return snd_seq_do_ioctl(client, cmd, (void __user *) arg); + mutex_lock(&client->ioctl_mutex); + ret = snd_seq_do_ioctl(client, cmd, (void __user *) arg); + mutex_unlock(&client->ioctl_mutex); + return ret; } #ifdef CONFIG_COMPAT --- a/sound/core/seq/seq_clientmgr.h +++ b/sound/core/seq/seq_clientmgr.h @@ -59,6 +59,7 @@ struct snd_seq_client { struct list_head ports_list_head; rwlock_t ports_lock; struct mutex ports_mutex; + struct mutex ioctl_mutex; int convert32; /* convert 32->64bit */ /* output pool */

7 years, 7 months

1
0
0 0

Re: [PATCH 7/9] KVM/VMX: Emulate MSR_IA32_ARCH_CAPABILITIES

by Paolo Bonzini

On 19/02/2018 14:35, David Woodhouse wrote: > On Mon, 2018-02-19 at 14:10 +0100, Paolo Bonzini wrote: >>> Hardware seems like a reasonable place to get the default value (cf. >>> the VMX capability MSRs). >> >> There are some differences: >> >> - a zero value for ARCH_CAPABILITIES should be safe, while a zero value >> for VMX capabilities doesn't really make sense. On the contrary, a >> nonzero value for ARCH_CAPABILITIES is not safe across live migration. > > Any VMM which is going to support live migration surely needs to pay at > least a small amount of attention to the features it exposes? Exposing > the ARCH_CAPABILITIES CPUID bit without actually looking at the > contents of the associated MSR which that bit advertises would be... a > little strange, would it not? I think what we should do is simply backport Tom Lendacky's series to 4.14 and 4.9 ASAP, and add ARCH_CAPABILITIES support there. Then the question of the default becomes moot, more or less. Paolo > I don't see why we care so much about the *default* value, in that > context.

7 years, 7 months

1
0
0 0

[Linux-stable-mirror] [STABLE 4.9.y PATCH 0/9] Backport of KVM Speculation Control support

by David Woodhouse

I've put together a linux-4.9.y branch at http://git.infradead.org/retpoline-stable.git/shortlog/refs/heads/linux-4.9… Most of it is fairly straightforward, apart from the IBPB on context switch for which Tim has already posted a candidate. I wanted some more review on my backports of the KVM bits though, including some extra historical patches I pulled in. Ashok Raj (1): KVM/x86: Add IBPB support David Hildenbrand (1): KVM: nVMX: vmx_complete_nested_posted_interrupt() can't fail David Matlack (1): KVM: nVMX: mark vmcs12 pages dirty on L2 exit Jim Mattson (1): KVM: nVMX: Eliminate vmcs02 pool KarimAllah Ahmed (3): KVM/VMX: Emulate MSR_IA32_ARCH_CAPABILITIES KVM/VMX: Allow direct access to MSR_IA32_SPEC_CTRL KVM/SVM: Allow direct access to MSR_IA32_SPEC_CTRL Paolo Bonzini (2): KVM: VMX: introduce alloc_loaded_vmcs KVM: VMX: make MSR bitmaps per-VCPU arch/x86/kvm/cpuid.c | 21 +- arch/x86/kvm/cpuid.h | 31 +++ arch/x86/kvm/svm.c | 116 ++++++++ arch/x86/kvm/vmx.c | 730 +++++++++++++++++++++++++++------------------------ arch/x86/kvm/x86.c | 1 + 5 files changed, 554 insertions(+), 345 deletions(-) -- 2.7.4

7 years, 7 months

5
19
0 0

Applied "ASoC: rt5651: Fix regcache sync errors on resume" to the asoc tree

by Mark Brown

The patch ASoC: rt5651: Fix regcache sync errors on resume has been applied to the asoc tree at https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted. You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed. If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced. Please add any relevant lists and maintainers to the CCs when replying to this mail. Thanks, Mark >From 2d30e9494f1ea320aaaad0cff9ddd92c87eac355 Mon Sep 17 00:00:00 2001 From: Hans de Goede <hdegoede(a)redhat.com> Date: Sun, 18 Feb 2018 23:01:44 +0100 Subject: [PATCH] ASoC: rt5651: Fix regcache sync errors on resume The ALC5651 does not like multi-write accesses, avoid them. This fixes: rt5651 i2c-10EC5651:00: Unable to sync registers 0x27-0x28. -121 Errors on resume (and all registers after the registers in the error not being synced). Signed-off-by: Hans de Goede <hdegoede(a)redhat.com> Signed-off-by: Mark Brown <broonie(a)kernel.org> Cc: stable(a)vger.kernel.org --- sound/soc/codecs/rt5651.c | 1 + 1 file changed, 1 insertion(+) diff --git a/sound/soc/codecs/rt5651.c b/sound/soc/codecs/rt5651.c index 831b297978a4..45a73049cf64 100644 --- a/sound/soc/codecs/rt5651.c +++ b/sound/soc/codecs/rt5651.c @@ -1722,6 +1722,7 @@ static const struct regmap_config rt5651_regmap = { .num_reg_defaults = ARRAY_SIZE(rt5651_reg), .ranges = rt5651_ranges, .num_ranges = ARRAY_SIZE(rt5651_ranges), + .use_single_rw = true, }; #if defined(CONFIG_OF) -- 2.16.1

7 years, 7 months

1
0
0 0

[PATCH v3 3/3] x86/xen: add pvh specific rsdp address retrieval function

by Juergen Gross

Add pvh_get_root_pointer() for Xen PVH guests to communicate the address of the RSDP table given to the kernel via Xen start info. This makes the kernel boot again in PVH mode after on recent Xen the RSDP was moved to higher addresses. So up to that change it was pure luck that the legacy method to locate the RSDP was working when running as PVH mode. Cc: <stable(a)vger.kernel.org> # 4.11 Signed-off-by: Juergen Gross <jgross(a)suse.com> --- arch/x86/xen/enlighten_pvh.c | 14 +++++++++++--- 1 file changed, 11 insertions(+), 3 deletions(-) diff --git a/arch/x86/xen/enlighten_pvh.c b/arch/x86/xen/enlighten_pvh.c index 436c4f003e17..aa1c6a6831a9 100644 --- a/arch/x86/xen/enlighten_pvh.c +++ b/arch/x86/xen/enlighten_pvh.c @@ -6,6 +6,7 @@ #include <asm/io_apic.h> #include <asm/hypervisor.h> #include <asm/e820/api.h> +#include <asm/x86_init.h> #include <asm/xen/interface.h> #include <asm/xen/hypercall.h> @@ -16,15 +17,20 @@ /* * PVH variables. * - * xen_pvh and pvh_bootparams need to live in data segment since they - * are used after startup_{32|64}, which clear .bss, are invoked. + * xen_pvh pvh_bootparams and pvh_start_info need to live in data segment + * since they are used after startup_{32|64}, which clear .bss, are invoked. */ bool xen_pvh __attribute__((section(".data"))) = 0; struct boot_params pvh_bootparams __attribute__((section(".data"))); +struct hvm_start_info pvh_start_info __attribute__((section(".data"))); -struct hvm_start_info pvh_start_info; unsigned int pvh_start_info_sz = sizeof(pvh_start_info); +static u64 pvh_get_root_pointer(void) +{ + return pvh_start_info.rsdp_paddr; +} + static void __init init_pvh_bootparams(void) { struct xen_memory_map memmap; @@ -71,6 +77,8 @@ static void __init init_pvh_bootparams(void) */ pvh_bootparams.hdr.version = 0x212; pvh_bootparams.hdr.type_of_loader = (9 << 4) | 0; /* Xen loader */ + + x86_init.acpi.get_root_pointer = pvh_get_root_pointer; } /* -- 2.13.6

7 years, 7 months

1
0
0 0

[PATCH v3 2/3] x86/acpi: add a new x86_init_acpi structure to x86_init_ops

by Juergen Gross

Add a new struct x86_init_acpi to x86_init_ops. For now it contains only one init function to get the RSDP table address. Cc: <stable(a)vger.kernel.org> # 4.11 Signed-off-by: Juergen Gross <jgross(a)suse.com> --- arch/x86/include/asm/acpi.h | 7 +++++++ arch/x86/include/asm/x86_init.h | 9 +++++++++ arch/x86/kernel/x86_init.c | 5 +++++ 3 files changed, 21 insertions(+) diff --git a/arch/x86/include/asm/acpi.h b/arch/x86/include/asm/acpi.h index 11881726ed37..6609dd7289b5 100644 --- a/arch/x86/include/asm/acpi.h +++ b/arch/x86/include/asm/acpi.h @@ -31,6 +31,7 @@ #include <asm/mmu.h> #include <asm/mpspec.h> #include <asm/realmode.h> +#include <asm/x86_init.h> #ifdef CONFIG_ACPI_APEI # include <asm/pgtable_types.h> @@ -133,6 +134,12 @@ static inline bool acpi_has_cpu_in_madt(void) return !!acpi_lapic; } +#define ACPI_HAVE_ARCH_GET_ROOT_POINTER +static inline u64 acpi_arch_get_root_pointer(void) +{ + return x86_init.acpi.get_root_pointer(); +} + #else /* !CONFIG_ACPI */ #define acpi_lapic 0 diff --git a/arch/x86/include/asm/x86_init.h b/arch/x86/include/asm/x86_init.h index fc2f082ac635..2e2c34d2bb00 100644 --- a/arch/x86/include/asm/x86_init.h +++ b/arch/x86/include/asm/x86_init.h @@ -131,6 +131,14 @@ struct x86_hyper_init { }; /** + * struct x86_init_acpi - x86 ACPI init functions + * @get_root_pointer: get RSDP address + */ +struct x86_init_acpi { + u64 (*get_root_pointer)(void); +}; + +/** * struct x86_init_ops - functions for platform specific setup * */ @@ -144,6 +152,7 @@ struct x86_init_ops { struct x86_init_iommu iommu; struct x86_init_pci pci; struct x86_hyper_init hyper; + struct x86_init_acpi acpi; }; /** diff --git a/arch/x86/kernel/x86_init.c b/arch/x86/kernel/x86_init.c index 1151ccd72ce9..9e4e994a4836 100644 --- a/arch/x86/kernel/x86_init.c +++ b/arch/x86/kernel/x86_init.c @@ -30,6 +30,7 @@ int __init iommu_init_noop(void) { return 0; } void iommu_shutdown_noop(void) { } bool __init bool_x86_init_noop(void) { return false; } void x86_op_int_noop(int cpu) { } +u64 u64_x86_init_noop(void) { return 0; } /* * The platform setup functions are preset with the default functions @@ -91,6 +92,10 @@ struct x86_init_ops x86_init __initdata = { .x2apic_available = bool_x86_init_noop, .init_mem_mapping = x86_init_noop, }, + + .acpi = { + .get_root_pointer = u64_x86_init_noop, + }, }; struct x86_cpuinit_ops x86_cpuinit = { -- 2.13.6

7 years, 7 months

1
0
0 0

[PATCH v3 1/3] acpi: introduce acpi_arch_get_root_pointer() for getting rsdp address

by Juergen Gross

Add an architecture specific function to get the address of the RSDP table. Per default it will just return 0 indicating falling back to the current mechanism. Cc: <stable(a)vger.kernel.org> # 4.11 Signed-off-by: Juergen Gross <jgross(a)suse.com> --- drivers/acpi/osl.c | 5 ++++- include/linux/acpi.h | 7 +++++++ 2 files changed, 11 insertions(+), 1 deletion(-) diff --git a/drivers/acpi/osl.c b/drivers/acpi/osl.c index 3bb46cb24a99..ff812243bac3 100644 --- a/drivers/acpi/osl.c +++ b/drivers/acpi/osl.c @@ -189,12 +189,15 @@ early_param("acpi_rsdp", setup_acpi_rsdp); acpi_physical_address __init acpi_os_get_root_pointer(void) { - acpi_physical_address pa = 0; + acpi_physical_address pa; #ifdef CONFIG_KEXEC if (acpi_rsdp) return acpi_rsdp; #endif + pa = acpi_arch_get_root_pointer(); + if (pa) + return pa; if (efi_enabled(EFI_CONFIG_TABLES)) { if (efi.acpi20 != EFI_INVALID_TABLE_ADDR) diff --git a/include/linux/acpi.h b/include/linux/acpi.h index 968173ec2726..15bfb15c2fa5 100644 --- a/include/linux/acpi.h +++ b/include/linux/acpi.h @@ -623,6 +623,13 @@ bool acpi_gtdt_c3stop(int type); int acpi_arch_timer_mem_init(struct arch_timer_mem *timer_mem, int *timer_count); #endif +#ifndef ACPI_HAVE_ARCH_GET_ROOT_POINTER +static inline u64 acpi_arch_get_root_pointer(void) +{ + return 0; +} +#endif + #else /* !CONFIG_ACPI */ #define acpi_disabled 1 -- 2.13.6

7 years, 7 months

1
0
0 0

Re: [PATCH] x86/mm/kaiser: avoid 32-bit/PAE build warning

by Arnd Bergmann

On Wed, Dec 6, 2017 at 4:08 PM, Dave Hansen <dave.hansen(a)linux.intel.com> wrote: > On 12/06/2017 07:03 AM, Arnd Bergmann wrote: >> On Wed, Dec 6, 2017 at 3:15 PM, Arnd Bergmann <arnd(a)arndb.de> wrote: >> >>> This changes the type to u64 in the architecture-independent dummy, >>> and to pteval_t in the x86 specific portion that is used when KAISER >>> is enabled, ensuring that the flags can always fit. Unfortunately, >>> pteval_t is not provided by most other architectures, so we are >>> a little bit inconsistent here. >> >> I ran into a new regression with my patch applied, after doing more randconfig >> builds: >> >> In file included from /git/arm-soc/include/linux/kaiser.h:5, >> from /git/arm-soc/arch/x86/events/intel/ds.c:4: >> arch/x86/include/asm/kaiser.h:34:10: error: unknown type name >> 'pteval_t'; did you mean 'dev_t'? >> >> Maybe it's better to just to the last one-line change in include/linux/kaiser.h. > > Hi Arnd, > > Are you hitting this in -next? > > The newest version of this code has a single kpti_init() function that > shouldn't have any of these problems. Coming back to an old thread... I did some randconfig testing on 4.9.80, and now I see the same problem there, since that version uses the KAISER patches rather than PTI: /git/arm-soc/arch/x86/kernel/ldt.c: In function 'alloc_ldt_struct': /git/arm-soc/arch/x86/include/asm/pgtable_types.h:208:24: error: large integer implicitly truncated to unsigned type [-Werror=overflow] #define __PAGE_KERNEL (__PAGE_KERNEL_EXEC | _PAGE_NX) ^ /git/arm-soc/arch/x86/kernel/ldt.c:81:6: note: in expansion of macro '__PAGE_KERNEL' __PAGE_KERNEL); ^~~~~~~~~~~~~ I also saw another warning: /git/arm-soc/arch/x86/mm/kaiser.c: In function 'kaiser_init': /git/arm-soc/arch/x86/mm/kaiser.c:347:8: error: 'vsyscall_pgprot' undeclared (first use in this function); did you mean 'massage_pgprot'? I can send this as proper patches for inclusion in 4.9-stable, unless someone has a better idea or finds a problem Signed-off-by: Arnd Bergmann <arnd(a)arndb.de> diff --git a/include/linux/kaiser.h b/include/linux/kaiser.h index 58c55b1589d0..b56c19010480 100644 --- a/include/linux/kaiser.h +++ b/include/linux/kaiser.h @@ -32,7 +32,7 @@ static inline void kaiser_init(void) { } static inline int kaiser_add_mapping(unsigned long addr, - unsigned long size, unsigned long flags) + unsigned long size, u64 flags) { return 0; } --- a/arch/x86/include/asm/vsyscall.h +++ b/arch/x86/include/asm/vsyscall.h @@ -13,7 +13,6 @@ extern void map_vsyscall(void); */ extern bool emulate_vsyscall(struct pt_regs *regs, unsigned long address); extern bool vsyscall_enabled(void); -extern unsigned long vsyscall_pgprot; #else static inline void map_vsyscall(void) {} static inline bool emulate_vsyscall(struct pt_regs *regs, unsigned long address) @@ -23,4 +22,6 @@ static inline bool emulate_vsyscall(struct pt_regs *regs, unsigned long address) static inline bool vsyscall_enabled(void) { return false; } #endif +extern unsigned long vsyscall_pgprot; + #endif /* _ASM_X86_VSYSCALL_H */ Arnd

7 years, 7 months

2
5
0 0

[PATCH v4] extcon: int3496: process id-pin first so that we start with the right status

by Hans de Goede

Some other drivers may be waiting for our extcon to show-up, exiting their probe methods with -EPROBE_DEFER until we show up. These drivers will typically get the cable state directly after getting the extcon, this commit changes the int3496 code to wait for the initial processing of the id-pin to complete before exiting probe() with 0, which will cause devices waiting on the defered probe to get reprobed. This fixes a race where the initial work might still be running while other drivers were already calling extcon_get_state(). Fixes: 2f556bdb9f2e ("extcon: int3496: Add Intel INT3496 ACPI ... driver") Cc: stable(a)vger.kernel.org Signed-off-by: Hans de Goede <hdegoede(a)redhat.com> --- Changes in v2: -Add Fixes tag Changes in v3: -Fix oops on probe by scheduling the work too early Changes in v4: -Ugh sorry about this, but we cannot call extcon_set_state() before extcon_dev_register() at all because before registration the cable array is not yet allocated. Instead wait for the initial processing of the id-pin to complete before exiting probe(). --- drivers/extcon/extcon-intel-int3496.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/extcon/extcon-intel-int3496.c b/drivers/extcon/extcon-intel-int3496.c index c8691b5a9cb0..191e99f06a9a 100644 --- a/drivers/extcon/extcon-intel-int3496.c +++ b/drivers/extcon/extcon-intel-int3496.c @@ -153,8 +153,9 @@ static int int3496_probe(struct platform_device *pdev) return ret; } - /* queue initial processing of id-pin */ + /* process id-pin so that we start with the right status */ queue_delayed_work(system_wq, &data->work, 0); + flush_delayed_work(&data->work); platform_set_drvdata(pdev, data); -- 2.14.3

7 years, 7 months

2
1
0 0

Patch "RDMA/rxe: Fix a race condition related to the QP error state" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled RDMA/rxe: Fix a race condition related to the QP error state to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: rdma-rxe-fix-a-race-condition-related-to-the-qp-error-state.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 6f301e06de4cf9ab7303f5acd43e64fcd4aa04be Mon Sep 17 00:00:00 2001 From: Bart Van Assche <bart.vanassche(a)wdc.com> Date: Tue, 9 Jan 2018 11:23:40 -0800 Subject: RDMA/rxe: Fix a race condition related to the QP error state From: Bart Van Assche <bart.vanassche(a)wdc.com> commit 6f301e06de4cf9ab7303f5acd43e64fcd4aa04be upstream. The following sequence: * Change queue pair state into IB_QPS_ERR. * Post a work request on the queue pair. Triggers the following race condition in the rdma_rxe driver: * rxe_qp_error() triggers an asynchronous call of rxe_completer(), the function that examines the QP send queue. * rxe_post_send() posts a work request on the QP send queue. If rxe_completer() runs prior to rxe_post_send(), it will drain the send queue and the driver will assume no further action is necessary. However, once we post the send to the send queue, because the queue is in error, no send completion will ever happen and the send will get stuck. In order to process the send, we need to make sure that rxe_completer() gets run after a send is posted to a queue pair in an error state. This patch ensures that happens. Signed-off-by: Bart Van Assche <bart.vanassche(a)wdc.com> Cc: Moni Shoua <monis(a)mellanox.com> Cc: <stable(a)vger.kernel.org> # v4.8 Signed-off-by: Doug Ledford <dledford(a)redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/infiniband/sw/rxe/rxe_verbs.c | 2 ++ 1 file changed, 2 insertions(+) --- a/drivers/infiniband/sw/rxe/rxe_verbs.c +++ b/drivers/infiniband/sw/rxe/rxe_verbs.c @@ -848,6 +848,8 @@ static int rxe_post_send_kernel(struct r (queue_count(qp->sq.queue) > 1); rxe_run_task(&qp->req.task, must_sched); + if (unlikely(qp->req.state == QP_STATE_ERROR)) + rxe_run_task(&qp->comp.task, 1); return err; } Patches currently in stable-queue which might be from bart.vanassche(a)wdc.com are queue-4.9/rdma-rxe-fix-a-race-condition-related-to-the-qp-error-state.patch

7 years, 7 months

1
0
0 0

Patch "kselftest: fix OOM in memory compaction test" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled kselftest: fix OOM in memory compaction test to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: kselftest-fix-oom-in-memory-compaction-test.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 4c1baad223906943b595a887305f2e8124821dad Mon Sep 17 00:00:00 2001 From: Arnd Bergmann <arnd(a)arndb.de> Date: Tue, 9 Jan 2018 17:26:24 +0100 Subject: kselftest: fix OOM in memory compaction test From: Arnd Bergmann <arnd(a)arndb.de> commit 4c1baad223906943b595a887305f2e8124821dad upstream. Running the compaction_test sometimes results in out-of-memory failures. When I debugged this, it turned out that the code to reset the number of hugepages to the initial value is simply broken since we write into an open sysctl file descriptor multiple times without seeking back to the start. Adding the lseek here fixes the problem. Cc: stable(a)vger.kernel.org Reported-by: Naresh Kamboju <naresh.kamboju(a)linaro.org> Link: https://bugs.linaro.org/show_bug.cgi?id=3145 Signed-off-by: Arnd Bergmann <arnd(a)arndb.de> Signed-off-by: Shuah Khan <shuahkh(a)osg.samsung.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- tools/testing/selftests/vm/compaction_test.c | 2 ++ 1 file changed, 2 insertions(+) --- a/tools/testing/selftests/vm/compaction_test.c +++ b/tools/testing/selftests/vm/compaction_test.c @@ -136,6 +136,8 @@ int check_compaction(unsigned long mem_f printf("No of huge pages allocated = %d\n", (atoi(nr_hugepages))); + lseek(fd, 0, SEEK_SET); + if (write(fd, initial_nr_hugepages, strlen(initial_nr_hugepages)) != strlen(initial_nr_hugepages)) { perror("Failed to write value to /proc/sys/vm/nr_hugepages\n"); Patches currently in stable-queue which might be from arnd(a)arndb.de are queue-4.9/kselftest-fix-oom-in-memory-compaction-test.patch

7 years, 7 months

1
0
0 0

Patch "IB/qib: Fix comparison error with qperf compare/swap test" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled IB/qib: Fix comparison error with qperf compare/swap test to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: ib-qib-fix-comparison-error-with-qperf-compare-swap-test.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 87b3524cb5058fdc7c2afdb92bdb2e079661ddc4 Mon Sep 17 00:00:00 2001 From: Mike Marciniszyn <mike.marciniszyn(a)intel.com> Date: Tue, 14 Nov 2017 04:34:52 -0800 Subject: IB/qib: Fix comparison error with qperf compare/swap test From: Mike Marciniszyn <mike.marciniszyn(a)intel.com> commit 87b3524cb5058fdc7c2afdb92bdb2e079661ddc4 upstream. This failure exists with qib: ver_rc_compare_swap: mismatch, sequence 2, expected 123456789abcdef, got 0 The request builder was using the incorrect inlines to build the request header resulting in incorrect data in the atomic header. Fix by using the appropriate inlines to create the request. Fixes: 261a4351844b ("IB/qib,IB/hfi: Use core common header file") Reviewed-by: Michael J. Ruhl <michael.j.ruhl(a)intel.com> Signed-off-by: Mike Marciniszyn <mike.marciniszyn(a)intel.com> Signed-off-by: Dennis Dalessandro <dennis.dalessandro(a)intel.com> Signed-off-by: Jason Gunthorpe <jgg(a)mellanox.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/infiniband/hw/qib/qib_rc.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) --- a/drivers/infiniband/hw/qib/qib_rc.c +++ b/drivers/infiniband/hw/qib/qib_rc.c @@ -443,13 +443,13 @@ no_flow_control: qp->s_state = OP(COMPARE_SWAP); put_ib_ateth_swap(wqe->atomic_wr.swap, &ohdr->u.atomic_eth); - put_ib_ateth_swap(wqe->atomic_wr.compare_add, - &ohdr->u.atomic_eth); + put_ib_ateth_compare(wqe->atomic_wr.compare_add, + &ohdr->u.atomic_eth); } else { qp->s_state = OP(FETCH_ADD); put_ib_ateth_swap(wqe->atomic_wr.compare_add, &ohdr->u.atomic_eth); - put_ib_ateth_swap(0, &ohdr->u.atomic_eth); + put_ib_ateth_compare(0, &ohdr->u.atomic_eth); } put_ib_ateth_vaddr(wqe->atomic_wr.remote_addr, &ohdr->u.atomic_eth); Patches currently in stable-queue which might be from mike.marciniszyn(a)intel.com are queue-4.9/ib-qib-fix-comparison-error-with-qperf-compare-swap-test.patch

7 years, 7 months

1
0
0 0

Patch "IB/mlx4: Fix incorrectly releasing steerable UD QPs when have only ETH ports" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled IB/mlx4: Fix incorrectly releasing steerable UD QPs when have only ETH ports to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: ib-mlx4-fix-incorrectly-releasing-steerable-ud-qps-when-have-only-eth-ports.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 852f6927594d0d3e8632c889b2ab38cbc46476ad Mon Sep 17 00:00:00 2001 From: Jack Morgenstein <jackm(a)dev.mellanox.co.il> Date: Fri, 12 Jan 2018 07:58:40 +0200 Subject: IB/mlx4: Fix incorrectly releasing steerable UD QPs when have only ETH ports From: Jack Morgenstein <jackm(a)dev.mellanox.co.il> commit 852f6927594d0d3e8632c889b2ab38cbc46476ad upstream. Allocating steerable UD QPs depends on having at least one IB port, while releasing those QPs does not. As a result, when there are only ETH ports, the IB (RoCE) driver requests releasing a qp range whose base qp is zero, with qp count zero. When SR-IOV is enabled, and the VF driver is running on a VM over a hypervisor which treats such qp release calls as errors (rather than NOPs), we see lines in the VM message log like: mlx4_core 0002:00:02.0: Failed to release qp range base:0 cnt:0 Fix this by adding a check for a zero count in mlx4_release_qp_range() (which thus treats releasing 0 qps as a nop), and eliminating the check for device managed flow steering when releasing steerable UD QPs. (Freeing ib_uc_qpns_bitmap unconditionally is also OK, since it remains NULL when steerable UD QPs are not allocated). Fixes: 4196670be786 ("IB/mlx4: Don't allocate range of steerable UD QPs for Ethernet-only device") Signed-off-by: Jack Morgenstein <jackm(a)dev.mellanox.co.il> Signed-off-by: Leon Romanovsky <leon(a)kernel.org> Signed-off-by: Jason Gunthorpe <jgg(a)mellanox.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/infiniband/hw/mlx4/main.c | 13 +++++-------- drivers/net/ethernet/mellanox/mlx4/qp.c | 3 +++ 2 files changed, 8 insertions(+), 8 deletions(-) --- a/drivers/infiniband/hw/mlx4/main.c +++ b/drivers/infiniband/hw/mlx4/main.c @@ -2928,9 +2928,8 @@ err_steer_free_bitmap: kfree(ibdev->ib_uc_qpns_bitmap); err_steer_qp_release: - if (ibdev->steering_support == MLX4_STEERING_MODE_DEVICE_MANAGED) - mlx4_qp_release_range(dev, ibdev->steer_qpn_base, - ibdev->steer_qpn_count); + mlx4_qp_release_range(dev, ibdev->steer_qpn_base, + ibdev->steer_qpn_count); err_counter: for (i = 0; i < ibdev->num_ports; ++i) mlx4_ib_delete_counters_table(ibdev, &ibdev->counters_table[i]); @@ -3035,11 +3034,9 @@ static void mlx4_ib_remove(struct mlx4_d ibdev->iboe.nb.notifier_call = NULL; } - if (ibdev->steering_support == MLX4_STEERING_MODE_DEVICE_MANAGED) { - mlx4_qp_release_range(dev, ibdev->steer_qpn_base, - ibdev->steer_qpn_count); - kfree(ibdev->ib_uc_qpns_bitmap); - } + mlx4_qp_release_range(dev, ibdev->steer_qpn_base, + ibdev->steer_qpn_count); + kfree(ibdev->ib_uc_qpns_bitmap); iounmap(ibdev->uar_map); for (p = 0; p < ibdev->num_ports; ++p) --- a/drivers/net/ethernet/mellanox/mlx4/qp.c +++ b/drivers/net/ethernet/mellanox/mlx4/qp.c @@ -286,6 +286,9 @@ void mlx4_qp_release_range(struct mlx4_d u64 in_param = 0; int err; + if (!cnt) + return; + if (mlx4_is_mfunc(dev)) { set_param_l(&in_param, base_qpn); set_param_h(&in_param, cnt); Patches currently in stable-queue which might be from jackm(a)dev.mellanox.co.il are queue-4.9/ib-mlx4-fix-incorrectly-releasing-steerable-ud-qps-when-have-only-eth-ports.patch

7 years, 7 months

1
0
0 0

Patch "IB/mlx4: Fix incorrectly releasing steerable UD QPs when have only ETH ports" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled IB/mlx4: Fix incorrectly releasing steerable UD QPs when have only ETH ports to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: ib-mlx4-fix-incorrectly-releasing-steerable-ud-qps-when-have-only-eth-ports.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 852f6927594d0d3e8632c889b2ab38cbc46476ad Mon Sep 17 00:00:00 2001 From: Jack Morgenstein <jackm(a)dev.mellanox.co.il> Date: Fri, 12 Jan 2018 07:58:40 +0200 Subject: IB/mlx4: Fix incorrectly releasing steerable UD QPs when have only ETH ports From: Jack Morgenstein <jackm(a)dev.mellanox.co.il> commit 852f6927594d0d3e8632c889b2ab38cbc46476ad upstream. Allocating steerable UD QPs depends on having at least one IB port, while releasing those QPs does not. As a result, when there are only ETH ports, the IB (RoCE) driver requests releasing a qp range whose base qp is zero, with qp count zero. When SR-IOV is enabled, and the VF driver is running on a VM over a hypervisor which treats such qp release calls as errors (rather than NOPs), we see lines in the VM message log like: mlx4_core 0002:00:02.0: Failed to release qp range base:0 cnt:0 Fix this by adding a check for a zero count in mlx4_release_qp_range() (which thus treats releasing 0 qps as a nop), and eliminating the check for device managed flow steering when releasing steerable UD QPs. (Freeing ib_uc_qpns_bitmap unconditionally is also OK, since it remains NULL when steerable UD QPs are not allocated). Fixes: 4196670be786 ("IB/mlx4: Don't allocate range of steerable UD QPs for Ethernet-only device") Signed-off-by: Jack Morgenstein <jackm(a)dev.mellanox.co.il> Signed-off-by: Leon Romanovsky <leon(a)kernel.org> Signed-off-by: Jason Gunthorpe <jgg(a)mellanox.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/infiniband/hw/mlx4/main.c | 13 +++++-------- drivers/net/ethernet/mellanox/mlx4/qp.c | 3 +++ 2 files changed, 8 insertions(+), 8 deletions(-) --- a/drivers/infiniband/hw/mlx4/main.c +++ b/drivers/infiniband/hw/mlx4/main.c @@ -2483,9 +2483,8 @@ err_steer_free_bitmap: kfree(ibdev->ib_uc_qpns_bitmap); err_steer_qp_release: - if (ibdev->steering_support == MLX4_STEERING_MODE_DEVICE_MANAGED) - mlx4_qp_release_range(dev, ibdev->steer_qpn_base, - ibdev->steer_qpn_count); + mlx4_qp_release_range(dev, ibdev->steer_qpn_base, + ibdev->steer_qpn_count); err_counter: for (i = 0; i < ibdev->num_ports; ++i) mlx4_ib_delete_counters_table(ibdev, &ibdev->counters_table[i]); @@ -2586,11 +2585,9 @@ static void mlx4_ib_remove(struct mlx4_d ibdev->iboe.nb.notifier_call = NULL; } - if (ibdev->steering_support == MLX4_STEERING_MODE_DEVICE_MANAGED) { - mlx4_qp_release_range(dev, ibdev->steer_qpn_base, - ibdev->steer_qpn_count); - kfree(ibdev->ib_uc_qpns_bitmap); - } + mlx4_qp_release_range(dev, ibdev->steer_qpn_base, + ibdev->steer_qpn_count); + kfree(ibdev->ib_uc_qpns_bitmap); iounmap(ibdev->uar_map); for (p = 0; p < ibdev->num_ports; ++p) --- a/drivers/net/ethernet/mellanox/mlx4/qp.c +++ b/drivers/net/ethernet/mellanox/mlx4/qp.c @@ -280,6 +280,9 @@ void mlx4_qp_release_range(struct mlx4_d u64 in_param = 0; int err; + if (!cnt) + return; + if (mlx4_is_mfunc(dev)) { set_param_l(&in_param, base_qpn); set_param_h(&in_param, cnt); Patches currently in stable-queue which might be from jackm(a)dev.mellanox.co.il are queue-4.4/ib-mlx4-fix-incorrectly-releasing-steerable-ud-qps-when-have-only-eth-ports.patch

7 years, 7 months

1
0
0 0

Patch "selftests: seccomp: fix compile error seccomp_bpf" has been added to the 4.15-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled selftests: seccomp: fix compile error seccomp_bpf to the 4.15-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: selftests-seccomp-fix-compile-error-seccomp_bpf.patch and it can be found in the queue-4.15 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 912ec316686df352028afb6efec59e47a958a24d Mon Sep 17 00:00:00 2001 From: Anders Roxell <anders.roxell(a)linaro.org> Date: Fri, 5 Jan 2018 17:31:18 +0100 Subject: selftests: seccomp: fix compile error seccomp_bpf From: Anders Roxell <anders.roxell(a)linaro.org> commit 912ec316686df352028afb6efec59e47a958a24d upstream. aarch64-linux-gnu-gcc -Wl,-no-as-needed -Wall -lpthread seccomp_bpf.c -o seccomp_bpf seccomp_bpf.c: In function 'tracer_ptrace': seccomp_bpf.c:1720:12: error: '__NR_open' undeclared (first use in this function) if (nr == __NR_open) ^~~~~~~~~ seccomp_bpf.c:1720:12: note: each undeclared identifier is reported only once for each function it appears in In file included from seccomp_bpf.c:48:0: seccomp_bpf.c: In function 'TRACE_syscall_ptrace_syscall_dropped': seccomp_bpf.c:1795:39: error: '__NR_open' undeclared (first use in this function) EXPECT_SYSCALL_RETURN(EPERM, syscall(__NR_open)); ^ open(2) is a legacy syscall, replaced with openat(2) since 2.6.16. Thus new architectures in the kernel, such as arm64, don't implement these legacy syscalls. Fixes: a33b2d0359a0 ("selftests/seccomp: Add tests for basic ptrace actions") Signed-off-by: Anders Roxell <anders.roxell(a)linaro.org> Tested-by: Naresh Kamboju <naresh.kamboju(a)linaro.org> Cc: stable(a)vger.kernel.org Acked-by: Kees Cook <keescook(a)chromium.org> Signed-off-by: Shuah Khan <shuahkh(a)osg.samsung.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- tools/testing/selftests/seccomp/seccomp_bpf.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) --- a/tools/testing/selftests/seccomp/seccomp_bpf.c +++ b/tools/testing/selftests/seccomp/seccomp_bpf.c @@ -1717,7 +1717,7 @@ void tracer_ptrace(struct __test_metadat if (nr == __NR_getpid) change_syscall(_metadata, tracee, __NR_getppid); - if (nr == __NR_open) + if (nr == __NR_openat) change_syscall(_metadata, tracee, -1); } @@ -1792,7 +1792,7 @@ TEST_F(TRACE_syscall, ptrace_syscall_dro true); /* Tracer should skip the open syscall, resulting in EPERM. */ - EXPECT_SYSCALL_RETURN(EPERM, syscall(__NR_open)); + EXPECT_SYSCALL_RETURN(EPERM, syscall(__NR_openat)); } TEST_F(TRACE_syscall, syscall_allowed) Patches currently in stable-queue which might be from anders.roxell(a)linaro.org are queue-4.15/selftests-seccomp-fix-compile-error-seccomp_bpf.patch

7 years, 7 months

1
0
0 0

Patch "RDMA/rxe: Fix rxe_qp_cleanup()" has been added to the 4.15-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled RDMA/rxe: Fix rxe_qp_cleanup() to the 4.15-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: rdma-rxe-fix-rxe_qp_cleanup.patch and it can be found in the queue-4.15 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From bb3ffb7ad48a21e98a5c64eb21103a74fd9f03f6 Mon Sep 17 00:00:00 2001 From: Bart Van Assche <bart.vanassche(a)wdc.com> Date: Fri, 12 Jan 2018 15:11:59 -0800 Subject: RDMA/rxe: Fix rxe_qp_cleanup() From: Bart Van Assche <bart.vanassche(a)wdc.com> commit bb3ffb7ad48a21e98a5c64eb21103a74fd9f03f6 upstream. rxe_qp_cleanup() can sleep so it must be run in thread context and not in atomic context. This patch avoids that the following bug is triggered: Kernel BUG at 00000000560033f3 [verbose debug info unavailable] BUG: sleeping function called from invalid context at net/core/sock.c:2761 in_atomic(): 1, irqs_disabled(): 0, pid: 7, name: ksoftirqd/0 INFO: lockdep is turned off. Preemption disabled at: [<00000000b6e69628>] __do_softirq+0x4e/0x540 CPU: 0 PID: 7 Comm: ksoftirqd/0 Not tainted 4.15.0-rc7-dbg+ #4 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.0.0-prebuilt.qemu-project.org 04/01/2014 Call Trace: dump_stack+0x85/0xbf ___might_sleep+0x177/0x260 lock_sock_nested+0x1d/0x90 inet_shutdown+0x2e/0xd0 rxe_qp_cleanup+0x107/0x140 [rdma_rxe] rxe_elem_release+0x18/0x80 [rdma_rxe] rxe_requester+0x1cf/0x11b0 [rdma_rxe] rxe_do_task+0x78/0xf0 [rdma_rxe] tasklet_action+0x99/0x270 __do_softirq+0xc0/0x540 run_ksoftirqd+0x1c/0x70 smpboot_thread_fn+0x1be/0x270 kthread+0x117/0x130 ret_from_fork+0x24/0x30 Signed-off-by: Bart Van Assche <bart.vanassche(a)wdc.com> Cc: Moni Shoua <monis(a)mellanox.com> Signed-off-by: Doug Ledford <dledford(a)redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/infiniband/sw/rxe/rxe_qp.c | 12 ++++++++++-- drivers/infiniband/sw/rxe/rxe_verbs.h | 3 +++ 2 files changed, 13 insertions(+), 2 deletions(-) --- a/drivers/infiniband/sw/rxe/rxe_qp.c +++ b/drivers/infiniband/sw/rxe/rxe_qp.c @@ -824,9 +824,9 @@ void rxe_qp_destroy(struct rxe_qp *qp) } /* called when the last reference to the qp is dropped */ -void rxe_qp_cleanup(struct rxe_pool_entry *arg) +static void rxe_qp_do_cleanup(struct work_struct *work) { - struct rxe_qp *qp = container_of(arg, typeof(*qp), pelem); + struct rxe_qp *qp = container_of(work, typeof(*qp), cleanup_work.work); rxe_drop_all_mcast_groups(qp); @@ -859,3 +859,11 @@ void rxe_qp_cleanup(struct rxe_pool_entr kernel_sock_shutdown(qp->sk, SHUT_RDWR); sock_release(qp->sk); } + +/* called when the last reference to the qp is dropped */ +void rxe_qp_cleanup(struct rxe_pool_entry *arg) +{ + struct rxe_qp *qp = container_of(arg, typeof(*qp), pelem); + + execute_in_process_context(rxe_qp_do_cleanup, &qp->cleanup_work); +} --- a/drivers/infiniband/sw/rxe/rxe_verbs.h +++ b/drivers/infiniband/sw/rxe/rxe_verbs.h @@ -35,6 +35,7 @@ #define RXE_VERBS_H #include <linux/interrupt.h> +#include <linux/workqueue.h> #include <rdma/rdma_user_rxe.h> #include "rxe_pool.h" #include "rxe_task.h" @@ -281,6 +282,8 @@ struct rxe_qp { struct timer_list rnr_nak_timer; spinlock_t state_lock; /* guard requester and completer */ + + struct execute_work cleanup_work; }; enum rxe_mem_state { Patches currently in stable-queue which might be from bart.vanassche(a)wdc.com are queue-4.15/ib-core-fix-two-kernel-warnings-triggered-by-rxe-registration.patch queue-4.15/rdma-rxe-fix-a-race-condition-in-rxe_requester.patch queue-4.15/rdma-rxe-fix-rxe_qp_cleanup.patch queue-4.15/rdma-rxe-fix-a-race-condition-related-to-the-qp-error-state.patch

7 years, 7 months

1
0
0 0

Patch "RDMA/rxe: Fix a race condition related to the QP error state" has been added to the 4.15-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled RDMA/rxe: Fix a race condition related to the QP error state to the 4.15-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: rdma-rxe-fix-a-race-condition-related-to-the-qp-error-state.patch and it can be found in the queue-4.15 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 6f301e06de4cf9ab7303f5acd43e64fcd4aa04be Mon Sep 17 00:00:00 2001 From: Bart Van Assche <bart.vanassche(a)wdc.com> Date: Tue, 9 Jan 2018 11:23:40 -0800 Subject: RDMA/rxe: Fix a race condition related to the QP error state From: Bart Van Assche <bart.vanassche(a)wdc.com> commit 6f301e06de4cf9ab7303f5acd43e64fcd4aa04be upstream. The following sequence: * Change queue pair state into IB_QPS_ERR. * Post a work request on the queue pair. Triggers the following race condition in the rdma_rxe driver: * rxe_qp_error() triggers an asynchronous call of rxe_completer(), the function that examines the QP send queue. * rxe_post_send() posts a work request on the QP send queue. If rxe_completer() runs prior to rxe_post_send(), it will drain the send queue and the driver will assume no further action is necessary. However, once we post the send to the send queue, because the queue is in error, no send completion will ever happen and the send will get stuck. In order to process the send, we need to make sure that rxe_completer() gets run after a send is posted to a queue pair in an error state. This patch ensures that happens. Signed-off-by: Bart Van Assche <bart.vanassche(a)wdc.com> Cc: Moni Shoua <monis(a)mellanox.com> Cc: <stable(a)vger.kernel.org> # v4.8 Signed-off-by: Doug Ledford <dledford(a)redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/infiniband/sw/rxe/rxe_verbs.c | 2 ++ 1 file changed, 2 insertions(+) --- a/drivers/infiniband/sw/rxe/rxe_verbs.c +++ b/drivers/infiniband/sw/rxe/rxe_verbs.c @@ -814,6 +814,8 @@ static int rxe_post_send_kernel(struct r (queue_count(qp->sq.queue) > 1); rxe_run_task(&qp->req.task, must_sched); + if (unlikely(qp->req.state == QP_STATE_ERROR)) + rxe_run_task(&qp->comp.task, 1); return err; } Patches currently in stable-queue which might be from bart.vanassche(a)wdc.com are queue-4.15/ib-core-fix-two-kernel-warnings-triggered-by-rxe-registration.patch queue-4.15/rdma-rxe-fix-a-race-condition-in-rxe_requester.patch queue-4.15/rdma-rxe-fix-rxe_qp_cleanup.patch queue-4.15/rdma-rxe-fix-a-race-condition-related-to-the-qp-error-state.patch

7 years, 7 months

1
0
0 0

Patch "RDMA/rxe: Fix a race condition in rxe_requester()" has been added to the 4.15-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled RDMA/rxe: Fix a race condition in rxe_requester() to the 4.15-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: rdma-rxe-fix-a-race-condition-in-rxe_requester.patch and it can be found in the queue-4.15 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 65567e41219888feec72fee1de98ccf1efbbc16d Mon Sep 17 00:00:00 2001 From: Bart Van Assche <bart.vanassche(a)wdc.com> Date: Fri, 12 Jan 2018 15:11:58 -0800 Subject: RDMA/rxe: Fix a race condition in rxe_requester() From: Bart Van Assche <bart.vanassche(a)wdc.com> commit 65567e41219888feec72fee1de98ccf1efbbc16d upstream. The rxe driver works as follows: * The send queue, receive queue and completion queues are implemented as circular buffers. * ib_post_send() and ib_post_recv() calls are serialized through a spinlock. * Removing elements from various queues happens from tasklet context. Tasklets are guaranteed to run on at most one CPU. This serializes access to these queues. See also rxe_completer(), rxe_requester() and rxe_responder(). * rxe_completer() processes the skbs queued onto qp->resp_pkts. * rxe_requester() handles the send queue (qp->sq.queue). * rxe_responder() processes the skbs queued onto qp->req_pkts. Since rxe_drain_req_pkts() processes qp->req_pkts, calling rxe_drain_req_pkts() from rxe_requester() is racy. Hence this patch. Reported-by: Moni Shoua <monis(a)mellanox.com> Signed-off-by: Bart Van Assche <bart.vanassche(a)wdc.com> Cc: stable(a)vger.kernel.org Signed-off-by: Doug Ledford <dledford(a)redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/infiniband/sw/rxe/rxe_loc.h | 1 - drivers/infiniband/sw/rxe/rxe_req.c | 9 +-------- drivers/infiniband/sw/rxe/rxe_resp.c | 2 +- 3 files changed, 2 insertions(+), 10 deletions(-) --- a/drivers/infiniband/sw/rxe/rxe_loc.h +++ b/drivers/infiniband/sw/rxe/rxe_loc.h @@ -237,7 +237,6 @@ int rxe_srq_from_attr(struct rxe_dev *rx void rxe_release(struct kref *kref); -void rxe_drain_req_pkts(struct rxe_qp *qp, bool notify); int rxe_completer(void *arg); int rxe_requester(void *arg); int rxe_responder(void *arg); --- a/drivers/infiniband/sw/rxe/rxe_req.c +++ b/drivers/infiniband/sw/rxe/rxe_req.c @@ -594,15 +594,8 @@ int rxe_requester(void *arg) rxe_add_ref(qp); next_wqe: - if (unlikely(!qp->valid)) { - rxe_drain_req_pkts(qp, true); + if (unlikely(!qp->valid || qp->req.state == QP_STATE_ERROR)) goto exit; - } - - if (unlikely(qp->req.state == QP_STATE_ERROR)) { - rxe_drain_req_pkts(qp, true); - goto exit; - } if (unlikely(qp->req.state == QP_STATE_RESET)) { qp->req.wqe_index = consumer_index(qp->sq.queue); --- a/drivers/infiniband/sw/rxe/rxe_resp.c +++ b/drivers/infiniband/sw/rxe/rxe_resp.c @@ -1210,7 +1210,7 @@ static enum resp_states do_class_d1e_err } } -void rxe_drain_req_pkts(struct rxe_qp *qp, bool notify) +static void rxe_drain_req_pkts(struct rxe_qp *qp, bool notify) { struct sk_buff *skb; Patches currently in stable-queue which might be from bart.vanassche(a)wdc.com are queue-4.15/ib-core-fix-two-kernel-warnings-triggered-by-rxe-registration.patch queue-4.15/rdma-rxe-fix-a-race-condition-in-rxe_requester.patch queue-4.15/rdma-rxe-fix-rxe_qp_cleanup.patch queue-4.15/rdma-rxe-fix-a-race-condition-related-to-the-qp-error-state.patch

7 years, 7 months

1
0
0 0

Patch "IB/umad: Fix use of unprotected device pointer" has been added to the 4.15-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled IB/umad: Fix use of unprotected device pointer to the 4.15-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: ib-umad-fix-use-of-unprotected-device-pointer.patch and it can be found in the queue-4.15 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From f23a5350e43c810ca36b26d4ed4ecd9a08686f47 Mon Sep 17 00:00:00 2001 From: Jack Morgenstein <jackm(a)dev.mellanox.co.il> Date: Sun, 28 Jan 2018 11:25:29 +0200 Subject: IB/umad: Fix use of unprotected device pointer From: Jack Morgenstein <jackm(a)dev.mellanox.co.il> commit f23a5350e43c810ca36b26d4ed4ecd9a08686f47 upstream. The ib_write_umad() is protected by taking the umad file mutex. However, it accesses file->port->ib_dev -- which is protected only by the port's mutex (field file_mutex). The ib_umad_remove_one() calls ib_umad_kill_port() which sets port->ib_dev to NULL under the port mutex (NOT the file mutex). It then sets the mad agent to "dead" under the umad file mutex. This is a race condition -- because there is a window where port->ib_dev is NULL, while the agent is not "dead". As a result, we saw stack traces like: [16490.678059] BUG: unable to handle kernel NULL pointer dereference at 00000000000000b0 [16490.678246] IP: ib_umad_write+0x29c/0xa3a [ib_umad] [16490.678333] PGD 0 P4D 0 [16490.678404] Oops: 0000 [#1] SMP PTI [16490.678466] Modules linked in: rdma_ucm(OE) ib_ucm(OE) rdma_cm(OE) iw_cm(OE) ib_ipoib(OE) ib_cm(OE) ib_uverbs(OE) ib_umad(OE) mlx4_en(OE) ptp pps_core mlx4_ib(OE-) ib_core(OE) mlx4_core(OE) mlx_compat (OE) memtrack(OE) devlink mst_pciconf(OE) mst_pci(OE) netconsole nfsv3 nfs_acl nfs lockd grace fscache cfg80211 rfkill esp6_offload esp6 esp4_offload esp4 sunrpc kvm_intel kvm ppdev parport_pc irqbypass parport joydev i2c_piix4 virtio_balloon cirrus drm_kms_helper ttm drm e1000 serio_raw virtio_pci virtio_ring virtio ata_generic pata_acpi qemu_fw_cfg [last unloaded: mlxfw] [16490.679202] CPU: 4 PID: 3115 Comm: sminfo Tainted: G OE 4.14.13-300.fc27.x86_64 #1 [16490.679339] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Ubuntu-1.8.2-1ubuntu2 04/01/2014 [16490.679477] task: ffff9cf753890000 task.stack: ffffaf70c26b0000 [16490.679571] RIP: 0010:ib_umad_write+0x29c/0xa3a [ib_umad] [16490.679664] RSP: 0018:ffffaf70c26b3d90 EFLAGS: 00010202 [16490.679747] RAX: 0000000000000010 RBX: ffff9cf75610fd80 RCX: 0000000000000000 [16490.679856] RDX: 0000000000000001 RSI: 00007ffdf2bfd714 RDI: ffff9cf6bb2a9c00 In the above trace, ib_umad_write is trying to dereference the NULL file->port->ib_dev pointer. Fix this by using the agent's device pointer (the device field in struct ib_mad_agent) -- which IS protected by the umad file mutex. Fixes: 44c58487d51a ("IB/core: Define 'ib' and 'roce' rdma_ah_attr types") Signed-off-by: Jack Morgenstein <jackm(a)dev.mellanox.co.il> Signed-off-by: Leon Romanovsky <leon(a)kernel.org> Signed-off-by: Jason Gunthorpe <jgg(a)mellanox.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/infiniband/core/user_mad.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/infiniband/core/user_mad.c +++ b/drivers/infiniband/core/user_mad.c @@ -500,7 +500,7 @@ static ssize_t ib_umad_write(struct file } memset(&ah_attr, 0, sizeof ah_attr); - ah_attr.type = rdma_ah_find_type(file->port->ib_dev, + ah_attr.type = rdma_ah_find_type(agent->device, file->port->port_num); rdma_ah_set_dlid(&ah_attr, be16_to_cpu(packet->mad.hdr.lid)); rdma_ah_set_sl(&ah_attr, packet->mad.hdr.sl); Patches currently in stable-queue which might be from jackm(a)dev.mellanox.co.il are queue-4.15/ib-mlx4-fix-incorrectly-releasing-steerable-ud-qps-when-have-only-eth-ports.patch queue-4.15/ib-umad-fix-use-of-unprotected-device-pointer.patch

7 years, 7 months

1
0
0 0

Patch "kselftest: fix OOM in memory compaction test" has been added to the 4.15-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled kselftest: fix OOM in memory compaction test to the 4.15-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: kselftest-fix-oom-in-memory-compaction-test.patch and it can be found in the queue-4.15 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 4c1baad223906943b595a887305f2e8124821dad Mon Sep 17 00:00:00 2001 From: Arnd Bergmann <arnd(a)arndb.de> Date: Tue, 9 Jan 2018 17:26:24 +0100 Subject: kselftest: fix OOM in memory compaction test From: Arnd Bergmann <arnd(a)arndb.de> commit 4c1baad223906943b595a887305f2e8124821dad upstream. Running the compaction_test sometimes results in out-of-memory failures. When I debugged this, it turned out that the code to reset the number of hugepages to the initial value is simply broken since we write into an open sysctl file descriptor multiple times without seeking back to the start. Adding the lseek here fixes the problem. Cc: stable(a)vger.kernel.org Reported-by: Naresh Kamboju <naresh.kamboju(a)linaro.org> Link: https://bugs.linaro.org/show_bug.cgi?id=3145 Signed-off-by: Arnd Bergmann <arnd(a)arndb.de> Signed-off-by: Shuah Khan <shuahkh(a)osg.samsung.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- tools/testing/selftests/vm/compaction_test.c | 2 ++ 1 file changed, 2 insertions(+) --- a/tools/testing/selftests/vm/compaction_test.c +++ b/tools/testing/selftests/vm/compaction_test.c @@ -137,6 +137,8 @@ int check_compaction(unsigned long mem_f printf("No of huge pages allocated = %d\n", (atoi(nr_hugepages))); + lseek(fd, 0, SEEK_SET); + if (write(fd, initial_nr_hugepages, strlen(initial_nr_hugepages)) != strlen(initial_nr_hugepages)) { perror("Failed to write value to /proc/sys/vm/nr_hugepages\n"); Patches currently in stable-queue which might be from arnd(a)arndb.de are queue-4.15/kselftest-fix-oom-in-memory-compaction-test.patch

7 years, 7 months

1
0
0 0

Patch "IB/qib: Fix comparison error with qperf compare/swap test" has been added to the 4.15-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled IB/qib: Fix comparison error with qperf compare/swap test to the 4.15-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: ib-qib-fix-comparison-error-with-qperf-compare-swap-test.patch and it can be found in the queue-4.15 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 87b3524cb5058fdc7c2afdb92bdb2e079661ddc4 Mon Sep 17 00:00:00 2001 From: Mike Marciniszyn <mike.marciniszyn(a)intel.com> Date: Tue, 14 Nov 2017 04:34:52 -0800 Subject: IB/qib: Fix comparison error with qperf compare/swap test From: Mike Marciniszyn <mike.marciniszyn(a)intel.com> commit 87b3524cb5058fdc7c2afdb92bdb2e079661ddc4 upstream. This failure exists with qib: ver_rc_compare_swap: mismatch, sequence 2, expected 123456789abcdef, got 0 The request builder was using the incorrect inlines to build the request header resulting in incorrect data in the atomic header. Fix by using the appropriate inlines to create the request. Fixes: 261a4351844b ("IB/qib,IB/hfi: Use core common header file") Reviewed-by: Michael J. Ruhl <michael.j.ruhl(a)intel.com> Signed-off-by: Mike Marciniszyn <mike.marciniszyn(a)intel.com> Signed-off-by: Dennis Dalessandro <dennis.dalessandro(a)intel.com> Signed-off-by: Jason Gunthorpe <jgg(a)mellanox.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/infiniband/hw/qib/qib_rc.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) --- a/drivers/infiniband/hw/qib/qib_rc.c +++ b/drivers/infiniband/hw/qib/qib_rc.c @@ -434,13 +434,13 @@ no_flow_control: qp->s_state = OP(COMPARE_SWAP); put_ib_ateth_swap(wqe->atomic_wr.swap, &ohdr->u.atomic_eth); - put_ib_ateth_swap(wqe->atomic_wr.compare_add, - &ohdr->u.atomic_eth); + put_ib_ateth_compare(wqe->atomic_wr.compare_add, + &ohdr->u.atomic_eth); } else { qp->s_state = OP(FETCH_ADD); put_ib_ateth_swap(wqe->atomic_wr.compare_add, &ohdr->u.atomic_eth); - put_ib_ateth_swap(0, &ohdr->u.atomic_eth); + put_ib_ateth_compare(0, &ohdr->u.atomic_eth); } put_ib_ateth_vaddr(wqe->atomic_wr.remote_addr, &ohdr->u.atomic_eth); Patches currently in stable-queue which might be from mike.marciniszyn(a)intel.com are queue-4.15/ib-qib-fix-comparison-error-with-qperf-compare-swap-test.patch

7 years, 7 months

1
0
0 0

Patch "IB/mlx4: Fix incorrectly releasing steerable UD QPs when have only ETH ports" has been added to the 4.15-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled IB/mlx4: Fix incorrectly releasing steerable UD QPs when have only ETH ports to the 4.15-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: ib-mlx4-fix-incorrectly-releasing-steerable-ud-qps-when-have-only-eth-ports.patch and it can be found in the queue-4.15 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 852f6927594d0d3e8632c889b2ab38cbc46476ad Mon Sep 17 00:00:00 2001 From: Jack Morgenstein <jackm(a)dev.mellanox.co.il> Date: Fri, 12 Jan 2018 07:58:40 +0200 Subject: IB/mlx4: Fix incorrectly releasing steerable UD QPs when have only ETH ports From: Jack Morgenstein <jackm(a)dev.mellanox.co.il> commit 852f6927594d0d3e8632c889b2ab38cbc46476ad upstream. Allocating steerable UD QPs depends on having at least one IB port, while releasing those QPs does not. As a result, when there are only ETH ports, the IB (RoCE) driver requests releasing a qp range whose base qp is zero, with qp count zero. When SR-IOV is enabled, and the VF driver is running on a VM over a hypervisor which treats such qp release calls as errors (rather than NOPs), we see lines in the VM message log like: mlx4_core 0002:00:02.0: Failed to release qp range base:0 cnt:0 Fix this by adding a check for a zero count in mlx4_release_qp_range() (which thus treats releasing 0 qps as a nop), and eliminating the check for device managed flow steering when releasing steerable UD QPs. (Freeing ib_uc_qpns_bitmap unconditionally is also OK, since it remains NULL when steerable UD QPs are not allocated). Fixes: 4196670be786 ("IB/mlx4: Don't allocate range of steerable UD QPs for Ethernet-only device") Signed-off-by: Jack Morgenstein <jackm(a)dev.mellanox.co.il> Signed-off-by: Leon Romanovsky <leon(a)kernel.org> Signed-off-by: Jason Gunthorpe <jgg(a)mellanox.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/infiniband/hw/mlx4/main.c | 13 +++++-------- drivers/net/ethernet/mellanox/mlx4/qp.c | 3 +++ 2 files changed, 8 insertions(+), 8 deletions(-) --- a/drivers/infiniband/hw/mlx4/main.c +++ b/drivers/infiniband/hw/mlx4/main.c @@ -2995,9 +2995,8 @@ err_steer_free_bitmap: kfree(ibdev->ib_uc_qpns_bitmap); err_steer_qp_release: - if (ibdev->steering_support == MLX4_STEERING_MODE_DEVICE_MANAGED) - mlx4_qp_release_range(dev, ibdev->steer_qpn_base, - ibdev->steer_qpn_count); + mlx4_qp_release_range(dev, ibdev->steer_qpn_base, + ibdev->steer_qpn_count); err_counter: for (i = 0; i < ibdev->num_ports; ++i) mlx4_ib_delete_counters_table(ibdev, &ibdev->counters_table[i]); @@ -3102,11 +3101,9 @@ static void mlx4_ib_remove(struct mlx4_d ibdev->iboe.nb.notifier_call = NULL; } - if (ibdev->steering_support == MLX4_STEERING_MODE_DEVICE_MANAGED) { - mlx4_qp_release_range(dev, ibdev->steer_qpn_base, - ibdev->steer_qpn_count); - kfree(ibdev->ib_uc_qpns_bitmap); - } + mlx4_qp_release_range(dev, ibdev->steer_qpn_base, + ibdev->steer_qpn_count); + kfree(ibdev->ib_uc_qpns_bitmap); iounmap(ibdev->uar_map); for (p = 0; p < ibdev->num_ports; ++p) --- a/drivers/net/ethernet/mellanox/mlx4/qp.c +++ b/drivers/net/ethernet/mellanox/mlx4/qp.c @@ -287,6 +287,9 @@ void mlx4_qp_release_range(struct mlx4_d u64 in_param = 0; int err; + if (!cnt) + return; + if (mlx4_is_mfunc(dev)) { set_param_l(&in_param, base_qpn); set_param_h(&in_param, cnt); Patches currently in stable-queue which might be from jackm(a)dev.mellanox.co.il are queue-4.15/ib-mlx4-fix-incorrectly-releasing-steerable-ud-qps-when-have-only-eth-ports.patch queue-4.15/ib-umad-fix-use-of-unprotected-device-pointer.patch

7 years, 7 months

1
0
0 0

Patch "IB/core: Fix two kernel warnings triggered by rxe registration" has been added to the 4.15-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled IB/core: Fix two kernel warnings triggered by rxe registration to the 4.15-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: ib-core-fix-two-kernel-warnings-triggered-by-rxe-registration.patch and it can be found in the queue-4.15 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 02ee9da347873699603d9ce0112a80b5dd69dea1 Mon Sep 17 00:00:00 2001 From: Bart Van Assche <bart.vanassche(a)wdc.com> Date: Wed, 3 Jan 2018 13:28:18 -0800 Subject: IB/core: Fix two kernel warnings triggered by rxe registration From: Bart Van Assche <bart.vanassche(a)wdc.com> commit 02ee9da347873699603d9ce0112a80b5dd69dea1 upstream. Eliminate the WARN_ONs that create following two warnings when registering an rxe device: WARNING: CPU: 2 PID: 1005 at drivers/infiniband/core/device.c:449 ib_register_device+0x591/0x640 [ib_core] CPU: 2 PID: 1005 Comm: run_tests Not tainted 4.15.0-rc4-dbg+ #2 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.0.0-prebuilt.qemu-project.org 04/01/2014 RIP: 0010:ib_register_device+0x591/0x640 [ib_core] Call Trace: rxe_register_device+0x3c6/0x470 [rdma_rxe] rxe_add+0x543/0x5e0 [rdma_rxe] rxe_net_add+0x37/0xb0 [rdma_rxe] rxe_param_set_add+0x5a/0x120 [rdma_rxe] param_attr_store+0x5e/0xc0 module_attr_store+0x19/0x30 sysfs_kf_write+0x3d/0x50 kernfs_fop_write+0x116/0x1a0 __vfs_write+0x23/0x120 vfs_write+0xbe/0x1b0 SyS_write+0x44/0xa0 entry_SYSCALL_64_fastpath+0x23/0x9a WARNING: CPU: 2 PID: 1005 at drivers/infiniband/core/sysfs.c:1279 ib_device_register_sysfs+0x11d/0x160 [ib_core] CPU: 2 PID: 1005 Comm: run_tests Tainted: G W 4.15.0-rc4-dbg+ #2 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.0.0-prebuilt.qemu-project.org 04/01/2014 RIP: 0010:ib_device_register_sysfs+0x11d/0x160 [ib_core] Call Trace: ib_register_device+0x3f7/0x640 [ib_core] rxe_register_device+0x3c6/0x470 [rdma_rxe] rxe_add+0x543/0x5e0 [rdma_rxe] rxe_net_add+0x37/0xb0 [rdma_rxe] rxe_param_set_add+0x5a/0x120 [rdma_rxe] param_attr_store+0x5e/0xc0 module_attr_store+0x19/0x30 sysfs_kf_write+0x3d/0x50 kernfs_fop_write+0x116/0x1a0 __vfs_write+0x23/0x120 vfs_write+0xbe/0x1b0 SyS_write+0x44/0xa0 entry_SYSCALL_64_fastpath+0x23/0x9a The code should accept either a parent pointer or a fully specified DMA specification without producing warnings. Fixes: 99db9494035f ("IB/core: Remove ib_device.dma_device") Signed-off-by: Bart Van Assche <bart.vanassche(a)wdc.com> Cc: Leon Romanovsky <leon(a)kernel.org> Signed-off-by: Jason Gunthorpe <jgg(a)mellanox.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/infiniband/core/device.c | 20 ++++++++++++++------ drivers/infiniband/core/sysfs.c | 1 - 2 files changed, 14 insertions(+), 7 deletions(-) --- a/drivers/infiniband/core/device.c +++ b/drivers/infiniband/core/device.c @@ -462,7 +462,6 @@ int ib_register_device(struct ib_device struct ib_udata uhw = {.outlen = 0, .inlen = 0}; struct device *parent = device->dev.parent; - WARN_ON_ONCE(!parent); WARN_ON_ONCE(device->dma_device); if (device->dev.dma_ops) { /* @@ -471,16 +470,25 @@ int ib_register_device(struct ib_device * into device->dev. */ device->dma_device = &device->dev; - if (!device->dev.dma_mask) - device->dev.dma_mask = parent->dma_mask; - if (!device->dev.coherent_dma_mask) - device->dev.coherent_dma_mask = - parent->coherent_dma_mask; + if (!device->dev.dma_mask) { + if (parent) + device->dev.dma_mask = parent->dma_mask; + else + WARN_ON_ONCE(true); + } + if (!device->dev.coherent_dma_mask) { + if (parent) + device->dev.coherent_dma_mask = + parent->coherent_dma_mask; + else + WARN_ON_ONCE(true); + } } else { /* * The caller did not provide custom DMA operations. Use the * DMA mapping operations of the parent device. */ + WARN_ON_ONCE(!parent); device->dma_device = parent; } --- a/drivers/infiniband/core/sysfs.c +++ b/drivers/infiniband/core/sysfs.c @@ -1276,7 +1276,6 @@ int ib_device_register_sysfs(struct ib_d int ret; int i; - WARN_ON_ONCE(!device->dev.parent); ret = dev_set_name(class_dev, "%s", device->name); if (ret) return ret; Patches currently in stable-queue which might be from bart.vanassche(a)wdc.com are queue-4.15/ib-core-fix-two-kernel-warnings-triggered-by-rxe-registration.patch queue-4.15/rdma-rxe-fix-a-race-condition-in-rxe_requester.patch queue-4.15/rdma-rxe-fix-rxe_qp_cleanup.patch queue-4.15/rdma-rxe-fix-a-race-condition-related-to-the-qp-error-state.patch

7 years, 7 months

1
0
0 0

Patch "IB/core: Fix ib_wc structure size to remain in 64 bytes boundary" has been added to the 4.15-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled IB/core: Fix ib_wc structure size to remain in 64 bytes boundary to the 4.15-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: ib-core-fix-ib_wc-structure-size-to-remain-in-64-bytes-boundary.patch and it can be found in the queue-4.15 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From cd2a6e7d384b043d5d029e39663061cebc949385 Mon Sep 17 00:00:00 2001 From: Bodong Wang <bodong(a)mellanox.com> Date: Fri, 12 Jan 2018 07:58:41 +0200 Subject: IB/core: Fix ib_wc structure size to remain in 64 bytes boundary From: Bodong Wang <bodong(a)mellanox.com> commit cd2a6e7d384b043d5d029e39663061cebc949385 upstream. The change of slid from u16 to u32 results in sizeof(struct ib_wc) cross 64B boundary, which causes more cache misses. This patch rearranges the fields and remain the size to 64B. Pahole output before this change: struct ib_wc { union { u64 wr_id; /* 8 */ struct ib_cqe * wr_cqe; /* 8 */ }; /* 0 8 */ enum ib_wc_status status; /* 8 4 */ enum ib_wc_opcode opcode; /* 12 4 */ u32 vendor_err; /* 16 4 */ u32 byte_len; /* 20 4 */ struct ib_qp * qp; /* 24 8 */ union { __be32 imm_data; /* 4 */ u32 invalidate_rkey; /* 4 */ } ex; /* 32 4 */ u32 src_qp; /* 36 4 */ int wc_flags; /* 40 4 */ u16 pkey_index; /* 44 2 */ /* XXX 2 bytes hole, try to pack */ u32 slid; /* 48 4 */ u8 sl; /* 52 1 */ u8 dlid_path_bits; /* 53 1 */ u8 port_num; /* 54 1 */ u8 smac[6]; /* 55 6 */ /* XXX 1 byte hole, try to pack */ u16 vlan_id; /* 62 2 */ /* --- cacheline 1 boundary (64 bytes) --- */ u8 network_hdr_type; /* 64 1 */ /* size: 72, cachelines: 2, members: 17 */ /* sum members: 62, holes: 2, sum holes: 3 */ /* padding: 7 */ /* last cacheline: 8 bytes */ }; Pahole output after this change: struct ib_wc { union { u64 wr_id; /* 8 */ struct ib_cqe * wr_cqe; /* 8 */ }; /* 0 8 */ enum ib_wc_status status; /* 8 4 */ enum ib_wc_opcode opcode; /* 12 4 */ u32 vendor_err; /* 16 4 */ u32 byte_len; /* 20 4 */ struct ib_qp * qp; /* 24 8 */ union { __be32 imm_data; /* 4 */ u32 invalidate_rkey; /* 4 */ } ex; /* 32 4 */ u32 src_qp; /* 36 4 */ u32 slid; /* 40 4 */ int wc_flags; /* 44 4 */ u16 pkey_index; /* 48 2 */ u8 sl; /* 50 1 */ u8 dlid_path_bits; /* 51 1 */ u8 port_num; /* 52 1 */ u8 smac[6]; /* 53 6 */ /* XXX 1 byte hole, try to pack */ u16 vlan_id; /* 60 2 */ u8 network_hdr_type; /* 62 1 */ /* size: 64, cachelines: 1, members: 17 */ /* sum members: 62, holes: 1, sum holes: 1 */ /* padding: 1 */ }; Fixes: 7db20ecd1d97 ("IB/core: Change wc.slid from 16 to 32 bits") Signed-off-by: Bodong Wang <bodong(a)mellanox.com> Reviewed-by: Parav Pandit <parav(a)mellanox.com> Signed-off-by: Leon Romanovsky <leon(a)kernel.org> Signed-off-by: Jason Gunthorpe <jgg(a)mellanox.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- include/rdma/ib_verbs.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/include/rdma/ib_verbs.h +++ b/include/rdma/ib_verbs.h @@ -983,9 +983,9 @@ struct ib_wc { u32 invalidate_rkey; } ex; u32 src_qp; + u32 slid; int wc_flags; u16 pkey_index; - u32 slid; u8 sl; u8 dlid_path_bits; u8 port_num; /* valid only for DR SMPs on switches */ Patches currently in stable-queue which might be from bodong(a)mellanox.com are queue-4.15/ib-core-fix-ib_wc-structure-size-to-remain-in-64-bytes-boundary.patch

7 years, 7 months

1
0
0 0

Patch "IB/core: Avoid a potential OOPs for an unused optional parameter" has been added to the 4.15-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled IB/core: Avoid a potential OOPs for an unused optional parameter to the 4.15-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: ib-core-avoid-a-potential-oops-for-an-unused-optional-parameter.patch and it can be found in the queue-4.15 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 2ff124d597c2df8696169ce0006fc974c49a4569 Mon Sep 17 00:00:00 2001 From: "Michael J. Ruhl" <michael.j.ruhl(a)intel.com> Date: Thu, 1 Feb 2018 12:31:06 -0800 Subject: IB/core: Avoid a potential OOPs for an unused optional parameter From: Michael J. Ruhl <michael.j.ruhl(a)intel.com> commit 2ff124d597c2df8696169ce0006fc974c49a4569 upstream. The ev_file is an optional parameter for CQ creation. If the parameter is not passed, the ev_file pointer will be NULL. Using that pointer to set the cq_context will result in an OOPs. Verify that ev_file is not NULL before using. Cc: <stable(a)vger.kernel.org> # 4.14.x Fixes: 9ee79fce3642 ("IB/core: Add completion queue (cq) object actions") Reviewed-by: Dennis Dalessandro <dennis.dalessandro(a)intel.com> Reviewed-by: Ira Weiny <ira.weiny(a)intel.com> Signed-off-by: Michael J. Ruhl <michael.j.ruhl(a)intel.com> Signed-off-by: Dennis Dalessandro <dennis.dalessandro(a)intel.com> Signed-off-by: Jason Gunthorpe <jgg(a)mellanox.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/infiniband/core/uverbs_std_types.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/infiniband/core/uverbs_std_types.c +++ b/drivers/infiniband/core/uverbs_std_types.c @@ -315,7 +315,7 @@ static int uverbs_create_cq_handler(stru cq->uobject = &obj->uobject; cq->comp_handler = ib_uverbs_comp_handler; cq->event_handler = ib_uverbs_cq_event_handler; - cq->cq_context = &ev_file->ev_queue; + cq->cq_context = ev_file ? &ev_file->ev_queue : NULL; obj->uobject.object = cq; obj->uobject.user_handle = user_handle; atomic_set(&cq->usecnt, 0); Patches currently in stable-queue which might be from michael.j.ruhl(a)intel.com are queue-4.15/ib-core-avoid-a-potential-oops-for-an-unused-optional-parameter.patch queue-4.15/ib-qib-fix-comparison-error-with-qperf-compare-swap-test.patch

7 years, 7 months

1
0
0 0

Patch "selftests: seccomp: fix compile error seccomp_bpf" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled selftests: seccomp: fix compile error seccomp_bpf to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: selftests-seccomp-fix-compile-error-seccomp_bpf.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 912ec316686df352028afb6efec59e47a958a24d Mon Sep 17 00:00:00 2001 From: Anders Roxell <anders.roxell(a)linaro.org> Date: Fri, 5 Jan 2018 17:31:18 +0100 Subject: selftests: seccomp: fix compile error seccomp_bpf From: Anders Roxell <anders.roxell(a)linaro.org> commit 912ec316686df352028afb6efec59e47a958a24d upstream. aarch64-linux-gnu-gcc -Wl,-no-as-needed -Wall -lpthread seccomp_bpf.c -o seccomp_bpf seccomp_bpf.c: In function 'tracer_ptrace': seccomp_bpf.c:1720:12: error: '__NR_open' undeclared (first use in this function) if (nr == __NR_open) ^~~~~~~~~ seccomp_bpf.c:1720:12: note: each undeclared identifier is reported only once for each function it appears in In file included from seccomp_bpf.c:48:0: seccomp_bpf.c: In function 'TRACE_syscall_ptrace_syscall_dropped': seccomp_bpf.c:1795:39: error: '__NR_open' undeclared (first use in this function) EXPECT_SYSCALL_RETURN(EPERM, syscall(__NR_open)); ^ open(2) is a legacy syscall, replaced with openat(2) since 2.6.16. Thus new architectures in the kernel, such as arm64, don't implement these legacy syscalls. Fixes: a33b2d0359a0 ("selftests/seccomp: Add tests for basic ptrace actions") Signed-off-by: Anders Roxell <anders.roxell(a)linaro.org> Tested-by: Naresh Kamboju <naresh.kamboju(a)linaro.org> Cc: stable(a)vger.kernel.org Acked-by: Kees Cook <keescook(a)chromium.org> Signed-off-by: Shuah Khan <shuahkh(a)osg.samsung.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- tools/testing/selftests/seccomp/seccomp_bpf.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) --- a/tools/testing/selftests/seccomp/seccomp_bpf.c +++ b/tools/testing/selftests/seccomp/seccomp_bpf.c @@ -1717,7 +1717,7 @@ void tracer_ptrace(struct __test_metadat if (nr == __NR_getpid) change_syscall(_metadata, tracee, __NR_getppid); - if (nr == __NR_open) + if (nr == __NR_openat) change_syscall(_metadata, tracee, -1); } @@ -1792,7 +1792,7 @@ TEST_F(TRACE_syscall, ptrace_syscall_dro true); /* Tracer should skip the open syscall, resulting in EPERM. */ - EXPECT_SYSCALL_RETURN(EPERM, syscall(__NR_open)); + EXPECT_SYSCALL_RETURN(EPERM, syscall(__NR_openat)); } TEST_F(TRACE_syscall, syscall_allowed) Patches currently in stable-queue which might be from anders.roxell(a)linaro.org are queue-4.14/selftests-seccomp-fix-compile-error-seccomp_bpf.patch

7 years, 7 months

1
0
0 0

Patch "RDMA/rxe: Fix rxe_qp_cleanup()" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled RDMA/rxe: Fix rxe_qp_cleanup() to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: rdma-rxe-fix-rxe_qp_cleanup.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From bb3ffb7ad48a21e98a5c64eb21103a74fd9f03f6 Mon Sep 17 00:00:00 2001 From: Bart Van Assche <bart.vanassche(a)wdc.com> Date: Fri, 12 Jan 2018 15:11:59 -0800 Subject: RDMA/rxe: Fix rxe_qp_cleanup() From: Bart Van Assche <bart.vanassche(a)wdc.com> commit bb3ffb7ad48a21e98a5c64eb21103a74fd9f03f6 upstream. rxe_qp_cleanup() can sleep so it must be run in thread context and not in atomic context. This patch avoids that the following bug is triggered: Kernel BUG at 00000000560033f3 [verbose debug info unavailable] BUG: sleeping function called from invalid context at net/core/sock.c:2761 in_atomic(): 1, irqs_disabled(): 0, pid: 7, name: ksoftirqd/0 INFO: lockdep is turned off. Preemption disabled at: [<00000000b6e69628>] __do_softirq+0x4e/0x540 CPU: 0 PID: 7 Comm: ksoftirqd/0 Not tainted 4.15.0-rc7-dbg+ #4 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.0.0-prebuilt.qemu-project.org 04/01/2014 Call Trace: dump_stack+0x85/0xbf ___might_sleep+0x177/0x260 lock_sock_nested+0x1d/0x90 inet_shutdown+0x2e/0xd0 rxe_qp_cleanup+0x107/0x140 [rdma_rxe] rxe_elem_release+0x18/0x80 [rdma_rxe] rxe_requester+0x1cf/0x11b0 [rdma_rxe] rxe_do_task+0x78/0xf0 [rdma_rxe] tasklet_action+0x99/0x270 __do_softirq+0xc0/0x540 run_ksoftirqd+0x1c/0x70 smpboot_thread_fn+0x1be/0x270 kthread+0x117/0x130 ret_from_fork+0x24/0x30 Signed-off-by: Bart Van Assche <bart.vanassche(a)wdc.com> Cc: Moni Shoua <monis(a)mellanox.com> Signed-off-by: Doug Ledford <dledford(a)redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/infiniband/sw/rxe/rxe_qp.c | 12 ++++++++++-- drivers/infiniband/sw/rxe/rxe_verbs.h | 3 +++ 2 files changed, 13 insertions(+), 2 deletions(-) --- a/drivers/infiniband/sw/rxe/rxe_qp.c +++ b/drivers/infiniband/sw/rxe/rxe_qp.c @@ -824,9 +824,9 @@ void rxe_qp_destroy(struct rxe_qp *qp) } /* called when the last reference to the qp is dropped */ -void rxe_qp_cleanup(struct rxe_pool_entry *arg) +static void rxe_qp_do_cleanup(struct work_struct *work) { - struct rxe_qp *qp = container_of(arg, typeof(*qp), pelem); + struct rxe_qp *qp = container_of(work, typeof(*qp), cleanup_work.work); rxe_drop_all_mcast_groups(qp); @@ -859,3 +859,11 @@ void rxe_qp_cleanup(struct rxe_pool_entr kernel_sock_shutdown(qp->sk, SHUT_RDWR); sock_release(qp->sk); } + +/* called when the last reference to the qp is dropped */ +void rxe_qp_cleanup(struct rxe_pool_entry *arg) +{ + struct rxe_qp *qp = container_of(arg, typeof(*qp), pelem); + + execute_in_process_context(rxe_qp_do_cleanup, &qp->cleanup_work); +} --- a/drivers/infiniband/sw/rxe/rxe_verbs.h +++ b/drivers/infiniband/sw/rxe/rxe_verbs.h @@ -35,6 +35,7 @@ #define RXE_VERBS_H #include <linux/interrupt.h> +#include <linux/workqueue.h> #include <rdma/rdma_user_rxe.h> #include "rxe_pool.h" #include "rxe_task.h" @@ -281,6 +282,8 @@ struct rxe_qp { struct timer_list rnr_nak_timer; spinlock_t state_lock; /* guard requester and completer */ + + struct execute_work cleanup_work; }; enum rxe_mem_state { Patches currently in stable-queue which might be from bart.vanassche(a)wdc.com are queue-4.14/ib-core-fix-two-kernel-warnings-triggered-by-rxe-registration.patch queue-4.14/rdma-rxe-fix-a-race-condition-in-rxe_requester.patch queue-4.14/rdma-rxe-fix-rxe_qp_cleanup.patch queue-4.14/rdma-rxe-fix-a-race-condition-related-to-the-qp-error-state.patch

7 years, 7 months

1
0
0 0

Patch "RDMA/rxe: Fix a race condition related to the QP error state" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled RDMA/rxe: Fix a race condition related to the QP error state to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: rdma-rxe-fix-a-race-condition-related-to-the-qp-error-state.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 6f301e06de4cf9ab7303f5acd43e64fcd4aa04be Mon Sep 17 00:00:00 2001 From: Bart Van Assche <bart.vanassche(a)wdc.com> Date: Tue, 9 Jan 2018 11:23:40 -0800 Subject: RDMA/rxe: Fix a race condition related to the QP error state From: Bart Van Assche <bart.vanassche(a)wdc.com> commit 6f301e06de4cf9ab7303f5acd43e64fcd4aa04be upstream. The following sequence: * Change queue pair state into IB_QPS_ERR. * Post a work request on the queue pair. Triggers the following race condition in the rdma_rxe driver: * rxe_qp_error() triggers an asynchronous call of rxe_completer(), the function that examines the QP send queue. * rxe_post_send() posts a work request on the QP send queue. If rxe_completer() runs prior to rxe_post_send(), it will drain the send queue and the driver will assume no further action is necessary. However, once we post the send to the send queue, because the queue is in error, no send completion will ever happen and the send will get stuck. In order to process the send, we need to make sure that rxe_completer() gets run after a send is posted to a queue pair in an error state. This patch ensures that happens. Signed-off-by: Bart Van Assche <bart.vanassche(a)wdc.com> Cc: Moni Shoua <monis(a)mellanox.com> Cc: <stable(a)vger.kernel.org> # v4.8 Signed-off-by: Doug Ledford <dledford(a)redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/infiniband/sw/rxe/rxe_verbs.c | 2 ++ 1 file changed, 2 insertions(+) --- a/drivers/infiniband/sw/rxe/rxe_verbs.c +++ b/drivers/infiniband/sw/rxe/rxe_verbs.c @@ -813,6 +813,8 @@ static int rxe_post_send_kernel(struct r (queue_count(qp->sq.queue) > 1); rxe_run_task(&qp->req.task, must_sched); + if (unlikely(qp->req.state == QP_STATE_ERROR)) + rxe_run_task(&qp->comp.task, 1); return err; } Patches currently in stable-queue which might be from bart.vanassche(a)wdc.com are queue-4.14/ib-core-fix-two-kernel-warnings-triggered-by-rxe-registration.patch queue-4.14/rdma-rxe-fix-a-race-condition-in-rxe_requester.patch queue-4.14/rdma-rxe-fix-rxe_qp_cleanup.patch queue-4.14/rdma-rxe-fix-a-race-condition-related-to-the-qp-error-state.patch

7 years, 7 months

1
0
0 0

Patch "RDMA/rxe: Fix a race condition in rxe_requester()" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled RDMA/rxe: Fix a race condition in rxe_requester() to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: rdma-rxe-fix-a-race-condition-in-rxe_requester.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 65567e41219888feec72fee1de98ccf1efbbc16d Mon Sep 17 00:00:00 2001 From: Bart Van Assche <bart.vanassche(a)wdc.com> Date: Fri, 12 Jan 2018 15:11:58 -0800 Subject: RDMA/rxe: Fix a race condition in rxe_requester() From: Bart Van Assche <bart.vanassche(a)wdc.com> commit 65567e41219888feec72fee1de98ccf1efbbc16d upstream. The rxe driver works as follows: * The send queue, receive queue and completion queues are implemented as circular buffers. * ib_post_send() and ib_post_recv() calls are serialized through a spinlock. * Removing elements from various queues happens from tasklet context. Tasklets are guaranteed to run on at most one CPU. This serializes access to these queues. See also rxe_completer(), rxe_requester() and rxe_responder(). * rxe_completer() processes the skbs queued onto qp->resp_pkts. * rxe_requester() handles the send queue (qp->sq.queue). * rxe_responder() processes the skbs queued onto qp->req_pkts. Since rxe_drain_req_pkts() processes qp->req_pkts, calling rxe_drain_req_pkts() from rxe_requester() is racy. Hence this patch. Reported-by: Moni Shoua <monis(a)mellanox.com> Signed-off-by: Bart Van Assche <bart.vanassche(a)wdc.com> Cc: stable(a)vger.kernel.org Signed-off-by: Doug Ledford <dledford(a)redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/infiniband/sw/rxe/rxe_loc.h | 1 - drivers/infiniband/sw/rxe/rxe_req.c | 9 +-------- drivers/infiniband/sw/rxe/rxe_resp.c | 2 +- 3 files changed, 2 insertions(+), 10 deletions(-) --- a/drivers/infiniband/sw/rxe/rxe_loc.h +++ b/drivers/infiniband/sw/rxe/rxe_loc.h @@ -237,7 +237,6 @@ int rxe_srq_from_attr(struct rxe_dev *rx void rxe_release(struct kref *kref); -void rxe_drain_req_pkts(struct rxe_qp *qp, bool notify); int rxe_completer(void *arg); int rxe_requester(void *arg); int rxe_responder(void *arg); --- a/drivers/infiniband/sw/rxe/rxe_req.c +++ b/drivers/infiniband/sw/rxe/rxe_req.c @@ -594,15 +594,8 @@ int rxe_requester(void *arg) rxe_add_ref(qp); next_wqe: - if (unlikely(!qp->valid)) { - rxe_drain_req_pkts(qp, true); + if (unlikely(!qp->valid || qp->req.state == QP_STATE_ERROR)) goto exit; - } - - if (unlikely(qp->req.state == QP_STATE_ERROR)) { - rxe_drain_req_pkts(qp, true); - goto exit; - } if (unlikely(qp->req.state == QP_STATE_RESET)) { qp->req.wqe_index = consumer_index(qp->sq.queue); --- a/drivers/infiniband/sw/rxe/rxe_resp.c +++ b/drivers/infiniband/sw/rxe/rxe_resp.c @@ -1210,7 +1210,7 @@ static enum resp_states do_class_d1e_err } } -void rxe_drain_req_pkts(struct rxe_qp *qp, bool notify) +static void rxe_drain_req_pkts(struct rxe_qp *qp, bool notify) { struct sk_buff *skb; Patches currently in stable-queue which might be from bart.vanassche(a)wdc.com are queue-4.14/ib-core-fix-two-kernel-warnings-triggered-by-rxe-registration.patch queue-4.14/rdma-rxe-fix-a-race-condition-in-rxe_requester.patch queue-4.14/rdma-rxe-fix-rxe_qp_cleanup.patch queue-4.14/rdma-rxe-fix-a-race-condition-related-to-the-qp-error-state.patch

7 years, 7 months

1
0
0 0

Patch "kselftest: fix OOM in memory compaction test" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled kselftest: fix OOM in memory compaction test to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: kselftest-fix-oom-in-memory-compaction-test.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 4c1baad223906943b595a887305f2e8124821dad Mon Sep 17 00:00:00 2001 From: Arnd Bergmann <arnd(a)arndb.de> Date: Tue, 9 Jan 2018 17:26:24 +0100 Subject: kselftest: fix OOM in memory compaction test From: Arnd Bergmann <arnd(a)arndb.de> commit 4c1baad223906943b595a887305f2e8124821dad upstream. Running the compaction_test sometimes results in out-of-memory failures. When I debugged this, it turned out that the code to reset the number of hugepages to the initial value is simply broken since we write into an open sysctl file descriptor multiple times without seeking back to the start. Adding the lseek here fixes the problem. Cc: stable(a)vger.kernel.org Reported-by: Naresh Kamboju <naresh.kamboju(a)linaro.org> Link: https://bugs.linaro.org/show_bug.cgi?id=3145 Signed-off-by: Arnd Bergmann <arnd(a)arndb.de> Signed-off-by: Shuah Khan <shuahkh(a)osg.samsung.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- tools/testing/selftests/vm/compaction_test.c | 2 ++ 1 file changed, 2 insertions(+) --- a/tools/testing/selftests/vm/compaction_test.c +++ b/tools/testing/selftests/vm/compaction_test.c @@ -137,6 +137,8 @@ int check_compaction(unsigned long mem_f printf("No of huge pages allocated = %d\n", (atoi(nr_hugepages))); + lseek(fd, 0, SEEK_SET); + if (write(fd, initial_nr_hugepages, strlen(initial_nr_hugepages)) != strlen(initial_nr_hugepages)) { perror("Failed to write value to /proc/sys/vm/nr_hugepages\n"); Patches currently in stable-queue which might be from arnd(a)arndb.de are queue-4.14/kselftest-fix-oom-in-memory-compaction-test.patch queue-4.14/tracing-prevent-profile_all_branches-when-fortify_source-y.patch

7 years, 7 months

1
0
0 0

Patch "IB/umad: Fix use of unprotected device pointer" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled IB/umad: Fix use of unprotected device pointer to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: ib-umad-fix-use-of-unprotected-device-pointer.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From f23a5350e43c810ca36b26d4ed4ecd9a08686f47 Mon Sep 17 00:00:00 2001 From: Jack Morgenstein <jackm(a)dev.mellanox.co.il> Date: Sun, 28 Jan 2018 11:25:29 +0200 Subject: IB/umad: Fix use of unprotected device pointer From: Jack Morgenstein <jackm(a)dev.mellanox.co.il> commit f23a5350e43c810ca36b26d4ed4ecd9a08686f47 upstream. The ib_write_umad() is protected by taking the umad file mutex. However, it accesses file->port->ib_dev -- which is protected only by the port's mutex (field file_mutex). The ib_umad_remove_one() calls ib_umad_kill_port() which sets port->ib_dev to NULL under the port mutex (NOT the file mutex). It then sets the mad agent to "dead" under the umad file mutex. This is a race condition -- because there is a window where port->ib_dev is NULL, while the agent is not "dead". As a result, we saw stack traces like: [16490.678059] BUG: unable to handle kernel NULL pointer dereference at 00000000000000b0 [16490.678246] IP: ib_umad_write+0x29c/0xa3a [ib_umad] [16490.678333] PGD 0 P4D 0 [16490.678404] Oops: 0000 [#1] SMP PTI [16490.678466] Modules linked in: rdma_ucm(OE) ib_ucm(OE) rdma_cm(OE) iw_cm(OE) ib_ipoib(OE) ib_cm(OE) ib_uverbs(OE) ib_umad(OE) mlx4_en(OE) ptp pps_core mlx4_ib(OE-) ib_core(OE) mlx4_core(OE) mlx_compat (OE) memtrack(OE) devlink mst_pciconf(OE) mst_pci(OE) netconsole nfsv3 nfs_acl nfs lockd grace fscache cfg80211 rfkill esp6_offload esp6 esp4_offload esp4 sunrpc kvm_intel kvm ppdev parport_pc irqbypass parport joydev i2c_piix4 virtio_balloon cirrus drm_kms_helper ttm drm e1000 serio_raw virtio_pci virtio_ring virtio ata_generic pata_acpi qemu_fw_cfg [last unloaded: mlxfw] [16490.679202] CPU: 4 PID: 3115 Comm: sminfo Tainted: G OE 4.14.13-300.fc27.x86_64 #1 [16490.679339] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Ubuntu-1.8.2-1ubuntu2 04/01/2014 [16490.679477] task: ffff9cf753890000 task.stack: ffffaf70c26b0000 [16490.679571] RIP: 0010:ib_umad_write+0x29c/0xa3a [ib_umad] [16490.679664] RSP: 0018:ffffaf70c26b3d90 EFLAGS: 00010202 [16490.679747] RAX: 0000000000000010 RBX: ffff9cf75610fd80 RCX: 0000000000000000 [16490.679856] RDX: 0000000000000001 RSI: 00007ffdf2bfd714 RDI: ffff9cf6bb2a9c00 In the above trace, ib_umad_write is trying to dereference the NULL file->port->ib_dev pointer. Fix this by using the agent's device pointer (the device field in struct ib_mad_agent) -- which IS protected by the umad file mutex. Fixes: 44c58487d51a ("IB/core: Define 'ib' and 'roce' rdma_ah_attr types") Signed-off-by: Jack Morgenstein <jackm(a)dev.mellanox.co.il> Signed-off-by: Leon Romanovsky <leon(a)kernel.org> Signed-off-by: Jason Gunthorpe <jgg(a)mellanox.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/infiniband/core/user_mad.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/infiniband/core/user_mad.c +++ b/drivers/infiniband/core/user_mad.c @@ -500,7 +500,7 @@ static ssize_t ib_umad_write(struct file } memset(&ah_attr, 0, sizeof ah_attr); - ah_attr.type = rdma_ah_find_type(file->port->ib_dev, + ah_attr.type = rdma_ah_find_type(agent->device, file->port->port_num); rdma_ah_set_dlid(&ah_attr, be16_to_cpu(packet->mad.hdr.lid)); rdma_ah_set_sl(&ah_attr, packet->mad.hdr.sl); Patches currently in stable-queue which might be from jackm(a)dev.mellanox.co.il are queue-4.14/ib-mlx4-fix-incorrectly-releasing-steerable-ud-qps-when-have-only-eth-ports.patch queue-4.14/ib-umad-fix-use-of-unprotected-device-pointer.patch

7 years, 7 months

1
0
0 0

Patch "IB/qib: Fix comparison error with qperf compare/swap test" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled IB/qib: Fix comparison error with qperf compare/swap test to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: ib-qib-fix-comparison-error-with-qperf-compare-swap-test.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 87b3524cb5058fdc7c2afdb92bdb2e079661ddc4 Mon Sep 17 00:00:00 2001 From: Mike Marciniszyn <mike.marciniszyn(a)intel.com> Date: Tue, 14 Nov 2017 04:34:52 -0800 Subject: IB/qib: Fix comparison error with qperf compare/swap test From: Mike Marciniszyn <mike.marciniszyn(a)intel.com> commit 87b3524cb5058fdc7c2afdb92bdb2e079661ddc4 upstream. This failure exists with qib: ver_rc_compare_swap: mismatch, sequence 2, expected 123456789abcdef, got 0 The request builder was using the incorrect inlines to build the request header resulting in incorrect data in the atomic header. Fix by using the appropriate inlines to create the request. Fixes: 261a4351844b ("IB/qib,IB/hfi: Use core common header file") Reviewed-by: Michael J. Ruhl <michael.j.ruhl(a)intel.com> Signed-off-by: Mike Marciniszyn <mike.marciniszyn(a)intel.com> Signed-off-by: Dennis Dalessandro <dennis.dalessandro(a)intel.com> Signed-off-by: Jason Gunthorpe <jgg(a)mellanox.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/infiniband/hw/qib/qib_rc.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) --- a/drivers/infiniband/hw/qib/qib_rc.c +++ b/drivers/infiniband/hw/qib/qib_rc.c @@ -434,13 +434,13 @@ no_flow_control: qp->s_state = OP(COMPARE_SWAP); put_ib_ateth_swap(wqe->atomic_wr.swap, &ohdr->u.atomic_eth); - put_ib_ateth_swap(wqe->atomic_wr.compare_add, - &ohdr->u.atomic_eth); + put_ib_ateth_compare(wqe->atomic_wr.compare_add, + &ohdr->u.atomic_eth); } else { qp->s_state = OP(FETCH_ADD); put_ib_ateth_swap(wqe->atomic_wr.compare_add, &ohdr->u.atomic_eth); - put_ib_ateth_swap(0, &ohdr->u.atomic_eth); + put_ib_ateth_compare(0, &ohdr->u.atomic_eth); } put_ib_ateth_vaddr(wqe->atomic_wr.remote_addr, &ohdr->u.atomic_eth); Patches currently in stable-queue which might be from mike.marciniszyn(a)intel.com are queue-4.14/ib-qib-fix-comparison-error-with-qperf-compare-swap-test.patch

7 years, 7 months

1
0
0 0

Patch "IB/mlx4: Fix incorrectly releasing steerable UD QPs when have only ETH ports" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled IB/mlx4: Fix incorrectly releasing steerable UD QPs when have only ETH ports to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: ib-mlx4-fix-incorrectly-releasing-steerable-ud-qps-when-have-only-eth-ports.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 852f6927594d0d3e8632c889b2ab38cbc46476ad Mon Sep 17 00:00:00 2001 From: Jack Morgenstein <jackm(a)dev.mellanox.co.il> Date: Fri, 12 Jan 2018 07:58:40 +0200 Subject: IB/mlx4: Fix incorrectly releasing steerable UD QPs when have only ETH ports From: Jack Morgenstein <jackm(a)dev.mellanox.co.il> commit 852f6927594d0d3e8632c889b2ab38cbc46476ad upstream. Allocating steerable UD QPs depends on having at least one IB port, while releasing those QPs does not. As a result, when there are only ETH ports, the IB (RoCE) driver requests releasing a qp range whose base qp is zero, with qp count zero. When SR-IOV is enabled, and the VF driver is running on a VM over a hypervisor which treats such qp release calls as errors (rather than NOPs), we see lines in the VM message log like: mlx4_core 0002:00:02.0: Failed to release qp range base:0 cnt:0 Fix this by adding a check for a zero count in mlx4_release_qp_range() (which thus treats releasing 0 qps as a nop), and eliminating the check for device managed flow steering when releasing steerable UD QPs. (Freeing ib_uc_qpns_bitmap unconditionally is also OK, since it remains NULL when steerable UD QPs are not allocated). Fixes: 4196670be786 ("IB/mlx4: Don't allocate range of steerable UD QPs for Ethernet-only device") Signed-off-by: Jack Morgenstein <jackm(a)dev.mellanox.co.il> Signed-off-by: Leon Romanovsky <leon(a)kernel.org> Signed-off-by: Jason Gunthorpe <jgg(a)mellanox.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/infiniband/hw/mlx4/main.c | 13 +++++-------- drivers/net/ethernet/mellanox/mlx4/qp.c | 3 +++ 2 files changed, 8 insertions(+), 8 deletions(-) --- a/drivers/infiniband/hw/mlx4/main.c +++ b/drivers/infiniband/hw/mlx4/main.c @@ -2972,9 +2972,8 @@ err_steer_free_bitmap: kfree(ibdev->ib_uc_qpns_bitmap); err_steer_qp_release: - if (ibdev->steering_support == MLX4_STEERING_MODE_DEVICE_MANAGED) - mlx4_qp_release_range(dev, ibdev->steer_qpn_base, - ibdev->steer_qpn_count); + mlx4_qp_release_range(dev, ibdev->steer_qpn_base, + ibdev->steer_qpn_count); err_counter: for (i = 0; i < ibdev->num_ports; ++i) mlx4_ib_delete_counters_table(ibdev, &ibdev->counters_table[i]); @@ -3079,11 +3078,9 @@ static void mlx4_ib_remove(struct mlx4_d ibdev->iboe.nb.notifier_call = NULL; } - if (ibdev->steering_support == MLX4_STEERING_MODE_DEVICE_MANAGED) { - mlx4_qp_release_range(dev, ibdev->steer_qpn_base, - ibdev->steer_qpn_count); - kfree(ibdev->ib_uc_qpns_bitmap); - } + mlx4_qp_release_range(dev, ibdev->steer_qpn_base, + ibdev->steer_qpn_count); + kfree(ibdev->ib_uc_qpns_bitmap); iounmap(ibdev->uar_map); for (p = 0; p < ibdev->num_ports; ++p) --- a/drivers/net/ethernet/mellanox/mlx4/qp.c +++ b/drivers/net/ethernet/mellanox/mlx4/qp.c @@ -287,6 +287,9 @@ void mlx4_qp_release_range(struct mlx4_d u64 in_param = 0; int err; + if (!cnt) + return; + if (mlx4_is_mfunc(dev)) { set_param_l(&in_param, base_qpn); set_param_h(&in_param, cnt); Patches currently in stable-queue which might be from jackm(a)dev.mellanox.co.il are queue-4.14/ib-mlx4-fix-incorrectly-releasing-steerable-ud-qps-when-have-only-eth-ports.patch queue-4.14/ib-umad-fix-use-of-unprotected-device-pointer.patch

7 years, 7 months

1
0
0 0

Patch "IB/core: Fix two kernel warnings triggered by rxe registration" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled IB/core: Fix two kernel warnings triggered by rxe registration to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: ib-core-fix-two-kernel-warnings-triggered-by-rxe-registration.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 02ee9da347873699603d9ce0112a80b5dd69dea1 Mon Sep 17 00:00:00 2001 From: Bart Van Assche <bart.vanassche(a)wdc.com> Date: Wed, 3 Jan 2018 13:28:18 -0800 Subject: IB/core: Fix two kernel warnings triggered by rxe registration From: Bart Van Assche <bart.vanassche(a)wdc.com> commit 02ee9da347873699603d9ce0112a80b5dd69dea1 upstream. Eliminate the WARN_ONs that create following two warnings when registering an rxe device: WARNING: CPU: 2 PID: 1005 at drivers/infiniband/core/device.c:449 ib_register_device+0x591/0x640 [ib_core] CPU: 2 PID: 1005 Comm: run_tests Not tainted 4.15.0-rc4-dbg+ #2 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.0.0-prebuilt.qemu-project.org 04/01/2014 RIP: 0010:ib_register_device+0x591/0x640 [ib_core] Call Trace: rxe_register_device+0x3c6/0x470 [rdma_rxe] rxe_add+0x543/0x5e0 [rdma_rxe] rxe_net_add+0x37/0xb0 [rdma_rxe] rxe_param_set_add+0x5a/0x120 [rdma_rxe] param_attr_store+0x5e/0xc0 module_attr_store+0x19/0x30 sysfs_kf_write+0x3d/0x50 kernfs_fop_write+0x116/0x1a0 __vfs_write+0x23/0x120 vfs_write+0xbe/0x1b0 SyS_write+0x44/0xa0 entry_SYSCALL_64_fastpath+0x23/0x9a WARNING: CPU: 2 PID: 1005 at drivers/infiniband/core/sysfs.c:1279 ib_device_register_sysfs+0x11d/0x160 [ib_core] CPU: 2 PID: 1005 Comm: run_tests Tainted: G W 4.15.0-rc4-dbg+ #2 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.0.0-prebuilt.qemu-project.org 04/01/2014 RIP: 0010:ib_device_register_sysfs+0x11d/0x160 [ib_core] Call Trace: ib_register_device+0x3f7/0x640 [ib_core] rxe_register_device+0x3c6/0x470 [rdma_rxe] rxe_add+0x543/0x5e0 [rdma_rxe] rxe_net_add+0x37/0xb0 [rdma_rxe] rxe_param_set_add+0x5a/0x120 [rdma_rxe] param_attr_store+0x5e/0xc0 module_attr_store+0x19/0x30 sysfs_kf_write+0x3d/0x50 kernfs_fop_write+0x116/0x1a0 __vfs_write+0x23/0x120 vfs_write+0xbe/0x1b0 SyS_write+0x44/0xa0 entry_SYSCALL_64_fastpath+0x23/0x9a The code should accept either a parent pointer or a fully specified DMA specification without producing warnings. Fixes: 99db9494035f ("IB/core: Remove ib_device.dma_device") Signed-off-by: Bart Van Assche <bart.vanassche(a)wdc.com> Cc: Leon Romanovsky <leon(a)kernel.org> Signed-off-by: Jason Gunthorpe <jgg(a)mellanox.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/infiniband/core/device.c | 20 ++++++++++++++------ drivers/infiniband/core/sysfs.c | 1 - 2 files changed, 14 insertions(+), 7 deletions(-) --- a/drivers/infiniband/core/device.c +++ b/drivers/infiniband/core/device.c @@ -446,7 +446,6 @@ int ib_register_device(struct ib_device struct ib_udata uhw = {.outlen = 0, .inlen = 0}; struct device *parent = device->dev.parent; - WARN_ON_ONCE(!parent); WARN_ON_ONCE(device->dma_device); if (device->dev.dma_ops) { /* @@ -455,16 +454,25 @@ int ib_register_device(struct ib_device * into device->dev. */ device->dma_device = &device->dev; - if (!device->dev.dma_mask) - device->dev.dma_mask = parent->dma_mask; - if (!device->dev.coherent_dma_mask) - device->dev.coherent_dma_mask = - parent->coherent_dma_mask; + if (!device->dev.dma_mask) { + if (parent) + device->dev.dma_mask = parent->dma_mask; + else + WARN_ON_ONCE(true); + } + if (!device->dev.coherent_dma_mask) { + if (parent) + device->dev.coherent_dma_mask = + parent->coherent_dma_mask; + else + WARN_ON_ONCE(true); + } } else { /* * The caller did not provide custom DMA operations. Use the * DMA mapping operations of the parent device. */ + WARN_ON_ONCE(!parent); device->dma_device = parent; } --- a/drivers/infiniband/core/sysfs.c +++ b/drivers/infiniband/core/sysfs.c @@ -1262,7 +1262,6 @@ int ib_device_register_sysfs(struct ib_d int ret; int i; - WARN_ON_ONCE(!device->dev.parent); ret = dev_set_name(class_dev, "%s", device->name); if (ret) return ret; Patches currently in stable-queue which might be from bart.vanassche(a)wdc.com are queue-4.14/ib-core-fix-two-kernel-warnings-triggered-by-rxe-registration.patch queue-4.14/rdma-rxe-fix-a-race-condition-in-rxe_requester.patch queue-4.14/rdma-rxe-fix-rxe_qp_cleanup.patch queue-4.14/rdma-rxe-fix-a-race-condition-related-to-the-qp-error-state.patch

7 years, 7 months

1
0
0 0

Patch "IB/core: Fix ib_wc structure size to remain in 64 bytes boundary" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled IB/core: Fix ib_wc structure size to remain in 64 bytes boundary to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: ib-core-fix-ib_wc-structure-size-to-remain-in-64-bytes-boundary.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From cd2a6e7d384b043d5d029e39663061cebc949385 Mon Sep 17 00:00:00 2001 From: Bodong Wang <bodong(a)mellanox.com> Date: Fri, 12 Jan 2018 07:58:41 +0200 Subject: IB/core: Fix ib_wc structure size to remain in 64 bytes boundary From: Bodong Wang <bodong(a)mellanox.com> commit cd2a6e7d384b043d5d029e39663061cebc949385 upstream. The change of slid from u16 to u32 results in sizeof(struct ib_wc) cross 64B boundary, which causes more cache misses. This patch rearranges the fields and remain the size to 64B. Pahole output before this change: struct ib_wc { union { u64 wr_id; /* 8 */ struct ib_cqe * wr_cqe; /* 8 */ }; /* 0 8 */ enum ib_wc_status status; /* 8 4 */ enum ib_wc_opcode opcode; /* 12 4 */ u32 vendor_err; /* 16 4 */ u32 byte_len; /* 20 4 */ struct ib_qp * qp; /* 24 8 */ union { __be32 imm_data; /* 4 */ u32 invalidate_rkey; /* 4 */ } ex; /* 32 4 */ u32 src_qp; /* 36 4 */ int wc_flags; /* 40 4 */ u16 pkey_index; /* 44 2 */ /* XXX 2 bytes hole, try to pack */ u32 slid; /* 48 4 */ u8 sl; /* 52 1 */ u8 dlid_path_bits; /* 53 1 */ u8 port_num; /* 54 1 */ u8 smac[6]; /* 55 6 */ /* XXX 1 byte hole, try to pack */ u16 vlan_id; /* 62 2 */ /* --- cacheline 1 boundary (64 bytes) --- */ u8 network_hdr_type; /* 64 1 */ /* size: 72, cachelines: 2, members: 17 */ /* sum members: 62, holes: 2, sum holes: 3 */ /* padding: 7 */ /* last cacheline: 8 bytes */ }; Pahole output after this change: struct ib_wc { union { u64 wr_id; /* 8 */ struct ib_cqe * wr_cqe; /* 8 */ }; /* 0 8 */ enum ib_wc_status status; /* 8 4 */ enum ib_wc_opcode opcode; /* 12 4 */ u32 vendor_err; /* 16 4 */ u32 byte_len; /* 20 4 */ struct ib_qp * qp; /* 24 8 */ union { __be32 imm_data; /* 4 */ u32 invalidate_rkey; /* 4 */ } ex; /* 32 4 */ u32 src_qp; /* 36 4 */ u32 slid; /* 40 4 */ int wc_flags; /* 44 4 */ u16 pkey_index; /* 48 2 */ u8 sl; /* 50 1 */ u8 dlid_path_bits; /* 51 1 */ u8 port_num; /* 52 1 */ u8 smac[6]; /* 53 6 */ /* XXX 1 byte hole, try to pack */ u16 vlan_id; /* 60 2 */ u8 network_hdr_type; /* 62 1 */ /* size: 64, cachelines: 1, members: 17 */ /* sum members: 62, holes: 1, sum holes: 1 */ /* padding: 1 */ }; Fixes: 7db20ecd1d97 ("IB/core: Change wc.slid from 16 to 32 bits") Signed-off-by: Bodong Wang <bodong(a)mellanox.com> Reviewed-by: Parav Pandit <parav(a)mellanox.com> Signed-off-by: Leon Romanovsky <leon(a)kernel.org> Signed-off-by: Jason Gunthorpe <jgg(a)mellanox.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- include/rdma/ib_verbs.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/include/rdma/ib_verbs.h +++ b/include/rdma/ib_verbs.h @@ -971,9 +971,9 @@ struct ib_wc { u32 invalidate_rkey; } ex; u32 src_qp; + u32 slid; int wc_flags; u16 pkey_index; - u32 slid; u8 sl; u8 dlid_path_bits; u8 port_num; /* valid only for DR SMPs on switches */ Patches currently in stable-queue which might be from bodong(a)mellanox.com are queue-4.14/ib-core-fix-ib_wc-structure-size-to-remain-in-64-bytes-boundary.patch

7 years, 7 months

1
0
0 0

Patch "IB/core: Avoid a potential OOPs for an unused optional parameter" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled IB/core: Avoid a potential OOPs for an unused optional parameter to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: ib-core-avoid-a-potential-oops-for-an-unused-optional-parameter.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 2ff124d597c2df8696169ce0006fc974c49a4569 Mon Sep 17 00:00:00 2001 From: "Michael J. Ruhl" <michael.j.ruhl(a)intel.com> Date: Thu, 1 Feb 2018 12:31:06 -0800 Subject: IB/core: Avoid a potential OOPs for an unused optional parameter From: Michael J. Ruhl <michael.j.ruhl(a)intel.com> commit 2ff124d597c2df8696169ce0006fc974c49a4569 upstream. The ev_file is an optional parameter for CQ creation. If the parameter is not passed, the ev_file pointer will be NULL. Using that pointer to set the cq_context will result in an OOPs. Verify that ev_file is not NULL before using. Cc: <stable(a)vger.kernel.org> # 4.14.x Fixes: 9ee79fce3642 ("IB/core: Add completion queue (cq) object actions") Reviewed-by: Dennis Dalessandro <dennis.dalessandro(a)intel.com> Reviewed-by: Ira Weiny <ira.weiny(a)intel.com> Signed-off-by: Michael J. Ruhl <michael.j.ruhl(a)intel.com> Signed-off-by: Dennis Dalessandro <dennis.dalessandro(a)intel.com> Signed-off-by: Jason Gunthorpe <jgg(a)mellanox.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/infiniband/core/uverbs_std_types.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/infiniband/core/uverbs_std_types.c +++ b/drivers/infiniband/core/uverbs_std_types.c @@ -315,7 +315,7 @@ static int uverbs_create_cq_handler(stru cq->uobject = &obj->uobject; cq->comp_handler = ib_uverbs_comp_handler; cq->event_handler = ib_uverbs_cq_event_handler; - cq->cq_context = &ev_file->ev_queue; + cq->cq_context = ev_file ? &ev_file->ev_queue : NULL; obj->uobject.object = cq; obj->uobject.user_handle = user_handle; atomic_set(&cq->usecnt, 0); Patches currently in stable-queue which might be from michael.j.ruhl(a)intel.com are queue-4.14/ib-core-avoid-a-potential-oops-for-an-unused-optional-parameter.patch queue-4.14/ib-qib-fix-comparison-error-with-qperf-compare-swap-test.patch

7 years, 7 months

1
0
0 0

Patch "IB/mlx4: Fix incorrectly releasing steerable UD QPs when have only ETH ports" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled IB/mlx4: Fix incorrectly releasing steerable UD QPs when have only ETH ports to the 3.18-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: ib-mlx4-fix-incorrectly-releasing-steerable-ud-qps-when-have-only-eth-ports.patch and it can be found in the queue-3.18 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 852f6927594d0d3e8632c889b2ab38cbc46476ad Mon Sep 17 00:00:00 2001 From: Jack Morgenstein <jackm(a)dev.mellanox.co.il> Date: Fri, 12 Jan 2018 07:58:40 +0200 Subject: IB/mlx4: Fix incorrectly releasing steerable UD QPs when have only ETH ports From: Jack Morgenstein <jackm(a)dev.mellanox.co.il> commit 852f6927594d0d3e8632c889b2ab38cbc46476ad upstream. Allocating steerable UD QPs depends on having at least one IB port, while releasing those QPs does not. As a result, when there are only ETH ports, the IB (RoCE) driver requests releasing a qp range whose base qp is zero, with qp count zero. When SR-IOV is enabled, and the VF driver is running on a VM over a hypervisor which treats such qp release calls as errors (rather than NOPs), we see lines in the VM message log like: mlx4_core 0002:00:02.0: Failed to release qp range base:0 cnt:0 Fix this by adding a check for a zero count in mlx4_release_qp_range() (which thus treats releasing 0 qps as a nop), and eliminating the check for device managed flow steering when releasing steerable UD QPs. (Freeing ib_uc_qpns_bitmap unconditionally is also OK, since it remains NULL when steerable UD QPs are not allocated). Fixes: 4196670be786 ("IB/mlx4: Don't allocate range of steerable UD QPs for Ethernet-only device") Signed-off-by: Jack Morgenstein <jackm(a)dev.mellanox.co.il> Signed-off-by: Leon Romanovsky <leon(a)kernel.org> Signed-off-by: Jason Gunthorpe <jgg(a)mellanox.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/infiniband/hw/mlx4/main.c | 13 +++++-------- drivers/net/ethernet/mellanox/mlx4/qp.c | 3 +++ 2 files changed, 8 insertions(+), 8 deletions(-) --- a/drivers/infiniband/hw/mlx4/main.c +++ b/drivers/infiniband/hw/mlx4/main.c @@ -2348,9 +2348,8 @@ err_steer_free_bitmap: kfree(ibdev->ib_uc_qpns_bitmap); err_steer_qp_release: - if (ibdev->steering_support == MLX4_STEERING_MODE_DEVICE_MANAGED) - mlx4_qp_release_range(dev, ibdev->steer_qpn_base, - ibdev->steer_qpn_count); + mlx4_qp_release_range(dev, ibdev->steer_qpn_base, + ibdev->steer_qpn_count); err_counter: for (; i; --i) if (ibdev->counters[i - 1] != -1) @@ -2452,11 +2451,9 @@ static void mlx4_ib_remove(struct mlx4_d ibdev->iboe.nb.notifier_call = NULL; } - if (ibdev->steering_support == MLX4_STEERING_MODE_DEVICE_MANAGED) { - mlx4_qp_release_range(dev, ibdev->steer_qpn_base, - ibdev->steer_qpn_count); - kfree(ibdev->ib_uc_qpns_bitmap); - } + mlx4_qp_release_range(dev, ibdev->steer_qpn_base, + ibdev->steer_qpn_count); + kfree(ibdev->ib_uc_qpns_bitmap); if (ibdev->iboe.nb_inet.notifier_call) { if (unregister_inetaddr_notifier(&ibdev->iboe.nb_inet)) --- a/drivers/net/ethernet/mellanox/mlx4/qp.c +++ b/drivers/net/ethernet/mellanox/mlx4/qp.c @@ -257,6 +257,9 @@ void mlx4_qp_release_range(struct mlx4_d u64 in_param = 0; int err; + if (!cnt) + return; + if (mlx4_is_mfunc(dev)) { set_param_l(&in_param, base_qpn); set_param_h(&in_param, cnt); Patches currently in stable-queue which might be from jackm(a)dev.mellanox.co.il are queue-3.18/ib-mlx4-fix-incorrectly-releasing-steerable-ud-qps-when-have-only-eth-ports.patch

7 years, 7 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror