Heiko Carstens [Mon, 8 Jun 2026 14:19:08 +0000 (16:19 +0200)]
s390/process: Fix kernel thread function pointer type
In case of a kernel thread __ret_from_fork() calls the specified function
indirectly. Fix the kernel thread function pointer, since kernel threads
return an int instead of void.
Fixes: 56e62a737028 ("s390: convert to generic entry") Reviewed-by: Alexander Gordeev <agordeev@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com> Signed-off-by: Alexander Gordeev <agordeev@linux.ibm.com>
Kean Ren [Thu, 11 Jun 2026 02:37:57 +0000 (10:37 +0800)]
ASoC: SDCA: fix NULL pointer dereference in sdca_dev_unregister_functions
sdca_dev_unregister_functions() iterates over all SDCA function
descriptors and calls sdca_dev_unregister() on each func_dev without
checking for NULL. When a function registration has failed partway
through, or the device cleanup races with probe deferral, func_dev
entries may be NULL, leading to a kernel oops:
This was observed on a Lenovo ThinkPad X1 Carbon G14 (Panther Lake)
with the SOF audio driver probe failing due to missing Panther Lake
firmware, causing the subsequent cleanup of SoundWire devices to
trigger the crash.
Fix this with three changes:
1) Add a NULL guard in sdca_dev_unregister() so that callers do not
need to pre-validate the pointer (defense in depth).
2) In sdca_dev_unregister_functions(), skip NULL func_dev entries
and clear func_dev to NULL after unregistration, making the
function idempotent and safe against double-invocation.
3) In sdca_dev_register_functions(), roll back all previously
registered functions when a later one fails, so the function
array is never left in a partially-populated state.
Fixes: 4496d1c65bad ("ASoC: SDCA: add function devices") Signed-off-by: Kean Ren <rh_king@163.com> Reviewed-by: Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://patch.msgid.link/20260611023757.1553960-1-rh_king@163.com Signed-off-by: Mark Brown <broonie@kernel.org>
Arnd Bergmann [Wed, 10 Jun 2026 14:23:29 +0000 (19:53 +0530)]
dma-buf: move system_cc_shared heap under separate Kconfig
While system heap and system_cc_shared heap share a lot of code
and hence the same source file, their users have different needs.
system heap users need it to be a loadable module, while
system_cc_shared heap users don't.
Building as a loadable module breaks system_cc_shared heap on
powerpc and s390 due to un-exported set_memory_encrypted /
set_memory_decrypted functions.
Fix these by reorganising code to put the system_cc_shared heap
under a new Kconfig symbol, which allows either building both
into the kernel, or leave encryption up to the consumers of the
system heap.
Fixes: fd55edff8a0a ("dma-buf: heaps: system: Turn the heap into a module") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Sumit Semwal <sumit.semwal@linaro.org>
[sumits: updated DMABUF_HEAPS_CC_SYSTEM to DMABUF_HEAPS_SYSTEM_CC_SHARED] Reviewed-by: T.J. Mercier <tjmercier@google.com> Acked-by: Maxime Ripard <mripard@kernel.org> Reviewed-by: Jiri Pirko <jiri@nvidia.com> Link: https://patch.msgid.link/20260610142329.3836808-1-sumit.semwal@linaro.org
Add compatible string for TI SN65LVDS93. Similar to
SN65LVDS83 but with an industrial temperature range.
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Signed-off-by: Hugo Villeneuve <hvilleneuve@dimonoff.com> Acked-by: Conor Dooley <conor.dooley@microchip.com> Signed-off-by: Frank Li <Frank.Li@nxp.com>
backlight: Use named initializers for arrays of i2c_device_data
While being less compact, using named initializers allows to more easily
see which members of the structs are assigned which value without having
to lookup the declaration of the struct. And it's also more robust
against changes to the struct definition.
The mentioned robustness is relevant for a planned change to struct
i2c_device_id that replaces .driver_data by an anonymous union.
While touching all these arrays, unify usage of whitespace in the list
terminator.
This patch doesn't modify the compiled arrays, only their representation
in source form benefits. The former was confirmed with x86 and arm64
builds.
ASoC: cs35l56: Fix possible uninitialized value in cs35l56_spi_system_reset()
In cs35l56_spi_system_reset() initialize val to zero before using it in
the read_poll_timeout(). This prevents testing an uninitialized value if
the regmap_read_bypassed() returns an error.
Read errors are intentionally ignored during this loop because the
device is resetting (though SPI can't really detect that so shouldn't
fail because of that, it's safer to ignore errors and keep polling).
Because of this, val must be initialized to something in case the first
read fails. The polling loop is looking for a non-zero value, so
initializing val to 0 will ensure that the loop continues until a valid
state is read from the device or it times out.
Johan Hovold [Tue, 9 Jun 2026 16:06:34 +0000 (18:06 +0200)]
pmdomain: core: fix early domain registration
A recent change switching to a dynamically allocated root device broke
platforms like rcar-sysc that registers PM domains before the PM domain
bus itself has been registered (cf. commit c5ae5a0c6112 ("pmdomain:
renesas: rcar-sysc: Add genpd OF provider at postcore_initcall")).
Defer the assignment of the parent root device until the domain is
registered with driver core to avoid it being left unset.
Lauri Saurus [Mon, 18 May 2026 19:28:50 +0000 (19:28 +0000)]
HID: logitech-hidpp: sync wheel multiplier on wheel mode changes
The hid-logitech-hidpp driver enables high resolution scrolling on
device connect for capable HID++ 2.0 devices. Driver also reads the
wheel capability and caches the returned high resolution wheel scroll
multiplier, that is used for scroll scaling when handling wheel scroll
events.
Wheel mode can also be set externally through HID++ requests, which
can leave the cached multiplier stale and cause incorrect scroll
scaling. If external SetWheelMode HID++ request sets the mode to
low resolution, the cached multiplier is not updated accordingly. This
causes extremely slow scrolling since driver expects multiple wheel
scroll events per detent but is only getting one.
The fix listens for HID++ SetWheelMode request responses and updates
the wheel scroll multiplier based on the set high resolution scroll
mode. The fix has been tested with Logitech G502X lightspeed mouse.
Signed-off-by: Lauri Saurus <saurla@saurla.com> Signed-off-by: Jiri Kosina <jkosina@suse.com>
Florian Fainelli [Mon, 25 May 2026 16:38:17 +0000 (17:38 +0100)]
ARM: 9476/1: mm: fix kexec and hibernation with CONFIG_CPU_TTBR0_PAN
Commit 7af5b901e847 ("ARM: 9358/2: Implement PAN for LPAE by TTBR0
page table walks disablement") implemented PAN for LPAE kernels by
setting TTBCR.EPD0 on every kernel entry, disabling TTBR0 page-table
walks while running in kernel mode. The commit correctly updated
cpu_suspend() in arch/arm/kernel/suspend.c, but missed two other code
paths that switch the CPU to the identity mapping before jumping to
low-PA (TTBR0-range) physical addresses:
1. setup_mm_for_reboot() in arch/arm/mm/idmap.c, used by the kexec
reboot path. With TTBCR.EPD0 still set, the subsequent branch to
the identity-mapped cpu_v7_reset causes a PrefetchAbort because the
TTBR0 page-table walk needed to resolve the identity-mapped address
is disabled. This manifests as a hard hang or "bad PC value" panic
on LPAE kernels booted on CPUs that strictly enforce EPD0 for
instruction fetch (e.g. Cortex-A53 in AArch32 mode) while the same
image may accidentally work on Cortex-A15 due to microarchitectural
differences in EPD0 enforcement.
2. arch_restore_image() in arch/arm/kernel/hibernate.c, which calls
cpu_switch_mm(idmap_pgd, &init_mm) directly without going through
setup_mm_for_reboot(), leaving TTBCR.EPD0 set while the identity
mapping is active.
Fix both sites by calling uaccess_save_and_enable() before switching
to the identity mapping, mirroring what the original commit did for
cpu_suspend().
Assisted-by: Cursor:claude-sonnet-4.6 Fixes: 7af5b901e847 ("ARM: 9358/2: Implement PAN for LPAE by TTBR0 page table walks disablement") Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Linus Walleij <linusw@kernel.org> Signed-off-by: Florian Fainelli <florian.fainelli@broadcom.com> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Karl Mehltretter [Sun, 24 May 2026 05:52:35 +0000 (06:52 +0100)]
ARM: 9475/1: entry: use byte load for KASAN VMAP stack shadow
Commit 44e9a3bb76e5 ("ARM: 9430/1: entry: Do a dummy read from
VMAP shadow") added a dummy read from the KASAN VMAP stack shadow in
__switch_to(). The read uses ldr, but the KASAN shadow address is
byte-granular and is not guaranteed to be word aligned.
ARMv5 faults unaligned word loads. With CONFIG_KASAN_VMALLOC and
CONFIG_VMAP_STACK enabled, ARM926/VersatilePB crashes in __switch_to()
with an alignment exception before reaching init.
Use ldrb for the dummy shadow access. The code only needs to fault in the
shadow mapping if the stack shadow is missing, so a byte load is sufficient
and matches the granularity of KASAN shadow memory.
Fixes: 44e9a3bb76e5 ("ARM: 9430/1: entry: Do a dummy read from VMAP shadow") Cc: stable@vger.kernel.org # v6.13+ Signed-off-by: Karl Mehltretter <kmehltretter@gmail.com> Reviewed-by: Linus Walleij <linusw@kernel.org> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Karl Mehltretter [Sun, 24 May 2026 05:52:36 +0000 (06:52 +0100)]
ARM: 9474/1: io: avoid KASAN instrumentation of raw halfword I/O
For CPUs before ARMv6, __raw_readw() and __raw_writew() are implemented
as C volatile halfword accesses so the compiler can generate an access
sequence that is safe for those machines. With KASAN enabled, those C
accesses are instrumented as normal memory accesses.
That is not valid for MMIO. On ARM926/VersatilePB with KASAN enabled,
PL011 probing traps in __asan_store2() while registering the UART, because
the instrumented writew() tries to check KASAN shadow for an MMIO address.
Keep the existing volatile halfword access, but move the ARMv5 definitions
into __no_kasan_or_inline functions so raw MMIO halfword accesses are not
instrumented by KASAN. The ARMv6-and-newer inline assembly path is
unchanged.
Fixes: 421015713b30 ("ARM: 9017/2: Enable KASan for ARM") Cc: stable@vger.kernel.org # v5.11+ Signed-off-by: Karl Mehltretter <kmehltretter@gmail.com> Reviewed-by: Linus Walleij <linusw@kernel.org> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Vadim Fedorenko [Wed, 10 Jun 2026 22:28:43 +0000 (22:28 +0000)]
spi: xilinx: let transfers timeout in case of no IRQ
In case of failed HW the driver may not see an interrupt and will stuck
in waiting forever. We can avoid such situation by timing out of
transfers if the interrupt is not seen in a reasonable time.
This problem can be found on unload of ptp_ocp driver for TimeCard which
uses Xilinx SPI AXI and SPI-NOR flash memory. During tear-down process
spi-nor drivers send soft reset command which is not triggering an
interrupt stalling the unload process completely.
Even though the Allwinner A523 SoC implements 10 GPIO banks, it has
actually registers for 11 IRQ banks, and even an interrupt assigned to
the first, non-implemented IRQ bank.
Add that first interrupt to the list of GPIO interrupts, to correct the
association between IRQs and GPIO banks.
This fixes GPIO IRQ operation on boards with A523 SoCs, as seen by
broken SD card detect functionality, for instance.
Jakub Kicinski [Tue, 9 Jun 2026 18:33:53 +0000 (11:33 -0700)]
net: sched: avoid printing uninitialized link speed
sch_cbs and sch_taprio print ecmd.base.speed, even if
netif_get_link_ksettings() failed. When netif_get_link_ksettings()
fails the ecmd may not be initialized.
Use the always-initialized speed variable instead.
The semantics change slightly because UNKNOWN will
never be printed, but that doesn't seem important
enough to complicate the code for.
Rodrigo Vivi [Wed, 10 Jun 2026 15:25:49 +0000 (11:25 -0400)]
drm/xe: fix job timeout recovery for unstarted jobs and kernel queues
A job that GuC never scheduled (never started) indicates a GuC
scheduling failure; previously such jobs were silently errored out
instead of triggering a GT reset to recover. Trigger a GT reset and
resubmit them, but only when the queue was not already killed or banned:
an unstarted job on an already banned queue is the ban working as
intended and must neither clear the ban nor kick off a reset, otherwise
a banned userspace queue could be resurrected and spam GT resets.
Kernel queues are always recovered this way and wedge the device once
recovery attempts are exhausted, since kernel work must not silently
fail. A started job that times out on a userspace VM bind queue stays
banned rather than being reset and retried.
The queue is banned early in the timeout handler to signal the G2H
scheduling-done handler so it wakes the disable-scheduling waiter;
without it the waiter sleeps the full 5s timeout. When a reset is
warranted the ban is cleared before rearming so that
guc_exec_queue_start() can resubmit jobs after the GT reset - a
still-banned queue would block resubmission and cause an infinite TDR
loop. The already-banned case is gated out before this point via
skip_timeout_check, so it is unaffected.
v2: (Himal) Do it for any queue type, not just kernel/migration
v3: - (Sashiko and Sanjay): don't clear the ban / GT reset for already
killed/banned queues on unstarted-job timeout
- Update commit message
- (Matt) Add Fixes tag
Fixes: fe05cee4d953 ("drm/xe: Don't short circuit TDR on jobs not started") Cc: Matthew Auld <matthew.auld@intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Cc: Sanjay Yadav <sanjay.kumar.yadav@intel.com> Cc: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com> Assisted-by: GitHub-Copilot:claude-sonnet-4.6 Assisted-by: GitHub-Copilot:claude-opus-4.8 Tested-by: Sanjay Yadav <sanjay.kumar.yadav@intel.com> Reviewed-by: Sanjay Yadav <sanjay.kumar.yadav@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com> Link: https://patch.msgid.link/20260610152548.404575-3-rodrigo.vivi@intel.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
(cherry picked from commit b1107d085e7e8ed15ba6f80c102528a9c8a6cb0e) Signed-off-by: Matthew Brost <matthew.brost@intel.com>
Wentao Liang [Wed, 10 Jun 2026 17:27:05 +0000 (10:27 -0700)]
drm/xe: fix refcount leak in xe_range_fence_insert()
xe_range_fence_insert() acquires a reference on fence via
dma_fence_get() and stores it in rfence->fence. It then calls
dma_fence_add_callback() and handles two cases: when the callback
is successfully registered (err == 0) the fence is transferred to
the tree for later cleanup; when the fence is already signaled
(err == -ENOENT) it manually drops the extra reference with
dma_fence_put(fence).
However, dma_fence_add_callback() can fail with other errors
(e.g. -EINVAL) and in that case the code falls through to the free:
label without releasing the acquired reference, leaking it.
Fix the leak by adding an else branch that calls dma_fence_put()
before jumping to free: for any error other than -ENOENT.
Eric Dumazet [Tue, 9 Jun 2026 09:13:37 +0000 (09:13 +0000)]
ip6_tunnel: do not use dst6_mtu() in ip4ip6_err() and ip6erspan_tunnel_xmit()
This is a minor performance / conceptual fix.
1) ip6erspan_tunnel_xmit()
ERSPAN tunnel can mirror both IPv4 and IPv6 traffic, skb
(the packet being mirrored) can be an IPv4 packet,
and thus dst can be an IPv4 destination entry
Use dst_mtu() which contains generic logic for both families.
2) ip4ip6_err()
skb2 has been prepared as an IPv4 packet, and its destination
is an IPv4 route.
dst6_mtu() is optimized for IPv6 destinations and uses INDIRECT_CALL_1
to call ip6_mtu() directly if the ops match.
Merge branches 'acpi-processor', 'acpi-cppc' and 'acpi-pci'
Merge an ACPI processor driver update, two ACPI CPPC library updates
and ACPI PCI/CXL support updates for 7.2-rc1:
- Add cpuidle driver check in acpi_processor_register_idle_driver() to
avoid evaluating _CST unnecessarily (Tony W Wang-oc)
- Suppress UBSAN warning caused by field misuse during PCC-based
register access in the ACPI CPPC library (Jeremy Linton)
- Add support for CPPC v4 to the ACPI CPPC library (Sumit Gupta)
- Update the ACPI device enumeration code to honor _DEP for ACPI0016
PCI/CXL host bridges and make the ACPI PCI root driver clear _DEP
dependencies for PCI roots that have become operational (Chen Pei)
* acpi-processor:
ACPI: processor: Add cpuidle driver check in acpi_processor_register_idle_driver()
* acpi-cppc:
ACPI: CPPC: Suppress UBSAN warning caused by field misuse
ACPI: CPPC: Add support for CPPC v4
- Clean up lid handling in the ACPI button driver and
acpi_button_probe(), reorganize installing and removing event
handlers in that driver and switch it over to using devres-based
resource management during probe (Rafael Wysocki)
* acpi-button:
ACPI: button: Switch over to devres-based resource management
ACPI: button: Reorganize installing and removing event handlers
ACPI: button: Use string literals for generating netlink messages
ACPI: button: Clean up adding and removing lid procfs interface
ACPI: button: Merge two switch () statements in acpi_button_probe()
ACPI: button: Drop redundant variable from acpi_button_probe()
ACPI: button: Rework device verification during probe
ACPI: button: Use local pointer to platform device dev field in probe
ACPI: button: Eliminate redundant conditional statement
ACPI: button: Change return type of two functions to void
ACPI: button: Eliminate ternary operator from acpi_lid_evaluate_state()
ACPI: button: Use bool for representing boolean values
ACPI: button: Improve warning message regarding lid state
ACPI: button: Pass ACPI handle to acpi_lid_evaluate_state()
ACPI: button: Fix lid_device value leak past driver removal
Merge updates of core ACPI device drivers for 7.2-rc1:
- Fix multiple issues related to probe, removal and missing NVDIMM
device notifications in the ACPI NFIT driver (Rafael Wysocki)
- Add support for devres-based management of ACPI notify handlers to
the ACPI core (Rafael Wysocki)
- Switch multiple core ACPI device drivers (including the ACPI PAD,
ACPI video bus, ACPI HED, ACPI thermal zone, ACPI AC, ACPI battery,
and ACPI NFIT drivers) over to using devres-based resource management
during probe (Rafael Wysocki)
- Replace mutex_lock/unlock() with guard()/scoped_guard() in the ACPI
PMIC driver (Maxwell Doose)
- Fix message kref handling in the dead device path of the ACPI IPMI
address space handler (Yuho Choi)
- Use sysfs_emit() in idlecpus_show() in the ACPI processor aggregator
device (PAD) driver (Yury Norov)
- Clean up device_id_scheme initialization in the ACPI video bus driver
(Jean-Ralph Aviles)
* acpi-driver: (26 commits)
ACPI: IPMI: Fix message kref handling on dead device
ACPI: NFIT: core: Fix possible deadlock and missing notifications
ACPI: NFIT: core: Eliminate redundant local variable
ACPI: NFIT: core: Fix acpi_nfit_init() error cleanup
ACPI: NFIT: core: Fix possible NULL pointer dereference
ACPI: bus: Clean up devm_acpi_install_notify_handler()
ACPI: PAD: Use sysfs_emit() in idlecpus_show()
ACPI: video: Do not initialise device_id_scheme directly
ACPI: video: Switch over to devres-based resource management
ACPI: video: Use devm for video->entry and backlight cleanup
ACPI: video: Use devm action for freeing video devices
ACPI: video: Use devm action for video bus object cleanup
ACPI: video: Rearrange probe and remove code
ACPI: video: Reduce the number of auxiliary device dereferences
ACPI: PAD: Switch over to devres-based resource management
ACPI: PAD: Fix teardown ordering in acpi_pad_remove()
ACPI: PAD: Pass struct device pointer to acpi_pad_notify()
ACPI: PAD: Rearrange acpi_pad_notify()
ACPI: thermal: Switch over to devres-based resource management
ACPI: HED: Switch over to devres-based resource management
...
pinctrl: qcom: Register functions before enabling pinctrl
pinctrl consumers can request states while the pinctrl core enables the
controller. On Qualcomm pinctrl drivers this can happen before the SoC
function list has been registered, which leaves the function table
incomplete during state lookup.
On APQ8064 this can fail while claiming pinctrl hogs:
apq8064-pinctrl 800000.pinctrl: invalid function ps_hold in map table
apq8064-pinctrl 800000.pinctrl: error claiming hogs: -22
apq8064-pinctrl 800000.pinctrl: could not claim hogs: -22
Register Qualcomm pinctrl with devm_pinctrl_register_and_init(), add the
SoC pin functions, and only then enable the pinctrl device.
Add support for the pin controller on the UltraRISC DP1000 SoC.
The controller provides mux selection for pins in ports A, B, C, D, and
LPC. Ports A-D default to GPIO and support peripheral muxing. LPC pins
can be switched to eSPI, but are not available as GPIOs. Basic pin
configuration controls such as drive strength, pull-up, and pull-down
are also supported.
Merge ACPICA updates for 7.2-rc1 including the following changes:
- Add support for the Legacy Virtual Register (LVR) field in I2C serial
bus resource descriptors to ACPICA (Akhil R)
- Fix multiple issues related to bounds checks, input validation,
use-after-free, and integer overflow checks in the AML interpreter
in ACPICA (ikaros)
- Update the copyright year to 2026 in ACPICA files and make minor
changes related to ACPI 6.6 support (Pawel Chmielewski)
- Remove spurious precision from format used to dump parse trees in
ACPICA (David Laight)
- Add modern standby DSM GUIDs to ACPICA header files (Daniel Schaefer)
- Update D3hot/cold device power states definitions in ACPICA header
files (Aymeric Wibo)
- Fix NULL pointer dereference in acpi_ns_custom_package() (Weiming
Shi)
- Update ACPICA version to 20260408 (Saket Dumbre)
* acpica: (27 commits)
ACPICA: add boundary checks in two places
ACPICA: Add package limit checks in parser functions
ACPICA: Update version to 20260408
ACPICA: Update the copyright year to 2026
ACPICA: Remove spurious precision from format used to dump parse trees
ACPICA: Enhance OEM ID and Table ID validation in acpi_ex_load_table_op()
ACPICA: Fix NULL pointer dereference in acpi_ns_custom_package()
ACPICA: Enhance buffer validation in acpi_ut_walk_aml_resources()
ACPICA: Add validation for node in acpi_ns_build_normalized_path()
ACPICA: validate handler object type in two places
ACPICA: Improve argument parsing in acpi_ps_get_next_simple_arg()
ACPICA: Fix integer overflow in acpi_ex_opcode_3A_1T_1R() (mid_op)
ACPICA: Prevent adding invalid references
ACPICA: add boundary checks in acpi_ps_get_next_field()
ACPICA: validate byte_count in acpi_ps_get_next_package_length()
ACPICA: Fix use-after-free in acpi_ds_terminate_control_method()
ACPICA: fix I2C LVR item count in the conversion table
ACPICA: Mention the LVR bits
ACPICA: Change LVR to 8 bit value
ACPICA: Fetch LVR I2C resource descriptor
...
pinctrl: tegra: PINCTRL_TEGRA264 should depend on ARCH_TEGRA
The NVIDIA Tegra264 MAIN, AON, and UPHY pin controllers are only present
on NVIDIA Tegra264 SoCs. Hence add a dependency on ARCH_TEGRA, to
prevent asking the user about this driver when configuring a kernel
without NVIDIA Tegra SoC support.
pinctrl: tegra: PINCTRL_TEGRA238 should depend on ARCH_TEGRA
The NVIDIA Tegra238 MAIN and AON pin controllers are only present on
NVIDIA Tegra238 SoCs. Hence add a dependency on ARCH_TEGRA, to prevent
asking the user about this driver when configuring a kernel without
NVIDIA Tegra SoC support.
Add 24 pin groups on ports EE, FF, GG and HH to the AON pin controller
group table (tegra238_aon_groups[]). Their pin arrays, drive-group
macros and pin descriptors were already defined, but the matching
PINGROUP() entries were not present, so these pins could not be muxed
or configured through the AON pin controller.
The pin arrays were not referenced, so the build emitted
-Wunused-const-variable warnings, and commit 119de2c33d96 ("pinctrl:
tegra238: remove unused entries") removed three of them. Restore those
arrays and add the full set of PINGROUP() entries to make the pins
usable.
dt-bindings: pinctrl: tegra238: add missing AON pin groups
Add 24 pin groups, and their matching drive groups, on ports EE, FF,
GG and HH to the Tegra238 AON pinmux binding. These groups are present
on the AON pin controller, so device trees that mux these pins through
it validate against the schema.
Andre Przywara [Fri, 27 Mar 2026 11:30:05 +0000 (11:30 +0000)]
dt-bindings: pinctrl: sun55i-a523: increase IRQ banks number
The Allwinner A523 SoC implements 10 GPIO banks in the first pinctrl
instance, but it skips the first bank (PortA), so their index goes from
1 to 10. The same is actually true for the IRQ banks: there are registers
for 11 banks, though the first bank is not implemented (RAZ/WI).
In contrast to previous SoCs, the count of the IRQ banks starts with this
first unimplemented bank, so we need to provide an interrupt for it.
And indeed the A523 user manual lists an interrupt number for PortA, so we
need to increase the maximum number of interrupts per pin controller to 11,
to be able to assign the correct interrupt number for each bank.
Andre Przywara [Fri, 27 Mar 2026 11:30:04 +0000 (11:30 +0000)]
pinctrl: sunxi: a523: Remove unneeded IRQ remuxing flag
The Allwinner A10 and H3 SoCs cannot read the state of a GPIO line when
that line is muxed for IRQ triggering (muxval 6), but only if it's
explicitly muxed for GPIO input (muxval 0). Other SoCs do not show this
behaviour, so we added a optional workaround, triggered by a quirk bit,
which triggers remuxing the pin when it's configured for IRQ, while we
need to read its value.
For some reasons this quirk flag was copied over to newer SoCs, even
though they don't show this behaviour, and the GPIO data register
reflects the true GPIO state even with a pin muxed to IRQ trigger.
Remove the unneeded quirk from the A523 family, where it's definitely
not needed (confirmed by experiments), and where it actually breaks,
because the workaround is not compatible with the newer generation
pinctrl IP used in that chip.
Together with a DT change this fixes GPIO IRQ operation on the A523
family of SoCs, as for instance used for the SD card detection.
Signed-off-by: Andre Przywara <andre.przywara@arm.com> Fixes: b8a51e95b376 ("pinctrl: sunxi: Add support for the secondary A523 GPIO ports") Reviewed-by: Jernej Skrabec <jernej.skrabec@gmail.com> Acked-by: Chen-Yu Tsai <wens@kernel.org> Signed-off-by: Linus Walleij <linusw@kernel.org>
Dmitry Ilvokhin [Thu, 4 Jun 2026 07:15:07 +0000 (07:15 +0000)]
locking: Add contended_release tracepoint to sleepable locks
Add the contended_release trace event. This tracepoint fires on the
holder side when a contended lock is released, complementing the
existing contention_begin/contention_end tracepoints which fire on the
waiter side.
This enables correlating lock hold time under contention with waiter
events by lock address.
Add trace_contended_release()/trace_call__contended_release() calls to
the slowpath unlock paths of sleepable locks: mutex, rtmutex, semaphore,
rwsem, percpu-rwsem, and RT-specific rwbase locks.
Where possible, trace_contended_release() fires before the lock is
released and before the waiter is woken. For some lock types, the
tracepoint fires after the release but before the wake. Making the
placement consistent across all lock types is not worth the added
complexity.
For reader/writer locks, the tracepoint fires for every reader releasing
while a writer is waiting, not only for the last reader.
Dmitry Ilvokhin [Thu, 4 Jun 2026 07:15:06 +0000 (07:15 +0000)]
locking/percpu-rwsem: Extract __percpu_up_read()
Move the percpu_up_read() slowpath out of the inline function into a new
__percpu_up_read() to avoid binary size increase from adding a
tracepoint to an inlined function.
Peter Zijlstra [Wed, 10 Jun 2026 21:20:09 +0000 (23:20 +0200)]
futex: Optimize futex hash bucket access patterns
Breno reported significant c2c HITM in a futex hash heavy workload.
It turns out that the hash bucket to private hash table reverse pointer
(futex_hash_bucket::priv) was to blame. Notably when the hash buckets are
heavily contended, the: 'fph = bh->priv;' load in futex_hash() will typically
miss and consequently become quite expensive.
Since this load in particular is quite superfluous, removing it is fairly
straight forward. However, removing it does not in fact achieve anything much.
The pain moves to the next user, notably: futex_hash_put().
Therefore rework the whole private hash refcounting to avoid needing this back
pointer (and removing it). Instead of passing around 'struct futex_hash_bucket
*hb', pass around a new structure that contains it and the related 'struct
futex_private_hash *fph' pointer in tandem.
Funnily this turns out to remove more code than it adds and significantly
improves futex hash performance (as measured by 'perf bench futex hash'):
i=56: pick_task(rq_56)
pick_task_fair(rq_56)
cfs_rq->nr_queued == 0
goto idle
sched_balance_newidle(rq_56)
raw_spin_rq_unlock(rq_56)
// core-wide lock released
newidle_balance() pulls
task A: rq_57 -> rq_56
// task_rq(A) == rq_56 now
raw_spin_rq_lock(rq_56)
// core-wide lock re-acquired
return > 0
goto again
pick_task_fair(rq_56)
-> picks task A
rq_56->core_pick = task A
// first loop done
// rq_57->core_pick is still task A (set before lock release)
// but task_rq(A) == rq_56 now
next = rq_57->core_pick // = task A
put_prev_set_next_task(rq_57, prev, task A)
__set_next_task_fair(rq_57, task A)
hrtick_start_fair(rq_57, task A)
WARN_ON_ONCE(task_rq(task A) != rq_57)
// task_rq(A) == rq_56
IOW: by allowing pick_task_fair() to do newidle_balance and not returning
RETRY_TASK, it can end up selecting the same task on two CPUs. Restore the
previous state by never doing newidle when core scheduling is enabled.
Potin Lai [Thu, 11 Jun 2026 05:46:18 +0000 (13:46 +0800)]
hwmon: (pmbus/lm25066) Fix PMBus coefficients for LM5064/5066/5066i
Swap the high setting and low setting coefficients in the lm25066_coeff
table for LM5064, LM5066, and LM5066i. The coefficients were previously
mapped incorrectly, resulting in inverted current and power scaling.
Additionally, dynamically assign the exponent (R) registers inside the
probe's LM25066_DEV_SETUP_CL check. This ensures that the proper
exponent is applied (e.g., for LM25056, high setting power exponent
is -4, but low setting power exponent is -3).
Maher Sanalla [Sun, 24 May 2026 15:38:09 +0000 (18:38 +0300)]
IB/core: Delegate IB_QP_RATE_LIMIT validation to drivers
Remove IB_QP_RATE_LIMIT from the qp_state_table and instead
pass it through ib_modify_qp_is_ok() unconditionally. This
delegates rate limit attribute validation to the individual
drivers that support it.
As rate limit support expands to additional QP types and transitions
across different vendors, centralizing this policy in the core becomes
impractical. Each driver is better positioned to enforce its own
supported QP types and transitions over non-standard attributes.
Future support for non-standard attributes will be handled per vendor
driver instead of in generic IB core qp_state_table.
Maher Sanalla [Sun, 24 May 2026 15:38:08 +0000 (18:38 +0300)]
RDMA/ionic: Validate rate limit attribute in modify QP
Rate limit transition validation for RC QPs currently relies on
the IB core qp_state_table. Add a driver-level helper to validate
the rate limit attribute directly during QP modify, ensuring it
is only accepted for RC QPs in INIT->RTR, RTR->RTS and RTS->RTS
transitions.
This makes the driver responsible for rate limit validation
and prepares for a follow-up IB core change that delegates
IB_QP_RATE_LIMIT and all future non-standard modify attributes
handling to individual vendor drivers.
Maher Sanalla [Sun, 24 May 2026 15:38:07 +0000 (18:38 +0300)]
RDMA/bnxt_re: Validate rate limit attribute in modify QP
Rate limit transition validation for RC QPs currently relies on
the IB core qp_state_table. Add a driver-level helper to validate
the rate limit attribute directly during QP modify, ensuring it
is only accepted for RC QPs in INIT->RTR, RTR->RTS and RTS->RTS
transitions.
This makes the driver responsible for rate limit validation
and prepares for a follow-up IB core change that delegates
IB_QP_RATE_LIMIT and all future non-standard modify attributes
handling to individual vendor drivers.
Maher Sanalla [Sun, 24 May 2026 15:38:05 +0000 (18:38 +0300)]
RDMA/mlx5: Support deferred rate limit configuration
Allow passing a rate limit attribute in modify QP flows even when the
QP is in a state that does not support packet pacing programming in
the lower layers.
When the user sets a rate limit during a QP transition that is not to
RTS, store the value in the mlx5 QP struct and program it to FW when
the QP later transitions to RTS, which is the state that allows
configuring the rate limit index in the QP context.
Maher Sanalla [Sun, 24 May 2026 15:38:03 +0000 (18:38 +0300)]
RDMA/mlx5: Refactor raw packet QP rate limit handling
Refactor the raw packet QP modify path to extract rate limit
configuration into a qp_rl_parse() helper that parses user attributes,
and a qp_rl_prepare() helper that handles FW rate limit table
adjustments before the SQ modify itself.
Use qp_rl_commit() to commit changes to QP once FW call
succeeds, and qp_rl_rollback() to rollback changes done to
the FW rate limit table in the prepare stage, in case the
modify operation fails.
These helpers will be reused for extending rate limit support to
additional QP types in the following patch.
Kiran Kumar K [Mon, 8 Jun 2026 09:54:55 +0000 (15:24 +0530)]
octeontx2-af: fix IP fragment flag corruption on custom KPU profile load
npc_cn20k_apply_custom_kpu() overwrites KPU profile entries with custom
firmware values and then calls npc_cn20k_update_action_entries_n_flags()
over all entries. Since the same function already ran during default
profile initialisation, entries not overridden by the custom firmware
get their flags translated twice, corrupting the CN20K-specific values.
Fix this by extracting the per-entry translation into a helper
npc_cn20k_translate_action_flags() and calling it as each custom entry
is loaded, removing the redundant batch call at the end.
====================
net: shaper: follow ups to recent fixes
As discussed previously on the patch set with real fixes the xa_locking
in shapers is a little confusing, remove it. Link: https://lore.kernel.org/20260506000628.1501691-2-kuba@kernel.org
The remaining three patches are an attempt to silence AI reviewers,
I believe Sashiko was complaining about these non-issues. Not adding
Reported tags since these are false positives.
====================
Jakub Kicinski [Tue, 9 Jun 2026 18:32:24 +0000 (11:32 -0700)]
net: shaper: add a note that we expect cap dumps to be tiny
Various AI scan tools may complain that we don't support resuming
the cap dump. This is true, but the cap dumps are tiny.
net_shaper_nl_cap_pre_dumpit() sets up the dump for just
one device, so the size of the dump scales with NET_SHAPER_SCOPE_MAX (3).
We don't expect them to ever need more than a 4kB page.
Document this.
Jakub Kicinski [Tue, 9 Jun 2026 18:32:21 +0000 (11:32 -0700)]
net: shaper: drop redundant xa_lock() bracketing
The shaper insertion and update code takes xa_lock() explicitly.
Paolo explained that the locking was purely to avoid re-taking
the lock in loops. But it may be mis-read as if it was expecting
readers to be fenced off by xa_lock. Readers of XArray are purely
under RCU. Remove explicit taking of xa_lock().
All writers to hierarchy->shapers are serialized by the netdev
instance lock (or run after netdev is made inaccessible to readers).
Paolo Abeni [Thu, 11 Jun 2026 10:29:59 +0000 (12:29 +0200)]
Merge tag 'nf-26-06-10' of git://git.kernel.org/pub/scm/linux/kernel/git/netfilter/nf
Pablo Neira Ayuso says:
====================
Netfilter fixes for net
The following patchset contains Netfilter fixes for net:
1) Revalidate bridge ports, add missing NULL checks to fetch the bridge
device by the port. From Florian Westphal.
2) Fix netdevice refcount leak in the error path of nft_fwd hardware
offload function, also from Florian.
3) Unregister helper expectfn callback on conntrack helper module
removal, otherwise dangling pointer remains in place,
from Weiming Shi.
4) Fix possible pointer infoleak in getsockopt() IPT_SO_GET_ENTRIES,
From Kyle Zeng.
5) Validate that device MAC header is present before nf_syslog
accesses it. From Xiang Mei.
6-8) Three patches to address a possible infoleak of stale stack
data in three nf_tables expressions, due to mismatch in the
_init() and _eval() function which is possible since 14fb07130c7d.
From Davide Ornaghi and Florian Westphal.
netfilter pull request 26-06-10
* tag 'nf-26-06-10' of git://git.kernel.org/pub/scm/linux/kernel/git/netfilter/nf:
netfilter: nft_meta_bridge: fix stale stack leak via IIFHWADDR register
netfilter: nft_fib: fix stale stack leak via the OIFNAME register
netfilter: nft_exthdr: fix register tracking for F_PRESENT flag
netfilter: nf_log: validate MAC header was set before dumping it
netfilter: x_tables: avoid leaking percpu counter pointers
netfilter: nf_conntrack: destroy stale expectfn expectations on unregister
netfilter: nf_tables_offload: drop device refcount on error
netfilter: revalidate bridge ports
====================
Li Jun [Thu, 11 Jun 2026 01:00:45 +0000 (09:00 +0800)]
ASoC: loongson: Fix invalid position error in ls_pcm_pointer
The "invalid position" error occurred when the DMA position descriptor
returned an invalid address value (e.g., pos = -1048838144). This happened
because the `bytes_to_frames()` function returns a signed value, but when
`addr < runtime->dma_addr`, the subtraction produces a negative result that
gets interpreted as a large unsigned integer in comparisons.
when the addr is abnormal, for example,the DMA controller is abnormal in
hardware,x=0 should not be a point(x == runtime->buffer_size),but a range,
which includes the addr address being less than runtime ->dma1-adr, and
the addr exceeding the DMA address range.the value of pos should not better
a negative，return 0, maybe better.
====================
net: rds: convert rds to getsockopt_iter
This series continues the conversion of the remaining proto_ops getsockopt
callbacks to the new getsockopt_iter callback introduced in commit 67fab22a7adc ("net: add getsockopt_iter callback to proto_ops"), this time
for RDS.
RDS is a little more involved than the protocols converted so far, because
the RDS_INFO_* options snapshot kernel state directly into the destination
buffer: the info producers memcpy into the pages under a spinlock via
kmap_atomic() and so must not fault.
The conversion preserves that model — it obtains the same page array and
starting offset from opt->iter_out with iov_iter_extract_pages(),
preallocating the array so the iterator fills it in place, and leaves
the rds_info_iterator / rds_info_copy machinery and all producer
callbacks unchanged; kernel (ITER_KVEC) buffers remain unsupported on
the RDS_INFO path, as before.
I've vibe-coded a kselftest exercising both the simple options and the
RDS_INFO_* snapshot path, feel free to drop it in case this is not
useful.
Breno Leitao [Mon, 8 Jun 2026 09:44:58 +0000 (02:44 -0700)]
rds: convert to getsockopt_iter
Convert RDS socket's getsockopt implementation to use the new
getsockopt_iter callback with sockopt_t.
Key changes:
- Replace (char __user *optval, int __user *optlen) with sockopt_t *opt
- Use opt->optlen for buffer length (input) and returned size (output)
- Use copy_to_iter() instead of put_user()/copy_to_user()
The RDS_INFO_* snapshot path in rds_info_getsockopt() used to pin the
userspace buffer with pin_user_pages_fast() on the raw optval address;
the info producers then memcpy into those pages under a spinlock via
kmap_atomic() and so must not fault. Obtain the same page array and
starting offset from opt->iter_out with iov_iter_extract_pages(), which
pins for write because iter_out is ITER_DEST.
The page array is preallocated here (sized with iov_iter_npages()) and
passed in, so iov_iter_extract_pages() fills it in place rather than
allocating one for us; RDS therefore keeps ownership of the array on
every return path and frees it itself. The rds_info_iterator /
rds_info_copy machinery and all producer callbacks are unchanged.
Kernel buffers (ITER_KVEC) are not page-backed in a way the info
producers can use, so the RDS_INFO path returns -EOPNOTSUPP for them;
this matches the previous behaviour, where a kernel-buffer getsockopt
hit the WARN_ONCE() path in do_sock_getsockopt() and returned
-EOPNOTSUPP. The simple RDS_RECVERR and SO_RDS_TRANSPORT options keep
working for kernel buffers via copy_to_iter().
Breno Leitao [Mon, 8 Jun 2026 09:44:57 +0000 (02:44 -0700)]
selftests: net: rds: add getsockopt() conversion test
Add a kselftest that exercises the RDS getsockopt() paths converted to
the getsockopt_iter() / sockopt_t callback:
- RDS_RECVERR and SO_RDS_TRANSPORT, which return their int value through
copy_to_iter() and report the written length in opt->optlen.
- RDS_INFO_*, which obtains the userspace buffer pages with
iov_iter_extract_pages() (including a non-zero starting page offset)
and lets the info producers copy the snapshot in under a spinlock.
1) xfrm: iptfs: preserve shared-frag marker in iptfs_consume_frags()
Propagate SKBFL_SHARED_FRAG when paged fragments are moved between
skbs so ESP can decide whether in-place crypto is safe.
2) xfrm: iptfs: fix use-after-free on first_skb in __input_process_payload
Replace the unlocked read of xtfs->ra_newskb with a local flag so a
concurrent reassembly can no longer free first_skb between
spin_unlock and the post-loop check.
3) xfrm: policy: fix use-after-free on inexact bin in xfrm_policy_bysel_ctx()
Prune the inexact bin under xfrm_policy_lock so a concurrent
xfrm_hash_rebuild() can no longer free it before xfrm_policy_kill()
dereferences it.
4) xfrm: iptfs: fix ABBA deadlock in iptfs_destroy_state()
Move hrtimer_cancel() for the output and drop timers ahead of their
spinlocks, breaking the softirq/lock cycle that could deadlock
against the timer callbacks on SMP.
5) xfrm: espintcp: do not reuse an in-progress partial send
Fail a new send when espintcp_push_msgs() returns with emsg->len
still set, so a blocking caller can no longer overwrite ctx->partial
while a previous transfer still owns it.
6) esp: fix page frag reference leak on skb_to_sgvec failure
Add a flag to esp_ssg_unref() to unconditionally unref the source
scatterlist, releasing the old page references that are otherwise
leaked when the second skb_to_sgvec() in esp_output_tail() fails.
Please pull or let me know if there are problems.
ipsec-2026-06-10
* tag 'ipsec-2026-06-10' of git://git.kernel.org/pub/scm/linux/kernel/git/klassert/ipsec:
esp: fix page frag reference leak on skb_to_sgvec failure
xfrm: espintcp: do not reuse an in-progress partial send
xfrm: iptfs: fix ABBA deadlock in iptfs_destroy_state()
xfrm: policy: fix use-after-free on inexact bin in xfrm_policy_bysel_ctx()
xfrm: iptfs: fix use-after-free on first_skb in __input_process_payload
xfrm: iptfs: preserve shared-frag marker in iptfs_consume_frags()
====================
Ido Schimmel [Tue, 9 Jun 2026 14:54:48 +0000 (17:54 +0300)]
ipv6: Fix a potential NPD in cleanup_prefix_route()
addrconf_get_prefix_route() can return the fib6_null_entry sentinel
entry which has a NULL fib6_table pointer. Therefore, before setting the
route's expiration time, check that we are not working with this entry,
as otherwise a NPD will be triggered [1].
Note that the other callers of addrconf_get_prefix_route() are not
susceptible to this bug:
1. addrconf_prefix_rcv(): Requests a route with the 'RTF_ADDRCONF |
RTF_PREFIX_RT' flags which are not set on fib6_null_entry.
2. modify_prefix_route(): Fixed by commit a747e02430df ("ipv6: avoid
possible NULL deref in modify_prefix_route()").
3. __ipv6_ifa_notify(): Calls ip6_del_rt() which specifically checks for
fib6_null_entry and returns an error.
Fixes: 5eb902b8e719 ("net/ipv6: Remove expired routes with a separated list of routes.") Reported-by: Ji'an Zhou <eilaimemedsnaimel@gmail.com> Reviewed-by: David Ahern <dahern@nvidia.com> Signed-off-by: Ido Schimmel <idosch@nvidia.com> Link: https://patch.msgid.link/20260609145448.768318-1-idosch@nvidia.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
I noticed that so_txtime is only passing on NIPA setups which are
looped within a single host. The cross-machine cases just flat out
fail. The initial bug is obvious - the test does not deploy the binary.
But even with that I think more work would be needed to sync the
time / adjust the expectations for a dual-machine test.
Willem promised to follow up on the fundamental issues with 2-host
setups :)
Jakub Kicinski [Tue, 9 Jun 2026 18:08:02 +0000 (11:08 -0700)]
selftests: drv-net: so_txtime: remember to deploy the binaries
The test seems to be written with a single-host loopback
in mind. We need to deploy the binary to remote before
we run it. This is just fixing an obvious issue, but
more work will be needed to make the dual-host setup
work reliably. Most of the runs still fail with:
For AML devices, there are some issues where the wrong module
indentified then configure PHY failed.
The module info buffers should be initialized to 0 before the firmware
returns information. And DECLARE_PHY_INTERFACE_MASK() does not guarantee
zeroed contents, so explicitly clear the temporary interface masks before
setting supported interfaces.
Rework txgbe_identify_module() to validate module identifiers through
explicit type checks instead of relying on transceiver_type heuristics.
When using the SFP module, transceiver_type could be a random value,
because it was read from an invalid register.
====================
Jiawen Wu [Mon, 8 Jun 2026 07:08:42 +0000 (15:08 +0800)]
net: txgbe: initialize PHY interface to 0
DECLARE_PHY_INTERFACE_MASK() does not guarantee zeroed contents. Add a
new macro DECLARE_PHY_INTERFACE_MASK_ZERO(), make the stack variable to
be zeroed before setting supported interfaces.
Jiawen Wu [Mon, 8 Jun 2026 07:08:41 +0000 (15:08 +0800)]
net: txgbe: distinguish module types by checking identifier
Rework txgbe_identify_module() to validate module identifiers through
explicit type checks instead of relying on transceiver_type heuristics.
When using the SFP module, transceiver_type could be a random value,
because it was read from an invalid register.
Jiawen Wu [Mon, 8 Jun 2026 07:08:40 +0000 (15:08 +0800)]
net: txgbe: initialize module info buffer
The module info buffer should be initialized to 0 before the firmware
returns information. Otherwise, there is a risk that the buffer field
not filled by the firmware is random value.
gpio: nomadik: remove dead DB8540 code from <gpio/gpio-nomadik.h>
DB8540 support was removed in commit b6d09f780761 ("pinctrl: nomadik:
Drop U8540/9540 support"), but a couple small pieces of related code
remained in <gpio/gpio-nomadik.h>. Remove them.
Discovered while searching for CONFIG_* symbols referenced in code but
not defined in any Kconfig file.
Now that the Kconfig space always enables CONFIG_X86_TSC (on x86),
remove !CONFIG_X86_TSC code from the x86 arch code.
We still keep the Kconfig option to catch any eventual code still
pending in maintainer or non-mainline trees, plus some drivers
have raw TSC timestamping hacks that use CONFIG_X86_TSC.
It's also still possible to disable TSC support runtime.
Signed-off-by: Ingo Molnar <mingo@kernel.org> Reviewed-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Dave Hansen <dave.hansen@linux.intel.com> Cc: Ahmed S . Darwish <darwi@linutronix.de> Cc: Andrew Cooper <andrew.cooper3@citrix.com> Cc: Ard Biesheuvel <ardb@kernel.org> Cc: H . Peter Anvin <hpa@zytor.com> Cc: John Ogness <john.ogness@linutronix.de> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Link: https://lore.kernel.org/r/20250425084216.3913608-13-mingo@kernel.org
This is v5 of the earlier XDP_PASS fix. The XDP_PASS change is
retained, and the series also fixes related RX/XDP buffer handling
issues found during review.
Tested with tools/testing/selftests/drivers/net/xdp.py on mvpp2
hardware.
====================
Til Kaiser [Sun, 7 Jun 2026 13:49:43 +0000 (15:49 +0200)]
net: mvpp2: build skb from XDP-adjusted data on XDP_PASS
When an XDP program uses bpf_xdp_adjust_head() or bpf_xdp_adjust_tail()
and then returns XDP_PASS, mvpp2 still builds the skb from fixed offsets
derived from the original RX descriptor. Packet geometry changes made by
the XDP program are therefore discarded before the skb reaches the stack.
Update rx_offset and rx_bytes from xdp.data and xdp.data_end for
XDP_PASS. This makes skb_reserve() and skb_put() reflect the packet seen
by XDP, and makes RX byte accounting for XDP_PASS follow the length of the
skb passed to the network stack.
Keep a separate rx_sync_size for page-pool recycling on skb allocation
failure, which must stay tied to the received buffer range.
Non-PASS verdicts continue to account the descriptor length because no skb
is passed up in those cases.
Til Kaiser [Sun, 7 Jun 2026 13:49:42 +0000 (15:49 +0200)]
net: mvpp2: refill RX buffers before XDP or skb use
The RX error path returns the current descriptor buffer to the hardware
BM pool. That is only valid while the driver still owns the buffer.
mvpp2_rx_refill() can fail after the current buffer has been handed to
XDP or attached to an skb. In those cases mvpp2_run_xdp() may have
recycled, redirected, or queued the page for XDP_TX, and an skb free also
retires the data buffer. Returning such a buffer to BM lets hardware DMA
into memory that is no longer owned by the RX ring.
Refill the BM pool before handing the current buffer to XDP or to the
skb. If the allocation fails there, drop the packet and return the
still-owned current buffer to BM, preserving the pool depth. Once the
refill succeeds, later local drops retire/free the current buffer instead
of returning it to BM.
Fixes: 07dd0a7aae7f ("mvpp2: add basic XDP support") Fixes: d6526926de73 ("net: mvpp2: fix memory leak in mvpp2_rx") Signed-off-by: Til Kaiser <mail@tk154.de> Link: https://patch.msgid.link/20260607134943.21996-4-mail@tk154.de Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Til Kaiser [Sun, 7 Jun 2026 13:49:41 +0000 (15:49 +0200)]
net: mvpp2: limit XDP frame size to the RX buffer
mvpp2 has short and long BM pools, and short pool buffers can be smaller
than PAGE_SIZE. The XDP path nevertheless initializes every xdp_buff with
PAGE_SIZE as frame size.
XDP helpers use frame_sz to validate tail growth and to derive the hard
end of the data area. Advertising PAGE_SIZE for short buffers can let
bpf_xdp_adjust_tail() grow a packet past the real allocation, corrupting
memory or later tripping skb tailroom checks.
Initialize the XDP buffer with bm_pool->frag_size so XDP tailroom matches
the actual buffer backing the packet.
Til Kaiser [Sun, 7 Jun 2026 13:49:40 +0000 (15:49 +0200)]
net: mvpp2: sync RX data at the hardware packet offset
mvpp2 programs the RX queue packet offset, so hardware writes received
data at dma_addr + MVPP2_SKB_HEADROOM. The current CPU sync starts at
dma_addr and only covers rx_bytes + MVPP2_MH_SIZE bytes, which syncs the
unused headroom and misses the same number of bytes at the packet tail.
On non-coherent DMA systems this can leave the CPU reading stale cache
contents for the end of the received frame.
Use dma_sync_single_range_for_cpu() with MVPP2_SKB_HEADROOM as the range
offset so the sync covers the Marvell header and packet data actually
written by hardware.
Takashi Iwai [Wed, 10 Jun 2026 15:45:33 +0000 (17:45 +0200)]
ALSA: hda: Use the new helper for PCM instance refcount
HD-audio core driver has some open-code for managing the refcount for
PCM instances, and it can be replaced gracefully with the new helpers.
Only a code cleanup, no functional changes.
Takashi Iwai [Wed, 10 Jun 2026 15:45:32 +0000 (17:45 +0200)]
ALSA: core: Use the new helper for the power refcount
Replace the open code for managing the power refcount in the snd_card
object with the new helper functions.
Only a code cleanup, no functional changes.
projects / thirdparty / kernel / stable.git / log
