Introduce devres-based helper for of_reserved_mem_device_init()
to help fight dangling references and ever so slightly reduce the
number of boilerplate deinitialization calls.
Signed-off-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
Link: https://patch.msgid.link/20260730073214.1146432-1-mukesh.ojha@oss.qualcomm.com
Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
In ubi_update_fastmap(), when no fresh PEB is available to replace an
old fastmap PEB, the old PEB is reused by erasing it synchronously
via ubi_sync_erase() with the torture flag hardcoded to zero.
However, old_fm->to_be_tortured[] may be non-zero: it is set during
fastmap scanning when ubi_io_read_data()/ubi_io_read_ec_hdr() reports
UBI_IO_BITFLIPS, meaning the PEB showed signs of bit decay and should
be tortured to verify it is still reliable.
When the old PEB is instead returned to the WL sub-system via
ubi_wl_put_fm_peb(), the to_be_tortured flag is honored. The
synchronous reuse path is inconsistent: it silently skips the torture
test for PEBs that exhibited bit-flips.
Fix it by passing &old_fm->to_be_tortured[i] to ubi_sync_erase().
Fixes: dbb7d2a88d ("UBI: Add fastmap core")
Signed-off-by: Zhihao Cheng <chengzhihao1@huawei.com>
Signed-off-by: Richard Weinberger <richard@nod.at>
In __erase_worker(), when ubi_sync_erase() returns -EINTR, -ENOMEM,
-EAGAIN, or -EBUSY, the physical eraseblock is rescheduled for erasure
via schedule_erase() with the torture flag hardcoded to 0. This
unconditionally drops the torture request.
If the error occurred before torture_peb() completed (e.g., -ENOMEM
from the ec_hdr allocation in ubi_sync_erase(), errors from
self_check_not_bad()/nor_erase_prepare() in ubi_io_sync_erase(), or
torture_peb() failing mid-test because its internal do_sync_erase()/
ubi_io_read()/ubi_io_write() returned one of the above error codes),
the torture test was never finished. Such a PEB may reach the free
pool without being tortured, defeating the purpose of the torture
test for detecting marginally-bad eraseblocks.
If the error occurred after torture_peb() succeeded (the final
do_sync_erase() in ubi_io_sync_erase() or ubi_io_write_ec_hdr() in
ubi_sync_erase() failed), the torture has already been done and need
not be repeated.
Pass the torture flag by pointer to ubi_sync_erase() and
ubi_io_sync_erase(), and clear it to zero once torture_peb() has
completed successfully. __erase_worker() then forwards the updated
wl_wrk->torture to schedule_erase(): torture already done is dropped,
torture not completed is preserved across the reschedule.
Fixes: 784c145444 ("UBI: fix error handling in erase worker")
Signed-off-by: Zhihao Cheng <chengzhihao1@huawei.com>
Signed-off-by: Richard Weinberger <richard@nod.at>
That flag exists to stop gas emulating instructions the assembler thinks
the target lacks. It is a gas-only option, and LLVM's integrated
assembler does not emulate instructions in the first place, so nothing
is needed there.
Condition it on CONFIG_AS_IS_GNU rather than the compiler, so it is
still passed for clang builds using GNU as (LLVM_IAS=0) and omitted only
for the integrated assembler.
Signed-off-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Magnus Lindholm <linmag7@gmail.com>
Link: https://lore.kernel.org/r/20260805185557.3283233-1-mattst88@gmail.com
Signed-off-by: Magnus Lindholm <linmag7@gmail.com>
do_entInt() opens with local_irq_disable(), which with
CONFIG_TRACE_IRQFLAGS only calls trace_hardirqs_off() if interrupts were
not already off:
#define local_irq_disable() \
do { \
bool was_disabled = raw_irqs_disabled();\
raw_local_irq_disable(); \
if (!was_disabled) \
trace_hardirqs_off(); \
} while (0)
On alpha raw_irqs_disabled() is (rdps() & 7) == IPL_MAX, i.e. IPL 7.
PALcode raises PS.IPL to the level of the interrupt before entInt runs,
so for an IPL 7 entry - a processor machine check (vector 0x660) or a
system event (vector 0x680), both IPL_MCHECK == IPL_MAX - the gate is
already true and the annotation is skipped. lockdep keeps whatever
hardirq state the interrupted context had. If that context had
interrupts enabled, lockdep believes they are still enabled for the
duration of the handler, and every lockdep_assert_irqs_disabled() in the
interrupt path fires:
WARNING: kernel/context_tracking.c:346 at ct_irq_enter+0xc4/0xd0, CPU#0: swapper/0/0
[...]
[<fffffc0001ef74d4>] ct_irq_enter+0xc4/0xd0
[<fffffc000105ebd0>] irq_enter+0x20/0x50
[<fffffc000103707c>] do_entInt+0x1dc/0x2e0
[<fffffc0001031d60>] ret_from_exception+0x0/0x10
irq event stamp: 735356346
hardirqs last enabled at (735356346): trace_hardirqs_on+0x68/0x220
hardirqs last disabled at (735356345): do_idle+0xf0/0x270
The stamps show the problem directly: the most recent event is the
enable from the interrupted idle loop, and do_entInt() recorded no
disable at all. ct_irq_exit() warns the same way on the way out.
Ordinary device interrupts arrive at IPL 3-5 and IPIs and performance
counter interrupts at IPL 6, so was_disabled is false for them and the
annotation happens normally. Only the two IPL 7 vectors are affected,
which is why this needs an environmental event to show up.
Take the hardware IPL out of the decision and drive the annotation from
lockdep's own state instead.
This corrects the annotation only. An IPL 7 event can also interrupt a
region that has legitimately disabled interrupts, where irq_enter() and
irq_exit() are not the right primitives and NMI semantics are needed;
that is a larger change and is left alone here.
Tested on an AlphaServer ES47 (Marvel/EV7) by injecting system events
through the system management path: fifteen injections, idle and under
load, with no splat. The same injection on a freshly booted kernel
without this change reproduces both warnings.
Signed-off-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Magnus Lindholm <linmag7@gmail.com>
Tested-by: Magnus Lindholm <linmag7@gmail.com>
Link: https://lore.kernel.org/r/20260810202835.3592833-2-mattst88@gmail.com
Signed-off-by: Magnus Lindholm <linmag7@gmail.com>
On Marvel the CMOS clock is only reachable from the boot cpu, so
remote_read_time() and remote_set_time() bounce the access there with
smp_call_function_single(), whose callback runs in hard interrupt
context.
alpha_rtc_read_time() calls mc146818_get_time() with a 10 ms timeout.
That waits out the RTC update cycle in mc146818_avoid_UIP(), which drops
rtc_lock and udelay()s 100 us at a time until the update completes or
the timeout expires:
for (i = 0; UIP_RECHECK_LOOPS_MS(i) < timeout; i++) {
spin_lock_irqsave(&rtc_lock, flags);
...
if (CMOS_READ(RTC_FREQ_SELECT) & RTC_UIP) {
spin_unlock_irqrestore(&rtc_lock, flags);
udelay(UIP_RECHECK_DELAY);
continue;
}
So a clock read from a non-boot cpu can spin for up to 10 ms in hard
interrupt context on the boot cpu, while the cpu that sent the request
spins in smp_call_function_single() waiting for it to finish.
mc146818_set_time() does not poll, but it takes rtc_lock too, and
rtc_lock is a spinlock_t. Only raw spinlocks may be taken in hard
interrupt context, so lockdep reports the write path as soon as a
non-boot cpu sets the clock:
[ BUG: Invalid wait context ]
-----------------------------
swapper/0/0 is trying to lock:
fffffc0003690470 (rtc_lock){....}-{3:3}, at: mc146818_set_time+0x74/0x450
other info that might help us debug this:
context-{2:2}
no locks held by swapper/0/0.
stack backtrace:
CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 7.2.0-rc1 #1 NONE
Trace:
[<fffffc000102ebb0>] dump_stack+0x28/0x44
[<fffffc000110efcc>] __lock_acquire+0xb0c/0x1060
[<fffffc000110f5f0>] lock_acquire.part.0+0xd0/0x300
[...]
[<fffffc0001b0d834>] mc146818_set_time+0x74/0x450
[<fffffc0001f090cc>] _raw_spin_lock_irqsave+0x7c/0xc0
[<fffffc0001042f90>] do_remote_set+0x90/0xc0
[<fffffc000119c1a4>] __flush_smp_call_function_queue+0x314/0x5c0
[<fffffc000119c474>] generic_smp_call_function_single_interrupt+0x24/0x40
[<fffffc000103d984>] handle_ipi+0xa4/0x230
[<fffffc0001037044>] do_entInt+0x1a4/0x2e0
The rtc class ops are always called from process context, so there is no
reason to run the access from an interrupt at all. Use work_on_cpu() to
run it in a worker on the boot cpu. Alpha does not support cpu hotplug,
so the boot cpu cannot go offline while the work is pending.
Tested on an AlphaServer ES47 (Marvel/EV7): hwclock read and write
pinned to a non-boot cpu, twenty times, with no splat.
Signed-off-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Magnus Lindholm <linmag7@gmail.com>
Link: https://lore.kernel.org/r/20260810202835.3592833-1-mattst88@gmail.com
Signed-off-by: Magnus Lindholm <linmag7@gmail.com>
Md Sadre Alam <md.alam@oss.qualcomm.com> says:
The Qualcomm QPIC SPI-NAND controller supports both single (x1) and
quad (x4) transfer modes, however the current driver operates only in
single-bit mode. This series adds support for quad data transfers and
includes a vendor-specific fix required for Macronix SPI-NAND devices.
Link: https://patch.msgid.link/20260807-quad-v2-0-8ec821e2f22b@oss.qualcomm.com
Macronix SPI-NAND devices use opcode 0x6b for quad output cache reads,
while most other devices use opcode 0xeb. The QPIC SPI-NAND driver does
not currently recognize opcode 0x6b, causing read operations to fail
when Macronix devices select this cache read variant.
Add the Macronix-specific read opcode to the command mapping logic and
treat it the same as the existing quad read operations.
This allows Macronix SPI-NAND devices to operate correctly in quad read
mode.
Signed-off-by: Md Sadre Alam <md.alam@oss.qualcomm.com>
Link: https://patch.msgid.link/20260807-quad-v2-3-8ec821e2f22b@oss.qualcomm.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Add support for quad (x4) transfer mode in the QPIC SPI NAND driver.
The controller supports both single (x1) and quad (x4) SPI transfers,
but the driver currently operates only in x1 mode.
Track the QUAD enable state from the device configuration register
(0xB0) and switch the data transfer width accordingly. When the core
enables quad mode, use x4 transfers for read and program operations to
improve throughput.
Introduce a quad_mode flag in struct qpic_spi_nand to cache the current
device state. The flag is updated based on GET_FEATURE responses from
the configuration register.
Signed-off-by: Md Sadre Alam <md.alam@oss.qualcomm.com>
Link: https://patch.msgid.link/20260807-quad-v2-2-8ec821e2f22b@oss.qualcomm.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Move qcom_spi_cmd_mapping() above qcom_spi_read_page() so it can be
used by read path changes added in a subsequent patch.
No functional change.
Signed-off-by: Md Sadre Alam <md.alam@oss.qualcomm.com>
Link: https://patch.msgid.link/20260807-quad-v2-1-8ec821e2f22b@oss.qualcomm.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Ville Saarinen <wiza@saarinenkoti.fi> says:
The HP OmniBook X Flip 14-kc0xxx (board 8EA1, Strix Point, ACP 7.2) has no
usable audio on mainline at all. Its BIOS reports an ACP configuration flag
of FLAG_AMD_LEGACY_ONLY_DMIC, which binds the legacy ACP driver and
registers a PDM-only card, so the SoundWire links are never scanned. The
two TAS2783 speaker amplifiers on link 0 and the RT712-VB jack codec on
link 1 never enumerate, and the machine has no playback path whatsoever.
Patch 1 adds a DMI quirk overriding the flag so snd_pci_ps probes. Patch 2
adds the machine entry describing the link topology.
With both applied the card comes up and every path on the machine works:
internal speakers, headphone jack with detection, headset microphone and
the internal DMIC array. Two further patches are needed for the speakers
to render stereo rather than mono, and to survive a system resume; those
are in the TAS2783 codec driver and are being sent separately to the TI
maintainers, since they have no build dependency on this pair.
Related reports for the same root cause on other machines:
- kernel bugzilla #221226 (ASUS Zenbook S16)
- CachyOS linux-cachyos#820 (HP OmniBook X Flip 16, board 8EA2 -- the
sibling board, which would need its own entry; I have no access to
one and have not added it)
Tested on the affected machine only. I do not have any other ACP 7.2
board, so the gating on patch 2 is written to be conservative rather than
broad.
Testing
=======
The hardware testing was done on v7.1.6, where an equivalent version of
this pair is what makes audio work on the machine. Against the master
commit named below, both patches have been compile-tested only (gcc, W=1,
no new warnings, no new external symbol references).
Patch 2 has been reworked slightly relative to the tested build: the
RT712-VB entry now reuses the existing jack_dmic_endpoints array, which
already describes exactly the AIF1 jack + AIF3 DMIC pairing this board
needs, instead of adding a second identical copy of it. That was a
mechanical substitution, but it has not been through hardware.
Tool disclosure, per Documentation/process/generated-content.rst
================================================================
This work was done in extended interactive sessions with Claude (Anthropic,
model claude-opus-5) acting as a coding and debugging assistant, and a
substantial amount of the analysis and of the patch text originated with
it. Both patches carry an Assisted-by tag as described in
Documentation/process/coding-assistants.rst.
The division of work:
- The assistant read the DMI data and ACP configuration flag off the
running machine, identified the flag override as the fix, derived the
SoundWire topology from the enumerated peripherals, and drafted both
patches and both changelogs.
- I ran everything that needed root or physical access, rebooted into
each build, and did the listening tests. The left/right ordering in
patch 2 is set by the order of the two amplifier entries; the first
version had the sides reversed and that was caught by ear, not by the
assistant.
- No single prompt generated these patches. The session was iterative
over roughly a day: inspect state, form a hypothesis, build, reboot,
measure, discard the hypothesis if the measurement disagreed. Several
confident intermediate conclusions were wrong and were only caught by
measurement.
I have reviewed both patches, I understand what they do, and I take
responsibility for them.
Link: https://patch.msgid.link/20260809101439.4798-1-wiza@saarinenkoti.fi
Describe the SoundWire topology of the HP OmniBook X Flip 14-kc0xxx
(board 8EA1): two TAS2783 smart amplifiers aggregated on link 0 (unique
IDs 0xC and 0x9, group_position 0 and 1, name prefixes tas2783-1 and
tas2783-2) driving the left and right internal speakers, and an RT712-VB
on link 1 providing the headset jack on AIF1 and the internal DMIC array
on AIF3. The RT712 amplifier path (AIF2) is left unused because the
speakers are driven by the external TAS2783 pair, so the existing
jack_dmic_endpoints array describes it exactly.
The entry is gated on snd_soc_acpi_amd_sdca_is_device_rt712_vb() so it
does not capture a board carrying a different link 1 codec.
Developed with AI assistance. The assistant derived the link topology
from the enumerated peripherals and drafted the table entry. The order
of the two amplifier entries, which is what assigns the physical sides,
was corrected after a listening test by the submitter.
All hardware measurements quoted above were run by the submitter on the
affected machine. The submitter has reviewed the change, understands it
and takes responsibility for it.
Assisted-by: Claude:claude-opus-5
Signed-off-by: Ville Saarinen <wiza@saarinenkoti.fi>
Link: https://patch.msgid.link/20260809101439.4798-3-wiza@saarinenkoti.fi
Signed-off-by: Mark Brown <broonie@kernel.org>
The BIOS on the HP OmniBook X Flip 14-kc0xxx (board 8EA1, Strix Point,
ACP 7.2) reports acp-audio-config-flag = FLAG_AMD_LEGACY_ONLY_DMIC. That
binds the legacy ACP driver and registers a PDM-only card, so the
SoundWire links are never scanned: the two TAS2783 speaker amplifiers on
link 0 and the RT712-VB jack codec on link 1 do not enumerate and the
machine ends up with no usable playback path at all.
Add a DMI entry for the board so the flag is overridden to 0 and
snd_pci_ps probes instead.
Developed with AI assistance. The assistant read the board's ACP
configuration flag out of the running system, identified the flag
override as the fix and drafted the DMI entry.
All hardware measurements quoted above were run by the submitter on the
affected machine. The submitter has reviewed the change, understands it
and takes responsibility for it.
Assisted-by: Claude:claude-opus-5
Signed-off-by: Ville Saarinen <wiza@saarinenkoti.fi>
Link: https://patch.msgid.link/20260809101439.4798-2-wiza@saarinenkoti.fi
Signed-off-by: Mark Brown <broonie@kernel.org>
fsl_asoc_card_probe() hard-fails with -EINVAL when the CPU DAI (SAI)
platform device is not found. Like the codec, the CPU DAI may just be
probed later than the machine driver; the order is not guaranteed and
varies across kernel versions, so a permanent -EINVAL leaves the card
unregistered with no analog playback or capture.
Defer probe instead, mirroring commit e396dec46c ("ASoC:
fsl-asoc-card: Defer probe when fail to find codec device").
Tested on i.MX8MP with an ALC5672 on SAI3: the card that failed to
register on v6.18 now comes up during boot.
Fixes: 708b4351f0 ("ASoC: fsl: Add Freescale Generic ASoC Sound Card with ASRC support")
Signed-off-by: LiangCheng Wang <zaq14760@gmail.com>
Link: https://patch.msgid.link/20260805-fsl-asoc-defer-cpu-dai-v1-1-43f7f538e384@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
On EV6 and later the hardware records exception status bits in the FPCR
before delivering a software completion trap, and those bits can be wrong
for the instruction that trapped. Converting a double that is exactly
representable as a subnormal float sets FPCR_UNF even though the result
is exact, and an underflow trap additionally sets FPCR_INE even when the
emulated operation turns out to be exact.
alpha_fp_emul() only wrote the FPCR when soft-fp raised an exception, so
whenever it determined that the instruction was exact the fabricated bits
stayed in the FPCR and were reported to user space by fetestexcept().
Pass the exception summary register down from do_entArith() so the
handler can tell which exceptions the hardware attributed to the trapping
instruction, and always write the FPCR. Clear the exceptions that the
trap reported but that soft-fp did not raise. EXC_SUM reports only the
underflow or overflow when the hardware also set INE, so treat INE as a
candidate in that case, and treat a trap with no reported exception as a
denormal operand trap, for which the hardware can fabricate INE and UNF
as well. Bits that software has already confirmed in ieee_state belong
to this or an earlier instruction and are never cleared.
The imprecise path passes no summary. There the trap was taken somewhere
in the trap shadow, so EXC_SUM is not attribution for the instruction
being re-executed -- and only EV6, which traps precisely and so never
takes that path, has fabricated bits to clear. For the same reason the
clearing is guarded by implver(), matching swcr_update_status().
On an UP1500 (EV68) this takes the glibc math testsuite from 831 failures
to 28, the remainder being unrelated to exception status.
This belongs with the preceding fix to ieee_swcr_to_fpcr(), and should
not be backported without it -- nor it without this. That fix stops
FPCR_DNOD being set unconditionally, so denormal operand traps start
firing again. Those traps very often find an exact result, which is
precisely the case where the old code left the FPCR unwritten and the
fabricated bits visible. Applied alone it would make spurious exception
flags more common, not less.
One case cannot be resolved here: an inexact instruction without the
software completion suffix never traps, so its INE reaches the FPCR
without being recorded anywhere else. Such a bit is indistinguishable
from an INE the hardware fabricated for a trapping instruction, and is
lost if an underflow or overflow trap with an exact result follows it.
The FPCR is the only record of those instructions and it carries no
attribution.
The bug predates the git history, so there is no commit to reference in a
Fixes tag.
Cc: stable@vger.kernel.org # 5.15+
Signed-off-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Magnus Lindholm <linmag7@gmail.com>
Tested-by: Magnus Lindholm <linmag7@gmail.com>
Link: https://lore.kernel.org/r/20260803-alpha-fp-exceptions-v1-2-c99d75608e60@gmail.com
Signed-off-by: Magnus Lindholm <linmag7@gmail.com>
ieee_swcr_to_fpcr() converts the software IEEE trap-enable and status
bits kept in thread_info.ieee_state into the hardware FPCR format. It
contained:
fp |= (~sw & IEEE_TRAP_ENABLE_DNO) << 41;
FPCR_DNOD (bit 47) disables denormal operand traps: with it set the
hardware handles a denormal operand itself, treating it as zero, instead
of trapping for software completion. The intent was to set DNOD when the
user has not asked for SIGFPE on denormal operands, but
IEEE_TRAP_ENABLE_DNO is clear by default, so ieee_swcr_to_fpcr(0) always
set DNOD.
Instructions built with the software completion suffix therefore never
trapped on a denormal operand. The hardware silently substituted zero
and produced wrong results, affecting every program compiled with -mieee
and default FPU settings, glibc included.
Set FPCR_DNOD only when IEEE_MAP_DMZ is requested, which is exactly the
case where flushing denormal inputs to zero is what the user asked for.
DNOD then encodes MAP_DMZ, which ieee_fpcr_to_swcr() already recovers
from FPCR_DNZ, so drop its attempt to recover IEEE_TRAP_ENABLE_DNO from
DNOD; the DNO trap enable lives solely in ieee_state.
Both functions are in a uapi header, so the encoding change is visible to
userspace, but nothing outside the kernel is known to depend on DNOD
carrying the DNO trap enable, and the kernel is the only writer of the
FPCR.
This must not be backported on its own. Re-enabling denormal operand
traps exposes a second bug, fixed in the following patch: those traps
usually find an exact result, and for an exact result the emulator did
not write the FPCR back, leaving hardware-fabricated exception bits
visible to user space. Taken alone this change would make spurious
exception flags more common.
The bug predates the git history, so there is no commit to reference in a
Fixes tag.
Cc: stable@vger.kernel.org # 5.15+
Signed-off-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Magnus Lindholm <linmag7@gmail.com>
Tested-by: Magnus Lindholm <linmag7@gmail.com>
Link: https://lore.kernel.org/r/20260803-alpha-fp-exceptions-v1-1-c99d75608e60@gmail.com
Signed-off-by: Magnus Lindholm <linmag7@gmail.com>
The Device Tree binding defines the extclk clock as an optional
property, but the driver currently uses devm_clk_get() and manually
handles the absence of the clock.
Use devm_clk_get_optional() to match the binding and simplify the
optional clock handling. This also propagates errors other than the
absence of the optional clock, including -EPROBE_DEFER.
This changes the existing behavior for errors other than
-EPROBE_DEFER. RFC to discuss whether these errors should cause probe
to fail rather than being treated as an unavailable optional clock.
Fixes: 90eb6b59d3 ("ASoC: pxa-ssp: add support for an external clock in devicetree")
Signed-off-by: bui duc phuc <phucduc.bui@gmail.com>
Link: https://patch.msgid.link/20260811100949.61142-1-phucduc.bui@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
- use the struct keyword when describing a struct in kernel-doc format.
- add or correct missing struct members @leaf, @eof, and
@superblock_need_write.
- add Returns: clauses for 4 function descriptions.
to prevent kernel-doc warnings:
Warning: fs/ubifs/ubifs.h:755 struct member 'leaf' not described in 'ubifs_zbranch'
Warning: fs/ubifs/ubifs.h:814 struct member 'eof' not described in 'bu_info'
Warning: fs/ubifs/ubifs.h:814 Excess struct member 'oef' description in 'bu_info'
Warning: fs/ubifs/ubifs.h:992 cannot understand function prototype: 'struct ubifs_stats_info'
Warning: fs/ubifs/ubifs.h:1513 struct member 'superblock_need_write' not described in 'ubifs_info'
Warning: fs/ubifs/ubifs.h:1597 No description found for return value of 'ubifs_check_hash'
Warning: fs/ubifs/ubifs.h:1612 No description found for return value of 'ubifs_check_hmac'
Warning: fs/ubifs/ubifs.h:1653 No description found for return value of 'ubifs_branch_hash'
Warning: fs/ubifs/ubifs.h:1703 No description found for return value of 'ubifs_auth_node_sz'
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Reviewed-by: Zhihao Cheng <chengzhihao1@huawei.com>
Signed-off-by: Richard Weinberger <richard@nod.at>
Use @hash as the function parameter name to prevent kernel-doc warnings:
Warning: fs/ubifs/key.h:42 function parameter 'hash' not described in 'key_mask_hash'
Warning: fs/ubifs/key.h:42 Excess function parameter 'val' description in 'key_mask_hash'
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Reviewed-by: Zhihao Cheng <chengzhihao1@huawei.com>
Signed-off-by: Richard Weinberger <richard@nod.at>
Use the "struct" keyword to describe structs in kernel-doc format.
This avoids kernel-doc warnings:
Warning: fs/ubifs/debug.h:75 cannot understand function prototype: 'struct ubifs_debug_info'
Warning: fs/ubifs/debug.h:130 cannot understand function prototype: 'struct ubifs_global_debug_info'
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: Richard Weinberger <richard@nod.at>
idpf_tx_splitq_build_flow_desc performs a 32-bit store to &cmd_dtype
to set the 8-bit cmd_dtype and zero the adjacent 3-byte timestamp
field in a single operation.
Descriptors are in little endian. Add missing cpu_to_le32 and cast to
__le32 to ensure the fields are written correctly also on big endian
platforms.
Fixes: 1a49cf814f ("idpf: add Tx timestamp flows")
Signed-off-by: Willem de Bruijn <willemb@google.com>
Reviewed-by: Jason Xing <kerneljasonxing@gmail.com>
Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
FW caps the NVM read lock at a maximum of 3000ms regardless of the timeout
requested via ice_acquire_nvm(). ice_read_flat_nvm() splits a read into
multiple ice_aq_read_nvm() commands, one per 4KB sector, all issued under a
single lock taken by the caller. Reading a large region can exceed 3000ms,
so FW reclaims the lock mid-read and the remaining commands might fail.
Move the lock acquire/release into ice_read_flat_nvm() so it brackets each
individual ice_aq_read_nvm() command, ensuring the lock is never held
across more than one FW read.
ice_release_nvm() issues its own AQ command and overwrites
hw->adminq.sq_last_status, which some callers inspect after a failed read.
Add an optional read_aq_err output parameter to ice_read_flat_nvm() to
capture the failing read's AQ error before the release; callers that need
it (ice_discover_flash_size() and the ethtool/devlink log paths) use it
instead of sq_last_status, others pass NULL.
Callers that previously took the lock around ice_read_flat_nvm(),
ice_read_sr_word() or ice_read_flash_module() now call them without it.
The now-redundant per-block locking in ice_devlink_nvm_snapshot() is
dropped. ice_read_sr_word() is now a thin wrapper, so ice_read_sr_word_aq()
is folded into it.
Fixes: e94509906d ("ice: create function to read a section of the NVM and Shadow RAM")
Signed-off-by: Robert Malz <robert.malz@canonical.com>
Reviewed-by: Przemek Kitszel <przemyslaw.kitszel@intel.com>
Reviewed-by: Marcin Szycik <marcin.szycik@linux.intel.com>
Tested-by: Rinitha S <sx.rinitha@intel.com> (A Contingent worker at Intel)
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
When a VSI is configured as the switch's default forwarding VSI
(ICE_SW_LKUP_DFLT) and is then torn down, the rule is left behind in
the switch. ice_vsi_release() no longer removes it, and the SR-IOV VF
free path (ice_free_vfs() -> ice_free_vf_res() -> ice_vf_vsi_release()
-> ice_vsi_release()) does not disable promiscuous mode either, which
only happens on VF reset in ice_vf_clear_all_promisc_modes().
A trusted VF that enters unicast promiscuous mode becomes the default
forwarding VSI (this is the default mode, when the PF does not have VF
true-promiscuous mode enabled). If the VFs are then destroyed without
the VF first leaving promiscuous mode, the ICE_SW_LKUP_DFLT rule for
the now-freed VSI is leaked. When VFs are recreated, a VSI reuses the
freed hw_vsi_id. If it is assigned a different VSI handle than the
leaked rule holds, ice_set_dflt_vsi() does not recognize it as
already-default, and ice_add_update_vsi_list() folds the dangling
(freed) handle into a VSI list, which the firmware rejects. The VSI
handle assigned on re-creation varies, so the failure is intermittent
rather than every cycle.
Reproduce by repeatedly running the cycle below on the two ports of the
same card, where $VF0 and $VF1 are the netdevs of vf 15 once they
appear. The VF must be brought up so iavf actually pushes the unicast
promiscuous request, and the rule must settle before the VFs are torn
down again:
echo 16 > /sys/class/net/$PF0/device/sriov_numvfs
echo 16 > /sys/class/net/$PF1/device/sriov_numvfs
ip link set $PF0 vf 15 trust on
ip link set $PF1 vf 15 trust on
ip link set $VF0 up
ip link set $VF1 up
ip link set $VF0 promisc on
ip link set $VF1 promisc on
sleep 1
echo 0 > /sys/class/net/$PF0/device/sriov_numvfs
echo 0 > /sys/class/net/$PF1/device/sriov_numvfs
Within a few cycles the ice PF and iavf VF log:
Failed to set VSI 25 as the default forwarding VSI, error -22
Turning on/off promiscuous mode for VF 63 failed, error: -22
PF returned error -53 (IAVF_ERR_ADMIN_QUEUE_ERROR) to our request 14
This cleanup used to live in ice_vsi_release() but was dropped by the
referenced refactor. Restore it. Clear the default forwarding VSI rule
in ice_vsi_release() when this VSI owns it, which covers every teardown
path.
Fixes: 6624e780a5 ("ice: split ice_vsi_setup into smaller functions")
Signed-off-by: Petr Oros <poros@redhat.com>
Reviewed-by: Marcin Szycik <marcin.szycik@linux.intel.com>
Tested-by: Rafal Romanowski <rafal.romanowski@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
The low-latency (LL) PHY timer interface relies on a tight, atomic poll
of the PF_SB_ATQBAL register with a 2ms timeout. After an NVM update /
EMPR, FW may need significantly longer than 2ms to start responding to
ATQBAL commands. The first PHY adjust or incval write issued by
ice_ptp_rebuild_owner() fails with -ETIMEDOUT.
Fix this by falling back to the existing SBQ-based PHY register write
path when LL times out. This makes sure PTP is initialized when FW takes
longer than expected to come back online.
Steps to reproduce:
./nvmupdate64e -if devlink -f
Update E810 card with nvmupdate64e, and observe dmesg errors:
Failed to write PHC increment value, status -110
PTP reset failed, error: -110 (-ETIMEDOUT)
Fixes: ef9a64c072 ("ice: implement low latency PHY timer updates")
Signed-off-by: Przemyslaw Korba <przemyslaw.korba@intel.com>
Reviewed-by: Simon Horman <horms@kernel.org>
Tested-by: Rinitha S <sx.rinitha@intel.com> (A Contingent worker at Intel)
Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
c4iw_alloc() creates the per-device debugfs tree (dev->debugfs_root via
setup_debugfs()), but it is removed only in c4iw_remove(), not in
c4iw_dealloc(). When RDMA device registration fails, the registration
worker's err_dealloc_ctx path calls c4iw_dealloc() directly, bypassing
c4iw_remove(), so the debugfs dentries leak and outlive the freed
c4iw_dev.
Move debugfs_remove_recursive() into c4iw_dealloc() so every path that
frees ctx->dev also removes its debugfs tree.
Fixes: 49ea0c036e ("RDMA/iw_cxgb4: cleanup device debugfs entries on ULD remove")
Link: https://patch.msgid.link/r/20260806130128.465460-2-fanwu01@zju.edu.cn
Assisted-by: Codex:gpt-5.6
Signed-off-by: Fan Wu <fanwu01@zju.edu.cn>
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
c4iw_uld_state_change() queues reg_work to register the RDMA device.
c4iw_remove() can free ctx->dev while this work is pending or running,
leaving c4iw_register_device() accessing the freed device.
Cancel reg_work before removing the device. The registration work can
tear down ctx->dev when registration fails, so do not unregister or
deallocate it again in that case.
This issue was found by an in-house static analysis tool.
Fixes: 1c8f1da5d8 ("iw_cxgb4: Fix possible circular dependency locking warning")
Link: https://patch.msgid.link/r/20260806130128.465460-1-fanwu01@zju.edu.cn
Cc: stable@vger.kernel.org
Assisted-by: Codex:gpt-5.6
Signed-off-by: Fan Wu <fanwu01@zju.edu.cn>
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
When a function-like macro expands to an expression, that expression
doesn't need a semicolon after it. All uses have been verified to
have their own semicolons.
This was found using the following Coccinelle semantic patch:
@r@
identifier i : script:ocaml() { String.lowercase_ascii i = i };
expression e;
@@
*#define i(...) e;
Link: https://patch.msgid.link/20260801191002.1383835-6-Julia.Lawall@inria.fr
Signed-off-by: Julia Lawall <Julia.Lawall@inria.fr>
Acked-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
The interrupt-emulation virtual IRQ uses handle_level_irq(), but the IRQ
descriptor has not been marked with IRQ_LEVEL.
The interrupt emulation is somewhat unusual: the eDMA interrupt handlers
dispatch the virtual IRQ for every edma_int[] interrupt because software
cannot reliably tell an interrupt-emulation event from one caused solely
by DONE/ABORT status. If an interrupt arrives before the doorbell
handler is registered for the virtual IRQ, the IRQ core marks it
pending. When the IRQ is later started, check_irq_resend() treats it as
non-level and replays the pending interrupt, causing the newly
registered handler to run for a stale event.
Mark the virtual IRQ with IRQ_LEVEL so the stale pending state is
cleared without being replayed. This was observed in pci_endpoint_test
as two doorbell handler calls when the DMA-variant test ran before
DOORBELL_TEST.
Fixes: d9d5e1bdd1 ("dmaengine: dw-edma: Add virtual IRQ for interrupt-emulation doorbells")
Cc: stable@vger.kernel.org
Reported-by: Niklas Cassel <cassel@kernel.org>
Closes: https://lore.kernel.org/r/ampndLtU32ODmncX@ryzen
Tested-by: Niklas Cassel <cassel@kernel.org>
Signed-off-by: Koichiro Den <den@valinux.co.jp>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Reviewed-by: Manivannan Sadhasivam <mani@kernel.org>
Link: https://patch.msgid.link/20260730160701.3550710-1-den@valinux.co.jp
Signed-off-by: Vinod Koul <vkoul@kernel.org>
The IAA device defaults only assigned engine 0 to group 0, leaving
engines 1 through max_engines-1 unassigned (group_id = -1). This means
that by default only a single engine processed descriptors, limiting
throughput to one engine's capacity.
Assign all available engines to group 0 so that the full hardware
parallelism is used out of the box without requiring manual
accel-config setup.
Signed-off-by: Giovanni Cabiddu <giovanni.cabiddu@intel.com>
Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@intel.com>
Reviewed-by: Dave Jiang <dave.jiang@intel.com>
Link: https://patch.msgid.link/20260805-iaa-crypto-fixes-zswap-v2-1-55c02694f499@intel.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Both branches of the check return the same value, so the check has
no effect. Remove it and return the value directly.
This is the result of running the Coccinelle script from
scripts/coccinelle/misc/cond_return_no_effect.cocci.
Signed-off-by: Sang-Heon Jeon <ekffu200098@gmail.com>
Link: https://patch.msgid.link/20260723184538.3888637-20-ekffu200098@gmail.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
bam_dma_probe() calls pm_runtime_use_autosuspend(), but
bam_dma_remove() does not call the matching
pm_runtime_dont_use_autosuspend() when removing the device.
If the autosuspend delay is set to a negative value while autosuspend
is enabled, the runtime PM core increments usage_count to prevent
runtime suspend. Without calling pm_runtime_dont_use_autosuspend()
during teardown, this reference is not dropped and usage_count remains
unbalanced.
Add the missing pm_runtime_dont_use_autosuspend() call before forcing
the device into runtime suspend during removal.
This issue was found by manual code inspection.
Fixes: 7d2545599f ("dmaengine: qcom-bam-dma: Add pm_runtime support")
Signed-off-by: Guangshuo Li <lgs201920130244@gmail.com>
Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
Link: https://patch.msgid.link/20260808110642.2770355-1-lgs201920130244@gmail.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
orangefs_prepare_cdm_array() sizes each client debug keyword buffer
with strcspn(cds_head, " "), but then parses the keyword with %s. The
%s conversion skips leading whitespace, while strcspn() does not.
If a client debug entry starts with a space, the allocation can be sized
for an empty keyword while sscanf() copies the following non-empty token.
This can write past the end of the allocated keyword buffer.
Skip leading spaces before computing the keyword length so the allocation
matches the string parsed by sscanf().
Fixes: f7be4ee07f ("Orangefs: kernel client part 4")
Cc: stable@vger.kernel.org
Reported-by: Vega <vega@nebusec.ai>
Assisted-by: Codex:gpt-5.4
Signed-off-by: Zhiling Zou <zhilinz@nebusec.ai>
Signed-off-by: Ren Wei <enjou1224z@gmail.com>
Signed-off-by: Mike Marshall <hubcap@omnibond.com>
The code has been commented out since 2017 - remove it.
Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev>
Signed-off-by: Mike Marshall <hubcap@omnibond.com>
orangefs_page_mkwrite() records the faulted range with
page_offset(vmf->page) and PAGE_SIZE, although the write range it sets
is attached to the folio and the rest of the function already operates
on folios. Use folio_pos() and folio_size() instead. This gets rid of
two calls to page_offset(), removing two calls to compound_head().
No functional change. orangefs folios are always order-0, so the values
are identical. However, if orangefs ever enables large folios, this
change is necessary for correctness with the current write range
tracking scheme. Tracking only a single page of a larger folio would
leave the rest of the folio's dirty data outside the range that gets
written back, leading to data loss.
Signed-off-by: Tal Zussman <tz2294@columbia.edu>
Signed-off-by: Mike Marshall <hubcap@omnibond.com>
On a readdir downcall, orangefs_devreq_write_iter() frees
op->downcall.trailer_buf with vfree() when copy_from_iter_full() fails,
but does not clear the pointer before goto Efault. The waiter in
do_readdir() is then woken with a negative status and frees the same
pointer again on its r < 0 path, causing a deterministic double-free.
A client holding /dev/pvfs2-req triggers it by sending a readdir
downcall whose declared trailer_size exceeds the bytes it supplies.
Clear the pointer after freeing so the readdir-side vfree() becomes a
no-op.
Fixes: 382f4581e6 ("orangefs: rewrite readdir to fix several bugs")
Cc: stable@vger.kernel.org
Assisted-by: Claude:claude-opus-4-8
Signed-off-by: Yifei Gao <gyf161023@gmail.com>
Signed-off-by: Mike Marshall <hubcap@omnibond.com>
The fsl edma events store a pointer to a struct fsl_edma_engine in the
ringbuffer and dereference it when a log entry is printed. At this time,
the pointer may no longer be valid.
Event injection can be used to trigger a crash:
$ cd /sys/kernel/tracing
$ echo 'value = 0' > events/fsl_edma/edma_writeb/inject
$ cat trace
The log output needs only edma->membase. Add a membase field at the end
of the event and use the new field for log output. Keep the existing
fields for backward compatibility.
Fixes: 11102d0c34 ("dmaengine: fsl-edma: add trace event support")
Cc: stable@vger.kernel.org
Reviewed-by: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Martin Kaiser <martin@kaiser.cx>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Link: https://patch.msgid.link/20260718130024.341243-1-martin@kaiser.cx
Signed-off-by: Vinod Koul <vkoul@kernel.org>
As per the ARM GICv3 spec, the maintenance interrupt identified by
ICH_MISR_EL2.NP is asserted when it is enabled and no List register is
in pending state. This is further described in the document as "no List
registers with the State field set to 0b01 (pending)". By checking only
the pending bit of the LR (bit 62), KVM currently asserts the MI when
there are no LRs in "pending" or "pending and active" states.
Fix the detection logic to consider only the "pending" state.
Cc: stable@vger.kernel.org
Fixes: 96c2f03311 ("KVM: arm64: nv: Plumb handling of GICv3 EL2 accesses")
Signed-off-by: Kajetan Puchalski <kajetan.puchalski@arm.com>
Reviewed-by: Marc Zyngier <maz@kernel.org>
Link: https://patch.msgid.link/20260810102923.2426475-2-kajetan.puchalski@arm.com
Signed-off-by: Oliver Upton <oupton@kernel.org>
With pKVM, the host stage-2 is lazily mapped. kallsyms, accessed via
the modifier %pB is therefore potentially unmapped. If the hyp panic
occurred while the host stage-2 lock was held, handling this fault
deadlocks.
Skip %pB formatting unless the host stage-2 is disabled.
Fixes: 6ccf9cb557 ("KVM: arm64: Symbolize the nVHE HYP addresses")
Signed-off-by: Vincent Donnefort <vdonnefort@google.com>
Reviewed-by: Fuad Tabba <fuad.tabba@linux.dev>
Tested-by: Fuad Tabba <fuad.tabba@linux.dev>
Link: https://patch.msgid.link/20260803093906.3531699-1-vdonnefort@google.com
Signed-off-by: Oliver Upton <oupton@kernel.org>
kvm_vgic_create() sets vgic.in_kernel before allocating the per-vCPU
private IRQs, but the allocation-failure path resets only vgic_model and
leaves in_kernel set. As irqchip_in_kernel() is !!in_kernel, the VM is
left with an in-kernel irqchip but no model, and the -EEXIST guard at the
top of kvm_vgic_create() rejects every retry, so userspace cannot recover
from a transient -ENOMEM.
Reset in_kernel alongside vgic_model on the failure path.
Fixes: 9435c1e143 ("KVM: arm64: gic: Set vgic_model before initing private IRQs")
Cc: stable@vger.kernel.org
Signed-off-by: Fuad Tabba <fuad.tabba@linux.dev>
Acked-by: Marc Zyngier <maz@kernel.org>
Link: https://patch.msgid.link/20260802150845.3485757-1-fuad.tabba@linux.dev
Signed-off-by: Oliver Upton <oupton@kernel.org>
vgic_v2_deactivate() passes the INTID a guest wrote to GICV_DIR straight
to vgic_get_vcpu_irq(), and treats a failed lookup as a "can't happen"
condition with WARN_ON_ONCE().
The guest can make it happen at will, though: for any INTID outside of
the implemented SGI, PPI and SPI ranges the lookup returns NULL, since
GICv2 has no LPIs. A guest running with EOImode==1 writing such an INTID
to GICV_DIR triggers the WARN, and panics hosts running with
panic_on_warn.
Drop the WARN and ignore failed lookups.
Fixes: 255de897e7 ("KVM: arm64: GICv2: Handle deactivation via GICV_DIR traps")
Cc: stable@vger.kernel.org
Suggested-by: Marc Zyngier <maz@kernel.org>
Signed-off-by: Karl Mehltretter <kmehltretter@gmail.com>
Link: https://patch.msgid.link/20260726174803.5880-1-kmehltretter@gmail.com
Signed-off-by: Oliver Upton <oupton@kernel.org>
kvm_handle_cp_64() only seeds params.regval for writes. If a CP64 read is
decoded but UNDEFs, emulate_cp() still returns handled and the caller
writes params.regval back to Rt/Rt2.
This can happen for PMU counter read accesses generating an UNDEF. KVM
injects the exception into the guest, so the MRRC GPRs must remain
unchanged.
Instead, the uninitialised regval is copied into the guest GPRs. With stack
auto-initialisation this is a deterministic zero or pattern value. With
CONFIG_INIT_STACK_NONE it may be stale host stack data.
Match kvm_handle_cp_32() and kvm_handle_sys_reg() by seeding regval from
the GPRs before emulation.
Fixes: 62a89c4495 ("arm64: KVM: 32bit handling of coprocessor traps")
Assisted-by: Claude:claude-opus-5
Signed-off-by: Karl Mehltretter <kmehltretter@gmail.com>
Reviewed-by: Marc Zyngier <maz@kernel.org>
Link: https://patch.msgid.link/20260802182222.2239-1-kmehltretter@gmail.com
Signed-off-by: Oliver Upton <oupton@kernel.org>
ucma_set_ib_path() calls ucma_event_handler() straight from the write()
path, without the handler lock that keeps ctx->file stable while a uevent
is queued. The handler re-reads ctx->file for every dereference:
mutex_lock(&ctx->file->mut); /* file A */
list_add_tail(&uevent->list, &ctx->file->event_list); /* file B */
mutex_unlock(&ctx->file->mut); /* file B */
wake_up_interruptible(&ctx->file->poll_wait); /* file B */
A concurrent ucma_migrate_id() reassigns ctx->file while the SET_OPTION
caller sleeps in mutex_lock(), so the list_add_tail() lands on file B's
event_list while only file A's mutex is held, racing every other user of
that list:
BUG: KASAN: slab-use-after-free in __list_add_valid_or_report+0x1aa/0x1c0
Read of size 8 at addr ffff888153c6a418 by task poc_corr/486
Call Trace:
__list_add_valid_or_report+0x1aa/0x1c0
ucma_event_handler+0x1be/0xc00
ucma_set_ib_path+0x45e/0x710
ucma_set_option+0x32e/0x590
ucma_write+0x1f9/0x330
Allocated by task 505:
ucma_write_cm_event+0x1a1/0x660
Freed by task 505:
kfree+0x1da/0x4c0
ucma_get_event+0x5d5/0x7e0
The freed object is a ucma_event that another thread dequeued from file B's
list under file B's mutex. File A's mut is left held on top of that,
wedging its next writer in uninterruptible sleep.
This path needs a bound and address-resolved cm_id, so it requires an RDMA
device to be present.
Take the handler lock around the call.
Fixes: 09e328e47a ("RDMA/ucma: Fix the locking of ctx->file")
Link: https://patch.msgid.link/r/2823D190-92D5-4714-8769-4FB643C64FF3@doyensec.com
Cc: stable@vger.kernel.org
Assisted-by: Claude:claude-opus-5
Signed-off-by: Norbert Szetei <norbert@doyensec.com>
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
ctx->file may only be changed under the handler lock and the xa_lock, which
is what stops uevents being queued for a ctx while ucma_migrate_id() moves
it to another file. The CM core takes that lock before invoking
ucma_event_handler(), but the write() paths that queue uevents themselves
do not.
ucma_write_cm_event() re-reads ctx->file for each of its four dereferences,
so ucma_migrate_id() can swap it mid-sequence:
mutex_lock(&ctx->file->mut); /* file A */
list_add_tail(&uevent->list, &ctx->file->event_list); /* file B */
mutex_unlock(&ctx->file->mut); /* file B */
wake_up_interruptible(&ctx->file->poll_wait); /* file B */
The window is the mutex_lock() itself: the writer sleeps in it while the
migration reassigns ctx->file. The list_add_tail() then runs on file B's
event_list holding only file A's mutex:
list_add corruption. prev->next should be next (ffff888101320f30),
but was ffff88814a08c418. (prev=ffff88814a075c18).
kernel BUG at lib/list_debug.c:32!
Call Trace:
ucma_write_cm_event+0x36e/0x5e0
and file A's mut is left held forever, wedging its next writer in D state.
The uevent is also stranded on a list ucma_cleanup_ctx_events() will not
walk, so it outlives its context. /dev/infiniband/rdma_cm is 0666 and no
RDMA device is involved, so an unprivileged user reaches all of this.
Take the handler lock, as ucma_cleanup_mc_events() does; ctx->cm_id is
pinned by the ucma_get_ctx() reference.
Fixes: a3c9d0fcd3 ("RDMA/ucma: Support write an event into a CM")
Link: https://patch.msgid.link/r/60544A67-EFD6-4D5D-974C-D983445F1070@doyensec.com
Cc: stable@vger.kernel.org
Assisted-by: Claude:claude-opus-5
Signed-off-by: Norbert Szetei <norbert@doyensec.com>
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
nvme_find_rq() and nvme_handle_cqe() print an unratelimited message for
every completion queue entry whose command id does not resolve to an
in-flight request. Both are reached from the completion interrupt path
(nvme_irq() -> nvme_poll_cq() -> nvme_handle_cqe()) and the decision to
print is made entirely from device-supplied data, so a controller that
posts a stream of bogus command ids drives unbounded printk from hard
interrupt context.
This is not hypothetical. A single boot under an emulated controller
that posts invalid completions produced 846 "could not locate request
for tag 0x0", 846 "invalid id 0 completed on queue 2" and 123 "genctr
mismatch" lines. Once the tag set has been torn down every subsequent
completion resolves to nothing, so the print rate is bounded only by how
fast the device can post entries.
Ratelimit the three messages. The information they carry is diagnostic
and repeats, so the suppression count printed by the ratelimit helpers
is enough to tell that the condition persists. This matches how the
other device-driven error prints in the driver are already handled, for
example the status messages in nvme_log_error() and
nvme_log_err_passthru().
nvme_find_rq() lives in nvme.h and is shared by pci, tcp, rdma, apple and
target-loop, so all transports are covered.
Found by FuzzNvme.
Signed-off-by: Chao Shi <coshi036@gmail.com>
Signed-off-by: Keith Busch <kbusch@kernel.org>
