This is a note to let you know that I've just added the patch titled
ARM: OMAP: Fix SRAM W+X mapping
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-omap-fix-sram-w-x-mapping.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 eb85a355c3afd9379f5953cfe2df73632d14c884 Mon Sep 17 00:00:00 2001
From: Tony Lindgren <tony(a)atomide.com>
Date: Wed, 21 Mar 2018 08:16:29 -0700
Subject: ARM: OMAP: Fix SRAM W+X mapping
From: Tony Lindgren <tony(a)atomide.com>
commit eb85a355c3afd9379f5953cfe2df73632d14c884 upstream.
We are still using custom SRAM code for some SoCs and are not marking
the PM code mapped to SRAM as read-only and executable after we're
done. With CONFIG_DEBUG_WX=y, we will get "Found insecure W+X mapping
at address" warning.
Let's fix this issue the same way as commit 728bbe75c82f ("misc: sram:
Introduce support code for protect-exec sram type") is doing for
drivers/misc/sram-exec.c.
On omap3, we need to restore SRAM when returning from off mode after
idle, so init time configuration is not enough.
And as we no longer have users for omap_sram_push_address() we can
make it static while at it.
Note that eventually we should be using sram-exec.c for all SoCs.
Cc: stable(a)vger.kernel.org # v4.12+
Cc: Dave Gerlach <d-gerlach(a)ti.com>
Reported-by: Pavel Machek <pavel(a)ucw.cz>
Signed-off-by: Tony Lindgren <tony(a)atomide.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/arm/plat-omap/include/plat/sram.h | 11 ----------
arch/arm/plat-omap/sram.c | 36 ++++++++++++++++++++++++++++++++-
2 files changed, 36 insertions(+), 11 deletions(-)
--- a/arch/arm/plat-omap/include/plat/sram.h
+++ b/arch/arm/plat-omap/include/plat/sram.h
@@ -5,13 +5,4 @@ void omap_map_sram(unsigned long start,
unsigned long skip, int cached);
void omap_sram_reset(void);
-extern void *omap_sram_push_address(unsigned long size);
-
-/* Macro to push a function to the internal SRAM, using the fncpy API */
-#define omap_sram_push(funcp, size) ({ \
- typeof(&(funcp)) _res = NULL; \
- void *_sram_address = omap_sram_push_address(size); \
- if (_sram_address) \
- _res = fncpy(_sram_address, &(funcp), size); \
- _res; \
-})
+extern void *omap_sram_push(void *funcp, unsigned long size);
--- a/arch/arm/plat-omap/sram.c
+++ b/arch/arm/plat-omap/sram.c
@@ -23,6 +23,7 @@
#include <asm/fncpy.h>
#include <asm/tlb.h>
#include <asm/cacheflush.h>
+#include <asm/set_memory.h>
#include <asm/mach/map.h>
@@ -42,7 +43,7 @@ static void __iomem *omap_sram_ceil;
* Note that fncpy requires the returned address to be aligned
* to an 8-byte boundary.
*/
-void *omap_sram_push_address(unsigned long size)
+static void *omap_sram_push_address(unsigned long size)
{
unsigned long available, new_ceil = (unsigned long)omap_sram_ceil;
@@ -60,6 +61,30 @@ void *omap_sram_push_address(unsigned lo
return (void *)omap_sram_ceil;
}
+void *omap_sram_push(void *funcp, unsigned long size)
+{
+ void *sram;
+ unsigned long base;
+ int pages;
+ void *dst = NULL;
+
+ sram = omap_sram_push_address(size);
+ if (!sram)
+ return NULL;
+
+ base = (unsigned long)sram & PAGE_MASK;
+ pages = PAGE_ALIGN(size) / PAGE_SIZE;
+
+ set_memory_rw(base, pages);
+
+ dst = fncpy(sram, funcp, size);
+
+ set_memory_ro(base, pages);
+ set_memory_x(base, pages);
+
+ return dst;
+}
+
/*
* The SRAM context is lost during off-idle and stack
* needs to be reset.
@@ -75,6 +100,9 @@ void omap_sram_reset(void)
void __init omap_map_sram(unsigned long start, unsigned long size,
unsigned long skip, int cached)
{
+ unsigned long base;
+ int pages;
+
if (size == 0)
return;
@@ -95,4 +123,10 @@ void __init omap_map_sram(unsigned long
*/
memset_io(omap_sram_base + omap_sram_skip, 0,
omap_sram_size - omap_sram_skip);
+
+ base = (unsigned long)omap_sram_base;
+ pages = PAGE_ALIGN(omap_sram_size) / PAGE_SIZE;
+
+ set_memory_ro(base, pages);
+ set_memory_x(base, pages);
}
Patches currently in stable-queue which might be from tony(a)atomide.com are
queue-4.15/arm-omap-fix-sram-w-x-mapping.patch
This is a note to let you know that I've just added the patch titled
ARM: dts: sun6i: a31s: bpi-m2: improve pmic properties
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-sun6i-a31s-bpi-m2-improve-pmic-properties.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 b23af6ad8d2f708c4c3f92dd8f82c233247ba8bf Mon Sep 17 00:00:00 2001
From: Philipp Rossak <embed3d(a)gmail.com>
Date: Wed, 14 Feb 2018 15:10:24 +0100
Subject: ARM: dts: sun6i: a31s: bpi-m2: improve pmic properties
From: Philipp Rossak <embed3d(a)gmail.com>
commit b23af6ad8d2f708c4c3f92dd8f82c233247ba8bf upstream.
The eldoin is supplied from the dcdc1 regulator. The N_VBUSEN pin is
connected to an external power regulator (SY6280AAC).
With this commit we update the pmic binding properties to support
those features.
Fixes: 7daa21370075 ("ARM: dts: sunxi: Add regulators for Sinovoip BPI-M2")
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Philipp Rossak <embed3d(a)gmail.com>
Signed-off-by: Maxime Ripard <maxime.ripard(a)bootlin.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/arm/boot/dts/sun6i-a31s-sinovoip-bpi-m2.dts | 2 ++
1 file changed, 2 insertions(+)
--- a/arch/arm/boot/dts/sun6i-a31s-sinovoip-bpi-m2.dts
+++ b/arch/arm/boot/dts/sun6i-a31s-sinovoip-bpi-m2.dts
@@ -163,6 +163,8 @@
reg = <0x68>;
interrupt-parent = <&nmi_intc>;
interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
+ eldoin-supply = <®_dcdc1>;
+ x-powers,drive-vbus-en;
};
};
Patches currently in stable-queue which might be from embed3d(a)gmail.com are
queue-4.15/arm-dts-sun6i-a31s-bpi-m2-improve-pmic-properties.patch
queue-4.15/arm-dts-sun6i-a31s-bpi-m2-add-missing-regulators.patch
This is a note to let you know that I've just added the patch titled
ARM: 8746/1: vfp: Go back to clearing vfp_current_hw_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:
arm-8746-1-vfp-go-back-to-clearing-vfp_current_hw_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 1328f02005bbbaed15b9d5b7f3ab5ec9d4d5268a Mon Sep 17 00:00:00 2001
From: Fabio Estevam <festevam(a)gmail.com>
Date: Mon, 22 Jan 2018 12:20:26 +0100
Subject: ARM: 8746/1: vfp: Go back to clearing vfp_current_hw_state[]
From: Fabio Estevam <festevam(a)gmail.com>
commit 1328f02005bbbaed15b9d5b7f3ab5ec9d4d5268a upstream.
Commit 384b38b66947 ("ARM: 7873/1: vfp: clear vfp_current_hw_state
for dying cpu") fixed the cpu dying notifier by clearing
vfp_current_hw_state[]. However commit e5b61bafe704 ("arm: Convert VFP
hotplug notifiers to state machine") incorrectly used the original
vfp_force_reload() function in the cpu dying notifier.
Fix it by going back to clearing vfp_current_hw_state[].
Fixes: e5b61bafe704 ("arm: Convert VFP hotplug notifiers to state machine")
Cc: linux-stable <stable(a)vger.kernel.org>
Reported-by: Kohji Okuno <okuno.kohji(a)jp.panasonic.com>
Signed-off-by: Fabio Estevam <fabio.estevam(a)nxp.com>
Signed-off-by: Russell King <rmk+kernel(a)armlinux.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/arm/vfp/vfpmodule.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/arch/arm/vfp/vfpmodule.c
+++ b/arch/arm/vfp/vfpmodule.c
@@ -648,7 +648,7 @@ int vfp_restore_user_hwstate(struct user
*/
static int vfp_dying_cpu(unsigned int cpu)
{
- vfp_force_reload(cpu, current_thread_info());
+ vfp_current_hw_state[cpu] = NULL;
return 0;
}
Patches currently in stable-queue which might be from festevam(a)gmail.com are
queue-4.15/arm-8746-1-vfp-go-back-to-clearing-vfp_current_hw_state.patch
This is a note to let you know that I've just added the patch titled
ALSA: pcm: Use dma_bytes as size parameter in dma_mmap_coherent()
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:
alsa-pcm-use-dma_bytes-as-size-parameter-in-dma_mmap_coherent.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 9066ae7ff5d89c0b5daa271e2d573540097a94fa Mon Sep 17 00:00:00 2001
From: Stefan Roese <sr(a)denx.de>
Date: Mon, 26 Mar 2018 16:10:21 +0200
Subject: ALSA: pcm: Use dma_bytes as size parameter in dma_mmap_coherent()
From: Stefan Roese <sr(a)denx.de>
commit 9066ae7ff5d89c0b5daa271e2d573540097a94fa upstream.
When trying to use the driver (e.g. aplay *.wav), the 4MiB DMA buffer
will get mmapp'ed in 16KiB chunks. But this fails with the 2nd 16KiB
area, as the page offset is outside of the VMA range (size), which is
currently used as size parameter in snd_pcm_lib_default_mmap(). By
using the DMA buffer size (dma_bytes) instead, the complete DMA buffer
can be mmapp'ed and the issue is fixed.
This issue was detected on an ARM platform (TI AM57xx) using the RME
HDSP MADI PCIe soundcard.
Fixes: 657b1989dacf ("ALSA: pcm - Use dma_mmap_coherent() if available")
Signed-off-by: Stefan Roese <sr(a)denx.de>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai(a)suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
sound/core/pcm_native.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/sound/core/pcm_native.c
+++ b/sound/core/pcm_native.c
@@ -3422,7 +3422,7 @@ int snd_pcm_lib_default_mmap(struct snd_
area,
substream->runtime->dma_area,
substream->runtime->dma_addr,
- area->vm_end - area->vm_start);
+ substream->runtime->dma_bytes);
#endif /* CONFIG_X86 */
/* mmap with fault handler */
area->vm_ops = &snd_pcm_vm_ops_data_fault;
Patches currently in stable-queue which might be from sr(a)denx.de are
queue-4.15/alsa-pcm-use-dma_bytes-as-size-parameter-in-dma_mmap_coherent.patch
This is a note to let you know that I've just added the patch titled
ALSA: usb-audio: Add native DSD support for TEAC UD-301
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:
alsa-usb-audio-add-native-dsd-support-for-teac-ud-301.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 b00214865d65100163574ba250008f182cf90869 Mon Sep 17 00:00:00 2001
From: Nobutaka Okabe <nob77413(a)gmail.com>
Date: Fri, 23 Mar 2018 19:49:44 +0900
Subject: ALSA: usb-audio: Add native DSD support for TEAC UD-301
From: Nobutaka Okabe <nob77413(a)gmail.com>
commit b00214865d65100163574ba250008f182cf90869 upstream.
Add native DSD support quirk for TEAC UD-301 DAC,
by adding the PID/VID 0644:804a.
Signed-off-by: Nobutaka Okabe <nob77413(a)gmail.com>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai(a)suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
sound/usb/quirks.c | 1 +
1 file changed, 1 insertion(+)
--- a/sound/usb/quirks.c
+++ b/sound/usb/quirks.c
@@ -1171,6 +1171,7 @@ static bool is_teac_dsd_dac(unsigned int
switch (id) {
case USB_ID(0x0644, 0x8043): /* TEAC UD-501/UD-503/NT-503 */
case USB_ID(0x0644, 0x8044): /* Esoteric D-05X */
+ case USB_ID(0x0644, 0x804a): /* TEAC UD-301 */
return true;
}
return false;
Patches currently in stable-queue which might be from nob77413(a)gmail.com are
queue-4.15/alsa-usb-audio-add-native-dsd-support-for-teac-ud-301.patch
This is a note to let you know that I've just added the patch titled
ALSA: pcm: potential uninitialized return values
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:
alsa-pcm-potential-uninitialized-return-values.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 5607dddbfca774fb38bffadcb077fe03aa4ac5c6 Mon Sep 17 00:00:00 2001
From: Dan Carpenter <dan.carpenter(a)oracle.com>
Date: Tue, 27 Mar 2018 16:07:52 +0300
Subject: ALSA: pcm: potential uninitialized return values
From: Dan Carpenter <dan.carpenter(a)oracle.com>
commit 5607dddbfca774fb38bffadcb077fe03aa4ac5c6 upstream.
Smatch complains that "tmp" can be uninitialized if we do a zero size
write.
Fixes: 02a5d6925cd3 ("ALSA: pcm: Avoid potential races between OSS ioctls and read/write")
Signed-off-by: Dan Carpenter <dan.carpenter(a)oracle.com>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai(a)suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
sound/core/oss/pcm_oss.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/sound/core/oss/pcm_oss.c
+++ b/sound/core/oss/pcm_oss.c
@@ -1326,7 +1326,7 @@ static ssize_t snd_pcm_oss_write2(struct
static ssize_t snd_pcm_oss_write1(struct snd_pcm_substream *substream, const char __user *buf, size_t bytes)
{
size_t xfer = 0;
- ssize_t tmp;
+ ssize_t tmp = 0;
struct snd_pcm_runtime *runtime = substream->runtime;
if (atomic_read(&substream->mmap_count))
@@ -1433,7 +1433,7 @@ static ssize_t snd_pcm_oss_read2(struct
static ssize_t snd_pcm_oss_read1(struct snd_pcm_substream *substream, char __user *buf, size_t bytes)
{
size_t xfer = 0;
- ssize_t tmp;
+ ssize_t tmp = 0;
struct snd_pcm_runtime *runtime = substream->runtime;
if (atomic_read(&substream->mmap_count))
Patches currently in stable-queue which might be from dan.carpenter(a)oracle.com are
queue-4.15/alsa-pcm-potential-uninitialized-return-values.patch
This is a note to let you know that I've just added the patch titled
x86/platform/uv/BAU: Add APIC idt entry
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-platform-uv-bau-add-apic-idt-entry.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 151ad17fbe5e56afa59709f41980508672c777ce Mon Sep 17 00:00:00 2001
From: Andrew Banman <abanman(a)hpe.com>
Date: Tue, 27 Mar 2018 17:09:06 -0500
Subject: x86/platform/uv/BAU: Add APIC idt entry
From: Andrew Banman <abanman(a)hpe.com>
commit 151ad17fbe5e56afa59709f41980508672c777ce upstream.
BAU uses the old alloc_initr_gate90 method to setup its interrupt. This
fails silently as the BAU vector is in the range of APIC vectors that are
registered to the spurious interrupt handler. As a consequence BAU
broadcasts are not handled, and the broadcast source CPU hangs.
Update BAU to use new idt structure.
Fixes: dc20b2d52653 ("x86/idt: Move interrupt gate initialization to IDT code")
Signed-off-by: Andrew Banman <abanman(a)hpe.com>
Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de>
Acked-by: Mike Travis <mike.travis(a)hpe.com>
Cc: Dimitri Sivanich <sivanich(a)hpe.com>
Cc: Russ Anderson <rja(a)hpe.com>
Cc: stable(a)vger.kernel.org
Cc: "H. Peter Anvin" <hpa(a)zytor.com>
Link: https://lkml.kernel.org/r/1522188546-196177-1-git-send-email-abanman@hpe.com
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/x86/include/asm/hw_irq.h | 1 +
arch/x86/kernel/idt.c | 3 +++
arch/x86/platform/uv/tlb_uv.c | 2 --
3 files changed, 4 insertions(+), 2 deletions(-)
--- a/arch/x86/include/asm/hw_irq.h
+++ b/arch/x86/include/asm/hw_irq.h
@@ -34,6 +34,7 @@ extern asmlinkage void kvm_posted_intr_w
extern asmlinkage void kvm_posted_intr_nested_ipi(void);
extern asmlinkage void error_interrupt(void);
extern asmlinkage void irq_work_interrupt(void);
+extern asmlinkage void uv_bau_message_intr1(void);
extern asmlinkage void spurious_interrupt(void);
extern asmlinkage void thermal_interrupt(void);
--- a/arch/x86/kernel/idt.c
+++ b/arch/x86/kernel/idt.c
@@ -140,6 +140,9 @@ static const __initconst struct idt_data
# ifdef CONFIG_IRQ_WORK
INTG(IRQ_WORK_VECTOR, irq_work_interrupt),
# endif
+#ifdef CONFIG_X86_UV
+ INTG(UV_BAU_MESSAGE, uv_bau_message_intr1),
+#endif
INTG(SPURIOUS_APIC_VECTOR, spurious_interrupt),
INTG(ERROR_APIC_VECTOR, error_interrupt),
#endif
--- a/arch/x86/platform/uv/tlb_uv.c
+++ b/arch/x86/platform/uv/tlb_uv.c
@@ -2254,8 +2254,6 @@ static int __init uv_bau_init(void)
init_uvhub(uvhub, vector, uv_base_pnode);
}
- alloc_intr_gate(vector, uv_bau_message_intr1);
-
for_each_possible_blade(uvhub) {
if (uv_blade_nr_possible_cpus(uvhub)) {
unsigned long val;
Patches currently in stable-queue which might be from abanman(a)hpe.com are
queue-4.14/x86-platform-uv-bau-add-apic-idt-entry.patch
This is a note to let you know that I've just added the patch titled
powerpc/64s: Fix lost pending interrupt due to race causing lost update to irq_happened
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-64s-fix-lost-pending-interrupt-due-to-race-causing-lost-update-to-irq_happened.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 ff6781fd1bb404d8a551c02c35c70cec1da17ff1 Mon Sep 17 00:00:00 2001
From: Nicholas Piggin <npiggin(a)gmail.com>
Date: Wed, 21 Mar 2018 12:22:28 +1000
Subject: powerpc/64s: Fix lost pending interrupt due to race causing lost update to irq_happened
From: Nicholas Piggin <npiggin(a)gmail.com>
commit ff6781fd1bb404d8a551c02c35c70cec1da17ff1 upstream.
force_external_irq_replay() can be called in the do_IRQ path with
interrupts hard enabled and soft disabled if may_hard_irq_enable() set
MSR[EE]=1. It updates local_paca->irq_happened with a load, modify,
store sequence. If a maskable interrupt hits during this sequence, it
will go to the masked handler to be marked pending in irq_happened.
This update will be lost when the interrupt returns and the store
instruction executes. This can result in unpredictable latencies,
timeouts, lockups, etc.
Fix this by ensuring hard interrupts are disabled before modifying
irq_happened.
This could cause any maskable asynchronous interrupt to get lost, but
it was noticed on P9 SMP system doing RDMA NVMe target over 100GbE,
so very high external interrupt rate and high IPI rate. The hang was
bisected down to enabling doorbell interrupts for IPIs. These provided
an interrupt type that could run at high rates in the do_IRQ path,
stressing the race.
Fixes: 1d607bb3bd60 ("powerpc/irq: Add mechanism to force a replay of interrupts")
Cc: stable(a)vger.kernel.org # v4.8+
Reported-by: Carol L. Soto <clsoto(a)us.ibm.com>
Signed-off-by: Nicholas Piggin <npiggin(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/kernel/irq.c | 8 ++++++++
1 file changed, 8 insertions(+)
--- a/arch/powerpc/kernel/irq.c
+++ b/arch/powerpc/kernel/irq.c
@@ -430,6 +430,14 @@ void force_external_irq_replay(void)
*/
WARN_ON(!arch_irqs_disabled());
+ /*
+ * Interrupts must always be hard disabled before irq_happened is
+ * modified (to prevent lost update in case of interrupt between
+ * load and store).
+ */
+ __hard_irq_disable();
+ local_paca->irq_happened |= PACA_IRQ_HARD_DIS;
+
/* Indicate in the PACA that we have an interrupt to replay */
local_paca->irq_happened |= PACA_IRQ_EE;
}
Patches currently in stable-queue which might be from npiggin(a)gmail.com are
queue-4.14/powerpc-64s-fix-lost-pending-interrupt-due-to-race-causing-lost-update-to-irq_happened.patch
queue-4.14/powerpc-64s-fix-i-side-slb-miss-bad-address-handler-saving-nonvolatile-gprs.patch
This is a note to let you know that I've just added the patch titled
powerpc/64s: Fix i-side SLB miss bad address handler saving nonvolatile GPRs
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-64s-fix-i-side-slb-miss-bad-address-handler-saving-nonvolatile-gprs.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 52396500f97c53860164debc7d4f759077853423 Mon Sep 17 00:00:00 2001
From: Nicholas Piggin <npiggin(a)gmail.com>
Date: Fri, 23 Mar 2018 15:53:38 +1000
Subject: powerpc/64s: Fix i-side SLB miss bad address handler saving nonvolatile GPRs
From: Nicholas Piggin <npiggin(a)gmail.com>
commit 52396500f97c53860164debc7d4f759077853423 upstream.
The SLB bad address handler's trap number fixup does not preserve the
low bit that indicates nonvolatile GPRs have not been saved. This
leads save_nvgprs to skip saving them, and subsequent functions and
return from interrupt will think they are saved.
This causes kernel branch-to-garbage debugging to not have correct
registers, can also cause userspace to have its registers clobbered
after a segfault.
Fixes: f0f558b131db ("powerpc/mm: Preserve CFAR value on SLB miss caused by access to bogus address")
Cc: stable(a)vger.kernel.org # v4.9+
Signed-off-by: Nicholas Piggin <npiggin(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/kernel/exceptions-64s.S | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/arch/powerpc/kernel/exceptions-64s.S
+++ b/arch/powerpc/kernel/exceptions-64s.S
@@ -704,7 +704,7 @@ EXC_COMMON_BEGIN(bad_addr_slb)
ld r3, PACA_EXSLB+EX_DAR(r13)
std r3, _DAR(r1)
beq cr6, 2f
- li r10, 0x480 /* fix trap number for I-SLB miss */
+ li r10, 0x481 /* fix trap number for I-SLB miss */
std r10, _TRAP(r1)
2: bl save_nvgprs
addi r3, r1, STACK_FRAME_OVERHEAD
Patches currently in stable-queue which might be from npiggin(a)gmail.com are
queue-4.14/powerpc-64s-fix-lost-pending-interrupt-due-to-race-causing-lost-update-to-irq_happened.patch
queue-4.14/powerpc-64s-fix-i-side-slb-miss-bad-address-handler-saving-nonvolatile-gprs.patch