The ITE controller behind the keyboard of the Lenovo Yoga Slim 7x Gen 11
(048d:83db) carries out a reset but never raises the interrupt that
acknowledges it. i2c_hid_finish_hwreset() therefore waits out its full
one second timeout and logs "device did not ack reset within 1000 ms" on
every probe and every resume, before the keyboard comes up regardless.
Set I2C_HID_QUIRK_NO_IRQ_AFTER_RESET for it, as is already done for
several other ITE parts, so the reset is followed by a fixed 100 ms sleep
instead.
Signed-off-by: Oleg Keri <okerixx@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
Extend critical section in roccat_connect() to ensure that partially
initialized 'struct roccat_device' is never exposed in 'devices' list,
and do the same in roccat_disconnect() to avoid racy 'devices' access
against roccat_release().
Signed-off-by: Dmitry Antipov <dmantipov@yandex.ru>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
PPR and GAlog interrupt is enabled only if buffer is allocated.
(See amd_iommu_enable_ppr_log() and iommu_ga_log_enable()).
The duplicate check in interrupt hanlder path is unnecessary
and can be removed.
No functional changes.
Signed-off-by: Vasant Hegde <vasant.hegde@amd.com>
Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
The amd_iommu_irq_remap flag is already validated during irq remapping
domain creation (before calling amd_iommu_create_irq_domain()). The
duplicate check in irq_remapping_select() is unnecessary and can be
removed.
Additionally, mark amd_iommu_irq_remap as static.
No functional changes.
Signed-off-by: Vasant Hegde <vasant.hegde@amd.com>
Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
The headset reports connection and battery status on HID interface
5. When the device is disconnected, ignore incoming battery
reports as they will incorrectly report battery level 0.
Clamp overreported battery values to 100% and add USB ID 1038:12ad
to the driver's device tables.
Signed-off-by: Erik Håkansson <erikhakan@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
The G502 X Lightspeed enumerates as 046d:c098 when connected with its
cable. Add the id so the driver handles the wired device.
Signed-off-by: Andres Diaz <andresd.diaz16@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
The threaded IRQ handler can run before devm_request_threaded_irq()
returns, but thread_lock was initialized afterwards. Initialize it before
requesting either interrupt.
Fixes: 8047310ee9 ("mmc: sh_mmcif: fix a race, causing an Oops on SMP")
Cc: stable@vger.kernel.org
Assisted-by: Codex:GPT-5
Signed-off-by: Runyu Xiao <runyu.xiao@seu.edu.cn>
Signed-off-by: Ulf Hansson <ulfh@kernel.org>
Replace "expression" with "identifier" in the declaration of hdev.
This is necessary because hdev is used as the name of a function
parameter.
Move the two uses of @p2 to the relevant function names.
Convert <... ...>, meaning that the contained pattern is optional,
to use ..., when any, and exists. This requires that the function
contain calls to hid_hw_start, etc, which reduces the set of files
that are considered for matching against this pattern.
Reported-by: Ricardo Ribalda <ribalda@chromium.org>
Signed-off-by: Julia Lawall <Julia.Lawall@inria.fr>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
nvmet_ns_device_path_store() frees the old path before allocating its
replacement, losing the existing configuration if allocation fails.
Allocate the new path before freeing the old one.
Fixes: a07b4970f4 ("nvmet: add a generic NVMe target")
Signed-off-by: Julian Sun <sunjunchao@bytedance.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Keith Busch <kbusch@kernel.org>
In nvme_fc_reconnect_or_delete(), the system attempts to remove
the controller when reconnect limits are reached by calling
nvme_delete_ctrl(). This call is currently wrapped in a WARN_ON().
If a user concurrently deletes the controller via sysfs, the
controller's state may have already transitioned out of the
CONNECTING state. When this happens, nvme_delete_ctrl() correctly
rejects the operation and returns -EBUSY. Because of the WARN_ON()
wrapper, this race condition triggers an unnecessary kernel warning
stack trace.
Remove the WARN_ON() macro around nvme_delete_ctrl();
this allows the system to safely ignore the -EBUSY return value
if the controller is already being deleted.
Signed-off-by: Maurizio Lombardi <mlombard@redhat.com>
Reviewed-by: Daniel Wagner <dwagner@suse.de>
Signed-off-by: Keith Busch <kbusch@kernel.org>
The Micron 4100AT fetches PRP Lists in 512 byte strides, but the driver
allocates small PRP List descriptors in 256 byte strides. A descriptor
in the last 256 bytes of a dmapool page makes the controller read past
the page: the access lands on an adjacent IOVA, the IOMMU faults the
command. That last block only became reachable with commit da9619a30e
("dmapool: link blocks across pages"), so this affects v6.4 and later.
Align the small descriptor pool to 512 bytes, as commit ebefac5647
("nvme-pci: 512 byte aligned dma pool segment quirk") already does for
another controller with the same erratum. The last block then starts
at offset 0xE00 and the fetch stays inside the page.
Cc: <stable@vger.kernel.org> # 6.4.x: ebefac5647: nvme-pci: 512 byte aligned dma pool segment quirk
Cc: <stable@vger.kernel.org> # 6.4.x
Signed-off-by: Gaurav Sinha <gsinha@micron.com>
Signed-off-by: Bean Huo <beanhuo@micron.com>
Signed-off-by: Keith Busch <kbusch@kernel.org>
alps_input_configured() stores data->input2 before calling
input_register_device(). If registration fails, input_free_device()
frees the input device but data->input2 still points to the freed memory.
alps_input_configured() calls hid_hw_open() before allocating input2, so
URBs are already active and raw_event can fire during the failure window.
A U1_SP_ABSOLUTE_REPORT_ID report arriving then causes u1_raw_event()
to dereference the freed data->input2 -> use-after-free.
Fix by only storing input2 into drvdata after successful registration
and adding a NULL guard in the raw_event path.
Fixes: 2562756dde ("HID: add Alps I2C HID Touchpad-Stick support")
Cc: stable@vger.kernel.org
Signed-off-by: Chen Changcheng <chenchangcheng@kylinos.cn>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
alps_input_configured() allocates a second input device ("DualPoint
Stick") with input_allocate_device() and registers it, but the
alps_driver struct has no .remove handler and input2 is not tracked in
hdev->inputs. The default remove path (hid_hw_stop -> hidinput_disconnect)
only iterates hdev->inputs, so input2 is never unregistered and leaks
on every device removal.
Add a .remove handler that stops the device first (preventing URB
callbacks from touching input2 during teardown) and then unregisters
input2.
Fixes: 2562756dde ("HID: add Alps I2C HID Touchpad-Stick support")
Cc: stable@vger.kernel.org
Signed-off-by: Chen Changcheng <chenchangcheng@kylinos.cn>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
winwing_init_ff() passes the driver's private data, allocated with
devm_kzalloc() in winwing_probe(), as the effect context to
input_ff_create_memless(). The memoryless force-feedback core takes
ownership of that pointer and frees it with kfree() from
input_ff_destroy() (ml_ff_destroy()) when the input device is
destroyed.
Freeing a devm-managed allocation with kfree() is an invalid free, and
the same object is then released again by devres when the HID device is
torn down, a double free. As the allocation also embeds the LED class
devices, their timers and work item live on freed memory and the slab
gets corrupted. This triggers on unbind, rmmod, hot-unplug and on system
suspend, where the firmware cache walks the now-corrupt devres list.
KASAN reports:
BUG: KASAN: invalid-free in input_ff_destroy
Allocated by task N:
winwing_probe
Pass NULL as the memless context instead and fetch the driver data from
the input device in winwing_play_effect(): the HID core already stores
the hid_device as the input device's drvdata. The force-feedback core
then owns nothing that it must not free.
Fixes: 42d020b54e ("HID: winwing: Enable rumble effects")
Signed-off-by: René Onier <f3nr1l@me.com>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
When an out_fence_ptr is provided but DRM_MODE_PAGE_FLIP_EVENT is not
set, a drm_pending_vblank_event will be allocated. If later, there is an
allocation failure or another failure at setup_out_fence(), that event
will not have base.fence set and it will not be released at
complete_signaling().
Release the event and set crtc_state->event to NULL just like in the
DRM_MODE_PAGE_FLIP_EVENT case when there is a failure at
drm_event_reserve_init(). That is, prepare_signaling() releases the
event and there is nothing to be done at complete_signaling(). Use
drm_event_cancel_free() as that will also undo drm_event_reserve_init()
in case it has been called.
Reported-by: sashiko-bot@kernel.org
Closes: https://sashiko.dev/#/patchset/20260727-drm_crtc_atomic_commit_leak-v1-1-23d9948a9d7c@igalia.com?part=1
Fixes: 92c715fca9 ("drm/atomic: Fix double free in drm_atomic_state_default_clear")
Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@igalia.com>
Reviewed-by: Melissa Wen <mwen@igalia.com>
Signed-off-by: Melissa Wen <mwen@igalia.com>
Link: https://patch.msgid.link/20260826-drm_pending_vblank_event_leak-v4-1-f8de8b996b9d@igalia.com
Commit e716edafed ("HID: multitouch: Check to ensure report
responses match the request") introduced validating GET_FEATURE
responses return the requested report ID.
ASUS ROG Z13 Flow (2025) GZ302EA touchpad (USB 0b05:1a30) returns
a different report ID for Win8 feature request. Before this check,
the response was still processed and allowed device to switch into
its full Touchpad Precision mode.
After the validation, the response is discarded before
hid_report_raw_event() processes it and device remains in fallback
mode and no longer exposes ABS_MT_SLOT, ABS_MT_TOOL_TYPE or the
multi-finger BTN_TOOL_* capabilities for palm rejection.
Add a device quirk to allow the known firmware behavior for
this device while preserving report ID validation for all other
devices.
The device previously matched the generic MT_CLS_WIN_8 entry, so
base the new class on MT_CLS_WIN_8 to keep it on the same quirk set
as before the regression. MT_QUIRK_CONFIDENCE must be set
explicitly: it is normally enabled by the class name check in
mt_touch_input_mapping(), which only matches the MT_CLS_WIN_8*
names, and it is what makes ABS_MT_TOOL_TYPE available for
touchpads.
Fixes: e716edafed ("HID: multitouch: Check to ensure report responses match the request")
Signed-off-by: Lovekesh Solanki <lovekeshsolanki00@gmail.com>
Reported-by: mayhemandcoffee <mayhemandcoffee@gmail.com>
Closes: https://bugzilla.kernel.org/show_bug.cgi?id=221774
Tested-by: mayhemandcoffee <mayhemandcoffee@gmail.com>
Link: https://bugzilla.kernel.org/show_bug.cgi?id=221774
Signed-off-by: Jiri Kosina <jkosina@suse.com>
Sashiko reported that in get_boot_config_from_initrd(), a crafted initrd
with a huge bootconfig size (such as 0xFFFFFFFF) can cause the pointer
arithmetic:
data = ((void *)hdr) - size;
to wrap around on 32-bit systems (or when pointer subtraction overflows).
Because data wraps around, the subsequent bounds check:
if ((unsigned long)data < initrd_start)
evaluates to false, bypassing the check. The kernel then calls
xbc_calc_checksum(data, size), which attempts to read 4GB of memory,
hitting unmapped pages and triggering a fatal kernel page fault during
early boot. Furthermore, on 64-bit systems with an initrd > 4.29 GB, an
unbounded 32-bit size can similarly bypass the initrd_start check.
Fix this by:
1. Ensuring the initrd is at least large enough to contain the bootconfig
footer and verifying hdr is within the initrd bounds.
2. Checking that size does not exceed XBC_DATA_MAX and does not exceed
the available space between initrd_start and hdr before performing
pointer subtraction.
Link: https://lore.kernel.org/all/178905333479.213925.1358412668943562406.stgit@devnote2/
Fixes: de462e5f10 ("bootconfig: Fix to remove bootconfig data from initrd while boot")
Cc: stable@vger.kernel.org
Reported-by: Sashiko <sashiko-bot@kernel.org>
Closes: https://lore.kernel.org/all/20260910010137.EE0431F000FF@smtp.kernel.org/
Assisted-by: Antigravity:gemini-3.8-flash
Signed-off-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
Reviewed-by: Sang-Heon Jeon <ekffu200098@gmail.com>
Sashiko reported that on 32-bit systems, if an attacker crafts size in
the bootconfig footer such that adding BOOTCONFIG_FOOTER_SIZE wraps around
(for instance, if size is 0xFFFFFFFF), the size check in
load_xbc_from_initrd() can be bypassed:
if (stat.st_size < size + BOOTCONFIG_FOOTER_SIZE) {
pr_err("bootconfig size is too big\n");
return -E2BIG;
}
Furthermore, on 64-bit systems with an initrd > 4.29 GB, comparing a
corrupted 32-bit size (e.g. 0xFFFFFFFF) against
stat.st_size - BOOTCONFIG_FOOTER_SIZE can also bypass the check if
size is not bounded. Similarly, load_xbc_file() passes 64-bit stat.st_size
directly into the 32-bit int size parameter of load_xbc_fd(), truncating
large standalone files (>= 2GB).
In both cases, passing 0xFFFFFFFF to load_xbc_fd() truncates to -1,
resulting in malloc(0), an integer overflow in read(), and an
out-of-bounds null-byte write.
Fix this by:
1. Rejecting size > XBC_DATA_MAX or
size > stat.st_size - BOOTCONFIG_FOOTER_SIZE in load_xbc_from_initrd().
2. Rejecting stat.st_size > XBC_DATA_MAX in load_xbc_file() before passing
it to load_xbc_fd().
3. Checking size < 0 || size > XBC_DATA_MAX defensively in load_xbc_fd().
Link: https://lore.kernel.org/all/178905332413.213925.3179977110281463499.stgit@devnote2/
Fixes: 950313ebf7 ("tools: bootconfig: Add bootconfig command")
Cc: stable@vger.kernel.org
Reported-by: Sashiko <sashiko-bot@kernel.org>
Closes: https://lore.kernel.org/all/20260909161113.16C691F00A3A@smtp.kernel.org/
Closes: https://lore.kernel.org/all/20260910010137.EE0431F000FF@smtp.kernel.org/
Assisted-by: Antigravity:gemini-3.8-flash
Signed-off-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
Reviewed-by: Sang-Heon Jeon <ekffu200098@gmail.com>
The 'wacom_wac_pen_serial_enforce()' function may calculate and pass an
invalid offset to hid_field_extract(), resulting in memory reads at
incorrect addresses -- possibly beyond the end of the report. If a
field in the HID descriptor lists more usages than its Report Count
actually reserves space for, the function's inner 'j' will walk past
the end of the field:
for (i = 0; i < report->maxfield; i++) {
for (j = 0; j < report->field[i]->maxusage; j++) {
...
value = hid_field_extract(hdev, raw_data + 1,
offset + j * size, size);
A descriptor listing 12288 usages against Report Count 1 has the loop
extract the usage at index 12287 from bit offset 98296 -- about 12 KB
past a 2-byte received report. The value is stored in
wacom_wac->serial[0] and can reach userspace as an MSC_SERIAL event,
making this an information disclosure.
Clamp the loop to field->report_count, the number of value slots the
report holds. Value slots past the last declared usage are still
scanned; they reuse that usage (HID 1.11, 6.2.2.8).
Verified on v6.12.105 with a UHID reproducer: a 2-byte report from
such a descriptor trips KASAN before the patch and not after it.
Fixes: 8341720642 ("HID: wacom: Queue events with missing type/serial data for later processing")
Suggested-by: Jason Gerecke <killertofu@gmail.com>
Cc: stable@vger.kernel.org
Assisted-by: Claude:claude-opus-5
Assisted-by: GLM:glm-5.3
Signed-off-by: Wei Jie Law <98lawweijie@gmail.com>
Reviewed-by: Jason Gerecke <jason.gerecke@wacom.com>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
PTRACE_{PEEK,POKE}MTETAGS return -EIO rather than -EOPNOTSUPP (as
documented) when no tags are copied from/to a mapping without PROT_MTE.
This has been the behaviour since the interface was introduced, though
the original intent was to distinguish between address not being
accessible and mapped as untagged.
Update the documentation to match the implementation (de-facto ABI).
Since -EOPNOTSUPP was never returned, change the error assignment to
-EIO as well to avoid confusion.
Fixes: df9d7a22dd ("arm64: mte: Add Memory Tagging Extension documentation")
Fixes: 18ddbaa02b ("arm64: mte: ptrace: Add PTRACE_{PEEK,POKE}MTETAGS support")
Reported-by: Yury Khrustalev <yury.khrustalev@arm.com>
Cc: Will Deacon <will@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Will Deacon <will@kernel.org>
pthread_join() stores the thread's return value (a "void *", i.e.
8 bytes on 64 bit computers) into the address that is passed as second
parameter. However, the entries of thread_data are only normal "int"s,
i.e. only 4 bytes. The additional 4 bytes of the return value clobber
whatever is adjacent on the stack, i.e. other members of the thread_data
array (which will be re-written in the next iteration of the for-loop,
so that nobody noticed this problem), or another other local variable
on the stack for the last iteration. Use "intptr_t" to declare the
thread_data array entries with the correct size.
Fixes: 29f0808816 ("kselftest/arm64: check GCR_EL1 after context switch")
Cc: stable@vger.kernel.org
Signed-off-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: Will Deacon <will@kernel.org>
The Acer Nitro ANV15-41 exposes a functional UCSI ACPI PPM but
reports a UCSI VERSION value of zero.
ucsi_register() rejects a zero version with -ENODEV, leaving the
system without registered USB Type-C connectors.
The PPM works correctly when using the UCSI 1.2 layout. With UCSI
1.2 assumed, both Type-C connectors register correctly and USB Power
Delivery negotiation works.
Add a DMI-specific UCSI operation for the Acer Nitro ANV15-41 that
substitutes UCSI 1.2 only when firmware reports a zero version.
Preserve any valid non-zero firmware version.
Tested on an Acer Nitro ANV15-41 with BIOS V1.51.
Fixes: c1b0bc2dab ("usb: typec: Add support for UCSI interface")
Cc: stable <stable@kernel.org>
Assisted-by: LLM
Signed-off-by: Pannarat Wiriyaarritham <pannarat.wiriyaarritham@danielcorp.dev>
Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Link: https://patch.msgid.link/20260910023338.31816-1-pannarat.wiriyaarritham@danielcorp.dev
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The assembly for __percpu_##name##_case_##sz() and
__percpu_##name##_return_case_##sz() doesn't use the 'sfx' macro
argument to form the LSE instruction. Without 'sfx', a W register
argument will imply a 32-bit memory location, and consequently
{8,16}-bit ops will erroneously read and write 32 bits of memory when
the LSE instruction is used.
Fix this by appending 'sfx' to 'op_lse' to LSE instruction. It is not
necessary (and not valid) to append 'sfx' to 'op_llsc', as 'op_llsc' is
a register-register operation which does not access memory (and does not
take a size suffix).
Fixes: 959bf2fd03 ("arm64: percpu: Rewrite per-cpu ops to allow use of LSE atomics")
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Reviewed-by: Jinjie Ruan <ruanjinjie@huawei.com>
Cc: Ada Couprie Diaz <ada.coupriediaz@arm.com>
Cc: Ard Biesheuvel <ardb@kernel.org>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: James Morse <james.morse@arm.com>
Cc: Marc Zyngier <maz@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Vladimir Murzin <vladimir.murzin@arm.com>
Cc: Will Deacon <will@kernel.org>
Cc: Yang Shi <yang@os.amperecomputing.com>
Cc: stable@vger.kernel.org
Reviewed-by: Vladimir Murzin <vladimir.murzin@arm.com>
Signed-off-by: Will Deacon <will@kernel.org>
The arm64 implementation of this_cpu_and(pcp, val) is built in terms of
ANDNOT operations, which requires the 'val' argument to be bitwise
negated. The bitwise negation is not implemented correctly, with two
bugs described below.
(1) The bitwise negation is performed as '~val' rather than '~(val)'.
This won't always generate the expected value when 'val' is an
expression.
For example, for this_cpu_and(pcp, 1 - 1):
* 'val' is '1 - 1' ===> (int) 0x00000000
* '~val' is '~1 - 1' ===> (int) 0xfffffffd
* '~(val)' is '~(1 - 1)' ===> (int) 0xffffffff
... and thus bit[1] of 'pcp' would be preserved unexpectedly by the
ANDNOT operation.
(2) The bitwise negation is performed on 'val' before it has been cast
to (at least) the width of 'pcp'. This won't always generate the
expected value for the upper bits.
For example, for this_cpu_and(pcp, zero), where 'pcp' is a u64 and
'zero' is a u32:
* 'zero' ===> (u32) 0x00000000
* '~(zero)' ===> (u32) 0xffffffff
* '(u64)~(zero)' ===> (u64) 0x00000000ffffffff
* '~((u64)(zero))' ===> (u64) 0xffffffffffffffff
... and thus bits[63:32] of 'pcp' would be preserved unexpectedly by
the ANDNOT operation.
Fix these issues by adding brackets around 'val', and by casting 'val'
to an appropriately-sized type before bitwise negation.
Fixes: 959bf2fd03 ("arm64: percpu: Rewrite per-cpu ops to allow use of LSE atomics")
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Reviewed-by: Jinjie Ruan <ruanjinjie@huawei.com>
Tested-by: Muhammad Usama Anjum <usama.anjum@arm.com>
Acked-by: Christopher Lameter (Ampere) <cl@gentwo.org>
Cc: Ada Couprie Diaz <ada.coupriediaz@arm.com>
Cc: Ard Biesheuvel <ardb@kernel.org>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: James Morse <james.morse@arm.com>
Cc: Marc Zyngier <maz@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Vladimir Murzin <vladimir.murzin@arm.com>
Cc: Will Deacon <will@kernel.org>
Cc: Yang Shi <yang@os.amperecomputing.com>
Cc: stable@vger.kernel.org
Signed-off-by: Will Deacon <will@kernel.org>
The arm64 implementation of this_cpu_write() casts 'val' to unsigned
long. This is necessary to handle cases where 'val' is a pointer type,
and to avoid spurious compiler warnings for the (unreachable!) cases
where the pointer type would be cast to a smaller integer type.
Unfortunately, the cast is applied to 'val' rather than '(val)', which
won't always generate the expected value when 'val' is an expression.
For example, for this_cpu_write(pcp, zero - 1), where 'pcp' is a u64 and
'zero' is a u32:
* 'zero' ===> (u32) 0x00000000
* 'zero - 1' ===> (u32) 0xffffffff
* '(unsigned long)zero - 1' ===> (u64) 0xffffffffffffffff
* '(unsigned long)(zero - 1)' ===> (u64) 0x00000000ffffffff
Fix this by adding brackets around 'val'.
Fixes: 959bf2fd03 ("arm64: percpu: Rewrite per-cpu ops to allow use of LSE atomics")
Reported-by: David Laight <david.laight.linux@gmail.com>
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Reviewed-by: David Laight <david.laight.linux@gmail.com>
Reviewed-by: Jinjie Ruan <ruanjinjie@huawei.com>
Tested-by: Muhammad Usama Anjum <usama.anjum@arm.com>
Acked-by: Christopher Lameter (Ampere) <cl@gentwo.org>
Cc: Ada Couprie Diaz <ada.coupriediaz@arm.com>
Cc: Ard Biesheuvel <ardb@kernel.org>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: James Morse <james.morse@arm.com>
Cc: Marc Zyngier <maz@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Vladimir Murzin <vladimir.murzin@arm.com>
Cc: Will Deacon <will@kernel.org>
Cc: Yang Shi <yang@os.amperecomputing.com>
Cc: stable@vger.kernel.org
Reviewed-by: Lorenzo Stoakes (ARM) <ljs@kernel.org>
Signed-off-by: Will Deacon <will@kernel.org>
This is similar to commit 1537e55728 ("arm64: trans_pgd: clone only
the linear map that exists at runtime"), but in a different place.
swsusp_arch_resume() clones the kernel linear map with
trans_pgd_create_copy(..., PAGE_OFFSET, PAGE_END). PAGE_OFFSET comes
from the compile-time VA_BITS, so a CONFIG_ARM64_VA_BITS_52 kernel
booting on hardware without LPA2 -- vabits_actual is 48 and the fifth
level is folded -- hands the walk a 3.9PB window while its linear map
only spans the top 128TB.
On a VA_BITS_52 4k kernel with CONFIG_KASAN_GENERIC in a 4GB VM, I see:
swapper/0: page allocation failure: order:0, mode:0x920(GFP_ATOMIC|__GFP_ZERO)
hibernate_page_alloc+0x10/0x1c
swsusp_arch_resume+0x70/0x320
hibernation_restore+0xa4/0x138
software_resume+0x15c/0x270
PM: hibernation: Failed to load image, recovering.
PM: hibernation: resume failed (-12)
Fix it by copying the linear map that is the actual one, not the
compiled one.
Fixes: a6bbf5d4d9 ("arm64: mm: Add definitions to support 5 levels of paging")
Signed-off-by: Breno Leitao <leitao@debian.org>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Will Deacon <will@kernel.org>
When MXP_MULTIPLE_DTM_EN is TRUE, each DTM will monitor at most
two device ports. In this case, {wp_dev_sel2, wp_dev_sel} will
only use values 2'b00 and 2'b01 per DTM.
Previously the setting allowed values beyond the supported range
per DTM, which could cause each DTM to select invalid ports when
MXP_MULTIPLE_DTM_EN is TRUE.
Fix this by only setting CMN_DTM_WPn_CONFIG_WP_DEV_SEL2 when
!multi_dtm.
Fixes: 60d1504070 ("perf/arm-cmn: Support new IP features")
Signed-off-by: Shouping Wang <allen.wang@hj-micro.com>
Reviewed-by: Robin Murphy <robin.murphy@arm.com>
Signed-off-by: Will Deacon <will@kernel.org>
nf_ct_put() releases the ct->ext area inmediately, the rcu typesafe
semantics also allow to refer to the wrong conntrack from the flowtable
datapath. Hold reference on ct until flow is released after rcu grace
period.
Add rcu_barrier() on module exit path, to ensure pending flow entries
are release before module goes away.
Fixes: 0ff90b6c20 ("netfilter: nf_flow_offload: fix use-after-free and a resource leak")
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
If nf_hook_entries_insert_raw() fails, the NAT hooks get never released,
resulting in a memleak.
Postpone setting nat_proto_net->nat_hook_ops when the hooks are
registered to simplify the error path to decide whether the nat hooks
need unwinding.
Fixes: 1cd472bf03 ("netfilter: nf_nat: add nat hook register functions to nf_nat")
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Currently, a netdev chain or flowtable hooked to a device prefix can be
unintentionally deleted by a control-plane request targeting an exact
device name or even a shorter one due to the usage of min() to calculate
the length to match.
Fix this by making sure an exact device match never matches a prefix and
that both the target and the candidate have the same length during
delete operation. The add and update paths retain the existing overlap
matching to prevent a single device from matching multiple hooks.
Reported-by: Wei Fang <void0red@gmail.com>
Closes: https://lore.kernel.org/netfilter-devel/CANE+tVrDeNCHQVmsqkV2ozeBqyE3GtRDMhZgsg1bhw10yGNTRQ@mail.gmail.com/
Fixes: 6d07a28950 ("netfilter: nf_tables: Support wildcard netdev hook specs")
Signed-off-by: Fernando Fernandez Mancera <fmancera@suse.de>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
nft_nat_setup_netmap() builds the mapped address in an on-stack
union nf_inet_addr. For an IPv4 mapping it writes only the 4-byte .ip
member and the loop runs a single 32-bit iteration, but it then copies
the whole 16-byte union into range->min_addr and range->max_addr, so the
upper 12 bytes reach nf_nat_setup_info() uninitialised.
KMSAN reports an uninit-value in nf_nat_setup_info() reached from
nft_nat_eval(). The IPv6 path fills all 16 bytes and is not affected.
Zero-initialise new_addr.
Fixes: 3ff7ddb135 ("netfilter: nft_nat: add netmap support")
Signed-off-by: Theodor Arsenij Larionov Trichkine <theodorlarionov@gmail.com>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Currently, `fill_sg_entry()` splits the scatterlist using `UINT_MAX`.
This creates a non-page-aligned DMA length (`0xFFFFFFFF`) for the
first entry, resulting in non-page-aligned DMA addresses for all
subsequent entries.
While the underlying IOMMU mapping may be contiguous, hardware
DMA engines often require explicit address alignment (e.g., page,
cacheline, or storage sector boundaries). Passing unaligned
addresses and lengths can cause explicit failures in DMA descriptor
creation or silent data corruption if lower unaligned bits are
truncated.
In addition, a non-page-aligned sgl length will trigger an edge case
in `ib_umem_find_best_pgsz()`. In case of a discontinuity in later
buffers, we will have a `va` with lowest bit set to 1. That will lead
to `ib_umem_find_best_pgsz()` always return 0, and break the promise
to find best page size for the mapping on the NIC side.
Fix this by splitting the scatterlist by the largest possible page
aligned chunk within `UINT_MAX` (`ALIGN_DOWN(UINT_MAX, PAGE_SIZE)`).
This ensures all scatterlist DMA addresses and lengths remain page
aligned, while minimizing the total number of sgl entries.
Page-aligned entries allow the system to cleanly chunk payloads into
PCIe MaxPayloadSize (MPS) (e.g., 128 bytes, 256 bytes, 512 bytes).
As a result, this may help reduce TLP fragmentation in P2P transfers
and alleviate potential congestion within a logical PCIe switch
partition, especially when Relaxed Ordering is not possible due to
hardware constraints.
Reported-by: sashiko-bot <sashiko-bot@kernel.org>
Closes: https://lore.kernel.org/all/20260609165431.778061F00893@smtp.kernel.org/
Fixes: 3aa31a8bb1 ("dma-buf: provide phys_vec to scatter-gather mapping routine")
Cc: stable@vger.kernel.org
Reviewed-by: Leon Romanovsky <leonro@nvidia.com>
Signed-off-by: David Hu <xuehaohu@google.com>
Signed-off-by: Christian König <christian.koenig@amd.com>
Link: https://lore.kernel.org/r/20260901170849.4052816-3-dhu@x6u.co
In case MMIO size is bigger than 4G and peer2peer DMA goes
through host bridge, we trigger a code path that assigns the
total linked IOVA (which is greater than 4G) to mapped_len.
Previously, `mapped_len` was declared as 32-bit `unsigned int`.
When accumulating `size_t` lengths, this leads to a silent wrap-around.
This truncation causes truncated lengths to be passed to functions
like `fill_sg_entry()`.
Fix this by changing `mapped_len` to `size_t` (64-bit). While
at it, fix similar potential overflow issues in `calc_sg_nents`
by using `check_add_overflow()` for `nents` and using
`unsigned int` for the loop iterator in `fill_sg_entry` to match.
Fixes: 3aa31a8bb1 ("dma-buf: provide phys_vec to scatter-gather mapping routine")
Cc: stable@vger.kernel.org
Cc: iommu@lists.linux.dev
Reviewed-by: Pranjal Shrivastava <praan@google.com>
Reviewed-by: Kevin Tian <kevin.tian@intel.com>
Reviewed-by: Leon Romanovsky <leon@kernel.org>
Signed-off-by: David Hu <xuehaohu@google.com>
Signed-off-by: Christian König <christian.koenig@amd.com>
Link: https://lore.kernel.org/r/20260901170849.4052816-2-dhu@x6u.co
Commit 646013f513 ("dma-buf: enable DMABUF_DEBUG by default on DEBUG
kernels") changed the default of DMABUF_DEBUG to "y if DEBUG", but no
Kconfig symbol DEBUG exists, so the option has had no default since.
Use DEBUG_KERNEL, the Kconfig symbol for a debug kernel.
Fixes: 646013f513 ("dma-buf: enable DMABUF_DEBUG by default on DEBUG kernels")
Assisted-by: LLM
Signed-off-by: Karl Mehltretter <kmehltretter@gmail.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Christian König <christian.koenig@amd.com>
Link: https://lore.kernel.org/r/20260907020015.24719-1-kmehltretter@gmail.com
A couple of core fixes, the rest usual mix of driver issues that surfaced
from merge window until now.
core
- buffer: Ensure that when using the iio_push_to_buffers_with_ts_unaligned()
that the full buffer is zeroed.
- trigger: Cancel reenable_work() before freeing the trigger that might be
re-enabled.
dma-buffer
- Fix wrong sizing for a mapped sg_list. If an IOMMU was using a fused
entry the mapping might walk off the end.
adi,ade9000
- Wait for power up before requesting interrupts.
- Fix overlap in scan index for current and voltage channels.
- Ensure Phase C dip event included in IRQ1 handler.
adi,adf4377
- Initialize all of a clk_init_data.
adi,adis*
- Ensure debugfs reads are finished before unbind.
adi,axi-adc
- Initialize mutex.
adi,admv1013
- Ensure mutex is intialized before notifier that might use it is
registered.
- Fix wrong channel field used for read_raw.
allwinner,sun4i
- Drop a pm_runtime_put() when there was no get.
- Ensure correct cleanup on driver probe fail due to any issues with
the thermal zone.
aspeed,adc,
- Don't eat reset deassert errors.
awinic,aw96103
- Make sure firmware length is validated rather than blindly trusting
it.
bosch,bmp280
- Fix out of bounds lookup of sampling frequency due to indexing based on
elements in matrix rather than just the correct dimension.
invensense,timestamp library
- Ensure time estimate doesn't invert wrt to current time in a corner
case occasionally seen.
kionix,kx022a
- Off by one in array boundary check.
- Close a memory leak and state corruption in error path.
maxim,max1363
- Sign extend bipolar values to ensure correct reporting to userspace.
maxim,max30102
- Fix NULL dereference by checking there is data in the FIFO before
trying to do anything with it.
microchip,mcp47a1
- Ensure highest possible value actually settable.
pulsed-light,lidar-lite
- Don't leak the IIO device registration if runtime pm setup fails
particularly as it was being freed.
rockchip,saradc
- Fix wrong fallback compatible for rv1106 that lead to trying
to use too many channels (correct support will follow next
merge window)
rohm,bd79124
- Correct limit used for rising alarms.
- Fix which registers related to limits are used in initialization.
- Apply GPIO mask to allow subset of GPIOs to be toggled.
- Add missing regmap error handling in a few places.
- Ensures scale is read only.
rohm,bm1390
- Don't silently eat a data read error.
rohm,bu27034
- Don't silently eat error when reading gain.
- Ensure we infinite delay doesn't happen on error.
semtech,sx9324
- Fix wrong proximity channel resolution.
sharp,gp2ap020a00f
- Make sure to drain irq_work in remove path.
st,vl5310x
- Ensure direct mode is claimed for read_raw avoiding corruption
of buffered accesses.
vishay,vcnl3020
- Use write bits for ISR mask and ensure right event reported.
vti,sca3000
- Fix up a condition check for the frequency divider.
xilinx,xadc
- Swap registration of cleanup of work with that of irq
to ensure that no irqs can cause work that has been freed
to be queued.
x-powers,axp288
- Add bias override quirk for Haier HV103H. Fix because we
used to always override then moved to trusting the firmware
setup - which fixed some boards, but broke others.
-----BEGIN PGP SIGNATURE-----
iQJFBAABCgAvFiEEbilms4eEBlKRJoGxVIU0mcT0FogFAmqjNCIRHGppYzIzQGtl
cm5lbC5vcmcACgkQVIU0mcT0FohFeA//apYJFiljUxBhFP1nxlsvOgYVmz2ovOR7
OdG+0smJdWTFM2b8Pu5MA8b/ls48mjyJHCueqe+OP8e7xGhiT0jFObzrJRHomJ72
66XmAE/X3cYC6BPChtU6fn65CnxrHZWhBVzEsO2CxQ8MM5nbhQsl+XjgUG3jCach
DcZIdJAstgi8Ao3ju364saj9k9o3DF5IwHW5Y0bIq3H50X67oEOBo5vfIcFUjnYj
RZHzvmwBnt9ar5ivKPPrIqv0j0OccRvCzp6X6A1IO8aeHJe2Ow+IOqFGJhxPYydr
YHKo5cJZtxYK4Re6eFqATPe7boKuJJIxhU5wimT10pLKA38bBbqQlSoq9P/vvCrW
MLCcRE83pHwS0vxjiJWfeZVdkfQmDnNtpBXoiCvk6iucsoXg3rniuzC3RG9iUiMx
Xr1DiQ5QRJdQrSRCWqfJpQDnMrAJoXk9dDc1e1LFyKKPjvsI0jZJdfmsCdf8MNHS
ssC7XHaLMpqIHYMsASFQLOoO1Bw6khcyxLeAVFxwNWQmVIOnQvbB9Jv7WxmR5nse
CuC1NKgpnaKvH/vQYgCNWOP8TVAaLu3iUuLx6Q6zzS8MmnjkvsEn8zeQI31pKtun
6rdG9gC/pA2qsu0Kt0uwMKuGVQNF1qTT4Sf3ZYQhoJ9iYW7liQFytz4ooptjszNM
IDv8BGnVT7c=
=gbfP
-----END PGP SIGNATURE-----
Merge tag 'iio-fixes-for-7.3a' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/jic23/iio into char-misc-linus
Jonathan writes:
IIO: 1st set of fixes for the 7.3 cycle.
A couple of core fixes, the rest usual mix of driver issues that surfaced
from merge window until now.
core
- buffer: Ensure that when using the iio_push_to_buffers_with_ts_unaligned()
that the full buffer is zeroed.
- trigger: Cancel reenable_work() before freeing the trigger that might be
re-enabled.
dma-buffer
- Fix wrong sizing for a mapped sg_list. If an IOMMU was using a fused
entry the mapping might walk off the end.
adi,ade9000
- Wait for power up before requesting interrupts.
- Fix overlap in scan index for current and voltage channels.
- Ensure Phase C dip event included in IRQ1 handler.
adi,adf4377
- Initialize all of a clk_init_data.
adi,adis*
- Ensure debugfs reads are finished before unbind.
adi,axi-adc
- Initialize mutex.
adi,admv1013
- Ensure mutex is intialized before notifier that might use it is
registered.
- Fix wrong channel field used for read_raw.
allwinner,sun4i
- Drop a pm_runtime_put() when there was no get.
- Ensure correct cleanup on driver probe fail due to any issues with
the thermal zone.
aspeed,adc,
- Don't eat reset deassert errors.
awinic,aw96103
- Make sure firmware length is validated rather than blindly trusting
it.
bosch,bmp280
- Fix out of bounds lookup of sampling frequency due to indexing based on
elements in matrix rather than just the correct dimension.
invensense,timestamp library
- Ensure time estimate doesn't invert wrt to current time in a corner
case occasionally seen.
kionix,kx022a
- Off by one in array boundary check.
- Close a memory leak and state corruption in error path.
maxim,max1363
- Sign extend bipolar values to ensure correct reporting to userspace.
maxim,max30102
- Fix NULL dereference by checking there is data in the FIFO before
trying to do anything with it.
microchip,mcp47a1
- Ensure highest possible value actually settable.
pulsed-light,lidar-lite
- Don't leak the IIO device registration if runtime pm setup fails
particularly as it was being freed.
rockchip,saradc
- Fix wrong fallback compatible for rv1106 that lead to trying
to use too many channels (correct support will follow next
merge window)
rohm,bd79124
- Correct limit used for rising alarms.
- Fix which registers related to limits are used in initialization.
- Apply GPIO mask to allow subset of GPIOs to be toggled.
- Add missing regmap error handling in a few places.
- Ensures scale is read only.
rohm,bm1390
- Don't silently eat a data read error.
rohm,bu27034
- Don't silently eat error when reading gain.
- Ensure we infinite delay doesn't happen on error.
semtech,sx9324
- Fix wrong proximity channel resolution.
sharp,gp2ap020a00f
- Make sure to drain irq_work in remove path.
st,vl5310x
- Ensure direct mode is claimed for read_raw avoiding corruption
of buffered accesses.
vishay,vcnl3020
- Use write bits for ISR mask and ensure right event reported.
vti,sca3000
- Fix up a condition check for the frequency divider.
xilinx,xadc
- Swap registration of cleanup of work with that of irq
to ensure that no irqs can cause work that has been freed
to be queued.
x-powers,axp288
- Add bias override quirk for Haier HV103H. Fix because we
used to always override then moved to trusting the firmware
setup - which fixed some boards, but broke others.
* tag 'iio-fixes-for-7.3a' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/jic23/iio: (42 commits)
iio: proximity: vcnl3020: fix ISR bitmask check in IRQ handler
iio: proximity: vl53l0x-i2c: claim direct mode for raw reads
iio: dac: mcp47a1: Allow full-scale output
iio: accel: kionix-kx022a: Prevent memory leak and fix state
iio: light: rohm-bu27034: Fix infinite delay on error
iio: adc: sun4i-gpadc-iio: clean up on thermal zone registration failure
iio: adc: sun4i-gpadc-iio: drop underflowing pm_runtime_put() calls
iio: adc: axp288: Add TS bias override for Haier HV103H
dt-bindings: iio: adc: rockchip-saradc: Fix RV1106 compatible
dt-bindings: iio: adc: rockchip-saradc: Group single-entries into an enum list
iio: inv_sensors: fix estimated value larger than interrupt timestamp
iio: adc: aspeed: propagate reset deassert errors
iio: buffer-dmaengine: fix sg entry iteration when building dma_vecs
iio: proximity: pulsedlight: fix iio_device left registered on PM setup failure
iio: trigger: cancel reenable_work before freeing trigger
iio: frequency: admv1013: fix wrong channel field used in admv1013_read_raw()
iio: accel: sca3000: fix frequency divider condition check
iio: admv1013: initialize callback mutex before registering notifier
iio: gyro: adis16136: fix unprotected debugfs reads
iio: imu: adis16400: fix unprotected debugfs reads
...
Here is a fix for a long-standing ioctl-hangup race and a couple of
fixes for port lifetime issues that can lead to NULL-pointer
dereferences when disconnecting devices or deregistering drivers.
Included are also a fix for a related dynamic id leak and some new modem
device ids.
All have been in linux-next with no reported issues.
-----BEGIN PGP SIGNATURE-----
iJEEABYKADkWIQQHbPq+cpGvN/peuzMLxc3C7H1lCAUCaqPLfBsUgAAAAAAEAA5t
YW51MiwyLjUrMS4xMiwyLDIACgkQC8XNwux9ZQgVZQEAwz27kdiSWAEj0o0RXM5Y
mw7KaLrHveCOY57qg8SmbCEBAJxB9HlcuPJIG5Aqp8S5zPqI3h7nfz0xeT0MEawI
nCMM
=Ptq2
-----END PGP SIGNATURE-----
Merge tag 'usb-serial-7.3-rc3' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial into usb-linus
Johan writes:
USB serial fixes for 7.3-rc3
Here is a fix for a long-standing ioctl-hangup race and a couple of
fixes for port lifetime issues that can lead to NULL-pointer
dereferences when disconnecting devices or deregistering drivers.
Included are also a fix for a related dynamic id leak and some new modem
device ids.
All have been in linux-next with no reported issues.
* tag 'usb-serial-7.3-rc3' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial:
USB: serial: fix ioctl hangup race
USB: serial: use iterator for driver deregistration
USB: serial: fix driver deregistration order
USB: serial: fix dynamic id driver deregistration race
USB: serial: fix port tear down use-after-free
USB: serial: option: add Compal EXC-T1 support
USB: serial: option: add Quectel RG660QB
USB: serial: option: add Compal EXM-G1x support
USB: serial: option: add support for SIMCom SIM8260C
USB: serial: option: add Quectel EG060W
Commit 8277a12d0d ("dma-pool: track decrypted atomic pools and select
them via attrs") exposed an issue with force_dma_unencrypted() on
systems using host memory encryption.
force_dma_unencrypted() checks whether the device DMA mask can address
the encryption bit and, if not, requires DMA allocations to use
unencrypted memory. However, this check is not applicable when the
device is using the IOMMU. In that case, the device DMA mask constrains
the IOVA seen by the device, not the backing physical address, so it
does not need to cover the C-bit.
This currently causes dma_alloc_attrs() to set
__DMA_ATTR_ALLOC_CC_SHARED for such devices. iommu_dma_alloc() does not
support that attribute and rejects the allocation, causing DMA
allocations to fail.
Do not force DMA allocations to be unencrypted when the device is using
the IOMMU. This allows the IOMMU to map the encrypted physical pages as
before and avoids incorrectly requesting CC_SHARED allocations.
Fixes: 8277a12d0d ("dma-pool: track decrypted atomic pools and select them via attrs")
Reported-by: Timo Witte <timo.witte@gmail.com>
Closes: https://lore.kernel.org/all/CANB4YXS=Nf-co3t8eMHtqrW4sn=1BDcP6o=EoTrgZm0WYMYTyw@mail.gmail.com/
Signed-off-by: Aneesh Kumar K.V (Arm) <aneesh.kumar@kernel.org>
Link: https://lore.kernel.org/r/20260908113232.247457-1-aneesh.kumar@kernel.org
[mszyprow: adjusted url and changed 'link' tag to the 'closes' one]
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Rearming a queued timer with nonzero slack can leave the timerqueue out
of order. remove_and_enqueue_same_base() checks the new soft expiry
against its neighbours' hard expiries, then stores the new hard expiry
in the node without requeueing it.
For example, with A at 10 and B at 20, rearming A at 11 with slack 30
passes the neighbour check but leaves A's hard expiry of 41 before B's
20. The same function also caches the soft expiry in base->expires_next
when updating or inserting the first timer, giving next-event selection
an earlier deadline than the queue head's hard expiry.
Set the timer expiry before handling the queue. Use its stored hard
expiry for the in-place ordering check and both updates to
base->expires_next.
The early update is safe because remove_and_enqueue_same_base() runs
with base->cpu_base->lock held. The lock keeps the queue stable while
hrtimer_can_update_in_place() checks the new expiry against both
neighbours. If the check fails, timerqueue_linked_del() removes the node
without comparing expiry values before it is reinserted.
Fixes: eddffab828 ("hrtimer: Keep track of first expiring timer per clock base")
Fixes: 343f2f4dc5 ("hrtimer: Try to modify timers in place")
Signed-off-by: Andrea Parri <parri.andrea@gmail.com>
Signed-off-by: Thomas Gleixner <tglx@kernel.org>
Assisted-by: LLM
Cc: stable@vger.kernel.org
Link: https://patch.msgid.link/20260910143442.2018-1-parri.andrea@gmail.com
drm/i915 fixes for v7.3-rc3:
- Fix a memleak on perf config query error path
- Fix UHBR SST SDP splitting when sink doesn't support it
Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Jani Nikula <jani.nikula@intel.com>
Link: https://patch.msgid.link/27458ccc4d6be77a0d440f32279586711f3294f0@intel.com
LOLLM pointed out a race condition in xrep_findparent_scan -- the
directory live update hook holds the directory ILOCK when it calls the
xchk_iscan_want_live_update predicate to figure out if it needs to
remember the live update, but xrep_findparent_scan drops the directory
ILOCK before advancing the cursor. Therefore, it's possible for a live
update to check the scan cursor after the scan drops the ILOCK but
before the scan updates its cursor. If this happens, we'll fail to
record the live update. Fix this by moving the cursor update logic
inside xrep_findparent_walk_directory.
Note that for non-directories it's ok to advance the cursor without
holding any ILOCK because the findparent scan only cares about directory
parents, not the children.
Cc: stable@vger.kernel.org # v6.10
Fixes: a07b455762 ("xfs: scan the filesystem to repair a directory dotdot entry")
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Assisted-by: LOLLM # finding obvious bugs
Reviewed-by: Carlos Maiolino <cmaiolino@redhat.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Carlos Maiolino <cem@kernel.org>
LOLLM noticed that xfs_parent_removename only partially initializes the
passed-in parent pointer arguments object. In the directory tree repair
code, we could decide to remove multiple links to a file, so we don't
want state from one call to bleed into the next one. Zero the whole
thing explicitly.
Cc: stable@vger.kernel.org # v6.10
Fixes: 3f31406aef ("xfs: fix corruptions in the directory tree")
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Assisted-by: LOLLM # finding obvious bugs
Reviewed-by: Carlos Maiolino <cmaiolino@redhat.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Carlos Maiolino <cem@kernel.org>
xrep_dir_replay_removename is the function that replays a directory
entry removal from sc->ip into the temporary directory so that when we
swap the contents of sc->tempip and sc->ip, the directory is correct.
LOLLM noticed that we were passing the wrong inode pointer into
xrep_dir_init_args. It doesn't make sense to set rd->args.dp to
rd->args.dp so let's fix this.
Cc: stable@vger.kernel.org # v6.10
Fixes: 8559b21a64 ("xfs: implement live updates for directory repairs")
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Assisted-by: LOLLM # finding obvious bugs
Reviewed-by: Carlos Maiolino <cmaiolino@redhat.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Carlos Maiolino <cem@kernel.org>
xchk_should_terminate can turn its @error argument into -EINTR if the
user is sitting on ^C. Unfortunately, this code here turns that into a
0 return, which isn't quite correct. LOLLM complains about this, though
I think it's a very minor matter because the only way -EINTR happens is
if there's a fatal signal.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Assisted-by: LOLLM # finding obvious bugs
Reviewed-by: Carlos Maiolino <cmaiolino@redhat.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Carlos Maiolino <cem@kernel.org>
LOLLM points out that xchk_bmap_xref_rmap_cow skips the cross-reference
if the data-section rmapbt cursor is not present. However, this is
broken for realtime file data fork scanning, because they will have an
rtrmapbt cursor and not an rmapbt cursor. Fix the behavior by removing
the cursor checks because xchk_bmap_get_rmap already accounts for that.
Cc: stable@vger.kernel.org # v6.14
Fixes: 037a44d827 ("xfs: cross-reference the realtime rmapbt")
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Assisted-by: LOLLM # finding obvious bugs
Reviewed-by: Carlos Maiolino <cmaiolino@redhat.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Carlos Maiolino <cem@kernel.org>
LOLLM points out that the superblock scrubber doesn't check the new
fields that were added for internal realtime volumes when we added zoned
device support.
Cc: stable@vger.kernel.org # v6.15
Fixes: 2167eaabe2 ("xfs: define the zoned on-disk format")
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Assisted-by: LOLLM # finding obvious bugs
Reviewed-by: Carlos Maiolino <cmaiolino@redhat.com>
Signed-off-by: Carlos Maiolino <cem@kernel.org>
Whilst running QA on XFS for-next as of 7.3-rc2 with MKFS_OPTIONS="-n
size=8192", I observed the following (trimmed) dmesg splat:
XFS: Assertion failed: args->total >= dp->i_nblocks - nblks, file: fs/xfs/libxfs/xfs_da_btree.c, line: 2387
WARNING: fs/xfs/xfs_message.c:104 at assfail+0x46/0x4a [xfs], CPU#0: xfs_scrub/1426511
CPU: 0 UID: 0 PID: 1426511 Comm: xfs_scrub Tainted: G W 7.3.0-rc2-djwx #rc2 PREEMPT(lazy) 6e418570b606a39783b0e7e7b30dc407b965f9e8
Tainted: [W]=WARN
RIP: 0010:assfail+0x46/0x4a [xfs]
RSP: 0018:ffffc900010d7890 EFLAGS: 00010246
RAX: 0000000000000000 RBX: 0000000000000000 RCX: 00000000ffffffd1
RDX: 0000000000000000 RSI: 0000000000000021 RDI: ffffffffa059fd38
RBP: 0000000000000002 R08: 0000000000000000 R09: 0000000000000000
R10: 000000000000000a R11: 000000007fffffff R12: ffffc900010d7940
R13: ffff888368d8f980 R14: ffffc900010d7a48 R15: ffffc900010d78d0
FS: 00007f445c5ce680(0000) GS:ffff8884a97ea000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f443803b9a8 CR3: 0000000107a4b000 CR4: 00000000003506f0
Call Trace:
<TASK>
xfs_da_grow_inode_int+0x2e0/0x300 [xfs 5de2257e14108c136f11317e6bbb8ac77efd392c]
xfs_dir2_grow_inode+0x6e/0x150 [xfs 5de2257e14108c136f11317e6bbb8ac77efd392c]
xfs_dir2_sf_to_block+0x149/0x870 [xfs 5de2257e14108c136f11317e6bbb8ac77efd392c]
xrep_dir_swap_prep+0xe2/0x110 [xfs 5de2257e14108c136f11317e6bbb8ac77efd392c]
xrep_dir_swap+0xfb/0x2f0 [xfs 5de2257e14108c136f11317e6bbb8ac77efd392c]
xrep_dir_rebuild_tree+0x99/0x100 [xfs 5de2257e14108c136f11317e6bbb8ac77efd392c]
xrep_directory+0x83/0x1c0 [xfs 5de2257e14108c136f11317e6bbb8ac77efd392c]
xrep_attempt+0x4f/0x1e0 [xfs 5de2257e14108c136f11317e6bbb8ac77efd392c]
xfs_scrub_metadata+0x393/0x5b0 [xfs 5de2257e14108c136f11317e6bbb8ac77efd392c]
xfs_ioc_scrubv_metadata+0x306/0x570 [xfs 5de2257e14108c136f11317e6bbb8ac77efd392c]
xfs_file_ioctl+0xa4f/0x1150 [xfs 5de2257e14108c136f11317e6bbb8ac77efd392c]
__x64_sys_ioctl+0x76/0xc0
do_syscall_64+0x7a/0x3b0
entry_SYSCALL_64_after_hwframe+0x4b/0x53
This is a consequence of commit 0fe77e5758, which added the
following assertion to xfs_da_grow_inode_int:
ASSERT(args->total >= dp->i_nblocks - nblks);
Tracing this back to xrep_dir_swap_prep, I noticed that the xfs_da_args
object that's passed to xfs_dir2_sf_to_block sets args->total to 1.
This is incorrect because mkfs set the directory block size to 8k and
the filesystem block size to 4k. In other words, args->total should be
2 here, not 1.
Dave Chinner tripped over the same problem with the same branch through
a different channel -- his test setup set the fs block size to 1k, in
which case the directory block size is still set to 4k. Here,
args->total should be 4.
Changing the assignment of args->total to sc->mp->m_dir_geo->fsbcount
makes the assertion go away, but that isn't a complete fix. In
xrep_tempexch_estimate, we also incorrectly assume that a shortform
conversion requires 1 fsblock when it should be m_dir_geo->fsbcount.
Without that, we can under-reserve space in the transaction and cause a
filesystem shutdown.
Note that the xfs_dabuf_nfsb helper will compute the correct value for
directories and xattr, so we use that instead of open-coding the logic.
Also fix xrep_xattr_swap_prep to assign args->total via xfs_dabuf_nfsb
to avoid one logic bomb if we ever support multi-fsblock attrs.
Cc: stable@vger.kernel.org # v6.10
Cc: floss@jetm.me
Reported-by: dgc@kernel.org
Fixes: 629fdaf5f5 ("xfs: use atomic extent swapping to fix user file fork data")
Tripped-by: 0fe77e5758 ("xfs: assert the reservation covers each da fork growth")
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Carlos Maiolino <cmaiolino@redhat.com>
Signed-off-by: Carlos Maiolino <cem@kernel.org>
