Fixes for 4.4

Signed-off-by: Sasha Levin <sashal@kernel.org>

diff --git a/queue-4.4/s390-ftrace-save-traced-function-caller.patch b/queue-4.4/s390-ftrace-save-traced-function-caller.patch
new file mode 100644 (file)
index 0000000..a7eec73
--- /dev/null
+++ b/queue-4.4/s390-ftrace-save-traced-function-caller.patch
@@ -0,0 +1,55 @@
+From 016f1833292fbd7d25cf88d410ac4189eba0d92e Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Tue, 10 Dec 2019 13:50:23 +0100
+Subject: s390/ftrace: save traced function caller
+
+From: Vasily Gorbik <gor@linux.ibm.com>
+
+[ Upstream commit b4adfe55915d8363e244e42386d69567db1719b9 ]
+
+A typical backtrace acquired from ftraced function currently looks like
+the following (e.g. for "path_openat"):
+
+arch_stack_walk+0x15c/0x2d8
+stack_trace_save+0x50/0x68
+stack_trace_call+0x15a/0x3b8
+ftrace_graph_caller+0x0/0x1c
+0x3e0007e3c98 <- ftraced function caller (should be do_filp_open+0x7c/0xe8)
+do_open_execat+0x70/0x1b8
+__do_execve_file.isra.0+0x7d8/0x860
+__s390x_sys_execve+0x56/0x68
+system_call+0xdc/0x2d8
+
+Note random "0x3e0007e3c98" stack value as ftraced function caller. This
+value causes either imprecise unwinder result or unwinding failure.
+That "0x3e0007e3c98" comes from r14 of ftraced function stack frame, which
+it haven't had a chance to initialize since the very first instruction
+calls ftrace code ("ftrace_caller"). (ftraced function might never
+save r14 as well). Nevertheless according to s390 ABI any function
+is called with stack frame allocated for it and r14 contains return
+address. "ftrace_caller" itself is called with "brasl %r0,ftrace_caller".
+So, to fix this issue simply always save traced function caller onto
+ftraced function stack frame.
+
+Reported-by: Sven Schnelle <svens@linux.ibm.com>
+Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ arch/s390/kernel/mcount.S | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/arch/s390/kernel/mcount.S b/arch/s390/kernel/mcount.S
+index 78ba14546e00..68425e68e65a 100644
+--- a/arch/s390/kernel/mcount.S
++++ b/arch/s390/kernel/mcount.S
+@@ -36,6 +36,7 @@ ENTRY(_mcount)
+ ENTRY(ftrace_caller)
+       .globl  ftrace_regs_caller
+       .set    ftrace_regs_caller,ftrace_caller
++      stg     %r14,(__SF_GPRS+8*8)(%r15)      # save traced function caller
+       lgr     %r1,%r15
+ #ifndef CC_USING_HOTPATCH
+       aghi    %r0,MCOUNT_RETURN_FIXUP
+-- 
+2.25.1
+

diff --git a/queue-4.4/series b/queue-4.4/series
index 2a66b552ef83a1fb2cb321bab9e597695c129892..56e7445f3a1af7340dff7dbcc8c0fc3f935c5448 100644 (file)
--- a/queue-4.4/series
+++ b/queue-4.4/series
@@ -4,3 +4,5 @@ platform-x86-acer-wmi-setup-accelerometer-when-acpi-device-was-found.patch
 esp6-fix-memleak-on-error-path-in-esp6_input.patch
 ib-mlx4-fix-an-error-handling-path-in-mlx4_ib_rereg_user_mr.patch
 alsa-hda-no-loopback-on-alc299-codec.patch
+spi-dw-use-smp_mb-to-avoid-sending-spi-data-error.patch
+s390-ftrace-save-traced-function-caller.patch

diff --git a/queue-4.4/spi-dw-use-smp_mb-to-avoid-sending-spi-data-error.patch b/queue-4.4/spi-dw-use-smp_mb-to-avoid-sending-spi-data-error.patch
new file mode 100644 (file)
index 0000000..eefb1df
--- /dev/null
+++ b/queue-4.4/spi-dw-use-smp_mb-to-avoid-sending-spi-data-error.patch
@@ -0,0 +1,48 @@
+From 0751af137c1e9d1d6e94b694d4530544245519d5 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Fri, 3 Jan 2020 10:52:10 +0800
+Subject: spi: dw: use "smp_mb()" to avoid sending spi data error
+
+From: Xinwei Kong <kong.kongxinwei@hisilicon.com>
+
+[ Upstream commit bfda044533b213985bc62bd7ca96f2b984d21b80 ]
+
+Because of out-of-order execution about some CPU architecture,
+In this debug stage we find Completing spi interrupt enable ->
+prodrucing TXEI interrupt -> running "interrupt_transfer" function
+will prior to set "dw->rx and dws->rx_end" data, so this patch add
+memory barrier to enable dw->rx and dw->rx_end to be visible and
+solve to send SPI data error.
+eg:
+it will fix to this following low possibility error in testing environment
+which using SPI control to connect TPM Modules
+
+kernel: tpm tpm0: Operation Timed out
+kernel: tpm tpm0: tpm_relinquish_locality: : error -1
+
+Signed-off-by: fengsheng <fengsheng5@huawei.com>
+Signed-off-by: Xinwei Kong <kong.kongxinwei@hisilicon.com>
+Link: https://lore.kernel.org/r/1578019930-55858-1-git-send-email-kong.kongxinwei@hisilicon.com
+Signed-off-by: Mark Brown <broonie@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/spi/spi-dw.c | 3 +++
+ 1 file changed, 3 insertions(+)
+
+diff --git a/drivers/spi/spi-dw.c b/drivers/spi/spi-dw.c
+index 4edd38d03b93..5688591e9cd3 100644
+--- a/drivers/spi/spi-dw.c
++++ b/drivers/spi/spi-dw.c
+@@ -306,6 +306,9 @@ static int dw_spi_transfer_one(struct spi_master *master,
+       dws->len = transfer->len;
+       spin_unlock_irqrestore(&dws->buf_lock, flags);
+ 
++      /* Ensure dw->rx and dw->rx_end are visible */
++      smp_mb();
++
+       spi_enable_chip(dws, 0);
+ 
+       /* Handle per transfer options for bpw and speed */
+-- 
+2.25.1
+