It seems that the firmware of the 88W8897 card sometimes ignores or
misses when we try to wake it up by writing to the firmware status
register. This leads to the firmware wakeup timeout expiring and the
driver resetting the card because we assume the firmware has hung up or
crashed (unfortunately that's not unlikely with this card).
Turns out that most of the time the firmware actually didn't hang up,
but simply "missed" our wakeup request and didn't send us an AWAKE
event.
Trying again to read the firmware status register after a short timeout
usually makes the firmware wake up as expected, so add a small retry
loop to mwifiex_pm_wakeup_card() that looks at the interrupt status to
check whether the card woke up.
The number of tries and timeout lengths for this were determined
experimentally: The firmware usually takes about 500 us to wake up
after we attempt to read the status register. In some cases where the
firmware is very busy (for example while doing a bluetooth scan) it
might even miss our requests for multiple milliseconds, which is why
after 15 tries the waiting time gets increased to 10 ms. The maximum
number of tries it took to wake the firmware when testing this was
around 20, so a maximum number of 50 tries should give us plenty of
safety margin.
A good reproducer for this issue is letting the firmware sleep and wake
up in very short intervals, for example by pinging a device on the
network every 0.1 seconds.
Cc: stable(a)vger.kernel.org
Signed-off-by: Jonas Dreßler <verdre(a)v0yd.nl>
---
drivers/net/wireless/marvell/mwifiex/pcie.c | 33 +++++++++++++++++----
1 file changed, 27 insertions(+), 6 deletions(-)
diff --git a/drivers/net/wireless/marvell/mwifiex/pcie.c b/drivers/net/wireless/marvell/mwifiex/pcie.c
index 0eff717ac5fa..7fea319e013c 100644
--- a/drivers/net/wireless/marvell/mwifiex/pcie.c
+++ b/drivers/net/wireless/marvell/mwifiex/pcie.c
@@ -661,11 +661,15 @@ static void mwifiex_delay_for_sleep_cookie(struct mwifiex_adapter *adapter,
"max count reached while accessing sleep cookie\n");
}
+#define N_WAKEUP_TRIES_SHORT_INTERVAL 15
+#define N_WAKEUP_TRIES_LONG_INTERVAL 35
+
/* This function wakes up the card by reading fw_status register. */
static int mwifiex_pm_wakeup_card(struct mwifiex_adapter *adapter)
{
struct pcie_service_card *card = adapter->card;
const struct mwifiex_pcie_card_reg *reg = card->pcie.reg;
+ int n_tries = 0;
mwifiex_dbg(adapter, EVENT,
"event: Wakeup device...\n");
@@ -673,12 +677,29 @@ static int mwifiex_pm_wakeup_card(struct mwifiex_adapter *adapter)
if (reg->sleep_cookie)
mwifiex_pcie_dev_wakeup_delay(adapter);
- /* Accessing fw_status register will wakeup device */
- if (mwifiex_write_reg(adapter, reg->fw_status, FIRMWARE_READY_PCIE)) {
- mwifiex_dbg(adapter, ERROR,
- "Writing fw_status register failed\n");
- return -1;
- }
+ /* Access the fw_status register to wake up the device.
+ * Since the 88W8897 firmware sometimes appears to ignore or miss
+ * that wakeup request, we continue trying until we receive an
+ * interrupt from the card.
+ */
+ do {
+ if (mwifiex_write_reg(adapter, reg->fw_status, FIRMWARE_READY_PCIE)) {
+ mwifiex_dbg(adapter, ERROR,
+ "Writing fw_status register failed\n");
+ return -EIO;
+ }
+
+ n_tries++;
+
+ if (n_tries <= N_WAKEUP_TRIES_SHORT_INTERVAL)
+ usleep_range(400, 700);
+ else
+ msleep(10);
+ } while (n_tries <= N_WAKEUP_TRIES_SHORT_INTERVAL + N_WAKEUP_TRIES_LONG_INTERVAL &&
+ READ_ONCE(adapter->int_status) == 0);
+
+ mwifiex_dbg(adapter, EVENT,
+ "event: Tried %d times until firmware woke up\n", n_tries);
if (reg->sleep_cookie) {
mwifiex_pcie_dev_wakeup_delay(adapter);
--
2.31.1
The patch below does not apply to the 5.10-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 8646e53633f314e4d746a988240d3b951a92f94a Mon Sep 17 00:00:00 2001
From: Sean Christopherson <seanjc(a)google.com>
Date: Wed, 1 Sep 2021 13:30:26 -0700
Subject: [PATCH] KVM: rseq: Update rseq when processing NOTIFY_RESUME on xfer
to KVM guest
Invoke rseq's NOTIFY_RESUME handler when processing the flag prior to
transferring to a KVM guest, which is roughly equivalent to an exit to
userspace and processes many of the same pending actions. While the task
cannot be in an rseq critical section as the KVM path is reachable only
by via ioctl(KVM_RUN), the side effects that apply to rseq outside of a
critical section still apply, e.g. the current CPU needs to be updated if
the task is migrated.
Clearing TIF_NOTIFY_RESUME without informing rseq can lead to segfaults
and other badness in userspace VMMs that use rseq in combination with KVM,
e.g. due to the CPU ID being stale after task migration.
Fixes: 72c3c0fe54a3 ("x86/kvm: Use generic xfer to guest work function")
Reported-by: Peter Foley <pefoley(a)google.com>
Bisected-by: Doug Evans <dje(a)google.com>
Acked-by: Mathieu Desnoyers <mathieu.desnoyers(a)efficios.com>
Cc: Shakeel Butt <shakeelb(a)google.com>
Cc: Thomas Gleixner <tglx(a)linutronix.de>
Cc: stable(a)vger.kernel.org
Signed-off-by: Sean Christopherson <seanjc(a)google.com>
Message-Id: <20210901203030.1292304-2-seanjc(a)google.com>
Signed-off-by: Paolo Bonzini <pbonzini(a)redhat.com>
diff --git a/kernel/entry/kvm.c b/kernel/entry/kvm.c
index 49972ee99aff..049fd06b4c3d 100644
--- a/kernel/entry/kvm.c
+++ b/kernel/entry/kvm.c
@@ -19,8 +19,10 @@ static int xfer_to_guest_mode_work(struct kvm_vcpu *vcpu, unsigned long ti_work)
if (ti_work & _TIF_NEED_RESCHED)
schedule();
- if (ti_work & _TIF_NOTIFY_RESUME)
+ if (ti_work & _TIF_NOTIFY_RESUME) {
tracehook_notify_resume(NULL);
+ rseq_handle_notify_resume(NULL, NULL);
+ }
ret = arch_xfer_to_guest_mode_handle_work(vcpu, ti_work);
if (ret)
diff --git a/kernel/rseq.c b/kernel/rseq.c
index 35f7bd0fced0..6d45ac3dae7f 100644
--- a/kernel/rseq.c
+++ b/kernel/rseq.c
@@ -282,9 +282,17 @@ void __rseq_handle_notify_resume(struct ksignal *ksig, struct pt_regs *regs)
if (unlikely(t->flags & PF_EXITING))
return;
- ret = rseq_ip_fixup(regs);
- if (unlikely(ret < 0))
- goto error;
+
+ /*
+ * regs is NULL if and only if the caller is in a syscall path. Skip
+ * fixup and leave rseq_cs as is so that rseq_sycall() will detect and
+ * kill a misbehaving userspace on debug kernels.
+ */
+ if (regs) {
+ ret = rseq_ip_fixup(regs);
+ if (unlikely(ret < 0))
+ goto error;
+ }
if (unlikely(rseq_update_cpu_id(t)))
goto error;
return;
All 3 upstream commits apply cleanly:
* 5fcfb6d0bfcd ("hso: fix bailout in error case of probe") is a support
patch needed for context
* a6ecfb39ba9d ("usb: hso: fix error handling code of hso_create_net_device")
is the actual fix
* dcb713d53e2e ("usb: hso: remove the bailout parameter") is a follow up
cleanup commit
Dongliang Mu (2):
usb: hso: fix error handling code of hso_create_net_device
usb: hso: remove the bailout parameter
Oliver Neukum (1):
hso: fix bailout in error case of probe
drivers/net/usb/hso.c | 33 +++++++++++++++++++++++----------
1 file changed, 23 insertions(+), 10 deletions(-)
--
2.25.1
From: Suzuki K Poulose <suzuki.poulose(a)arm.com>
commit c0b15c25d25171db4b70cc0b7dbc1130ee94017d upstream.
The erratum 1024718 affects Cortex-A55 r0p0 to r2p0. However
we apply the work around for r0p0 - r1p0. Unfortunately this
won't be fixed for the future revisions for the CPU. Thus
extend the work around for all versions of A55, to cover
for r2p0 and any future revisions.
Cc: stable(a)vger.kernel.org #v4.4 v4.9 v4.14
Cc: Catalin Marinas <catalin.marinas(a)arm.com>
Cc: Will Deacon <will(a)kernel.org>
Cc: James Morse <james.morse(a)arm.com>
Cc: Kunihiko Hayashi <hayashi.kunihiko(a)socionext.com>
Signed-off-by: Suzuki K Poulose <suzuki.poulose(a)arm.com>
Link: https://lore.kernel.org/r/20210203230057.3961239-1-suzuki.poulose@arm.com
[will: Update Kconfig help text]
Signed-off-by: Will Deacon <will(a)kernel.org>
[Nanyon: adjust for stable version below v4.16, which set TCR_HD earlier
in assembly code]
Signed-off-by: Nanyong Sun <sunnanyong(a)huawei.com>
---
arch/arm64/Kconfig | 2 +-
arch/arm64/mm/proc.S | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index e296ae3e20f4..e76f74874a42 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -450,7 +450,7 @@ config ARM64_ERRATUM_1024718
help
This option adds work around for Arm Cortex-A55 Erratum 1024718.
- Affected Cortex-A55 cores (r0p0, r0p1, r1p0) could cause incorrect
+ Affected Cortex-A55 cores (all revisions) could cause incorrect
update of the hardware dirty bit when the DBM/AP bits are updated
without a break-before-make. The work around is to disable the usage
of hardware DBM locally on the affected cores. CPUs not affected by
diff --git a/arch/arm64/mm/proc.S b/arch/arm64/mm/proc.S
index ecbc060807d2..a9ff7fb41832 100644
--- a/arch/arm64/mm/proc.S
+++ b/arch/arm64/mm/proc.S
@@ -455,8 +455,8 @@ ENTRY(__cpu_setup)
cmp x9, #2
b.lt 1f
#ifdef CONFIG_ARM64_ERRATUM_1024718
- /* Disable hardware DBM on Cortex-A55 r0p0, r0p1 & r1p0 */
- cpu_midr_match MIDR_CORTEX_A55, MIDR_CPU_VAR_REV(0, 0), MIDR_CPU_VAR_REV(1, 0), x1, x2, x3, x4
+ /* Disable hardware DBM on Cortex-A55 all versions */
+ cpu_midr_match MIDR_CORTEX_A55, MIDR_CPU_VAR_REV(0, 0), MIDR_CPU_VAR_REV(0xf, 0xf), x1, x2, x3, x4
cbnz x1, 1f
#endif
orr x10, x10, #TCR_HD // hardware Dirty flag update
--
2.17.1
This patch series is present in v5.14 and fixes warnings seen at insmod
with FTRACE and MODULE_PLTS enabled on ARM/Linux.
Changes in v3:
- resolved build error with allmodconfig enabling CONFIG_OLD_MCOUNT
Changes in v2:
- included build fix without DYNAMIC_FTRACE
- preserved Author's original name in 4.9 submission
Alex Sverdlin (4):
ARM: 9077/1: PLT: Move struct plt_entries definition to header
ARM: 9078/1: Add warn suppress parameter to arm_gen_branch_link()
ARM: 9079/1: ftrace: Add MODULE_PLTS support
ARM: 9098/1: ftrace: MODULE_PLT: Fix build problem without
DYNAMIC_FTRACE
arch/arm/include/asm/ftrace.h | 3 +++
arch/arm/include/asm/insn.h | 8 +++---
arch/arm/include/asm/module.h | 10 +++++++
arch/arm/kernel/ftrace.c | 45 +++++++++++++++++++++++++++-----
arch/arm/kernel/insn.c | 19 +++++++-------
arch/arm/kernel/module-plts.c | 49 +++++++++++++++++++++++++++--------
6 files changed, 103 insertions(+), 31 deletions(-)
--
2.25.1
The patch below does not apply to the 5.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 32b2397c1e56f33b0b1881def965bb89bd12f448 Mon Sep 17 00:00:00 2001
From: sumiyawang <sumiyawang(a)tencent.com>
Date: Sun, 22 Aug 2021 19:49:09 +0800
Subject: [PATCH] libnvdimm/pmem: Fix crash triggered when I/O in-flight during
unbind
There is a use after free crash when the pmem driver tears down its
mapping while I/O is still inbound.
This is triggered by driver unbind, "ndctl destroy-namespace", while I/O
is in flight.
Fix the sequence of blk_cleanup_queue() vs memunmap().
The crash signature is of the form:
BUG: unable to handle page fault for address: ffffc90080200000
CPU: 36 PID: 9606 Comm: systemd-udevd
Call Trace:
? pmem_do_bvec+0xf9/0x3a0
? xas_alloc+0x55/0xd0
pmem_rw_page+0x4b/0x80
bdev_read_page+0x86/0xb0
do_mpage_readpage+0x5d4/0x7a0
? lru_cache_add+0xe/0x10
mpage_readpages+0xf9/0x1c0
? bd_link_disk_holder+0x1a0/0x1a0
blkdev_readpages+0x1d/0x20
read_pages+0x67/0x1a0
ndctl Call Trace in vmcore:
PID: 23473 TASK: ffff88c4fbbe8000 CPU: 1 COMMAND: "ndctl"
__schedule
schedule
blk_mq_freeze_queue_wait
blk_freeze_queue
blk_cleanup_queue
pmem_release_queue
devm_action_release
release_nodes
devres_release_all
device_release_driver_internal
device_driver_detach
unbind_store
Cc: <stable(a)vger.kernel.org>
Signed-off-by: sumiyawang <sumiyawang(a)tencent.com>
Reviewed-by: yongduan <yongduan(a)tencent.com>
Link: https://lore.kernel.org/r/1629632949-14749-1-git-send-email-sumiyawang@tenc…
Fixes: 50f44ee7248a ("mm/devm_memremap_pages: fix final page put race")
Signed-off-by: Dan Williams <dan.j.williams(a)intel.com>
diff --git a/drivers/nvdimm/pmem.c b/drivers/nvdimm/pmem.c
index 1e0615b8565e..72de88ff0d30 100644
--- a/drivers/nvdimm/pmem.c
+++ b/drivers/nvdimm/pmem.c
@@ -450,11 +450,11 @@ static int pmem_attach_disk(struct device *dev,
pmem->pfn_flags |= PFN_MAP;
bb_range = pmem->pgmap.range;
} else {
+ addr = devm_memremap(dev, pmem->phys_addr,
+ pmem->size, ARCH_MEMREMAP_PMEM);
if (devm_add_action_or_reset(dev, pmem_release_queue,
&pmem->pgmap))
return -ENOMEM;
- addr = devm_memremap(dev, pmem->phys_addr,
- pmem->size, ARCH_MEMREMAP_PMEM);
bb_range.start = res->start;
bb_range.end = res->end;
}
The patch below does not apply to the 4.19-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 5297cfa6bdf93e3889f78f9b482e2a595a376083 Mon Sep 17 00:00:00 2001
From: Sai Krishna Potthuri <lakshmi.sai.krishna.potthuri(a)xilinx.com>
Date: Wed, 18 Aug 2021 12:53:14 +0530
Subject: [PATCH] EDAC/synopsys: Fix wrong value type assignment for edac_mode
dimm->edac_mode contains values of type enum edac_type - not the
corresponding capability flags. Fix that.
Issue caught by Coverity check "enumerated type mixed with another
type."
[ bp: Rewrite commit message, add tags. ]
Fixes: ae9b56e3996d ("EDAC, synps: Add EDAC support for zynq ddr ecc controller")
Signed-off-by: Sai Krishna Potthuri <lakshmi.sai.krishna.potthuri(a)xilinx.com>
Signed-off-by: Shubhrajyoti Datta <shubhrajyoti.datta(a)xilinx.com>
Signed-off-by: Borislav Petkov <bp(a)suse.de>
Cc: <stable(a)vger.kernel.org>
Link: https://lkml.kernel.org/r/20210818072315.15149-1-shubhrajyoti.datta@xilinx.…
diff --git a/drivers/edac/synopsys_edac.c b/drivers/edac/synopsys_edac.c
index 7e7146b22c16..7d08627e738b 100644
--- a/drivers/edac/synopsys_edac.c
+++ b/drivers/edac/synopsys_edac.c
@@ -782,7 +782,7 @@ static void init_csrows(struct mem_ctl_info *mci)
for (j = 0; j < csi->nr_channels; j++) {
dimm = csi->channels[j]->dimm;
- dimm->edac_mode = EDAC_FLAG_SECDED;
+ dimm->edac_mode = EDAC_SECDED;
dimm->mtype = p_data->get_mtype(priv->baseaddr);
dimm->nr_pages = (size >> PAGE_SHIFT) / csi->nr_channels;
dimm->grain = SYNPS_EDAC_ERR_GRAIN;
Hi reviewers,
I suggest to backport
commit "c739b17a715c net: stmmac: don't attach interface until resume finishes"
to linux-5.4 stable tree.
This patch fix resume issue by deferring netif_device_attach().
However, the patch cannot be cherry-pick directly on to stable-5.4.
A slightly change to the origin patch is required.
I'd like to provide the modification to stable-5.4 if it is needed.
commit: c739b17a715c6a850477189fb7c5f9a6af74f4bb
subject: net: stmmac: don't attach interface until resume finishes
kernel version to apply to: Linux-5.4
Thanks.
Macpaul Lin