A TX timeout on a qede NIC that has VXLAN/GENEVE tunnel ports
configured wedges the rtnetlink control plane of the whole machine:
NETDEV WATCHDOG: ens6f1 (qede): transmit queue 2 timed out 10226 ms
[qede_tx_timeout:586(ens6f1)]TX timeout on queue 2!
[qede_recovery_handler:2665(ens6f0)]Starting a recovery process
The recovery path deadlocks on the driver's own mutex:
qede_sp_task
rtnl_lock()
mutex_lock(&edev->qede_lock) <- taken
qede_recovery_handler
qede_load
udp_tunnel_nic_reset_ntf
__udp_tunnel_nic_device_sync
info->sync_table == qede_udp_tunnel_sync
mutex_lock(&edev->qede_lock) <- same task: deadlock
The mutex is not recursive, so the kworker blocks on itself with
rtnl_lock held, and neither lock is ever released. Every task that
calls rtnl_lock() afterwards (ip, ovs-vswitchd, lldpad, IPv6
addrconf, sshd) blocks forever while the node still answers ping.
In a vmcore from an affected production node rtnl_mutex.owner
decodes to the very kworker blocked at the innermost mutex_lock()
above.
Re-sync the tunnel ports from qede_sp_task() after the internal lock
is dropped, still under rtnl_lock as the udp_tunnel API requires.
This mirrors qede_open(), which calls udp_tunnel_nic_reset_ntf()
under rtnl without the internal lock.
qede_recovery_handler() now returns whether it has successfully
reloaded an open device, and the caller re-syncs the ports only in
that case. This keeps the old gating exactly: a device that was down
or a failed recovery returns false, as those paths never reached the
udp_tunnel_nic_reset_ntf() call before either.
This was the only user of the qede_lock()/qede_unlock() helpers, so
remove them.
Fixes: 8cd160a294 ("qede: convert to new udp_tunnel_nic infra")
Signed-off-by: Denis V. Lunev <den@openvz.org>
CC: Andrew Lunn <andrew+netdev@lunn.ch>
CC: "David S. Miller" <davem@davemloft.net>
CC: Eric Dumazet <edumazet@google.com>
CC: Jakub Kicinski <kuba@kernel.org>
CC: Paolo Abeni <pabeni@redhat.com>
Reviewed-by: Jacob Keller <jacob.e.keller@intel.com>
Link: https://patch.msgid.link/20260726104311.1782900-1-den@openvz.org
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
-----BEGIN PGP SIGNATURE-----
iIkEABYKADEWIQSl+MghEFFAdY3pYJLMOmT6rpmt0gUCamnRyhMcbWtsQHBlbmd1
dHJvbml4LmRlAAoJEMw6ZPquma3SS00A/Rpm6GVkF0ievxaEWz5no+Vojn2U/S7K
3ix+pFFfrnyTAP9CfWhg8aIkLOF19RXhKRRLDIm5vI8qKCqrqBkSZszJCw==
=Qoox
-----END PGP SIGNATURE-----
Merge tag 'linux-can-fixes-for-7.2-20260729' of git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can
Marc Kleine-Budde says:
====================
pull-request: can 2026-07-29
this is a pull request of 20 patches for net/main.
The first 2 patches fix problems in the CAN J1939 protocol and are by
Tetsuo Handa and Oleksij Rempel.
The next 2 patches fix problems in the CAN ISOTP protocol and are by
Oliver Hartkopp and Minhong He.
Avi Weiss contributes contributed 4 fixes for the ctucanfd, Pengpeng
Hou's patch adds a missing MODULE_DEVICE_TABLE.
The patches for the peak_usb driver are contributed by James Gao,
Maoyi Xie, Maoyi Xie and add sanity checks for the USB bulk data
parsing and fix a double free.
2 fixes for the kvaser_usb driver are provided by Abdun Nihaal and
Pengpeng Hou, a mem leak is fixed and sanity checks for the USB bulk
data parsing.
Tu Nguyen's patch for the rcar_canfd driver fixes the initializing
flow.
Pengpeng Hou contributes a patch for the softing driver to validate
the firmware record spans.
Lucas Martins Alves's patch for the c_can driver keeps the controller
in init mode until configuration is complete.
A patch by my add missing URB resubmission on skb allocation failure
to the gs_usb driver.
Guangshuo Li's patch for the etas_es58x driver fixes a RX buffer leak.
The last patch is by Pengpeng Hou and adds sanity checks to the USB
bulk data parsing of the ems_usb driver.
linux-can-fixes-for-7.2-20260729
* tag 'linux-can-fixes-for-7.2-20260729' of git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can:
can: ems_usb: validate CPC message lengths
can: etas_es58x: es58x_read_bulk_callback(): fix RX buffer leak on URB resubmit failure
can: gs_usb: gs_usb_receive_bulk_callback(): resubmit URB on skb allocation failure
can: c_can: c_can_chip_config(): keep controller in init mode until bittiming is configured
can: softing: fw_parse(): validate firmware record spans
can: rcar_canfd: change the initializing flow for clocks and resets
can: kvaser_usb_leaf: kvaser_usb_leaf_wait_cmd(): validate received command extents
can: kvaser_usb: kvaser_usb_hydra_get_busparams(): fix memory leak in kvaser_usb_hydra_get_busparams()
can: peak_usb: validate uCAN receive record lengths
can: peak_usb: peak_usb_start(): fix double free of transfer buffer on URB submit error
can: peak_usb: add bounds check for USB channel index
can: ctucanfd: add missing MODULE_DEVICE_TABLE()
can: ctucanfd: use self-test mode for PRESUME_ACK
can: ctucanfd: handle bus error interrupts
can: ctucanfd: mark error-active controller status valid
can: ctucanfd: unmap BAR0 using base address
can: isotp: check register_netdevice_notifier() error in module init
can: isotp: fix timer drain order, wakeup handling and tx_gen ordering
can: j1939: transport: j1939_session_fresh_new(): initialize receive buffer
can: j1939: use netdevice_tracker for j1939_{priv,session,ecu} tracking
====================
Link: https://patch.msgid.link/20260729102802.505168-1-mkl@pengutronix.de
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Convert acp-pci to the pcim-managed PCI life-cycle. Replace
pci_enable_device() with pcim_enable_device() and fold the
open-coded pci_request_regions() + devm_ioremap() pair into a single
pcim_iomap_region() call for BAR0, which reserves and iomaps the
register window.
This lets the driver drop the manual pci_release_regions() and
pci_disable_device() calls from the probe error path; pcim releases
the device and region automatically on detach or probe failure. The
error check moves from a NULL test to IS_ERR(), since pcim_iomap_region()
returns an IOMEM_ERR_PTR on failure.
The child platform devices only use devm_ioremap() on their sub-range
of BAR0 (no request_mem_region), so reserving the full BAR0 here does
not conflict with them.
Assisted-by: opencode:hy3-free
Signed-off-by: Rosen Penev <rosenp@gmail.com>
Link: https://patch.msgid.link/20260720001054.1439409-1-rosenp@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
A large amount of memory may be allocated for these magazines on
machines with a lot of IOMMU groups and CPU cores. Not all may be used
as some devices may be unused or be bound to drivers that do not use the
DMA-API. Furthermore, some drivers may not use all levels or CPUs.
Move the initialization of the loaded and prev magazines for each CPU on
the first attempt to try to insert a freed IOVA to them.
Signed-off-by: Logan Odell <loganodell@google.com>
Signed-off-by: Michal Clapinski <mclapinski@google.com>
Reviewed-by: Robin Murphy <robin.murphy@arm.com>
Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
iommu_call_iopf_notifier() looks up the requester with
pci_get_domain_bus_and_slot(), which returns a PCI device with its
reference count incremented.
Neither the successful iommu_report_device_fault() path nor the abort
path drops that reference, so every handled PPR request leaks a PCI
device reference.
This is the same ownership rule that was fixed for the old iommu_v2
ppr_notifier() path by commit 6cf0981c22 ("iommu/amd: Fix pci device
refcount leak in ppr_notifier()"), but iommu_call_iopf_notifier() was
added later as a separate PPR/IOPF notifier path.
Drop the PCI device reference after handling the PPR entry.
Fixes: 978d626b8f ("iommu/amd: Add IO page fault notifier handler")
Cc: stable@vger.kernel.org
Assisted-by: Qoder:Qwen-3.8-MAX-Preview
Signed-off-by: Shuai Xue <xueshuai@linux.alibaba.com>
Reviewed-by: Vasant Hegde <vasant.hegde@amd.com>
Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
Convert fsl_soc_dma_probe() to managed APIs. Replace the open-coded
of_address_to_resource()/of_iomap() of the DMA channel registers with
devm_platform_ioremap_resource(), and irq_of_parse_and_map() with
platform_get_irq() (which returns a negative errno instead of 0).
Switch the allocation to devm_kzalloc() and register the component via
the devm variant, dropping the now-unneeded error-path cleanup and the
manual fsl_soc_dma_remove().
The SSI node's register resource is still read via of_address_to_resource()
to compute the SSI FIFO physical addresses (dma->ssi_stx_phys /
ssi_srx_phys); only the DMA controller window is mapped.
The DMA controller register window is owned solely by this driver, so the
new region request from devm_platform_ioremap_resource() cannot conflict
with another claimant, and it is mapped exactly once (no double mapping).
The local channel pointer is declared as void __iomem * so the
devm_platform_ioremap_resource() result can be stored before assignment
to dma->channel.
No functional change; built for powerpc (allmodconfig + CONFIG_SND_SOC_FSL_DMA)
with LLVM=1 and sound/soc/fsl/fsl_dma.o compiles cleanly.
Assisted-by: opencode:hy3-free
Signed-off-by: Rosen Penev <rosenp@gmail.com>
Link: https://patch.msgid.link/20260721225442.817787-1-rosenp@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
haibo.chen@oss.nxp.com <haibo.chen@oss.nxp.com> says:
Patch 1 introduce per-SoC clock rate limits for both SDR and DTR modes
by adding max_sdr_rate and max_dtr_rate to nxp_fspi_devtype_data.
Patch 2 enter stop mode before reconfiguring MCR0 and DLL to follow
FlexSPI reference manual initialization sequence
Patch 3 propagate clock reconfig failures in nxp_fspi_select_mem()
Link: https://patch.msgid.link/20260728-fspi-clock-v2-0-dbe786a4a6eb@nxp.com
nxp_fspi_select_mem() disables the FlexSPI clocks before calling
clk_set_rate() and re-enabling them. If clk_set_rate() or the clock
re-enable fails, the function returned early (as void) leaving both the
serial root clock and the register interface clock disabled.
As the function returned void, nxp_fspi_exec_op() had no way to know
about the failure and continued to access FlexSPI registers (LUT setup,
data transfer, AHB buffer invalidation). Accessing the controller
registers while its clock is gated off results in a synchronous external
abort.
Make nxp_fspi_select_mem() return an error code and have
nxp_fspi_exec_op() bail out on failure before any further register
access, including nxp_fspi_invalid().
Signed-off-by: Haibo Chen <haibo.chen@nxp.com>
Link: https://patch.msgid.link/20260728-fspi-clock-v2-3-dbe786a4a6eb@nxp.com
Signed-off-by: Mark Brown <broonie@kernel.org>
In nxp_fspi_select_mem() the RX sample clock source (MCR0[RXCLKSRC])
and the DLL control registers (DLLxCR) are reconfigured while the
FlexSPI module is still enabled. According to the FlexSPI reference
manual initialization sequence, MCR0 and the DLL control registers
should be programmed while the module is in stop mode, i.e. with
MCR0[MDIS] set to 1, and the module re-enabled (MCR0[MDIS] = 0)
afterwards.
Wrap the RX sample clock source selection and the DLL calibration/
override reconfiguration in a stop-mode window to align with the RM
and avoid reconfiguring timing-critical registers while the module is
active.
Signed-off-by: Haibo Chen <haibo.chen@nxp.com>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Link: https://patch.msgid.link/20260728-fspi-clock-v2-2-dbe786a4a6eb@nxp.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The commit f43579ef35 ("spi: spi-nxp-fspi: limit the clock rate for
different sample clock source selection") introduced a global 166MHz
cap for DTR mode (RXCLKSRC=3), based on the i.MX8MN datasheet timing
specification (Section 3.9.9, page 65).
After reviewing the FlexSPI timing parameters in the datasheets for all
supported SoCs, the following corrections and additions are needed:
1. SDR mode (RXCLKSRC=0) limits vary per SoC:
- i.MX8MN/MM/MP/95: 66MHz (IMX8MNCEC §3.9.9, IMX8MMCEC §3.9.10,
IMX8MPCEC, IMX95CEC Rev.8 §4.11.7)
- i.MX8QXP/QM/DXL/ULP: 60MHz (IMX8QXPCEC, IMX8QMCEC, IMX8DXLCEC,
IMX8ULPCEC §7.3.1 ND mode)
- LX2160A: 100MHz (LX2160ACEC FlexSPI timing parameters)
2. DTR mode (RXCLKSRC=3) limits vary per SoC:
- i.MX8MN/MM/MP/ULP: 166MHz
- i.MX8QXP/QM/DXL: 200MHz (same FlexSPI IP across this family)
- i.MX95: 200MHz (IMX95CEC §4.11.7.3.2.3 Table 106)
- LX2160A: DTR disabled (FSPI_QUIRK_DISABLE_DTR)
Update related platform data with correct speed limation according
to datasheet.
Fixes: f43579ef35 ("spi: spi-nxp-fspi: limit the clock rate for different sample clock source selection")
Signed-off-by: Haibo Chen <haibo.chen@nxp.com>
Link: https://patch.msgid.link/20260728-fspi-clock-v2-1-dbe786a4a6eb@nxp.com
Signed-off-by: Mark Brown <broonie@kernel.org>
This is a relatively large set of updates, the biggest batch of things
is Charles' fixes for the SDCA code which have been through a number of
iterations on the list and deal with a bunch of issues that have been
seen as we get more real world usage of SDCA. We also have the usual
device specific fix and quirk traffic that we tend to see, there's a
small pile of fixes for the tas2562 driver since I saw some bugs while
reviewing fixes sent by Haidar Lee but it's nothing too remarkable.
-----BEGIN PGP SIGNATURE-----
iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAmprOjEACgkQJNaLcl1U
h9AJeAgAhXykup5iskMuGCmHG3DxDZpHQOxcmvy6x4Afrn39yBVWD1CSkhSWRxHn
IT2GDOMQeHtZE0inMjQ66BX4EUsHg9jZTrvDPEjbscGrLNJdOsrfz1L+e1CTecyG
BgdDsfZFXrjDA/pSa3GtwvbH3YalGZLlmW4lk5PPWGwf7SjkqGj+Xea7kVu1uZrf
nnTC9Sso8siSE+dWapST+yRw6KYwhJndf33ruhjX1OkBfsEM/iDn/gpgJ550G/Xl
ffN12LIB8bDeEuW6svKvQ7OdGUIQds1OfhGngDaNKmMSEqUWGZP0VfxT1s6N8TTQ
5SWz3zAwXUpxkzUYXGQWgUOpkC3CUw==
=u8gI
-----END PGP SIGNATURE-----
Merge tag 'asoc-fix-v7.2-rc5' of https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus
ASoC: Fixes for v7.2
This is a relatively large set of updates, the biggest batch of things
is Charles' fixes for the SDCA code which have been through a number of
iterations on the list and deal with a bunch of issues that have been
seen as we get more real world usage of SDCA. We also have the usual
device specific fix and quirk traffic that we tend to see, there's a
small pile of fixes for the tas2562 driver since I saw some bugs while
reviewing fixes sent by Haidar Lee but it's nothing too remarkable.
Replace irq_of_parse_and_map() calls with platform_get_irq_optional()
to fetch both IRQs in the probe function. This is a more portable
approach that works with both DT and non-DT platforms and follows
modern platform API conventions.
The -EPROBE_DEFER case is handled properly so deferred probe works
as expected, and invalid IRQ numbers are normalized to 0.
Signed-off-by: Rosen Penev <rosenp@gmail.com>
Link: https://patch.msgid.link/20260727194714.11354-1-rosenp@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
While attaching a newly created meter attach_meter() function makes
the new meter visible to other CPUs but can still fail afterwards.
On failure, it detaches the meter back and returns an error.
However, this is an unexpected behavior for the ovs_meter_cmd_set()
that uses a plain kfree(meter) on attach failure without waiting for
RCU readers to stop using it, assuming it was never visible.
This is never a problem for ovs-vswitchd as it always creates meters
before creating any flows that use them. But the UAF can be triggered
with a custom application using uAPI:
BUG: KASAN: slab-use-after-free in ovs_meter_execute (net/openvswitch/meter.c:653)
Read of size 8 at addr ffff88810d152650 by task meter/2508
Call Trace:
ovs_meter_execute (net/openvswitch/meter.c:653)
do_execute_actions (net/openvswitch/actions.c:1407)
ovs_execute_actions (net/openvswitch/actions.c:1584)
ovs_packet_cmd_execute (net/openvswitch/datapath.c:703)
...
netlink_sendmsg (af_netlink.c:1900)
Allocated by task 2519:
__kasan_kmalloc (mm/kasan/common.c:398 mm/kasan/common.c:415)
ovs_meter_cmd_set (net/openvswitch/meter.c:422)
...
netlink_sendmsg (af_netlink.c:1900)
Freed by task 2519:
kfree (mm/slub.c:2705 mm/slub.c:6405 mm/slub.c:6720)
ovs_meter_cmd_set (net/openvswitch/meter.c:479)
...
netlink_sendmsg (af_netlink.c:1900)
Fix that by making sure attach_meter() doesn't make the meter visible
until all the checks are done and the function can't fail anymore.
This also makes sure the "hash" value is calculated after the potential
re-sizing of the table.
Reported by Trend Micro's Zero Day Initiative as ZDI-CAN-31642.
Fixes: c7c4c44c9a ("net: openvswitch: expand the meters supported number")
Cc: stable@vger.kernel.org
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
Reviewed-by: Eelco Chaudron <echaudro@redhat.com>
Link: https://patch.msgid.link/20260727121022.198461-1-i.maximets@ovn.org
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
ksz9131 is configured for local loopback in a similar fashion as the
ksz9031, with a need for full-duplex operation, but with some extra
steps to take as specified in section 4.13.1 :
1. Configure the following registers:
- MMD 1C, Register 15 = EEEE
- MMD 1C, Register 16 = EEEE
- MMD 1C, Register 18 = EEEE
- MMD 1C, Register 1B = EEEE
These 4 registers are marked as "Reserved" in the register map.
When setting loopback up without configuring these 4 registers, the PHY
appears to shut its RXC down, which can trigger failures on MACs that
require it, such as stmmac.
The datasheet does not specify to which state the registers must be
reset when disabling loopback, so let's restore them to their measured
initial values.
This was discovered when trying to use stmmac selftests on imx8mp with a
ksz9131 connected in RGMII.
Signed-off-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Link: https://patch.msgid.link/20260728075222.956780-1-maxime.chevallier@bootlin.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
The ipip fill_forward_path callback currently does not check for
configurations that cannot be offloaded to hardware:
- Collect metadata (flow-based) tunnels have no fixed destination
and rely on per-packet tunnel metadata, so the forward path
cannot be pre-computed.
- TOS inheritance (parms.iph.tos & 0x1) requires copying the outer
TOS from the inner packet at encapsulation time, which is not
known during forward path resolution.
Return -EOPNOTSUPP for both cases to fall back to the software
forwarding path.
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
Link: https://patch.msgid.link/20260725-ipip-fill-forward-path-fix-v1-1-bc69fd3127d5@kernel.org
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Sang-Heon Jeon says:
====================
net: remove conditional returns with no effect
This series removes conditional returns where both branches return
the same value, so the check has no effect. As suggested by Jakub, the
netdev patches of the treewide v1 series [1] are posted separately.
All patches are generated by the Coccinelle script, which you can
find in v1.
The patch grouping is unchanged from v1. If you would rather split,
merge or drop any of the patches, just let me know and I will address
it in the next version.
[1] https://lore.kernel.org/all/20260723184538.3888637-1-ekffu200098@gmail.com/
---
Sang-Heon Jeon (4):
dpll: zl3073x: remove conditional return with no effect
net: ethernet: remove conditional return with no effect
net: remove conditional return with no effect
net: intel: remove conditional return with no effect
drivers/dpll/zl3073x/dpll.c | 6 +-----
drivers/dpll/zl3073x/out.c | 8 ++------
drivers/net/ethernet/amazon/ena/ena_netdev.c | 6 +-----
drivers/net/ethernet/aquantia/atlantic/aq_macsec.c | 6 +-----
drivers/net/ethernet/freescale/dpaa2/dpaa2-switch.c | 6 +-----
drivers/net/ethernet/freescale/gianfar.c | 6 +-----
drivers/net/ethernet/intel/i40e/i40e_main.c | 8 +-------
drivers/net/ethernet/intel/igb/e1000_i210.c | 6 +-----
drivers/net/ethernet/intel/igc/igc_phy.c | 6 +-----
drivers/net/ethernet/qlogic/netxen/netxen_nic_hw.c | 7 +------
drivers/net/ethernet/qlogic/qlcnic/qlcnic_83xx_init.c | 6 +-----
drivers/net/ethernet/renesas/rtsn.c | 7 +------
drivers/net/phy/microchip_t1.c | 6 +-----
drivers/net/pse-pd/tps23881.c | 6 +-----
14 files changed, 15 insertions(+), 75 deletions(-)
====================
Link: https://patch.msgid.link/20260725150852.859188-1-ekffu200098@gmail.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Both branches of the check return the same value, so the check has
no effect. Remove it and return the value directly.
This is the result of running the Coccinelle script from
scripts/coccinelle/misc/cond_return_no_effect.cocci.
Signed-off-by: Sang-Heon Jeon <ekffu200098@gmail.com>
Reviewed-by: Marcin Szycik <marcin.szycik@linux.intel.com>
Link: https://patch.msgid.link/20260725150852.859188-5-ekffu200098@gmail.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Both branches of the check return the same value, so the check has
no effect. Remove it and return the value directly.
This is the result of running the Coccinelle script from
scripts/coccinelle/misc/cond_return_no_effect.cocci.
Signed-off-by: Sang-Heon Jeon <ekffu200098@gmail.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Link: https://patch.msgid.link/20260725150852.859188-4-ekffu200098@gmail.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Both branches of the check return the same value, so the check has
no effect. Remove it and return the value directly.
This is the result of running the Coccinelle script from
scripts/coccinelle/misc/cond_return_no_effect.cocci.
Signed-off-by: Sang-Heon Jeon <ekffu200098@gmail.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
Reviewed-by: Arthur Kiyanovski <akiyano@amazon.com>
Reviewed-by: Ioana Ciornei <ioana.ciornei@nxp.com> # for dpaa2-switch
Link: https://patch.msgid.link/20260725150852.859188-3-ekffu200098@gmail.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Both branches of the check return the same value, so the check has
no effect. Remove it and return the value directly.
This is the result of running the Coccinelle script from
scripts/coccinelle/misc/cond_return_no_effect.cocci.
Signed-off-by: Sang-Heon Jeon <ekffu200098@gmail.com>
Reviewed-by: Ivan Vecera <ivecera@redhat.com>
Link: https://patch.msgid.link/20260725150852.859188-2-ekffu200098@gmail.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Commit 14a8570564 ("sched/deadline: Use revised wakeup rule for
dl_server") applies the revised wakeup rule to any server, as a result
servers that are not running (dl_defer_running == 0) and start with a
deadline overflow get enqueued and can boost tasks as if they were
running, invalidating the defer rule and the documented state model.
Apply the revised wakeup rule only for deferrable servers that are
marked as running.
Fixes: 14a8570564 ("sched/deadline: Use revised wakeup rule for dl_server")
Signed-off-by: Gabriele Monaco <gmonaco@redhat.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Acked-by: Juri Lelli <juri.lelli@redhat.com>
Tested-by: Andrea Righi <arighi@nvidia.com>
Link: https://patch.msgid.link/20260522125833.264145-1-gmonaco@redhat.com
As noted in commit 85a2d4a890 ("x86,ibt: Use UDB instead of 0xEA") Jcc should
be assumed not-taken, however the normal kCFI (ABI) emits the following sequence:
movl $(-hash), %r10d
addl -15(%r11), %r10d
je 1f
ud2
1: cs call __x86_indirect_thunk_r11
(when used in conjunction with -mretpoline-external-thunk).
Notably, the Jcc here is always taken, resulting in lower throughput than would
be ideal. Replace it with the following sequence on boot:
movl $(-hash), %r10d
addl -15(%r11), %r10d
jne . + 3
test $0xd6, %al
cs call __x86_indirect_thunk_r11
This jumps to the UDB instruction used as an immediate byte in the test
instruction. The test instruction will clobber eflags, but that is immaterial,
eflags is already changed by the preceding addl.
Intel recommends the FineIBT sequence on platforms that support IBT; older
platforms are still widely used and would benefit from this.
An earlier PoC was benchmarked by Scott:
Indirect branch miss rate (br_misp_retired.indirect:k / br_inst_retired.indirect:k)
BHI_DIS_S=1
Benchmark Baseline IBT kCFI kCFI-opt
-----------------------------------------------------------------------------
iperf3 UDP 0.103764 0.103180 0.104311 0.102945
hackbench 0.000885 0.000876 0.001996 0.000826
lmbench syscall 0.005089 0.004486 0.016990 0.005852
lmbench fork+exit 0.018454 0.019176 0.031085 0.015153
lmbench fork+exec 0.017147 0.021613 0.029129 0.016337
redis 0.032220 0.032655 0.045540 0.027946
nginx+wrk 0.109033 0.112765 0.132557 0.102417
fio randread 0.009704 0.009620 0.008548 0.000962
fio seqwrite 0.006927 0.006707 0.019372 0.004590
kbuild 0.056748 0.057324 0.064640 0.048136
BHI_DIS_S=0
Benchmark Baseline IBT kCFI kCFI-opt
-----------------------------------------------------------------------------
iperf3 UDP 0.000077 0.000106 0.000186 0.000073
hackbench 0.000123 0.000132 0.000367 0.000097
lmbench syscall 0.023259 0.018319 0.040903 0.012772
lmbench fork+exit 0.011494 0.011887 0.029079 0.016415
lmbench fork+exec 0.037782 0.038994 0.055378 0.026381
redis 0.002481 0.003152 0.017073 0.000184
nginx+wrk 0.015478 0.016266 0.033637 0.000268
fio randread 0.009836 0.007949 0.007096 0.000143
fio seqwrite 0.014587 0.014165 0.041792 0.002157
kbuild 0.055774 0.055249 0.062590 0.046546
Suggested-by: Scott D Constable <scott.d.constable@intel.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Acked-by: Borislav Petkov (AMD) <bp@alien8.de>
Tested-by: Nathan Chancellor <nathan@kernel.org>
Link: https://patch.msgid.link/20260612071506.GQ187714%40noisy.programming.kicks-ass.net
remove_spares() and remove_and_add_spares() modify the array's rdev
configuration. These operations are only safe after the array has been
suspended.
md_start_sync() checks whether spare configuration changes are needed
before taking reconfig_mutex. However, the rdev state can change before
the mutex is acquired, so the initial check can become stale. In that
case, md_choose_sync_action() may remove or replace rdevs while normal
I/O is still accessing them.
The race can occur as follows:
raid10d Worker Normal IO
____________ _______________________ ______________________
raid10_write_request()
wait_blocked_dev()
set Blocked
set Faulty
Skip Faulty rdev
rrdev->nr_pending++
.repl_bio = bio
removeable_rdev = false .
array not suspended .
lock mddev goto err_handle
lock mddev (wait)
.
update sb .
clear Blocked .
.
unlock mddev .
lock mddev (acquires)
remove_spares()
removeable_rdev = true
raid10_remove_disk()
rdev = replacement
replacement = NULL
rdev_dec_pending(NULL)
unlock mddev (NULL)->nr_pending--
In this case, rdev_dec_pending() is called with a NULL pointer,
resulting in a NULL pointer dereference when attempting to decrement
nr_pending.
Fix this by suspending the array when spare configuration changes are
needed, including for non-read-write arrays, and checking again after
taking reconfig_mutex. If the array was not already suspended and a
change is now needed, release the mutex, suspend the array, and
reacquire the mutex before continuing.
Fixes: bc08041b32 ("md: suspend array in md_start_sync() if array need reconfiguration")
Reported-by: sashiko-bot <sashiko-bot@kernel.org>
Closes: https://sashiko.dev/#/patchset/20260628142420.1051027-1-abd.masalkhi@gmail.com?part=3
Signed-off-by: Abd-Alrhman Masalkhi <abd.masalkhi@gmail.com>
Reviewed-by: Yu Kuai <yukuai@fygo.io>
Link: https://patch.msgid.link/20260708112003.474537-1-abd.masalkhi@gmail.com
Signed-off-by: Yu Kuai <yukuai@fygo.io>
During link down event, we were doing netif_tx_stop_all_queues() first
and then netif_carrier_off(). This can cause a potential race since
carrier is still on during down event. This patch reverse the calling
order to fix the issue.
Fixes: 50fe6c02e5 ("octeontx2-pf: Register and handle link notifications")
Signed-off-by: Suman Ghosh <sumang@marvell.com>
Signed-off-by: Ratheesh Kannoth <rkannoth@marvell.com>
Reviewed-by: Simon Horman <horms@kernel.org>
Link: https://patch.msgid.link/20260724072831.2415281-1-rkannoth@marvell.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Add a leading "struct" keyword to struct descriptions:
Warning: ../include/uapi/rdma/ib_user_mad.h:72 cannot understand function prototype: 'struct ib_user_mad_hdr_old'
Warning: ../include/uapi/rdma/ib_user_mad.h:116 cannot understand function prototype: 'struct ib_user_mad_hdr'
Warning: ../include/uapi/rdma/ib_user_mad.h:143 cannot understand function prototype: 'struct ib_user_mad'
Warning: ../include/uapi/rdma/ib_user_mad.h:184 cannot understand function prototype: 'struct ib_user_mad_reg_req'
Warning: ../include/uapi/rdma/ib_user_mad.h:216 cannot understand function prototype: 'enum'
One enum and #define are moved out of line so that the struct description
and the struct block are not split (separated).
When this is done, more warnings are exposed:
Warning: include/uapi/rdma/ib_user_mad.h:89 struct member 'length' not described in 'ib_user_mad_hdr_old'
Warning: include/uapi/rdma/ib_user_mad.h:135 struct member 'length' not described in 'ib_user_mad_hdr'
Warning: include/uapi/rdma/ib_user_mad.h:135 struct member 'reserved' not described in 'ib_user_mad_hdr'
Warning: include/uapi/rdma/ib_user_mad.h:227 struct member 'id' not described in 'ib_user_mad_reg_req2'
Warning: include/uapi/rdma/ib_user_mad.h:227 struct member 'qpn' not described in 'ib_user_mad_reg_req2'
Warning: include/uapi/rdma/ib_user_mad.h:227 struct member 'mgmt_class' not described in 'ib_user_mad_reg_req2'
Warning: include/uapi/rdma/ib_user_mad.h:227 struct member 'mgmt_class_version' not described in 'ib_user_mad_reg_req2'
Warning: include/uapi/rdma/ib_user_mad.h:227 struct member 'res' not described in 'ib_user_mad_reg_req2'
Warning: include/uapi/rdma/ib_user_mad.h:227 struct member 'flags' not described in 'ib_user_mad_reg_req2'
Warning: include/uapi/rdma/ib_user_mad.h:227 struct member 'method_mask' not described in 'ib_user_mad_reg_req2'
Warning: include/uapi/rdma/ib_user_mad.h:227 struct member 'oui' not described in 'ib_user_mad_reg_req2'
Warning: include/uapi/rdma/ib_user_mad.h:227 struct member 'rmpp_version' not described in 'ib_user_mad_reg_req2'
Warning: include/uapi/rdma/ib_user_mad.h:227 struct member 'reserved' not described in 'ib_user_mad_reg_req2'
These are all repaired by using ':' as the separator between the struct
member @name and its description (instead of '-').
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Link: https://patch.msgid.link/20260728183403.1136827-1-rdunlap@infradead.org
Signed-off-by: Leon Romanovsky <leon@kernel.org>
REQ_NOWAIT support in md personalities that can block internally is
fundamentally incomplete. While reads can avoid some blocking paths,
write requests can still encounter cases where one mirror succeeds while
another returns -EAGAIN. At that point md cannot distinguish queue
pressure from a real device failure, so it can neither record a bad
block nor safely retry the write without REQ_NOWAIT, leaving mirrors
with divergent data.
Rather than continue advertising REQ_NOWAIT support for personalities
that cannot implement it correctly, remove it from raid1, raid10 and
raid456. Keep REQ_NOWAIT for linear and raid0, which only remap bios to
their underlying devices; stacked limits will still clear the feature if
any component device lacks REQ_NOWAIT support.
Fixes: bf2c411bb1 ("md: raid456 add nowait support")
Fixes: c9aa889b03 ("md: raid10 add nowait support")
Fixes: 5aa705039c ("md: raid1 add nowait support")
Fixes: f51d46d0e7 ("md: add support for REQ_NOWAIT")
Suggested-by: Yu Kuai <yukuai@fygo.io>
Signed-off-by: Abd-Alrhman Masalkhi <abd.masalkhi@gmail.com>
Reviewed-by: Yu Kuai <yukuai@fygo.io>
Link: https://patch.msgid.link/20260628142737.1051059-1-abd.masalkhi@gmail.com
Signed-off-by: Yu Kuai <yukuai@fygo.io>
When udf_expand_file_adinicb() converts file from inline format to out
of line, we use filemap_fdatawrite() to writeout the data to the new
blocks. However since 36580ed087 ("udf: Do not allocate blocks on page
writeback") the writeback actually doesn't allocate the new block and
the folio dirty bit is just silently cleared. Thus unless the file is
written to after the conversion (as it can easily happen in case of
truncate up), the data is just lost. Fix the problem by explicitely
allocating the block underlying the data before starting writeback.
Fixes: 36580ed087 ("udf: Do not allocate blocks on page writeback")
CC: stable@vger.kernel.org
Link: https://patch.msgid.link/20260730104232.4086759-4-jack@suse.cz
Signed-off-by: Jan Kara <jack@suse.cz>
The system call can clobber the ctr and xer registers.
Make sure the compiler takes this into account.
The missing clobbers only seem to be an issue with newer compilers.
Fixes: 0cb0675ec3 ("tools/nolibc: add support for powerpc")
Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
Link: https://patch.msgid.link/20260727-nolibc-powerpc-clobber-v1-1-e0911cc99ce1@linutronix.de
Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
When TX VLAN hardware offload is disabled, VLAN tags are embedded in
the packet payload (software VLAN). Previously, the driver failed to
set the WX_TX_FLAGS_SW_VLAN flag for these packets during transmission.
This missing flag caused the txgbe FDIR ATR logic to fall through to the
default hash calculation path. This resulted in asymmetric hash values
for Tx and Rx flows, preventing return packets from being steered to the
same queue as the transmit packets.
Fix this by detecting software VLANs via eth_type_vlan(skb->protocol)
and setting WX_TX_FLAGS_SW_VLAN. This ensures the ATR feature selects
the correct hashing algorithm to maintain Tx/Rx queue symmetry.
Fixes: b501d261a5 ("net: txgbe: add FDIR ATR support")
Signed-off-by: Jiawen Wu <jiawenwu@trustnetic.com>
Reviewed-by: Simon Horman <horms@kernel.org>
Link: https://patch.msgid.link/0879DA38A8E32701+20260724074657.10773-1-jiawenwu@trustnetic.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Jori Koolstra <jkoolstra@xs4all.nl> says:
While reworking lookup_open() to implement O_CREAT|O_DIRECTORY I came
across inconsistency in how audit_inode_child() is called in various
file create paths.
audit_inode_child() is called in may_create_dentry() so that failed
filesystem operations still register an audit entry. On success, the
entry is overwritten when, for instance, fsnotify_create() is called.
This is the calling convention in vfs_create() and vfs_mkdir().
In lookup_open(), however, when atomic_open() should have created a
file but didn't, no call to audit_inode_child() is made. The same is
true for the regular ->create() path.
On the suggestion of Christian, I am splitting this series from the
O_CREAT|O_DIRECTORY work, so that this can be discussed with the audit
people without delaying that work.
* patches from https://patch.msgid.link/20260710164233.827744-1-jkoolstra@xs4all.nl:
fs/namei.c: update kerneldoc of atomic_open()
vfs: call audit_inode_child() in lookup_open() on failure
vfs: move create error && negative dentry case in lookup_open() up
Link: https://patch.msgid.link/20260710164233.827744-1-jkoolstra@xs4all.nl
Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
The comments above atomic_open() contain several errors:
- atomic_open() does not return 0 if successful
- @path is not updated
Fix those and be more explicit about when FMODE_OPENED and FMODE_CREATED
are set. Change to a full kerneldoc.
Signed-off-by: Jori Koolstra <jkoolstra@xs4all.nl>
Link: https://patch.msgid.link/20260710164233.827744-4-jkoolstra@xs4all.nl
Reviewed-by: Paul Moore <paul@paul-moore.com>
Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
audit_inode_child() is called in may_create_dentry() so that failed
filesystem operations still register an audit entry. On success, the
entry is overwritten when, for instance, fsnotify_create() is called.
This is the calling convention in vfs_create() and vfs_mkdir().
In lookup_open(), however, when atomic_open() should have created a
file but didn't, no call to audit_inode_child() is made. The same is
true for the regular ->create() path.
Fix the calling of audit_inode_child() in lookup_open() to match the
vfs_create() path. For the ->atomic_open() filesystems this logic has
been pushed into atomic_open(). This function is also reordered a bit
to make the case distinction of the possible returns from
->atomic_open() more explicit (i.e. finish_open() or finish_no_open()).
When retrying delegation breaking, audit_inode_child() could be called
more than once, but this is OK because those entries are reused.
Signed-off-by: Jori Koolstra <jkoolstra@xs4all.nl>
Link: https://patch.msgid.link/20260710164233.827744-3-jkoolstra@xs4all.nl
Acked-by: Paul Moore (audit) <paul@paul-moore.com>
Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
O_CREAT is stripped when create_error is set in lookup_open(), so when
lookup does not return an inode, the case
if (!dentry->d_inode && (open_flag & O_CREAT))
is always skipped. We can get rid of this cognitive step by handling the
error case first.
Reviewed-by: NeilBrown <neil@brown.name>
Signed-off-by: Jori Koolstra <jkoolstra@xs4all.nl>
Link: https://patch.msgid.link/20260710164233.827744-2-jkoolstra@xs4all.nl
Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
Breno Leitao says:
====================
netpoll: finish untangling netconsole from netpoll
This is the final series moving the netconsole-specific functions out of
netpoll and into netconsole.
There is nothing else left except struct netpoll ->name and ->dev_mac
fields, which are netconsole-specific fields, but they are still in
netpoll structure (no other netpoll user uses these two fields).
netpoll is now left simpler and with a clearer role: an API that takes
an skb and transmits it. The device setup and the local/remote address
handling that only netconsole needs no longer sit in the generic netpoll
code, but in netconsole (which was the only user).
struct netpoll gets leaner too. The netconsole-only fields are gone, so
the other netpoll users (bonding, team, bridge, vlan, macvlan, dsa) no
longer carry fields they never touch. (except ->name and ->dev_mac)
Signed-off-by: Breno Leitao <leitao@debian.org>
====================
Link: https://patch.msgid.link/20260724-netconsole_move_more_final-v1-0-a5f7691db81c@debian.org
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
netpoll_wait_carrier() waits for the egress device carrier during
netconsole setup. Its only caller, netcons_netpoll_setup(), already
lives in netconsole. Move the function into drivers/net/netconsole.c,
drop EXPORT_SYMBOL_GPL() and remove the prototype from <linux/netpoll.h>.
Rename it to netcons_wait_carrier() for the netcons_ prefix. It now reads
the timeout through netpoll_get_carrier_timeout(), since carrier_timeout
stays in netpoll to keep the netpoll.carrier_timeout parameter.
Signed-off-by: Breno Leitao <leitao@debian.org>
Reviewed-by: Gustavo Luiz Duarte <gustavold@gmail.com>
Link: https://patch.msgid.link/20260724-netconsole_move_more_final-v1-9-a5f7691db81c@debian.org
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
With netpoll_setup() and the packet-building path now living in
netconsole, local_ip, remote_ip and ipv6 in struct netpoll are read
and written only by netconsole. No other netpoll user touches them.
Move the three fields into netconsole_target and switch the packet
builders and setup helpers to take the target instead of the netpoll
handle. struct netpoll is left holding only the device-binding state
that the shared netpoll transport needs.
Signed-off-by: Breno Leitao <leitao@debian.org>
Reviewed-by: Gustavo Luiz Duarte <gustavold@gmail.com>
Link: https://patch.msgid.link/20260724-netconsole_move_more_final-v1-8-a5f7691db81c@debian.org
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Move netpoll_take_ipv4() to netconsole, which is the only user. Rename
it to netcons_take_ipv4() for the netcons_ prefix. The body is
unchanged.
Signed-off-by: Breno Leitao <leitao@debian.org>
Reviewed-by: Gustavo Luiz Duarte <gustavold@gmail.com>
Link: https://patch.msgid.link/20260724-netconsole_move_more_final-v1-5-a5f7691db81c@debian.org
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Move netpoll_local_ip_unset() from netpoll to netconsole and rename it
to netcons_local_ip_unset();
The body is otherwise unchanged, only the comment's setup-function
reference is updated.
Signed-off-by: Breno Leitao <leitao@debian.org>
Reviewed-by: Gustavo Luiz Duarte <gustavold@gmail.com>
Link: https://patch.msgid.link/20260724-netconsole_move_more_final-v1-4-a5f7691db81c@debian.org
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
netpoll_setup() is only used by netconsole. All the other users use
__netpoll_setup().
Move netpoll_setup() to netconsole, and rename it to
netcons_netpoll_setup().
Pure code motion: the body is unchanged.
Signed-off-by: Breno Leitao <leitao@debian.org>
Reviewed-by: Gustavo Luiz Duarte <gustavold@gmail.com>
Link: https://patch.msgid.link/20260724-netconsole_move_more_final-v1-3-a5f7691db81c@debian.org
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Temporarily export leaf functions that will be moved to netconsole.
The upcoming patch will move the setup function to netconsole, and
continue to call these leaf functions here in netpoll, then other
patches will move these exports functions to netconsole (and make them
statics).
In summary, these exports are temporary in order to make the patchset
digestible.
Signed-off-by: Breno Leitao <leitao@debian.org>
Reviewed-by: Gustavo Luiz Duarte <gustavold@gmail.com>
Link: https://patch.msgid.link/20260724-netconsole_move_more_final-v1-2-a5f7691db81c@debian.org
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
netpoll_wait_carrier() is only used in netconsole, and it will move to
netconsole.
The carrier_timeout module parameter has to stay in netpoll so the
existing netpoll.carrier_timeout kernel parameter keeps working for
current users, and we don't break user compatibility.
Add a netpoll_get_carrier_timeout() accessor and export it so netconsole
can read the value once the carrier wait lives there. Drop the now
redundant timeout argument from netpoll_wait_carrier() (its only caller
passed carrier_timeout) and read the parameter directly while the helper
still lives here.
Signed-off-by: Breno Leitao <leitao@debian.org>
Reviewed-by: Gustavo Luiz Duarte <gustavold@gmail.com>
Link: https://patch.msgid.link/20260724-netconsole_move_more_final-v1-1-a5f7691db81c@debian.org
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
The fanotify permission watchdog can be disabled by writing zero to
fs/fanotify/watchdog_timeout. fanotify_perm_watchdog_group_add() already
checks for a zero timeout before scheduling the watchdog.
However, once the watchdog work has been scheduled, perm_group_watchdog()
unconditionally schedules itself again with the current timeout. If the
sysctl is changed to zero while the work is active, secs_to_jiffies(0)
causes the work to be rescheduled immediately, resulting in a kworker
busy loop.
Read the timeout once in perm_group_watchdog_schedule() and do not
schedule the work when it is zero. This lets a running watchdog stop
after the next execution when the sysctl is set to zero.
Fixes: b8cf8fda52 ("fanotify: add watchdog for permission events")
Signed-off-by: Yichong Chen <chenyichong@uniontech.com>
Link: https://patch.msgid.link/20260730070648.549458-1-chenyichong@uniontech.com
Signed-off-by: Jan Kara <jack@suse.cz>
panthor_fw_load_section_entry() skips BO creation when the firmware section
VA range is empty. If such a section is added to the firmware section list,
section->mem is left as NULL.
Later reload and unplug paths iterate over all firmware sections and
dereference section->mem, which can lead to a NULL pointer dereference.
Zero-sized firmware sections are valid, so accept them as no-op entries but
skip adding them to the section list.
Fixes: 2718d91816 ("drm/panthor: Add the FW logical block")
Cc: stable@vger.kernel.org
Signed-off-by: Osama Abdelkader <osama.abdelkader@gmail.com>
Reviewed-by: Liviu Dudau <liviu.dudau@arm.com>
Reviewed-by: Steven Price <steven.price@arm.com>
Link: https://patch.msgid.link/20260724172621.63046-1-osama.abdelkader@gmail.com
Signed-off-by: Steven Price <steven.price@arm.com>
During reshape:
- reshape_request() advances rdev->recovery_offset for non-In_sync
devices locklessly.
- analyse_stripe() reads rdev->recovery_offset locklessly to decide:
a. use a replacement device to read ?
b. a device can already be treated as in-sync for the current
stripe ?
one possible scenario is:
CPU1 CPU2
reshape_request()
-> mddev->curr_resync_completed = sector_nr
-> if (!mddev->reshape_backwards)
-> rdev->recovery_offset = sector_nr
analyse_stripe(sh)
-> rdev = conf->disks[i].replacement
-> if (rdev->recovery_offset >=
sh->sector + stripe_sectors)
set_bit(R5_ReadRepl)
-> or
-> if (sh->sector + stripe_sectors <=
rdev->recovery_offset)
set_bit(R5_Insync)
And it could be:
- reading from a replacement before it is recovered far enough; or
- treating a not-yet-recovered device as in-sync for the current stripe.
Fixes: db0505d320 ("md: be cautious about using ->curr_resync_completed for ->recovery_offset")
The race report:
==================================================================
BUG: KCSAN: data-race in ops_run_io / reshape_request
write to 0xffff8bdee168b270 of 8 bytes by task 1704 on cpu 10:
reshape_request+0x1292/0x17b0
raid5_sync_request+0x815/0xa00
md_do_sync.cold+0xf8d/0x1516
[......]
read to 0xffff8bdee168b270 of 8 bytes by task 1696 on cpu 9:
ops_run_io+0xc25/0x1960
handle_stripe+0x2273/0x4570
handle_active_stripes.isra.0+0x6e0/0xa50
raid5d+0x7d5/0xb90
[......]
value changed: 0x0000000000091a00 -> 0x0000000000091b00
==================================================================
Signed-off-by: Chen Cheng <chencheng@fnnas.com>
Reviewed-by: Yu Kuai <yukuai@fygo.io>
Link: https://patch.msgid.link/20260627102519.136940-1-chencheng@fnnas.com
Signed-off-by: Yu Kuai <yukuai@fygo.io>
reshape stripe lifetime:
- start reshape ==> reshape_request():
* get destination stripe,
- if need to copy source data chunks, set STRIPE_EXPANDING;
- or, if new regions past the old end of the array, zero-filled,
no need source data, set STRIPE_EXPANDING | STRIPE_READY
* get source stripe,
- set STRIPE_EXPAND_SOURCE
- handle expand stripe ==> handle_stripe():
reshape use reconstruct-write to construct stripe,
four stages:
1. prepare source data chunks for old geometry stripe
- fill source stripe data by read or compute
2. move data from old geometry source stripe to new geometry
destination stripe
- source stripe clear STRIPE_EXPAND_SOURCE
- drain data from source to destination stripe
- mark stripe chunk as R5_Expanded|R5_UPTODATE when the
drain from source chunk to destination chunk is completed
- all stripe chunks drain are completed, then mark
STRIPE_EXPAND_READY
3. calculate p/q chunks for destination stripe
- if destination stripe doesn't depends on source dstripe,
then we can clear STRIPE_EXPANDING
4. write-out to disks and release
- set R5_Wantwrite|R5_Locked, writeout to disk
- if write-out succeeded, clear STRIPE_EXPAND_READY, and
decrement reshape_stripe, call md_done_sync() to report
reshape progress.
1. cleanup the following kinds of **destination stripe**
when failed device more than max degraded:
- new regions past the old end of the array, zero-filled in place,
requires no source data.
(STRIPE_EXPANDING | STRIPE_EXPAND_READY)
- prepare source data chunks already done, and writeout failed
(STRIPE_EXPAND_READY)
2. destination stripes that need source data
(STRIPE_EXPANDING, no STRIPE_HANDLE)
- these kind of stripes sit idle in the stripe cache and are never seen
by handle_stripe(). So clean up indirectly when their source stripe
(type 3) is processed.
3. source stripes (STRIPE_EXPAND_SOURCE)
- hit handle_stripe() after their member disks are marked Faulty.
- clear STRIPE_EXPAND_SOURCE, finds and cleanup all dependent destination
stripes that were waiting for data.
- walks the source's data disks, compute the corresponding destination
sector, looks up the destination stripe, and do cleanup(clear flags,
dec counters, call md_done_sync())
Reproducer:
- Create a 4-disk RAID5 with mdadm on top of 5 disposable test disks
wrapped by dm targets.
- Add the 5th device as a spare and start a 4 -> 5 reshape.
- Wait until /sys/block/mdX/md/sync_action reports "reshape".
- Inject failures on two members so reshape exceeds max_degraded.
- After a few seconds, write "frozen" to /sys/block/mdX/md/sync_action.
Before this fix, the write blocks indefinitely.
Read-error variant:
- Use dm-dust on /dev/sd[b-f].
- Preload bad blocks on two source members, e.g. dust0 and dust1:
dmsetup message dust0 0 addbadblock <range>
dmsetup message dust1 0 addbadblock <range>
- Start reshape:
mdadm -C /dev/mdX -e 1.2 -l 5 -n 4 -c 64 \
--assume-clean /dev/mapper/dust{0..3}
mdadm --manage /dev/mdX --add /dev/mapper/dust4
mdadm --grow /dev/mdX -n 5 --backup-file=/tmp/grow.backup &
- Once reshape starts, enable the injected read failures:
dmsetup message dust0 0 enable
dmsetup message dust1 0 enable
- Then:
echo frozen > /sys/block/mdX/md/sync_action
hangs forever before the fix.
Write-error variant:
- Use dm-flakey on /dev/sd[b-f].
- Start the same 4 -> 5 reshape on flakey0..flakey4.
- Once reshape starts, switch two members, e.g. flakey3 and flakey4,
to error_writes.
- Then:
echo frozen > /sys/block/mdX/md/sync_action
hangs forever before the fix.
md_do_sync() exits its main loop on MD_RECOVERY_INTR but then blocks
forever at:
wait_event(mddev->recovery_wait,
!atomic_read(&mddev->recovery_active));
After the fix recovery_active drains to zero, md_do_sync() prints
md/raid:md0: Cannot continue operation (2/5 failed).
md: md0: reshape interrupted.
Signed-off-by: Chen Cheng <chencheng@fnnas.com>
Reviewed-by: Yu Kuai <yukuai@fygo.io>
Link: https://patch.msgid.link/20260624075824.2601110-1-chencheng@fnnas.com
Signed-off-by: Yu Kuai <yukuai@fygo.io>
Lorenzo Bianconi says:
====================
airoha: add the capability to configure GDM3/GDM4 as WAN/LAN on demand
Add the capability to configure GDM3/GDM4 as WAN/LAN on demand when QoS
offload is created or destroyed.
Make dev->qdma an RCU pointer so the TX path can safely dereference it
without holding RTNL.
Introduce airoha_qdma_start() and airoha_qdma_stop() helpers.
====================
Link: https://patch.msgid.link/20260725-airoha-ethtool-priv_flags-v12-0-5136a30b2157@kernel.org
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
