The patch below does not apply to the 4.14-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 03e607cbb2931374db1825f371e9c7f28526d3f4 Mon Sep 17 00:00:00 2001
From: Sean Anderson <sean.anderson(a)seco.com>
Date: Mon, 25 Apr 2022 13:14:09 -0400
Subject: [PATCH] usb: phy: generic: Get the vbus supply
While support for working with a vbus was added, the regulator was never
actually gotten (despite what was documented). Fix this by actually
getting the supply from the device tree.
Fixes: 7acc9973e3c4 ("usb: phy: generic: add vbus support")
Cc: stable <stable(a)kernel.org>
Signed-off-by: Sean Anderson <sean.anderson(a)seco.com>
Link: https://lore.kernel.org/r/20220425171412.1188485-3-sean.anderson@seco.com
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
diff --git a/drivers/usb/phy/phy-generic.c b/drivers/usb/phy/phy-generic.c
index 661a229c105d..34b9f8140187 100644
--- a/drivers/usb/phy/phy-generic.c
+++ b/drivers/usb/phy/phy-generic.c
@@ -268,6 +268,13 @@ int usb_phy_gen_create_phy(struct device *dev, struct usb_phy_generic *nop)
return -EPROBE_DEFER;
}
+ nop->vbus_draw = devm_regulator_get_exclusive(dev, "vbus");
+ if (PTR_ERR(nop->vbus_draw) == -ENODEV)
+ nop->vbus_draw = NULL;
+ if (IS_ERR(nop->vbus_draw))
+ return dev_err_probe(dev, PTR_ERR(nop->vbus_draw),
+ "could not get vbus regulator\n");
+
nop->dev = dev;
nop->phy.dev = nop->dev;
nop->phy.label = "nop-xceiv";
The patch below does not apply to the 4.9-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 03e607cbb2931374db1825f371e9c7f28526d3f4 Mon Sep 17 00:00:00 2001
From: Sean Anderson <sean.anderson(a)seco.com>
Date: Mon, 25 Apr 2022 13:14:09 -0400
Subject: [PATCH] usb: phy: generic: Get the vbus supply
While support for working with a vbus was added, the regulator was never
actually gotten (despite what was documented). Fix this by actually
getting the supply from the device tree.
Fixes: 7acc9973e3c4 ("usb: phy: generic: add vbus support")
Cc: stable <stable(a)kernel.org>
Signed-off-by: Sean Anderson <sean.anderson(a)seco.com>
Link: https://lore.kernel.org/r/20220425171412.1188485-3-sean.anderson@seco.com
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
diff --git a/drivers/usb/phy/phy-generic.c b/drivers/usb/phy/phy-generic.c
index 661a229c105d..34b9f8140187 100644
--- a/drivers/usb/phy/phy-generic.c
+++ b/drivers/usb/phy/phy-generic.c
@@ -268,6 +268,13 @@ int usb_phy_gen_create_phy(struct device *dev, struct usb_phy_generic *nop)
return -EPROBE_DEFER;
}
+ nop->vbus_draw = devm_regulator_get_exclusive(dev, "vbus");
+ if (PTR_ERR(nop->vbus_draw) == -ENODEV)
+ nop->vbus_draw = NULL;
+ if (IS_ERR(nop->vbus_draw))
+ return dev_err_probe(dev, PTR_ERR(nop->vbus_draw),
+ "could not get vbus regulator\n");
+
nop->dev = dev;
nop->phy.dev = nop->dev;
nop->phy.label = "nop-xceiv";
The patch below does not apply to the 4.9-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 03e607cbb2931374db1825f371e9c7f28526d3f4 Mon Sep 17 00:00:00 2001
From: Sean Anderson <sean.anderson(a)seco.com>
Date: Mon, 25 Apr 2022 13:14:09 -0400
Subject: [PATCH] usb: phy: generic: Get the vbus supply
While support for working with a vbus was added, the regulator was never
actually gotten (despite what was documented). Fix this by actually
getting the supply from the device tree.
Fixes: 7acc9973e3c4 ("usb: phy: generic: add vbus support")
Cc: stable <stable(a)kernel.org>
Signed-off-by: Sean Anderson <sean.anderson(a)seco.com>
Link: https://lore.kernel.org/r/20220425171412.1188485-3-sean.anderson@seco.com
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
diff --git a/drivers/usb/phy/phy-generic.c b/drivers/usb/phy/phy-generic.c
index 661a229c105d..34b9f8140187 100644
--- a/drivers/usb/phy/phy-generic.c
+++ b/drivers/usb/phy/phy-generic.c
@@ -268,6 +268,13 @@ int usb_phy_gen_create_phy(struct device *dev, struct usb_phy_generic *nop)
return -EPROBE_DEFER;
}
+ nop->vbus_draw = devm_regulator_get_exclusive(dev, "vbus");
+ if (PTR_ERR(nop->vbus_draw) == -ENODEV)
+ nop->vbus_draw = NULL;
+ if (IS_ERR(nop->vbus_draw))
+ return dev_err_probe(dev, PTR_ERR(nop->vbus_draw),
+ "could not get vbus regulator\n");
+
nop->dev = dev;
nop->phy.dev = nop->dev;
nop->phy.label = "nop-xceiv";
The patch below does not apply to the 4.9-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 f4fd84ae0765a80494b28c43b756a95100351a94 Mon Sep 17 00:00:00 2001
From: Thinh Nguyen <Thinh.Nguyen(a)synopsys.com>
Date: Thu, 21 Apr 2022 19:33:56 -0700
Subject: [PATCH] usb: dwc3: core: Only handle soft-reset in DCTL
Make sure not to set run_stop bit or link state change request while
initiating soft-reset. Register read-modify-write operation may
unintentionally start the controller before the initialization completes
with its previous DCTL value, which can cause initialization failure.
Fixes: f59dcab17629 ("usb: dwc3: core: improve reset sequence")
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Thinh Nguyen <Thinh.Nguyen(a)synopsys.com>
Link: https://lore.kernel.org/r/6aecbd78328f102003d40ccf18ceeebd411d3703.16505947…
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index 1ca9dae57855..d28cd1a6709b 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -274,7 +274,8 @@ int dwc3_core_soft_reset(struct dwc3 *dwc)
reg = dwc3_readl(dwc->regs, DWC3_DCTL);
reg |= DWC3_DCTL_CSFTRST;
- dwc3_writel(dwc->regs, DWC3_DCTL, reg);
+ reg &= ~DWC3_DCTL_RUN_STOP;
+ dwc3_gadget_dctl_write_safe(dwc, reg);
/*
* For DWC_usb31 controller 1.90a and later, the DCTL.CSFRST bit
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 1dc9f1a66e1718479e1c4f95514e1750602a3cb9 Mon Sep 17 00:00:00 2001
From: Wang Qing <wangqing(a)vivo.com>
Date: Sun, 10 Apr 2022 19:36:19 -0700
Subject: [PATCH] arch_topology: Do not set llc_sibling if llc_id is invalid
When ACPI is not enabled, cpuid_topo->llc_id = cpu_topo->llc_id = -1, which
will set llc_sibling 0xff(...), this is misleading.
Don't set llc_sibling(default 0) if we don't know the cache topology.
Reviewed-by: Sudeep Holla <sudeep.holla(a)arm.com>
Signed-off-by: Wang Qing <wangqing(a)vivo.com>
Fixes: 37c3ec2d810f ("arm64: topology: divorce MC scheduling domain from core_siblings")
Cc: stable <stable(a)vger.kernel.org>
Link: https://lore.kernel.org/r/1649644580-54626-1-git-send-email-wangqing@vivo.c…
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
diff --git a/drivers/base/arch_topology.c b/drivers/base/arch_topology.c
index 5497c5ab7318..f73b836047cf 100644
--- a/drivers/base/arch_topology.c
+++ b/drivers/base/arch_topology.c
@@ -693,7 +693,7 @@ void update_siblings_masks(unsigned int cpuid)
for_each_online_cpu(cpu) {
cpu_topo = &cpu_topology[cpu];
- if (cpuid_topo->llc_id == cpu_topo->llc_id) {
+ if (cpu_topo->llc_id != -1 && cpuid_topo->llc_id == cpu_topo->llc_id) {
cpumask_set_cpu(cpu, &cpuid_topo->llc_sibling);
cpumask_set_cpu(cpuid, &cpu_topo->llc_sibling);
}
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 b3fa25de31fb7e9afebe9599b8ff32eda13d7c94 Mon Sep 17 00:00:00 2001
From: Pawel Laszczak <pawell(a)cadence.com>
Date: Tue, 29 Mar 2022 10:46:05 +0200
Subject: [PATCH] usb: cdns3: Fix issue for clear halt endpoint
Path fixes bug which occurs during resetting endpoint in
__cdns3_gadget_ep_clear_halt function. During resetting endpoint
controller will change HW/DMA owned TRB. It set Abort flag in
trb->control and will change trb->length field. If driver want
to use the aborted trb it must update the changed field in
TRB.
Fixes: 7733f6c32e36 ("usb: cdns3: Add Cadence USB3 DRD Driver")
cc: <stable(a)vger.kernel.org>
Acked-by: Peter Chen <peter.chen(a)kernel.org>
Signed-off-by: Pawel Laszczak <pawell(a)cadence.com>
Link: https://lore.kernel.org/r/20220329084605.4022-1-pawell@cadence.com
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
diff --git a/drivers/usb/cdns3/cdns3-gadget.c b/drivers/usb/cdns3/cdns3-gadget.c
index f9af7ebe003d..d6d515d598dc 100644
--- a/drivers/usb/cdns3/cdns3-gadget.c
+++ b/drivers/usb/cdns3/cdns3-gadget.c
@@ -2684,6 +2684,7 @@ int __cdns3_gadget_ep_clear_halt(struct cdns3_endpoint *priv_ep)
struct usb_request *request;
struct cdns3_request *priv_req;
struct cdns3_trb *trb = NULL;
+ struct cdns3_trb trb_tmp;
int ret;
int val;
@@ -2693,8 +2694,10 @@ int __cdns3_gadget_ep_clear_halt(struct cdns3_endpoint *priv_ep)
if (request) {
priv_req = to_cdns3_request(request);
trb = priv_req->trb;
- if (trb)
+ if (trb) {
+ trb_tmp = *trb;
trb->control = trb->control ^ cpu_to_le32(TRB_CYCLE);
+ }
}
writel(EP_CMD_CSTALL | EP_CMD_EPRST, &priv_dev->regs->ep_cmd);
@@ -2709,7 +2712,7 @@ int __cdns3_gadget_ep_clear_halt(struct cdns3_endpoint *priv_ep)
if (request) {
if (trb)
- trb->control = trb->control ^ cpu_to_le32(TRB_CYCLE);
+ *trb = trb_tmp;
cdns3_rearm_transfer(priv_ep, 1);
}
The patch below does not apply to the 5.15-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 74a53a959028e5f28e3c0e9445a876e5c8da147c Mon Sep 17 00:00:00 2001
From: Stephen Boyd <swboyd(a)chromium.org>
Date: Thu, 31 Mar 2022 14:04:25 -0700
Subject: [PATCH] iio:proximity:sx_common: Fix device property parsing on DT
systems
After commit 7a3605bef878 ("iio: sx9310: Support ACPI property") we
started using the 'indio_dev->dev' to extract device properties for
various register settings in sx9310_get_default_reg(). This broke DT
based systems because dev_fwnode() used in the device_property*() APIs
can't find an 'of_node'. That's because the 'indio_dev->dev.of_node'
pointer isn't set until iio_device_register() is called. Set the pointer
earlier, next to where the ACPI companion is set, so that the device
property APIs work on DT systems.
Cc: Gwendal Grignou <gwendal(a)chromium.org>
Fixes: 7a3605bef878 ("iio: sx9310: Support ACPI property")
Signed-off-by: Stephen Boyd <swboyd(a)chromium.org>
Reviewed-by: Gwendal Grignou <gwendal(a)chromium.org>
Link: https://lore.kernel.org/r/20220331210425.3908278-1-swboyd@chromium.org
Cc: <Stable(a)vger.kernel.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron(a)huawei.com>
diff --git a/drivers/iio/proximity/sx_common.c b/drivers/iio/proximity/sx_common.c
index a7c07316a0a9..8ad814d96b7e 100644
--- a/drivers/iio/proximity/sx_common.c
+++ b/drivers/iio/proximity/sx_common.c
@@ -521,6 +521,7 @@ int sx_common_probe(struct i2c_client *client,
return dev_err_probe(dev, ret, "error reading WHOAMI\n");
ACPI_COMPANION_SET(&indio_dev->dev, ACPI_COMPANION(dev));
+ indio_dev->dev.of_node = client->dev.of_node;
indio_dev->modes = INDIO_DIRECT_MODE;
indio_dev->channels = data->chip_info->iio_channels;
The patch below does not apply to the 5.17-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 74a53a959028e5f28e3c0e9445a876e5c8da147c Mon Sep 17 00:00:00 2001
From: Stephen Boyd <swboyd(a)chromium.org>
Date: Thu, 31 Mar 2022 14:04:25 -0700
Subject: [PATCH] iio:proximity:sx_common: Fix device property parsing on DT
systems
After commit 7a3605bef878 ("iio: sx9310: Support ACPI property") we
started using the 'indio_dev->dev' to extract device properties for
various register settings in sx9310_get_default_reg(). This broke DT
based systems because dev_fwnode() used in the device_property*() APIs
can't find an 'of_node'. That's because the 'indio_dev->dev.of_node'
pointer isn't set until iio_device_register() is called. Set the pointer
earlier, next to where the ACPI companion is set, so that the device
property APIs work on DT systems.
Cc: Gwendal Grignou <gwendal(a)chromium.org>
Fixes: 7a3605bef878 ("iio: sx9310: Support ACPI property")
Signed-off-by: Stephen Boyd <swboyd(a)chromium.org>
Reviewed-by: Gwendal Grignou <gwendal(a)chromium.org>
Link: https://lore.kernel.org/r/20220331210425.3908278-1-swboyd@chromium.org
Cc: <Stable(a)vger.kernel.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron(a)huawei.com>
diff --git a/drivers/iio/proximity/sx_common.c b/drivers/iio/proximity/sx_common.c
index a7c07316a0a9..8ad814d96b7e 100644
--- a/drivers/iio/proximity/sx_common.c
+++ b/drivers/iio/proximity/sx_common.c
@@ -521,6 +521,7 @@ int sx_common_probe(struct i2c_client *client,
return dev_err_probe(dev, ret, "error reading WHOAMI\n");
ACPI_COMPANION_SET(&indio_dev->dev, ACPI_COMPANION(dev));
+ indio_dev->dev.of_node = client->dev.of_node;
indio_dev->modes = INDIO_DIRECT_MODE;
indio_dev->channels = data->chip_info->iio_channels;
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 33597f0c48be0836854d43c577e35c8f8a765a7d Mon Sep 17 00:00:00 2001
From: Mathias Nyman <mathias.nyman(a)linux.intel.com>
Date: Fri, 8 Apr 2022 16:48:23 +0300
Subject: [PATCH] xhci: increase usb U3 -> U0 link resume timeout from 100ms to
500ms
The first U3 wake signal by the host may be lost if the USB 3 connection is
tunneled over USB4, with a runtime suspended USB4 host, and firmware
implemented connection manager.
Specs state the host must wait 100ms (tU3WakeupRetryDelay) before
resending a U3 wake signal if device doesn't respond, leading to U3 -> U0
link transition times around 270ms in the tunneled case.
Fixes: 0200b9f790b0 ("xhci: Wait until link state trainsits to U0 after setting USB_SS_PORT_LS_U0")
Cc: stable(a)vger.kernel.org
Signed-off-by: Mathias Nyman <mathias.nyman(a)linux.intel.com>
Link: https://lore.kernel.org/r/20220408134823.2527272-4-mathias.nyman@linux.inte…
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
diff --git a/drivers/usb/host/xhci-hub.c b/drivers/usb/host/xhci-hub.c
index 1e7dc130c39a..f65f1ba2b592 100644
--- a/drivers/usb/host/xhci-hub.c
+++ b/drivers/usb/host/xhci-hub.c
@@ -1434,7 +1434,7 @@ int xhci_hub_control(struct usb_hcd *hcd, u16 typeReq, u16 wValue,
}
spin_unlock_irqrestore(&xhci->lock, flags);
if (!wait_for_completion_timeout(&bus_state->u3exit_done[wIndex],
- msecs_to_jiffies(100)))
+ msecs_to_jiffies(500)))
xhci_dbg(xhci, "missing U0 port change event for port %d-%d\n",
hcd->self.busnum, wIndex + 1);
spin_lock_irqsave(&xhci->lock, flags);
I'm announcing the release of the 4.19.241 kernel.
All users of the 4.19 kernel series must upgrade.
The updated 4.19.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-4.19.y
and can be browsed at the normal kernel.org git web browser:
https://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary
thanks,
greg k-h
------------
Makefile | 2
arch/ia64/kernel/kprobes.c | 78 +++++++++++++++++++-
arch/powerpc/include/asm/exception-64s.h | 37 +++++----
drivers/block/Kconfig | 16 ++++
drivers/block/floppy.c | 43 ++++++++---
drivers/lightnvm/Kconfig | 2
drivers/media/platform/vicodec/vicodec-core.c | 6 -
drivers/net/ethernet/stmicro/stmmac/altr_tse_pcs.c | 8 ++
drivers/net/ethernet/stmicro/stmmac/altr_tse_pcs.h | 4 -
drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c | 13 ++-
drivers/net/hamradio/6pack.c | 5 -
net/sched/cls_u32.c | 18 ++--
12 files changed, 180 insertions(+), 52 deletions(-)
Dafna Hirschfeld (1):
media: vicodec: upon release, call m2m release before freeing ctrl handler
Eric Dumazet (1):
net/sched: cls_u32: fix netns refcount changes in u32_change()
Greg Kroah-Hartman (3):
Revert "net: ethernet: stmmac: fix altr_tse_pcs function when using a fixed-link"
lightnvm: disable the subsystem
Linux 4.19.241
Lin Ma (2):
hamradio: defer 6pack kfree after unregister_netdev
hamradio: remove needs_free_netdev to avoid UAF
Masami Hiramatsu (3):
Revert "ia64: kprobes: Fix to pass correct trampoline address to the handler"
Revert "ia64: kprobes: Use generic kretprobe trampoline handler"
ia64: kprobes: Fix to pass correct trampoline address to the handler
Michael Ellerman (1):
powerpc/64s: Unmerge EX_LR and EX_DAR
Nicholas Piggin (1):
powerpc/64/interrupt: Temporarily save PPR on stack to fix register corruption due to SLB miss
Willy Tarreau (1):
floppy: disable FDRAWCMD by default
Based on DesignWare Ethernet QoS datasheet, we are seeing the limitation
of Split Header (SPH) feature is not supported for Ipv4 fragmented packet.
This SPH limitation will cause ping failure when the packets size exceed
the MTU size. For example, the issue happens once the basic ping packet
size is larger than the configured MTU size and the data is lost inside
the fragmented packet, replaced by zeros/corrupted values, and leads to
ping fail.
So, disable the Split Header for Intel platforms.
v2: Add fixes tag in commit message.
Fixes: 67afd6d1cfdf("net: stmmac: Add Split Header support and enable it
in XGMAC cores")
Cc: <stable(a)vger.kernel.org> # 5.10.x
Suggested-by: Ong, Boon Leong <boon.leong.ong(a)intel.com>
Signed-off-by: Mohammad Athari Bin Ismail <mohammad.athari.ismail(a)intel.com>
Signed-off-by: Wong Vee Khee <vee.khee.wong(a)linux.intel.com>
Signed-off-by: Tan Tee Min <tee.min.tan(a)linux.intel.com>
---
drivers/net/ethernet/stmicro/stmmac/dwmac-intel.c | 1 +
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 2 +-
include/linux/stmmac.h | 1 +
3 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-intel.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-intel.c
index 63754a9c4ba7..0b0be0898ac5 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-intel.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-intel.c
@@ -454,6 +454,7 @@ static int intel_mgbe_common_data(struct pci_dev *pdev,
plat->has_gmac4 = 1;
plat->force_sf_dma_mode = 0;
plat->tso_en = 1;
+ plat->sph_disable = 1;
/* Multiplying factor to the clk_eee_i clock time
* period to make it closer to 100 ns. This value
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 4a4b3651ab3e..2525a80353b7 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -7021,7 +7021,7 @@ int stmmac_dvr_probe(struct device *device,
dev_info(priv->device, "TSO feature enabled\n");
}
- if (priv->dma_cap.sphen) {
+ if (priv->dma_cap.sphen && !priv->plat->sph_disable) {
ndev->hw_features |= NETIF_F_GRO;
priv->sph_cap = true;
priv->sph = priv->sph_cap;
diff --git a/include/linux/stmmac.h b/include/linux/stmmac.h
index 24eea1b05ca2..29917850f079 100644
--- a/include/linux/stmmac.h
+++ b/include/linux/stmmac.h
@@ -270,5 +270,6 @@ struct plat_stmmacenet_data {
int msi_rx_base_vec;
int msi_tx_base_vec;
bool use_phy_wol;
+ bool sph_disable;
};
#endif
--
2.25.1
From: Hugh Dickins <hughd(a)google.com>
Twice now, when exercising ext4 looped on shmem huge pages, I have crashed
on the PF_ONLY_HEAD check inside PageWaiters(): ext4_finish_bio() calling
end_page_writeback() calling wake_up_page() on tail of a shmem huge page,
no longer an ext4 page at all.
The problem is that PageWriteback is not accompanied by a page reference
(as the NOTE at the end of test_clear_page_writeback() acknowledges): as
soon as TestClearPageWriteback has been done, that page could be removed
from page cache, freed, and reused for something else by the time that
wake_up_page() is reached.
https://lore.kernel.org/linux-mm/20200827122019.GC14765@casper.infradead.or…
Matthew Wilcox suggested avoiding or weakening the PageWaiters() tail
check; but I'm paranoid about even looking at an unreferenced struct page,
lest its memory might itself have already been reused or hotremoved (and
wake_up_page_bit() may modify that memory with its ClearPageWaiters()).
Then on crashing a second time, realized there's a stronger reason against
that approach. If my testing just occasionally crashes on that check,
when the page is reused for part of a compound page, wouldn't it be much
more common for the page to get reused as an order-0 page before reaching
wake_up_page()? And on rare occasions, might that reused page already be
marked PageWriteback by its new user, and already be waited upon? What
would that look like?
It would look like BUG_ON(PageWriteback) after wait_on_page_writeback()
in write_cache_pages() (though I have never seen that crash myself).
Matthew Wilcox explaining this to himself:
"page is allocated, added to page cache, dirtied, writeback starts,
--- thread A ---
filesystem calls end_page_writeback()
test_clear_page_writeback()
--- context switch to thread B ---
truncate_inode_pages_range() finds the page, it doesn't have writeback set,
we delete it from the page cache. Page gets reallocated, dirtied, writeback
starts again. Then we call write_cache_pages(), see
PageWriteback() set, call wait_on_page_writeback()
--- context switch back to thread A ---
wake_up_page(page, PG_writeback);
... thread B is woken, but because the wakeup was for the old use of
the page, PageWriteback is still set.
Devious"
And prior to 2a9127fcf229 ("mm: rewrite wait_on_page_bit_common() logic")
this would have been much less likely: before that, wake_page_function()'s
non-exclusive case would stop walking and not wake if it found Writeback
already set again; whereas now the non-exclusive case proceeds to wake.
I have not thought of a fix that does not add a little overhead: the
simplest fix is for end_page_writeback() to get_page() before calling
test_clear_page_writeback(), then put_page() after wake_up_page().
Was there a chance of missed wakeups before, since a page freed before
reaching wake_up_page() would have PageWaiters cleared? I think not,
because each waiter does hold a reference on the page. This bug comes
when the old use of the page, the one we do TestClearPageWriteback on,
had *no* waiters, so no additional page reference beyond the page cache
(and whoever racily freed it). The reuse of the page has a waiter
holding a reference, and its own PageWriteback set; but the belated
wake_up_page() has woken the reuse to hit that BUG_ON(PageWriteback).
Orabug: 33634162
Reported-by: syzbot+3622cea378100f45d59f(a)syzkaller.appspotmail.com
Reported-by: Qian Cai <cai(a)lca.pw>
Fixes: 2a9127fcf229 ("mm: rewrite wait_on_page_bit_common() logic")
Signed-off-by: Hugh Dickins <hughd(a)google.com>
Cc: stable(a)vger.kernel.org # v5.8+
Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org>
(cherry picked from commit 073861ed77b6b957c3c8d54a11dc503f7d986ceb)
Signed-off-by: Partha Sarathi Satapathy <partha.satapathy(a)oracle.com>
---
mm/filemap.c | 8 ++++++++
mm/page-writeback.c | 6 ------
2 files changed, 8 insertions(+), 6 deletions(-)
diff --git a/mm/filemap.c b/mm/filemap.c
index dc20b49..336a065 100644
--- a/mm/filemap.c
+++ b/mm/filemap.c
@@ -1366,11 +1366,19 @@ void end_page_writeback(struct page *page)
rotate_reclaimable_page(page);
}
+ /*
+ * Writeback does not hold a page reference of its own, relying
+ * on truncation to wait for the clearing of PG_writeback.
+ * But here we must make sure that the page is not freed and
+ * reused before the wake_up_page().
+ */
+ get_page(page);
if (!test_clear_page_writeback(page))
BUG();
smp_mb__after_atomic();
wake_up_page(page, PG_writeback);
+ put_page(page);
}
EXPORT_SYMBOL(end_page_writeback);
diff --git a/mm/page-writeback.c b/mm/page-writeback.c
index 2d658b2..52d3006 100644
--- a/mm/page-writeback.c
+++ b/mm/page-writeback.c
@@ -2746,12 +2746,6 @@ int test_clear_page_writeback(struct page *page)
} else {
ret = TestClearPageWriteback(page);
}
- /*
- * NOTE: Page might be free now! Writeback doesn't hold a page
- * reference on its own, it relies on truncation to wait for
- * the clearing of PG_writeback. The below can only access
- * page state that is static across allocation cycles.
- */
if (ret) {
dec_lruvec_state(lruvec, NR_WRITEBACK);
dec_zone_page_state(page, NR_ZONE_WRITE_PENDING);
--
1.8.3.1
The following commit has been merged into the x86/urgent branch of tip:
Commit-ID: 7e0815b3e09986d2fe651199363e135b9358132a
Gitweb: https://git.kernel.org/tip/7e0815b3e09986d2fe651199363e135b9358132a
Author: Thomas Gleixner <tglx(a)linutronix.de>
AuthorDate: Thu, 28 Apr 2022 15:50:54 +02:00
Committer: Thomas Gleixner <tglx(a)linutronix.de>
CommitterDate: Fri, 29 Apr 2022 14:37:39 +02:00
x86/pci/xen: Disable PCI/MSI[-X] masking for XEN_HVM guests
When a XEN_HVM guest uses the XEN PIRQ/Eventchannel mechanism, then
PCI/MSI[-X] masking is solely controlled by the hypervisor, but contrary to
XEN_PV guests this does not disable PCI/MSI[-X] masking in the PCI/MSI
layer.
This can lead to a situation where the PCI/MSI layer masks an MSI[-X]
interrupt and the hypervisor grants the write despite the fact that it
already requested the interrupt. As a consequence interrupt delivery on the
affected device is not happening ever.
Set pci_msi_ignore_mask to prevent that like it's done for XEN_PV guests
already.
Fixes: 809f9267bbab ("xen: map MSIs into pirqs")
Reported-by: Jeremi Piotrowski <jpiotrowski(a)linux.microsoft.com>
Reported-by: Dusty Mabe <dustymabe(a)redhat.com>
Reported-by: Salvatore Bonaccorso <carnil(a)debian.org>
Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de>
Tested-by: Noah Meyerhans <noahm(a)debian.org>
Cc: stable(a)vger.kernel.org
Link: https://lore.kernel.org/r/87tuaduxj5.ffs@tglx
---
arch/x86/pci/xen.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/arch/x86/pci/xen.c b/arch/x86/pci/xen.c
index 9bb1e29..b94f727 100644
--- a/arch/x86/pci/xen.c
+++ b/arch/x86/pci/xen.c
@@ -467,7 +467,6 @@ static __init void xen_setup_pci_msi(void)
else
xen_msi_ops.setup_msi_irqs = xen_setup_msi_irqs;
xen_msi_ops.teardown_msi_irqs = xen_pv_teardown_msi_irqs;
- pci_msi_ignore_mask = 1;
} else if (xen_hvm_domain()) {
xen_msi_ops.setup_msi_irqs = xen_hvm_setup_msi_irqs;
xen_msi_ops.teardown_msi_irqs = xen_teardown_msi_irqs;
@@ -481,6 +480,11 @@ static __init void xen_setup_pci_msi(void)
* in allocating the native domain and never use it.
*/
x86_init.irqs.create_pci_msi_domain = xen_create_pci_msi_domain;
+ /*
+ * With XEN PIRQ/Eventchannels in use PCI/MSI[-X] masking is solely
+ * controlled by the hypervisor.
+ */
+ pci_msi_ignore_mask = 1;
}
#else /* CONFIG_PCI_MSI */
Save some CPU from unnecessary polling and make SPI flash reading
a tiny bit faster.
Cc: <stable(a)vger.kernel.org> # v5.7+
Fixes: 23beb1adb5f6 ("arm64: dts: mt7622: add flash related device nodes")
Signed-off-by: Chuanhong Guo <gch981213(a)gmail.com>
---
The nor controller driver in kernem when this dt is added doesn't
support IRQ so there isn't one defined in dt back then. However,
device-tree is supposed to describe the hardware, so I think this
can count as a fix.
My main purpose for the fixes tag is just for the linux-stable
backport though. spi-mtk-nor supports interrupt since v5.7.
arch/arm64/boot/dts/mediatek/mt7622.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/boot/dts/mediatek/mt7622.dtsi b/arch/arm64/boot/dts/mediatek/mt7622.dtsi
index 8c2563a3919a..e263a81a011b 100644
--- a/arch/arm64/boot/dts/mediatek/mt7622.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt7622.dtsi
@@ -570,6 +570,7 @@ nor_flash: spi@11014000 {
compatible = "mediatek,mt7622-nor",
"mediatek,mt8173-nor";
reg = <0 0x11014000 0 0xe0>;
+ interrupts = <GIC_SPI 88 IRQ_TYPE_LEVEL_LOW>;
clocks = <&pericfg CLK_PERI_FLASH_PD>,
<&topckgen CLK_TOP_FLASH_SEL>;
clock-names = "spi", "sf";
--
2.35.1
Remove unsupported forcing of `cpu_has_fpu' to 1, which makes the `nofpu'
kernel parameter non-functional, and also causes a link error:
ld: arch/mips/kernel/traps.o: in function `trap_init':
./arch/mips/include/asm/msa.h:(.init.text+0x348): undefined reference to `handle_fpe'
ld: ./arch/mips/include/asm/msa.h:(.init.text+0x354): undefined reference to `handle_fpe'
ld: ./arch/mips/include/asm/msa.h:(.init.text+0x360): undefined reference to `handle_fpe'
where the CONFIG_MIPS_FP_SUPPORT configuration option has been disabled.
Signed-off-by: Maciej W. Rozycki <macro(a)orcam.me.uk>
Fixes: 7505576d1c1a ("MIPS: add support for SGI Octane (IP30)")
Cc: stable(a)vger.kernel.org # v5.5+
---
Changes from v1:
- s/chosen/disabled/ in the change description.
---
arch/mips/include/asm/mach-ip30/cpu-feature-overrides.h | 1 -
1 file changed, 1 deletion(-)
linux-mips-ip30-cpu-has-fpu.diff
Index: linux-macro/arch/mips/include/asm/mach-ip30/cpu-feature-overrides.h
===================================================================
--- linux-macro.orig/arch/mips/include/asm/mach-ip30/cpu-feature-overrides.h
+++ linux-macro/arch/mips/include/asm/mach-ip30/cpu-feature-overrides.h
@@ -28,7 +28,6 @@
#define cpu_has_4kex 1
#define cpu_has_3k_cache 0
#define cpu_has_4k_cache 1
-#define cpu_has_fpu 1
#define cpu_has_nofpuex 0
#define cpu_has_32fpr 1
#define cpu_has_counter 1
Remove unsupported forcing of `cpu_has_fpu' to 1, which makes the `nofpu'
kernel parameter non-functional, and also causes a link error:
ld: arch/mips/kernel/traps.o: in function `trap_init':
./arch/mips/include/asm/msa.h:(.init.text+0x348): undefined reference to `handle_fpe'
ld: ./arch/mips/include/asm/msa.h:(.init.text+0x354): undefined reference to `handle_fpe'
ld: ./arch/mips/include/asm/msa.h:(.init.text+0x360): undefined reference to `handle_fpe'
where the CONFIG_MIPS_FP_SUPPORT configuration option has been disabled.
Signed-off-by: Maciej W. Rozycki <macro(a)orcam.me.uk>
Fixes: 0ebb2f4159af ("MIPS: IP27: Update/restructure CPU overrides")
Cc: stable(a)vger.kernel.org # v4.2+
---
Changes from v1:
- s/chosen/disabled/ in the change description.
---
arch/mips/include/asm/mach-ip27/cpu-feature-overrides.h | 1 -
1 file changed, 1 deletion(-)
linux-mips-ip27-cpu-has-fpu.diff
Index: linux-macro/arch/mips/include/asm/mach-ip27/cpu-feature-overrides.h
===================================================================
--- linux-macro.orig/arch/mips/include/asm/mach-ip27/cpu-feature-overrides.h
+++ linux-macro/arch/mips/include/asm/mach-ip27/cpu-feature-overrides.h
@@ -25,7 +25,6 @@
#define cpu_has_4kex 1
#define cpu_has_3k_cache 0
#define cpu_has_4k_cache 1
-#define cpu_has_fpu 1
#define cpu_has_nofpuex 0
#define cpu_has_32fpr 1
#define cpu_has_counter 1
As Yanming reported in bugzilla:
https://bugzilla.kernel.org/show_bug.cgi?id=215904
The kernel message is shown below:
kernel BUG at fs/f2fs/inode.c:825!
Call Trace:
evict+0x282/0x4e0
__dentry_kill+0x2b2/0x4d0
shrink_dentry_list+0x17c/0x4f0
shrink_dcache_parent+0x143/0x1e0
do_one_tree+0x9/0x30
shrink_dcache_for_umount+0x51/0x120
generic_shutdown_super+0x5c/0x3a0
kill_block_super+0x90/0xd0
kill_f2fs_super+0x225/0x310
deactivate_locked_super+0x78/0xc0
cleanup_mnt+0x2b7/0x480
task_work_run+0xc8/0x150
exit_to_user_mode_prepare+0x14a/0x150
syscall_exit_to_user_mode+0x1d/0x40
do_syscall_64+0x48/0x90
The root cause is: inode node and dnode node share the same nid,
so during f2fs_evict_inode(), dnode node truncation will invalidate
its NAT entry, so when truncating inode node, it fails due to
invalid NAT entry, result in inode is still marked as dirty, fix
this issue by clearing dirty for inode and setting SBI_NEED_FSCK
flag in filesystem.
output from dump.f2fs:
[print_node_info: 354] Node ID [0xf:15] is inode
i_nid[0] [0x f : 15]
Cc: stable(a)vger.kernel.org
Reported-by: Ming Yan <yanming(a)tju.edu.cn>
Signed-off-by: Chao Yu <chao.yu(a)oppo.com>
---
fs/f2fs/inode.c | 16 +++++++++++++++-
1 file changed, 15 insertions(+), 1 deletion(-)
diff --git a/fs/f2fs/inode.c b/fs/f2fs/inode.c
index 234b8ed02644..030474b842ce 100644
--- a/fs/f2fs/inode.c
+++ b/fs/f2fs/inode.c
@@ -795,8 +795,22 @@ void f2fs_evict_inode(struct inode *inode)
f2fs_lock_op(sbi);
err = f2fs_remove_inode_page(inode);
f2fs_unlock_op(sbi);
- if (err == -ENOENT)
+ if (err == -ENOENT) {
err = 0;
+
+ /*
+ * in fuzzed image, another node may has the same
+ * block address as inode's, if it was truncated
+ * previously, truncation of inode node will fail.
+ */
+ if (is_inode_flag_set(inode, FI_DIRTY_INODE)) {
+ f2fs_warn(F2FS_I_SB(inode),
+ "f2fs_evict_inode: inconsistent node id, ino:%lu",
+ inode->i_ino);
+ f2fs_inode_synced(inode);
+ set_sbi_flag(sbi, SBI_NEED_FSCK);
+ }
+ }
}
/* give more chances, if ENOMEM case */
--
2.25.1
Hello Dear
I am glad to know you, but God knows you better and he knows why he
has directed me to you at this point in time so do not be surprised at
all. My name is Mrs.Sophia Erick, a widow, i have been suffering from
ovarian cancer disease. At this moment i am about to end the race like
this because the illness has gotten to a very bad stage, without any
family members and no child. I hope that you will not expose or betray
this trust and confidence that I am about to entrust to you for the
mutual benefit of the orphans and the less privileged ones. I have
some funds I inherited from my late husband,the sum of ($11.000.000
Eleven million dollars.) deposited in the Bank. Having known my
present health status, I decided to entrust this fund to you believing
that you will utilize it the way i am going to instruct
herein.Therefore I need you to assist me and reclaim this money and
use it for Charity works, for orphanages and giving justice and help
to the poor, needy and to promote the words of God and the effort that
the house of God will be maintained says The Lord." Jeremiah
22:15-16.“
It will be my great pleasure to compensate you with 35 % percent of
the total money for your personal use, 5 % percent for any expenses
that may occur during the international transfer process while 60% of
the money will go to the charity project. All I require from you is
sincerity and the ability to complete God's task without any failure.
It will be my pleasure to see that the bank has finally released and
transferred the fund into your bank account therein your country even
before I die here in the hospital, because of my present health status
everything needs to be processed rapidly as soon as possible. Please
kindly respond quickly. Thanks and God bless you,
May God Bless you for your kind help.
Yours sincerely sister Mrs. Sophia Erick.
This is the start of the stable review cycle for the 4.19.240 release.
There are 53 patches in this series, all will be posted as a response
to this one. If anyone has any issues with these being applied, please
let me know.
Responses should be made by Thu, 28 Apr 2022 08:17:22 +0000.
Anything received after that time might be too late.
The whole patch series can be found in one patch at:
https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.19.240-r…
or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.19.y
and the diffstat can be found below.
thanks,
greg k-h
-------------
Pseudo-Shortlog of commits:
Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Linux 4.19.240-rc1
Marek Vasut <marex(a)denx.de>
Revert "net: micrel: fix KS8851_MLL Kconfig"
Duoming Zhou <duoming(a)zju.edu.cn>
ax25: Fix UAF bugs in ax25 timers
Duoming Zhou <duoming(a)zju.edu.cn>
ax25: Fix NULL pointer dereferences in ax25 timers
Duoming Zhou <duoming(a)zju.edu.cn>
ax25: fix NPD bug in ax25_disconnect
Duoming Zhou <duoming(a)zju.edu.cn>
ax25: fix UAF bug in ax25_send_control()
Duoming Zhou <duoming(a)zju.edu.cn>
ax25: Fix refcount leaks caused by ax25_cb_del()
Duoming Zhou <duoming(a)zju.edu.cn>
ax25: fix UAF bugs of net_device caused by rebinding operation
Duoming Zhou <duoming(a)zju.edu.cn>
ax25: fix reference count leaks of ax25_dev
Duoming Zhou <duoming(a)zju.edu.cn>
ax25: add refcount in ax25_dev to avoid UAF bugs
Khazhismel Kumykov <khazhy(a)google.com>
block/compat_ioctl: fix range check in BLKGETSIZE
Lee Jones <lee.jones(a)linaro.org>
staging: ion: Prevent incorrect reference counting behavour
Theodore Ts'o <tytso(a)mit.edu>
ext4: force overhead calculation if the s_overhead_cluster makes no sense
Theodore Ts'o <tytso(a)mit.edu>
ext4: fix overhead calculation to account for the reserved gdt blocks
Tadeusz Struk <tadeusz.struk(a)linaro.org>
ext4: limit length to bitmap_maxbytes - blocksize in punch_hole
Ye Bin <yebin10(a)huawei.com>
ext4: fix symlink file size not match to file content
Rob Herring <robh(a)kernel.org>
arm_pmu: Validate single/group leader events
Sergey Matyukevich <sergey.matyukevich(a)synopsys.com>
ARC: entry: fix syscall_trace_exit argument
Sasha Neftin <sasha.neftin(a)intel.com>
e1000e: Fix possible overflow in LTR decoding
Xiaomeng Tong <xiam0nd.tong(a)gmail.com>
ASoC: soc-dapm: fix two incorrect uses of list iterator
Paolo Valerio <pvalerio(a)redhat.com>
openvswitch: fix OOB access in reserve_sfa_size()
Athira Rajeev <atrajeev(a)linux.vnet.ibm.com>
powerpc/perf: Fix power9 event alternatives
Dave Stevenson <dave.stevenson(a)raspberrypi.com>
drm/panel/raspberrypi-touchscreen: Initialise the bridge in prepare
Dave Stevenson <dave.stevenson(a)raspberrypi.com>
drm/panel/raspberrypi-touchscreen: Avoid NULL deref if not initialised
Xiaomeng Tong <xiam0nd.tong(a)gmail.com>
dma: at_xdmac: fix a missing check on list iterator
Zheyu Ma <zheyuma97(a)gmail.com>
ata: pata_marvell: Check the 'bmdma_addr' beforing reading
Mikulas Patocka <mpatocka(a)redhat.com>
stat: fix inconsistency between struct stat and struct compat_stat
Tomas Melin <tomas.melin(a)vaisala.com>
net: macb: Restart tx only if queue pointer is lagging
Xiaoke Wang <xkernel.wang(a)foxmail.com>
drm/msm/mdp5: check the return of kzalloc()
Lv Ruyi <lv.ruyi(a)zte.com.cn>
dpaa_eth: Fix missing of_node_put in dpaa_get_ts_info()
Borislav Petkov <bp(a)alien8.de>
brcmfmac: sdio: Fix undefined behavior due to shift overflowing the constant
Borislav Petkov <bp(a)suse.de>
mt76: Fix undefined behavior due to shift overflowing the constant
David Howells <dhowells(a)redhat.com>
cifs: Check the IOCB_DIRECT flag, not O_DIRECT
Hongbin Wang <wh_bin(a)126.com>
vxlan: fix error return code in vxlan_fdb_append
Borislav Petkov <bp(a)suse.de>
ALSA: usb-audio: Fix undefined behavior due to shift overflowing the constant
Jiapeng Chong <jiapeng.chong(a)linux.alibaba.com>
platform/x86: samsung-laptop: Fix an unsigned comparison which can never be negative
Sameer Pujar <spujar(a)nvidia.com>
reset: tegra-bpmp: Restore Handle errors in BPMP response
Kees Cook <keescook(a)chromium.org>
ARM: vexpress/spc: Avoid negative array index when !SMP
Eric Dumazet <edumazet(a)google.com>
netlink: reset network and mac headers in netlink_dump()
Eric Dumazet <edumazet(a)google.com>
net/sched: cls_u32: fix possible leak in u32_init_knode()
Hangbin Liu <liuhangbin(a)gmail.com>
net/packet: fix packet_sock xmit return value checking
David Howells <dhowells(a)redhat.com>
rxrpc: Restore removed timer deletion
Miaoqian Lin <linmq006(a)gmail.com>
dmaengine: imx-sdma: Fix error checking in sdma_event_remap
Miaoqian Lin <linmq006(a)gmail.com>
ASoC: msm8916-wcd-digital: Check failure for devm_snd_soc_register_component
Mark Brown <broonie(a)kernel.org>
ASoC: atmel: Remove system clock tree configuration for at91sam9g20ek
Kuniyuki Iwashima <kuniyu(a)amazon.co.jp>
tcp: Fix potential use-after-free due to double kfree()
Ricardo Dias <rdias(a)singlestore.com>
tcp: fix race condition when creating child sockets from syncookies
Takashi Iwai <tiwai(a)suse.de>
ALSA: usb-audio: Clear MIDI port active flag after draining
Bob Peterson <rpeterso(a)redhat.com>
gfs2: assign rgrp glock before compute_bitstructs
Mikulas Patocka <mpatocka(a)redhat.com>
dm integrity: fix memory corruption when tag_size is less than digest size
Hangyu Hua <hbh25y(a)gmail.com>
can: usb_8dev: usb_8dev_start_xmit(): fix double dev_kfree_skb() in error path
Daniel Bristot de Oliveira <bristot(a)kernel.org>
tracing: Dump stacktrace trigger to the corresponding instance
Xiongwei Song <sxwjean(a)gmail.com>
mm: page_alloc: fix building error on -Werror=array-compare
Kees Cook <keescook(a)chromium.org>
etherdevice: Adjust ether_addr* prototypes to silence -Wstringop-overead
-------------
Diffstat:
Makefile | 4 +-
arch/arc/kernel/entry.S | 1 +
arch/arm/mach-vexpress/spc.c | 2 +-
arch/powerpc/perf/power9-pmu.c | 8 +--
arch/x86/include/asm/compat.h | 6 +-
block/compat_ioctl.c | 2 +-
drivers/ata/pata_marvell.c | 2 +
drivers/dma/at_xdmac.c | 12 ++--
drivers/dma/imx-sdma.c | 4 +-
drivers/gpu/drm/msm/disp/mdp5/mdp5_plane.c | 3 +
.../gpu/drm/panel/panel-raspberrypi-touchscreen.c | 13 ++++-
drivers/md/dm-integrity.c | 7 ++-
drivers/net/can/usb/usb_8dev.c | 30 +++++-----
drivers/net/ethernet/cadence/macb_main.c | 8 +++
drivers/net/ethernet/freescale/dpaa/dpaa_ethtool.c | 8 ++-
drivers/net/ethernet/intel/e1000e/ich8lan.c | 4 +-
drivers/net/ethernet/micrel/Kconfig | 1 -
drivers/net/vxlan.c | 4 +-
.../wireless/broadcom/brcm80211/brcmfmac/sdio.c | 2 +-
drivers/net/wireless/mediatek/mt76/mt76x2_pci.c | 2 +-
drivers/perf/arm_pmu.c | 10 ++--
drivers/platform/x86/samsung-laptop.c | 2 -
drivers/reset/tegra/reset-bpmp.c | 9 ++-
drivers/staging/android/ion/ion.c | 3 +
fs/cifs/cifsfs.c | 2 +-
fs/ext4/inode.c | 11 +++-
fs/ext4/page-io.c | 4 +-
fs/ext4/super.c | 19 ++++--
fs/gfs2/rgrp.c | 9 +--
fs/stat.c | 19 +++---
include/linux/etherdevice.h | 5 +-
include/net/ax25.h | 12 ++++
include/net/inet_hashtables.h | 5 +-
kernel/trace/trace_events_trigger.c | 9 ++-
mm/page_alloc.c | 2 +-
net/ax25/af_ax25.c | 38 +++++++++---
net/ax25/ax25_dev.c | 28 +++++++--
net/ax25/ax25_route.c | 13 ++++-
net/ax25/ax25_subr.c | 20 +++++--
net/dccp/ipv4.c | 2 +-
net/dccp/ipv6.c | 2 +-
net/ipv4/inet_connection_sock.c | 2 +-
net/ipv4/inet_hashtables.c | 68 +++++++++++++++++++---
net/ipv4/tcp_ipv4.c | 13 ++++-
net/ipv6/tcp_ipv6.c | 13 ++++-
net/netlink/af_netlink.c | 7 +++
net/openvswitch/flow_netlink.c | 2 +-
net/packet/af_packet.c | 13 +++--
net/rxrpc/net_ns.c | 2 +
net/sched/cls_u32.c | 8 +--
sound/soc/atmel/sam9g20_wm8731.c | 61 -------------------
sound/soc/codecs/msm8916-wcd-digital.c | 9 ++-
sound/soc/soc-dapm.c | 6 +-
sound/usb/midi.c | 1 +
sound/usb/usbaudio.h | 2 +-
55 files changed, 359 insertions(+), 195 deletions(-)
xtensa is the last user of the PT_SINGLESTEP flag. Changing tsk->ptrace in
user_enable_single_step and user_disable_single_step without locking could
potentiallly cause problems.
So use a thread info flag instead of a flag in tsk->ptrace. Use TIF_SINGLESTEP
that xtensa already had defined but unused.
Remove the definitions of PT_SINGLESTEP and PT_BLOCKSTEP as they have no more users.
Cc: stable(a)vger.kernel.org
Acked-by: Max Filippov <jcmvbkbc(a)gmail.com>
Signed-off-by: "Eric W. Biederman" <ebiederm(a)xmission.com>
---
arch/xtensa/kernel/ptrace.c | 4 ++--
arch/xtensa/kernel/signal.c | 4 ++--
include/linux/ptrace.h | 6 ------
3 files changed, 4 insertions(+), 10 deletions(-)
diff --git a/arch/xtensa/kernel/ptrace.c b/arch/xtensa/kernel/ptrace.c
index 323c678a691f..b952e67cc0cc 100644
--- a/arch/xtensa/kernel/ptrace.c
+++ b/arch/xtensa/kernel/ptrace.c
@@ -225,12 +225,12 @@ const struct user_regset_view *task_user_regset_view(struct task_struct *task)
void user_enable_single_step(struct task_struct *child)
{
- child->ptrace |= PT_SINGLESTEP;
+ set_tsk_thread_flag(child, TIF_SINGLESTEP);
}
void user_disable_single_step(struct task_struct *child)
{
- child->ptrace &= ~PT_SINGLESTEP;
+ clear_tsk_thread_flag(child, TIF_SINGLESTEP);
}
/*
diff --git a/arch/xtensa/kernel/signal.c b/arch/xtensa/kernel/signal.c
index 6f68649e86ba..ac50ec46c8f1 100644
--- a/arch/xtensa/kernel/signal.c
+++ b/arch/xtensa/kernel/signal.c
@@ -473,7 +473,7 @@ static void do_signal(struct pt_regs *regs)
/* Set up the stack frame */
ret = setup_frame(&ksig, sigmask_to_save(), regs);
signal_setup_done(ret, &ksig, 0);
- if (current->ptrace & PT_SINGLESTEP)
+ if (test_thread_flag(TIF_SINGLESTEP))
task_pt_regs(current)->icountlevel = 1;
return;
@@ -499,7 +499,7 @@ static void do_signal(struct pt_regs *regs)
/* If there's no signal to deliver, we just restore the saved mask. */
restore_saved_sigmask();
- if (current->ptrace & PT_SINGLESTEP)
+ if (test_thread_flag(TIF_SINGLESTEP))
task_pt_regs(current)->icountlevel = 1;
return;
}
diff --git a/include/linux/ptrace.h b/include/linux/ptrace.h
index 4c06f9f8ef3f..c952c5ba8fab 100644
--- a/include/linux/ptrace.h
+++ b/include/linux/ptrace.h
@@ -46,12 +46,6 @@ extern int ptrace_access_vm(struct task_struct *tsk, unsigned long addr,
#define PT_EXITKILL (PTRACE_O_EXITKILL << PT_OPT_FLAG_SHIFT)
#define PT_SUSPEND_SECCOMP (PTRACE_O_SUSPEND_SECCOMP << PT_OPT_FLAG_SHIFT)
-/* single stepping state bits (used on ARM and PA-RISC) */
-#define PT_SINGLESTEP_BIT 31
-#define PT_SINGLESTEP (1<<PT_SINGLESTEP_BIT)
-#define PT_BLOCKSTEP_BIT 30
-#define PT_BLOCKSTEP (1<<PT_BLOCKSTEP_BIT)
-
extern long arch_ptrace(struct task_struct *child, long request,
unsigned long addr, unsigned long data);
extern int ptrace_readdata(struct task_struct *tsk, unsigned long src, char __user *dst, int len);
--
2.35.3
[BUG]
For a 4K sector sized btrfs with v1 cache enabled and only mounted on
systems with 4K page size, if it's mounted on subpage (64K page size)
systems, it can cause the following warning on v1 space cache:
BTRFS error (device dm-1): csum mismatch on free space cache
BTRFS warning (device dm-1): failed to load free space cache for block group 84082688, rebuilding it now
Although not a big deal, as kernel can rebuild it without problem, such
warning will bother end users, especially if they want to switch the
same btrfs seamlessly between different page sized systems.
[CAUSE]
V1 free space cache is still using fixed PAGE_SIZE for various bitmap,
like BITS_PER_BITMAP.
Such hard-coded PAGE_SIZE usage will cause various mismatch, from v1
cache size to checksum.
Thus kernel will always reject v1 cache with a different PAGE_SIZE with
csum mismatch.
[FIX]
Although we should fix v1 cache, it's already going to be marked
deprecated soon.
And we have v2 cache based on metadata (which is already fully subpage
compatible), and it has almost everything superior than v1 cache.
So just force subpage mount to use v2 cache on mount.
Reported-by: Matt Corallo <blnxfsl(a)bluematt.me>
CC: stable(a)vger.kernel.org # 5.15+
Link: https://lore.kernel.org/linux-btrfs/61aa27d1-30fc-c1a9-f0f4-9df544395ec3@bl…
Signed-off-by: Qu Wenruo <wqu(a)suse.com>
---
fs/btrfs/disk-io.c | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/fs/btrfs/disk-io.c b/fs/btrfs/disk-io.c
index d456f426924c..34eb6d4b904a 100644
--- a/fs/btrfs/disk-io.c
+++ b/fs/btrfs/disk-io.c
@@ -3675,6 +3675,17 @@ int __cold open_ctree(struct super_block *sb, struct btrfs_fs_devices *fs_device
if (sectorsize < PAGE_SIZE) {
struct btrfs_subpage_info *subpage_info;
+ /*
+ * V1 space cache has some hardcoded PAGE_SIZE usage, and is
+ * going to be deprecated.
+ *
+ * Force to use v2 cache for subpage case.
+ */
+ btrfs_clear_opt(fs_info->mount_opt, SPACE_CACHE);
+ btrfs_set_and_info(fs_info, FREE_SPACE_TREE,
+ "forcing free space tree for sector size %u with page size %lu",
+ sectorsize, PAGE_SIZE);
+
btrfs_warn(fs_info,
"read-write for sector size %u with page size %lu is experimental",
sectorsize, PAGE_SIZE);
--
2.35.1
From: Oliver Hartkopp <socketcan(a)hartkopp.net>
As a carry over from the CAN_RAW socket (which allows to change the CAN
interface while mantaining the filter setup) the re-binding of the
CAN_ISOTP socket needs to take care about CAN ID address information and
subscriptions. It turned out that this feature is so limited (e.g. the
sockopts remain fix) that it finally has never been needed/used.
In opposite to the stateless CAN_RAW socket the switching of the CAN ID
subscriptions might additionally lead to an interrupted ongoing PDU
reception. So better remove this unneeded complexity.
Fixes: e057dd3fc20f ("can: add ISO 15765-2:2016 transport protocol")
Link: https://lore.kernel.org/all/20220422082337.1676-1-socketcan@hartkopp.net
Cc: stable(a)vger.kernel.org
Signed-off-by: Oliver Hartkopp <socketcan(a)hartkopp.net>
Signed-off-by: Marc Kleine-Budde <mkl(a)pengutronix.de>
---
net/can/isotp.c | 25 +++++--------------------
1 file changed, 5 insertions(+), 20 deletions(-)
diff --git a/net/can/isotp.c b/net/can/isotp.c
index ff5d7870294e..1e7c6a460ef9 100644
--- a/net/can/isotp.c
+++ b/net/can/isotp.c
@@ -1189,6 +1189,11 @@ static int isotp_bind(struct socket *sock, struct sockaddr *uaddr, int len)
lock_sock(sk);
+ if (so->bound) {
+ err = -EINVAL;
+ goto out;
+ }
+
/* do not register frame reception for functional addressing */
if (so->opt.flags & CAN_ISOTP_SF_BROADCAST)
do_rx_reg = 0;
@@ -1199,10 +1204,6 @@ static int isotp_bind(struct socket *sock, struct sockaddr *uaddr, int len)
goto out;
}
- if (so->bound && addr->can_ifindex == so->ifindex &&
- rx_id == so->rxid && tx_id == so->txid)
- goto out;
-
dev = dev_get_by_index(net, addr->can_ifindex);
if (!dev) {
err = -ENODEV;
@@ -1237,22 +1238,6 @@ static int isotp_bind(struct socket *sock, struct sockaddr *uaddr, int len)
dev_put(dev);
- if (so->bound && do_rx_reg) {
- /* unregister old filter */
- if (so->ifindex) {
- dev = dev_get_by_index(net, so->ifindex);
- if (dev) {
- can_rx_unregister(net, dev, so->rxid,
- SINGLE_MASK(so->rxid),
- isotp_rcv, sk);
- can_rx_unregister(net, dev, so->txid,
- SINGLE_MASK(so->txid),
- isotp_rcv_echo, sk);
- dev_put(dev);
- }
- }
- }
-
/* switch to new settings */
so->ifindex = ifindex;
so->rxid = rx_id;
base-commit: d9157f6806d1499e173770df1f1b234763de5c79
--
2.35.1
The patch titled
Subject: arm[64]/memremap: don't abuse pfn_valid() to ensure presence of linear map
has been added to the -mm mm-hotfixes-unstable branch. Its filename is
arm-memremap-dont-abuse-pfn_valid-to-ensure-presence-of-linear-map.patch
This patch should soon appear in the mm-hotfixes-unstable branch at
git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/process/submit-checklist.rst when testing your code ***
The -mm tree is included into linux-next via the mm-everything
branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
and is updated there every 2-3 working days
------------------------------------------------------
From: Mike Rapoport <rppt(a)linux.ibm.com>
Subject: arm[64]/memremap: don't abuse pfn_valid() to ensure presence of linear map
The semantics of pfn_valid() is to check presence of the memory map for a
PFN and not whether a PFN is covered by the linear map. The memory map
may be present for NOMAP memory regions, but they won't be mapped in the
linear mapping. Accessing such regions via __va() when they are
memremap()'ed will cause a crash.
On v5.4.y the crash happens on qemu-arm with UEFI [1]:
<1>[ 0.084476] 8<--- cut here ---
<1>[ 0.084595] Unable to handle kernel paging request at virtual address dfb76000
<1>[ 0.084938] pgd = (ptrval)
<1>[ 0.085038] [dfb76000] *pgd=5f7fe801, *pte=00000000, *ppte=00000000
...
<4>[ 0.093923] [<c0ed6ce8>] (memcpy) from [<c16a06f8>] (dmi_setup+0x60/0x418)
<4>[ 0.094204] [<c16a06f8>] (dmi_setup) from [<c16a38d4>] (arm_dmi_init+0x8/0x10)
<4>[ 0.094408] [<c16a38d4>] (arm_dmi_init) from [<c0302e9c>] (do_one_initcall+0x50/0x228)
<4>[ 0.094619] [<c0302e9c>] (do_one_initcall) from [<c16011e4>] (kernel_init_freeable+0x15c/0x1f8)
<4>[ 0.094841] [<c16011e4>] (kernel_init_freeable) from [<c0f028cc>] (kernel_init+0x8/0x10c)
<4>[ 0.095057] [<c0f028cc>] (kernel_init) from [<c03010e8>] (ret_from_fork+0x14/0x2c)
On kernels v5.10.y and newer the same crash won't reproduce on ARM because
commit b10d6bca8720 ("arch, drivers: replace for_each_membock() with
for_each_mem_range()") changed the way memory regions are registered in
the resource tree, but that merely covers up the problem.
On ARM64 memory resources registered in yet another way and there the
issue of wrong usage of pfn_valid() to ensure availability of the linear
map is also covered.
Implement arch_memremap_can_ram_remap() on ARM and ARM64 to prevent access
to NOMAP regions via the linear mapping in memremap().
Link: https://lore.kernel.org/all/Yl65zxGgFzF1Okac@sirena.org.uk
Link: https://lkml.kernel.org/r/20220426060107.7618-1-rppt@kernel.org
Signed-off-by: Mike Rapoport <rppt(a)linux.ibm.com>
Reported-by: "kernelci.org bot" <bot(a)kernelci.org>
Tested-by: Mark Brown <broonie(a)kernel.org>
Reviewed-by: Ard Biesheuvel <ardb(a)kernel.org>
Acked-by: Catalin Marinas <catalin.marinas(a)arm.com>
Cc: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Cc: Mark Brown <broonie(a)kernel.org>
Cc: Mark-PK Tsai <mark-pk.tsai(a)mediatek.com>
Cc: Russell King <linux(a)armlinux.org.uk>
Cc: Tony Lindgren <tony(a)atomide.com>
Cc: Will Deacon <will(a)kernel.org>
Cc: <stable(a)vger.kernel.org> [5.4+]
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
arch/arm/include/asm/io.h | 3 +++
arch/arm/mm/ioremap.c | 8 ++++++++
arch/arm64/include/asm/io.h | 4 ++++
arch/arm64/mm/ioremap.c | 8 ++++++++
4 files changed, 23 insertions(+)
--- a/arch/arm64/include/asm/io.h~arm-memremap-dont-abuse-pfn_valid-to-ensure-presence-of-linear-map
+++ a/arch/arm64/include/asm/io.h
@@ -192,4 +192,8 @@ extern void __iomem *ioremap_cache(phys_
extern int valid_phys_addr_range(phys_addr_t addr, size_t size);
extern int valid_mmap_phys_addr_range(unsigned long pfn, size_t size);
+extern bool arch_memremap_can_ram_remap(resource_size_t offset, size_t size,
+ unsigned long flags);
+#define arch_memremap_can_ram_remap arch_memremap_can_ram_remap
+
#endif /* __ASM_IO_H */
--- a/arch/arm64/mm/ioremap.c~arm-memremap-dont-abuse-pfn_valid-to-ensure-presence-of-linear-map
+++ a/arch/arm64/mm/ioremap.c
@@ -99,3 +99,11 @@ void __init early_ioremap_init(void)
{
early_ioremap_setup();
}
+
+bool arch_memremap_can_ram_remap(resource_size_t offset, size_t size,
+ unsigned long flags)
+{
+ unsigned long pfn = PHYS_PFN(offset);
+
+ return pfn_is_map_memory(pfn);
+}
--- a/arch/arm/include/asm/io.h~arm-memremap-dont-abuse-pfn_valid-to-ensure-presence-of-linear-map
+++ a/arch/arm/include/asm/io.h
@@ -440,6 +440,9 @@ extern void pci_iounmap(struct pci_dev *
#define ARCH_HAS_VALID_PHYS_ADDR_RANGE
extern int valid_phys_addr_range(phys_addr_t addr, size_t size);
extern int valid_mmap_phys_addr_range(unsigned long pfn, size_t size);
+extern bool arch_memremap_can_ram_remap(resource_size_t offset, size_t size,
+ unsigned long flags);
+#define arch_memremap_can_ram_remap arch_memremap_can_ram_remap
#endif
/*
--- a/arch/arm/mm/ioremap.c~arm-memremap-dont-abuse-pfn_valid-to-ensure-presence-of-linear-map
+++ a/arch/arm/mm/ioremap.c
@@ -493,3 +493,11 @@ void __init early_ioremap_init(void)
{
early_ioremap_setup();
}
+
+bool arch_memremap_can_ram_remap(resource_size_t offset, size_t size,
+ unsigned long flags)
+{
+ unsigned long pfn = PHYS_PFN(offset);
+
+ return memblock_is_map_memory(pfn);
+}
_
Patches currently in -mm which might be from rppt(a)linux.ibm.com are
arm-memremap-dont-abuse-pfn_valid-to-ensure-presence-of-linear-map.patch
During the uvcg_video_pump() process, if an error occurs and
uvcg_queue_cancel() is called, the buffer queue will be cleared out, but
the current marker (queue->buf_used) of the active buffer (no longer
active) is not reset. On the next iteration of uvcg_video_pump() the
stale buf_used count will be used and the logic of min((unsigned
int)len, buf->bytesused - queue->buf_used) may incorrectly calculate a
nbytes size, causing an invalid memory access.
[80802.185460][ T315] configfs-gadget gadget: uvc: VS request completed
with status -18.
[80802.185519][ T315] configfs-gadget gadget: uvc: VS request completed
with status -18.
...
uvcg_queue_cancel() is called and the queue is cleared out, but the
marker queue->buf_used is not reset.
...
[80802.262328][ T8682] Unable to handle kernel paging request at virtual
address ffffffc03af9f000
...
...
[80802.263138][ T8682] Call trace:
[80802.263146][ T8682] __memcpy+0x12c/0x180
[80802.263155][ T8682] uvcg_video_pump+0xcc/0x1e0
[80802.263165][ T8682] process_one_work+0x2cc/0x568
[80802.263173][ T8682] worker_thread+0x28c/0x518
[80802.263181][ T8682] kthread+0x160/0x170
[80802.263188][ T8682] ret_from_fork+0x10/0x18
[80802.263198][ T8682] Code: a8c12829 a88130cb a8c130
Fixes: d692522577c0 ("usb: gadget/uvc: Port UVC webcam gadget to use videobuf2 framework")
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Dan Vacura <w36195(a)motorola.com>
---
Changes in v3:
- Cc stable
Changes in v2:
- Add Fixes tag
drivers/usb/gadget/function/uvc_queue.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/usb/gadget/function/uvc_queue.c b/drivers/usb/gadget/function/uvc_queue.c
index d852ac9e47e7..2cda982f3765 100644
--- a/drivers/usb/gadget/function/uvc_queue.c
+++ b/drivers/usb/gadget/function/uvc_queue.c
@@ -264,6 +264,8 @@ void uvcg_queue_cancel(struct uvc_video_queue *queue, int disconnect)
buf->state = UVC_BUF_STATE_ERROR;
vb2_buffer_done(&buf->buf.vb2_buf, VB2_BUF_STATE_ERROR);
}
+ queue->buf_used = 0;
+
/* This must be protected by the irqlock spinlock to avoid race
* conditions between uvc_queue_buffer and the disconnection event that
* could result in an interruptible wait in uvc_dequeue_buffer. Do not
--
2.32.0
From: Mike Rapoport <rppt(a)linux.ibm.com>
The semantics of pfn_valid() is to check presence of the memory map for a
PFN and not whether a PFN is covered by the linear map. The memory map may
be present for NOMAP memory regions, but they won't be mapped in the linear
mapping. Accessing such regions via __va() when they are memremap()'ed
will cause a crash.
On v5.4.y the crash happens on qemu-arm with UEFI [1]:
<1>[ 0.084476] 8<--- cut here ---
<1>[ 0.084595] Unable to handle kernel paging request at virtual address dfb76000
<1>[ 0.084938] pgd = (ptrval)
<1>[ 0.085038] [dfb76000] *pgd=5f7fe801, *pte=00000000, *ppte=00000000
...
<4>[ 0.093923] [<c0ed6ce8>] (memcpy) from [<c16a06f8>] (dmi_setup+0x60/0x418)
<4>[ 0.094204] [<c16a06f8>] (dmi_setup) from [<c16a38d4>] (arm_dmi_init+0x8/0x10)
<4>[ 0.094408] [<c16a38d4>] (arm_dmi_init) from [<c0302e9c>] (do_one_initcall+0x50/0x228)
<4>[ 0.094619] [<c0302e9c>] (do_one_initcall) from [<c16011e4>] (kernel_init_freeable+0x15c/0x1f8)
<4>[ 0.094841] [<c16011e4>] (kernel_init_freeable) from [<c0f028cc>] (kernel_init+0x8/0x10c)
<4>[ 0.095057] [<c0f028cc>] (kernel_init) from [<c03010e8>] (ret_from_fork+0x14/0x2c)
On kernels v5.10.y and newer the same crash won't reproduce on ARM because
commit b10d6bca8720 ("arch, drivers: replace for_each_membock() with
for_each_mem_range()") changed the way memory regions are registered in the
resource tree, but that merely covers up the problem.
On ARM64 memory resources registered in yet another way and there the
issue of wrong usage of pfn_valid() to ensure availability of the linear
map is also covered.
Implement arch_memremap_can_ram_remap() on ARM and ARM64 to prevent access
to NOMAP regions via the linear mapping in memremap().
Link: https://lore.kernel.org/all/Yl65zxGgFzF1Okac@sirena.org.uk
Reported-by: "kernelci.org bot" <bot(a)kernelci.org>
Tested-by: Mark Brown <broonie(a)kernel.org>
Cc: stable(a)vger.kernel.org # 5.4+
Signed-off-by: Mike Rapoport <rppt(a)linux.ibm.com>
---
v2: don't remove pfn_valid() from try_ram_remap(), per Ard
arch/arm/include/asm/io.h | 3 +++
arch/arm/mm/ioremap.c | 8 ++++++++
arch/arm64/include/asm/io.h | 4 ++++
arch/arm64/mm/ioremap.c | 8 ++++++++
4 files changed, 23 insertions(+)
diff --git a/arch/arm/include/asm/io.h b/arch/arm/include/asm/io.h
index 0c70eb688a00..2a0739a2350b 100644
--- a/arch/arm/include/asm/io.h
+++ b/arch/arm/include/asm/io.h
@@ -440,6 +440,9 @@ extern void pci_iounmap(struct pci_dev *dev, void __iomem *addr);
#define ARCH_HAS_VALID_PHYS_ADDR_RANGE
extern int valid_phys_addr_range(phys_addr_t addr, size_t size);
extern int valid_mmap_phys_addr_range(unsigned long pfn, size_t size);
+extern bool arch_memremap_can_ram_remap(resource_size_t offset, size_t size,
+ unsigned long flags);
+#define arch_memremap_can_ram_remap arch_memremap_can_ram_remap
#endif
/*
diff --git a/arch/arm/mm/ioremap.c b/arch/arm/mm/ioremap.c
index aa08bcb72db9..290702328a33 100644
--- a/arch/arm/mm/ioremap.c
+++ b/arch/arm/mm/ioremap.c
@@ -493,3 +493,11 @@ void __init early_ioremap_init(void)
{
early_ioremap_setup();
}
+
+bool arch_memremap_can_ram_remap(resource_size_t offset, size_t size,
+ unsigned long flags)
+{
+ unsigned long pfn = PHYS_PFN(offset);
+
+ return memblock_is_map_memory(pfn);
+}
diff --git a/arch/arm64/include/asm/io.h b/arch/arm64/include/asm/io.h
index 7fd836bea7eb..3995652daf81 100644
--- a/arch/arm64/include/asm/io.h
+++ b/arch/arm64/include/asm/io.h
@@ -192,4 +192,8 @@ extern void __iomem *ioremap_cache(phys_addr_t phys_addr, size_t size);
extern int valid_phys_addr_range(phys_addr_t addr, size_t size);
extern int valid_mmap_phys_addr_range(unsigned long pfn, size_t size);
+extern bool arch_memremap_can_ram_remap(resource_size_t offset, size_t size,
+ unsigned long flags);
+#define arch_memremap_can_ram_remap arch_memremap_can_ram_remap
+
#endif /* __ASM_IO_H */
diff --git a/arch/arm64/mm/ioremap.c b/arch/arm64/mm/ioremap.c
index b7c81dacabf0..b21f91cd830d 100644
--- a/arch/arm64/mm/ioremap.c
+++ b/arch/arm64/mm/ioremap.c
@@ -99,3 +99,11 @@ void __init early_ioremap_init(void)
{
early_ioremap_setup();
}
+
+bool arch_memremap_can_ram_remap(resource_size_t offset, size_t size,
+ unsigned long flags)
+{
+ unsigned long pfn = PHYS_PFN(offset);
+
+ return pfn_is_map_memory(pfn);
+}
base-commit: b2d229d4ddb17db541098b83524d901257e93845
--
2.28.0
I have very important information to give you, but first I must tell
with your confidence before reviewing it because it can cause my work,
so I need someone I can trust to I can check the secret
Hi Greg,
Please cherry-pick this patch series into 5.15.y stable. It
includes a feature that fixes CVE-2022-0500 which allows a user with
cap_bpf privileges to get root privileges. The patch that fixes
the bug is
patch 7/10: bpf: Make per_cpu_ptr return rdonly
The rest are the depedences required by the fix patch. Note that v5.10 and
below are not affected by this bug.
This patchset has been merged in mainline v5.17 and backported to v5.16[1],
except patch 10/10 ("bpf: Fix crash due to out of bounds access into reg2btf_ids."),
which fixes an out-of-bound access in the main feature in this series and
hasn't been backported to v5.16 yet. If it's convenient, could you
apply patch 10/10 to 5.16? I can send a separate patch for v5.16, if you
prefer.
Tested by compile, build and run through the bpf selftest test_progs.
[1] https://www.spinics.net/lists/stable/msg535877.html
Hao Luo (9):
bpf: Introduce composable reg, ret and arg types.
bpf: Replace ARG_XXX_OR_NULL with ARG_XXX | PTR_MAYBE_NULL
bpf: Replace RET_XXX_OR_NULL with RET_XXX | PTR_MAYBE_NULL
bpf: Replace PTR_TO_XXX_OR_NULL with PTR_TO_XXX | PTR_MAYBE_NULL
bpf: Introduce MEM_RDONLY flag
bpf: Convert PTR_TO_MEM_OR_NULL to composable types.
bpf: Make per_cpu_ptr return rdonly PTR_TO_MEM.
bpf: Add MEM_RDONLY for helper args that are pointers to rdonly mem.
bpf/selftests: Test PTR_TO_RDONLY_MEM
Kumar Kartikeya Dwivedi (1):
bpf: Fix crash due to out of bounds access into reg2btf_ids.
include/linux/bpf.h | 101 +++-
include/linux/bpf_verifier.h | 18 +
kernel/bpf/btf.c | 16 +-
kernel/bpf/cgroup.c | 2 +-
kernel/bpf/helpers.c | 12 +-
kernel/bpf/map_iter.c | 4 +-
kernel/bpf/ringbuf.c | 2 +-
kernel/bpf/syscall.c | 2 +-
kernel/bpf/verifier.c | 488 +++++++++---------
kernel/trace/bpf_trace.c | 22 +-
net/core/bpf_sk_storage.c | 2 +-
net/core/filter.c | 64 +--
net/core/sock_map.c | 2 +-
.../selftests/bpf/prog_tests/ksyms_btf.c | 14 +
.../bpf/progs/test_ksyms_btf_write_check.c | 29 ++
15 files changed, 445 insertions(+), 333 deletions(-)
create mode 100644 tools/testing/selftests/bpf/progs/test_ksyms_btf_write_check.c
--
2.36.0.464.gb9c8b46e94-goog
The bug is here:
if (!buf) {
The list iterator value 'buf' will *always* be set and non-NULL
by list_for_each_entry(), so it is incorrect to assume that the
iterator value will be NULL if the list is empty (in this case, the
check 'if (!buf) {' will always be false and never exit expectly).
To fix the bug, use a new variable 'iter' as the list iterator,
while use the original variable 'buf' as a dedicated pointer to
point to the found element.
Cc: stable(a)vger.kernel.org
Fixes: 2419e55e532de ("misc: fastrpc: add mmap/unmap support")
Signed-off-by: Xiaomeng Tong <xiam0nd.tong(a)gmail.com>
---
drivers/misc/fastrpc.c | 9 +++++----
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/misc/fastrpc.c b/drivers/misc/fastrpc.c
index aa1682b94a23..45aaf54a7560 100644
--- a/drivers/misc/fastrpc.c
+++ b/drivers/misc/fastrpc.c
@@ -1353,17 +1353,18 @@ static int fastrpc_req_munmap_impl(struct fastrpc_user *fl,
struct fastrpc_req_munmap *req)
{
struct fastrpc_invoke_args args[1] = { [0] = { 0 } };
- struct fastrpc_buf *buf, *b;
+ struct fastrpc_buf *buf = NULL, *iter, *b;
struct fastrpc_munmap_req_msg req_msg;
struct device *dev = fl->sctx->dev;
int err;
u32 sc;
spin_lock(&fl->lock);
- list_for_each_entry_safe(buf, b, &fl->mmaps, node) {
- if ((buf->raddr == req->vaddrout) && (buf->size == req->size))
+ list_for_each_entry_safe(iter, b, &fl->mmaps, node) {
+ if ((iter->raddr == req->vaddrout) && (iter->size == req->size)) {
+ buf = iter;
break;
- buf = NULL;
+ }
}
spin_unlock(&fl->lock);
--
2.17.1
I have very important information to give you, but first I must tell
with your confidence before reviewing it because it can cause my work,
so I need someone I can trust to I can check the secret
Fix the discrepancy between the two places we check for the CP0 counter
erratum in along with the incorrect comparison of the R4400 revision
number against 0x30 which matches none and consistently consider all
R4000 and R4400 processors affected, as documented in processor errata
publications[1][2][3], following the mapping between CP0 PRId register
values and processor models:
PRId | Processor Model
---------+--------------------
00000422 | R4000 Revision 2.2
00000430 | R4000 Revision 3.0
00000440 | R4400 Revision 1.0
00000450 | R4400 Revision 2.0
00000460 | R4400 Revision 3.0
No other revision of either processor has ever been spotted.
Contrary to what has been stated in commit ce202cbb9e0b ("[MIPS] Assume
R4000/R4400 newer than 3.0 don't have the mfc0 count bug") marking the
CP0 counter as buggy does not preclude it from being used as either a
clock event or a clock source device. It just cannot be used as both at
a time, because in that case clock event interrupts will be occasionally
lost, and the use as a clock event device takes precedence.
Compare against 0x4ff in `can_use_mips_counter' so that a single machine
instruction is produced.
References:
[1] "MIPS R4000PC/SC Errata, Processor Revision 2.2 and 3.0", MIPS
Technologies Inc., May 10, 1994, Erratum 53, p.13
[2] "MIPS R4400PC/SC Errata, Processor Revision 1.0", MIPS Technologies
Inc., February 9, 1994, Erratum 21, p.4
[3] "MIPS R4400PC/SC Errata, Processor Revision 2.0 & 3.0", MIPS
Technologies Inc., January 24, 1995, Erratum 14, p.3
Signed-off-by: Maciej W. Rozycki <macro(a)orcam.me.uk>
Fixes: ce202cbb9e0b ("[MIPS] Assume R4000/R4400 newer than 3.0 don't have the mfc0 count bug")
Cc: stable(a)vger.kernel.org # v2.6.24+
---
Thomas,
Please review the requirements for SNI platforms. In the case of an
erratic CP0 timer we give precedence to the use as a clock event rather
than clock source device; see `time_init' in arch/mips/kernel/time.c.
Therefore if SNI systems have no alternative timer interrupt source, then
the CP0 timer is supposed to still do regardless of the erratum.
Conversely a system can do without a high-precision clock source, in
which case jiffies will be used. Of course such a system will suffer if
used for precision timekeeping, but such is the price for broken hardware.
Don't SNI systems have any alternative timer available, not even the
venerable 8254?
Long-term I think this code should be factored out and rewritten so that
it lives in one place and can take advantage of compile-time constants,
which will be the case for the majority of platforms. For the time being
fix the immediate breakage however.
With the considerations above in mind, please apply.
Maciej
---
arch/mips/include/asm/timex.h | 8 ++++----
arch/mips/kernel/time.c | 11 +++--------
2 files changed, 7 insertions(+), 12 deletions(-)
linux-mips-r4k-count-erratum-prid.diff
Index: linux-macro/arch/mips/include/asm/timex.h
===================================================================
--- linux-macro.orig/arch/mips/include/asm/timex.h
+++ linux-macro/arch/mips/include/asm/timex.h
@@ -40,9 +40,9 @@
typedef unsigned int cycles_t;
/*
- * On R4000/R4400 before version 5.0 an erratum exists such that if the
- * cycle counter is read in the exact moment that it is matching the
- * compare register, no interrupt will be generated.
+ * On R4000/R4400 an erratum exists such that if the cycle counter is
+ * read in the exact moment that it is matching the compare register,
+ * no interrupt will be generated.
*
* There is a suggested workaround and also the erratum can't strike if
* the compare interrupt isn't being used as the clock source device.
@@ -63,7 +63,7 @@ static inline int can_use_mips_counter(u
if (!__builtin_constant_p(cpu_has_counter))
asm volatile("" : "=m" (cpu_data[0].options));
if (likely(cpu_has_counter &&
- prid >= (PRID_IMP_R4000 | PRID_REV_ENCODE_44(5, 0))))
+ prid > (PRID_IMP_R4000 | PRID_REV_ENCODE_44(15, 15))))
return 1;
else
return 0;
Index: linux-macro/arch/mips/kernel/time.c
===================================================================
--- linux-macro.orig/arch/mips/kernel/time.c
+++ linux-macro/arch/mips/kernel/time.c
@@ -141,15 +141,10 @@ static __init int cpu_has_mfc0_count_bug
case CPU_R4400MC:
/*
* The published errata for the R4400 up to 3.0 say the CPU
- * has the mfc0 from count bug.
- */
- if ((current_cpu_data.processor_id & 0xff) <= 0x30)
- return 1;
-
- /*
- * we assume newer revisions are ok
+ * has the mfc0 from count bug. This seems the last version
+ * produced.
*/
- return 0;
+ return 1;
}
return 0;
We always calling hold_lkb(lkb) if we increment lkb->lkb_wait_count. As
conclusion we always need to call unhold_lkb(lkb) if we decrement
lkb->lkb_wait_count. This patch will add missing unhold_lkb(lkb) if we
decrement lkb->lkb_wait_count. In case of setting lkb->lkb_wait_count to
zero we need to countdown until reaching zero and call unhold_lkb(lkb).
The waiters list unhold_lkb(lkb) can be removed because it's done for
the last lkb_wait_count decrement iteration as it's done in
_remove_from_waiters().
This issue was discovered by a dlm gfs2 test case which use excessively
dlm_unlock(LKF_CANCEL) feature. Probably the lkb->lkb_wait_count value
never reached above 1 if this feature isn't used and so it was not
discovered before.
The testcase ended in a rsb on the rsb keep data structure with a
refcount of 1 but no lkb was associated with it anymore which is itself
an invalid behaviour. As sideeffect it was observed that the dlm
lockspace was in a kind of deadlock state by sending remove messages in
a looping behaviour. With this patch I never observed a similar
behaviour again.
Cc: stable(a)vger.kernel.org
Signed-off-by: Alexander Aring <aahringo(a)redhat.com>
---
fs/dlm/lock.c | 11 +++++++++--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/fs/dlm/lock.c b/fs/dlm/lock.c
index 1899bb266e2e..d19cfa03c9bb 100644
--- a/fs/dlm/lock.c
+++ b/fs/dlm/lock.c
@@ -1578,6 +1578,7 @@ static int _remove_from_waiters(struct dlm_lkb *lkb, int mstype,
lkb->lkb_wait_type = 0;
lkb->lkb_flags &= ~DLM_IFL_OVERLAP_CANCEL;
lkb->lkb_wait_count--;
+ unhold_lkb(lkb);
goto out_del;
}
@@ -1604,6 +1605,7 @@ static int _remove_from_waiters(struct dlm_lkb *lkb, int mstype,
log_error(ls, "remwait error %x reply %d wait_type %d overlap",
lkb->lkb_id, mstype, lkb->lkb_wait_type);
lkb->lkb_wait_count--;
+ unhold_lkb(lkb);
lkb->lkb_wait_type = 0;
}
@@ -5364,11 +5366,16 @@ int dlm_recover_waiters_post(struct dlm_ls *ls)
lkb->lkb_flags &= ~DLM_IFL_OVERLAP_UNLOCK;
lkb->lkb_flags &= ~DLM_IFL_OVERLAP_CANCEL;
lkb->lkb_wait_type = 0;
- lkb->lkb_wait_count = 0;
+ /* drop all wait_count references we still
+ * hold a reference for this iteration.
+ */
+ while (lkb->lkb_wait_count) {
+ lkb->lkb_wait_count--;
+ unhold_lkb(lkb);
+ }
mutex_lock(&ls->ls_waiters_mutex);
list_del_init(&lkb->lkb_wait_reply);
mutex_unlock(&ls->ls_waiters_mutex);
- unhold_lkb(lkb); /* for waiters list */
if (oc || ou) {
/* do an unlock or cancel instead of resending */
--
2.31.1
From: Andreas Larsson <andreas(a)gaisler.com>
The previous split budget between TX and RX made it return not using
the entire budget but at the same time not having calling called
napi_complete. This sometimes led to the poll to not be called, and at
the same time having TX and RX interrupts disabled resulting in the
driver getting stuck.
Fixes: 6cec9b07fe6a ("can: grcan: Add device driver for GRCAN and GRHCAN cores")
Link: https://lore.kernel.org/all/20220429084656.29788-4-andreas@gaisler.com
Cc: stable(a)vger.kernel.org
Signed-off-by: Andreas Larsson <andreas(a)gaisler.com>
Signed-off-by: Marc Kleine-Budde <mkl(a)pengutronix.de>
---
drivers/net/can/grcan.c | 22 +++++++---------------
1 file changed, 7 insertions(+), 15 deletions(-)
diff --git a/drivers/net/can/grcan.c b/drivers/net/can/grcan.c
index 4ca3da56d3aa..5215bd9b2c80 100644
--- a/drivers/net/can/grcan.c
+++ b/drivers/net/can/grcan.c
@@ -1125,7 +1125,7 @@ static int grcan_close(struct net_device *dev)
return 0;
}
-static int grcan_transmit_catch_up(struct net_device *dev, int budget)
+static void grcan_transmit_catch_up(struct net_device *dev)
{
struct grcan_priv *priv = netdev_priv(dev);
unsigned long flags;
@@ -1133,7 +1133,7 @@ static int grcan_transmit_catch_up(struct net_device *dev, int budget)
spin_lock_irqsave(&priv->lock, flags);
- work_done = catch_up_echo_skb(dev, budget, true);
+ work_done = catch_up_echo_skb(dev, -1, true);
if (work_done) {
if (!priv->resetting && !priv->closing &&
!(priv->can.ctrlmode & CAN_CTRLMODE_LISTENONLY))
@@ -1147,8 +1147,6 @@ static int grcan_transmit_catch_up(struct net_device *dev, int budget)
}
spin_unlock_irqrestore(&priv->lock, flags);
-
- return work_done;
}
static int grcan_receive(struct net_device *dev, int budget)
@@ -1230,19 +1228,13 @@ static int grcan_poll(struct napi_struct *napi, int budget)
struct net_device *dev = priv->dev;
struct grcan_registers __iomem *regs = priv->regs;
unsigned long flags;
- int tx_work_done, rx_work_done;
- int rx_budget = budget / 2;
- int tx_budget = budget - rx_budget;
+ int work_done;
- /* Half of the budget for receiving messages */
- rx_work_done = grcan_receive(dev, rx_budget);
+ work_done = grcan_receive(dev, budget);
- /* Half of the budget for transmitting messages as that can trigger echo
- * frames being received
- */
- tx_work_done = grcan_transmit_catch_up(dev, tx_budget);
+ grcan_transmit_catch_up(dev);
- if (rx_work_done < rx_budget && tx_work_done < tx_budget) {
+ if (work_done < budget) {
napi_complete(napi);
/* Guarantee no interference with a running reset that otherwise
@@ -1259,7 +1251,7 @@ static int grcan_poll(struct napi_struct *napi, int budget)
spin_unlock_irqrestore(&priv->lock, flags);
}
- return rx_work_done + tx_work_done;
+ return work_done;
}
/* Work tx bug by waiting while for the risky situation to clear. If that fails,
--
2.35.1
From: Duoming Zhou <duoming(a)zju.edu.cn>
There are deadlocks caused by del_timer_sync(&priv->hang_timer) and
del_timer_sync(&priv->rr_timer) in grcan_close(), one of the deadlocks
are shown below:
(Thread 1) | (Thread 2)
| grcan_reset_timer()
grcan_close() | mod_timer()
spin_lock_irqsave() //(1) | (wait a time)
... | grcan_initiate_running_reset()
del_timer_sync() | spin_lock_irqsave() //(2)
(wait timer to stop) | ...
We hold priv->lock in position (1) of thread 1 and use
del_timer_sync() to wait timer to stop, but timer handler also need
priv->lock in position (2) of thread 2. As a result, grcan_close()
will block forever.
This patch extracts del_timer_sync() from the protection of
spin_lock_irqsave(), which could let timer handler to obtain the
needed lock.
Link: https://lore.kernel.org/all/20220425042400.66517-1-duoming@zju.edu.cn
Fixes: 6cec9b07fe6a ("can: grcan: Add device driver for GRCAN and GRHCAN cores")
Cc: stable(a)vger.kernel.org
Signed-off-by: Duoming Zhou <duoming(a)zju.edu.cn>
Reviewed-by: Andreas Larsson <andreas(a)gaisler.com>
Signed-off-by: Marc Kleine-Budde <mkl(a)pengutronix.de>
---
drivers/net/can/grcan.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/net/can/grcan.c b/drivers/net/can/grcan.c
index d0c5a7a60daf..1189057b5d68 100644
--- a/drivers/net/can/grcan.c
+++ b/drivers/net/can/grcan.c
@@ -1102,8 +1102,10 @@ static int grcan_close(struct net_device *dev)
priv->closing = true;
if (priv->need_txbug_workaround) {
+ spin_unlock_irqrestore(&priv->lock, flags);
del_timer_sync(&priv->hang_timer);
del_timer_sync(&priv->rr_timer);
+ spin_lock_irqsave(&priv->lock, flags);
}
netif_stop_queue(dev);
grcan_stop_hardware(dev);
--
2.35.1
People are occasionally reporting a warning bfqq_request_over_limit()
triggering reporting that BFQ's idea of cgroup hierarchy (and its depth)
does not match what generic blkcg code thinks. This can actually happen
when bfqq gets moved between BFQ groups while bfqq_request_over_limit()
is running. Make sure the code is safe against BFQ queue being moved to
a different BFQ group.
Fixes: 76f1df88bbc2 ("bfq: Limit number of requests consumed by each cgroup")
CC: stable(a)vger.kernel.org
Link: https://lore.kernel.org/all/CAJCQCtTw_2C7ZSz7as5Gvq=OmnDiio=HRkQekqWpKot84s…
Reported-by: Chris Murphy <lists(a)colorremedies.com>
Reported-by: "yukuai (C)" <yukuai3(a)huawei.com>
Signed-off-by: Jan Kara <jack(a)suse.cz>
---
block/bfq-iosched.c | 12 +++++++++---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/block/bfq-iosched.c b/block/bfq-iosched.c
index e47c75f1fa0f..272d48d8f326 100644
--- a/block/bfq-iosched.c
+++ b/block/bfq-iosched.c
@@ -569,7 +569,7 @@ static bool bfqq_request_over_limit(struct bfq_queue *bfqq, int limit)
struct bfq_entity *entity = &bfqq->entity;
struct bfq_entity *inline_entities[BFQ_LIMIT_INLINE_DEPTH];
struct bfq_entity **entities = inline_entities;
- int depth, level;
+ int depth, level, alloc_depth = BFQ_LIMIT_INLINE_DEPTH;
int class_idx = bfqq->ioprio_class - 1;
struct bfq_sched_data *sched_data;
unsigned long wsum;
@@ -578,15 +578,21 @@ static bool bfqq_request_over_limit(struct bfq_queue *bfqq, int limit)
if (!entity->on_st_or_in_serv)
return false;
+retry:
+ spin_lock_irq(&bfqd->lock);
/* +1 for bfqq entity, root cgroup not included */
depth = bfqg_to_blkg(bfqq_group(bfqq))->blkcg->css.cgroup->level + 1;
- if (depth > BFQ_LIMIT_INLINE_DEPTH) {
+ if (depth > alloc_depth) {
+ spin_unlock_irq(&bfqd->lock);
+ if (entities != inline_entities)
+ kfree(entities);
entities = kmalloc_array(depth, sizeof(*entities), GFP_NOIO);
if (!entities)
return false;
+ alloc_depth = depth;
+ goto retry;
}
- spin_lock_irq(&bfqd->lock);
sched_data = entity->sched_data;
/* Gather our ancestors as we need to traverse them in reverse order */
level = 0;
--
2.34.1
As discussed with Willem here:
https://lore.kernel.org/netdev/CA+FuTSdQ57O6RWj_Lenmu_Vd3NEX9xMzMYkB0C3rKMz…
the kernel silently doesn't act upon the SOF_TIMESTAMPING_OPT_ID socket
option in several cases on older kernels, yet user space has no way to
find out about this, practically resulting in broken functionality.
This patch set backports the support towards linux-4.14.y and linux-4.19.y,
which fixes the issue described above by simply making the kernel act
upon SOF_TIMESTAMPING_OPT_ID as expected.
Testing was done with the most recent (not the vintage-correct one)
kselftest script at:
tools/testing/selftests/networking/timestamping/txtimestamp.sh
with the message "OK. All tests passed".
I tried to backport the changes to linux-4.9.y as well, but something
apparently unrelated is broken there, and I didn't investigate further
so I'm not targeting that stable branch:
./txtimestamp.sh
protocol: TCP
payload: 10
server port: 9000
family: INET
test SND
USR: 1581090724 s 856088 us (seq=0, len=0)
./txtimestamp: poll
Willem de Bruijn (2):
ipv6: add missing tx timestamping on IPPROTO_RAW
net: add missing SOF_TIMESTAMPING_OPT_ID support
include/net/sock.h | 25 +++++++++++++++++++++----
net/can/raw.c | 2 +-
net/ipv4/raw.c | 2 +-
net/ipv6/raw.c | 7 +++++--
net/packet/af_packet.c | 6 +++---
5 files changed, 31 insertions(+), 11 deletions(-)
--
2.25.1
The patch below does not apply to the 5.15-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 8f0b36497303487d5a32c75789c77859cc2ee895 Mon Sep 17 00:00:00 2001
From: Muchun Song <songmuchun(a)bytedance.com>
Date: Fri, 1 Apr 2022 11:28:36 -0700
Subject: [PATCH] mm: kfence: fix objcgs vector allocation
If the kfence object is allocated to be used for objects vector, then
this slot of the pool eventually being occupied permanently since the
vector is never freed. The solutions could be (1) freeing vector when
the kfence object is freed or (2) allocating all vectors statically.
Since the memory consumption of object vectors is low, it is better to
chose (2) to fix the issue and it is also can reduce overhead of vectors
allocating in the future.
Link: https://lkml.kernel.org/r/20220328132843.16624-1-songmuchun@bytedance.com
Fixes: d3fb45f370d9 ("mm, kfence: insert KFENCE hooks for SLAB")
Signed-off-by: Muchun Song <songmuchun(a)bytedance.com>
Reviewed-by: Marco Elver <elver(a)google.com>
Reviewed-by: Roman Gushchin <roman.gushchin(a)linux.dev>
Cc: Alexander Potapenko <glider(a)google.com>
Cc: Dmitry Vyukov <dvyukov(a)google.com>
Cc: Xiongchun Duan <duanxiongchun(a)bytedance.com>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org>
diff --git a/mm/kfence/core.c b/mm/kfence/core.c
index 2f9fdfde1941..a203747ad2c0 100644
--- a/mm/kfence/core.c
+++ b/mm/kfence/core.c
@@ -566,6 +566,8 @@ static unsigned long kfence_init_pool(void)
* enters __slab_free() slow-path.
*/
for (i = 0; i < KFENCE_POOL_SIZE / PAGE_SIZE; i++) {
+ struct slab *slab = page_slab(&pages[i]);
+
if (!i || (i % 2))
continue;
@@ -573,7 +575,11 @@ static unsigned long kfence_init_pool(void)
if (WARN_ON(compound_head(&pages[i]) != &pages[i]))
return addr;
- __SetPageSlab(&pages[i]);
+ __folio_set_slab(slab_folio(slab));
+#ifdef CONFIG_MEMCG
+ slab->memcg_data = (unsigned long)&kfence_metadata[i / 2 - 1].objcg |
+ MEMCG_DATA_OBJCGS;
+#endif
}
/*
@@ -1033,6 +1039,9 @@ void __kfence_free(void *addr)
{
struct kfence_metadata *meta = addr_to_metadata((unsigned long)addr);
+#ifdef CONFIG_MEMCG
+ KFENCE_WARN_ON(meta->objcg);
+#endif
/*
* If the objects of the cache are SLAB_TYPESAFE_BY_RCU, defer freeing
* the object, as the object page may be recycled for other-typed
diff --git a/mm/kfence/kfence.h b/mm/kfence/kfence.h
index 2a2d5de9d379..9a6c4b1b12a8 100644
--- a/mm/kfence/kfence.h
+++ b/mm/kfence/kfence.h
@@ -89,6 +89,9 @@ struct kfence_metadata {
struct kfence_track free_track;
/* For updating alloc_covered on frees. */
u32 alloc_stack_hash;
+#ifdef CONFIG_MEMCG
+ struct obj_cgroup *objcg;
+#endif
};
extern struct kfence_metadata kfence_metadata[CONFIG_KFENCE_NUM_OBJECTS];
From: Ritesh Harjani <riteshh(a)linux.ibm.com>
commit cc16eecae687912238ee6efbff71ad31e2bc414e upstream.
jbd2_journal_wait_updates() is called with j_state_lock held. But if
there is a commit in progress, then this transaction might get committed
and freed via jbd2_journal_commit_transaction() ->
jbd2_journal_free_transaction(), when we release j_state_lock.
So check for journal->j_running_transaction everytime we release and
acquire j_state_lock to avoid use-after-free issue.
Link: https://lore.kernel.org/r/948c2fed518ae739db6a8f7f83f1d58b504f87d0.16444971…
Fixes: 4f98186848707f53 ("jbd2: refactor wait logic for transaction updates into a common function")
Cc: stable(a)kernel.org
Reported-and-tested-by: syzbot+afa2ca5171d93e44b348(a)syzkaller.appspotmail.com
Reviewed-by: Jan Kara <jack(a)suse.cz>
Signed-off-by: Ritesh Harjani <riteshh(a)linux.ibm.com>
Signed-off-by: Theodore Ts'o <tytso(a)mit.edu>
[backport to 4.9-4.19 in original jbd2_journal_commit_transaction()
location before the refactor in
4f9818684870 "jbd2: refactor wait logic for transaction updates into a
common function"]
Signed-off-by: Samuel Mendoza-Jonas <samjonas(a)amazon.com>
Fixes: 1da177e4c3f41524
Cc: stable(a)kernel.org # 4.9.x - 4.19.x
---
While marked for 5.17 stable, it looks like this fix also applies to the
original location in jbd2_journal_commit_transaction() before it was
refactored to use jbd2_journal_wait_updates(). This applies the same
change there.
fs/jbd2/commit.c | 22 +++++++++++++---------
1 file changed, 13 insertions(+), 9 deletions(-)
diff --git a/fs/jbd2/commit.c b/fs/jbd2/commit.c
index 97760cb9bcd7..66e776eb5ea7 100644
--- a/fs/jbd2/commit.c
+++ b/fs/jbd2/commit.c
@@ -382,6 +382,7 @@ void jbd2_journal_commit_transaction(journal_t *journal)
int csum_size = 0;
LIST_HEAD(io_bufs);
LIST_HEAD(log_bufs);
+ DEFINE_WAIT(wait);
if (jbd2_journal_has_csum_v2or3(journal))
csum_size = sizeof(struct jbd2_journal_block_tail);
@@ -434,22 +435,25 @@ void jbd2_journal_commit_transaction(journal_t *journal)
stats.run.rs_running = jbd2_time_diff(commit_transaction->t_start,
stats.run.rs_locked);
- spin_lock(&commit_transaction->t_handle_lock);
- while (atomic_read(&commit_transaction->t_updates)) {
- DEFINE_WAIT(wait);
+ while (1) {
+ commit_transaction = journal->j_running_transaction;
+ if (!commit_transaction)
+ break;
+ spin_lock(&commit_transaction->t_handle_lock);
prepare_to_wait(&journal->j_wait_updates, &wait,
TASK_UNINTERRUPTIBLE);
- if (atomic_read(&commit_transaction->t_updates)) {
+ if (!atomic_read(&commit_transaction->t_updates)) {
spin_unlock(&commit_transaction->t_handle_lock);
- write_unlock(&journal->j_state_lock);
- schedule();
- write_lock(&journal->j_state_lock);
- spin_lock(&commit_transaction->t_handle_lock);
+ finish_wait(&journal->j_wait_updates, &wait);
+ break;
}
+ spin_unlock(&commit_transaction->t_handle_lock);
+ write_unlock(&journal->j_state_lock);
+ schedule();
finish_wait(&journal->j_wait_updates, &wait);
+ write_lock(&journal->j_state_lock);
}
- spin_unlock(&commit_transaction->t_handle_lock);
J_ASSERT (atomic_read(&commit_transaction->t_outstanding_credits) <=
journal->j_max_transaction_buffers);
--
2.25.1
Hi,
Kernel test bot reported that the ia64 build error on stable 4.19.y because
of the commit d3380de483d5 ("ia64: kprobes: Use generic kretprobe trampoline
handler").
I also found that this commit was involved by the backporting of commit
f5f96e3643dc ("ia64: kprobes: Fix to pass correct trampoline address to the
handler"), and this 2nd commit was backported wrong way. Actually, this 2nd
commit aimed to use dereference_function_descriptor() in kprobes@ia64, but
the comment (and Fixes tag) points the 1st commit. Thus I guess this mistake
happened.
So I re-backport the upstream commit a7fe2378454c ("ia64: kprobes: Fix to
pass correct trampoline address to the handler") correctly, without involving
the 1st commit.
Thank you,
---
Masami Hiramatsu (3):
Revert "ia64: kprobes: Fix to pass correct trampoline address to the handler"
Revert "ia64: kprobes: Use generic kretprobe trampoline handler"
ia64: kprobes: Fix to pass correct trampoline address to the handler
arch/ia64/kernel/kprobes.c | 78 ++++++++++++++++++++++++++++++++++++++++++--
1 file changed, 75 insertions(+), 3 deletions(-)
--
Masami Hiramatsu (Linaro) <mhiramat(a)kernel.org>
Hi Greg,
Here are two custom backports to v4.19 for some powerpc issues we've discovered.
Both were fixed upstream as part of a large non-backportable rewrite. Other stable
kernel versions are not affected.
cheers
Michael Ellerman (1):
powerpc/64s: Unmerge EX_LR and EX_DAR
Nicholas Piggin (1):
powerpc/64/interrupt: Temporarily save PPR on stack to fix register
corruption due to SLB miss
arch/powerpc/include/asm/exception-64s.h | 37 ++++++++++++++----------
1 file changed, 22 insertions(+), 15 deletions(-)
--
2.35.1
Hi all,
Commit 3db09e762dc79584a69c10d74a6b98f89a9979f8 upstream ("net/sched:
cls_u32: fix netns refcount changes in u32_change()") fixes a crash
and seems like a good candidate for stable trees.
The change fixes 35c55fc156d8 ("cls_u32: use tcf_exts_get_net() before
call_rcu()"), which was added in 4.14, so I think it might make sense
to cherry-pick the fix to 4.14+.
Let me know what you think.
Thanks,
-Robert
From: Lin Ma <linma(a)zju.edu.cn>
commit 0b9111922b1f399aba6ed1e1b8f2079c3da1aed8 upstream.
There is a possible race condition (use-after-free) like below
(USE) | (FREE)
dev_queue_xmit |
__dev_queue_xmit |
__dev_xmit_skb |
sch_direct_xmit | ...
xmit_one |
netdev_start_xmit | tty_ldisc_kill
__netdev_start_xmit | 6pack_close
sp_xmit | kfree
sp_encaps |
|
According to the patch "defer ax25 kfree after unregister_netdev", this
patch reorder the kfree after the unregister_netdev to avoid the possible
UAF as the unregister_netdev() is well synchronized and won't return if
there is a running routine.
Signed-off-by: Lin Ma <linma(a)zju.edu.cn>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Xu Jia <xujia39(a)huawei.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Signed-off-by: Ovidiu Panait <ovidiu.panait(a)windriver.com>
---
These commits are part of CVE-2022-1195 patchset.
Reference: https://bugzilla.redhat.com/show_bug.cgi?id=2056381
[1] https://github.com/torvalds/linux/commit/3e0588c291d6ce225f2b891753ca41d45b…
[2] https://github.com/torvalds/linux/commit/b2f37aead1b82a770c48b5d583f35ec22a…
[3] https://github.com/torvalds/linux/commit/0b9111922b1f399aba6ed1e1b8f2079c3d…
[4] https://github.com/torvalds/linux/commit/81b1d548d00bcd028303c4f3150fa753b9…
Commits [1] and [2] are already present in 5.4-stable, this patchset includes
backports for [3] and [4] (clean cherry-picks from 5.10 stable).
drivers/net/hamradio/6pack.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/net/hamradio/6pack.c b/drivers/net/hamradio/6pack.c
index 02d6f3ad9aca..82507a688efe 100644
--- a/drivers/net/hamradio/6pack.c
+++ b/drivers/net/hamradio/6pack.c
@@ -679,9 +679,11 @@ static void sixpack_close(struct tty_struct *tty)
del_timer_sync(&sp->tx_t);
del_timer_sync(&sp->resync_t);
- /* Free all 6pack frame buffers. */
+ /* Free all 6pack frame buffers after unreg. */
kfree(sp->rbuff);
kfree(sp->xbuff);
+
+ free_netdev(sp->dev);
}
/* Perform I/O control on an active 6pack channel. */
--
2.36.0
Even if SPI_NOR_NO_ERASE was specified at flash declaration, the erase
type of size nor->info->sector_size was incorrectly set as supported.
Don't set erase types when SPI_NOR_NO_ERASE is set.
Fixes: b199489d37b2 ("mtd: spi-nor: add the framework for SPI NOR")
Signed-off-by: Tudor Ambarus <tudor.ambarus(a)microchip.com>
Cc: stable(a)vger.kernel.org
---
v2:
- add comment, update commit message, split change in individual commit
- add fixes tag and cc to stable.
drivers/mtd/spi-nor/core.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/mtd/spi-nor/core.c b/drivers/mtd/spi-nor/core.c
index b4f141ad9c9c..64cf7b9df621 100644
--- a/drivers/mtd/spi-nor/core.c
+++ b/drivers/mtd/spi-nor/core.c
@@ -2392,6 +2392,10 @@ static void spi_nor_no_sfdp_init_params(struct spi_nor *nor)
SPINOR_OP_PP, SNOR_PROTO_8_8_8_DTR);
}
+ /* Skip setting erase types when SPI_NOR_NO_ERASE is set. */
+ if (nor->info->flags & SPI_NOR_NO_ERASE)
+ return;
+
/*
* Sector Erase settings. Sort Erase Types in ascending order, with the
* smallest erase size starting at BIT(0).
--
2.25.1
The patch titled
Subject: mm: mremap: fix sign for EFAULT error return value
has been added to the -mm tree. Its filename is
mm-mremap-fix-sign-for-efault-error-return-value.patch
This patch should soon appear at
https://ozlabs.org/~akpm/mmots/broken-out/mm-mremap-fix-sign-for-efault-err…
and later at
https://ozlabs.org/~akpm/mmotm/broken-out/mm-mremap-fix-sign-for-efault-err…
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/process/submit-checklist.rst when testing your code ***
The -mm tree is included into linux-next and is updated
there every 3-4 working days
------------------------------------------------------
From: Niels Dossche <dossche.niels(a)gmail.com>
Subject: mm: mremap: fix sign for EFAULT error return value
The mremap syscall is supposed to return a pointer to the new virtual
memory area on success, and a negative value of the error code in case of
failure. Currently, EFAULT is returned when the VMA is not found, instead
of -EFAULT. The users of this syscall will therefore believe the syscall
succeeded in case the VMA didn't exist, as it returns a pointer to address
0xe (0xe being the value of EFAULT). Fix the sign of the error value.
Link: https://lkml.kernel.org/r/20220427224439.23828-2-dossche.niels@gmail.com
Fixes: 550a7d60bd5e ("mm, hugepages: add mremap() support for hugepage backed vma")
Signed-off-by: Niels Dossche <dossche.niels(a)gmail.com>
Cc: Mina Almasry <almasrymina(a)google.com>
Cc: Mike Kravetz <mike.kravetz(a)oracle.com>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
mm/mremap.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/mm/mremap.c~mm-mremap-fix-sign-for-efault-error-return-value
+++ a/mm/mremap.c
@@ -941,7 +941,7 @@ SYSCALL_DEFINE5(mremap, unsigned long, a
return -EINTR;
vma = vma_lookup(mm, addr);
if (!vma) {
- ret = EFAULT;
+ ret = -EFAULT;
goto out;
}
_
Patches currently in -mm which might be from dossche.niels(a)gmail.com are
mm-mremap-fix-sign-for-efault-error-return-value.patch
The following commit has been merged into the timers/urgent branch of tip:
Commit-ID: 2c33d775ef4c25c0e1e1cc0fd5496d02f76bfa20
Gitweb: https://git.kernel.org/tip/2c33d775ef4c25c0e1e1cc0fd5496d02f76bfa20
Author: Kurt Kanzenbach <kurt(a)linutronix.de>
AuthorDate: Thu, 28 Apr 2022 08:24:32 +02:00
Committer: Thomas Gleixner <tglx(a)linutronix.de>
CommitterDate: Fri, 29 Apr 2022 00:07:53 +02:00
timekeeping: Mark NMI safe time accessors as notrace
Mark the CLOCK_MONOTONIC fast time accessors as notrace. These functions are
used in tracing to retrieve timestamps, so they should not recurse.
Fixes: 4498e7467e9e ("time: Parametrize all tk_fast_mono users")
Fixes: f09cb9a1808e ("time: Introduce tk_fast_raw")
Reported-by: Steven Rostedt <rostedt(a)goodmis.org>
Signed-off-by: Kurt Kanzenbach <kurt(a)linutronix.de>
Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de>
Cc: stable(a)vger.kernel.org
Link: https://lore.kernel.org/r/20220426175338.3807ca4f@gandalf.local.home/
Link: https://lore.kernel.org/r/20220428062432.61063-1-kurt@linutronix.de
---
kernel/time/timekeeping.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/kernel/time/timekeeping.c b/kernel/time/timekeeping.c
index dcdcb85..3b1398f 100644
--- a/kernel/time/timekeeping.c
+++ b/kernel/time/timekeeping.c
@@ -482,7 +482,7 @@ static __always_inline u64 __ktime_get_fast_ns(struct tk_fast *tkf)
* of the following timestamps. Callers need to be aware of that and
* deal with it.
*/
-u64 ktime_get_mono_fast_ns(void)
+u64 notrace ktime_get_mono_fast_ns(void)
{
return __ktime_get_fast_ns(&tk_fast_mono);
}
@@ -494,7 +494,7 @@ EXPORT_SYMBOL_GPL(ktime_get_mono_fast_ns);
* Contrary to ktime_get_mono_fast_ns() this is always correct because the
* conversion factor is not affected by NTP/PTP correction.
*/
-u64 ktime_get_raw_fast_ns(void)
+u64 notrace ktime_get_raw_fast_ns(void)
{
return __ktime_get_fast_ns(&tk_fast_raw);
}
This is a note to let you know that I've just added the patch titled
iio: imu: inv_icm42600: Fix I2C init possible nack
to my char-misc git tree which can be found at
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git
in the char-misc-linus branch.
The patch will show up in the next release of the linux-next tree
(usually sometime within the next 24 hours during the week.)
The patch will hopefully also be merged in Linus's tree for the
next -rc kernel release.
If you have any questions about this process, please let me know.
From b5d6ba09b10d2ccb865ed9bc45941db0a41c6756 Mon Sep 17 00:00:00 2001
From: Fawzi Khaber <fawzi.khaber(a)tdk.com>
Date: Mon, 11 Apr 2022 13:15:33 +0200
Subject: iio: imu: inv_icm42600: Fix I2C init possible nack
This register write to REG_INTF_CONFIG6 enables a spike filter that
is impacting the line and can prevent the I2C ACK to be seen by the
controller. So we don't test the return value.
Fixes: 7297ef1e261672b8 ("iio: imu: inv_icm42600: add I2C driver")
Signed-off-by: Fawzi Khaber <fawzi.khaber(a)tdk.com>
Signed-off-by: Jean-Baptiste Maneyrol <jean-baptiste.maneyrol(a)tdk.com>
Link: https://lore.kernel.org/r/20220411111533.5826-1-jmaneyrol@invensense.com
Cc: <Stable(a)vger.kernel.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron(a)huawei.com>
---
drivers/iio/imu/inv_icm42600/inv_icm42600_i2c.c | 15 +++++++++------
1 file changed, 9 insertions(+), 6 deletions(-)
diff --git a/drivers/iio/imu/inv_icm42600/inv_icm42600_i2c.c b/drivers/iio/imu/inv_icm42600/inv_icm42600_i2c.c
index 33d9afb1ba91..d4a692b838d0 100644
--- a/drivers/iio/imu/inv_icm42600/inv_icm42600_i2c.c
+++ b/drivers/iio/imu/inv_icm42600/inv_icm42600_i2c.c
@@ -18,12 +18,15 @@ static int inv_icm42600_i2c_bus_setup(struct inv_icm42600_state *st)
unsigned int mask, val;
int ret;
- /* setup interface registers */
- ret = regmap_update_bits(st->map, INV_ICM42600_REG_INTF_CONFIG6,
- INV_ICM42600_INTF_CONFIG6_MASK,
- INV_ICM42600_INTF_CONFIG6_I3C_EN);
- if (ret)
- return ret;
+ /*
+ * setup interface registers
+ * This register write to REG_INTF_CONFIG6 enables a spike filter that
+ * is impacting the line and can prevent the I2C ACK to be seen by the
+ * controller. So we don't test the return value.
+ */
+ regmap_update_bits(st->map, INV_ICM42600_REG_INTF_CONFIG6,
+ INV_ICM42600_INTF_CONFIG6_MASK,
+ INV_ICM42600_INTF_CONFIG6_I3C_EN);
ret = regmap_update_bits(st->map, INV_ICM42600_REG_INTF_CONFIG4,
INV_ICM42600_INTF_CONFIG4_I3C_BUS_ONLY, 0);
--
2.36.0
This is a note to let you know that I've just added the patch titled
iio: dac: ad5446: Fix read_raw not returning set value
to my char-misc git tree which can be found at
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git
in the char-misc-linus branch.
The patch will show up in the next release of the linux-next tree
(usually sometime within the next 24 hours during the week.)
The patch will hopefully also be merged in Linus's tree for the
next -rc kernel release.
If you have any questions about this process, please let me know.
From 89a01cd688d3c0ac983ef0b0e5f40018ab768317 Mon Sep 17 00:00:00 2001
From: Michael Hennerich <michael.hennerich(a)analog.com>
Date: Wed, 6 Apr 2022 12:56:20 +0200
Subject: iio: dac: ad5446: Fix read_raw not returning set value
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
read_raw should return the un-scaled value.
Fixes: 5e06bdfb46e8b ("staging:iio:dac:ad5446: Return cached value for 'raw' attribute")
Signed-off-by: Michael Hennerich <michael.hennerich(a)analog.com>
Reviewed-by: Nuno Sá <nuno.sa(a)analog.com>
Link: https://lore.kernel.org/r/20220406105620.1171340-1-michael.hennerich@analog…
Cc: <Stable(a)vger.kernel.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron(a)huawei.com>
---
drivers/iio/dac/ad5446.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/iio/dac/ad5446.c b/drivers/iio/dac/ad5446.c
index 14cfabacbea5..fdf824041497 100644
--- a/drivers/iio/dac/ad5446.c
+++ b/drivers/iio/dac/ad5446.c
@@ -178,7 +178,7 @@ static int ad5446_read_raw(struct iio_dev *indio_dev,
switch (m) {
case IIO_CHAN_INFO_RAW:
- *val = st->cached_val;
+ *val = st->cached_val >> chan->scan_type.shift;
return IIO_VAL_INT;
case IIO_CHAN_INFO_SCALE:
*val = st->vref_mv;
--
2.36.0
This is a note to let you know that I've just added the patch titled
iio: magnetometer: ak8975: Fix the error handling in
to my char-misc git tree which can be found at
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git
in the char-misc-linus branch.
The patch will show up in the next release of the linux-next tree
(usually sometime within the next 24 hours during the week.)
The patch will hopefully also be merged in Linus's tree for the
next -rc kernel release.
If you have any questions about this process, please let me know.
From 3a26787dacf04257a68b16315c984eb2c340bc5e Mon Sep 17 00:00:00 2001
From: Zheyu Ma <zheyuma97(a)gmail.com>
Date: Sat, 9 Apr 2022 11:48:49 +0800
Subject: iio: magnetometer: ak8975: Fix the error handling in
ak8975_power_on()
When the driver fails to enable the regulator 'vid', we will get the
following splat:
[ 79.955610] WARNING: CPU: 5 PID: 441 at drivers/regulator/core.c:2257 _regulator_put+0x3ec/0x4e0
[ 79.959641] RIP: 0010:_regulator_put+0x3ec/0x4e0
[ 79.967570] Call Trace:
[ 79.967773] <TASK>
[ 79.967951] regulator_put+0x1f/0x30
[ 79.968254] devres_release_group+0x319/0x3d0
[ 79.968608] i2c_device_probe+0x766/0x940
Fix this by disabling the 'vdd' regulator when failing to enable 'vid'
regulator.
Signed-off-by: Zheyu Ma <zheyuma97(a)gmail.com>
Link: https://lore.kernel.org/r/20220409034849.3717231-2-zheyuma97@gmail.com
Cc: <Stable(a)vger.kernel.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron(a)huawei.com>
---
drivers/iio/magnetometer/ak8975.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/iio/magnetometer/ak8975.c b/drivers/iio/magnetometer/ak8975.c
index 088f748b683e..2432e697150c 100644
--- a/drivers/iio/magnetometer/ak8975.c
+++ b/drivers/iio/magnetometer/ak8975.c
@@ -416,6 +416,7 @@ static int ak8975_power_on(const struct ak8975_data *data)
if (ret) {
dev_warn(&data->client->dev,
"Failed to enable specified Vid supply\n");
+ regulator_disable(data->vdd);
return ret;
}
--
2.36.0
This is a note to let you know that I've just added the patch titled
iio:proximity:sx_common: Fix device property parsing on DT systems
to my char-misc git tree which can be found at
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git
in the char-misc-linus branch.
The patch will show up in the next release of the linux-next tree
(usually sometime within the next 24 hours during the week.)
The patch will hopefully also be merged in Linus's tree for the
next -rc kernel release.
If you have any questions about this process, please let me know.
From 74a53a959028e5f28e3c0e9445a876e5c8da147c Mon Sep 17 00:00:00 2001
From: Stephen Boyd <swboyd(a)chromium.org>
Date: Thu, 31 Mar 2022 14:04:25 -0700
Subject: iio:proximity:sx_common: Fix device property parsing on DT systems
After commit 7a3605bef878 ("iio: sx9310: Support ACPI property") we
started using the 'indio_dev->dev' to extract device properties for
various register settings in sx9310_get_default_reg(). This broke DT
based systems because dev_fwnode() used in the device_property*() APIs
can't find an 'of_node'. That's because the 'indio_dev->dev.of_node'
pointer isn't set until iio_device_register() is called. Set the pointer
earlier, next to where the ACPI companion is set, so that the device
property APIs work on DT systems.
Cc: Gwendal Grignou <gwendal(a)chromium.org>
Fixes: 7a3605bef878 ("iio: sx9310: Support ACPI property")
Signed-off-by: Stephen Boyd <swboyd(a)chromium.org>
Reviewed-by: Gwendal Grignou <gwendal(a)chromium.org>
Link: https://lore.kernel.org/r/20220331210425.3908278-1-swboyd@chromium.org
Cc: <Stable(a)vger.kernel.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron(a)huawei.com>
---
drivers/iio/proximity/sx_common.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/iio/proximity/sx_common.c b/drivers/iio/proximity/sx_common.c
index a7c07316a0a9..8ad814d96b7e 100644
--- a/drivers/iio/proximity/sx_common.c
+++ b/drivers/iio/proximity/sx_common.c
@@ -521,6 +521,7 @@ int sx_common_probe(struct i2c_client *client,
return dev_err_probe(dev, ret, "error reading WHOAMI\n");
ACPI_COMPANION_SET(&indio_dev->dev, ACPI_COMPANION(dev));
+ indio_dev->dev.of_node = client->dev.of_node;
indio_dev->modes = INDIO_DIRECT_MODE;
indio_dev->channels = data->chip_info->iio_channels;
--
2.36.0
This is a note to let you know that I've just added the patch titled
iio: dac: ad5592r: Fix the missing return value.
to my char-misc git tree which can be found at
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git
in the char-misc-linus branch.
The patch will show up in the next release of the linux-next tree
(usually sometime within the next 24 hours during the week.)
The patch will hopefully also be merged in Linus's tree for the
next -rc kernel release.
If you have any questions about this process, please let me know.
From b55b38f7cc12da3b9ef36e7a3b7f8f96737df4d5 Mon Sep 17 00:00:00 2001
From: Zizhuang Deng <sunsetdzz(a)gmail.com>
Date: Thu, 10 Mar 2022 20:54:50 +0800
Subject: iio: dac: ad5592r: Fix the missing return value.
The third call to `fwnode_property_read_u32` did not record
the return value, resulting in `channel_offstate` possibly
being assigned the wrong value.
Fixes: 56ca9db862bf ("iio: dac: Add support for the AD5592R/AD5593R ADCs/DACs")
Signed-off-by: Zizhuang Deng <sunsetdzz(a)gmail.com>
Link: https://lore.kernel.org/r/20220310125450.4164164-1-sunsetdzz@gmail.com
Cc: <Stable(a)vger.kernel.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron(a)huawei.com>
---
drivers/iio/dac/ad5592r-base.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/iio/dac/ad5592r-base.c b/drivers/iio/dac/ad5592r-base.c
index a424b7220b61..4434c1b2a322 100644
--- a/drivers/iio/dac/ad5592r-base.c
+++ b/drivers/iio/dac/ad5592r-base.c
@@ -522,7 +522,7 @@ static int ad5592r_alloc_channels(struct iio_dev *iio_dev)
if (!ret)
st->channel_modes[reg] = tmp;
- fwnode_property_read_u32(child, "adi,off-state", &tmp);
+ ret = fwnode_property_read_u32(child, "adi,off-state", &tmp);
if (!ret)
st->channel_offstate[reg] = tmp;
}
--
2.36.0
This is a note to let you know that I've just added the patch titled
iio: scd4x: check return of scd4x_write_and_fetch
to my char-misc git tree which can be found at
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git
in the char-misc-linus branch.
The patch will show up in the next release of the linux-next tree
(usually sometime within the next 24 hours during the week.)
The patch will hopefully also be merged in Linus's tree for the
next -rc kernel release.
If you have any questions about this process, please let me know.
From f50232193e61cf89a73130b5e843fef30763c428 Mon Sep 17 00:00:00 2001
From: Tom Rix <trix(a)redhat.com>
Date: Mon, 28 Feb 2022 18:52:23 -0800
Subject: iio: scd4x: check return of scd4x_write_and_fetch
Clang static analysis reports this problem
scd4x.c:474:10: warning: The left operand of '==' is a
garbage value
if (val == 0xff) {
~~~ ^
val is only set from a successful call to scd4x_write_and_fetch()
So check it's return.
Fixes: 49d22b695cbb ("drivers: iio: chemical: Add support for Sensirion SCD4x CO2 sensor")
Signed-off-by: Tom Rix <trix(a)redhat.com>
Link: https://lore.kernel.org/r/20220301025223.223223-1-trix@redhat.com
Cc: <Stable(a)vger.kernel.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron(a)huawei.com>
---
drivers/iio/chemical/scd4x.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/iio/chemical/scd4x.c b/drivers/iio/chemical/scd4x.c
index 20d4e7584e92..37143b5526ee 100644
--- a/drivers/iio/chemical/scd4x.c
+++ b/drivers/iio/chemical/scd4x.c
@@ -471,12 +471,15 @@ static ssize_t calibration_forced_value_store(struct device *dev,
ret = scd4x_write_and_fetch(state, CMD_FRC, arg, &val, sizeof(val));
mutex_unlock(&state->lock);
+ if (ret)
+ return ret;
+
if (val == 0xff) {
dev_err(dev, "forced calibration has failed");
return -EINVAL;
}
- return ret ?: len;
+ return len;
}
static IIO_DEVICE_ATTR_RW(calibration_auto_enable, 0);
--
2.36.0
From: Lin Ma <linma(a)zju.edu.cn>
commit 0b9111922b1f399aba6ed1e1b8f2079c3da1aed8 upstream.
There is a possible race condition (use-after-free) like below
(USE) | (FREE)
dev_queue_xmit |
__dev_queue_xmit |
__dev_xmit_skb |
sch_direct_xmit | ...
xmit_one |
netdev_start_xmit | tty_ldisc_kill
__netdev_start_xmit | 6pack_close
sp_xmit | kfree
sp_encaps |
|
According to the patch "defer ax25 kfree after unregister_netdev", this
patch reorder the kfree after the unregister_netdev to avoid the possible
UAF as the unregister_netdev() is well synchronized and won't return if
there is a running routine.
Signed-off-by: Lin Ma <linma(a)zju.edu.cn>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Xu Jia <xujia39(a)huawei.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Signed-off-by: Ovidiu Panait <ovidiu.panait(a)windriver.com>
---
These commits are part of CVE-2022-1195 patchset.
Reference: https://bugzilla.redhat.com/show_bug.cgi?id=2056381
[1] https://github.com/torvalds/linux/commit/3e0588c291d6ce225f2b891753ca41d45b…
[2] https://github.com/torvalds/linux/commit/b2f37aead1b82a770c48b5d583f35ec22a…
[3] https://github.com/torvalds/linux/commit/0b9111922b1f399aba6ed1e1b8f2079c3d…
[4] https://github.com/torvalds/linux/commit/81b1d548d00bcd028303c4f3150fa753b9…
Commits [1] and [2] are already present in 4.14-stable, this patchset includes
backports for [3] and [4] (clean cherry-picks from 5.10 stable).
drivers/net/hamradio/6pack.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/net/hamradio/6pack.c b/drivers/net/hamradio/6pack.c
index 3d5b2b4899ec..7ff1c6f7eea2 100644
--- a/drivers/net/hamradio/6pack.c
+++ b/drivers/net/hamradio/6pack.c
@@ -690,9 +690,11 @@ static void sixpack_close(struct tty_struct *tty)
del_timer_sync(&sp->tx_t);
del_timer_sync(&sp->resync_t);
- /* Free all 6pack frame buffers. */
+ /* Free all 6pack frame buffers after unreg. */
kfree(sp->rbuff);
kfree(sp->xbuff);
+
+ free_netdev(sp->dev);
}
/* Perform I/O control on an active 6pack channel. */
--
2.36.0
From: Lin Ma <linma(a)zju.edu.cn>
commit 0b9111922b1f399aba6ed1e1b8f2079c3da1aed8 upstream.
There is a possible race condition (use-after-free) like below
(USE) | (FREE)
dev_queue_xmit |
__dev_queue_xmit |
__dev_xmit_skb |
sch_direct_xmit | ...
xmit_one |
netdev_start_xmit | tty_ldisc_kill
__netdev_start_xmit | 6pack_close
sp_xmit | kfree
sp_encaps |
|
According to the patch "defer ax25 kfree after unregister_netdev", this
patch reorder the kfree after the unregister_netdev to avoid the possible
UAF as the unregister_netdev() is well synchronized and won't return if
there is a running routine.
Signed-off-by: Lin Ma <linma(a)zju.edu.cn>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Xu Jia <xujia39(a)huawei.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Signed-off-by: Ovidiu Panait <ovidiu.panait(a)windriver.com>
---
These commits are part of CVE-2022-1195 patchset.
Reference: https://bugzilla.redhat.com/show_bug.cgi?id=2056381
[1] https://github.com/torvalds/linux/commit/3e0588c291d6ce225f2b891753ca41d45b…
[2] https://github.com/torvalds/linux/commit/b2f37aead1b82a770c48b5d583f35ec22a…
[3] https://github.com/torvalds/linux/commit/0b9111922b1f399aba6ed1e1b8f2079c3d…
[4] https://github.com/torvalds/linux/commit/81b1d548d00bcd028303c4f3150fa753b9…
Commits [1] and [2] are already present in 4.19-stable, this patchset includes
backports for [3] and [4] (clean cherry-picks from 5.10 stable).
drivers/net/hamradio/6pack.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/net/hamradio/6pack.c b/drivers/net/hamradio/6pack.c
index 29431e3eebee..381febb99bc3 100644
--- a/drivers/net/hamradio/6pack.c
+++ b/drivers/net/hamradio/6pack.c
@@ -679,9 +679,11 @@ static void sixpack_close(struct tty_struct *tty)
del_timer_sync(&sp->tx_t);
del_timer_sync(&sp->resync_t);
- /* Free all 6pack frame buffers. */
+ /* Free all 6pack frame buffers after unreg. */
kfree(sp->rbuff);
kfree(sp->xbuff);
+
+ free_netdev(sp->dev);
}
/* Perform I/O control on an active 6pack channel. */
--
2.36.0
Since commit dfeae1073583("mtd: cfi_cmdset_0002: Change write buffer to
check correct value") buffered writes fail on S29GL064N. This is
because, on S29GL064N, reads return 0xFF at the end of DQ polling for
write completion, where as, chip_good() check expects actual data
written to the last location to be returned post DQ polling completion.
Fix is to revert to using chip_good() for S29GL064N which only checks
for DQ lines to settle down to determine write completion.
Fixes: dfeae1073583("mtd: cfi_cmdset_0002: Change write buffer to check correct value")
Signed-off-by: Tokunori Ikegami <ikegami.t(a)gmail.com>
Cc: stable(a)vger.kernel.org
Link: https://lore.kernel.org/r/b687c259-6413-26c9-d4c9-b3afa69ea124@pengutronix.…
Tokunori Ikegami (4):
mtd: cfi_cmdset_0002: Move and rename
chip_check/chip_ready/chip_good_for_write
mtd: cfi_cmdset_0002: Use chip_ready() for write on S29GL064N
mtd: cfi_cmdset_0002: Add S29GL064N ID definition
mtd: cfi_cmdset_0002: Rename chip_ready variables
drivers/mtd/chips/cfi_cmdset_0002.c | 112 ++++++++++++++--------------
include/linux/mtd/cfi.h | 1 +
2 files changed, 55 insertions(+), 58 deletions(-)
--
2.32.0
The bug is here:
if (!iommu || iommu->dev->of_node != spec->np) {
The list iterator value 'iommu' will *always* be set and non-NULL by
list_for_each_entry(), so it is incorrect to assume that the iterator
value will be NULL if the list is empty or no element is found (in fact,
it will point to a invalid structure object containing HEAD).
To fix the bug, run insert_iommu_master(dev, &iommu, spec); unlock and
return 0 when found, otherwise unlock and return -ENODEV.
Cc: stable(a)vger.kernel.org
Fixes: f78ebca8ff3d6 ("iommu/msm: Add support for generic master bindings")
Signed-off-by: Xiaomeng Tong <xiam0nd.tong(a)gmail.com>
---
drivers/iommu/msm_iommu.c | 18 ++++++------------
1 file changed, 6 insertions(+), 12 deletions(-)
diff --git a/drivers/iommu/msm_iommu.c b/drivers/iommu/msm_iommu.c
index 3a38352b603f..1dbb8b0695ec 100644
--- a/drivers/iommu/msm_iommu.c
+++ b/drivers/iommu/msm_iommu.c
@@ -617,23 +617,17 @@ static int qcom_iommu_of_xlate(struct device *dev,
{
struct msm_iommu_dev *iommu;
unsigned long flags;
- int ret = 0;
spin_lock_irqsave(&msm_iommu_lock, flags);
list_for_each_entry(iommu, &qcom_iommu_devices, dev_node)
- if (iommu->dev->of_node == spec->np)
- break;
-
- if (!iommu || iommu->dev->of_node != spec->np) {
- ret = -ENODEV;
- goto fail;
- }
-
- insert_iommu_master(dev, &iommu, spec);
-fail:
+ if (iommu->dev->of_node == spec->np) {
+ insert_iommu_master(dev, &iommu, spec);
+ spin_unlock_irqrestore(&msm_iommu_lock, flags);
+ return 0;
+ }
spin_unlock_irqrestore(&msm_iommu_lock, flags);
- return ret;
+ return -ENODEV;
}
irqreturn_t msm_iommu_fault_handler(int irq, void *dev_id)
--
2.17.1
Based on DesignWare Ethernet QoS datasheet, we are seeing the limitation
of Split Header (SPH) feature is not supported for Ipv4 fragmented packet.
This SPH limitation will cause ping failure when the packets size exceed
the MTU size. For example, the issue happens once the basic ping packet
size is larger than the configured MTU size and the data is lost inside
the fragmented packet, replaced by zeros/corrupted values, and leads to
ping fail.
So, disable the Split Header for Intel platforms.
Cc: <stable(a)vger.kernel.org> # 5.10.x
Suggested-by: Ong, Boon Leong <boon.leong.ong(a)intel.com>
Signed-off-by: Mohammad Athari Bin Ismail <mohammad.athari.ismail(a)intel.com>
Signed-off-by: Wong Vee Khee <vee.khee.wong(a)linux.intel.com>
Signed-off-by: Tan Tee Min <tee.min.tan(a)linux.intel.com>
---
drivers/net/ethernet/stmicro/stmmac/dwmac-intel.c | 1 +
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 2 +-
include/linux/stmmac.h | 1 +
3 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-intel.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-intel.c
index 63754a9c4ba7..0b0be0898ac5 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-intel.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-intel.c
@@ -454,6 +454,7 @@ static int intel_mgbe_common_data(struct pci_dev *pdev,
plat->has_gmac4 = 1;
plat->force_sf_dma_mode = 0;
plat->tso_en = 1;
+ plat->sph_disable = 1;
/* Multiplying factor to the clk_eee_i clock time
* period to make it closer to 100 ns. This value
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 4a4b3651ab3e..2525a80353b7 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -7021,7 +7021,7 @@ int stmmac_dvr_probe(struct device *device,
dev_info(priv->device, "TSO feature enabled\n");
}
- if (priv->dma_cap.sphen) {
+ if (priv->dma_cap.sphen && !priv->plat->sph_disable) {
ndev->hw_features |= NETIF_F_GRO;
priv->sph_cap = true;
priv->sph = priv->sph_cap;
diff --git a/include/linux/stmmac.h b/include/linux/stmmac.h
index 24eea1b05ca2..29917850f079 100644
--- a/include/linux/stmmac.h
+++ b/include/linux/stmmac.h
@@ -270,5 +270,6 @@ struct plat_stmmacenet_data {
int msi_rx_base_vec;
int msi_tx_base_vec;
bool use_phy_wol;
+ bool sph_disable;
};
#endif
--
2.25.1
The patch titled
Subject: kasan: prevent cpu_quarantine corruption when CPU offline and cache shrink occur at same time
has been removed from the -mm tree. Its filename was
kasan-prevent-cpu_quarantine-corruption-when-cpu-offline-and-cache-shrink-occur-at-same-time.patch
This patch was dropped because it was merged into mainline or a subsystem tree
------------------------------------------------------
From: Zqiang <qiang1.zhang(a)intel.com>
Subject: kasan: prevent cpu_quarantine corruption when CPU offline and cache shrink occur at same time
kasan_quarantine_remove_cache() is called in kmem_cache_shrink()/
destroy(). The kasan_quarantine_remove_cache() call is protected by
cpuslock in kmem_cache_destroy() to ensure serialization with
kasan_cpu_offline().
However the kasan_quarantine_remove_cache() call is not protected by
cpuslock in kmem_cache_shrink(). When a CPU is going offline and cache
shrink occurs at same time, the cpu_quarantine may be corrupted by
interrupt (per_cpu_remove_cache operation).
So add a cpu_quarantine offline flags check in per_cpu_remove_cache().
[akpm(a)linux-foundation.org: add comment, per Zqiang]
Link: https://lkml.kernel.org/r/20220414025925.2423818-1-qiang1.zhang@intel.com
Signed-off-by: Zqiang <qiang1.zhang(a)intel.com>
Reviewed-by: Dmitry Vyukov <dvyukov(a)google.com>
Cc: Andrey Ryabinin <ryabinin.a.a(a)gmail.com>
Cc: Alexander Potapenko <glider(a)google.com>
Cc: Andrey Konovalov <andreyknvl(a)gmail.com>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
mm/kasan/quarantine.c | 7 +++++++
1 file changed, 7 insertions(+)
--- a/mm/kasan/quarantine.c~kasan-prevent-cpu_quarantine-corruption-when-cpu-offline-and-cache-shrink-occur-at-same-time
+++ a/mm/kasan/quarantine.c
@@ -315,6 +315,13 @@ static void per_cpu_remove_cache(void *a
struct qlist_head *q;
q = this_cpu_ptr(&cpu_quarantine);
+ /*
+ * Ensure the ordering between the writing to q->offline and
+ * per_cpu_remove_cache. Prevent cpu_quarantine from being corrupted
+ * by interrupt.
+ */
+ if (READ_ONCE(q->offline))
+ return;
qlist_move_cache(q, &to_free, cache);
qlist_free_all(&to_free, cache);
}
_
Patches currently in -mm which might be from qiang1.zhang(a)intel.com are
kasan-fix-sleeping-function-called-from-invalid-context-on-rt-kernel.patch
kvm_vcpu_check_block is called while not in TASK_RUNNING, and therefore
cannot sleep. Writing to guest memory is therefore forbidden, but it
can happen if kvm_check_nested_events causes a vmexit.
Fortunately, all events that are caught by kvm_check_nested_events are
also handled by kvm_vcpu_has_events through vendor callbacks such as
kvm_x86_interrupt_allowed or kvm_x86_ops.nested_ops->has_events, so
remove the call.
Cc: stable(a)vger.kernel.org
Reported-by: Maxim Levitsky <mlevitsk(a)redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini(a)redhat.com>
---
arch/x86/kvm/x86.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index d563812ca229..90b4f50b9a84 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -10341,9 +10341,6 @@ static inline int vcpu_block(struct kvm_vcpu *vcpu)
static inline bool kvm_vcpu_running(struct kvm_vcpu *vcpu)
{
- if (is_guest_mode(vcpu))
- kvm_check_nested_events(vcpu);
-
return (vcpu->arch.mp_state == KVM_MP_STATE_RUNNABLE &&
!vcpu->arch.apf.halted);
}
--
2.31.1
From: Zqiang <qiang1.zhang(a)intel.com>
Subject: kasan: prevent cpu_quarantine corruption when CPU offline and cache shrink occur at same time
kasan_quarantine_remove_cache() is called in kmem_cache_shrink()/
destroy(). The kasan_quarantine_remove_cache() call is protected by
cpuslock in kmem_cache_destroy() to ensure serialization with
kasan_cpu_offline().
However the kasan_quarantine_remove_cache() call is not protected by
cpuslock in kmem_cache_shrink(). When a CPU is going offline and cache
shrink occurs at same time, the cpu_quarantine may be corrupted by
interrupt (per_cpu_remove_cache operation).
So add a cpu_quarantine offline flags check in per_cpu_remove_cache().
[akpm(a)linux-foundation.org: add comment, per Zqiang]
Link: https://lkml.kernel.org/r/20220414025925.2423818-1-qiang1.zhang@intel.com
Signed-off-by: Zqiang <qiang1.zhang(a)intel.com>
Reviewed-by: Dmitry Vyukov <dvyukov(a)google.com>
Cc: Andrey Ryabinin <ryabinin.a.a(a)gmail.com>
Cc: Alexander Potapenko <glider(a)google.com>
Cc: Andrey Konovalov <andreyknvl(a)gmail.com>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
mm/kasan/quarantine.c | 7 +++++++
1 file changed, 7 insertions(+)
--- a/mm/kasan/quarantine.c~kasan-prevent-cpu_quarantine-corruption-when-cpu-offline-and-cache-shrink-occur-at-same-time
+++ a/mm/kasan/quarantine.c
@@ -315,6 +315,13 @@ static void per_cpu_remove_cache(void *a
struct qlist_head *q;
q = this_cpu_ptr(&cpu_quarantine);
+ /*
+ * Ensure the ordering between the writing to q->offline and
+ * per_cpu_remove_cache. Prevent cpu_quarantine from being corrupted
+ * by interrupt.
+ */
+ if (READ_ONCE(q->offline))
+ return;
qlist_move_cache(q, &to_free, cache);
qlist_free_all(&to_free, cache);
}
_
The patch titled
Subject: mm/hwpoison: use pr_err() instead of dump_page() in get_any_page()
has been added to the -mm tree. Its filename is
mm-hwpoison-use-pr_err-instead-of-dump_page-in-get_any_page.patch
This patch should soon appear at
https://ozlabs.org/~akpm/mmots/broken-out/mm-hwpoison-use-pr_err-instead-of…
and later at
https://ozlabs.org/~akpm/mmotm/broken-out/mm-hwpoison-use-pr_err-instead-of…
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/process/submit-checklist.rst when testing your code ***
The -mm tree is included into linux-next and is updated
there every 3-4 working days
------------------------------------------------------
From: Naoya Horiguchi <naoya.horiguchi(a)nec.com>
Subject: mm/hwpoison: use pr_err() instead of dump_page() in get_any_page()
The following VM_BUG_ON_FOLIO() is triggered when memory error event
happens on the (thp/folio) pages which are about to be freed:
[ 1160.232771] page:00000000b36a8a0f refcount:1 mapcount:0 mapping:0000000000000000 index:0x1 pfn:0x16a000
[ 1160.236916] page:00000000b36a8a0f refcount:0 mapcount:0 mapping:0000000000000000 index:0x1 pfn:0x16a000
[ 1160.240684] flags: 0x57ffffc0800000(hwpoison|node=1|zone=2|lastcpupid=0x1fffff)
[ 1160.243458] raw: 0057ffffc0800000 dead000000000100 dead000000000122 0000000000000000
[ 1160.246268] raw: 0000000000000001 0000000000000000 00000000ffffffff 0000000000000000
[ 1160.249197] page dumped because: VM_BUG_ON_FOLIO(!folio_test_large(folio))
[ 1160.251815] ------------[ cut here ]------------
[ 1160.253438] kernel BUG at include/linux/mm.h:788!
[ 1160.256162] invalid opcode: 0000 [#1] PREEMPT SMP PTI
[ 1160.258172] CPU: 2 PID: 115368 Comm: mceinj.sh Tainted: G E 5.18.0-rc1-v5.18-rc1-220404-2353-005-g83111+ #3
[ 1160.262049] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1.fc35 04/01/2014
[ 1160.265103] RIP: 0010:dump_page.cold+0x27e/0x2bd
[ 1160.266757] Code: fe ff ff 48 c7 c6 81 f1 5a 98 e9 4c fe ff ff 48 c7 c6 a1 95 59 98 e9 40 fe ff ff 48 c7 c6 50 bf 5a 98 48 89 ef e8 9d 04 6d ff <0f> 0b 41 f7 c4 ff 0f 00 00 0f 85 9f fd ff ff 49 8b 04 24 a9 00 00
[ 1160.273180] RSP: 0018:ffffaa2c4d59fd18 EFLAGS: 00010292
[ 1160.274969] RAX: 000000000000003e RBX: 0000000000000001 RCX: 0000000000000000
[ 1160.277263] RDX: 0000000000000001 RSI: ffffffff985995a1 RDI: 00000000ffffffff
[ 1160.279571] RBP: ffffdc9c45a80000 R08: 0000000000000000 R09: 00000000ffffdfff
[ 1160.281794] R10: ffffaa2c4d59fb08 R11: ffffffff98940d08 R12: ffffdc9c45a80000
[ 1160.283920] R13: ffffffff985b6f94 R14: 0000000000000000 R15: ffffdc9c45a80000
[ 1160.286641] FS: 00007eff54ce1740(0000) GS:ffff99c67bd00000(0000) knlGS:0000000000000000
[ 1160.289498] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 1160.291106] CR2: 00005628381a5f68 CR3: 0000000104712003 CR4: 0000000000170ee0
[ 1160.293031] Call Trace:
[ 1160.293724] <TASK>
[ 1160.294334] get_hwpoison_page+0x47d/0x570
[ 1160.295474] memory_failure+0x106/0xaa0
[ 1160.296474] ? security_capable+0x36/0x50
[ 1160.297524] hard_offline_page_store+0x43/0x80
[ 1160.298684] kernfs_fop_write_iter+0x11c/0x1b0
[ 1160.299829] new_sync_write+0xf9/0x160
[ 1160.300810] vfs_write+0x209/0x290
[ 1160.301835] ksys_write+0x4f/0xc0
[ 1160.302718] do_syscall_64+0x3b/0x90
[ 1160.303664] entry_SYSCALL_64_after_hwframe+0x44/0xae
[ 1160.304981] RIP: 0033:0x7eff54b018b7
As shown in the RIP address, this VM_BUG_ON in folio_entire_mapcount() is
called from dump_page("hwpoison: unhandlable page") in get_any_page().
The below explains the mechanism of the race:
CPU 0 CPU 1
memory_failure
get_hwpoison_page
get_any_page
dump_page
compound = PageCompound
free_pages_prepare
page->flags &= ~PAGE_FLAGS_CHECK_AT_PREP
folio_entire_mapcount
VM_BUG_ON_FOLIO(!folio_test_large(folio))
So replace dump_page() with safer one, pr_err().
Link: https://lkml.kernel.org/r/20220427053220.719866-1-naoya.horiguchi@linux.dev
Fixes: 74e8ee4708a8 ("mm: Turn head_compound_mapcount() into folio_entire_mapcount()")
Signed-off-by: Naoya Horiguchi <naoya.horiguchi(a)nec.com>
Cc: Matthew Wilcox <willy(a)infradead.org>
Cc: Miaohe Lin <linmiaohe(a)huawei.com>
Cc: Christoph Hellwig <hch(a)infradead.org>
Cc: John Hubbard <jhubbard(a)nvidia.com>
Cc: Jason Gunthorpe <jgg(a)nvidia.com>
Cc: William Kucharski <william.kucharski(a)oracle.com>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
mm/memory-failure.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/mm/memory-failure.c~mm-hwpoison-use-pr_err-instead-of-dump_page-in-get_any_page
+++ a/mm/memory-failure.c
@@ -1274,7 +1274,7 @@ try_again:
}
out:
if (ret == -EIO)
- dump_page(p, "hwpoison: unhandlable page");
+ pr_err("Memory failure: %#lx: unhandlable page.\n", page_to_pfn(p));
return ret;
}
_
Patches currently in -mm which might be from naoya.horiguchi(a)nec.com are
mm-hwpoison-use-pr_err-instead-of-dump_page-in-get_any_page.patch
mm-hwpoison-put-page-in-already-hwpoisoned-case-with-mf_count_increased.patch
revert-mm-memory-failurec-fix-race-with-changing-page-compound-again.patch
mm-hugetlb-hwpoison-separate-branch-for-free-and-in-use-hugepage.patch
The patch titled
Subject: mm/huge_memory: do not overkill when splitting huge_zero_page
has been added to the -mm tree. Its filename is
mm-huge_memory-do-not-overkill-when-splitting-huge_zero_page.patch
This patch should soon appear at
https://ozlabs.org/~akpm/mmots/broken-out/mm-huge_memory-do-not-overkill-wh…
and later at
https://ozlabs.org/~akpm/mmotm/broken-out/mm-huge_memory-do-not-overkill-wh…
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/process/submit-checklist.rst when testing your code ***
The -mm tree is included into linux-next and is updated
there every 3-4 working days
------------------------------------------------------
From: Xu Yu <xuyu(a)linux.alibaba.com>
Subject: mm/huge_memory: do not overkill when splitting huge_zero_page
Kernel panic when injecting memory_failure for the global huge_zero_page,
when CONFIG_DEBUG_VM is enabled, as follows.
Injecting memory failure for pfn 0x109ff9 at process virtual address 0x20ff9000
page:00000000fb053fc3 refcount:2 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x109e00
head:00000000fb053fc3 order:9 compound_mapcount:0 compound_pincount:0
flags: 0x17fffc000010001(locked|head|node=0|zone=2|lastcpupid=0x1ffff)
raw: 017fffc000010001 0000000000000000 dead000000000122 0000000000000000
raw: 0000000000000000 0000000000000000 00000002ffffffff 0000000000000000
page dumped because: VM_BUG_ON_PAGE(is_huge_zero_page(head))
------------[ cut here ]------------
kernel BUG at mm/huge_memory.c:2499!
invalid opcode: 0000 [#1] PREEMPT SMP PTI
CPU: 6 PID: 553 Comm: split_bug Not tainted 5.18.0-rc1+ #11
Hardware name: Alibaba Cloud Alibaba Cloud ECS, BIOS 3288b3c 04/01/2014
RIP: 0010:split_huge_page_to_list+0x66a/0x880
Code: 84 9b fb ff ff 48 8b 7c 24 08 31 f6 e8 9f 5d 2a 00 b8 b8 02 00 00 e9 e8 fb ff ff 48 c7 c6 e8 47 3c 82 4c b
RSP: 0018:ffffc90000dcbdf8 EFLAGS: 00010246
RAX: 000000000000003c RBX: 0000000000000001 RCX: 0000000000000000
RDX: 0000000000000000 RSI: ffffffff823e4c4f RDI: 00000000ffffffff
RBP: ffff88843fffdb40 R08: 0000000000000000 R09: 00000000fffeffff
R10: ffffc90000dcbc48 R11: ffffffff82d68448 R12: ffffea0004278000
R13: ffffffff823c6203 R14: 0000000000109ff9 R15: ffffea000427fe40
FS: 00007fc375a26740(0000) GS:ffff88842fd80000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007fc3757c9290 CR3: 0000000102174006 CR4: 00000000003706e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
try_to_split_thp_page+0x3a/0x130
memory_failure+0x128/0x800
madvise_inject_error.cold+0x8b/0xa1
__x64_sys_madvise+0x54/0x60
do_syscall_64+0x35/0x80
entry_SYSCALL_64_after_hwframe+0x44/0xae
RIP: 0033:0x7fc3754f8bf9
Code: 01 00 48 81 c4 80 00 00 00 e9 f1 fe ff ff 0f 1f 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 8
RSP: 002b:00007ffeda93a1d8 EFLAGS: 00000217 ORIG_RAX: 000000000000001c
RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007fc3754f8bf9
RDX: 0000000000000064 RSI: 0000000000003000 RDI: 0000000020ff9000
RBP: 00007ffeda93a200 R08: 0000000000000000 R09: 0000000000000000
R10: 00000000ffffffff R11: 0000000000000217 R12: 0000000000400490
R13: 00007ffeda93a2e0 R14: 0000000000000000 R15: 0000000000000000
We think that raising BUG is overkilling for splitting huge_zero_page, the
huge_zero_page can't be met from normal paths other than memory failure,
but memory failure is a valid caller. So we tend to replace the BUG to
WARN + returning -EBUSY, and thus the panic above won't happen again.
Link: https://lkml.kernel.org/r/f35f8b97377d5d3ede1bc5ac3114da888c57cbce.16510525…
Fixes: d173d5417fb ("mm/memory-failure.c: skip huge_zero_page in memory_failure()")
Fixes: 6a46079cf57a ("HWPOISON: The high level memory error handler in the VM v7")
Signed-off-by: Xu Yu <xuyu(a)linux.alibaba.com>
Suggested-by: Yang Shi <shy828301(a)gmail.com>
Reported-by: kernel test robot <lkp(a)intel.com>
Reviewed-by: Naoya Horiguchi <naoya.horiguchi(a)nec.com>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
mm/huge_memory.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
--- a/mm/huge_memory.c~mm-huge_memory-do-not-overkill-when-splitting-huge_zero_page
+++ a/mm/huge_memory.c
@@ -2495,11 +2495,16 @@ int split_huge_page_to_list(struct page
struct address_space *mapping = NULL;
int extra_pins, ret;
pgoff_t end;
+ bool is_hzp;
- VM_BUG_ON_PAGE(is_huge_zero_page(head), head);
VM_BUG_ON_PAGE(!PageLocked(head), head);
VM_BUG_ON_PAGE(!PageCompound(head), head);
+ is_hzp = is_huge_zero_page(head);
+ VM_WARN_ON_ONCE_PAGE(is_hzp, head);
+ if (is_hzp)
+ return -EBUSY;
+
if (PageWriteback(head))
return -EBUSY;
_
Patches currently in -mm which might be from xuyu(a)linux.alibaba.com are
revert-mm-memory-failurec-skip-huge_zero_page-in-memory_failure.patch
mm-huge_memory-do-not-overkill-when-splitting-huge_zero_page.patch
The patch titled
Subject: Revert "mm/memory-failure.c: skip huge_zero_page in memory_failure()"
has been added to the -mm tree. Its filename is
revert-mm-memory-failurec-skip-huge_zero_page-in-memory_failure.patch
This patch should soon appear at
https://ozlabs.org/~akpm/mmots/broken-out/revert-mm-memory-failurec-skip-hu…
and later at
https://ozlabs.org/~akpm/mmotm/broken-out/revert-mm-memory-failurec-skip-hu…
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/process/submit-checklist.rst when testing your code ***
The -mm tree is included into linux-next and is updated
there every 3-4 working days
------------------------------------------------------
From: Xu Yu <xuyu(a)linux.alibaba.com>
Subject: Revert "mm/memory-failure.c: skip huge_zero_page in memory_failure()"
Patch series "mm/memory-failure: rework fix on huge_zero_page splitting".
This patch (of 2):
This reverts commit d173d5417fb67411e623d394aab986d847e47dad.
The commit d173d5417fb6 ("mm/memory-failure.c: skip huge_zero_page in
memory_failure()") explicitly skips huge_zero_page in memory_failure(), in
order to avoid triggering VM_BUG_ON_PAGE on huge_zero_page in
split_huge_page_to_list().
This works, but Yang Shi thinks that,
Raising BUG is overkilling for splitting huge_zero_page. The
huge_zero_page can't be met from normal paths other than memory
failure, but memory failure is a valid caller. So I tend to replace
the BUG to WARN + returning -EBUSY. If we don't care about the
reason code in memory failure, we don't have to touch memory
failure.
And for the issue that huge_zero_page will be set PG_has_hwpoisoned,
Yang Shi comments that,
The anonymous page fault doesn't check if the page is poisoned or
not since it typically gets a fresh allocated page and assumes the
poisoned page (isolated successfully) can't be reallocated again.
But huge zero page and base zero page are reused every time. So no
matter what fix we pick, the issue is always there.
Finally, Yang, David, Anshuman and Naoya all agree to fix the bug, i.e.,
to split huge_zero_page, in split_huge_page_to_list().
This reverts the commit d173d5417fb6 ("mm/memory-failure.c: skip
huge_zero_page in memory_failure()"), and the original bug will be fixed
by the next patch.
Link: https://lkml.kernel.org/r/872cefb182ba1dd686b0e7db1e6b2ebe5a4fff87.16510396…
Fixes: d173d5417fb ("mm/memory-failure.c: skip huge_zero_page in memory_failure()")
Fixes: 6a46079cf57a ("HWPOISON: The high level memory error handler in the VM v7")
Signed-off-by: Xu Yu <xuyu(a)linux.alibaba.com>
Suggested-by: Yang Shi <shy828301(a)gmail.com>
Cc: Naoya Horiguchi <naoya.horiguchi(a)nec.com>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
mm/memory-failure.c | 13 -------------
1 file changed, 13 deletions(-)
--- a/mm/memory-failure.c~revert-mm-memory-failurec-skip-huge_zero_page-in-memory_failure
+++ a/mm/memory-failure.c
@@ -1861,19 +1861,6 @@ try_again:
if (PageTransHuge(hpage)) {
/*
- * Bail out before SetPageHasHWPoisoned() if hpage is
- * huge_zero_page, although PG_has_hwpoisoned is not
- * checked in set_huge_zero_page().
- *
- * TODO: Handle memory failure of huge_zero_page thoroughly.
- */
- if (is_huge_zero_page(hpage)) {
- action_result(pfn, MF_MSG_UNSPLIT_THP, MF_IGNORED);
- res = -EBUSY;
- goto unlock_mutex;
- }
-
- /*
* The flag must be set after the refcount is bumped
* otherwise it may race with THP split.
* And the flag can't be set in get_hwpoison_page() since
_
Patches currently in -mm which might be from xuyu(a)linux.alibaba.com are
revert-mm-memory-failurec-skip-huge_zero_page-in-memory_failure.patch
mm-huge_memory-do-not-overkill-when-splitting-huge_zero_page.patch
The following commit has been merged into the irq/urgent branch of tip:
Commit-ID: c7d2f89fea26c84d5accc55d9976dd7e5305e63a
Gitweb: https://git.kernel.org/tip/c7d2f89fea26c84d5accc55d9976dd7e5305e63a
Author: Shin'ichiro Kawasaki <shinichiro.kawasaki(a)wdc.com>
AuthorDate: Tue, 12 Apr 2022 16:56:36 +09:00
Committer: Thomas Gleixner <tglx(a)linutronix.de>
CommitterDate: Wed, 27 Apr 2022 19:42:32 +02:00
bus: fsl-mc-msi: Fix MSI descriptor mutex lock for msi_first_desc()
Commit e8604b1447b4 introduced a call to the helper function
msi_first_desc(), which needs MSI descriptor mutex lock before
call. However, the required mutex lock was not added. This results in
lockdep assertion:
WARNING: CPU: 4 PID: 119 at kernel/irq/msi.c:274 msi_first_desc+0xd0/0x10c
msi_first_desc+0xd0/0x10c
fsl_mc_msi_domain_alloc_irqs+0x7c/0xc0
fsl_mc_populate_irq_pool+0x80/0x3cc
Fix this by adding the mutex lock and unlock around the function call.
Fixes: e8604b1447b4 ("bus: fsl-mc-msi: Simplify MSI descriptor handling")
Signed-off-by: Shin'ichiro Kawasaki <shinichiro.kawasaki(a)wdc.com>
Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de>
Reviewed-by: Damien Le Moal <damien.lemoal(a)opensource.wdc.com>
Cc: stable(a)vger.kernel.org
Link: https://lore.kernel.org/r/20220412075636.755454-1-shinichiro.kawasaki@wdc.c…
---
drivers/bus/fsl-mc/fsl-mc-msi.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/bus/fsl-mc/fsl-mc-msi.c b/drivers/bus/fsl-mc/fsl-mc-msi.c
index 5e0e439..0cfe859 100644
--- a/drivers/bus/fsl-mc/fsl-mc-msi.c
+++ b/drivers/bus/fsl-mc/fsl-mc-msi.c
@@ -224,8 +224,12 @@ int fsl_mc_msi_domain_alloc_irqs(struct device *dev, unsigned int irq_count)
if (error)
return error;
+ msi_lock_descs(dev);
if (msi_first_desc(dev, MSI_DESC_ALL))
- return -EINVAL;
+ error = -EINVAL;
+ msi_unlock_descs(dev);
+ if (error)
+ return error;
/*
* NOTE: Calling this function will trigger the invocation of the
From: Wanpeng Li <wanpengli(a)tencent.com>
[ Upstream commit 0361bdfddca20c8855ea3bdbbbc9c999912b10ff ]
MSR_KVM_POLL_CONTROL is cleared on reset, thus reverting guests to
host-side polling after suspend/resume. Non-bootstrap CPUs are
restored correctly by the haltpoll driver because they are hot-unplugged
during suspend and hot-plugged during resume; however, the BSP
is not hotpluggable and remains in host-sde polling mode after
the guest resume. The makes the guest pay for the cost of vmexits
every time the guest enters idle.
Fix it by recording BSP's haltpoll state and resuming it during guest
resume.
Cc: Marcelo Tosatti <mtosatti(a)redhat.com>
Signed-off-by: Wanpeng Li <wanpengli(a)tencent.com>
Message-Id: <1650267752-46796-1-git-send-email-wanpengli(a)tencent.com>
Signed-off-by: Paolo Bonzini <pbonzini(a)redhat.com>
Signed-off-by: Sasha Levin <sashal(a)kernel.org>
---
arch/x86/kernel/kvm.c | 13 +++++++++++++
1 file changed, 13 insertions(+)
diff --git a/arch/x86/kernel/kvm.c b/arch/x86/kernel/kvm.c
index 18e952fed021..6c3d38b5a8ad 100644
--- a/arch/x86/kernel/kvm.c
+++ b/arch/x86/kernel/kvm.c
@@ -66,6 +66,7 @@ static DEFINE_PER_CPU_DECRYPTED(struct kvm_vcpu_pv_apf_data, apf_reason) __align
DEFINE_PER_CPU_DECRYPTED(struct kvm_steal_time, steal_time) __aligned(64) __visible;
static int has_steal_clock = 0;
+static int has_guest_poll = 0;
/*
* No need for any "IO delay" on KVM
*/
@@ -624,14 +625,26 @@ static int kvm_cpu_down_prepare(unsigned int cpu)
static int kvm_suspend(void)
{
+ u64 val = 0;
+
kvm_guest_cpu_offline(false);
+#ifdef CONFIG_ARCH_CPUIDLE_HALTPOLL
+ if (kvm_para_has_feature(KVM_FEATURE_POLL_CONTROL))
+ rdmsrl(MSR_KVM_POLL_CONTROL, val);
+ has_guest_poll = !(val & 1);
+#endif
return 0;
}
static void kvm_resume(void)
{
kvm_cpu_online(raw_smp_processor_id());
+
+#ifdef CONFIG_ARCH_CPUIDLE_HALTPOLL
+ if (kvm_para_has_feature(KVM_FEATURE_POLL_CONTROL) && has_guest_poll)
+ wrmsrl(MSR_KVM_POLL_CONTROL, 0);
+#endif
}
static struct syscore_ops kvm_syscore_ops = {
--
2.35.1
From: Wanpeng Li <wanpengli(a)tencent.com>
[ Upstream commit 0361bdfddca20c8855ea3bdbbbc9c999912b10ff ]
MSR_KVM_POLL_CONTROL is cleared on reset, thus reverting guests to
host-side polling after suspend/resume. Non-bootstrap CPUs are
restored correctly by the haltpoll driver because they are hot-unplugged
during suspend and hot-plugged during resume; however, the BSP
is not hotpluggable and remains in host-sde polling mode after
the guest resume. The makes the guest pay for the cost of vmexits
every time the guest enters idle.
Fix it by recording BSP's haltpoll state and resuming it during guest
resume.
Cc: Marcelo Tosatti <mtosatti(a)redhat.com>
Signed-off-by: Wanpeng Li <wanpengli(a)tencent.com>
Message-Id: <1650267752-46796-1-git-send-email-wanpengli(a)tencent.com>
Signed-off-by: Paolo Bonzini <pbonzini(a)redhat.com>
Signed-off-by: Sasha Levin <sashal(a)kernel.org>
---
arch/x86/kernel/kvm.c | 13 +++++++++++++
1 file changed, 13 insertions(+)
diff --git a/arch/x86/kernel/kvm.c b/arch/x86/kernel/kvm.c
index 408b51aba293..f582dda8dd34 100644
--- a/arch/x86/kernel/kvm.c
+++ b/arch/x86/kernel/kvm.c
@@ -59,6 +59,7 @@ static DEFINE_PER_CPU_DECRYPTED(struct kvm_vcpu_pv_apf_data, apf_reason) __align
DEFINE_PER_CPU_DECRYPTED(struct kvm_steal_time, steal_time) __aligned(64) __visible;
static int has_steal_clock = 0;
+static int has_guest_poll = 0;
/*
* No need for any "IO delay" on KVM
*/
@@ -584,14 +585,26 @@ static int kvm_cpu_down_prepare(unsigned int cpu)
static int kvm_suspend(void)
{
+ u64 val = 0;
+
kvm_guest_cpu_offline(false);
+#ifdef CONFIG_ARCH_CPUIDLE_HALTPOLL
+ if (kvm_para_has_feature(KVM_FEATURE_POLL_CONTROL))
+ rdmsrl(MSR_KVM_POLL_CONTROL, val);
+ has_guest_poll = !(val & 1);
+#endif
return 0;
}
static void kvm_resume(void)
{
kvm_cpu_online(raw_smp_processor_id());
+
+#ifdef CONFIG_ARCH_CPUIDLE_HALTPOLL
+ if (kvm_para_has_feature(KVM_FEATURE_POLL_CONTROL) && has_guest_poll)
+ wrmsrl(MSR_KVM_POLL_CONTROL, 0);
+#endif
}
static struct syscore_ops kvm_syscore_ops = {
--
2.35.1
--
Greetings,
I'm Mrs. Yameogo Oumarou, how are you doing hope you are in good health, the
Board director
try to reach you on phone several times Meanwhile, your number was not
connecting. before he ask me to send you an email to hear from you if
you are fine. hope to hear you are in good Health.
Thanks,
Mrs. Yameogo Oumarou.
While technically Xen dom0 is a virtual machine too, it does have
access to most of the hardware so it doesn't need to be considered a
"passthrough". Commit b818a5d37454 ("drm/amdgpu/gmc: use PCI BARs for
APUs in passthrough") changed how FB is accessed based on passthrough
mode. This breaks amdgpu in Xen dom0 with message like this:
[drm:dc_dmub_srv_wait_idle [amdgpu]] *ERROR* Error waiting for DMUB idle: status=3
While the reason for this failure is unclear, the passthrough mode is
not really necessary in Xen dom0 anyway. So, to unbreak booting affected
kernels, disable passthrough mode in this case.
Link: https://gitlab.freedesktop.org/drm/amd/-/issues/1985
Fixes: b818a5d37454 ("drm/amdgpu/gmc: use PCI BARs for APUs in passthrough")
Signed-off-by: Marek Marczykowski-Górecki <marmarek(a)invisiblethingslab.com>
Cc: stable(a)vger.kernel.org
---
drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c
index a025f080aa6a..5e3756643da3 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c
@@ -24,6 +24,7 @@
#include <linux/module.h>
#include <drm/drm_drv.h>
+#include <xen/xen.h>
#include "amdgpu.h"
#include "amdgpu_ras.h"
@@ -710,7 +711,8 @@ void amdgpu_detect_virtualization(struct amdgpu_device *adev)
adev->virt.caps |= AMDGPU_SRIOV_CAPS_ENABLE_IOV;
if (!reg) {
- if (is_virtual_machine()) /* passthrough mode exclus sriov mod */
+ /* passthrough mode exclus sriov mod */
+ if (is_virtual_machine() && !xen_initial_domain())
adev->virt.caps |= AMDGPU_PASSTHROUGH_MODE;
}
--
2.35.1
There are 3 places where the cpu and node masks of the top cpuset can
be initialized in the order they are executed:
1) start_kernel -> cpuset_init()
2) start_kernel -> cgroup_init() -> cpuset_bind()
3) kernel_init_freeable() -> do_basic_setup() -> cpuset_init_smp()
The first cpuset_init() function just sets all the bits in the masks.
The last one executed is cpuset_init_smp() which sets up cpu and node
masks suitable for v1, but not v2. cpuset_bind() does the right setup
for both v1 and v2.
For systems with cgroup v2 setup, cpuset_bind() is called once. For
systems with cgroup v1 setup, cpuset_bind() is called twice. It is
first called before cpuset_init_smp() in cgroup v2 mode. Then it is
called again when cgroup v1 filesystem is mounted in v1 mode after
cpuset_init_smp().
[ 2.609781] cpuset_bind() called - v2 = 1
[ 3.079473] cpuset_init_smp() called
[ 7.103710] cpuset_bind() called - v2 = 0
As a result, cpu and memory node hot add may fail to update the cpu and
node masks of the top cpuset to include the newly added cpu or node in
a cgroup v2 environment.
smp_init() is called after the first two init functions. So we don't
have a complete list of active cpus and memory nodes until later in
cpuset_init_smp() which is the right time to set up effective_cpus
and effective_mems.
To fix this problem, the potentially incorrect cpus_allowed &
mems_allowed setup in cpuset_init_smp() are removed. For cgroup v2
systems, the initial cpuset_bind() call will set them up correctly.
For cgroup v1 systems, the second call to cpuset_bind() will do the
right setup.
cc: stable(a)vger.kernel.org
Signed-off-by: Waiman Long <longman(a)redhat.com>
---
kernel/cgroup/cpuset.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/kernel/cgroup/cpuset.c b/kernel/cgroup/cpuset.c
index 9390bfd9f1cd..6bd8f5ef40fe 100644
--- a/kernel/cgroup/cpuset.c
+++ b/kernel/cgroup/cpuset.c
@@ -3390,8 +3390,9 @@ static struct notifier_block cpuset_track_online_nodes_nb = {
*/
void __init cpuset_init_smp(void)
{
- cpumask_copy(top_cpuset.cpus_allowed, cpu_active_mask);
- top_cpuset.mems_allowed = node_states[N_MEMORY];
+ /*
+ * cpus_allowd/mems_allowed will be properly set up in cpuset_bind().
+ */
top_cpuset.old_mems_allowed = top_cpuset.mems_allowed;
cpumask_copy(top_cpuset.effective_cpus, cpu_active_mask);
--
2.27.0
I'm announcing the release of the 4.9.312 kernel.
All users of the 4.9 kernel series must upgrade.
The updated 4.9.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-4.9.y
and can be browsed at the normal kernel.org git web browser:
https://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary
thanks,
greg k-h
------------
Makefile | 2 -
arch/arc/kernel/entry.S | 1
arch/arm/mach-vexpress/spc.c | 2 -
block/compat_ioctl.c | 2 -
drivers/ata/pata_marvell.c | 2 +
drivers/dma/at_xdmac.c | 12 +++++-----
drivers/dma/imx-sdma.c | 4 +--
drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c | 3 ++
drivers/net/ethernet/intel/e1000e/ich8lan.c | 4 +--
drivers/net/vxlan.c | 4 +--
drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c | 2 -
drivers/platform/x86/samsung-laptop.c | 2 -
fs/cifs/cifsfs.c | 2 -
fs/ext4/inode.c | 11 ++++++++-
fs/ext4/super.c | 19 ++++++++++++----
fs/gfs2/rgrp.c | 9 ++++---
include/linux/etherdevice.h | 5 +---
mm/page_alloc.c | 2 -
net/netlink/af_netlink.c | 7 +++++
net/openvswitch/flow_netlink.c | 2 -
net/packet/af_packet.c | 13 +++++++---
sound/soc/soc-dapm.c | 6 +----
sound/usb/midi.c | 1
sound/usb/usbaudio.h | 2 -
24 files changed, 78 insertions(+), 41 deletions(-)
Bob Peterson (1):
gfs2: assign rgrp glock before compute_bitstructs
Borislav Petkov (2):
ALSA: usb-audio: Fix undefined behavior due to shift overflowing the constant
brcmfmac: sdio: Fix undefined behavior due to shift overflowing the constant
David Howells (1):
cifs: Check the IOCB_DIRECT flag, not O_DIRECT
Eric Dumazet (1):
netlink: reset network and mac headers in netlink_dump()
Greg Kroah-Hartman (1):
Linux 4.9.312
Hangbin Liu (1):
net/packet: fix packet_sock xmit return value checking
Hongbin Wang (1):
vxlan: fix error return code in vxlan_fdb_append
Jiapeng Chong (1):
platform/x86: samsung-laptop: Fix an unsigned comparison which can never be negative
Kees Cook (2):
etherdevice: Adjust ether_addr* prototypes to silence -Wstringop-overead
ARM: vexpress/spc: Avoid negative array index when !SMP
Khazhismel Kumykov (1):
block/compat_ioctl: fix range check in BLKGETSIZE
Miaoqian Lin (1):
dmaengine: imx-sdma: Fix error checking in sdma_event_remap
Paolo Valerio (1):
openvswitch: fix OOB access in reserve_sfa_size()
Sasha Neftin (1):
e1000e: Fix possible overflow in LTR decoding
Sergey Matyukevich (1):
ARC: entry: fix syscall_trace_exit argument
Tadeusz Struk (1):
ext4: limit length to bitmap_maxbytes - blocksize in punch_hole
Takashi Iwai (1):
ALSA: usb-audio: Clear MIDI port active flag after draining
Theodore Ts'o (2):
ext4: fix overhead calculation to account for the reserved gdt blocks
ext4: force overhead calculation if the s_overhead_cluster makes no sense
Xiaoke Wang (1):
drm/msm/mdp5: check the return of kzalloc()
Xiaomeng Tong (2):
dma: at_xdmac: fix a missing check on list iterator
ASoC: soc-dapm: fix two incorrect uses of list iterator
Xiongwei Song (1):
mm: page_alloc: fix building error on -Werror=array-compare
Zheyu Ma (1):
ata: pata_marvell: Check the 'bmdma_addr' beforing reading
This is the start of the stable review cycle for the 5.4.191 release.
There are 62 patches in this series, all will be posted as a response
to this one. If anyone has any issues with these being applied, please
let me know.
Responses should be made by Thu, 28 Apr 2022 08:17:22 +0000.
Anything received after that time might be too late.
The whole patch series can be found in one patch at:
https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.4.191-rc…
or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.4.y
and the diffstat can be found below.
thanks,
greg k-h
-------------
Pseudo-Shortlog of commits:
Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Linux 5.4.191-rc1
Marek Vasut <marex(a)denx.de>
Revert "net: micrel: fix KS8851_MLL Kconfig"
Khazhismel Kumykov <khazhy(a)google.com>
block/compat_ioctl: fix range check in BLKGETSIZE
Lee Jones <lee.jones(a)linaro.org>
staging: ion: Prevent incorrect reference counting behavour
Tudor Ambarus <tudor.ambarus(a)microchip.com>
spi: atmel-quadspi: Fix the buswidth adjustment between spi-mem and controller
Ye Bin <yebin10(a)huawei.com>
jbd2: fix a potential race while discarding reserved buffers after an abort
Theodore Ts'o <tytso(a)mit.edu>
ext4: force overhead calculation if the s_overhead_cluster makes no sense
Theodore Ts'o <tytso(a)mit.edu>
ext4: fix overhead calculation to account for the reserved gdt blocks
wangjianjian (C) <wangjianjian3(a)huawei.com>
ext4, doc: fix incorrect h_reserved size
Tadeusz Struk <tadeusz.struk(a)linaro.org>
ext4: limit length to bitmap_maxbytes - blocksize in punch_hole
Ye Bin <yebin10(a)huawei.com>
ext4: fix use-after-free in ext4_search_dir
Ye Bin <yebin10(a)huawei.com>
ext4: fix symlink file size not match to file content
Rob Herring <robh(a)kernel.org>
arm_pmu: Validate single/group leader events
Sergey Matyukevich <sergey.matyukevich(a)synopsys.com>
ARC: entry: fix syscall_trace_exit argument
Sasha Neftin <sasha.neftin(a)intel.com>
e1000e: Fix possible overflow in LTR decoding
Xiaomeng Tong <xiam0nd.tong(a)gmail.com>
ASoC: soc-dapm: fix two incorrect uses of list iterator
Paolo Valerio <pvalerio(a)redhat.com>
openvswitch: fix OOB access in reserve_sfa_size()
Max Filippov <jcmvbkbc(a)gmail.com>
xtensa: fix a7 clobbering in coprocessor context load/store
Guo Ren <guoren(a)linux.alibaba.com>
xtensa: patch_text: Fixup last cpu should be master
Athira Rajeev <atrajeev(a)linux.vnet.ibm.com>
powerpc/perf: Fix power9 event alternatives
Miaoqian Lin <linmq006(a)gmail.com>
drm/vc4: Use pm_runtime_resume_and_get to fix pm_runtime_get_sync() usage
Alexey Kardashevskiy <aik(a)ozlabs.ru>
KVM: PPC: Fix TCE handling for VFIO
Dave Stevenson <dave.stevenson(a)raspberrypi.com>
drm/panel/raspberrypi-touchscreen: Initialise the bridge in prepare
Dave Stevenson <dave.stevenson(a)raspberrypi.com>
drm/panel/raspberrypi-touchscreen: Avoid NULL deref if not initialised
Xiaomeng Tong <xiam0nd.tong(a)gmail.com>
dma: at_xdmac: fix a missing check on list iterator
Zheyu Ma <zheyuma97(a)gmail.com>
ata: pata_marvell: Check the 'bmdma_addr' beforing reading
Nico Pache <npache(a)redhat.com>
oom_kill.c: futex: delay the OOM reaper to allow time for proper futex cleanup
Shubhrajyoti Datta <shubhrajyoti.datta(a)xilinx.com>
EDAC/synopsys: Read the error count from the correct register
Mikulas Patocka <mpatocka(a)redhat.com>
stat: fix inconsistency between struct stat and struct compat_stat
Mike Christie <michael.christie(a)oracle.com>
scsi: qedi: Fix failed disconnect handling
Tomas Melin <tomas.melin(a)vaisala.com>
net: macb: Restart tx only if queue pointer is lagging
Xiaoke Wang <xkernel.wang(a)foxmail.com>
drm/msm/mdp5: check the return of kzalloc()
Lv Ruyi <lv.ruyi(a)zte.com.cn>
dpaa_eth: Fix missing of_node_put in dpaa_get_ts_info()
Borislav Petkov <bp(a)alien8.de>
brcmfmac: sdio: Fix undefined behavior due to shift overflowing the constant
Borislav Petkov <bp(a)suse.de>
mt76: Fix undefined behavior due to shift overflowing the constant
David Howells <dhowells(a)redhat.com>
cifs: Check the IOCB_DIRECT flag, not O_DIRECT
Hongbin Wang <wh_bin(a)126.com>
vxlan: fix error return code in vxlan_fdb_append
Borislav Petkov <bp(a)suse.de>
ALSA: usb-audio: Fix undefined behavior due to shift overflowing the constant
Jiapeng Chong <jiapeng.chong(a)linux.alibaba.com>
platform/x86: samsung-laptop: Fix an unsigned comparison which can never be negative
Sameer Pujar <spujar(a)nvidia.com>
reset: tegra-bpmp: Restore Handle errors in BPMP response
Kees Cook <keescook(a)chromium.org>
ARM: vexpress/spc: Avoid negative array index when !SMP
Ido Schimmel <idosch(a)nvidia.com>
selftests: mlxsw: vxlan_flooding: Prevent flooding of unwanted packets
Eric Dumazet <edumazet(a)google.com>
netlink: reset network and mac headers in netlink_dump()
David Ahern <dsahern(a)kernel.org>
l3mdev: l3mdev_master_upper_ifindex_by_index_rcu should be using netdev_master_upper_dev_get_rcu
Eric Dumazet <edumazet(a)google.com>
net/sched: cls_u32: fix possible leak in u32_init_knode()
Hangbin Liu <liuhangbin(a)gmail.com>
net/packet: fix packet_sock xmit return value checking
Tony Lu <tonylu(a)linux.alibaba.com>
net/smc: Fix sock leak when release after smc_shutdown()
David Howells <dhowells(a)redhat.com>
rxrpc: Restore removed timer deletion
Sasha Neftin <sasha.neftin(a)intel.com>
igc: Fix BUG: scheduling while atomic
Sasha Neftin <sasha.neftin(a)intel.com>
igc: Fix infinite loop in release_swfw_sync
zhangqilong <zhangqilong3(a)huawei.com>
dmaengine: mediatek:Fix PM usage reference leak of mtk_uart_apdma_alloc_chan_resources
Miaoqian Lin <linmq006(a)gmail.com>
dmaengine: imx-sdma: Fix error checking in sdma_event_remap
Miaoqian Lin <linmq006(a)gmail.com>
ASoC: msm8916-wcd-digital: Check failure for devm_snd_soc_register_component
Mark Brown <broonie(a)kernel.org>
ASoC: atmel: Remove system clock tree configuration for at91sam9g20ek
Takashi Iwai <tiwai(a)suse.de>
ALSA: usb-audio: Clear MIDI port active flag after draining
Kuniyuki Iwashima <kuniyu(a)amazon.co.jp>
tcp: Fix potential use-after-free due to double kfree()
Eric Dumazet <edumazet(a)google.com>
net/sched: cls_u32: fix netns refcount changes in u32_change()
Ricardo Dias <rdias(a)singlestore.com>
tcp: fix race condition when creating child sockets from syncookies
Bob Peterson <rpeterso(a)redhat.com>
gfs2: assign rgrp glock before compute_bitstructs
Hangyu Hua <hbh25y(a)gmail.com>
can: usb_8dev: usb_8dev_start_xmit(): fix double dev_kfree_skb() in error path
Daniel Bristot de Oliveira <bristot(a)kernel.org>
tracing: Dump stacktrace trigger to the corresponding instance
Xiongwei Song <sxwjean(a)gmail.com>
mm: page_alloc: fix building error on -Werror=array-compare
Kees Cook <keescook(a)chromium.org>
etherdevice: Adjust ether_addr* prototypes to silence -Wstringop-overead
-------------
Diffstat:
Documentation/filesystems/ext4/attributes.rst | 2 +-
Makefile | 4 +-
arch/arc/kernel/entry.S | 1 +
arch/arm/mach-vexpress/spc.c | 2 +-
arch/powerpc/kvm/book3s_64_vio.c | 45 +++++++-------
arch/powerpc/kvm/book3s_64_vio_hv.c | 44 +++++++-------
arch/powerpc/perf/power9-pmu.c | 8 +--
arch/x86/include/asm/compat.h | 6 +-
arch/xtensa/kernel/coprocessor.S | 4 +-
arch/xtensa/kernel/jump_label.c | 2 +-
block/compat_ioctl.c | 2 +-
drivers/ata/pata_marvell.c | 2 +
drivers/dma/at_xdmac.c | 12 ++--
drivers/dma/imx-sdma.c | 4 +-
drivers/dma/mediatek/mtk-uart-apdma.c | 9 ++-
drivers/edac/synopsys_edac.c | 16 +++--
drivers/gpu/drm/msm/disp/mdp5/mdp5_plane.c | 3 +
.../gpu/drm/panel/panel-raspberrypi-touchscreen.c | 13 +++-
drivers/gpu/drm/vc4/vc4_dsi.c | 2 +-
drivers/net/can/usb/usb_8dev.c | 30 +++++-----
drivers/net/ethernet/cadence/macb_main.c | 8 +++
drivers/net/ethernet/freescale/dpaa/dpaa_ethtool.c | 8 ++-
drivers/net/ethernet/intel/e1000e/ich8lan.c | 4 +-
drivers/net/ethernet/intel/igc/igc_i225.c | 11 +++-
drivers/net/ethernet/intel/igc/igc_phy.c | 4 +-
drivers/net/ethernet/micrel/Kconfig | 1 -
drivers/net/vxlan.c | 4 +-
.../wireless/broadcom/brcm80211/brcmfmac/sdio.c | 2 +-
drivers/net/wireless/mediatek/mt76/mt76x2/pci.c | 2 +-
drivers/perf/arm_pmu.c | 10 ++--
drivers/platform/x86/samsung-laptop.c | 2 -
drivers/reset/tegra/reset-bpmp.c | 9 ++-
drivers/scsi/qedi/qedi_iscsi.c | 69 +++++++++++-----------
drivers/spi/atmel-quadspi.c | 3 +
drivers/staging/android/ion/ion.c | 3 +
fs/cifs/cifsfs.c | 2 +-
fs/ext4/ext4.h | 4 ++
fs/ext4/inode.c | 11 +++-
fs/ext4/namei.c | 4 +-
fs/ext4/page-io.c | 4 +-
fs/ext4/super.c | 19 ++++--
fs/gfs2/rgrp.c | 9 +--
fs/jbd2/commit.c | 4 +-
fs/stat.c | 19 +++---
include/linux/etherdevice.h | 5 +-
include/linux/sched.h | 1 +
include/net/inet_hashtables.h | 5 +-
kernel/trace/trace_events_trigger.c | 9 ++-
mm/oom_kill.c | 54 ++++++++++++-----
mm/page_alloc.c | 2 +-
net/dccp/ipv4.c | 2 +-
net/dccp/ipv6.c | 2 +-
net/ipv4/inet_connection_sock.c | 2 +-
net/ipv4/inet_hashtables.c | 68 ++++++++++++++++++---
net/ipv4/tcp_ipv4.c | 13 +++-
net/ipv6/tcp_ipv6.c | 13 +++-
net/l3mdev/l3mdev.c | 2 +-
net/netlink/af_netlink.c | 7 +++
net/openvswitch/flow_netlink.c | 2 +-
net/packet/af_packet.c | 13 ++--
net/rxrpc/net_ns.c | 2 +
net/sched/cls_u32.c | 24 ++++----
net/smc/af_smc.c | 4 +-
sound/soc/atmel/sam9g20_wm8731.c | 61 -------------------
sound/soc/codecs/msm8916-wcd-digital.c | 9 ++-
sound/soc/soc-dapm.c | 6 +-
sound/usb/midi.c | 1 +
sound/usb/usbaudio.h | 2 +-
.../selftests/drivers/net/mlxsw/vxlan_flooding.sh | 17 ++++++
69 files changed, 460 insertions(+), 293 deletions(-)
As Yanming reported in bugzilla:
https://bugzilla.kernel.org/show_bug.cgi?id=215894
I have encountered a bug in F2FS file system in kernel v5.17.
I have uploaded the system call sequence as case.c, and a fuzzed image can
be found in google net disk
The kernel should enable CONFIG_KASAN=y and CONFIG_KASAN_INLINE=y. You can
reproduce the bug by running the following commands:
kernel BUG at fs/f2fs/segment.c:2291!
Call Trace:
f2fs_invalidate_blocks+0x193/0x2d0
f2fs_fallocate+0x2593/0x4a70
vfs_fallocate+0x2a5/0xac0
ksys_fallocate+0x35/0x70
__x64_sys_fallocate+0x8e/0xf0
do_syscall_64+0x3b/0x90
entry_SYSCALL_64_after_hwframe+0x44/0xae
The root cause is, after image was fuzzed, block mapping info in inode
will be inconsistent with SIT table, so in f2fs_fallocate(), it will cause
panic when updating SIT with invalid blkaddr.
Let's fix the issue by adding sanity check on block address before updating
SIT table with it.
Cc: stable(a)vger.kernel.org
Reported-by: Ming Yan <yanming(a)tju.edu.cn>
Signed-off-by: Chao Yu <chao.yu(a)oppo.com>
---
fs/f2fs/file.c | 16 ++++++++++++----
1 file changed, 12 insertions(+), 4 deletions(-)
diff --git a/fs/f2fs/file.c b/fs/f2fs/file.c
index f08e6208e183..342b1f17a033 100644
--- a/fs/f2fs/file.c
+++ b/fs/f2fs/file.c
@@ -1437,11 +1437,19 @@ static int f2fs_do_zero_range(struct dnode_of_data *dn, pgoff_t start,
ret = -ENOSPC;
break;
}
- if (dn->data_blkaddr != NEW_ADDR) {
- f2fs_invalidate_blocks(sbi, dn->data_blkaddr);
- dn->data_blkaddr = NEW_ADDR;
- f2fs_set_data_blkaddr(dn);
+
+ if (dn->data_blkaddr == NEW_ADDR)
+ continue;
+
+ if (!f2fs_is_valid_blkaddr(sbi, dn->data_blkaddr,
+ DATA_GENERIC_ENHANCE)) {
+ ret = -EFSCORRUPTED;
+ break;
}
+
+ f2fs_invalidate_blocks(sbi, dn->data_blkaddr);
+ dn->data_blkaddr = NEW_ADDR;
+ f2fs_set_data_blkaddr(dn);
}
f2fs_update_extent_cache_range(dn, start, 0, index - start);
--
2.25.1
This is the start of the stable review cycle for the 4.14.277 release.
There are 43 patches in this series, all will be posted as a response
to this one. If anyone has any issues with these being applied, please
let me know.
Responses should be made by Thu, 28 Apr 2022 08:17:22 +0000.
Anything received after that time might be too late.
The whole patch series can be found in one patch at:
https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.14.277-r…
or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.14.y
and the diffstat can be found below.
thanks,
greg k-h
-------------
Pseudo-Shortlog of commits:
Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Linux 4.14.277-rc1
Marek Vasut <marex(a)denx.de>
Revert "net: micrel: fix KS8851_MLL Kconfig"
Duoming Zhou <duoming(a)zju.edu.cn>
ax25: Fix UAF bugs in ax25 timers
Duoming Zhou <duoming(a)zju.edu.cn>
ax25: Fix NULL pointer dereferences in ax25 timers
Duoming Zhou <duoming(a)zju.edu.cn>
ax25: fix NPD bug in ax25_disconnect
Duoming Zhou <duoming(a)zju.edu.cn>
ax25: fix UAF bug in ax25_send_control()
Duoming Zhou <duoming(a)zju.edu.cn>
ax25: Fix refcount leaks caused by ax25_cb_del()
Duoming Zhou <duoming(a)zju.edu.cn>
ax25: fix UAF bugs of net_device caused by rebinding operation
Duoming Zhou <duoming(a)zju.edu.cn>
ax25: fix reference count leaks of ax25_dev
Duoming Zhou <duoming(a)zju.edu.cn>
ax25: add refcount in ax25_dev to avoid UAF bugs
Khazhismel Kumykov <khazhy(a)google.com>
block/compat_ioctl: fix range check in BLKGETSIZE
Lee Jones <lee.jones(a)linaro.org>
staging: ion: Prevent incorrect reference counting behavour
Theodore Ts'o <tytso(a)mit.edu>
ext4: force overhead calculation if the s_overhead_cluster makes no sense
Theodore Ts'o <tytso(a)mit.edu>
ext4: fix overhead calculation to account for the reserved gdt blocks
Tadeusz Struk <tadeusz.struk(a)linaro.org>
ext4: limit length to bitmap_maxbytes - blocksize in punch_hole
Ye Bin <yebin10(a)huawei.com>
ext4: fix symlink file size not match to file content
Sergey Matyukevich <sergey.matyukevich(a)synopsys.com>
ARC: entry: fix syscall_trace_exit argument
Sasha Neftin <sasha.neftin(a)intel.com>
e1000e: Fix possible overflow in LTR decoding
Xiaomeng Tong <xiam0nd.tong(a)gmail.com>
ASoC: soc-dapm: fix two incorrect uses of list iterator
Paolo Valerio <pvalerio(a)redhat.com>
openvswitch: fix OOB access in reserve_sfa_size()
Athira Rajeev <atrajeev(a)linux.vnet.ibm.com>
powerpc/perf: Fix power9 event alternatives
Xiaomeng Tong <xiam0nd.tong(a)gmail.com>
dma: at_xdmac: fix a missing check on list iterator
Zheyu Ma <zheyuma97(a)gmail.com>
ata: pata_marvell: Check the 'bmdma_addr' beforing reading
Mikulas Patocka <mpatocka(a)redhat.com>
stat: fix inconsistency between struct stat and struct compat_stat
Tomas Melin <tomas.melin(a)vaisala.com>
net: macb: Restart tx only if queue pointer is lagging
Xiaoke Wang <xkernel.wang(a)foxmail.com>
drm/msm/mdp5: check the return of kzalloc()
Borislav Petkov <bp(a)alien8.de>
brcmfmac: sdio: Fix undefined behavior due to shift overflowing the constant
David Howells <dhowells(a)redhat.com>
cifs: Check the IOCB_DIRECT flag, not O_DIRECT
Hongbin Wang <wh_bin(a)126.com>
vxlan: fix error return code in vxlan_fdb_append
Borislav Petkov <bp(a)suse.de>
ALSA: usb-audio: Fix undefined behavior due to shift overflowing the constant
Jiapeng Chong <jiapeng.chong(a)linux.alibaba.com>
platform/x86: samsung-laptop: Fix an unsigned comparison which can never be negative
Kees Cook <keescook(a)chromium.org>
ARM: vexpress/spc: Avoid negative array index when !SMP
Eric Dumazet <edumazet(a)google.com>
netlink: reset network and mac headers in netlink_dump()
Hangbin Liu <liuhangbin(a)gmail.com>
net/packet: fix packet_sock xmit return value checking
Miaoqian Lin <linmq006(a)gmail.com>
dmaengine: imx-sdma: Fix error checking in sdma_event_remap
Kuniyuki Iwashima <kuniyu(a)amazon.co.jp>
tcp: Fix potential use-after-free due to double kfree()
Ricardo Dias <rdias(a)singlestore.com>
tcp: fix race condition when creating child sockets from syncookies
Takashi Iwai <tiwai(a)suse.de>
ALSA: usb-audio: Clear MIDI port active flag after draining
Bob Peterson <rpeterso(a)redhat.com>
gfs2: assign rgrp glock before compute_bitstructs
Hangyu Hua <hbh25y(a)gmail.com>
can: usb_8dev: usb_8dev_start_xmit(): fix double dev_kfree_skb() in error path
Daniel Bristot de Oliveira <bristot(a)kernel.org>
tracing: Dump stacktrace trigger to the corresponding instance
Steven Rostedt (Google) <rostedt(a)goodmis.org>
tracing: Have traceon and traceoff trigger honor the instance
Xiongwei Song <sxwjean(a)gmail.com>
mm: page_alloc: fix building error on -Werror=array-compare
Kees Cook <keescook(a)chromium.org>
etherdevice: Adjust ether_addr* prototypes to silence -Wstringop-overead
-------------
Diffstat:
Makefile | 4 +-
arch/arc/kernel/entry.S | 1 +
arch/arm/mach-vexpress/spc.c | 2 +-
arch/powerpc/perf/power9-pmu.c | 8 +--
arch/x86/include/asm/compat.h | 6 +-
block/compat_ioctl.c | 2 +-
drivers/ata/pata_marvell.c | 2 +
drivers/dma/at_xdmac.c | 12 ++--
drivers/dma/imx-sdma.c | 4 +-
drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c | 3 +
drivers/net/can/usb/usb_8dev.c | 30 +++++-----
drivers/net/ethernet/cadence/macb_main.c | 8 +++
drivers/net/ethernet/intel/e1000e/ich8lan.c | 4 +-
drivers/net/ethernet/micrel/Kconfig | 1 -
drivers/net/vxlan.c | 4 +-
.../wireless/broadcom/brcm80211/brcmfmac/sdio.c | 2 +-
drivers/platform/x86/samsung-laptop.c | 2 -
drivers/staging/android/ion/ion.c | 3 +
fs/cifs/cifsfs.c | 2 +-
fs/ext4/inode.c | 11 +++-
fs/ext4/page-io.c | 4 +-
fs/ext4/super.c | 19 ++++--
fs/gfs2/rgrp.c | 9 +--
fs/stat.c | 19 +++---
include/linux/etherdevice.h | 5 +-
include/net/ax25.h | 12 ++++
include/net/inet_hashtables.h | 5 +-
kernel/trace/trace_events_trigger.c | 61 ++++++++++++++++---
mm/page_alloc.c | 2 +-
net/ax25/af_ax25.c | 38 +++++++++---
net/ax25/ax25_dev.c | 28 +++++++--
net/ax25/ax25_route.c | 13 ++++-
net/ax25/ax25_subr.c | 20 +++++--
net/dccp/ipv4.c | 2 +-
net/dccp/ipv6.c | 2 +-
net/ipv4/inet_connection_sock.c | 2 +-
net/ipv4/inet_hashtables.c | 68 +++++++++++++++++++---
net/ipv4/tcp_ipv4.c | 13 ++++-
net/ipv6/tcp_ipv6.c | 13 ++++-
net/netlink/af_netlink.c | 7 +++
net/openvswitch/flow_netlink.c | 2 +-
net/packet/af_packet.c | 13 +++--
sound/soc/soc-dapm.c | 6 +-
sound/usb/midi.c | 1 +
sound/usb/usbaudio.h | 2 +-
45 files changed, 357 insertions(+), 120 deletions(-)
This is the start of the stable review cycle for the 4.9.312 release.
There are 24 patches in this series, all will be posted as a response
to this one. If anyone has any issues with these being applied, please
let me know.
Responses should be made by Thu, 28 Apr 2022 08:17:22 +0000.
Anything received after that time might be too late.
The whole patch series can be found in one patch at:
https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.9.312-rc…
or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.9.y
and the diffstat can be found below.
thanks,
greg k-h
-------------
Pseudo-Shortlog of commits:
Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Linux 4.9.312-rc1
Khazhismel Kumykov <khazhy(a)google.com>
block/compat_ioctl: fix range check in BLKGETSIZE
Theodore Ts'o <tytso(a)mit.edu>
ext4: force overhead calculation if the s_overhead_cluster makes no sense
Theodore Ts'o <tytso(a)mit.edu>
ext4: fix overhead calculation to account for the reserved gdt blocks
Tadeusz Struk <tadeusz.struk(a)linaro.org>
ext4: limit length to bitmap_maxbytes - blocksize in punch_hole
Sergey Matyukevich <sergey.matyukevich(a)synopsys.com>
ARC: entry: fix syscall_trace_exit argument
Sasha Neftin <sasha.neftin(a)intel.com>
e1000e: Fix possible overflow in LTR decoding
Xiaomeng Tong <xiam0nd.tong(a)gmail.com>
ASoC: soc-dapm: fix two incorrect uses of list iterator
Paolo Valerio <pvalerio(a)redhat.com>
openvswitch: fix OOB access in reserve_sfa_size()
Xiaomeng Tong <xiam0nd.tong(a)gmail.com>
dma: at_xdmac: fix a missing check on list iterator
Zheyu Ma <zheyuma97(a)gmail.com>
ata: pata_marvell: Check the 'bmdma_addr' beforing reading
Xiaoke Wang <xkernel.wang(a)foxmail.com>
drm/msm/mdp5: check the return of kzalloc()
Borislav Petkov <bp(a)alien8.de>
brcmfmac: sdio: Fix undefined behavior due to shift overflowing the constant
David Howells <dhowells(a)redhat.com>
cifs: Check the IOCB_DIRECT flag, not O_DIRECT
Hongbin Wang <wh_bin(a)126.com>
vxlan: fix error return code in vxlan_fdb_append
Borislav Petkov <bp(a)suse.de>
ALSA: usb-audio: Fix undefined behavior due to shift overflowing the constant
Jiapeng Chong <jiapeng.chong(a)linux.alibaba.com>
platform/x86: samsung-laptop: Fix an unsigned comparison which can never be negative
Kees Cook <keescook(a)chromium.org>
ARM: vexpress/spc: Avoid negative array index when !SMP
Eric Dumazet <edumazet(a)google.com>
netlink: reset network and mac headers in netlink_dump()
Hangbin Liu <liuhangbin(a)gmail.com>
net/packet: fix packet_sock xmit return value checking
Miaoqian Lin <linmq006(a)gmail.com>
dmaengine: imx-sdma: Fix error checking in sdma_event_remap
Takashi Iwai <tiwai(a)suse.de>
ALSA: usb-audio: Clear MIDI port active flag after draining
Bob Peterson <rpeterso(a)redhat.com>
gfs2: assign rgrp glock before compute_bitstructs
Xiongwei Song <sxwjean(a)gmail.com>
mm: page_alloc: fix building error on -Werror=array-compare
Kees Cook <keescook(a)chromium.org>
etherdevice: Adjust ether_addr* prototypes to silence -Wstringop-overead
-------------
Diffstat:
Makefile | 4 ++--
arch/arc/kernel/entry.S | 1 +
arch/arm/mach-vexpress/spc.c | 2 +-
block/compat_ioctl.c | 2 +-
drivers/ata/pata_marvell.c | 2 ++
drivers/dma/at_xdmac.c | 12 +++++++-----
drivers/dma/imx-sdma.c | 4 ++--
drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c | 3 +++
drivers/net/ethernet/intel/e1000e/ich8lan.c | 4 ++--
drivers/net/vxlan.c | 4 ++--
.../net/wireless/broadcom/brcm80211/brcmfmac/sdio.c | 2 +-
drivers/platform/x86/samsung-laptop.c | 2 --
fs/cifs/cifsfs.c | 2 +-
fs/ext4/inode.c | 11 ++++++++++-
fs/ext4/super.c | 19 +++++++++++++++----
fs/gfs2/rgrp.c | 9 +++++----
include/linux/etherdevice.h | 5 ++---
mm/page_alloc.c | 2 +-
net/netlink/af_netlink.c | 7 +++++++
net/openvswitch/flow_netlink.c | 2 +-
net/packet/af_packet.c | 13 +++++++++----
sound/soc/soc-dapm.c | 6 ++----
sound/usb/midi.c | 1 +
sound/usb/usbaudio.h | 2 +-
24 files changed, 79 insertions(+), 42 deletions(-)
Using not existing queues can panic the kernel with rtl8180/rtl8185
cards. Ignore the skb priority for those cards, they only have one
tx queue.
Cc: stable(a)vger.kernel.org
Reported-by: pa(a)panix.com
Tested-by: pa(a)panix.com
Signed-off-by: Alexander Wetzel <alexander(a)wetzel-home.de>
---
Pierre Asselin (pa(a)panix.com) reported a kernel crash in the Gentoo forum:
https://forums.gentoo.org/viewtopic-t-1147832-postdays-0-postorder-asc-star…
He also confirmed that this patch fixes the issue.
In summary this happened:
After updating wpa_supplicant from 2.9 to 2.10 the kernel crashed with a
"divide error: 0000" when connecting to an AP.
Control port tx now tries to use IEEE80211_AC_VO for the priority, which
wpa_supplicants starts to use in 2.10.
Since only the rtl8187se part of the driver supports QoS, the priority
of the skb is set to IEEE80211_AC_BE (2) by mac80211 for rtl8180/rtl8185
cards.
rtl8180 is then unconditionally reading out the priority and finally crashes on
drivers/net/wireless/realtek/rtl818x/rtl8180/dev.c line 544 without this
patch:
idx = (ring->idx + skb_queue_len(&ring->queue)) % ring->entries
"ring->entries" is zero for rtl8180/rtl8185 cards, tx_ring[2] never got
initialized.
drivers/net/wireless/realtek/rtl818x/rtl8180/dev.c | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/realtek/rtl818x/rtl8180/dev.c b/drivers/net/wireless/realtek/rtl818x/rtl8180/dev.c
index 2477e18c7cae..025619cd14e8 100644
--- a/drivers/net/wireless/realtek/rtl818x/rtl8180/dev.c
+++ b/drivers/net/wireless/realtek/rtl818x/rtl8180/dev.c
@@ -460,8 +460,10 @@ static void rtl8180_tx(struct ieee80211_hw *dev,
struct rtl8180_priv *priv = dev->priv;
struct rtl8180_tx_ring *ring;
struct rtl8180_tx_desc *entry;
+ unsigned int prio = 0;
unsigned long flags;
- unsigned int idx, prio, hw_prio;
+ unsigned int idx, hw_prio;
+
dma_addr_t mapping;
u32 tx_flags;
u8 rc_flags;
@@ -470,7 +472,9 @@ static void rtl8180_tx(struct ieee80211_hw *dev,
/* do arithmetic and then convert to le16 */
u16 frame_duration = 0;
- prio = skb_get_queue_mapping(skb);
+ /* rtl8180/rtl8185 only has one useable tx queue */
+ if (dev->queues > IEEE80211_AC_BK)
+ prio = skb_get_queue_mapping(skb);
ring = &priv->tx_ring[prio];
mapping = dma_map_single(&priv->pdev->dev, skb->data, skb->len,
--
2.35.1
--
My Dear,.
I represent a group of company based in Gulf Region and we are
currently seeking means of expanding and relocating our business
interest abroad in the following sectors: energy, real estate,
construction, stock,mining, or any other viable sector. We are ready
to fund any business that is capable of generating 5% (AROI) on Joint
Venture partnership bases.
We look forward to discussing this opportunity in detail with you.
Urgent khalid.loan1(a)outlook.com
Regards,
Khalid Al Rumaihi
Business Development Manager.
Mana ma, Bahrain.
CLEAR_FAULTS commands can apparently sometimes trigger catastrophic
power output glitches on the ahe-50dc, so block them from being sent
at all.
Signed-off-by: Zev Weiss <zev(a)bewilderbeest.net>
Cc: stable(a)vger.kernel.org
---
drivers/hwmon/pmbus/delta-ahe50dc-fan.c | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
diff --git a/drivers/hwmon/pmbus/delta-ahe50dc-fan.c b/drivers/hwmon/pmbus/delta-ahe50dc-fan.c
index 40dffd9c4cbf..f546f0c12497 100644
--- a/drivers/hwmon/pmbus/delta-ahe50dc-fan.c
+++ b/drivers/hwmon/pmbus/delta-ahe50dc-fan.c
@@ -14,6 +14,21 @@
#define AHE50DC_PMBUS_READ_TEMP4 0xd0
+static int ahe50dc_fan_write_byte(struct i2c_client *client, int page, u8 value)
+{
+ /*
+ * The CLEAR_FAULTS operation seems to sometimes (unpredictably, perhaps
+ * 5% of the time or so) trigger a problematic phenomenon in which the
+ * fan speeds surge momentarily and at least some (perhaps all?) of the
+ * system's power outputs experience a glitch.
+ *
+ * However, according to Delta it should be OK to simply not send any
+ * CLEAR_FAULTS commands (the device doesn't seem to be capable of
+ * reporting any faults anyway), so just blackhole them unconditionally.
+ */
+ return value == PMBUS_CLEAR_FAULTS ? -EOPNOTSUPP : -ENODATA;
+}
+
static int ahe50dc_fan_read_word_data(struct i2c_client *client, int page, int phase, int reg)
{
/* temp1 in (virtual) page 1 is remapped to mfr-specific temp4 */
@@ -68,6 +83,7 @@ static struct pmbus_driver_info ahe50dc_fan_info = {
PMBUS_HAVE_VIN | PMBUS_HAVE_FAN12 | PMBUS_HAVE_FAN34 |
PMBUS_HAVE_STATUS_FAN12 | PMBUS_HAVE_STATUS_FAN34 | PMBUS_PAGE_VIRTUAL,
.func[1] = PMBUS_HAVE_TEMP | PMBUS_PAGE_VIRTUAL,
+ .write_byte = ahe50dc_fan_write_byte,
.read_word_data = ahe50dc_fan_read_word_data,
};
--
2.36.0
Commit 4b5923249b8fa4 ("net: dsa: lantiq_gswip: Configure all remaining
GSWIP_MII_CFG bits") added all known bits in the GSWIP_MII_CFGp
register. It helped bring this register into a well-defined state so the
driver has to rely less on the bootloader to do things right.
Unfortunately it also sets the GSWIP_MII_CFG_RMII_CLK bit without any
possibility to configure it. Upon further testing it turns out that all
boards which are supported by the GSWIP driver in OpenWrt which use an
RMII PHY have a dedicated oscillator on the board which provides the
50MHz RMII reference clock.
Don't set the GSWIP_MII_CFG_RMII_CLK bit (but keep the code which always
clears it) to fix support for the Fritz!Box 7362 SL in OpenWrt. This is
a board with two Atheros AR8030 RMII PHYs. With the "RMII clock" bit set
the MAC also generates the RMII reference clock whose signal then
conflicts with the signal from the oscillator on the board. This results
in a constant cycle of the PHY detecting link up/down (and as a result
of that: the two ports using the AR8030 PHYs are not working).
At the time of writing this patch there's no known board where the MAC
(GSWIP) has to generate the RMII reference clock. If needed this can be
implemented in future by providing a device-tree flag so the
GSWIP_MII_CFG_RMII_CLK bit can be toggled per port.
Fixes: 4b5923249b8fa4 ("net: dsa: lantiq_gswip: Configure all remaining GSWIP_MII_CFG bits")
Cc: stable(a)vger.kernel.org
Tested-by: Jan Hoffmann <jan(a)3e8.eu>
Signed-off-by: Martin Blumenstingl <martin.blumenstingl(a)googlemail.com>
---
drivers/net/dsa/lantiq_gswip.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/net/dsa/lantiq_gswip.c b/drivers/net/dsa/lantiq_gswip.c
index a416240d001b..12c15da55664 100644
--- a/drivers/net/dsa/lantiq_gswip.c
+++ b/drivers/net/dsa/lantiq_gswip.c
@@ -1681,9 +1681,6 @@ static void gswip_phylink_mac_config(struct dsa_switch *ds, int port,
break;
case PHY_INTERFACE_MODE_RMII:
miicfg |= GSWIP_MII_CFG_MODE_RMIIM;
-
- /* Configure the RMII clock as output: */
- miicfg |= GSWIP_MII_CFG_RMII_CLK;
break;
case PHY_INTERFACE_MODE_RGMII:
case PHY_INTERFACE_MODE_RGMII_ID:
--
2.36.0
Fix incorrect usage of vli_cmp when calculating the value of res.x. For
signature verification to succeed, res.x must be the same as the r
component of the signature which is in the range of [1..n-1] with 'n'
being the order of the curve. Therefore, when res.x equals n calculate
res.x = res.x - n as well. Signature verification could have previously
unnecessarily failed in extremely rare cases.
Fixes: 4e6602916bc6 ("crypto: ecdsa - Add support for ECDSA signature verification")
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Stefan Berger <stefanb(a)linux.ibm.com>
---
crypto/ecdsa.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/crypto/ecdsa.c b/crypto/ecdsa.c
index b3a8a6b572ba..674ab9275366 100644
--- a/crypto/ecdsa.c
+++ b/crypto/ecdsa.c
@@ -120,8 +120,8 @@ static int _ecdsa_verify(struct ecc_ctx *ctx, const u64 *hash, const u64 *r, con
/* res = u1*G + u2 * pub_key */
ecc_point_mult_shamir(&res, u1, &curve->g, u2, &ctx->pub_key, curve);
- /* res.x = res.x mod n (if res.x > order) */
- if (unlikely(vli_cmp(res.x, curve->n, ndigits) == 1))
+ /* res.x = res.x mod n (if res.x >= order) */
+ if (unlikely(vli_cmp(res.x, curve->n, ndigits) >= 0))
/* faster alternative for NIST p384, p256 & p192 */
vli_sub(res.x, res.x, curve->n, ndigits);
--
2.34.1
As Yanming reported in bugzilla:
https://bugzilla.kernel.org/show_bug.cgi?id=215897
I have encountered a bug in F2FS file system in kernel v5.17.
The kernel should enable CONFIG_KASAN=y and CONFIG_KASAN_INLINE=y. You can
reproduce the bug by running the following commands:
The kernel message is shown below:
kernel BUG at fs/f2fs/f2fs.h:2511!
Call Trace:
f2fs_remove_inode_page+0x2a2/0x830
f2fs_evict_inode+0x9b7/0x1510
evict+0x282/0x4e0
do_unlinkat+0x33a/0x540
__x64_sys_unlinkat+0x8e/0xd0
do_syscall_64+0x3b/0x90
entry_SYSCALL_64_after_hwframe+0x44/0xae
The root cause is: .total_valid_block_count or .total_valid_node_count
could fuzzed to zero, then once dec_valid_node_count() was called, it
will cause BUG_ON(), this patch fixes to print warning info and set
SBI_NEED_FSCK into CP instead of panic.
Cc: stable(a)vger.kernel.org
Reported-by: Ming Yan <yanming(a)tju.edu.cn>
Signed-off-by: Chao Yu <chao.yu(a)oppo.com>
---
fs/f2fs/f2fs.h | 14 ++++++++++----
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
index f3eda4f13646..56adc3b68e14 100644
--- a/fs/f2fs/f2fs.h
+++ b/fs/f2fs/f2fs.h
@@ -2605,11 +2605,17 @@ static inline void dec_valid_node_count(struct f2fs_sb_info *sbi,
{
spin_lock(&sbi->stat_lock);
- f2fs_bug_on(sbi, !sbi->total_valid_block_count);
- f2fs_bug_on(sbi, !sbi->total_valid_node_count);
+ if (unlikely(!sbi->total_valid_block_count ||
+ !sbi->total_valid_node_count)) {
+ f2fs_warn(sbi, "dec_valid_node_count: inconsistent block counts, total_valid_block:%u, total_valid_node:%u",
+ sbi->total_valid_block_count,
+ sbi->total_valid_node_count);
+ set_sbi_flag(sbi, SBI_NEED_FSCK);
+ } else {
+ sbi->total_valid_block_count--;
+ sbi->total_valid_node_count--;
+ }
- sbi->total_valid_node_count--;
- sbi->total_valid_block_count--;
if (sbi->reserved_blocks &&
sbi->current_reserved_blocks < sbi->reserved_blocks)
sbi->current_reserved_blocks++;
--
2.32.0
From: Bean Huo <beanhuo(a)micron.com>
Occasionally, user-land applications initiate longer timeout values for certain commands
through ioctl() system call. But so far we are still using a fixed timeout of 10 seconds
in mmc_poll_for_busy() on the ioctl() path, even if a custom timeout is specified in the
userspace application. This patch allows custom timeout values to override this default
timeout values on the ioctl path.
Cc: stable <stable(a)vger.kernel.org>
Signed-off-by: Bean Huo <beanhuo(a)micron.com>
---
drivers/mmc/core/block.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/mmc/core/block.c b/drivers/mmc/core/block.c
index b35e7a95798b..6cb701aa1abc 100644
--- a/drivers/mmc/core/block.c
+++ b/drivers/mmc/core/block.c
@@ -609,11 +609,11 @@ static int __mmc_blk_ioctl_cmd(struct mmc_card *card, struct mmc_blk_data *md,
if (idata->rpmb || (cmd.flags & MMC_RSP_R1B) == MMC_RSP_R1B) {
/*
- * Ensure RPMB/R1B command has completed by polling CMD13
- * "Send Status".
+ * Ensure RPMB/R1B command has completed by polling CMD13 "Send Status". Here we
+ * allow to override the default timeout value if a custom timeout is specified.
*/
- err = mmc_poll_for_busy(card, MMC_BLK_TIMEOUT_MS, false,
- MMC_BUSY_IO);
+ err = mmc_poll_for_busy(card, idata->ic.cmd_timeout_ms ? : MMC_BLK_TIMEOUT_MS,
+ false, MMC_BUSY_IO);
}
return err;
--
2.34.1
This reverts commit 1ff5359afa5ec0dd09fe76183dc4fa24b50e4125.
The upstream commit c3efcedd272a ("net: micrel: fix KS8851_MLL Kconfig")
depends on e5f31552674e ("ethernet: fix PTP_1588_CLOCK dependencies")
which is not part of Linux 5.10.y . Revert the aforementioned commit to
prevent breakage in 5.10.y .
Signed-off-by: Marek Vasut <marex(a)denx.de>
Cc: David S. Miller <davem(a)davemloft.net>
Cc: Jakub Kicinski <kuba(a)kernel.org>
Cc: Paolo Abeni <pabeni(a)redhat.com>
Cc: Randy Dunlap <rdunlap(a)infradead.org>
Cc: Sasha Levin <sashal(a)kernel.org>
Cc: <stable(a)vger.kernel.org> # 5.10.x
---
drivers/net/ethernet/micrel/Kconfig | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/net/ethernet/micrel/Kconfig b/drivers/net/ethernet/micrel/Kconfig
index 9ceb7e1fb169..42bc014136fe 100644
--- a/drivers/net/ethernet/micrel/Kconfig
+++ b/drivers/net/ethernet/micrel/Kconfig
@@ -37,7 +37,6 @@ config KS8851
config KS8851_MLL
tristate "Micrel KS8851 MLL"
depends on HAS_IOMEM
- depends on PTP_1588_CLOCK_OPTIONAL
select MII
select CRC32
select EEPROM_93CX6
--
2.35.1
We received a report[1] of kernel crashes when Cilium is used in XDP
mode with virtio_net after updating to newer kernels. After
investigating the reason it turned out that when using mergeable bufs
with an XDP program which adjusts xdp.data or xdp.data_meta page_to_buf()
calculates the build_skb address wrong because the offset can become less
than the headroom so it gets the address of the previous page (-X bytes
depending on how lower offset is):
page_to_skb: page addr ffff9eb2923e2000 buf ffff9eb2923e1ffc offset 252 headroom 256
This is a pr_err() I added in the beginning of page_to_skb which clearly
shows offset that is less than headroom by adding 4 bytes of metadata
via an xdp prog. The calculations done are:
receive_mergeable():
headroom = VIRTIO_XDP_HEADROOM; // VIRTIO_XDP_HEADROOM == 256 bytes
offset = xdp.data - page_address(xdp_page) -
vi->hdr_len - metasize;
page_to_skb():
p = page_address(page) + offset;
...
buf = p - headroom;
Now buf goes -4 bytes from the page's starting address as can be seen
above which is set as skb->head and skb->data by build_skb later. Depending
on what's done with the skb (when it's freed most often) we get all kinds
of corruptions and BUG_ON() triggers in mm[2]. We have to recalculate
the new headroom after the xdp program has run, similar to how offset
and len are recalculated. Headroom is directly related to
data_hard_start, data and data_meta, so we use them to get the new size.
The result is correct (similar pr_err() in page_to_skb, one case of
xdp_page and one case of virtnet buf):
a) Case with 4 bytes of metadata
[ 115.949641] page_to_skb: page addr ffff8b4dcfad2000 offset 252 headroom 252
[ 121.084105] page_to_skb: page addr ffff8b4dcf018000 offset 20732 headroom 252
b) Case of pushing data +32 bytes
[ 153.181401] page_to_skb: page addr ffff8b4dd0c4d000 offset 288 headroom 288
[ 158.480421] page_to_skb: page addr ffff8b4dd00b0000 offset 24864 headroom 288
c) Case of pushing data -33 bytes
[ 835.906830] page_to_skb: page addr ffff8b4dd3270000 offset 223 headroom 223
[ 840.839910] page_to_skb: page addr ffff8b4dcdd68000 offset 12511 headroom 223
Offset and headroom are equal because offset points to the start of
reserved bytes for the virtio_net header which are at buf start +
headroom, while data points at buf start + vnet hdr size + headroom so
when data or data_meta are adjusted by the xdp prog both the headroom size
and the offset change equally. We can use data_hard_start to compute the
new headroom after the xdp prog (linearized / page start case, the
virtnet buf case is similar just with bigger base offset):
xdp.data_hard_start = page_address + vnet_hdr
xdp.data = page_address + vnet_hdr + headroom
new headroom after xdp prog = xdp.data - xdp.data_hard_start - metasize
An example reproducer xdp prog[3] is below.
[1] https://github.com/cilium/cilium/issues/19453
[2] Two of the many traces:
[ 40.437400] BUG: Bad page state in process swapper/0 pfn:14940
[ 40.916726] BUG: Bad page state in process systemd-resolve pfn:053b7
[ 41.300891] kernel BUG at include/linux/mm.h:720!
[ 41.301801] invalid opcode: 0000 [#1] PREEMPT SMP NOPTI
[ 41.302784] CPU: 1 PID: 1181 Comm: kubelet Kdump: loaded Tainted: G B W 5.18.0-rc1+ #37
[ 41.304458] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1.fc35 04/01/2014
[ 41.306018] RIP: 0010:page_frag_free+0x79/0xe0
[ 41.306836] Code: 00 00 75 ea 48 8b 07 a9 00 00 01 00 74 e0 48 8b 47 48 48 8d 50 ff a8 01 48 0f 45 fa eb d0 48 c7 c6 18 b8 30 a6 e8 d7 f8 fc ff <0f> 0b 48 8d 78 ff eb bc 48 8b 07 a9 00 00 01 00 74 3a 66 90 0f b6
[ 41.310235] RSP: 0018:ffffac05c2a6bc78 EFLAGS: 00010292
[ 41.311201] RAX: 000000000000003e RBX: 0000000000000000 RCX: 0000000000000000
[ 41.312502] RDX: 0000000000000001 RSI: ffffffffa6423004 RDI: 00000000ffffffff
[ 41.313794] RBP: ffff993c98823600 R08: 0000000000000000 R09: 00000000ffffdfff
[ 41.315089] R10: ffffac05c2a6ba68 R11: ffffffffa698ca28 R12: ffff993c98823600
[ 41.316398] R13: ffff993c86311ebc R14: 0000000000000000 R15: 000000000000005c
[ 41.317700] FS: 00007fe13fc56740(0000) GS:ffff993cdd900000(0000) knlGS:0000000000000000
[ 41.319150] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 41.320152] CR2: 000000c00008a000 CR3: 0000000014908000 CR4: 0000000000350ee0
[ 41.321387] Call Trace:
[ 41.321819] <TASK>
[ 41.322193] skb_release_data+0x13f/0x1c0
[ 41.322902] __kfree_skb+0x20/0x30
[ 41.343870] tcp_recvmsg_locked+0x671/0x880
[ 41.363764] tcp_recvmsg+0x5e/0x1c0
[ 41.384102] inet_recvmsg+0x42/0x100
[ 41.406783] ? sock_recvmsg+0x1d/0x70
[ 41.428201] sock_read_iter+0x84/0xd0
[ 41.445592] ? 0xffffffffa3000000
[ 41.462442] new_sync_read+0x148/0x160
[ 41.479314] ? 0xffffffffa3000000
[ 41.496937] vfs_read+0x138/0x190
[ 41.517198] ksys_read+0x87/0xc0
[ 41.535336] do_syscall_64+0x3b/0x90
[ 41.551637] entry_SYSCALL_64_after_hwframe+0x44/0xae
[ 41.568050] RIP: 0033:0x48765b
[ 41.583955] Code: e8 4a 35 fe ff eb 88 cc cc cc cc cc cc cc cc e8 fb 7a fe ff 48 8b 7c 24 10 48 8b 74 24 18 48 8b 54 24 20 48 8b 44 24 08 0f 05 <48> 3d 01 f0 ff ff 76 20 48 c7 44 24 28 ff ff ff ff 48 c7 44 24 30
[ 41.632818] RSP: 002b:000000c000a2f5b8 EFLAGS: 00000212 ORIG_RAX: 0000000000000000
[ 41.664588] RAX: ffffffffffffffda RBX: 000000c000062000 RCX: 000000000048765b
[ 41.681205] RDX: 0000000000005e54 RSI: 000000c000e66000 RDI: 0000000000000016
[ 41.697164] RBP: 000000c000a2f608 R08: 0000000000000001 R09: 00000000000001b4
[ 41.713034] R10: 00000000000000b6 R11: 0000000000000212 R12: 00000000000000e9
[ 41.728755] R13: 0000000000000001 R14: 000000c000a92000 R15: ffffffffffffffff
[ 41.744254] </TASK>
[ 41.758585] Modules linked in: br_netfilter bridge veth netconsole virtio_net
and
[ 33.524802] BUG: Bad page state in process systemd-network pfn:11e60
[ 33.528617] page ffffe05dc0147b00 ffffe05dc04e7a00 ffff8ae9851ec000 (1) len 82 offset 252 metasize 4 hroom 0 hdr_len 12 data ffff8ae9851ec10c data_meta ffff8ae9851ec108 data_end ffff8ae9851ec14e
[ 33.529764] page:000000003792b5ba refcount:0 mapcount:-512 mapping:0000000000000000 index:0x0 pfn:0x11e60
[ 33.532463] flags: 0xfffffc0000000(node=0|zone=1|lastcpupid=0x1fffff)
[ 33.532468] raw: 000fffffc0000000 0000000000000000 dead000000000122 0000000000000000
[ 33.532470] raw: 0000000000000000 0000000000000000 00000000fffffdff 0000000000000000
[ 33.532471] page dumped because: nonzero mapcount
[ 33.532472] Modules linked in: br_netfilter bridge veth netconsole virtio_net
[ 33.532479] CPU: 0 PID: 791 Comm: systemd-network Kdump: loaded Not tainted 5.18.0-rc1+ #37
[ 33.532482] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1.fc35 04/01/2014
[ 33.532484] Call Trace:
[ 33.532496] <TASK>
[ 33.532500] dump_stack_lvl+0x45/0x5a
[ 33.532506] bad_page.cold+0x63/0x94
[ 33.532510] free_pcp_prepare+0x290/0x420
[ 33.532515] free_unref_page+0x1b/0x100
[ 33.532518] skb_release_data+0x13f/0x1c0
[ 33.532524] kfree_skb_reason+0x3e/0xc0
[ 33.532527] ip6_mc_input+0x23c/0x2b0
[ 33.532531] ip6_sublist_rcv_finish+0x83/0x90
[ 33.532534] ip6_sublist_rcv+0x22b/0x2b0
[3] XDP program to reproduce(xdp_pass.c):
#include <linux/bpf.h>
#include <bpf/bpf_helpers.h>
SEC("xdp_pass")
int xdp_pkt_pass(struct xdp_md *ctx)
{
bpf_xdp_adjust_head(ctx, -(int)32);
return XDP_PASS;
}
char _license[] SEC("license") = "GPL";
compile: clang -O2 -g -Wall -target bpf -c xdp_pass.c -o xdp_pass.o
load on virtio_net: ip link set enp1s0 xdpdrv obj xdp_pass.o sec xdp_pass
CC: stable(a)vger.kernel.org
CC: Jason Wang <jasowang(a)redhat.com>
CC: Xuan Zhuo <xuanzhuo(a)linux.alibaba.com>
CC: Daniel Borkmann <daniel(a)iogearbox.net>
CC: "Michael S. Tsirkin" <mst(a)redhat.com>
CC: virtualization(a)lists.linux-foundation.org
Fixes: 8fb7da9e9907 ("virtio_net: get build_skb() buf by data ptr")
Signed-off-by: Nikolay Aleksandrov <razor(a)blackwall.org>
---
v3: Add a comment explaining why offset and headroom are equal,
no code changes
v2: Recalculate headroom based on data, data_hard_start and data_meta
drivers/net/virtio_net.c | 20 +++++++++++++++++++-
1 file changed, 19 insertions(+), 1 deletion(-)
diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index 87838cbe38cf..cbba9d2e8f32 100644
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -1005,6 +1005,24 @@ static struct sk_buff *receive_mergeable(struct net_device *dev,
* xdp.data_meta were adjusted
*/
len = xdp.data_end - xdp.data + vi->hdr_len + metasize;
+
+ /* recalculate headroom if xdp.data or xdp_data_meta
+ * were adjusted, note that offset should always point
+ * to the start of the reserved bytes for virtio_net
+ * header which are followed by xdp.data, that means
+ * that offset is equal to the headroom (when buf is
+ * starting at the beginning of the page, otherwise
+ * there is a base offset inside the page) but it's used
+ * with a different starting point (buf start) than
+ * xdp.data (buf start + vnet hdr size). If xdp.data or
+ * data_meta were adjusted by the xdp prog then the
+ * headroom size has changed and so has the offset, we
+ * can use data_hard_start, which points at buf start +
+ * vnet hdr size, to calculate the new headroom and use
+ * it later to compute buf start in page_to_skb()
+ */
+ headroom = xdp.data - xdp.data_hard_start - metasize;
+
/* We can only create skb based on xdp_page. */
if (unlikely(xdp_page != page)) {
rcu_read_unlock();
@@ -1012,7 +1030,7 @@ static struct sk_buff *receive_mergeable(struct net_device *dev,
head_skb = page_to_skb(vi, rq, xdp_page, offset,
len, PAGE_SIZE, false,
metasize,
- VIRTIO_XDP_HEADROOM);
+ headroom);
return head_skb;
}
break;
--
2.35.1
This is a note to let you know that I've just added the patch titled
usb: dwc3: gadget: Return proper request status
to my usb git tree which can be found at
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git
in the usb-linus branch.
The patch will show up in the next release of the linux-next tree
(usually sometime within the next 24 hours during the week.)
The patch will hopefully also be merged in Linus's tree for the
next -rc kernel release.
If you have any questions about this process, please let me know.
From c7428dbddcf4ea1919e1c8e15f715b94ca359268 Mon Sep 17 00:00:00 2001
From: Thinh Nguyen <Thinh.Nguyen(a)synopsys.com>
Date: Fri, 22 Apr 2022 17:36:28 -0700
Subject: usb: dwc3: gadget: Return proper request status
If the user sets the usb_request's no_interrupt, then there will be no
completion event for the request. Currently the driver incorrectly uses
the event status of a different request to report the status for a
request with no_interrupt. The dwc3 driver needs to check the TRB status
associated with the request when reporting its status.
Note: this is only applicable to missed_isoc TRB completion status, but
the other status are also listed for completeness/documentation.
Fixes: 6d8a019614f3 ("usb: dwc3: gadget: check for Missed Isoc from event status")
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Thinh Nguyen <Thinh.Nguyen(a)synopsys.com>
Link: https://lore.kernel.org/r/db2c80108286cfd108adb05bad52138b78d7c3a7.16506736…
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/usb/dwc3/gadget.c | 31 ++++++++++++++++++++++++++++++-
1 file changed, 30 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
index ab725d2262d6..0b9c2493844a 100644
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -3274,6 +3274,7 @@ static int dwc3_gadget_ep_cleanup_completed_request(struct dwc3_ep *dep,
const struct dwc3_event_depevt *event,
struct dwc3_request *req, int status)
{
+ int request_status;
int ret;
if (req->request.num_mapped_sgs)
@@ -3294,7 +3295,35 @@ static int dwc3_gadget_ep_cleanup_completed_request(struct dwc3_ep *dep,
req->needs_extra_trb = false;
}
- dwc3_gadget_giveback(dep, req, status);
+ /*
+ * The event status only reflects the status of the TRB with IOC set.
+ * For the requests that don't set interrupt on completion, the driver
+ * needs to check and return the status of the completed TRBs associated
+ * with the request. Use the status of the last TRB of the request.
+ */
+ if (req->request.no_interrupt) {
+ struct dwc3_trb *trb;
+
+ trb = dwc3_ep_prev_trb(dep, dep->trb_dequeue);
+ switch (DWC3_TRB_SIZE_TRBSTS(trb->size)) {
+ case DWC3_TRBSTS_MISSED_ISOC:
+ /* Isoc endpoint only */
+ request_status = -EXDEV;
+ break;
+ case DWC3_TRB_STS_XFER_IN_PROG:
+ /* Applicable when End Transfer with ForceRM=0 */
+ case DWC3_TRBSTS_SETUP_PENDING:
+ /* Control endpoint only */
+ case DWC3_TRBSTS_OK:
+ default:
+ request_status = 0;
+ break;
+ }
+ } else {
+ request_status = status;
+ }
+
+ dwc3_gadget_giveback(dep, req, request_status);
out:
return ret;
--
2.36.0
--
Hello,
My name is Warren E. Buffett, an American business magnate, investor
and philanthropist. I am the most successful investor in the world. I
believe strongly in giving while living' I had one idea that never
changed in my mind ? That you should use your wealth to help people
and I have decided to give you $2,500,000.00 to randomly selected
individuals worldwide. You should count yourself as the lucky
individual. Kindly reply back so I know your email address is valid.
God bless you.
Mr. Warren E. Buffett
All creation paths except for O_TMPFILE handle umask in the vfs directly
if the filesystem doesn't support or enable POSIX ACLs. If the filesystem
does then umask handling is deferred until posix_acl_create().
Because, O_TMPFILE misses umask handling in the vfs it will not honor
umask settings. Fix this by adding the missing umask handling.
Fixes: 60545d0d4610 ("[O_TMPFILE] it's still short a few helpers, but infrastructure should be OK now...")
Cc: <stable(a)vger.kernel.org> # 4.19+
Reported-by: Christian Brauner (Microsoft) <brauner(a)kernel.org>
Acked-by: Christian Brauner (Microsoft) <brauner(a)kernel.org>
Reviewed-by: Darrick J. Wong <djwong(a)kernel.org>
Signed-off-by: Yang Xu <xuyang2018.jy(a)fujitsu.com>
---
fs/namei.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/fs/namei.c b/fs/namei.c
index 509657fdf4f5..73646e28fae0 100644
--- a/fs/namei.c
+++ b/fs/namei.c
@@ -3521,6 +3521,8 @@ struct dentry *vfs_tmpfile(struct user_namespace *mnt_userns,
child = d_alloc(dentry, &slash_name);
if (unlikely(!child))
goto out_err;
+ if (!IS_POSIXACL(dir))
+ mode &= ~current_umask();
error = dir->i_op->tmpfile(mnt_userns, dir, child, mode);
if (error)
goto out_err;
--
2.27.0
In qla2x00_probe_one() -> qla2x00_mem_alloc(), fields in variable ha
is allocated and initialized. Fields ha->loop_id_map and ha->npiv_info
are also allocated in this function, but are freed when the function
encounters an error. Function qla2x00_probe_one() then calls
qla2x00_mem_free() to handle the error, which frees the corresponding
fields again. This results in double free of ha->loop_id_map and ha->
npiv_info, since the fields are not NULLed after freed the first time.
Fix this by storing NULL to the corresponding fields inside
qla2x00_mem_alloc() error handlers.
Fixes: e4e3a2ce9556 ("scsi: qla2xxx: Add ability to autodetect SFP type")
Fixes: b64b0e8fd964 ("[SCSI] qla2xxx: Pass in optional extended-initialization control block.")
Cc: stable(a)vger.kernel.org
Signed-off-by: Keita Suzuki <keitasuzuki.park(a)sslab.ics.keio.ac.jp>
---
drivers/scsi/qla2xxx/qla_os.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/scsi/qla2xxx/qla_os.c b/drivers/scsi/qla2xxx/qla_os.c
index 762229d495a8..a0b40578dbc8 100644
--- a/drivers/scsi/qla2xxx/qla_os.c
+++ b/drivers/scsi/qla2xxx/qla_os.c
@@ -4396,6 +4396,7 @@ qla2x00_mem_alloc(struct qla_hw_data *ha, uint16_t req_len, uint16_t rsp_len,
ha->sfp_data, ha->sfp_data_dma);
fail_sfp_data:
kfree(ha->loop_id_map);
+ ha->loop_id_map = NULL;
fail_loop_id_map:
dma_pool_free(ha->s_dma_pool, ha->async_pd, ha->async_pd_dma);
fail_async_pd:
@@ -4404,6 +4405,7 @@ qla2x00_mem_alloc(struct qla_hw_data *ha, uint16_t req_len, uint16_t rsp_len,
dma_pool_free(ha->s_dma_pool, ha->ex_init_cb, ha->ex_init_cb_dma);
fail_ex_init_cb:
kfree(ha->npiv_info);
+ ha->npiv_info = NULL;
fail_npiv_info:
dma_free_coherent(&ha->pdev->dev, ((*rsp)->length + 1) *
sizeof(response_t), (*rsp)->ring, (*rsp)->dma);
--
2.25.1