This is a note to let you know that I've just added the patch titled
bnx2x: Improve reliability in case of nested PCI errors
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:
bnx2x-improve-reliability-in-case-of-nested-pci-errors.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 foo@baz Wed Feb 28 16:13:29 CET 2018
From: "Guilherme G. Piccoli" <gpiccoli(a)linux.vnet.ibm.com>
Date: Fri, 22 Dec 2017 13:01:39 -0200
Subject: bnx2x: Improve reliability in case of nested PCI errors
From: "Guilherme G. Piccoli" <gpiccoli(a)linux.vnet.ibm.com>
[ Upstream commit f7084059a9cb9e56a186e1677b1dcffd76c2cd24 ]
While in recovery process of PCI error (called EEH on PowerPC arch),
another PCI transaction could be corrupted causing a situation of
nested PCI errors. Also, this scenario could be reproduced with
error injection mechanisms (for debug purposes).
We observe that in case of nested PCI errors, bnx2x might attempt to
initialize its shmem and cause a kernel crash due to bad addresses
read from MCP. Multiple different stack traces were observed depending
on the point the second PCI error happens.
This patch avoids the crashes by:
* failing PCI recovery in case of nested errors (since multiple
PCI errors in a row are not expected to lead to a functional
adapter anyway), and by,
* preventing access to adapter FW when MCP is failed (we mark it as
failed when shmem cannot get initialized properly).
Reported-by: Abdul Haleem <abdhalee(a)linux.vnet.ibm.com>
Signed-off-by: Guilherme G. Piccoli <gpiccoli(a)linux.vnet.ibm.com>
Acked-by: Shahed Shaikh <Shahed.Shaikh(a)cavium.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c | 4 ++--
drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c | 14 +++++++++++++-
2 files changed, 15 insertions(+), 3 deletions(-)
--- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c
+++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c
@@ -3034,7 +3034,7 @@ int bnx2x_nic_unload(struct bnx2x *bp, i
del_timer_sync(&bp->timer);
- if (IS_PF(bp)) {
+ if (IS_PF(bp) && !BP_NOMCP(bp)) {
/* Set ALWAYS_ALIVE bit in shmem */
bp->fw_drv_pulse_wr_seq |= DRV_PULSE_ALWAYS_ALIVE;
bnx2x_drv_pulse(bp);
@@ -3120,7 +3120,7 @@ int bnx2x_nic_unload(struct bnx2x *bp, i
bp->cnic_loaded = false;
/* Clear driver version indication in shmem */
- if (IS_PF(bp))
+ if (IS_PF(bp) && !BP_NOMCP(bp))
bnx2x_update_mng_version(bp);
/* Check if there are pending parity attentions. If there are - set
--- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
+++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
@@ -9578,6 +9578,15 @@ static int bnx2x_init_shmem(struct bnx2x
do {
bp->common.shmem_base = REG_RD(bp, MISC_REG_SHARED_MEM_ADDR);
+
+ /* If we read all 0xFFs, means we are in PCI error state and
+ * should bail out to avoid crashes on adapter's FW reads.
+ */
+ if (bp->common.shmem_base == 0xFFFFFFFF) {
+ bp->flags |= NO_MCP_FLAG;
+ return -ENODEV;
+ }
+
if (bp->common.shmem_base) {
val = SHMEM_RD(bp, validity_map[BP_PORT(bp)]);
if (val & SHR_MEM_VALIDITY_MB)
@@ -14312,7 +14321,10 @@ static pci_ers_result_t bnx2x_io_slot_re
BNX2X_ERR("IO slot reset --> driver unload\n");
/* MCP should have been reset; Need to wait for validity */
- bnx2x_init_shmem(bp);
+ if (bnx2x_init_shmem(bp)) {
+ rtnl_unlock();
+ return PCI_ERS_RESULT_DISCONNECT;
+ }
if (IS_PF(bp) && SHMEM2_HAS(bp, drv_capabilities_flag)) {
u32 v;
Patches currently in stable-queue which might be from gpiccoli(a)linux.vnet.ibm.com are
queue-4.9/bnx2x-improve-reliability-in-case-of-nested-pci-errors.patch
This is a note to let you know that I've just added the patch titled
ARM: dts: ls1021a: fix incorrect clock references
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:
arm-dts-ls1021a-fix-incorrect-clock-references.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 foo@baz Wed Feb 28 16:13:29 CET 2018
From: Arnd Bergmann <arnd(a)arndb.de>
Date: Thu, 21 Dec 2017 22:35:19 +0100
Subject: ARM: dts: ls1021a: fix incorrect clock references
From: Arnd Bergmann <arnd(a)arndb.de>
[ Upstream commit 506e8a912661c97b41adc8a286b875d01323ec45 ]
dtc warns about two 'clocks' properties that have an extraneous '1'
at the end:
arch/arm/boot/dts/ls1021a-qds.dtb: Warning (clocks_property): arch/arm/boot/dts/ls1021a-twr.dtb: Warning (clocks_property): Property 'clocks', cell 1 is not a phandle reference in /soc/i2c@2180000/mux@77/i2c@4/sgtl5000@2a
arch/arm/boot/dts/ls1021a-qds.dtb: Warning (clocks_property): Missing property '#clock-cells' in node /soc/interrupt-controller@1400000 or bad phandle (referred from /soc/i2c@2180000/mux@77/i2c@4/sgtl5000@2a:clocks[1])
Property 'clocks', cell 1 is not a phandle reference in /soc/i2c@2190000/sgtl5000@a
arch/arm/boot/dts/ls1021a-twr.dtb: Warning (clocks_property): Missing property '#clock-cells' in node /soc/interrupt-controller@1400000 or bad phandle (referred from /soc/i2c@2190000/sgtl5000@a:clocks[1])
The clocks that get referenced here are fixed-rate, so they do not
take any argument, and dtc interprets the next cell as a phandle, which
is invalid.
Signed-off-by: Arnd Bergmann <arnd(a)arndb.de>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/arm/boot/dts/ls1021a-qds.dts | 2 +-
arch/arm/boot/dts/ls1021a-twr.dts | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
--- a/arch/arm/boot/dts/ls1021a-qds.dts
+++ b/arch/arm/boot/dts/ls1021a-qds.dts
@@ -215,7 +215,7 @@
reg = <0x2a>;
VDDA-supply = <®_3p3v>;
VDDIO-supply = <®_3p3v>;
- clocks = <&sys_mclk 1>;
+ clocks = <&sys_mclk>;
};
};
};
--- a/arch/arm/boot/dts/ls1021a-twr.dts
+++ b/arch/arm/boot/dts/ls1021a-twr.dts
@@ -187,7 +187,7 @@
reg = <0x0a>;
VDDA-supply = <®_3p3v>;
VDDIO-supply = <®_3p3v>;
- clocks = <&sys_mclk 1>;
+ clocks = <&sys_mclk>;
};
};
Patches currently in stable-queue which might be from arnd(a)arndb.de are
queue-4.9/x86-asm-allow-again-using-asm.h-when-building-for-the-bpf-clang-target.patch
queue-4.9/arm-dts-ls1021a-fix-incorrect-clock-references.patch
This is a note to let you know that I've just added the patch titled
ASoC: nau8825: fix issue that pop noise when start capture
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:
asoc-nau8825-fix-issue-that-pop-noise-when-start-capture.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 foo@baz Wed Feb 28 16:13:29 CET 2018
From: Abhijeet Kumar <abhijeet.kumar(a)intel.com>
Date: Tue, 12 Dec 2017 00:40:25 +0530
Subject: ASoC: nau8825: fix issue that pop noise when start capture
From: Abhijeet Kumar <abhijeet.kumar(a)intel.com>
[ Upstream commit d070f7c703ef26e3db613f24206823f916272fc6 ]
In skylake platform, we hear a loud pop noise(0 dB) at start of
audio capture power up sequence. This patch removes the pop noise
from the recording by adding a delay before enabling ADC.
Signed-off-by: Abhijeet Kumar <abhijeet.kumar(a)intel.com>
Signed-off-by: Mark Brown <broonie(a)kernel.org>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
sound/soc/codecs/nau8825.c | 1 +
1 file changed, 1 insertion(+)
--- a/sound/soc/codecs/nau8825.c
+++ b/sound/soc/codecs/nau8825.c
@@ -882,6 +882,7 @@ static int nau8825_adc_event(struct snd_
switch (event) {
case SND_SOC_DAPM_POST_PMU:
+ msleep(125);
regmap_update_bits(nau8825->regmap, NAU8825_REG_ENA_CTRL,
NAU8825_ENABLE_ADC, NAU8825_ENABLE_ADC);
break;
Patches currently in stable-queue which might be from abhijeet.kumar(a)intel.com are
queue-4.9/asoc-nau8825-fix-issue-that-pop-noise-when-start-capture.patch
This is a note to let you know that I've just added the patch titled
ARM: 8731/1: Fix csum_partial_copy_from_user() stack mismatch
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:
arm-8731-1-fix-csum_partial_copy_from_user-stack-mismatch.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 foo@baz Wed Feb 28 16:13:29 CET 2018
From: Chunyan Zhang <zhang.lyra(a)gmail.com>
Date: Fri, 1 Dec 2017 03:51:04 +0100
Subject: ARM: 8731/1: Fix csum_partial_copy_from_user() stack mismatch
From: Chunyan Zhang <zhang.lyra(a)gmail.com>
[ Upstream commit 36b0cb84ee858f02c256d26f0cb4229c78e3399e ]
An additional 'ip' will be pushed to the stack, for restoring the
DACR later, if CONFIG_CPU_SW_DOMAIN_PAN defined.
However, the fixup still get the err_ptr by add #8*4 to sp, which
results in the fact that the code area pointed by the LR will be
overwritten, or the kernel will crash if CONFIG_DEBUG_RODATA is enabled.
This patch fixes the stack mismatch.
Fixes: a5e090acbf54 ("ARM: software-based priviledged-no-access support")
Signed-off-by: Lvqiang Huang <Lvqiang.Huang(a)spreadtrum.com>
Signed-off-by: Chunyan Zhang <zhang.lyra(a)gmail.com>
Signed-off-by: Russell King <rmk+kernel(a)armlinux.org.uk>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/arm/lib/csumpartialcopyuser.S | 4 ++++
1 file changed, 4 insertions(+)
--- a/arch/arm/lib/csumpartialcopyuser.S
+++ b/arch/arm/lib/csumpartialcopyuser.S
@@ -85,7 +85,11 @@
.pushsection .text.fixup,"ax"
.align 4
9001: mov r4, #-EFAULT
+#ifdef CONFIG_CPU_SW_DOMAIN_PAN
+ ldr r5, [sp, #9*4] @ *err_ptr
+#else
ldr r5, [sp, #8*4] @ *err_ptr
+#endif
str r4, [r5]
ldmia sp, {r1, r2} @ retrieve dst, len
add r2, r2, r1
Patches currently in stable-queue which might be from zhang.lyra(a)gmail.com are
queue-4.9/arm-8731-1-fix-csum_partial_copy_from_user-stack-mismatch.patch
This is a note to let you know that I've just added the patch titled
f2fs: fix a bug caused by NULL extent tree
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:
f2fs-fix-a-bug-caused-by-null-extent-tree.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 dad48e73127ba10279ea33e6dbc8d3905c4d31c0 Mon Sep 17 00:00:00 2001
From: Yunlei He <heyunlei(a)huawei.com>
Date: Fri, 19 May 2017 15:06:12 +0800
Subject: f2fs: fix a bug caused by NULL extent tree
From: Yunlei He <heyunlei(a)huawei.com>
commit dad48e73127ba10279ea33e6dbc8d3905c4d31c0 upstream.
Thread A: Thread B:
-f2fs_remount
-sbi->mount_opt.opt = 0;
<--- -f2fs_iget
-do_read_inode
-f2fs_init_extent_tree
-F2FS_I(inode)->extent_tree is NULL
-default_options && parse_options
-remount return
<--- -f2fs_map_blocks
-f2fs_lookup_extent_tree
-f2fs_bug_on(sbi, !et);
The same problem with f2fs_new_inode.
Signed-off-by: Yunlei He <heyunlei(a)huawei.com>
Signed-off-by: Jaegeuk Kim <jaegeuk(a)kernel.org>
Signed-off-by: Nikolay Borisov <nborisov(a)suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/f2fs/extent_cache.c | 12 +++++++++++-
1 file changed, 11 insertions(+), 1 deletion(-)
--- a/fs/f2fs/extent_cache.c
+++ b/fs/f2fs/extent_cache.c
@@ -177,7 +177,7 @@ static void __drop_largest_extent(struct
}
/* return true, if inode page is changed */
-bool f2fs_init_extent_tree(struct inode *inode, struct f2fs_extent *i_ext)
+static bool __f2fs_init_extent_tree(struct inode *inode, struct f2fs_extent *i_ext)
{
struct f2fs_sb_info *sbi = F2FS_I_SB(inode);
struct extent_tree *et;
@@ -215,6 +215,16 @@ out:
return false;
}
+bool f2fs_init_extent_tree(struct inode *inode, struct f2fs_extent *i_ext)
+{
+ bool ret = __f2fs_init_extent_tree(inode, i_ext);
+
+ if (!F2FS_I(inode)->extent_tree)
+ set_inode_flag(inode, FI_NO_EXTENT);
+
+ return ret;
+}
+
static bool f2fs_lookup_extent_tree(struct inode *inode, pgoff_t pgofs,
struct extent_info *ei)
{
Patches currently in stable-queue which might be from heyunlei(a)huawei.com are
queue-4.9/f2fs-fix-a-bug-caused-by-null-extent-tree.patch
This is a note to let you know that I've just added the patch titled
f2fs: fix a bug caused by NULL extent tree
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:
f2fs-fix-a-bug-caused-by-null-extent-tree.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 dad48e73127ba10279ea33e6dbc8d3905c4d31c0 Mon Sep 17 00:00:00 2001
From: Yunlei He <heyunlei(a)huawei.com>
Date: Fri, 19 May 2017 15:06:12 +0800
Subject: f2fs: fix a bug caused by NULL extent tree
From: Yunlei He <heyunlei(a)huawei.com>
commit dad48e73127ba10279ea33e6dbc8d3905c4d31c0 upstream.
Thread A: Thread B:
-f2fs_remount
-sbi->mount_opt.opt = 0;
<--- -f2fs_iget
-do_read_inode
-f2fs_init_extent_tree
-F2FS_I(inode)->extent_tree is NULL
-default_options && parse_options
-remount return
<--- -f2fs_map_blocks
-f2fs_lookup_extent_tree
-f2fs_bug_on(sbi, !et);
The same problem with f2fs_new_inode.
Signed-off-by: Yunlei He <heyunlei(a)huawei.com>
Signed-off-by: Jaegeuk Kim <jaegeuk(a)kernel.org>
Signed-off-by: Nikolay Borisov <nborisov(a)suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/f2fs/extent_cache.c | 10 +++++++++-
1 file changed, 9 insertions(+), 1 deletion(-)
--- a/fs/f2fs/extent_cache.c
+++ b/fs/f2fs/extent_cache.c
@@ -172,7 +172,7 @@ void f2fs_drop_largest_extent(struct ino
__drop_largest_extent(inode, fofs, 1);
}
-void f2fs_init_extent_tree(struct inode *inode, struct f2fs_extent *i_ext)
+static void __f2fs_init_extent_tree(struct inode *inode, struct f2fs_extent *i_ext)
{
struct f2fs_sb_info *sbi = F2FS_I_SB(inode);
struct extent_tree *et;
@@ -204,6 +204,14 @@ out:
write_unlock(&et->lock);
}
+void f2fs_init_extent_tree(struct inode *inode, struct f2fs_extent *i_ext)
+{
+ __f2fs_init_extent_tree(inode, i_ext);
+
+ if (!F2FS_I(inode)->extent_tree)
+ set_inode_flag(F2FS_I(inode), FI_NO_EXTENT);
+}
+
static bool f2fs_lookup_extent_tree(struct inode *inode, pgoff_t pgofs,
struct extent_info *ei)
{
Patches currently in stable-queue which might be from heyunlei(a)huawei.com are
queue-4.4/f2fs-fix-a-bug-caused-by-null-extent-tree.patch