--- /dev/null
+From 2f9a9621ce3ebed0aedc594aa4f013fad62bb972 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 0cfd5a83a1da..151f001a90ff 100644
+--- a/arch/s390/kernel/mcount.S
++++ b/arch/s390/kernel/mcount.S
+@@ -40,6 +40,7 @@ EXPORT_SYMBOL(_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
+
--- /dev/null
+From 8078721355528728ade37fdfd6b4b6301fb3c937 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Tue, 12 Nov 2019 17:30:56 +0800
+Subject: scsi: hisi_sas: Check sas_port before using it
+
+From: Xiang Chen <chenxiang66@hisilicon.com>
+
+[ Upstream commit 8c39673d5474b95374df2104dc1f65205c5278b8 ]
+
+Need to check the structure sas_port before using it.
+
+Link: https://lore.kernel.org/r/1573551059-107873-2-git-send-email-john.garry@huawei.com
+Signed-off-by: Xiang Chen <chenxiang66@hisilicon.com>
+Signed-off-by: John Garry <john.garry@huawei.com>
+Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/scsi/hisi_sas/hisi_sas_main.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+diff --git a/drivers/scsi/hisi_sas/hisi_sas_main.c b/drivers/scsi/hisi_sas/hisi_sas_main.c
+index b167411580ba..dd918c5d5cb8 100644
+--- a/drivers/scsi/hisi_sas/hisi_sas_main.c
++++ b/drivers/scsi/hisi_sas/hisi_sas_main.c
+@@ -655,12 +655,13 @@ static void hisi_sas_port_notify_formed(struct asd_sas_phy *sas_phy)
+ struct hisi_hba *hisi_hba = sas_ha->lldd_ha;
+ struct hisi_sas_phy *phy = sas_phy->lldd_phy;
+ struct asd_sas_port *sas_port = sas_phy->port;
+- struct hisi_sas_port *port = to_hisi_sas_port(sas_port);
++ struct hisi_sas_port *port;
+ unsigned long flags;
+
+ if (!sas_port)
+ return;
+
++ port = to_hisi_sas_port(sas_port);
+ spin_lock_irqsave(&hisi_hba->lock, flags);
+ port->port_attached = 1;
+ port->id = phy->port_id;
+--
+2.25.1
+
scsi-scsi_devinfo-fixup-string-compare.patch
libnvdimm-fix-endian-conversion-issues.patch
+scsi-hisi_sas-check-sas_port-before-using-it.patch
+spi-dw-use-smp_mb-to-avoid-sending-spi-data-error.patch
+s390-ftrace-save-traced-function-caller.patch
--- /dev/null
+From 57b924fbd03ae061ac2b666813fda4304c21ea23 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 b461200871f8..cbdad3c4930f 100644
+--- a/drivers/spi/spi-dw.c
++++ b/drivers/spi/spi-dw.c
+@@ -305,6 +305,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
+
projects / thirdparty / kernel / stable-queue.git / commitdiff
