From: Francesco Dolcini <francesco.dolcini(a)toradex.com>
Serdev recv_buf() callback is supposed to return the amount of bytes
consumed, therefore an int in between 0 and count.
Do not return negative number in case of issue, when
ssam_controller_receive_buf() returns ESHUTDOWN just returns 0, e.g. no
bytes consumed, this keep the exact same behavior as it was before.
This fixes a potential WARN in serdev-ttyport.c:ttyport_receive_buf().
Cc: <stable(a)vger.kernel.org>
Fixes: c167b9c7e3d6 ("platform/surface: Add Surface Aggregator subsystem")
Signed-off-by: Francesco Dolcini <francesco.dolcini(a)toradex.com>
---
drivers/platform/surface/aggregator/core.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/platform/surface/aggregator/core.c b/drivers/platform/surface/aggregator/core.c
index 1a6373dea109..6152be38398c 100644
--- a/drivers/platform/surface/aggregator/core.c
+++ b/drivers/platform/surface/aggregator/core.c
@@ -231,9 +231,12 @@ static int ssam_receive_buf(struct serdev_device *dev, const unsigned char *buf,
size_t n)
{
struct ssam_controller *ctrl;
+ int ret;
ctrl = serdev_device_get_drvdata(dev);
- return ssam_controller_receive_buf(ctrl, buf, n);
+ ret = ssam_controller_receive_buf(ctrl, buf, n);
+
+ return ret < 0 ? 0 : ret;
}
static void ssam_write_wakeup(struct serdev_device *dev)
--
2.25.1
Hi,
On Sun, Nov 19, 2023 at 06:14:50AM -0700, Jens Axboe wrote:
> On 11/18/23 4:45 PM, Timothy Pearson wrote:
> > During floating point and vector save to thread data fr0/vs0 are clobbered
> > by the FPSCR/VSCR store routine. This leads to userspace register corruption
> > and application data corruption / crash under the following rare condition:
> >
> > * A userspace thread is executing with VSX/FP mode enabled
> > * The userspace thread is making active use of fr0 and/or vs0
> > * An IPI is taken in kernel mode, forcing the userspace thread to reschedule
> > * The userspace thread is interrupted by the IPI before accessing data it
> > previously stored in fr0/vs0
> > * The thread being switched in by the IPI has a pending signal
> >
> > If these exact criteria are met, then the following sequence happens:
> >
> > * The existing thread FP storage is still valid before the IPI, due to a
> > prior call to save_fpu() or store_fp_state(). Note that the current
> > fr0/vs0 registers have been clobbered, so the FP/VSX state in registers
> > is now invalid pending a call to restore_fp()/restore_altivec().
> > * IPI -- FP/VSX register state remains invalid
> > * interrupt_exit_user_prepare_main() calls do_notify_resume(),
> > due to the pending signal
> > * do_notify_resume() eventually calls save_fpu() via giveup_fpu(), which
> > merrily reads and saves the invalid FP/VSX state to thread local storage.
> > * interrupt_exit_user_prepare_main() calls restore_math(), writing the invalid
> > FP/VSX state back to registers.
> > * Execution is released to userspace, and the application crashes or corrupts
> > data.
>
> What an epic bug hunt! Hats off to you for seeing it through and getting
> to the bottom of it. Particularly difficult as the commit that made it
> easier to trigger was in no way related to where the actual bug was.
>
> I ran this on the vm I have access to, and it survived 2x500 iterations.
> Happy to call that good:
>
> Tested-by: Jens Axboe <axboe(a)kernel.dk>
Thanks to all involved!
Is this going to land soon in mainline so it can be picked as well for
the affected stable trees?
Regards,
Salvatore
This commit has no upstream equivalent.
After commit 012dba0ab814 ("PCI: keystone: Don't discard .probe()
callback") in 5.4, there are two modpost warnings when building with
clang:
WARNING: modpost: vmlinux.o(.text+0x5aa6dc): Section mismatch in reference from the function ks_pcie_probe() to the function .init.text:ks_pcie_add_pcie_port()
The function ks_pcie_probe() references
the function __init ks_pcie_add_pcie_port().
This is often because ks_pcie_probe lacks a __init
annotation or the annotation of ks_pcie_add_pcie_port is wrong.
WARNING: modpost: vmlinux.o(.text+0x5aa6f4): Section mismatch in reference from the function ks_pcie_probe() to the function .init.text:ks_pcie_add_pcie_ep()
The function ks_pcie_probe() references
the function __init ks_pcie_add_pcie_ep().
This is often because ks_pcie_probe lacks a __init
annotation or the annotation of ks_pcie_add_pcie_ep is wrong.
ks_pcie_add_pcie_ep() was removed in upstream commit a0fd361db8e5 ("PCI:
dwc: Move "dbi", "dbi2", and "addr_space" resource setup into common
code") and ks_pcie_add_pcie_port() was removed in upstream
commit 60f5b73fa0f2 ("PCI: dwc: Remove unnecessary wrappers around
dw_pcie_host_init()"), both of which happened before upstream
commit 7994db905c0f ("PCI: keystone: Don't discard .probe() callback").
As neither of these removal changes are really suitable for stable, just
remove __init from these functions in stable, as it is no longer a
correct annotation after dropping __init from ks_pcie_probe().
Fixes: 012dba0ab814 ("PCI: keystone: Don't discard .probe() callback")
Reported-by: Naresh Kamboju <naresh.kamboju(a)linaro.org>
Signed-off-by: Nathan Chancellor <nathan(a)kernel.org>
---
This is not an issue in mainline but I still cc'd the author and
committer of 7994db905c0f in case they would like to check my analysis.
---
drivers/pci/controller/dwc/pci-keystone.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/pci/controller/dwc/pci-keystone.c b/drivers/pci/controller/dwc/pci-keystone.c
index ddbb2b3db74a..920444b1cfc7 100644
--- a/drivers/pci/controller/dwc/pci-keystone.c
+++ b/drivers/pci/controller/dwc/pci-keystone.c
@@ -861,8 +861,8 @@ static irqreturn_t ks_pcie_err_irq_handler(int irq, void *priv)
return ks_pcie_handle_error_irq(ks_pcie);
}
-static int __init ks_pcie_add_pcie_port(struct keystone_pcie *ks_pcie,
- struct platform_device *pdev)
+static int ks_pcie_add_pcie_port(struct keystone_pcie *ks_pcie,
+ struct platform_device *pdev)
{
struct dw_pcie *pci = ks_pcie->pci;
struct pcie_port *pp = &pci->pp;
@@ -992,8 +992,8 @@ static const struct dw_pcie_ep_ops ks_pcie_am654_ep_ops = {
.get_features = &ks_pcie_am654_get_features,
};
-static int __init ks_pcie_add_pcie_ep(struct keystone_pcie *ks_pcie,
- struct platform_device *pdev)
+static int ks_pcie_add_pcie_ep(struct keystone_pcie *ks_pcie,
+ struct platform_device *pdev)
{
int ret;
struct dw_pcie_ep *ep;
---
base-commit: 8e221b47173d59e1b2877f6d8dc91e8be2031746
change-id: 20231128-5-4-fix-pci-keystone-modpost-warning-2a8a9c3fa1ca
Best regards,
--
Nathan Chancellor <nathan(a)kernel.org>
From: Claire Lin <claire.lin(a)broadcom.com>
commit 7f852cc1579297fd763789f8cd370639d0c654b6 upstream.
In brcmstb_nand_verify_erased_page(), the ECC chunk pointer calculation
while correcting erased page bitflips is wrong, fix it.
Fixes: 02b88eea9f9c ("mtd: brcmnand: Add check for erased page bitflips")
Signed-off-by: Claire Lin <claire.lin(a)broadcom.com>
Reviewed-by: Ray Jui <ray.jui(a)broadcom.com>
Signed-off-by: Kamal Dasu <kdasu.kdev(a)gmail.com>
Signed-off-by: Miquel Raynal <miquel.raynal(a)bootlin.com>
Signed-off-by: Yuta Hayama <hayama(a)lineo.co.jp>
---
After applying e44b9a9c1357 ("mtd: nand: brcmnand: Zero bitflip is not an
error"), the return value 0 of brcmstb_nand_verify_erased_page() is
*correctly* interpreted as "no bit flips, no errors". However, that
function still has the issue that it may incorrectly return 0 for a page
that contains bitflips. Without this patch, the data buffer of the erased
page could be passed to a upper layer (e.g. UBIFS) without bitflips being
detected and corrected.
In active stable, 4.14.y and 4.19.y seem to have a same issue.
drivers/mtd/nand/raw/brcmnand/brcmnand.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/mtd/nand/raw/brcmnand/brcmnand.c b/drivers/mtd/nand/raw/brcmnand/brcmnand.c
index 0e14892ff926..dc7650ae0464 100644
--- a/drivers/mtd/nand/raw/brcmnand/brcmnand.c
+++ b/drivers/mtd/nand/raw/brcmnand/brcmnand.c
@@ -1753,6 +1753,7 @@ static int brcmstb_nand_verify_erased_page(struct mtd_info *mtd,
int bitflips = 0;
int page = addr >> chip->page_shift;
int ret;
+ void *ecc_chunk;
if (!buf) {
buf = chip->data_buf;
@@ -1768,7 +1769,9 @@ static int brcmstb_nand_verify_erased_page(struct mtd_info *mtd,
return ret;
for (i = 0; i < chip->ecc.steps; i++, oob += sas) {
- ret = nand_check_erased_ecc_chunk(buf, chip->ecc.size,
+ ecc_chunk = buf + chip->ecc.size * i;
+ ret = nand_check_erased_ecc_chunk(ecc_chunk,
+ chip->ecc.size,
oob, sas, NULL, 0,
chip->ecc.strength);
if (ret < 0)
--
2.25.1