A collection of small fixes. Most of them are device-specific fixes
while there are a few core fixes. The continued flux, but not too
scaring yet. Some highlights below.
ALSA Core:
- Fix potential UAF after asynchronous card release
- Fix a race condition in PCM timer initialization order
USB-Audio:
- Hardening fixes for issues reported by fuzzer for 6fire, bcd2000,
and implicit FB packets
- Fix double list addition in implicit FB handling
- Quirks for AVerMedia GC553Pro and Behringer FCA1616
HD-Audio:
- Quirks / fixes for HP OmniBook 7, OMEN 15, and Victus 15 laptops
ASoC:
- Support for DAI link codec channel mask to avoid mismatches
- Fix HDMI-codec channel status change report
- Fixes for various codecs and platforms: Realtek rt712/rt721
(calibration, reset fixes), Cirrus Logic (empty EFI variable
validation, capture channel fixup), AMD ACP SoundWire (bounds
checks, refactorings), ADAU1977 (OF match table support, SPI
cleanups), ES8336 (Huawei Matebook B3-420 quirk), UX500 (macro fix)
-----BEGIN PGP SIGNATURE-----
iQJCBAABCAAsFiEEIXTw5fNLNI7mMiVaLtJE4w1nLE8FAmqrwIYOHHRpd2FpQHN1
c2UuZGUACgkQLtJE4w1nLE8WeQ//eN0ufLXXqy5U6X7kri8eM4vjRDZa5v1z8oD/
oHBdkgPmSAOJOddCVHuyPyx5BP4reBgKbukxUTBjuJvVRD4iOYfvXSW1LzVCVcly
f60rJl1/Ck3RcXfVabNV9eeGCFtAwR00U/3oH7z0eDhjwisX2F4ucAMmgxyJUKTh
pLdMPFsI/XW5CWeVbPVObGlOB8Bf/c79wy5NAnpixAkR1WaXUSLKoF5djO9qIQex
eTIknPmMYLLSfzFfO0TWY1PPRPz5qJHDr6Acer0VMTHyZF0yg2bR+gRInbM1at2H
c/lg8m899ZbobSCiHFEJdPH/W5x3iHqFi3hKVtKtQ5niot+gWTirQpjUCZ2HxNOp
5fYEyieSJ0W/t2NfNW0SP+DUOvKaIxY9VUuGCW7z/YgjW5DvSxipd2FOC4Av0s6F
l67vYazzPzf9d34NIM333FHeSZ4WMXVKKTfB34CQD93lVB1GladNA6lFFer5zuqG
Sc8q+YGUF65OZEnbslANIDvqPG0eMNlqBn/iyqXQO+P/C6oXWIlqFm4DUtM5a8wB
3Vf/e9L4mzXwKZfoW2xsJLgfpAO0faYiTAO6fr7wjBPrRl7VoenOlsCshN5GLTmM
b4bQ29LZrpk9e3e8BdGdZzT/kfQEZ31O5sawaj6f+a2JG09xCi9qxklxV5wFvZ5E
FTO+HgE=
=PnHM
-----END PGP SIGNATURE-----
Merge tag 'sound-7.3-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound
Pull sound fixes from Takashi Iwai:
"A collection of small fixes. Most of them are device-specific fixes
while there are a few core fixes. The continued flux, but not too
scaring yet. Some highlights below.
ALSA Core:
- Fix potential UAF after asynchronous card release
- Fix a race condition in PCM timer initialization order
USB-Audio:
- Hardening fixes for issues reported by fuzzer for 6fire, bcd2000,
and implicit FB packets
- Fix double list addition in implicit FB handling
- Quirks for AVerMedia GC553Pro and Behringer FCA1616
HD-Audio:
- Quirks / fixes for HP OmniBook 7, OMEN 15, and Victus 15 laptops
ASoC:
- Support for DAI link codec channel mask to avoid mismatches
- Fix HDMI-codec channel status change report
- Fixes for various codecs and platforms: Realtek rt712/rt721
(calibration, reset fixes), Cirrus Logic (empty EFI variable
validation, capture channel fixup), AMD ACP SoundWire (bounds
checks, refactorings), ADAU1977 (OF match table support, SPI
cleanups), ES8336 (Huawei Matebook B3-420 quirk), UX500 (macro
fix)"
* tag 'sound-7.3-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound: (33 commits)
ASoC: adau1977-i2c: add OF match table for I2C
ASoC: adau1977-spi: drop __maybe_unused and of_match_ptr()
ASoC: adau1977: make the Kconfig symbols user selectable
ASoC: amd: acp: fix card name length warning in SOF SoundWire machine driver
ASoC: amd: acp: fix ffs() operator precedence for SoundWire link ID
ASoC: amd: acp: refactor codec config count in SOF SoundWire machine driver
ASoC: amd: acp: bounds-check SoundWire link ID in machine drivers
ASoC: cs-amp-lib: Prevent NULL pointer if efi variable is zero length
ASoC: codecs: rt712-sdca-dmic: fix uninitialized stream_config->type
ASoC: hdmi-codec: Report a change when the channel status moves
ASoC: ux500: Parenthesize MSP_{RX,TX}_CLKPOL_BIT() arguments
ASoC: rt721: Reset codec to fix abnormal sound
ALSA: usb-audio: fix list_add double-add in push_back_to_ready_list
ALSA: hda: trace PCM open only after assigning a stream
ALSA: usb-audio: skip the broken mute control on AVerMedia GC553Pro
ALSA: hda/realtek: Enable mute LEDs on HP OmniBook 7 17-dc0xxx
ALSA: 6fire: fix OOB write from device-reported iso length
ALSA: usb-audio: Add capture quirk for Behringer FCA1616
ALSA: hda/realtek: Add mute LED quirk for HP OMEN 15-ax
ASoC: Intel: sof_es8336: Add a quirk for Huawei Matebook B3-420
...
- fix fwnode reference leak on failure in shared GPIO handling
- fix regression in OF_POPULATED logic after the unification of GPIO hog
handling between OF, ACPI and machine variants
- don't call free_irq() if no IRQ is installed in gpio-virtuser
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEkeUTLeW1Rh17omX8BZ0uy/82hMMFAmqrs8YACgkQBZ0uy/82
hMPTsw/+Jm+8Z0tuCuryhBsDwMiqS4Gnr8TahCO3aB3UyMqApkiTS+hlqWGMRWbF
Np07I4uu3ca6ohutKN/RN6K5hrjlJz6FhU1kliJ9RrK1a3bjLH4rbYoXBVsYeIpC
mjLx9lyt6RmS4RaHPV75xPEmsAdxWbMyar6SQfiZT2t96Czsrph/VggX9kMbnXt3
SgKTM5SyHrKmw4DgnQmZ4OcWt8p2edW+5DO+jxRmPlWUvYE/q91yemaedw5wBEoz
ftrvbuIr+JRKKOSugjbswwBbJ0pVUkMm+hwkyAfWSPp83aF+sm2rUB46Gkr6tfQ7
oJVqVewAV6vqW/XoAnB8vr2KO3As5HFEx8xLYZpEf9RlOIDsu8R3HOooFkvO0flP
EsQSFccdX4WEHZoSc81iJl/TJjoM2gJtBZqqOvkHr2RZ7zdKPcnW81VHJGkSyZiW
o70PMzcQ+FAu7I/o5Q+cqsw1eG68wHhRYZG0q38mJCRznjlEop9yBqCAx3yi+1mF
cIhB37FlfRkFYGXByrqUFhi9V8gHWdDTChIQFJBMx1c99mBpT/eHD2hbGmac42LP
QI4sbywoN6L3m+UJpuJwS7KoO4NtJaVN444nqnS5C8bxBGRdXV3JQHelzwhSSED9
cq+MyMQm5hjS+i6SrADGGg+PytUF9w5Z7yRq2LFNUFwcS0TaHpk=
=NiRo
-----END PGP SIGNATURE-----
Merge tag 'gpio-fixes-for-v7.3-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux
Pull gpio fixes from Bartosz Golaszewski:
- fix fwnode reference leak on failure in shared GPIO handling
- fix regression in OF_POPULATED logic after the unification of GPIO
hog handling between OF, ACPI and machine variants
- don't call free_irq() if no IRQ is installed in gpio-virtuser
* tag 'gpio-fixes-for-v7.3-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux:
gpio: virtuser: skip free_irq when no IRQ is installed
gpiolib: of: don't mark hog nodes OF_POPULATED before a chip is found
gpiolib: Put fwnode reference on failure
dcn30_apply_idle_power_optimizations() derives the MALL frame cache
hysteresis timer with
tmr_delay = (uint32_t)(div_u64(..., denom) - 64LL);
div_u64() returns a u64, so when the quotient is smaller than 64 the
subtraction wraps instead of going negative and tmr_delay ends up huge.
The loop that follows tries to squeeze it into the 6 bit register field
by doubling denom, but that only makes the quotient smaller, so tmr_delay
can never converge. tmr_scale is bumped past 3 and the function gives up
with
/* Delay exceeds range of hysteresis timer */
ASSERT(false);
even though the requested delay is too *short* to encode, not too long.
With mall_additional_timer_percent left at its default of 0, the quotient
drops below 64 once the refresh rate used for the calculation goes above
~243 Hz. Every DCN 3.0 display above that loses MALL static screen
entirely and splats a WARN once per boot. Reproduced on Navi 23
(RX 6600) driving 1920x1080, resetting /sys/kernel/debug/clear_warn_once
between modes:
refresh MALL ASSERT
144 Hz enabled no
240 Hz enabled no
280 Hz skipped yes
360 Hz skipped yes
Commit 3bb68cec4d ("drm/amd/display: Add Overflow check to skip MALL")
already covered the other end of the range, where a large stutter period
makes the delay too long to encode. Cover the short end by clamping to
0, which selects the shortest hysteresis the register can express,
65.28us * 64 = ~4.18ms. That is marginally longer than what the formula
asks for at these refresh rates, and erring long is the safe direction:
it only delays MALL entry, it can never enter early.
The numerator does not change between iterations, only denom does, so
compute it once and keep both call sites inside 100 columns.
The genuinely out of range case at very low refresh rates still reaches
the ASSERT, which is where it belongs.
Fixes: 52f2e83e2f ("drm/amdgpu/display: add MALL support (v2)")
Signed-off-by: Francis Marlou Pacaro <pacaro.francis.marlou.n@gmail.com>
Reviewed-by: Leo Li <sunpeng.li@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit 387550e53e)
amdgpu_pci_remove() calls drm_dev_unplug() before fini_sw(), so
drm_dev_enter() is already false there and the iounmap() guarded by it
is skipped. This .remove path runs on both hot-unplug and plain rmmod,
so the register BAR ioremap mapping leaks one instance per unload.
Unmap rmmio unconditionally (guard only on non-NULL) and drop the now
unused idx.
Fixes: 62d5f9f711 ("drm/amdgpu: Unmap MMIO mappings when device is not unplugged")
Signed-off-by: Chengjun Yao <Chengjun.Yao@amd.com>
Reviewed-by: Asad Kamal <asad.kamal@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit dd6f86a972)
Cc: stable@vger.kernel.org
amdgpu_amdkfd_clear_kfd_mapping() assumes that a non-NULL kfd_dev
has a fully populated node array. This is not true when KFD device
initialization fails after probe.
For example, kgd2kfd_device_init() sets num_nodes before checking
PCIe atomics support. On Polaris systems without the required atomics,
it returns before allocating nodes[0], but the kfd_dev remains attached
to the amdgpu device. A later GPU reset then dereferences nodes[0]->id.
Require the authoritative KFD initialization flag before walking the
node array, matching the existing KFD reset and teardown paths.
Fixes: 70cadefcc6 ("drm/amdgpu: unmap all user mappings of framebuffer and doorbell before mode1 reset")
Closes: https://gitlab.freedesktop.org/drm/amd/-/work_items/5833
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit 4ac1835823)
Cc: stable@vger.kernel.org
dc->clk_mgr is checked for NULL earlier in dcn50_init_hw() and
dcn60_init_hw(), but dcn50_initialize_min_clocks() and
dcn401_initialize_min_clocks() are called without any guard,
causing Smatch to report potential NULL dereferences.
Guard both call sites with the same pattern used throughout
both functions:
if (dc->clk_mgr && dc->clk_mgr->funcs)
Also fix dcn50_initialize_min_clocks() which calls
get_dispclk_from_dentist without checking the function pointer,
unlike the dcn401 equivalent which guards that call.
Fix kernel-doc in dcn60_hwseq.c by adding missing parameter descriptions
for @probe in dcn60_update_probe_status() and @type in
is_probe_measurement_type_for_hubbub().
Fixes: 7f7d7ea1fa ("drm/amd/display: Add new sources for DCN6")
Reported-by: Dan Carpenter <error27@gmail.com>
Cc: Aurabindo Pillai <aurabindo.pillai@amd.com>
Cc: Ivan Lipski <ivan.lipski@amd.com>
Cc: Dan Wheeler <daniel.wheeler@amd.com>
Cc: Roman Li <roman.li@amd.com>
Cc: Alex Hung <alex.hung@amd.com>
Cc: Tom Chung <chiahsuan.chung@amd.com>
Signed-off-by: Srinivasan Shanmugam <srinivasan.shanmugam@amd.com>
Reviewed-by: Alex Hung <alex.hung@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit 325c9a827c)
The low 6 bits of cp_hqd_eop_control store the base-2 logarithm
of the EOP ring size. This was calculated as
order_base_2(q->eop_ring_buffer_size / 4) - 1
But order_base_2 can in theory return 0, so this could underflow
(although in practice the ring buffer size cannot be less than 4096).
Change this to
order_base_2(q->eop_ring_buffer_size / 8)
using properties of logarithms.
Also add to the above comment to make the mathematics more clear.
Reviewed-by: Kent Russell <kent.russell@amd.com>
Signed-off-by: David Francis <David.Francis@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit f0f43fcf8b)
Cc: stable@vger.kernel.org
The low 6 bits of cp_hqd_eop_control store the base-2 logarithm
of the EOP ring size. This was calculated as
ffs(q->eop_ring_buffer_size / sizeof(unsigned int)) - 1 - 1
But ffs can in theory return 1 or 0, so this could underflow
(although in practice the ring buffer size cannot be less than 4096).
Change this to
ffs(q->eop_ring_buffer_size / sizeof(unsigned int) / 4)
using properties of logarithms.
Reviewed-by: Kent Russell <kent.russell@amd.com>
Signed-off-by: David Francis <David.Francis@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit 4f18c56630)
Cc: stable@vger.kernel.org
Commit eb53125a7a ("drm/amd: Add dedicated helper for
amdgpu_device_find_parent()") made amdgpu_device_gpu_bandwidth() query
the first device outside the dGPU. That is the host side of the
physical link, not the GPU side.
As a result, the ASIC and platform capability masks can both be based
on the host port. drm_amdgpu_info_device then exposes the host
capabilities to userspace, such as Gen5 x16 for a Gen4 x8 GPU.
Cache both ends of the physical link during device initialization.
Use link_dev for the GPU capability and link_partner for the platform
capability and _PR3 detection.
Reported-by: "Marek Olšák" <maraeo@gmail.com>
Closes: https://lore.kernel.org/amd-gfx/CAAxE2A4VhsAzzO1QjBjUg+NgnbD04ZzMyN6xsUJxjKJHH6hxiw@mail.gmail.com/
Suggested-by: Lijo Lazar <lijo.lazar@amd.com>
Fixes: eb53125a7a ("drm/amd: Add dedicated helper for amdgpu_device_find_parent()")
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit 7ea6a47224)
Cc: stable@vger.kernel.org
nbio_v7_9_handle_ras_controller_intr_no_bifring() dereferences ras and obj
without checking either for NULL. Both amdgpu_ras_get_context() and
amdgpu_ras_find_obj() can return NULL, e.g. during the window between
adev->nbio.ras being set (early in amdgpu_ras_init(), by design, to
enable the fatal-error interrupt as soon as possible) and the PCIE_BIF
ras object actually being created in RAS late_init. Any interrupt in that
window crashes in hard-IRQ context.
This is analogous to commit d190b459b2 ("drm/amdgpu: the warning
dereferencing obj for nbio_v7_4"), which fixed the same issue in the
nbio_v7_4 handler.
Found by Linux Verification Center (linuxtesting.org) with SVACE.
Fixes: 7692e1ee24 ("drm/amdgpu: add RAS fatal error handler for NBIO v7.9")
Reviewed-by: Tao Zhou <tao.zhou1@amd.com>
Signed-off-by: Dmitriy Chumachenko <Dmitry.Chumachenko@cyberprotect.ru>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit c7071767a5)
amdgpu_dma_buf_map() adds VRAM to the allowed domains for a peer2peer
attachment. GTT is only a fallback placement when VRAM is preferred, so
ttm_bo_validate() migrates the buffer from GTT into VRAM. While the
exporting device is runtime suspended its SDMA rings are down and the
move fails:
amdgpu: Move buffer fallback to memcpy unavailable
An importer on a second GPU reaches this holding no runtime PM
reference on the exporter, e.g. a compositor on the APU submitting a
frame that references a buffer exported by an idle dGPU:
amdgpu_cs_ioctl -> amdgpu_cs_parser_bos -> amdgpu_cs_bo_validate
-> ttm_bo_validate -> amdgpu_bo_move -> dma_buf_map_attachment
-> amdgpu_dma_buf_map -> ttm_bo_validate -> amdgpu_bo_move
Pinning a dma-buf into VRAM has the same requirement, which
commit 030631e97b ("drm/amdgpu: revert "take runtime pm reference
when we attach a buffer" v2") called out as the one case that would
need the reference back.
Take it in attach and drop it in detach. pm_runtime_get_if_active()
never resumes the device, so it cannot deadlock against the reservation
taken during resume, which is why the old pm_runtime_get_sync() had to
go. If the device is not active, clear peer2peer instead: the buffer
then stays in GTT, which remains accessible while the GPU is powered
down. If runtime PM is disabled, take a plain reference so the put in
detach stays balanced.
Fixes: 030631e97b ("drm/amdgpu: revert "take runtime pm reference when we attach a buffer" v2")
Suggested-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Mike Lothian <mike@fireburn.co.uk>
Assisted-by: Claude:Opus-5 [Claude Code]
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit 062ff15e30)
Cc: stable@vger.kernel.org
kfd_mqd_manager_v12.c (GFX 12.0) and kfd_mqd_manager_v12_1.c (GFX 12.1)
do not implement restore_mqd callbacks, leaving the function pointers
NULL and causing CRIU restore to return -EOPNOTSUPP on GFX12.
Implement restore_mqd for both compute and SDMA queues in
kfd_mqd_manager_v12.c and kfd_mqd_manager_v12_1.c, modeled after the
GFX 11 implementation with the following improvements:
- update cp_mqd_base_addr_lo/hi to the newly allocated MQD address,
fixing a pre-existing gap shared with v11 where the in-MQD copy
still pointed at the old checkpoint-time address after restore
- memset the full allocation before memcpy for compute queues to avoid
stale data in the GTT sub-allocator tail; SDMA MQDs use sizeof(*m)
since they are packed at mqd_size stride in a shared BO
checkpoint_mqd registration is deferred to a follow-up patch that also
implements get_checkpoint_info, so that checkpoint and restore are
enabled together as a complete and testable unit.
Note: GFX12.1 restore handles XCC0 only. Multi-XCC CRIU restore is
currently unreachable due to a separate validation issue in
kfd_criu_restore_queue(). A pr_warn_once() is emitted if a multi-XCC
device is encountered.
Signed-off-by: Vladimir Marioukhine <Vladimir.Marioukhine@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit b1f9601237)
Cc: stable@vger.kernel.org
[Why]
The OTG_GLOBAL_SYNC_STATUS register controls various HW IRQ sources for
the output timing generator (OTG). VUPDATE_NO_LOCK is one of them.
To enable the IRQ, driver sets the VUPDATE_NO_LOCK_EN bit in the
GLOBAL_SYNC_STATUS register.
To ack the IRQ after it fires, the driver sets the VUPDATE_NO_LOCK_CLEAR
bit in the same GLOBAL_SYNC_STATUS register.
The bit sets are done through read/modify/write operations, which are
not atomic. Thus, the following race is possible:
Thread A: IRQ handler:
*HW IRQ fires*
# IRQ disable
val = read(GLOBAL_SYNC_STATUS)
unset(val, VUPDATE_NO_LOCK_EN)
write(val, GLOBAL_SYNC_STATUS)
# ACK reads VUPDATE_NO_LOCK_EN unset
val1 = read(GLOBAL_SYNC_STATUS)
set(val1, VUPDATE_NO_LOCK_CLEAR)
# IRQ enable
val = read(GLOBAL_SYNC_STATUS)
set(val, VUPDATE_NO_LOCK_EN)
write(val, GLOBAL_SYNC_STATUS)
# BAD! clears VUPDATE_NO_LOCK_EN
write(val1, GLOBAL_SYNC_STATUS)
Regarding the tagged Fixes: change, it appears the change made this race
more likely to occur. Since VUPDATE_NO_LOCK is now the sole IRQ source
for vblank handling, a single race on high refresh panels can lead to a
time out.
[How]
The GLOBAL_SYNC_STATUS register is only one example, other IRQ control
registers also share the same scheme. On top of GLOBAL_SYNC_STATUS,
let's clean up those as well.
To keep things simple, Let's atomize the IRQ rmw ops via a single
driver-wide spinlock. Due to the small scope of this lock, it is
unlikely to cause noticeable overhead on top of all the existing locking
within the IRQ set/handle paths.
Since DM is responsible for locking, wrap dc_interrupt_set/ack with the
spinlock in the new amdgpu_dm_irq_set/ack functions. Migrate/drop all
references in DM to dc_interrupt_set/ack to use amdgpu_dm_irq_set/ack
instead.
Closes: https://gitlab.freedesktop.org/drm/amd/-/work_items/5616
Fixes: c87e6635d2 ("drm/amd/display: consolidate DCN vblank/flip handling onto vupdate_no_lock")
Reviewed-by: Mario Limonciello <mario.limonciello@amd.com>
Signed-off-by: Leo Li <sunpeng.li@amd.com>
Signed-off-by: Chenyu Chen <chen-yu.chen@amd.com>
Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit 70de0a0216)
Cc: stable@vger.kernel.org
add energy accumulator on pmfw 0x00685000 and above version.
Signed-off-by: Kevin Wang <kevin.wang@amd.com>
Reviewed-by: Kenneth Feng <kenneth.feng@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit 4aa733ab15)
Matthieu Baerts says:
====================
mptcp: misc fixes for v7.3-rc4
Here are two unrelated fixes:
- Patch 1: avoid unneeded actions on subflow reset. A fix for another
fix introduced in v6.12 and targeting a commit from v5.7.
- Patch 2: close a possible race when scheduling a closing path. A fix
for another fix introduced in v6.0 and targeting v5.10.
- Patch 3: fix bad accounting when __subflow_push_pending returns an
error. A fix for v6.6.
====================
Link: https://patch.msgid.link/20260917-net-mptcp-misc-fixes-7-3-rc4-v2-0-0cf5c72667c8@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
If __subflow_push_pending() errors out we should avoid updating the
copied byte counters, to avoid mismatch push call later on.
Fixes: 0fa1b3783a ("mptcp: use get_send wrapper")
Cc: stable@vger.kernel.org
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Reviewed-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Link: https://patch.msgid.link/20260917-net-mptcp-misc-fixes-7-3-rc4-v2-3-0cf5c72667c8@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The mptcp scheduler may race with subflow sockets state change: data
transmission on the selected socket may fail and a later release could
try to use mss_now reset to 0 for a divide operation.
Address the issue by explicitly checking for the critical scenario.
Fixes: c886d70286 ("mptcp: do not queue data on closed subflows")
Cc: stable@vger.kernel.org
Reported-by: Shardul Bankar <shardul.b@mpiricsoftware.com>
Reported-by: Xinyang Ge <xinyang@anthropic.com>
Closes: https://lore.kernel.org/20260525194828.1137119-1-shardul.b@mpiricsoftware.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Reviewed-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Link: https://patch.msgid.link/20260917-net-mptcp-misc-fixes-7-3-rc4-v2-2-0cf5c72667c8@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Once in a blue moon, the mptcp receive path can recursively call
mptcp_data_ready() via state change under unlucky error conditions, and
then try to hold the data lock again.
Break the recursion loop explicitly checking for the exceptional
condition.
Add a new flag instead of using an existing one like 'closing', to exit
early in subflow_state_change(), and explicitly flush the RX queue at
reset time.
This avoids unneeded processing to check for available data -- calling
get_mapping_status() and more on a dying subflow -- but also in error
reporting and worker scheduling.
Note that we must consume the currently peeked skb before invoking
mptcp_dss_corruption to avoid consuming it again after the eventual
reset has freed it.
Fixes: e32d262c89 ("mptcp: handle consistently DSS corruption")
Cc: stable@vger.kernel.org
Reported-by: Xinyang Ge <xinyang@anthropic.com>
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Reviewed-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Link: https://patch.msgid.link/20260917-net-mptcp-misc-fixes-7-3-rc4-v2-1-0cf5c72667c8@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
A few fixes for the DMA-mapping code:
- resolved regression in accessing encrypted memory by IOMMU-backed
devices (Aneesh Kumar K.V),
- improved failure handling and removed rare bug in swiotlb/highmem
(Donggeun Yoo).
-----BEGIN PGP SIGNATURE-----
iHUEABYKAB0WIQSrngzkoBtlA8uaaJ+Jp1EFxbsSRAUCaquwMwAKCRCJp1EFxbsS
RMT6AP0elpdaZXNY0KwUBTwU95H604J+donqriepHABIBhIDEQD9GWZqNf/m1gEI
tR5lHQ3+NGs0Q7Vd2ed1vSe82HQSsgU=
=QxUC
-----END PGP SIGNATURE-----
Merge tag 'dma-mapping-7.3-2026-09-17' of git://git.kernel.org/pub/scm/linux/kernel/git/mszyprowski/linux
Pull dma-mapping fixes from Marek Szyprowski:
"A few fixes for the DMA-mapping code:
- resolved regression in accessing encrypted memory by IOMMU-backed
devices (Aneesh Kumar K.V)
- improved failure handling and removed rare bug in swiotlb/highmem
(Donggeun Yoo)"
* tag 'dma-mapping-7.3-2026-09-17' of git://git.kernel.org/pub/scm/linux/kernel/git/mszyprowski/linux:
x86/mm: Don't force unencrypted DMA for IOMMU-backed devices
dma-mapping: don't trace the DMA address when the allocation fails
swiotlb: use the adjusted address for the highmem page lookup
dma-coherent: report a failed reserved memory assignment
An rmnet device may be created with its real device in a different
netns than the rmnet device itself (rmnet_newlink() resolves it in
link_net), and the config paths below only check CAP_NET_ADMIN against
dev_net(dev), while mutating rmnet port state attached to the real
device:
- rmnet_changelink() rewrites the endpoint mux table and
port->data_format and, via rmnet_vnd_update_dev_mtu(), can shrink the
MTU of the rmnet endpoint netdevs.
- rmnet_add_bridge() and rmnet_del_bridge(), reachable via
ndo_add_slave/ndo_del_slave through RTM_SETLINK IFLA_MASTER, flip
port->rmnet_mode and port->bridge_ep on the real device's port; with
bridge_ep pointing at a caller-owned device, rmnet_rx_handler() then
forwards real-device ingress frames to it.
- rmnet_set_coalesce() rewrites the port aggregation parameters via
ETHTOOL_SCOALESCE (ioctl) or ETHTOOL_MSG_COALESCE_SET (netlink),
whose capability checks likewise only cover dev's netns.
A caller privileged only in the rmnet device's netns can therefore
rewrite the shared cellular data-path state owned by another netns, and
steer its ingress traffic.
Gate the rtnl paths with rtnl_dev_link_net_capable(), matching the
"require CAP_NET_ADMIN in the device netns for changelink" series
(vxlan/geneve, CVE-2026-68432), and gate the ethtool setter with
ns_capable() in the real device netns, mirroring the check dev_ethtool()
already applies to dev's netns. Report the new rejections through
extack where one is available.
The gates cover the configuration paths only. Teardown (RTM_DELLINK
reaching rmnet_dellink(), and rmnet_config_notify_cb() unregistering
the bridge when the slave device is deleted) is intentionally left
ungated: link deletion is normal netdev lifecycle behaviour, and the
changelink series this matches (vxlan/geneve, CVE-2026-68432) gated
only the configuration paths.
Reviewed-by: Simon Horman <horms@kernel.org>
Signed-off-by: Abdifatah Suruur <suruurism@gmail.com>
Reviewed-by: Subash Abhinov Kasiviswanathan <subash.a.kasiviswanathan@oss.qualcomm.com>
Link: https://patch.msgid.link/20260915195642.1912-1-suruurism@gmail.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Currently netlink-raw.yaml contains two if keys and two then keys in a
single mapping that enforces a "len" for "pad" members and a "len" or
"struct" for binary members.
During validation PyYAML resolves duplicate keys last-wins, so only the
binary rule survives. Pad has not been validated since commit
bf08f32c8c ("tools/net/ynl: Add support for nested structs") added
the second if/then pair in January 2024.
None of the current specs violate this rule, but this validation should
not be parser dependent and unspecified. Strict YAML validators such as
Red Hat's VS Code YAML extension and Adrien Verge's yamllint will
reject the netlink-raw.yaml schema:
Command:
$ yamllint Documentation/netlink/netlink-raw.yaml
Output:
185:13 error duplication of key "if" in mapping (key-duplicates)
189:13 error duplication of key "then" in mapping (key-duplicates)
The following invalid netlink family spec will pass validation in the
current ynl tooling:
# SPDX-License-Identifier: ((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause)
---
name: minimal-raw
doc: Minimal netlink-raw family for schema validation testing.
protocol: netlink-raw
protonum: 0
definitions:
-
name: test-struct
type: struct
members:
-
name: reserved
type: pad
# len intentionally omitted
attribute-sets: []
operations:
list: []
Signed-off-by: Taylor Bates <tmbates12@gmail.com>
Reviewed-by: Hangbin Liu <liuhangbin@kylinos.cn>
Reviewed-by: Donald Hunter <donald.hunter@gmail.com>
Link: https://patch.msgid.link/20260914-ynl-robustness-v2-1-c6125003b21e@gmail.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
pskb_carve_inside_header() and pskb_carve_inside_nonlinear() remove
the first bytes of a packet and reallocate skb->head.
All the headers that were present before the operation are gone,
but both functions call skb_headers_offset_update(skb, 0), which
is a no-op : skb->mac_header, skb->network_header,
skb->transport_header and skb->csum_start keep their old values and
now describe bytes which are no longer there.
Both helpers size the new head from the old skb_end_offset(), so the
stale offsets still land inside the new allocation. They point past
skb_tail_pointer() though, to bytes that were never initialized.
pskb_carve_inside_nonlinear() is the worst case, because it leaves a
zombie skb with an empty linear part (skb->data ==
skb_tail_pointer(skb), skb_headlen(skb) == 0), while
skb_mac_header_was_set() is still true and skb->mac_header is way
ahead of skb->data.
The only user of pskb_extract() is rds_tcp_data_recv(), and the
carved skb is queued on tinc->ti_skb_list. When the RDS incoming
message is released, rds_tcp_inc_free() calls skb_queue_purge(),
which frees the skbs with SKB_DROP_REASON_QUEUE_PURGE. This is
visible from drop_monitor, which then tries to pull back to the
(bogus) mac header :
skbuff: __skb_pull(len=234)
skb len=6968 data_len=6968 headroom=0 headlen=0 tailroom=0
end-tail=384 mac=(234,14) mac_len=14 net=(248,40) trans=288
shinfo(txflags=0 nr_frags=1 gso(size=1428 type=16 segs=5))
csum(0x100120 start=288 offset=16 ip_summed=3 complete_sw=0 valid=1 level=0)
hash(0x7b446c6c sw=0 l4=1) proto=0x86dd pkttype=0 iif=60
kernel BUG at ./include/linux/skbuff.h:2847!
Add skb_carve_reset_headers() to mark the mac and transport headers
as not set, reset the network header, clear skb->mac_len, and drop
a now meaningless CHECKSUM_PARTIAL (csum_start no longer describes
anything).
Invalidate the inner offsets as well. Unlike mac_header and
transport_header they have no "unset" sentinel, so a leftover
non-zero value still looks like a real header. Zero
skb->inner_mac_header, skb->inner_network_header,
skb->inner_transport_header, skb->inner_protocol and
skb->encapsulation, so that all the header state is invalidated in
one place.
v2: fixed an inaccurate changelog. The stale offsets stay inside the
new skb->head, which is never smaller than the old one, they
simply point past skb_tail_pointer() to bytes that are gone.
Thanks to Xuanqiang Luo for insisting on this.
Also invalidate the inner header state, as suggested by the
netdev AI review :
https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260911114922.621937-1-edumazet%40google.com
Fixes: 6fa01ccd88 ("skbuff: Add pskb_extract() helper function")
Reported-by: syzbot+586af68eb819833c2d91@syzkaller.appspotmail.com
Closes: https://lore.kernel.org/netdev/6aa3e9d3.f2639fcc.29487d.0028.GAE@google.com/
Cc: Xuanqiang Luo <xuanqiang.luo@linux.dev>
Cc: Allison Henderson <achender@kernel.org>
Cc: rds-devel@oss.oracle.com
Signed-off-by: Eric Dumazet <edumazet@google.com>
Reviewed-by: Xuanqiang Luo <luoxuanqiang@kylinos.cn>
Link: https://patch.msgid.link/20260915130423.3956471-1-edumazet@google.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Introduce the following new tests: `ipv4_verify_same_scope_addr_order`,
`ipv4_verify_inter_scope_addr_order`, `ipv6_verify_same_scope_addr_order`,
`ipv6_verify_inter_scope_addr_order` to check the ordering of a
set of IP addresses after being inserted.
The implementations of these protocols are inconsistent
in regard to address ordering. IPv4 addresses stay in the
same order as inserted while IPv6 addresses appear in
reverse order. This inconsistency has prompted attempts
to unify the ordering, so both protocols act the same
(as IPv4). This however caused user-space regressions in
certain applications, which relied on the order as it
was prior to the change (particularly NetworkManager).
A similar inconsistency occurs when inserting different
scope addresses, where IPv4 puts link local ones before global
and IPv6 does the opposite. Attempts were already made
to unify this also, risking further regressions.
The addition of these tests aims to consolidate current
behaviour to prevent regressions in the future.
The expected behaviour is the initial one, where each
protocol acts differently. The same goes for inter scope
addresses.
Conversations detailing the decision processes for creating
these tests are linked below.
Link: https://lore.kernel.org/netdev/20260521135310.GC977@cmadams.net/
Link: https://lore.kernel.org/netdev/20260529112357.5079-1-fmancera@suse.de/
Link: https://lore.kernel.org/netdev/20260721090114.GA2510713@shredder/
Suggested-by: Fernando Fernandez Mancera <fmancera@suse.de>
Signed-off-by: Martin Jabůrek <martin.jaburek@suse.com>
Reviewed-by: Fernando Fernandez Mancera <fmancera@suse.de>
Link: https://patch.msgid.link/20260914065848.10518-1-martin.jaburek@suse.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
IPV6_FREEBIND and IPV6_TRANSPARENT still take the socket lock despite
using inet_assign_bit() to update the flags shared with IP_FREEBIND
and IP_TRANSPARENT. IPv6 TCP and UDP sockets can already update these
flags without the lock through the corresponding SOL_IP options.
Move both options to the lockless setsockopt path.
Signed-off-by: Xuanqiang Luo <luoxuanqiang@kylinos.cn>
Reviewed-by: Hangbin Liu <liuhangbin@kylinos.cn>
Link: https://patch.msgid.link/20260912134040.215664-1-xuanqiang.luo@linux.dev
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Add a packetdrill test for an in-sequence data segment carrying an
excessively old ACK.
Verify that the segment falls through from the TCP fast path to the slow
path, where the existing ACK validation rejects it and sends a challenge
ACK. The payload is not accepted and RCV.NXT remains unchanged.
Based on the reproducer from Commit 3d501dd326
("tcp: do not accept ACK of bytes we never sent").
Signed-off-by: Inbal Schussheim <inbal.lipshtat@mail.huji.ac.il>
Reviewed-by: Eric Dumazet <edumazet@google.com>
Link: https://patch.msgid.link/20260914090408.1435080-3-inbal.lipshtat@mail.huji.ac.il
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Exclude old ACKs before SND.UNA from the tcp fast path
as well as ACKs after SND.NXT.
Such ACKs will fall through to the slow path, where tcp_ack()
performs the appropriate validation and challenge ACK handling
according to RFC5961 and Commit 3d501dd326 ("tcp: do not
accept ACK of bytes we never sent").
This prevents old ACKs from being accepted
or modifying connection state as part of the fast path before
appropriate ACK validation is applied.
In particular, this prevents payload carried by a segment with
an excessively old ACK from advancing RCV.NXT before the ACK
is rejected.
Fixes: 31770e34e4 ("tcp: Revert "tcp: remove header prediction"")
Reported-by: Amit Klein <amit.klein@mail.huji.ac.il>
Reported-by: Tamir Shahar <tamir.shahar1@mail.huji.ac.il>
Reported-by: Inbal Schussheim <inbal.lipshtat@mail.huji.ac.il>
Suggested-by: Eric Dumazet <edumazet@google.com>
Cc: stable@vger.kernel.org
Signed-off-by: Inbal Schussheim <inbal.lipshtat@mail.huji.ac.il>
Reviewed-by: Eric Dumazet <edumazet@google.com>
Link: https://patch.msgid.link/20260914090408.1435080-2-inbal.lipshtat@mail.huji.ac.il
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
dpll_pin_ref_sync_state_set() resolves the partner's driver private data
with dpll_pin_on_dpll_priv() and passes the result to ref_sync_get() and
ref_sync_set() without looking at it. The helper returns NULL when the
partner holds no ref on that dpll. Of the two drivers implementing the
feature only zl3073x dereferences the pointer (sync_pin->id); ice ignores
it, so ice cannot fault here.
The NULL is a teardown race, not a steady state - zl3073x registers every
input pin with every channel, so the partner is normally present on the
dpll the base pin resolves to. zl3073x_dev_stop() unregisters pins one at
a time, taking and dropping dpll_lock for each, and between the partner's
turn and the base pin's the partner is out of that dpll's pin_refs while
still registered with the channels not yet torn down, so
dpll_pin_available() keeps passing. That path is not only driver removal:
devlink reload and devlink dev flash both run zl3073x_dev_stop().
Reproduced by holding that state open with a mock dpll device, which is
where the frame name comes from:
BUG: kernel NULL pointer dereference, address: 0000000000000000
Oops: Oops: 0000 [#1] SMP NOPTI
RIP: 0010:mock_ref_sync_get+0x5/0x30
Call Trace:
<TASK>
dpll_pin_ref_sync_set+0x19f/0x4a0
dpll_nl_pin_set_doit+0x17d/0x840
genl_family_rcv_msg_doit+0xd6/0x130
genl_rcv_msg+0x181/0x2b0
netlink_rcv_skb+0x55/0x100
genl_rcv+0x23/0x30
netlink_unicast+0x24d/0x370
netlink_sendmsg+0x1e2/0x420
__sys_sendto+0x1db/0x1f0
__x64_sys_sendto+0x1f/0x30
do_syscall_64+0xe1/0x490
Commit d2e914a4a0 ("dpll: fix NULL pointer dereference in
dpll_msg_add_pin_ref_sync()") added the same guard to the read side, which
the kernel walks into by itself because the delete notification is emitted
from inside the unregister; the write side needs a pin-set to land in the
window and was left alone. Test the priv rather than look up pin_refs
directly, so that the two halves key off the same condition.
Fixes: 58256a26bf ("dpll: add reference sync get/set")
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Reviewed-by: Ivan Vecera <ivecera@redhat.com>
Link: https://patch.msgid.link/20260915213047.1352286-1-kuba@kernel.org
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
The per‑processor buffering scheme is supported only if the
number of pools (nrxqs * 2) does not exceed MVPP2_BM_MAX_POOLS (8).
This is already checked in mvpp2_probe() during the initial
activation of percpu_pools.
However, mvpp2_change_mtu() may later call
mvpp2_bm_switch_buffers(priv, true) without this check, which can
lead to an out-of-bounds access in the priv->page_pool array in
mvpp2_bm_init(). The array is sized to hold MVPP2_PORT_MAX_RXQ
entries, and mvpp2_get_nrxqs() may return exactly that value. The
per-CPU scheme then doubles it to nrxqs * 2, exceeding the array
bounds.
Check that the hardware version is MVPP22 or newer and that the
number of pools (nrxqs * 2) does not exceed MVPP2_BM_MAX_POOLS
before switching to per-CPU mode.
Found by Linux Verification Center (linuxtesting.org) with SVACE.
Fixes: 7d04b0b13b ("mvpp2: percpu buffers")
Signed-off-by: Dmitriy Okunev <dokunevdmitriy@gmail.com>
Link: https://patch.msgid.link/20260914091557.71769-1-dokunevdmitriy@gmail.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
PTP_SYS_OFFSET_EXTENDED returns system timestamps that do not correctly
bracket the PHC register read on MACB/GEM. On a Raspberry Pi 5, the
returned interval can be as short as 37 ns, while an ordered register
read takes approximately 1 us. This biases the midpoint used by phc2sys,
causing CLOCK_REALTIME to run approximately 0.5 us ahead when synchronized
to the PHC.
gem_tsu_get_time() reads the nanoseconds register using the driver's
relaxed MMIO accessor. On weakly ordered systems, the subsequent system
timestamp can be taken before the register read completes. The internal
smp_rmb() in the pre-timestamp path also does not guarantee ordering
against the subsequent MMIO read.
Add rmb() before and after the bracketed nanoseconds read in both the
normal and seconds rollover paths so the system timestamps bracket the
PHC read. Adding the post-read barrier increases the minimum interval on
the same Raspberry Pi 5 to approximately 1 us.
Fixes: e51bb5c278 ("net: macb: ptp: Switch to gettimex64() interface")
Tested-by: Nicolai Buchwitz <nb@tipi-net.de> # Raspberry Pi CM5, min bracket 37 ns -> 981 ns
Reviewed-by: Nicolai Buchwitz <nb@tipi-net.de>
Reviewed-by: Théo Lebrun <theo.lebrun@bootlin.com>
Assisted-by: LLM
Signed-off-by: James Clark <jjc@jclark.com>
Link: https://patch.msgid.link/20260915045823.76100-1-jjc@jclark.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Set the internal port TSO limit to GSO_MAX_SIZE (512 KB), as for
loopback and veth. This allows the admin/user to set a GSO limit up to
this value, to use BIG TCP for traffic routed through the internal port.
Only the capability limit changes: the IPv4 and IPv6 GSO and GRO limits
remain at 64 KiB until changed by the administrator.
Validation used a same-host test with a temporary OVS bridge, a veth pair,
and a network namespace:
TCP client -> OVS internal -> OVS bridge -> veth -> TCP server
The veth endpoints were BIG TCP capable throughout the test, and only the
OVS internal port limits changed between 64 KiB and 524280 bytes. A single
iperf3 3.19 TCP flow, run separately over IPv4 and IPv6 with six
alternating runs per state (`-t 15 -O 5`, fixed CPU affinity and port
tuple), increased throughput by 18.1% for IPv4 and 34.7% for IPv6:
protocol BIG TCP off BIG TCP on CV off / on
TCP/IPv4 65.567 Gbps 77.420 Gbps 1.12% / 0.37%
TCP/IPv6 55.355 Gbps 74.568 Gbps 1.20% / 0.68%
Assisted-by: LLM
Signed-off-by: Wang Zhan <wang.zhan@smartx.com>
Reviewed-by: Ilya Maximets <i.maximets@ovn.org>
Reviewed-by: Eelco Chaudron <echaudro@redhat.com>
Link: https://patch.msgid.link/20260916065844.1380155-1-wang.zhan@smartx.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
LOLLM noticed that the inode btree root formatting methods copy too many
bytes -- there's only one set of keys in node blocks, not two. This
causes memory corruption of whatever's beyond the buffers.
Cc: stable@vger.kernel.org # v6.14
Fixes: f0415af60f ("xfs: wire up a new metafile type for the realtime refcount")
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Assisted-by: LOLLM # finding obvious bugs
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Carlos Maiolino <cem@kernel.org>
LOLLM points out that if the amount of fdblocks that we can reserve for
a metadata btree file goes below the space already used by that file,
then the hidden_space subtraction can underflow, causing
xfs_dec_fdblocks to subtract a huge amount of space. We never want the
target to be less than the used sapce, so fix the logic that adjusts
dblocks_avail downwards.
Also fix an error in the adjacent comment.
Cc: stable@vger.kernel.org # v6.15
Fixes: 1df8d75030 ("xfs: make metabtree reservations global")
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Assisted-by: LOLLM # finding obvious bugs
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Carlos Maiolino <cem@kernel.org>
LOLLM noticed that xfs_qm_flush_one fails to drop the dquot flush lock
if it can't grab the buffer associated with the dquot. Since there's no
buffer, nobody else is going to drop the dqflock, so we need to do it
ourselves.
Cc: stable@vger.kernel.org # v6.13
Fixes: ca378189fd ("xfs: convert quotacheck to attach dquot buffers")
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Assisted-by: LOLLM # finding obvious bugs
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Carlos Maiolino <cem@kernel.org>
LOLLM pointed out a bug in xlog_recover_iunlink_bucket:
1. We don't null out prev_ip after releasing it, which can lead to UAF
problems if the inodegc flush call in the loop fails.
at which point I noticed even more bugs:
2. If the inodegc flush inside the loop fails, we also leak @ip.
3. We set prev_agino to agino having already advanced agino, which
results in inodes with i_prev_unlinked set to itself.
4. If we exit the bottom of the loop with prev_ip set, then prev_ip
aliases ip and we also set its i_prev_unlinked to itself.
Bugs 3 and 4 introduce loops into the unlinked list, though these loops
don't surface because we immediately flush each unlinked inode after
loading it.
Fix all of these issues.
Cc: stable@vger.kernel.org # v6.0
Fixes: 04755d2e58 ("xfs: refactor xlog_recover_process_iunlinks()")
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Assisted-by: LOLLM # finding obvious bugs
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Carlos Maiolino <cem@kernel.org>
LOLLM noticed the copy-paste error here -- if user quotas aren't
enforced but we're near the group quota limit, we fail to set FLAG_GID
and hence we might not actually free any preallocations, causing
unnecessary EDQUOT. Fix that.
Cc: stable@vger.kernel.org # v5.12
Fixes: c237dd7c70 ("xfs: flush eof/cowblocks if we can't reserve quota for inode creation")
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Assisted-by: LOLLM # finding obvious bugs
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Carlos Maiolino <cem@kernel.org>
LOLLM noticed that we can accidentally merge file range health
monitoring events even if they have different errors. We shouldn't do
that.
Cc: stable@vger.kernel.org # v7.0
Fixes: dfa8bad3a8 ("xfs: convey file I/O errors to the health monitor")
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Assisted-by: LOLLM # finding obvious bugs
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Carlos Maiolino <cem@kernel.org>
LOLLM complains that a memory allocation failure in
xrep_newbt_add_blocks results in online repair leaking blocks that were
previously allocated to write a new btree, but the problem is worse than
that -- a limitation of the codebase is that the callers cannot undo the
transaction /and/ return the error -- either you undo all changes and
commit the transaction, or you error out and the filesystem goes down.
However, the new btree space reservation object isn't that big (~48
bytes). Let's just do a NOFAIL allocation and the problem goes away.
Cc: stable@vger.kernel.org # v6.8
Fixes: be40841763 ("xfs: implement block reservation accounting for btrees we're staging")
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Assisted-by: LOLLM # finding obvious bugs
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Carlos Maiolino <cem@kernel.org>
LOLLM points out that runtime errors (e.g. ENOMEM) when we're trying to
compute space usag bitmaps are silently dropped by the rmapbt scrubber.
We ought to flag that as an incomplete scrub instead of reporting
cross-referencing errors based on faulty data.
Cc: stable@vger.kernel.org # v6.4
Fixes: fed050f345 ("xfs: cross-reference rmap records with ag btrees")
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Assisted-by: LOLLM # finding obvious bugs
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Carlos Maiolino <cem@kernel.org>
When I added online fsck for realtime reflink, I forgot to update
xrep_calc_rtgroup_resblks to factor in the size of the refcount btree
when it guesses how much space we need to start a repair. This hasn't
been a huge problem in practice because there are few filesystems with
(a) realtime, (b) rtgroups, (c) reflink, and (d) no rmap. But let's fix
this before someone stumbles upon it, especially since LOLLM flagged
this for me.
Cc: stable@vger.kernel.org # v6.14
Fixes: 83ccffc489 ("xfs: online repair of the realtime refcount btree")
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Assisted-by: LOLLM # finding obvious bugs
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Carlos Maiolino <cem@kernel.org>
Now that we have quotas for the realtime volume, we also have
precomputed watermark limits for the realtime block counts. These
precomputations should be done any time we change the rtb limits, which
means that xfs_qm_adjust_dqlimits needs to ensure that if we installed
a default rtb limit.
Cc: stable@vger.kernel.org # v6.13
Fixes: 5dd70852b0 ("xfs: create quota preallocation watermarks for realtime quota")
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Carlos Maiolino <cem@kernel.org>
Use an additional label so that a bit of exception handling can be better
reused at the end of this function implementation.
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
Reviewed-by: Simon Horman <horms@kernel.org>
Link: https://patch.msgid.link/15f151c7-58c8-4116-8a03-e985fd132b0f@web.de
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
When using eBPF to probe CS CALL instructions within a function,
a crash can be triggered.
The eBPF tool probes offset 257 of the __hrtimer_run_queues()
function:
<__hrtimer_run_queues+249>: nopl 0x0(%rax,%rax,1)
<__hrtimer_run_queues+254>: mov %r14,%rdi
<__hrtimer_run_queues+257>: cs call <__x86_indirect_thunk_r12>
<__hrtimer_run_queues+263>: mov %eax,%r12d
<__hrtimer_run_queues+266>: xchg %ax,%ax
<__hrtimer_run_queues+268>: mov %r13,%rdi
Which triggers this crash:
BUG: unable to handle page fault for address: 00000000000f41c9
#PF: supervisor write access in kernel mode
#PF: error_code(0x0002) - not-present page
PGD 0 P4D 0
Oops: 0002 [#1] SMP NOPTI
CPU: 1 PID: 0 Comm: swapper/1 Kdump: loaded Tainted: P
RIP: 0010:__hrtimer_run_queues+0x106/0x230
Note that __hrtimer_run_queues+0x106 is __hrtimer_run_queues+262, which is
at the 6th byte of the above CS CALL instruction. Since the CS CALL
instruction occupies 6 bytes, the exception occurred in the middle of that
call instruction.
The root cause is that when using eBPF tools to probe in the middle of a
function, a kprobe with INT3 is used as the underlying implementation.
During single-step emulation of the original CALL instruction,
int3_emulate_call() assumes that the probed CALL instruction is 5 bytes
long. However, the actual CS-prefixed CALL instruction occupies 6 bytes,
so it constructs an incorrect exception return address. When the CPU
returns from the kprobe handler, the next instruction to be executed is at
the address of the last byte of that CS CALL instruction. Coincidentally,
starting from that address, the CPU fetches and decodes a completely
different instruction, which ultimately triggers a kernel crash.
Fix the issue by using the actual instruction length obtained from
the instruction decoder when constructing the exception return
address, rather than relying on the hardcoded CALL_INSN_SIZE macro.
[ mingo: Refined the changelog ]
Fixes: 6256e668b7 ("x86/kprobes: Use int3 instead of debug trap for single-step")
Suggested-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
Signed-off-by: Jinke Han <jinkehan@didiglobal.com>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Reviewed-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
Acked-by: Yafang Shao <laoar.shao@gmail.com>
Acked-by: Borislav Petkov <bp@alien8.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Link: https://patch.msgid.link/20260908073742.GA10517@didi-ThinkCentre-M920t-N000
After commit 860e748bdd ("drm: ensure blend mode supported if pixel
format with alpha exposed") we get warnings at boot:
loongson 0000:00:06.1: [drm] [PLANE:41:ls-cursor-plane-0] pixel format with alpha exposed but blend mode not setup. Please fix.
loongson 0000:00:06.1: [drm] [PLANE:46:ls-cursor-plane-1] pixel format with alpha exposed but blend mode not setup. Please fix.
The reason is the cursor plane supports color formats with alpha but the
driver doesn't create blend mode property, which triggers the warning in
validate_blend_mode_for_alpha_formats().
The loongson DC HW doesn't support DRM_MODE_BLEND_PREMULTI, so create
blend mode property with DRM_MODE_BLEND_COVERAGE for cursor planes since
it is the only one implemented in the driver.
Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
Reviewed-by: Jianmin Lv <lvjianmin@loongson.cn>
Signed-off-by: Icenowy Zheng <zhengxingda@iscas.ac.cn>
Link: https://patch.msgid.link/20260903084212.3621540-1-chenhuacai@loongson.cn
A relatively large pile of fixes here, a lot of driver specific stuff
that's broadly unremarkable plus a few core fixes from Richard that fix
issues where SoundWire systems with multiple CODECs on the same link
would configure the CODECs to use the same bus slots leading to broken
audio.
-----BEGIN PGP SIGNATURE-----
iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAmqrCNoACgkQJNaLcl1U
h9DHWgf8D3dIL06bqj6IoyMLCFNrcQ8BYbWUeWNu5YE0vP29ybdpYidTxJFjqF2t
TUB8fTO2u3LvfKIIgOSVyXN84i7/4EwtDjBz1iVzGhm0/2ZfEOitO2LtUvhCHiZi
+JnEOXdwa7wM9jv0On6B81r8+vXj7FaNmq/TnLbUU3R/DeaRx571k913lazZSRb0
cfPj1FGMUvpfBZ7DC011yEufDD4C8qVaktV6IpRqeBAxks1vmXQX7Lt78gJCxvQt
w8Uu2T8FpiTuYvObI7KW7IZr01IQtPpJ4N9ekUMuBfOqkjvG+XOETM2aEWg7q9Jk
Qu5GfyB2LIav4/On4pCxwJGaJiUavQ==
=IMNO
-----END PGP SIGNATURE-----
Merge tag 'asoc-fix-v7.3-rc3' of https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus
ASoC: Fixes for v7.3
A relatively large pile of fixes here, a lot of driver specific stuff
that's broadly unremarkable plus a few core fixes from Richard that fix
issues where SoundWire systems with multiple CODECs on the same link
would configure the CODECs to use the same bus slots leading to broken
audio.
Daniel Zahka says:
====================
net: psp: avoid conflicts with skb->decrypted and sk_validate_xmit_skb()
Sashiko's review of commit da630d1da2 ("netdevsim: psp: drop tx key
ops") [1] showed that there is a hazard between PSP and offloaded TLS,
where both can clobber what the other set in the sk_validate_xmit_skb
callback.
It was discussed further on the mailing list [2], and it was pointed out
that there are conflicts with PSP and TLS ULP both using the
skb->decrypted bit.
The simplest fix is to make psp and tls mutually exclusive. This series
goes a bit further and makes psp exclusive with all TCP ULPs. The PSP
implementation that we have is not designed to be used with any TCP ULP,
so don't allow a socket to have state for both.
I will send a subsequent series to net-next which will remove the
ability to perform the rx-assoc and tx-assoc psp netlink calls on
sockets that are not in the TCP_ESTABLISHED state. This will close the
remaining quirk that a sk_clone() on a listen socket with psp tx-assoc
state will leave a stale sk->sk_validate_xmit_skb call back on a new,
non-psp socket. I do not believe that change needs to be regarded as a
fix, because it only stands to add unecessary validation code in the tx
path.
[1]: https://sashiko.dev/#/patchset/20260903-psp-prep-v1-0-d47e9c4c375d%40gmail.com
[2]: https://lore.kernel.org/netdev/20260903-psp-prep-v1-0-d47e9c4c375d@gmail.com/
====================
Link: https://patch.msgid.link/20260915-psp-ktls-fix-v2-0-0eedc3b148ec@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Test both setting PSP after TLS ULP, and TLS ULP after PSP.
Add CONFIG_TLS=y to the drivers/net/config.
Signed-off-by: Daniel Zahka <daniel.zahka@gmail.com>
Reviewed-by: Willem de Bruijn <willemb@google.com>
Link: https://patch.msgid.link/20260915-psp-ktls-fix-v2-2-0eedc3b148ec@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
PSP conflicts with TLS ULP in its usage of both skb->decrypted and
sk->sk_validate_xmit_skb().
Make PSP mutually exclusive with TLS ULP, the only other user of either
of these. As other users of skb->decrypted come along, they can be added
to sk_has_decrypt_user(). It would make sense to also assert that
sk->sk_validate_xmit_skb() is also NULL in both of these setup paths for
similar future proofing, but the PSP listener/sk_clone() path is still
broken and it could be seen as a regression to not allow rx assoc to run
on a child of a listener socket with PSP tx assoc state.
Include all TCP ULPs in the sk_has_decrypt_user() check, even though TLS
is the only one that conflicts with PSP via the decrypted bit. This is
intentional because PSP was not designed to be used with ULPs. It is
best to close off surface area that may make bugs reachable, until
someone wishes to design and test an actual user of PSP with ULPs.
Fixes: 6b46ca260e ("net: psp: add socket security association code")
Signed-off-by: Daniel Zahka <daniel.zahka@gmail.com>
Reviewed-by: Willem de Bruijn <willemb@google.com>
Link: https://patch.msgid.link/20260915-psp-ktls-fix-v2-1-0eedc3b148ec@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
