Chen-Yu Tsai [Tue, 24 Mar 2026 16:43:52 +0000 (00:43 +0800)]
soc: sunxi: sram: Allow SRAM to be claimed multiple times
On the H616, the SRAM C region is an alias mapping to part of the VE
SRAM (accessible in whole at a different address) and part of the DE
SRAM (otherwise unaccessible). As such both the VE and DE need to claim
this SRAM region to prevent access from the CPU.
The SRAM claim API is designed so that a "claim" routes the SRAM to the
peripheral device, disabling access from the CPU. So long as the written
register value is the same for all the claimants involved, allowing
multiple or repeated claims is trivial. This is indeed the case for all
supported SRAM regions. The only known SRAM region to have multiple
different settings is the SRAM C2 region; this can be claimed by the AE,
CE, or ACE (assumed to be AE + CE). This region is not supported, and
likely will never be needed nor supported, as there is no documentation
for the peripherals involved.
Change the SRAM region "claimed" field from a boolean to a reference
count. A claim will increment the count, while a release decreases it.
The first claim will trigger the register value write. The driver
otherwise behaves as before.
Chen-Yu Tsai [Tue, 24 Mar 2026 16:43:50 +0000 (00:43 +0800)]
dt-bindings: sram: sunxi-sram: Add H616 SRAM regions
The Allwinner H616 has two switchable peripheral SRAM regions:
- The VE SRAM is a 2 MB dedicated SRAM for the Video Engine. CPU access
to this region is enabled by default. CPU access can be disabled,
after which reads will show the same stale value for all addresses,
while writes are ignored.
The mux value for this region is different from previous generations.
- The SRAM C region is an alias of the first 128 KB of VE SRAM, plus 64
KB of DE SRAM. The latter is otherwise unaccessible from the CPU. When
CPU access is disabled, the whole region reads as zero, while writes
are ignored.
The mux value for this region is the same as on the A64 and H6.
Chen-Yu Tsai [Tue, 24 Mar 2026 16:43:49 +0000 (00:43 +0800)]
dt-bindings: sram: Document Allwinner H616 VE SRAM
The Allwinner H616 has two switchable peripheral SRAM regions:
- The VE SRAM is a 2 MB dedicated SRAM for the Video Engine. CPU access
to this region is enabled by default. CPU access can be disabled,
after which reads will show the same stale value for all addresses,
while writes are ignored.
The mux value for this region is different from previous generations,
and thus needs a completely new compatible.
- The SRAM C region is an alias of the first 128 KB of VE SRAM, plus 64
KB of DE SRAM. The latter is otherwise unaccessible from the CPU. When
CPU access is disabled, the whole region reads as zero, while writes
are ignored.
The mux value for this region is the same as on the A64 and H6. The
existing compatible for the A64 already covers this.
Add the compatible for the VE SRAM to the list of covered compatibles in
the generic SRAM region binding.
Revert b0e85c3c8554 ("PCI: Add Kconfig options for MPS/MRRS strategy"),
which allowed build-time selection of the "off", "default", "safe",
"performance", or "peer2peer" strategies for MPS and MRRS configuration.
These strategies can be selected at boot-time using the
"pci=pcie_bus_tune_*" kernel parameters.
Per the discussion mentioned below, these Kconfig options were added to
work around a hardware defect in a WiFi device used in a cable modem. The
defect occurred only when the device was configured with MPS=128, and
Kconfig was a way to avoid that setting. It was easier for the modem
vendor to use Kconfig and update the kernel image than to change the kernel
parameters.
Neither Kconfig nor kernel parameters are a complete solution because the
broken WiFi device may be used in other systems where it may be configured
with MPS=128 and be susceptible to the defect.
Remove the Kconfig settings to simplify the MPS code. If we can identify
the WiFi device in question, we may be able to make a generic quirk to
avoid the problem on all system.
This is not a fix and should not be backported to previous kernels.
Matt Evans [Thu, 23 Apr 2026 17:30:51 +0000 (10:30 -0700)]
PCI/P2PDMA: Avoid returning a provider for non_mappable_bars
Extend the checks in pcim_p2pdma_init() and pcim_p2pdma_provider() to
exclude functions that have pdev->non_mappable_bars set.
Consumers such as VFIO were previously able to map these for access by the
CPU or P2P. Update the comment on non_mappable_bars to show it refers to
any access, not just userspace CPU access.
Fixes: 372d6d1b8ae3c ("PCI/P2PDMA: Refactor to separate core P2P functionality from memory allocation") Suggested-by: Alex Williamson <alex@shazbot.org> Signed-off-by: Matt Evans <mattev@meta.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Niklas Schnelle <schnelle@linux.ibm.com> Reviewed-by: Alex Williamson <alex@shazbot.org> Link: https://patch.msgid.link/20260423173051.1999679-1-mattev@meta.com
PCI/pwrctrl: Do not try to power on/off devices that don't need pwrctrl
pci_pwrctrl_is_required() detects whether a device needs PCI pwrctrl
support. It is currently used in pci_pwrctrl_create_device(), but not in
pci_pwrctrl_power_{on/off}_device() APIs. This leads to pwrctrl core trying
to power on/off incompatible devices like USB hub downstream ports defined
in DT.
Add this check to prevent pwrctrl core from poking at wrong devices.
Fixes: b35cf3b6aa1e ("PCI/pwrctrl: Add APIs to power on/off pwrctrl devices") Reported-by: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com> Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
[bhelgaas: split pci_pwrctrl_is_required() move to separate patch] Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com> Link: https://patch.msgid.link/20260421104102.12322-1-manivannan.sadhasivam@oss.qualcomm.com
Marco Nenciarini [Fri, 17 Apr 2026 13:24:37 +0000 (15:24 +0200)]
PCI/IOV: Skip VF Resizable BAR restore on read error
sriov_restore_vf_rebar_state() uses the VF Resizable BAR Control register
to decide how many VF BARs to restore (nbars) and which VF BAR each
iteration addresses (bar_idx). bar_idx indexes into dev->sriov->barsz[],
which has only PCI_SRIOV_NUM_BARS (6) entries.
When a device does not respond, config reads typically return
PCI_ERROR_RESPONSE (~0). Both fields are 3 bits wide, so nbars and bar_idx
both evaluate to 7. The barsz[] access then goes out of bounds. UBSAN
reports this as:
UBSAN: array-index-out-of-bounds in drivers/pci/iov.c:948:51 index 7 is out of range for type 'resource_size_t [6]'
Observed on an NVIDIA RTX PRO 1000 GPU (GB207GLM) that stopped responding
during a failed GC6 power state exit. The subsequent pci_restore_state()
invoked sriov_restore_vf_rebar_state() while config reads returned
0xffffffff, triggering the splat.
Bail out if any VF Resizable BAR Control read returns PCI_ERROR_RESPONSE.
No further VF BARs are touched, which is safe because a config read that
returns PCI_ERROR_RESPONSE indicates the device is unreachable and
restoration is pointless. This mirrors the guard in
pci_restore_rebar_state().
Marco Nenciarini [Fri, 17 Apr 2026 13:24:36 +0000 (15:24 +0200)]
PCI: Skip Resizable BAR restore on read error
pci_restore_rebar_state() uses the Resizable BAR Control register to decide
how many BARs to restore (nbars) and which BAR each iteration addresses
(bar_idx).
When a device does not respond, config reads typically return
PCI_ERROR_RESPONSE (~0). Both fields are 3 bits wide, so nbars and bar_idx
both evaluate to 7, past the spec's valid ranges for both fields.
pci_resource_n() then returns an unrelated resource slot, whose size is
used to derive a nonsensical value written back to the Resizable BAR
Control register.
Bail out if any Resizable BAR Control read returns PCI_ERROR_RESPONSE. No
further BARs are touched, which is safe because a config read that returns
PCI_ERROR_RESPONSE indicates the device is unreachable and restoration is
pointless.
PCI: Stop setting cached power state to 'unknown' on unbind
When a PCI device is unbound from its driver, pci_device_remove() sets the
cached power state in pci_dev->current_state to PCI_UNKNOWN. This was
introduced by commit 2449e06a5696 ("PCI: reset pci device state to unknown
state for resume") to invalidate the cached power state in case the system
is subsequently put to sleep.
For bound devices, the cached power state is set to PCI_UNKNOWN in
pci_pm_suspend_noirq(), immediately before entering system sleep.
Extend to unbound devices for consistency.
This obviates the need to change the cached power state on unbind, so stop
doing so.
ntfs: fix error handling in ntfs_write_iomap_end_resident()
When ntfs_attr_get_search_ctx() fails and returns NULL, the function
returned early without calling put_page(ipage).
Fix this by jumping to err_out label on error. The err_out path now
properly releases the page and the mutex, with a NULL check for
the search context.
Reported-by: DaeMyung Kang <charsyam@gmail.com> Signed-off-by: Namjae Jeon <linkinjeon@kernel.org>
Alexey Klimov [Wed, 25 Mar 2026 00:26:32 +0000 (00:26 +0000)]
arm64: dts: exynos850: Add syscon-poweroff node
Without poweroff node Exynos850-based board continue to draw current
(around ~60 mA with my test setup) after poweroff. Kernel also reports
different lockup problems and RCU stalls warnings continuosly after
last kernel messages about hardware being switched off.
Turns out we missed a write to PMU's PS_HOLD_CONTROL (PMU + 0x30c)
register that actually switches the SoC off.
Add poweroff node that implements this.
With this change the current draw after power off is in range of few
milliampers and lockup messages are no more.
ntfs: fix VCN overflow in ntfs_mapping_pairs_decompress()
In ntfs_mapping_pairs_decompress(), lowest_vcn is read from
on-disk metadata and used as the initial vcn without validation.
A malformed value can introduce an invalid (e.g. negative) vcn,
corrupting the runlist from the start.
Additionally, the accumulation
vcn += deltaxcn
does not check for s64 overflow. A crafted mapping pairs array
can wrap vcn to a negative value, breaking the monotonically-
increasing invariant relied upon by ntfs_rl_vcn_to_lcn() and
related helpers.
Fix this by validating lowest_vcn and using check_add_overflow()
for vcn accumulation.
DaeMyung Kang [Sun, 26 Apr 2026 04:02:32 +0000 (13:02 +0900)]
ntfs: fix WSL symlink target leak on reparse failure
ntfs_reparse_set_wsl_symlink() converts the symlink target into an
allocated NLS string and transfers ownership to ni->target only after
ntfs_set_ntfs_reparse_data() succeeds. If setting the reparse data fails,
the converted target is left unreferenced and leaks.
Free the converted target on the reparse update failure path. Use kfree()
for the other local failure path as well, matching the ntfs_ucstonls()
allocation contract.
Fixes: fc053f05ca28 ("ntfs: add reparse and ea operations") Signed-off-by: DaeMyung Kang <charsyam@gmail.com> Reviewed-by: Hyunchul Lee <hyc.lee@gmail.com> Signed-off-by: Namjae Jeon <linkinjeon@kernel.org>
DaeMyung Kang [Sun, 26 Apr 2026 04:02:31 +0000 (13:02 +0900)]
ntfs: fix NULL dereference in ntfs_index_walk_down()
ntfs_index_walk_down() allocates ictx->ib when descending from the root
into an index allocation block. If that allocation fails, the old code
still passes the NULL buffer to ntfs_ib_read(), which can write through
it via ntfs_inode_attr_pread().
Allocate the index block into a temporary pointer and return -ENOMEM
before changing the index context on allocation failure. Also propagate
ERR_PTR() through ntfs_index_next() and ntfs_readdir() so walk-down
allocation or index block read failures are not mistaken for normal
index iteration inside the filesystem.
ntfs_readdir() keeps the existing userspace-visible behavior of
suppressing readdir errors after marking end_in_iterate; this change only
prevents the walk-down failure path from dereferencing NULL internally.
The failure was reproduced with failslab fail-nth injection on getdents64;
the original module hits a NULL pointer dereference in memcpy_orig through
ntfs_ib_read(), while the patched module reaches the same
ntfs_index_walk_down() allocation failure without crashing.
Fixes: 0a8ac0c1fa0b ("ntfs: update directory operations") Signed-off-by: DaeMyung Kang <charsyam@gmail.com> Reviewed-by: Hyunchul Lee <hyc.lee@gmail.com> Signed-off-by: Namjae Jeon <linkinjeon@kernel.org>
Haoyu Lu [Fri, 10 Apr 2026 13:37:35 +0000 (21:37 +0800)]
mtd: mtdsuper: replace simple_strtoul with kstrtouint
Modernize string-to-number conversion in mtdsuper.c by replacing
simple_strtoul with kstrtouint. This change provides proper type safety
for MTD device numbers which are non-negative integers.
Using kstrtouint avoids unsigned long to int conversion and is more
appropriate for device indices. The debug output format specifier is
updated to %u for unsigned int.
Signed-off-by: Haoyu Lu <hechushiguitu666@gmail.com> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Haoyu Lu [Fri, 10 Apr 2026 13:37:34 +0000 (21:37 +0800)]
mtd: mtdoops: replace simple_strtoul with kstrtouint
Replace deprecated simple_strtoul with kstrtouint for better error
handling and type safety. The kstrtouint function provides stricter
validation, automatically rejecting inputs like "123abc" that
simple_strtoul would partially accept.
Using kstrtouint avoids unsigned long to int conversion and is more
appropriate for MTD device indices which are non-negative integers.
Signed-off-by: Haoyu Lu <hechushiguitu666@gmail.com> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Various names for Qualcomm as a company are used in user-visible config
options: QCOM, Qualcomm and Qualcomm Technologies. Switch to unified
"Qualcomm" so it will be easier for users to identify the options when
for example running menuconfig.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
mtd: spinand: winbond: Fix ODTR write VCR on W35NxxJW
In most scenarios this variant is actually unused (VCR is written in
SSDR mode), but we need to provide an octal variant. The address is 24
bits but is sent over 4 bytes MSB first. This means we need to shift the
register address by one extra byte for the address to be correct.
I didn't catch this initially because the volatile register region is
256 bytes wide, so the write-then-read procedure did work with the small
register addresses I was using at that time: 0 and 1.
mtd: spinand: winbond: Set the packed page read flag to W35N02/04JW
Both W35N02JW and W35N04JW diverge from W35N01JW when it comes to the
"data read" operation in ODTR mode. In order to stuff more address
bits (up to 18), the second command byte is replaced by the most
significant address bits, keeping the number of address bytes to 2.
mtd: spinand: Add support for packed read data ODTR commands
Some devices stuff address bits in the double byte opcode (in place of
the repeated byte) in order to be able to increase the size of the
devices, without adding extra address bytes.
Create a flag to identify those devices. When the flag is set, use the
"packed" variant for the read data operation.
mtd: spi-nor: debugfs: fix out-of-bounds read in spi_nor_params_show()
Sashiko noticed an out-of-bounds read [1].
In spi_nor_params_show(), the snor_f_names array is passed to
spi_nor_print_flags() using sizeof(snor_f_names).
Since snor_f_names is an array of pointers, sizeof() returns the total
number of bytes occupied by the pointers
(element_count * sizeof(void *))
rather than the element count itself. On 64-bit systems, this makes the
passed length 8x larger than intended.
Inside spi_nor_print_flags(), the 'names_len' argument is used to
bounds-check the 'names' array access. An out-of-bounds read occurs
if a flag bit is set that exceeds the array's actual element count
but is within the inflated byte-size count.
Correct this by using ARRAY_SIZE() to pass the actual number of
string pointers in the array.
David Carlier [Fri, 24 Apr 2026 18:36:38 +0000 (19:36 +0100)]
mm/userfaultfd: detect VMA type change after copy retry in mfill_copy_folio_retry()
mfill_copy_folio_retry() drops mmap_lock for the copy_from_user() call.
During this window, the VMA can be replaced with a different type (e.g.
hugetlb), making the caller's ops pointer stale. Subsequent use of the
stale ops would dispatch into the wrong per-vma handlers.
Capture the VMA's ops via vma_uffd_ops() before dropping the lock and
compare against the current vma_uffd_ops() after re-acquiring it.
Return -EAGAIN if they differ so the operation can be retried. This
avoids comparing against the caller's ops which may have been
overridden to anon_uffd_ops for MAP_PRIVATE file-backed mappings.
Link: https://lore.kernel.org/20260424183638.196227-1-devnexen@gmail.com Fixes: 6ab703034f14 ("userfaultfd: mfill_atomic(): remove retry logic") Reported-by: Usama Arif <usama.arif@linux.dev> Closes: https://lore.kernel.org/all/20260410114809.3592720-1-usama.arif@linux.dev/ Signed-off-by: David Carlier <devnexen@gmail.com> Acked-by: Mike Rapoport (Microsoft) <rppt@kernel.org> Cc: Jann Horn <jannh@google.com> Cc: Liam Howlett <liam.howlett@oracle.com> Cc: Lorenzo Stoakes <ljs@kernel.org> Cc: Peter Xu <peterx@redhat.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
SeongJae Park [Sun, 19 Apr 2026 16:10:02 +0000 (09:10 -0700)]
mm/damon/stat: detect and use fresh enabled value
DAMON_STAT updates 'enabled' parameter value, which represents the running
status of its kdamond, when the user explicitly requests start/stop of the
kdamond. The kdamond can, however, be stopped even if the user explicitly
requested the stop, if ctx->regions_score_histogram allocation failure at
beginning of the execution of the kdamond. Hence, if the kdamond is
stopped by the allocation failure, the value of the parameter can be
stale.
Users could show the stale value and be confused. The problem will only
rarely happen in real and common setups because the allocation is arguably
too small to fail. Also, unlike the similar bugs that are now fixed in
DAMON_RECLAIM and DAMON_LRU_SORT, kdamond can be restarted in this case,
because DAMON_STAT force-updates the enabled parameter value for user
inputs. The bug is a bug, though.
The issue stems from the fact that there are multiple events that can
change the status, and following all the events is challenging.
Dynamically detect and use the fresh status for the parameters when those
are requested.
SeongJae Park [Sun, 19 Apr 2026 16:10:01 +0000 (09:10 -0700)]
mm/damon/lru_sort: detect and use fresh enabled and kdamond_pid values
DAMON_LRU_SORT updates 'enabled' and 'kdamond_pid' parameter values, which
represents the running status of its kdamond, when the user explicitly
requests start/stop of the kdamond. The kdamond can, however, be stopped
in events other than the explicit user request in the following three
events.
1. ctx->regions_score_histogram allocation failure at beginning of the
execution,
2. damon_commit_ctx() failure due to invalid user input, and
3. damon_commit_ctx() failure due to its internal allocation failures.
Hence, if the kdamond is stopped by the above three events, the values of
the status parameters can be stale. Users could show the stale values and
be confused. This is already bad, but the real consequence is worse.
DAMON_LRU_SORT avoids unnecessary damon_start() and damon_stop() calls
based on the 'enabled' parameter value. And the update of 'enabled'
parameter value depends on the damon_start() and damon_stop() call
results. Hence, once the kdamond has stopped by the unintentional events,
the user cannot restart the kdamond before the system reboot. For
example, the issue can be reproduced via below steps.
The problem will only rarely happen in real and common setups for the
following reasons. The allocation failures are unlikely in such setups
since those allocations are arguably too small to fail. Also sane users
on real production environments may not commit wrong input parameters.
But once it happens, the consequence is quite bad. And the bug is a bug.
The issue stems from the fact that there are multiple events that can
change the status, and following all the events is challenging.
Dynamically detect and use the fresh status for the parameters when those
are requested.
Link: https://lore.kernel.org/20260419161003.79176-3-sj@kernel.org Fixes: 40e983cca927 ("mm/damon: introduce DAMON-based LRU-lists Sorting") Co-developed-by: Liew Rui Yan <aethernet65535@gmail.com> Signed-off-by: Liew Rui Yan <aethernet65535@gmail.com> Signed-off-by: SeongJae Park <sj@kernel.org> Cc: <stable@vger.kernel.org> # 6.0.x Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
SeongJae Park [Sun, 19 Apr 2026 16:10:00 +0000 (09:10 -0700)]
mm/damon/reclaim: detect and use fresh enabled and kdamond_pid values
Patch series "mm/damon/modules: detect and use fresh status", v3.
DAMON modules including DAMON_RECLAIM, DAMON_LRU_SORT and DAMON_STAT
commonly expose the kdamond running status via their parameters. Under
certain scenarios including wrong user inputs and memory allocation
failures, those parameter values can be stale. It can confuse users. For
DAMON_RECLAIM and DAMON_LRU_SORT, it even makes the kdamond unable to be
restarted before the system reboot.
The problem comes from the fact that there are multiple events for the
status changes and it is difficult to follow up all the scenarios. Fix
the issue by detecting and using the status on demand, instead of using a
cached status that is difficult to be updated.
Patches 1-3 fix the bugs in DAMON_RECLAIM, DAMON_LRU_SORT and DAMON_STAT
in the order.
This patch (of 3):
DAMON_RECLAIM updates 'enabled' and 'kdamond_pid' parameter values, which
represents the running status of its kdamond, when the user explicitly
requests start/stop of the kdamond. The kdamond can, however, be stopped
in events other than the explicit user request in the following three
events.
1. ctx->regions_score_histogram allocation failure at beginning of the
execution,
2. damon_commit_ctx() failure due to invalid user input, and
3. damon_commit_ctx() failure due to its internal allocation failures.
Hence, if the kdamond is stopped by the above three events, the values of
the status parameters can be stale. Users could show the stale values and
be confused. This is already bad, but the real consequence is worse.
DAMON_RECLAIM avoids unnecessary damon_start() and damon_stop() calls
based on the 'enabled' parameter value. And the update of 'enabled'
parameter value depends on the damon_start() and damon_stop() call
results. Hence, once the kdamond has stopped by the unintentional events,
the user cannot restart the kdamond before the system reboot. For
example, the issue can be reproduced via below steps.
The problem will only rarely happen in real and common setups for the
following reasons. The allocation failures are unlikely in such setups
since those allocations are arguably too small to fail. Also sane users
on real production environments may not commit wrong input parameters.
But once it happens, the consequence is quite bad. And the bug is a bug.
The issue stems from the fact that there are multiple events that can
change the status, and following all the events is challenging.
Dynamically detect and use the fresh status for the parameters when those
are requested.
Mark Brown [Thu, 16 Apr 2026 18:40:56 +0000 (19:40 +0100)]
selftests/mm: specify requirement for PROC_MEM_ALWAYS_FORCE=y
Several of the mm selftests made use of /proc/pid/mem as part of their
operation but we do not specify this in the config fragment for them, at
least mkdirty and ksm_functional_tests have this requirement.
This has been working fine in practice since PROC_MEM_ALWAYS_FORCE was the
default setting but commit 599bbba5a36f ("proc: make PROC_MEM_FORCE_PTRACE
the Kconfig default") that is no longer the case, meaning that tests run
on kernels built based on defconfigs have started having the new more
restrictive default and failing. Add PROC_MEM_ALWAYS_FORCE to the config
fragment for the mm selftests.
Thanks to Aishwarya TCV for spotting the issue and identifying the commit
that introduced it.
Link: https://lore.kernel.org/20260416-selftests-mm-proc-mem-always-force-v1-1-3f5865153c67@kernel.org Fixes: 599bbba5a36f ("proc: make PROC_MEM_FORCE_PTRACE the Kconfig default") Signed-off-by: Mark Brown <broonie@kernel.org> Reported-by: Aishwarya TCV <aishwarya.tcv@arm.com> Reviewed-by: Mike Rapoport (Microsoft) <rppt@kernel.org> Acked-by: David Hildenbrand (Arm) <david@kernel.org> Reviewed-by: Anshuman Khandual <anshuman.khandual@arm.com> Reviewed-by: Dev Jain <dev.jain@arm.com> Cc: Lorenzo Stoakes <ljs@kernel.org> Cc: Michal Hocko <mhocko@suse.com> Cc: Mike Rapoport <rppt@kernel.org> Cc: Shuah Khan <shuah@kernel.org> Cc: Suren Baghdasaryan <surenb@google.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
SeongJae Park [Thu, 23 Apr 2026 15:02:52 +0000 (08:02 -0700)]
mm/damon/sysfs-schemes: protect path kfree() with damon_sysfs_lock
damon_sysfs_quot_goal->path can be read and written by users, via DAMON
sysfs 'path' file. It can also be indirectly read, for the parameters
{on,off}line committing to DAMON. The reads for parameters committing are
protected by damon_sysfs_lock to avoid the sysfs files being destroyed
while any of the parameters are being read. But the user-driven direct
reads and writes are not protected by any lock, while the write is
deallocating the path-pointing buffer. As a result, the readers could
read the already freed buffer (user-after-free). Note that the user-reads
don't race when the same open file is used by the writer, due to kernfs's
open file locking. Nonetheless, doing the reads and writes with separate
open files would be common. Fix it by protecting both the user-direct
reads and writes with damon_sysfs_lock.
SeongJae Park [Thu, 23 Apr 2026 15:02:51 +0000 (08:02 -0700)]
mm/damon/sysfs-schemes: protect memcg_path kfree() with damon_sysfs_lock
Patch series "mm/damon/sysfs-schemes: fix use-after-free for [memcg_]path".
Reads of 'memcg_path' and 'path' files in DAMON sysfs interface could race
with their writes, results in use-after-free. Fix those.
This patch (of 2):
damon_sysfs_scheme_filter->mmecg_path can be read and written by users,
via DAMON sysfs memcg_path file. It can also be indirectly read, for the
parameters {on,off}line committing to DAMON. The reads for parameters
committing are protected by damon_sysfs_lock to avoid the sysfs files
being destroyed while any of the parameters are being read. But the
user-driven direct reads and writes are not protected by any lock, while
the write is deallocating the memcg_path-pointing buffer. As a result,
the readers could read the already freed buffer (user-after-free). Note
that the user-reads don't race when the same open file is used by the
writer, due to kernfs's open file locking. Nonetheless, doing the reads
and writes with separate open files would be common. Fix it by protecting
both the user-direct reads and writes with damon_sysfs_lock.
Li Wang [Thu, 23 Apr 2026 13:26:49 +0000 (21:26 +0800)]
MAINTAINERS: update Li Wang's email address
Update my email address as my work email account is no longer in use.
Also update .mailmap.
Link: https://lore.kernel.org/20260423132649.31126-1-li.wang@linux.dev Signed-off-by: Li Wang <li.wang@linux.dev> Reviewed-by: Cyril Hrubis <chrubis@suse.cz> Reviewed-by: Petr Vorel <pvorel@suse.cz> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Jakub Kacinski <kuba@kernel.org> Cc: Li Wang <liwang@redhat.com> Cc: Martin Kepplinger <martink@posteo.de> Cc: Shannon Nelson <sln@onemain.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
mm/hugetlb_cma: round up per_node before logging it
When the user requests a total hugetlb CMA size without per-node
specification, hugetlb_cma_reserve() computes per_node from
hugetlb_cma_size and the number of nodes that have memory
So the actually reserved per_node size is multiple of (PAGE_SIZE <<
order), but the logged per_node is not rounded up, so it may be smaller
than the actual reserved size.
For example, as the existing comment describes, if a 3 GB area is
requested on a machine with 4 NUMA nodes that have memory, 1 GB is
allocated on the first three nodes, but the printed log is
hugetlb_cma: reserve 3072 MiB, up to 768 MiB per node
Round per_node up to (PAGE_SIZE << order) before logging so that the
printed log always matches the actual reserved size. No functional change
to the actual reservation size, as the following case analysis shows
Pedro Falcato [Wed, 22 Apr 2026 12:37:26 +0000 (13:37 +0100)]
MAINTAINERS: fix regex pattern in CORE MM category
The pattern "include/linux/page[-_]*" matches every file that starts with
"page", because it's a regex and not a glob (so it has the meaning of
include/linux/page + match [-_] 0+ times).
Fix it up into a more regex-correct expression. Doing so reduces CC's
drastically in patches that touch pagemap.h (which is maintained as part
of PAGE CACHE).
As a side-effect, move linux/pageblock-flags.h explicitly under PAGE
ALLOCATOR.
Link: https://lore.kernel.org/linux-mm/20260422005608.342028-1-fmayle@google.com/ Link: https://lore.kernel.org/20260422123726.517220-1-pfalcato@suse.de Signed-off-by: Pedro Falcato <pfalcato@suse.de> Reviewed-by: Lorenzo Stoakes <ljs@kernel.org> Acked-by: David Hildenbrand (Arm) <david@kernel.org> Acked-by: Vlastimil Babka (SUSE) <vbabka@kernel.org> Reviewed-by: SeongJae Park <sj@kernel.org> Cc: Liam Howlett <liam.howlett@oracle.com> Cc: Michal Hocko <mhocko@suse.com> Cc: Mike Rapoport <rppt@kernel.org> Cc: Suren Baghdasaryan <surenb@google.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Lorenzo Stoakes [Tue, 21 Apr 2026 10:21:50 +0000 (11:21 +0100)]
mm/vma: do not try to unmap a VMA if mmap_prepare() invoked from mmap()
The mmap_prepare hook functionality includes the ability to invoke
mmap_prepare() from the mmap() hook of existing 'stacked' drivers, that is
ones which are capable of calling the mmap hooks of other drivers/file
systems (e.g. overlayfs, shm).
As part of the mmap_prepare action functionality, we deal with errors by
unmapping the VMA should one arise. This works in the usual mmap_prepare
case, as we invoke this action at the last moment, when the VMA is
established in the maple tree.
However, the mmap() hook passes a not-fully-established VMA pointer to the
caller (which is the motivation behind the mmap_prepare() work), which is
detached.
So attempting to unmap a VMA in this state will be problematic, with the
most obvious symptom being a warning in vma_mark_detached(), because the
VMA is already detached.
It's also unncessary - the mmap() handler will clean up the VMA on error.
So to fix this issue, this patch propagates whether or not an mmap action
is being completed via the compatibility layer or directly.
If the former, then we do not attempt VMA cleanup, if the latter, then we
do.
This patch also updates the userland VMA tests to reflect the change.
Link: https://lore.kernel.org/20260421102150.189982-1-ljs@kernel.org Fixes: ac0a3fc9c07d ("mm: add ability to take further action in vm_area_desc") Signed-off-by: Lorenzo Stoakes <ljs@kernel.org> Reported-by: syzbot+db390288d141a1dccf96@syzkaller.appspotmail.com Closes: https://lore.kernel.org/all/69e69734.050a0220.24bfd3.0027.GAE@google.com/ Cc: David Hildenbrand <david@kernel.org> Cc: Jann Horn <jannh@google.com> Cc: Liam Howlett <liam.howlett@oracle.com> Cc: Michal Hocko <mhocko@suse.com> Cc: Mike Rapoport <rppt@kernel.org> Cc: Pedro Falcato <pfalcato@suse.de> Cc: Suren Baghdasaryan <surenb@google.com> Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Joanne Koong [Thu, 26 Mar 2026 23:46:29 +0000 (16:46 -0700)]
mm: start background writeback based on per-wb threshold for strictlimit BDIs
The proactive nr_dirty > gdtc->bg_thresh check in balance_dirty_pages()
only checks the global dirty threshold to start background writeback while
the writer is still free-running, but for strictlimit BDIs (eg fuse), the
per-wb dirty count can exceed the per-wb background threshold while the
global threshold is not yet exceeded, so background writeback for this
case never gets proactively started.
Add a per-wb threshold check for strictlimit BDIs so that background
writeback is started when wb_dirty exceeds wb_bg_thresh, which drains
dirty pages before the writer hits the throttle wall, matching the
proactive behavior that the global check provides for non-strictlimit
BDIs.
fio runs on fuse show about a 3-4% improvement in perf for buffered
writes:
fio --name=writeback_test --ioengine=psync --rw=write --bs=128k \
--size=2G --numjobs=4 --ramp_time=10 --runtime=20 \
--time_based --group_reporting=1 --direct=0
Link: https://lore.kernel.org/20260326234629.840938-2-joannelkoong@gmail.com Signed-off-by: Joanne Koong <joannelkoong@gmail.com> Reviewed-by: Jan Kara <jack@suse.cz> Cc: Matthew Wilcox (Oracle) <willy@infradead.org> Cc: Miklos Szeredi <miklos@szeredi.hu> Cc: Christoph Hellwig <hch@infradead.org> Cc: Johannes Weiner <hannes@cmpxchg.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Fix two error handling issues in kho_add_subtree(), where it doesn't
handle the error path correctly.
1. If fdt_setprop() fails after the subnode has been created, the
subnode is not removed. This leaves an incomplete node in the FDT
(missing "preserved-data" or "blob-size" properties).
2. The fdt_setprop() return value (an FDT error code) is stored
directly in err and returned to the caller, which expects -errno.
Fix both by storing fdt_setprop() results in fdt_err, jumping to a new
out_del_node label that removes the subnode on failure, and only setting
err = 0 on the success path, otherwise returning -ENOMEM (instead of
FDT_ERR_ errors that would come from fdt_setprop).
No user-visible changes. This patch fixes error handling in the KHO
(Kexec HandOver) subsystem, which is used to preserve data across kexec
reboots. The fix only affects a rare failure path during kexec
preparation — specifically when the kernel runs out of space in the
Flattened Device Tree buffer while registering preserved memory regions.
In the unlikely event that this error path was triggered, the old code
would leave a malformed node in the device tree and return an incorrect
error code to the calling subsystem, which could lead to confusing log
messages or incorrect recovery decisions. With this fix, the incomplete
node is properly cleaned up and the appropriate errno value is propagated,
this error code is not returned to the user.
liveupdate: fix return value on session allocation failure
When session allocation fails during deserialization, the global 'err'
variable was not updated before returning. This caused subsequent calls
to luo_session_deserialize() to incorrectly report success.
Ensure 'err' is set to the error code from PTR_ERR(session). This ensures
that an error is correctly returned to userspace when it attempts to open
/dev/liveupdate in the new kernel if deserialization failed.
Link: https://lore.kernel.org/20260415193738.515491-1-pasha.tatashin@soleen.com Signed-off-by: Pasha Tatashin <pasha.tatashin@soleen.com> Reviewed-by: Pratyush Yadav (Google) <pratyush@kernel.org> Cc: David Matlack <dmatlack@google.com> Cc: Mike Rapoport <rppt@kernel.org> Cc: Samiullah Khawaja <skhawaja@google.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Marco Elver [Mon, 20 Apr 2026 11:47:26 +0000 (13:47 +0200)]
vmalloc: fix buffer overflow in vrealloc_node_align()
Commit 4c5d3365882d ("mm/vmalloc: allow to set node and align in
vrealloc") added the ability to force a new allocation if the current
pointer is on the wrong NUMA node, or if an alignment constraint is not
met, even if the user is shrinking the allocation.
On this path (need_realloc), the code allocates a new object of 'size'
bytes and then memcpy()s 'old_size' bytes into it. If the request is to
shrink the object (size < old_size), this results in an out-of-bounds
write on the new buffer.
Fix this by bounding the copy length by the new allocation size.
Link: https://lore.kernel.org/20260420114805.3572606-2-elver@google.com Fixes: 4c5d3365882d ("mm/vmalloc: allow to set node and align in vrealloc") Signed-off-by: Marco Elver <elver@google.com> Reported-by: Harry Yoo (Oracle) <harry@kernel.org> Reviewed-by: Uladzislau Rezki (Sony) <urezki@gmail.com> Acked-by: Vlastimil Babka (SUSE) <vbabka@kernel.org> Reviewed-by: Harry Yoo (Oracle) <harry@kernel.org> Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
pmdomain: mediatek: fix use-after-free in scpsys_get_bus_protection_legacy()
In scpsys_get_bus_protection_legacy(), of_find_node_with_property()
returns a device node with its reference count incremented. The function
then calls of_node_put(node) before checking whether
syscon_regmap_lookup_by_phandle() returns an error. If an error occurs,
dev_err_probe() dereferences the node pointer to print diagnostic
information, but the node memory may have already been freed due to the
earlier of_node_put(), leading to a use-after-free vulnerability.
Fix this by moving the of_node_put() call after the error check, ensuring
the node is still valid when accessed in the error path.
ACPI: arm64: cpuidle: Tolerate platforms with no deep PSCI idle states
Commit cac173bea57d ("ACPI: processor: idle: Rework the handling of
acpi_processor_ffh_lpi_probe()") moved the acpi_processor_ffh_lpi_probe()
call from acpi_processor_setup_cpuidle_dev(), where its return value was
ignored, to acpi_processor_get_power_info(), where it is now treated as
a hard failure. As a result, platforms where psci_acpi_cpu_init_idle()
returned -ENODEV stopped registering any cpuidle states, forcing CPUs to
busy-poll when idle.
On NVIDIA Grace (aarch64) systems with PSCIv1.1, pr->power.count is 1
(only WFI, no deep PSCI states beyond it), so the previous
"count = pr->power.count - 1; if (count <= 0) return -ENODEV;" check
returned -ENODEV for all 72 CPUs and disabled cpuidle entirely.
The lpi_states count is already validated in acpi_processor_get_lpi_info(),
so the check here is redundant. Simplify the loop to iterate over
lpi_states[1..power.count). When only WFI is present, the loop body
simply does not execute and the function returns 0, which is the correct
outcome: there is nothing to validate for FFH and no error to report.
Suggested-by: Huisong Li <lihuisong@huawei.com> Cc: stable@vger.kernel.org Fixes: cac173bea57d ("ACPI: processor: idle: Rework the handling of acpi_processor_ffh_lpi_probe()") Signed-off-by: Breno Leitao <leitao@debian.org> Reviewed-by: Sudeep Holla <sudeep.holla@kernel.org> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
ALSA: caiaq: fix usb_dev refcount leak on probe failure
create_card() takes a reference on the USB device with usb_get_dev()
and stores the matching usb_put_dev() in card_free(), which is
installed as the snd_card's ->private_free destructor.
However, ->private_free is only assigned near the end of init_card(),
after several failure points (usb_set_interface(), EP type checks,
usb_submit_urb(), the EP1_CMD_GET_DEVICE_INFO exchange, and its
timeout). When any of those fail, init_card() returns an error to
snd_probe(), which calls snd_card_free(card). Because ->private_free
is still NULL, card_free() never runs, the usb_get_dev() reference
is not dropped, and the struct usb_device leaks along with its
descriptor allocations and device_private.
syzbot reproduces this with a malformed UAC3 device whose only valid
altsetting is 0; init_card()'s usb_set_interface(usb_dev, 0, 1) call
fails with -EIO and triggers the leak.
Move the ->private_free assignment into create_card(), immediately
after usb_get_dev(), so that every error path reaching snd_card_free()
balances the reference. card_free()'s callees (snd_usb_caiaq_input_free,
free_urbs, kfree) already tolerate the partially-initialized state
because the chip private area is zero-initialized by snd_card_new().
Fixes: 80bb50e2d459 ("ALSA: caiaq: take a reference on the USB device in create_card()") Reported-by: syzbot+2afd7e71155c7e241560@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=2afd7e71155c7e241560 Tested-by: syzbot+2afd7e71155c7e241560@syzkaller.appspotmail.com Cc: stable@vger.kernel.org Signed-off-by: Deepanshu Kartikey <kartikey406@gmail.com> Link: https://patch.msgid.link/20260426001934.70813-1-kartikey406@gmail.com Signed-off-by: Takashi Iwai <tiwai@suse.de>
pmdomain: core: Fix detach procedure for virtual devices in genpd
If a device is attached to a PM domain through genpd_dev_pm_attach_by_id(),
genpd calls pm_runtime_enable() for the corresponding virtual device that
it registers. While this avoids boilerplate code in drivers, there is no
corresponding call to pm_runtime_disable() in genpd_dev_pm_detach().
This means these virtual devices are typically detached from its genpd,
while runtime PM remains enabled for them, which is not how things are
designed to work. In worst cases it may lead to critical errors, like a
NULL pointer dereference bug in genpd_runtime_suspend(), which was recently
reported. For another case, we may end up keeping an unnecessary vote for a
performance state for the device.
To fix these problems, let's add this missing call to pm_runtime_disable()
in genpd_dev_pm_detach().
Reported-by: Geert Uytterhoeven <geert@linux-m68k.org> Closes: https://lore.kernel.org/all/CAMuHMdWapT40hV3c+CSBqFOW05aWcV1a6v_NiJYgoYi0i9_PDQ@mail.gmail.com/ Fixes: 3c095f32a92b ("PM / Domains: Add support for multi PM domains per device to genpd") Cc: stable@vger.kernel.org Tested-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
ARM: dts: socfpga: remove the reg property in the pmu
The Cortex-A9 PMU accesses the hardware via system coprocessor registers,
not memory-mapped I/O. The driver does not parse or use a 'reg' property
from the device tree, so we can remove the reg from the DTS.
This change fixes this dtbs_check warning:
(arm,cortex-a9-pmu): 'reg' does not match any of the regexes
The Agilex7-M devkit contains an Agilex7M SoC, which is a newly branded
version of the original Agilex SoC. The Agilex7M core peripherals are
identical to the Agilex SoC.
We can re-use the socfpga_agilex.dtsi for this devkit. The Agilex7-M
devkit supports PCIE 5.0(x16), DDR4, DDR5, LPDDR5 and does not have QSPI.
Add a missing sanity check for bNrChannels in detect_usb_format()
to prevent a division by zero in playback_urb_complete() and
capture_urb_complete().
USB core does not validate class-specific descriptor fields such
as bNrChannels, so drivers must verify them before use. If a
device provides bNrChannels = 0, frame_bytes becomes zero and is
later used as a divisor in the URB completion handlers, leading
to a kernel crash.
ALSA: usb-audio: apply quirk for Playstation PDP Riffmaster
This device, just like the Playstation 5's DualSense, has a volume
that's too low, hid-playstation solves this by raising the minimum
volume on the device itself by sending an output report, third party PS5
controllers/accessories do not support this output report format, so we
apply a quirk to raise the minimum volume by 6dB.
ALSA: hda: Remove duplicate cmedia entries in codecs Makefile
kconfiglint reports:
M004: 'snd-hda-codec-cmedia-y' assigned with ':=' but was already
assigned at line 5; previous value is overwritten
sound/hda/codecs/Makefile contains duplicate entries for the C-Media
codec driver — both the composite module definition and the obj-* build
target appear twice:
Line 5: snd-hda-codec-cmedia-y := cmedia.o
Line 10: snd-hda-codec-cmedia-y := cmedia.o (duplicate)
Line 24: obj-$(CONFIG_SND_HDA_CODEC_CMEDIA) += snd-hda-codec-cmedia.o
Line 29: obj-$(CONFIG_SND_HDA_CODEC_CMEDIA) += snd-hda-codec-cmedia.o (duplicate)
This file was created by commit 6014e9021b28 ("ALSA: hda: Move codec
drivers into sound/hda/codecs directory") which
moved codec drivers from sound/pci/hda/ to sound/hda/codecs/. In that
initial file, cmedia appeared once in each section.
Immediately after, commit aeeb85f26c3b ("ALSA: hda: Split Realtek
HD-audio codec driver") reordered the entries and
inserted cmedia at new positions near the top of each section, as part
of splitting out the Realtek driver. However, the original cmedia entries
were not removed during this reordering, creating duplicates of both
lines. The second assignment harmlessly overwrites the first with the
same value, and the second obj-* line causes the module to be listed
twice — neither causes a build failure, but both are dead code.
Remove the duplicate entries (second occurrence of each).
ALSA: scarlett2: Add Gen 4 firmware 2417 front-panel controls
Firmware 2417 for the Scarlett 4th Gen Solo, 2i2, and 4i4 added two
new front-panel features: a LED brightness setting (High/Medium/Low)
and an idle sleep timeout. Add ALSA controls to expose them:
ALSA: scarlett2: Add Gen 4 firmware 2417 autogain status text
Firmware 2417 for the Scarlett 4th Gen 2i2 and 4i4 added a new
autogain exit code ("Root"). Without this entry the new status is
reported as "Invalid".
ALSA: scarlett2: Update offsets for 2i2 Gen 4 firmware 2417
Firmware 2417 for the Scarlett 4th Gen 2i2 moved the direct monitor gain
parameters, so add a second config_set with the shifted offset and
select it for firmware versions >= 2417.
Fixes: 4e809a299677 ("ALSA: scarlett2: Add support for Solo, 2i2, and 4i4 Gen 4") Cc: stable@vger.kernel.org # ALSA: scarlett2: Allow selecting config_set by firmware version Cc: stable@vger.kernel.org # ALSA: scarlett2: Fold min_firmware_version into config_sets Cc: stable@vger.kernel.org Signed-off-by: Geoffrey D. Bennett <g@b4.vu> Signed-off-by: Takashi Iwai <tiwai@suse.de> Link: https://patch.msgid.link/ad0fc5a131e76eb656a24e0e198382f7134068fe.1777151532.git.g@b4.vu
ALSA: scarlett2: Fold min_firmware_version into config_sets
The device info's min_firmware_version field encoded the oldest
firmware the driver supports on each device. With the config_sets
array in place, the first entry's from_firmware_version carries the
same meaning (it's the oldest firmware range any config_set applies
to). Merge the two by dropping min_firmware_version from
scarlett2_device_info and reading config_sets[0].from_firmware_version
at the three call sites that used it.
ALSA: scarlett2: Allow selecting config_set by firmware version
The Scarlett 2i2 Gen 4 firmware 2417 moved the direct monitor gain
parameters, so we now need to allow each device to list multiple
scarlett2_config_set entries, one per applicable firmware version
range, and pick the matching one at probe time.
No functional change yet: each device gets a single config_sets
entry whose from_firmware_version matches the existing
min_firmware_version (0 where none was set). This both prepares for
selection and lets a follow-up commit remove the now-redundant
min_firmware_version field.
scarlett2_count_io() depends on the resolved config_set so it moves
out of scarlett2_init_private() into snd_scarlett2_controls_create()
after the firmware version has been read.
dt-bindings: arm: altera: document the Agilex7-M devkit
The Agilex7-M is a rebranded version of the original Agilex SoC. The
Agilex7-M SoC has the same core peripherals as the Agilex device.
This change is to document the Agilex7m devkit which has the Agilex7-M
device. The Agilex7-M SoC supports DDR4, DDR5, LPDDR5, PCIE 5.0(x16), but
not QSPI.
Also, now that Altera has separated from Intel, use the "altr" company
prefix.
Gray Huang [Wed, 25 Mar 2026 05:46:12 +0000 (13:46 +0800)]
arm64: dts: rockchip: Add HDMI and VOP support for Khadas Edge 2L
Enable the Video Output Processor (VOP) and the HDMI TX controller
to support HDMI display output on the Khadas Edge 2L. Also, enable
the associated HDMI PHY.
Gray Huang [Wed, 25 Mar 2026 05:46:11 +0000 (13:46 +0800)]
arm64: dts: rockchip: Enable GPU for Khadas Edge 2L
Enable the Mali GPU node on the Khadas Edge 2L board. Assign the
corresponding regulator to the mali-supply property to ensure
proper power management and dynamic voltage scaling (DVFS).
Gray Huang [Wed, 25 Mar 2026 05:46:09 +0000 (13:46 +0800)]
arm64: dts: rockchip: Add PMIC support for Khadas Edge 2L
Add RK806 PMIC support for the Khadas Edge 2L board. Assign the
corresponding PMIC regulators (vdd_cpu_lit_s0 and vdd_cpu_big_s0)
to the little and big CPU clusters to enable proper power
management and CPU frequency scaling.
ALSA: hda/realtek: Add micmute LED quirk for Acer Aspire A315-44P
The mic-mute LED on the Acer Aspire A315-44P (subsystem ID 0x10251640)
does not light up when the microphone is muted. The LED is connected to
GPIO3 of the Realtek ALC256 codec.
Add a quirk entry using ALC256_FIXUP_ACER_SFG16_MICMUTE_LED, which
configures GPIO3 (bitmask 0x04) as the micmute LED, identical to
the Acer Swift SFG16.
Tested by manually sending HDA verb commands directly to the codec
and verifying that GPIO3 drives the LED while GPIO1 and GPIO2
do not.
arm64/irqflags: __always_inline the arch_local_irq_*() helpers
The arch_local_irq_*() wrappers in <asm/irqflags.h> dispatch between two
underlying primitives: the __daif_* path on most systems, and the
__pmr_* path on builds that use GIC PMR-based masking (Pseudo-NMI). The
leaf primitives are already __always_inline, but the wrappers themselves
are plain "static inline".
That is unsafe for noinstr callers: nothing prevents the compiler from
emitting an out-of-line copy of e.g. arch_local_irq_disable(), and an
out-of-line copy can be instrumented (ftrace, kcov, sanitizers), which
breaks the noinstr contract on the entry/idle paths that rely on these
helpers.
x86 hit and fixed exactly this class of bug in commit 7a745be1cc90
("x86/entry: __always_inline irqflags for noinstr").
Force-inline all of the arch_local_irq_*() wrappers so they cannot be
emitted out-of-line:
The primary motivation is noinstr safety. There is a useful side effect
for fleet-wide profiling: when the wrapper is emitted out-of-line,
samples taken inside it during the post-WFI IRQ unmask in
default_idle_call() are attributed to arch_local_irq_enable rather than
default_idle_call(), and the FP-unwinder loses default_idle_call() from
the chain.
ALSA: hda/realtek: enable mute LED support on ThinkBook 16p
On ThinkBook 16p systems the platform mute LED is present and
bound to the audio-mute trigger, but it does not react to Master
mute changes.
The affected fixup chain sets up the DAC routing, but does not enable
vmaster mute LED handling. Because of that, the generic HDA code does
not mark Master Playback Switch with SNDRV_CTL_ELEM_ACCESS_SPK_LED,
and the audio-mute trigger never receives speaker mute updates.
Add a ThinkBook-specific wrapper around alc287_fixup_bind_dacs() and
enable spec->gen.vmaster_mute_led during PRE_PROBE. This keeps the
existing DAC binding logic unchanged while allowing the normal generic
LED path to drive the mute LED.
Rodrigo Zaiden [Sun, 22 Mar 2026 16:31:14 +0000 (13:31 -0300)]
tee: optee: fix kernel-doc warnings
Fix kernel-doc issues in optee_private.h and optee_msg.h:
- Add missing documentation for struct members: optee_msg_param_value,
optee_msg_param, optee_msg_arg, optee, and optee_ffa;
- Ensure member descriptions follow the order of declaration;
- Use consistent formatting (lowercase descriptions and ':' after
member names);
- Adjust indentation for better alignment;
This resolves kernel-doc warnings such as missing member descriptions
and incorrect prototype documentation.
No functional changes.
On ARM64, shared memory can have MT_NORMAL_TAGGED attribute when using
the Memory Tagging Extension (MTE). The OP-TEE driver needs to
recognize this as normal memory to allow sharing such buffers with the
Secure World.
Rijo Thomas [Fri, 27 Mar 2026 09:26:07 +0000 (09:26 +0000)]
tee: amdtee: store buffer ID in tee_shm->sec_world_id
Drop struct amdtee_shm_data and the per-context shm_list. In
handle_map_shmem() save the returned buf_id in shm->sec_world_id
instead of allocating a list node. Use shm->sec_world_id (with
get_buffer_id() removed) in amdtee_unmap_shmem() and in call.c when
building memref params. Remove shm_list and shm_mutex from
amdtee_context_data.
Aligns amdtee with other TEE drivers (optee, tstee, qcomtee) that use
tee_shm->sec_world_id for the secure-world handle.
Add keyword based matching for 'ARM/Rockchip SoC support'. This will
match rockchip, Rockchip, RockChip and ROCKCHIP separated by any
whitespace character or underscores.
The goal is to match arm64 defconfig patches, which should go through
the Rockchip tree as they right now only match the LKML and thus are
easily lost. The keyword matching is quite good for this, since it
also applies to the commit message and the config options itself might
not give any hint about being relevant for Rockchip.
Midgy BALON [Fri, 27 Mar 2026 09:11:28 +0000 (10:11 +0100)]
arm64: dts: rockchip: rock-3b: Model PI6C20100 as gated-fixed-clock
The Radxa ROCK 3B uses a PI6C20100 PCIe reference clock buffer to
provide a 100MHz reference clock to the PCIe 3.0 PHY and controllers.
This chip is currently modeled only as a fixed regulator
(vcc3v3_pi6c_03), with no clock output representation.
The PI6C20100 is a clock generator, not a power supply. Model it
properly as a gated-fixed-clock, following the pattern established
for the Rock 5 ITX and other boards with similar PCIe clock buffer
chips.
The gated-fixed-clock node references the regulator as its vdd-supply,
allowing the regulator to be enabled on demand. Remove the
regulator-always-on and regulator-boot-on properties from vcc3v3_pi6c_03
since the clock framework will manage the regulator lifecycle via
vdd-supply. The pcie3x2 node is updated to include the pipe and
reference clocks, matching the approach used in rk3588-rock-5-itx.dts.
arm64: dts: rockchip: Enable the NPU on rk3588-rock-5-itx
This commit enables the NPU on Radxa Rock 5 ITX board.
The regulator vdd_npu_s0 was already in place and since the NPUs
power domain supply is now described remove the always-on property
from the regulator.
iommu/pages: Fix iommu_pages_flush_incoherent() for non-x86
The dma_sync_single_for_device() function expects a dma_addr_t, but
iommu_pages_flush_incoherent() was incorrectly passing a virtual
address.
Since iommu_pages_start_incoherent() enforces a 1:1 mapping between
DMA addresses and physical addresses (checked via WARN_ON), we can
convert the virtual address to a physical address before passing it to
the DMA API.
This also matches the behaviour of the other non-x86 in
iommu_pages_free_incoherent(), which uses virt_to_phys(virt);
Fixes: 36ae67b13976 ("iommu/pages: Add support for incoherent IOMMU page table walkers") Signed-off-by: Mostafa Saleh <smostafa@google.com> Reviewed-by: Lu Baolu <baolu.lu@linux.intel.com> Reviewed-by: Pranjal Shrivastava <praan@google.com> Reviewed-by: Jason Gunthorpe <jgg@nvidia.com> Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
clk: rockchip: rk3588: add GATE_GRF clocks for I2S MCLK output to IO
The I2S MCLK outputs on RK3588 are gated by bits in the SYS_GRF
register SOC_CON6 (offset 0x318). These gates control whether the
internal CRU MCLK signals reach the external IO pins connected to
audio codecs.
The kernel should explicitly manage these gates so that audio
functionality does not depend on bootloader register state. This is
analogous to what was done for RK3576 SAI MCLK outputs [1].
Register the SYS_GRF as an auxiliary GRF with grf_type_sys using
rockchip_clk_add_grf(), and add GATE_GRF entries for all four I2S
MCLK output gates:
Convert sysfs show functions from sprintf() to sysfs_emit(), as
recommended by Documentation/filesystems/sysfs.rst. This ensures proper
buffer handling and avoids potential buffer overflows.
Signed-off-by: Stefan Pedratscher <pedratscher.stefan@gmail.com> Tested-by: Daniel Palmer <daniel@thingy.jp> Reviewed-by: Geert Uytterhoeven <geert@linux-m68k.org> Link: https://patch.msgid.link/20260406172512.6693-1-pedratscher.stefan@gmail.com Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
The UAC3 cluster descriptor length check in
snd_usb_get_audioformat_uac3()was added to
make sure that the buffer is large enough for
a struct uac3_cluster_header_descriptor before the
returned data is cast and used.
However, the check uses sizeof(cluster), where cluster
is a pointer, not the size of the descriptor header.
This makes the validation depend on the architecture
pointer size and does not match the intended object size.
Cássio Gabriel [Fri, 24 Apr 2026 12:48:41 +0000 (09:48 -0300)]
ALSA: aloop: Fix peer runtime UAF during format-change stop
loopback_check_format() may stop the capture side when playback starts
with parameters that no longer match a running capture stream. Commit 826af7fa62e3 ("ALSA: aloop: Fix racy access at PCM trigger") moved
the peer lookup under cable->lock, but the actual snd_pcm_stop() still
runs after dropping that lock.
A concurrent close can clear the capture entry from cable->streams[] and
detach or free its runtime while the playback trigger path still holds a
stale peer substream pointer.
Keep a per-cable count of in-flight peer stops before dropping
cable->lock, and make free_cable() wait for those stops before
detaching the runtime. This preserves the existing behavior while
making the peer runtime lifetime explicit.
Reported-by: syzbot+8fa95c41eafbc9d2ff6f@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=8fa95c41eafbc9d2ff6f Fixes: 597603d615d2 ("ALSA: introduce the snd-aloop module for the PCM loopback") Cc: stable@vger.kernel.org Suggested-by: Takashi Iwai <tiwai@suse.com> Signed-off-by: Cássio Gabriel <cassiogabrielcontato@gmail.com> Link: https://patch.msgid.link/20260424-alsa-aloop-peer-stop-uaf-v2-1-94e68101db8a@gmail.com Signed-off-by: Takashi Iwai <tiwai@suse.de>
ALSA: pcm: oss: Fix data race at accessing runtime.oss.trigger
Currently the runtime.oss.trigger field may be accessed concurrently
without protection, which may lead to the data race. And, in this
case, it may lead to more severe problem because it's a bit field; as
writing the data, it may overwrite other bit fields as well, which
confuses the operation completely, as spotted by fuzzing.
Fix it by covering runtime.oss.trigger bit fled also with the existing
params_lock mutex in both snd_pcm_oss_get_trigger() and
snd_pcm_oss_poll().
iommu/amd: Use maximum PPR log buffer size when SNP is enabled on Family 0x19
Due to CVE-2023-20585, the PPR log buffer must use the maximum supported
size (512K) on Genoa (Family 0x19, model >= 0x10) systems when SNP is
enabled, to mitigate a potential security vulnerability. Note that Family
0x19 models below 0x10 (Milan) do not support PPR when SNP is enabled.
Hence the PPR log size increase is only applied for model >= 0x10.
All other systems continue to use the default PPR log buffer size (8K).
Apply the errata fix by making the following changes:
- Introduce global new variable (amd_iommu_pprlog_size) to have PPR log buffer
size. Adjust variable size for Genoa family.
- Extend 'amd_iommu_apply_erratum_snp()' to also set the PPR log buffer
size to maximum for Family 0x19 model >= 0x10 when SNP is enabled.
iommu/amd: Use maximum Event log buffer size when SNP is enabled on Family 0x19
Due to CVE-2023-20585, the Event log buffer must use the maximum supported
size (512K) on Milan/Genoa (Family 0x19) systems when SNP is enabled,
to mitigate a potential security vulnerability. All other systems continue to
use the default Event log buffer size (8K).
Apply the errata fix by making the following changes:
* Introduce new global variable (amd_iommu_evtlog_size) to have event log
buffer size. Adjust variable size for family 0x19.
* Since 'iommu_snp_enable()' must be called after the core IOMMU subsystem
is initialized, it cannot be moved to the early init stage. The SNP errata
must also be applied after the 'iommu_snp_enable()' check. Therefore,
'alloc_event_buffer()' and 'iommu_enable_event_buffer()' are now called
in the IOMMU_ENABLED state, after the errata is applied.
* Adjust alloc_event_buffer() and iommu_enable_event_buffer() to handle
all IOMMU instances.
* Also rename EVT_* macros to make it more readable.
Cássio Gabriel [Thu, 23 Apr 2026 13:11:31 +0000 (10:11 -0300)]
ALSA: hda: cs35l56: Propagate ASP TX source control errors
cs35l56_hda_mixer_get() ignores regmap_read() and
cs35l56_hda_mixer_put() ignores regmap_update_bits_check().
This makes the ASP TX source controls report success when a regmap
access fails. The write path returns no change instead of an error,
and the read path continues after a failed read instead of aborting
the control callback.
Propagate the regmap errors, matching the posture and volume controls
in this driver.
Fixes: 73cfbfa9caea ("ALSA: hda/cs35l56: Add driver for Cirrus Logic CS35L56 amplifier") Cc: stable@vger.kernel.org Signed-off-by: Cássio Gabriel <cassiogabrielcontato@gmail.com> Reviewed-by: Richard Fitzgerald <rf@opensource.cirrus.com> Signed-off-by: Takashi Iwai <tiwai@suse.de> Link: https://patch.msgid.link/20260423-alsa-cs35l56-asp-tx-source-errors-v1-1-17ea7c62ec31@gmail.com
Cássio Gabriel [Sun, 19 Apr 2026 20:30:32 +0000 (17:30 -0300)]
ALSA: usb-audio: Update US-16x08 EQ/comp shadow state after successful writes
snd_us16x08_comp_put() and snd_us16x08_eq_put() update their
software stores before sending the USB write. If the transfer
fails, later get callbacks report a value the hardware never
accepted.
Build the outgoing message from the current store plus the
pending value, then commit the store only after a successful
write.
Cássio Gabriel [Sun, 19 Apr 2026 20:30:31 +0000 (17:30 -0300)]
ALSA: usb-audio: Propagate US-16x08 write errors in route/mix EQ-switch put callbacks
Several US-16x08 mixer put callbacks log failed control URBs but
still return success to userspace. That hides device write failures
even though the requested value was not applied.
Return the negative write error instead in the route, master, bus,
channel, and EQ switch put callbacks.
Cássio Gabriel [Sun, 19 Apr 2026 20:30:30 +0000 (17:30 -0300)]
ALSA: usb-audio: Propagate errors in scarlett_ctl_enum_put()
scarlett_ctl_enum_put() ignores the return value from
snd_usb_set_cur_mix_value() and reports success whenever the
requested enum value differs from the current one.
If the SET_CUR request fails, the callback still returns success even
though neither the hardware state nor the cached mixer value changed.
Cássio Gabriel [Sun, 19 Apr 2026 20:30:29 +0000 (17:30 -0300)]
ALSA: usb-audio: Propagate write errors in generic mixer put callbacks
mixer_ctl_feature_put(), mixer_ctl_procunit_put(), and
mixer_ctl_selector_put() ignore failures from their SET_CUR helper
routines and report the control as changed whenever the requested
value differs from the current one.
If the device rejects the write, userspace still sees success although
the hardware state did not change. Propagate write failures instead,
using filter_error() so ignore_ctl_error keeps the same semantics as
the existing get paths.
Cássio Gabriel [Mon, 13 Apr 2026 19:45:34 +0000 (16:45 -0300)]
ALSA: opti9xx: restore snd-miro state after resume
snd-miro has no PM callbacks, so system resume leaves the OPTi
master-control registers and the board-specific ACI mixer state
unrestored.
Like snd-opti9xx, the driver needs to reprogram the OPTi routing
registers before bringing the codec back. snd-miro also keeps mixer
state in the ACI block, so the codec resume callback alone is not
enough here. Save the ACI mixer state on suspend, reinitialize the
OPTi and ACI state on resume, replay the saved ACI values, and then
resume the WSS codec. Hook the PM handlers into both the ISA and PnP
paths.
Also initialize miro->card on the ISA path for the existing dev_*()
logging and keep the cached solo-mode value aligned with the value
written to hardware.
PCM20 radio tuner state remains outside this driver's PM scope.
Add the RK3588_SYSGRF_SOC_CON6 register offset to the RK3588 GRF
header. This register contains the I2S MCLK output to IO gate bits,
needed by the clock driver.
clk: rockchip: add helper to register auxiliary GRFs
Add rockchip_clk_add_grf() as a helper to register an auxiliary GRF
into the clock provider's aux_grf_table. This encapsulates the
struct rockchip_aux_grf allocation and hashtable insertion, so SoC
clock drivers do not need to open-code it.
clk: rockchip: allow grf_type_sys lookup in aux_grf_table
Remove the grf_type_sys exclusion from the auxiliary GRF table lookup
in rockchip_clk_register_branches(). Previously, branches with
grf_type_sys always used ctx->grf directly, bypassing the aux_grf_table.
This is a problem on SoCs like RK3588 where ctx->grf points to the
PHP_GRF (set via the CRU's rockchip,grf phandle), but GATE_GRF clock
entries need to access the SYS_GRF instead.
With this change, grf_type_sys branches first check the aux_grf_table,
and fall back to ctx->grf if no entry is found. This is backwards
compatible: on SoCs that do not register grf_type_sys in the
aux_grf_table, the behavior is unchanged.
Add clock identifiers for the four I2S MCLK output to IO gate clocks
on RK3588, needed by board DTS files where the codec requires MCLK
from the SoC on an external IO pin.
ima: return error early if file xattr cannot be changed
During early boot, the filesystem is read-only and any changes
to xattrs are not allowed. This fails in case of ext4 because
changing xattr starts an ext4 transaction which fails with the
following warning.
ima: Fix sigv3 signature handling for EVM_IMA_XATTR_DIGSIG
ima_get_hash_algo() only recognizes version 2 signatures when the xattr
type is EVM_IMA_XATTR_DIGSIG. Since sigv3 signatures also use
EVM_IMA_XATTR_DIGSIG as the xattr type, version 3 must be accepted as
well to correctly determine the hash algorithm.
Additionally, ima_validate_rule() does not include IMA_SIGV3_REQUIRED in
the allowed flags bitmask for MODULE_CHECK, KEXEC_KERNEL_CHECK, and
KEXEC_INITRAMFS_CHECK hook functions. As a result, policy rules with
"appraise_type=sigv3" are rejected for these functions.
Add version 3 to the accepted versions in ima_get_hash_algo() for
EVM_IMA_XATTR_DIGSIG, and add IMA_SIGV3_REQUIRED to the allowed flags
for MODULE_CHECK, KEXEC_KERNEL_CHECK, and KEXEC_INITRAMFS_CHECK in
ima_validate_rule().
Signed-off-by: Kamlesh Kumar <kam@juniper.net> Tested-by: Stefan Berger <stefanb@linux.ibm.com> Fixes: de4c44a7f559 ("ima: add support to require IMA sigv3 signatures") Signed-off-by: Mimi Zohar <zohar@linux.ibm.com>
arm64: dts: rockchip: Fix gmac0 reset pin for NanoPi R5S
According to the NanoPi R5S 2204 schematic on page 6, GPIO0_C4 is for
GMAC0_INT/PMEB_GPIO0_C4, while GPIO0_C5 is for GMAC0_RSTn_GPIO0_C5.
While the 'reset-gpios' property was set correctly, the corresponding
pinctrl didn't match that.
Next to fixing the pinctrl definition, also change the node name and
phandle to match what is used in the schematic.
Peter Chen [Tue, 21 Apr 2026 02:34:59 +0000 (10:34 +0800)]
usb: cdns3: Add USBSSP platform driver support
Expose Cadence USBSSP through the same platform path as USBSS, trim
Kconfig and Makefile: one core loadable object plus separate glue .ko
files.
Single cdns.ko bundles core, DRD, the generic "cdns,usb3" platform
driver in cdns3-plat.c, optional host.o, and optional gadget objects.
Use CONFIG_USB_CDNS3_GADGET as a bool to compile gadget support into
that module. Remove duplicate MODULE_* declarations from cdns3-plat.c
now that it links into the same module.
Kconfig: the generic platform driver is selected via CONFIG_USB_CDNS3.
Move CONFIG_USB_CDNSP_PCI beside CONFIG_USB_CDNS3_PCI_WRAP under
"Platform glue driver support". SoC glue entries (TI, i.MX, StarFive)
depend only on CONFIG_USB_CDNS3.
Tighten CONFIG_USB_CDNS_SUPPORT dependencies so the umbrella follows
host or gadget when either is built as a module. Match host and gadget
bools to the cdns.ko tristate with USB=USB_CDNS3 and USB_GADGET=USB_CDNS3
instead of comparing against USB_CDNS_SUPPORT.
Link host.o when CONFIG_USB_CDNS3_HOST is enabled and use that symbol in
host-export.h, removing the redundant CONFIG_USB_CDNS_HOST indirection.
Export cdns_core_init_role and reorganize the function cdns_init, and
controller version could be gotten before the gadget init function is
decided per controller.
Keep host_init / gadget_init callbacks in struct cdns, so core.c does
not need direct linkage to host or gadget objects. Refactor cdnsp-pci.c
into a thin PCI-to-platform wrapper.
drivers/usb/Makefile: descend into drivers/usb/cdns3/ only when
CONFIG_USB_CDNS_SUPPORT is enabled.
Peter Chen [Tue, 21 Apr 2026 02:34:58 +0000 (10:34 +0800)]
dt-bindings: usb: cdns,usb3: document USBSSP controller support
Update the Cadence USBSS DRD binding to document that it also covers
the USBSSP (SuperSpeed Plus, USB 3.1 gen2x1) controller. Both USBSS
and USBSSP share the same DRD/OTG register interface, so the driver
auto-detects the controller version at runtime: no additional
compatible string is needed.
Changes to the binding:
- Update title and add description
- maximum-speed: add super-speed-plus
Xu Yang [Thu, 23 Apr 2026 09:53:55 +0000 (17:53 +0800)]
usb: gadget: udc: skip pullup() if already connected
The device controller may update vbus status via usb_udc_vbus_handler(),
which tries to connect the gadget even though gadget_bind_driver() has
already called usb_udc_connect_control_locked(). This causes pullup() to
be called twice. Avoid this by checking if gadget->connected is true.
This also set gadget->connected as false in usb_gadget_activate() if it
became connected while it was being deactivated. Otherwise,
usb_gadget_connect_locked will return early and pullup() won't be called.
projects / thirdparty / linux.git / log
