summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
12 dayswifi: cfg80211: tests: check BSS lookup failure reasonsLouis Kotze
Add a KUnit test for the extack failure reasons that __cfg80211_get_bss() now reports: no matching scan entry at all, a matching entry that is expired, and a matching entry whose use_for flags do not allow the requested use. Also cover the cases that must not report a failure (a fresh entry, and an expired-but-held entry), an entry that is both expired and unusable, and the combined message when one matching entry is expired while another is current but unusable. Signed-off-by: Louis Kotze <loukot@gmail.com> Link: https://patch.msgid.link/20260722070734.3612581-3-loukot@gmail.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
12 dayswifi: cfg80211: say why the auth/assoc BSS lookup failedLouis Kotze
The BSS lookup for an authentication or association request can fail for three distinct reasons: cfg80211 has no scan entry at all for the BSSID/channel, an entry exists but is older than IEEE80211_SCAN_RESULT_EXPIRE (and not held), or a fresh entry exists but its use_for flags do not allow this use. All three currently surface as the same generic extack message "Error fetching BSS for link" on the MLO association path, and as a bare -ENOENT with no message at all on the authentication and non-MLO association paths. Since wpa_supplicant logs the extack message verbatim ("nl80211: kernel reports: ..."), that message is often the only diagnostic a user sees when an MLO association degrades to fewer links, and it does not say whether a fresh scan could have helped. In practice the expired case is common for MLO partner links: 6 GHz is passive-scan in many regulatory domains, so the partner-link entry is routinely stale by the time userspace requests the association even though the link is perfectly usable. Let __cfg80211_get_bss() take an optional extack and record, during the same bss_lock walk that fails the lookup, whether any matching entry was rejected for being expired or for not being usable for the requested use, and set a distinct message for each case (and a combined one when different entries were rejected for different reasons). Reorder the checks in the walk so that an entry's identity (type, privacy, channel, BSSID/SSID) is established before the usability checks; this doesn't change which entry is returned since an entry is only used when all checks pass. Also give the -EINVAL paths in nl80211_assoc_bss() proper messages while at it, and keep pointing the bad_attr at the failing link on the MLO path there; the message for that case is already set by the lookup itself. Signed-off-by: Louis Kotze <loukot@gmail.com> Link: https://patch.msgid.link/20260722070734.3612581-2-loukot@gmail.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
12 dayswifi: mac80211_hwsim: report TX status link_idPriyansha Tiwari
Populate link_valid/link_id in mac80211_hwsim TX status so the transmitted link is reported to mac80211. Set the link information in both the direct TX status path and the wmediumd/netlink TX status path. With that done, enable NL80211_EXT_FEATURE_PROBE_AP. Signed-off-by: Priyansha Tiwari <priyansha.tiwari@oss.qualcomm.com> Link: https://patch.msgid.link/20260709114228.672317-3-pritiwa@qti.qualcomm.com [add note about NL80211_EXT_FEATURE_PROBE_AP] Signed-off-by: Johannes Berg <johannes.berg@intel.com>
12 daysof: base: Handle optional argument in of_parse_phandle_with_args_map()Miquel Raynal (Schneider Electric)
The kernel doc claims out_args is optional. In practice, the function unconditionally dereferences it. It feels like calling this function with a NULL out_args argument may be a valid use case (in order to know if the lookup would work, even though we might not care about the result), even though in practice there seem to be no actual user of that possibility. All callers give an on-stack object to fill. There are two ways out: either we drop the "optional" wording from the kernel doc, or we handle the NULL case properly. Since handling this case goes in favor of more harmonization of the semantics and since of_parse_phandle_with_args() actually do handle that situation correctly, let's handle it in the _map() case as well. Use a local on-stack object in case no argument is passed. This way, we actually go through the same logic as if there was an argument. We may however return rather early, since the second part of the function is dedicated at filling that argument. Reported-by: Sashiko <sashiko-bot@kernel.org> Closes: https://lore.kernel.org/all/20260710183359.61D3A1F000E9@smtp.kernel.org/ Signed-off-by: Miquel Raynal (Schneider Electric) <miquel.raynal@bootlin.com> Link: https://patch.msgid.link/20260716-schneider-v7-2-rc1-eip-of-fix-v1-1-9b9383f936c6@bootlin.com Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
12 daysARM: npcm: Fix OF node refcount leaks in SMP setupYuho Choi
npcm7xx_smp_boot_secondary() and npcm7xx_smp_prepare_cpus() look up the GCR and SCU nodes with of_find_compatible_node(). The returned nodes are used for of_iomap(), but the node references are never released. of_iomap() does not consume the device node reference, and iounmap() only releases the MMIO mapping. Drop each node reference after the corresponding mapping attempt. Fixes: 7bffa14c9aed ("arm: npcm: add basic support for Nuvoton BMCs") Signed-off-by: Yuho Choi <dbgh9129@gmail.com> Reviewed-by: Avi Fishman <avifishman70@gmail.com> Signed-off-by: Andrew Jeffery <andrew@codeconstruct.com.au>
12 daysproc: Fix broken error paths for namespace linksJann Horn
Don't return the return value of down_read_killable() (0) when a ptrace access check fails, return -EACCES as intended. Reported-by: Magnus Lindholm <linmag7@gmail.com> Closes: https://lore.kernel.org/r/20260706170735.2941493-1-linmag7@gmail.com Fixes: 6650527444da ("proc: protect ptrace_may_access() with exec_update_lock (part 1)") Cc: stable@vger.kernel.org Signed-off-by: Jann Horn <jannh@google.com> Link: https://patch.msgid.link/20260706-procfs-ns-eacces-fix-v1-1-a69ab14c02e6@google.com Tested-by: Magnus Lindholm <linmag7@gmail.com> Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
12 daysdrm/v3d: Idle AXI transactions before disabling the clock on suspendMaíra Canal
Currently, v3d_power_suspend() removes the GPU clock without first quiescing the GPU's memory interface (AXI). If the clock is cut while the core still has outstanding AXI transactions in flight, the hardware is frozen mid-transaction. That corrupted state survives the power cycle, and the first job submitted after the next resume will cause a GPU hang accompanied by an L2T "pte invalid" MMU fault. The hardware already provides a safe-powerdown sequence for this: request the GMP to stop and wait for outstanding reads/writes to drain (v3d_idle_axi()), plus the GCA safe shutdown on pre-4.1 HW (v3d_idle_gca()). The driver implements both, but the runtime PM support added later never invoked them when powering the GPU down. Perform the safe-powerdown sequence in v3d_power_suspend() before disabling the clock, while the core is still powered. Link: https://github.com/raspberrypi/linux/issues/7443 Link: https://github.com/raspberrypi/linux/issues/7488 Fixes: 458f2a712ab4 ("drm/v3d: Introduce Runtime Power Management") Reviewed-by: Iago Toral Quiroga <itoral@igalia.com> Link: https://patch.msgid.link/20260718-v3d-pm-axi-transactions-v1-2-4ecd7729ed70@igalia.com Signed-off-by: Maíra Canal <mcanal@igalia.com>
12 daysio_uring/rw: fix missing ERESTARTSYS conversion in read pathsYitang Yang
Both read and write may receive internal restart error codes from the filesystem layer and should be converted to -EINTR. However, when multishot read support was added, the error code normalization was lost for both io_read() and io_read_mshot(). Extract the conversion into io_fixup_restart_res() and apply it in all three locations: io_rw_done(), io_read(), and io_read_mshot(). Fixes: a08d195b586a ("io_uring/rw: split io_read() into a helper") Cc: stable@vger.kernel.org Signed-off-by: Yitang Yang <yi1tang.yang@gmail.com> Link: https://patch.msgid.link/20260722124551.130563-1-yi1tang.yang@gmail.com Signed-off-by: Jens Axboe <axboe@kernel.dk>
12 dayswifi: mac80211: implement STA-mode peer probingPriyansha Tiwari
Add STA/P2P-client support to ieee80211_probe_peer(): when called for a station interface, send a null-data frame (TODS) to the associated AP and report the ACK via cfg80211_probe_status(). For MLO connections the driver/firmware selects the link (IEEE80211_LINK_UNSPECIFIED); for non-MLO the single link is used. Signed-off-by: Priyansha Tiwari <priyansha.tiwari@oss.qualcomm.com> Link: https://patch.msgid.link/20260709114228.672317-2-pritiwa@qti.qualcomm.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
12 daysdrm/v3d: Reach the GMP through the hub registers on V3D 7.xMaíra Canal
v3d_idle_axi() drains the GPU's memory interface for a safe powerdown by using the V3D_GMP_CFG register. It reached both registers with the macros V3D_CORE_READ and V3D_CORE_WRITE. On V3D 7.x the GMP is no longer a per-core block; it lives in the hub register region. Reaching it through the per-core register block addresses the wrong region. Select the hub accessors (V3D_{READ,WRITE}) for the GMP on V3D 7.x and keep the per-core path for earlier generations. Cc: stable@vger.kernel.org Fixes: 0ad5bc1ce463 ("drm/v3d: fix up register addresses for V3D 7.x") Link: https://patch.msgid.link/20260718-v3d-pm-axi-transactions-v1-1-4ecd7729ed70@igalia.com Reviewed-by: Iago Toral Quiroga <itoral@igalia.com> Signed-off-by: Maíra Canal <mcanal@igalia.com>
12 daysthermal: intel: int340x: clean up RFIM groups on DVFS failurePengpeng Hou
proc_thermal_rfim_add() can create the FIVR and DLVR sysfs groups before creating the DVFS group. If DVFS group creation fails while both earlier groups are enabled, the current error handling removes only one group: the FIVR branch returns before the DLVR cleanup branch can run. This leaves the DLVR group behind even though RFIM setup fails. Use one DVFS failure path that removes all previously created RFIM groups before returning the error. Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn> Link: https://patch.msgid.link/20260615065245.84252-1-pengpeng@iscas.ac.cn Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
12 daysdt-bindings: arm-smmu: qcom: Add compatible for Maili SoCJingyi Wang
Qualcomm Maili SoC includes apps smmu that implements arm,mmu-500, which is used to translate device-visible virtual addresses to physical addresses. Add compatible for it. Signed-off-by: Jingyi Wang <jingyi.wang@oss.qualcomm.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Signed-off-by: Will Deacon <will@kernel.org>
12 daysdt-bindings: iommu: ti,omap-iommu: Convert to DT schemaBhargav Joshi
Convert Texas Instruments OMAP2+ IOMMU from text to DT schema. Make the 'ti,hwmods' property optional and mark it deprecated as it is no longer used, it is kept to support legacy dtbs. Signed-off-by: Bhargav Joshi <j.bhargav.u@gmail.com> Reviewed-by: Rob Herring (Arm) <robh@kernel.org> Signed-off-by: Will Deacon <will@kernel.org>
12 daysiommu/tegra241-cmdqv: Fix CMD_SYNC use-after-free on teardownShameer Kolothum
arm_smmu_impl_remove() is registered as a devres action in arm_smmu_impl_probe(), before arm_smmu_init_queues() allocates smmu->cmdq.q.base. On a devres unwind, whether a failed probe or an unbind, the queue is freed first and arm_smmu_impl_remove() then runs tegra241_cmdqv_remove_vintf(), whose VINTF deinit issues a CMD_SYNC on the freed memory. Observed during testing with a QEMU hack that makes the VCMDQ fail to enable, so the impl reset fails and probe aborts into the devres unwind: platform NVDA200C:00: tegra241_cmdqv: VINTF0: VCMDQ0/LVCMDQ0: failed to enable, STATUS=0x00000000 platform NVDA200C:00: tegra241_cmdqv: VINTF0: VCMDQ0/LVCMDQ0: GERRORN=0x0, GERROR=0x4, CONS=0x0 platform NVDA200C:00: tegra241_cmdqv: VINTF0: VCMDQ0/LVCMDQ0: uncleared error detected, resetting arm-smmu-v3 arm-smmu-v3.0.auto: failed to reset impl arm-smmu-v3 arm-smmu-v3.0.auto: probe with driver arm-smmu-v3 failed with error -110 Unable to handle kernel paging request at virtual address ffff8000891e0098 ... Internal error: Oops: 0000000096000047 [#1] SMP ... Call trace: arm_smmu_cmdq_issue_cmdlist+0x320/0x6fc (P) tegra241_vcmdq_hw_deinit+0x98/0x168 tegra241_vintf_hw_deinit+0x5c/0x1b0 tegra241_cmdqv_remove_vintf+0x34/0xec tegra241_cmdqv_remove+0x40/0x9c arm_smmu_impl_remove+0x20/0x30 devm_action_release+0x14/0x20 devres_release_all+0xa8/0x110 device_unbind_cleanup+0x18/0x84 really_probe+0x1f0/0x29c Drop the VINTF deinit from tegra241_cmdqv_remove_vintf() so the unwind no longer touches the freed queue. Quiesce the VINTFs earlier instead. Add a device_disable() impl op and run it from arm_smmu_disable_action() while the CMDQ is still up. That handles a live unbind. A failed reset is already handled because tegra241_vintf_hw_init() deinits the VINTF on its own error path. tegra241_cmdqv_remove_vintf() is also used by the iommufd viommu destroy path, so quiesce there too. Fixes: 4dc0d12474f9 ("iommu/tegra241-cmdqv: Add user-space use support") Cc: stable@vger.kernel.org Reviewed-by: Nicolin Chen <nicolinc@nvidia.com> Signed-off-by: Shameer Kolothum <skolothumtho@nvidia.com> Reviewed-by: Jason Gunthorpe <jgg@nvidia.com> Signed-off-by: Will Deacon <will@kernel.org>
12 daysiommu/arm-smmu-v3: Manage teardown with devmShameer Kolothum
arm_smmu_device_remove() manually frees the IOPF queue, destroys the vmid_map and disables the device, while the IRQs and queues are devm managed. devm unwinds only after remove() returns, so the cleanup runs in the wrong order. The IOPF queue is freed before the event-queue IRQ whose handler uses it. Manage all of it with devm so the unwind order is correct. Free the IOPF queue and vmid_map via devm actions, and disable the device from one registered after arm_smmu_device_reset(). This is also a prerequisite for fixing a Tegra241 CMDQV CMD_SYNC use-after-free in the subsequent patch. Cc: stable@vger.kernel.org Suggested-by: Jason Gunthorpe <jgg@ziepe.ca> Reviewed-by: Nicolin Chen <nicolinc@nvidia.com> Signed-off-by: Shameer Kolothum <skolothumtho@nvidia.com> Reviewed-by: Jason Gunthorpe <jgg@nvidia.com> Signed-off-by: Will Deacon <will@kernel.org>
12 dayscpufreq: schedutil: Replace sprintf() with sysfs_emit() in sysfs showZhongqiu Han
Use sysfs_emit() instead of sprintf() in rate_limit_us_show(). sysfs_emit() is the preferred API for sysfs output as it provides PAGE_SIZE bounds checking and ensures proper sysfs formatting. No functional change intended. Signed-off-by: Zhongqiu Han <zhongqiu.han@oss.qualcomm.com> Link: https://patch.msgid.link/20260716131546.1159644-1-zhongqiu.han@oss.qualcomm.com Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
12 dayscpufreq: schedutil: Publish util hooks only after all sg_cpu are initializedZhongqiu Han
Commit 16a03c71bba0 ("cpufreq: schedutil: Merge initialization code of sg_cpu in single loop") merged the per-CPU initialization and the utilization-hook registration into a single loop in sugov_start(). For a shared cpufreq policy this re-introduces the race originally fixed by commit ab2f7cf141aa ("cpufreq: schedutil: Fix sugov_start() versus sugov_update_shared() race"). The scheduler's util path reaches the hook under RCU-sched and never takes policy->rwsem, so the rwsem held across sugov_start() cannot serialize the two. Once the first CPU's hook is published, sugov_update_shared() may run and, via sugov_next_freq_shared(), read/write each sibling sugov_cpu (iowait_boost, util, bw_min, ...) concurrently with the memset() still initializing them, with no lock common to both sides: the update side holds sg_policy->update_lock while the init side holds only policy->rwsem, which the scheduler's util path never takes. The walk only accesses scalar members, never a pointer like ->sg_policy, so it does not crash today; it merely uses stale (or zero on first start) values that skew the frequency selection and tracepoints. It is still a genuine data race, and a latent crash once any pointer member is dereferenced there. Restore the two-phase approach: initialize all per-CPU structures first, and only then publish the per-CPU utilization update hooks. Fixes: 16a03c71bba0 ("cpufreq: schedutil: Merge initialization code of sg_cpu in single loop") Cc: stable@vger.kernel.org Signed-off-by: Zhongqiu Han <zhongqiu.han@oss.qualcomm.com> Reviewed-by: Christian Loehle <christian.loehle@arm.com> Link: https://patch.msgid.link/20260716115159.848403-1-zhongqiu.han@oss.qualcomm.com Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
12 daysiommu/arm-smmu-v3: Declare eats_s1chk and eats_trans as host-endian u64Nicolin Chen
arm_smmu_get_ste_update_safe() declares the eats_s1chk and eats_trans locals as __le64, but initializes them from FIELD_PREP(), which returns a host-endian value, and passes them through cpu_to_le64() at the use sites. Sparse reports the following warnings: >> drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c:1122:38: sparse: sparse: cast from restricted __le64 drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c:1124:33: sparse: sparse: cast from restricted __le64 Declare both locals as u64 so the type matches FIELD_PREP() and the existing cpu_to_le64() at the use sites performs the host-to-little-endian conversion. No functional change. Fixes: 7cad80048595 ("iommu/arm-smmu-v3: Mark EATS_TRANS safe when computing the update sequence") Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/all/202606151017.QU0evpH9-lkp@intel.com/ Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Nicolin Chen <nicolinc@nvidia.com> Reviewed-by: Jason Gunthorpe <jgg@nvidia.com> Reviewed-by: Pranjal Shrivastava <praan@google.com> Signed-off-by: Will Deacon <will@kernel.org>
12 daysiommu: arm: Remove redundant dev_err()/dev_err_probe()Pan Chuang
Since commit 55b48e23f5c4 ("genirq/devres: Add error handling in devm_request_*_irq()"), devm_request_irq() and devm_request_threaded_irq() automatically log detailed error messages on failure. Remove the now-redundant driver-specific dev_err() and dev_err_probe() calls. Signed-off-by: Pan Chuang <panchuang@vivo.com> Reviewed-by: Robin Murphy <robin.murphy@arm.com> Signed-off-by: Will Deacon <will@kernel.org>
12 daysxfs: use kmalloc_objs() instead of kmalloc() in xfs_da_grow_inode_intCihan Karadag
Convert open-coded kmalloc() multiplication to the modern kmalloc_objs() interface to improve type safety and prevent potential integer overflows. No functional changes are intended. Signed-off-by: Cihan Karadag <cihan.cihan@gmail.com> Reviewed-by: Carlos Maiolino <cmaiolino@redhat.com> Reviewed-by: "Darrick J. Wong" <djwong@kernel.org> Signed-off-by: Carlos Maiolino <cem@kernel.org>
12 daysxfs: mark internal metadir file creation helpers staticJohannes Thumshirn
Now that there is xfs_metadir_create_file() mark xfs_metadir_start_create(), xfs_metadir_create() and xfs_metadir_cancel() as static and remove them from xfs_metadir.h. Signed-off-by: Johannes Thumshirn <johannes.thumshirn@wdc.com> Reviewed-by: "Darrick J. Wong" <djwong@kernel.org> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Carlos Maiolino <cem@kernel.org>
12 daysxfs: create rtgroup metadir inodes using xfs_metadir_create_fileJohannes Thumshirn
Now that we have xfs_metadir_create_file() use it in xfs_rtginode_create(). Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Johannes Thumshirn <johannes.thumshirn@wdc.com> Reviewed-by: "Darrick J. Wong" <djwong@kernel.org> Signed-off-by: Carlos Maiolino <cem@kernel.org>
12 daysxfs: create quota metadir inodes using xfs_metadir_create_fileJohannes Thumshirn
Now that we have xfs_metadir_create_file() use it in xfs_dqinode_metadir_create(). Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Johannes Thumshirn <johannes.thumshirn@wdc.com> Reviewed-by: "Darrick J. Wong" <djwong@kernel.org> Signed-off-by: Carlos Maiolino <cem@kernel.org>
12 daysxfs: add xfs_metadir_create_file helperJohannes Thumshirn
Factor the metadata inode create/commit/cleanup lifecycle out of xfs_metadir_mkdir into a reusable helper that takes an optional callback to initialize the new inode, and convert xfs_metadir_mkdir to it. Signed-off-by: Johannes Thumshirn <johannes.thumshirn@wdc.com> Reviewed-by: "Darrick J. Wong" <djwong@kernel.org> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Carlos Maiolino <cem@kernel.org>
12 daysxfs: add support for FALLOC_FL_WRITE_ZEROESPankaj Raghav
If the underlying block device supports the unmap write zeroes operation, this flag allows users to quickly preallocate a file with written extents that contain zeroes. This is beneficial for subsequent overwrites as it prevents the need for unwritten-to-written extent conversions, thereby significantly reducing metadata updates and journal I/O overhead, improving overwrite performance. Punch the range first so it becomes a hole, update the size via xfs_falloc_setsize() while it is still a hole (so its xfs_zero_range() skips it and avoids rezeroing), then convert it to written zeroed extents. A crash between the size update and the conversion is safe, as a hole within i_size reads back as zeroes. Co-developed-by: Lukas Herbolt <lukas@herbolt.com> Signed-off-by: Lukas Herbolt <lukas@herbolt.com> Signed-off-by: Pankaj Raghav <p.raghav@samsung.com> Reviewed-by: "Darrick J. Wong" <djwong@kernel.org> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Carlos Maiolino <cem@kernel.org>
12 daysxfs: add an allocation mode to xfs_alloc_file_space()Pankaj Raghav
xfs_alloc_file_space() hardcodes XFS_BMAPI_PREALLOC to preallocate unwritten extents across a range. In preparation for FALLOC_FL_WRITE_ZEROES, add an explicit allocation mode argument, enum xfs_alloc_file_space_mode, and derive the xfs_bmapi flags from it. The only mode for now is XFS_ALLOC_FILE_SPACE_PREALLOC, which preallocates unwritten extents and marks the inode as preallocated exactly as before, so there is no functional change. Reviewed-by: Christoph Hellwig <hch@lst.de> Reviewed-by: "Darrick J. Wong" <djwong@kernel.org> Signed-off-by: Pankaj Raghav <p.raghav@samsung.com> Signed-off-by: Carlos Maiolino <cem@kernel.org>
12 dayscpufreq: cppc: Sanitize lockless policy limit snapshotsChristian Loehle
cppc_cpufreq_update_perf_limits() reads policy->min and policy->max without holding the policy lock. The cpufreq core updates those fields with separate stores, so a reader can observe the old minimum together with the new maximum and construct MIN_PERF greater than MAX_PERF. Read both fields once and, if the lockless snapshot is inconsistent, reduce the minimum to the observed maximum. This matches the conservative correction used by cpufreq_driver_resolve_freq() and ensures that CPPC never receives an inverted limit pair. Fixes: ea3db45ae476 ("cpufreq: cppc: Update MIN_PERF/MAX_PERF in target callbacks") Cc: stable@vger.kernel.org Signed-off-by: Christian Loehle <christian.loehle@arm.com> Link: https://patch.msgid.link/20260722093825.1030594-3-christian.loehle@arm.com Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
12 daysACPI: CPPC: Check all controls for fast switchingChristian Loehle
ACPI 6.2, Section 6.2.11.2 permits _CPC registers to use flexible address spaces. Linux advertises that capability through _OSC and parses the address space of each _CPC register independently. A directly accessible DESIRED_PERF combined with PCC-backed limits is therefore a valid configuration. cppc_allow_fast_switch() only checks DESIRED_PERF, although the fast-switch callback passes DESIRED_PERF, MIN_PERF and MAX_PERF to cppc_set_perf(). If a limit uses PCC, that function can sleep while called from scheduler context. Allow fast switching only when every supported control used by the callback has an address space already accepted for fast access. Check the complete policy domain, including initialized CPUs that are currently offline and may later become the policy's managing CPU. Fixes: 658fa7b1c47a ("ACPI: CPPC: Add cppc_get_perf() API to read performance controls") Cc: stable@vger.kernel.org Signed-off-by: Christian Loehle <christian.loehle@arm.com> Link: https://patch.msgid.link/20260722093825.1030594-2-christian.loehle@arm.com Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
12 daysiommu/qcom: Enable clocks before hardware access in qcom_iommu_ctx_probe()Mukesh Ojha
qcom_iommu_ctx_probe() reads and writes the CB_FSR register to clear any stale IRQ left by the bootloader. This happens during devm_of_platform_populate() which is called from the parent device's probe before any pm_runtime_get(). The parent's clocks (iface, bus, tbu) are therefore not guaranteed to be on, making the register access unreliable on rebind or after a suspend cycle. Use pm_runtime_resume_and_get() on the parent device to ensure clocks are enabled before the register access, and release the reference immediately after. Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com> Signed-off-by: Will Deacon <will@kernel.org>
12 daysiommu/qcom: Publish pgtbl_ops before releasing init_mutexMukesh Ojha
qcom_domain->pgtbl_ops was assigned after mutex_unlock(). Another thread calling qcom_iommu_init_domain() would see qcom_domain->iommu already set (domain fully initialized) and skip re-initialization under the mutex. If it then called qcom_iommu_map() before the first thread set pgtbl_ops, it would observe a NULL ops pointer and return -ENODEV for valid mappings. Move the assignment to before mutex_unlock() so that once the mutex is released the domain is fully visible to concurrent operations. Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com> Signed-off-by: Will Deacon <will@kernel.org>
12 daysiommu/qcom: Fix pgtbl_ops leak in qcom_iommu_init_domain() error pathMukesh Ojha
alloc_io_pgtable_ops() can succeed and then qcom_scm_restore_sec_cfg() can fail for one of the context banks. The goto out_clear_iommu path only cleared qcom_domain->iommu; the locally allocated pgtbl_ops was never freed, leaking it permanently since qcom_domain->pgtbl_ops is only assigned on the success path. free_io_pgtable_ops() safely handles a NULL argument (covers the case where alloc_io_pgtable_ops() itself failed), so add it unconditionally in the out_clear_iommu handler. Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com> Signed-off-by: Will Deacon <will@kernel.org>
12 daysiommu/qcom: Check pm_runtime_resume_and_get() return in probeMukesh Ojha
The SMMU_INTR_SEL_NS register write in qcom_iommu_device_probe() uses pm_runtime_get_sync() without checking the return value. If runtime resume fails the subsequent writel_relaxed() would access hardware with clocks potentially disabled. Switch to pm_runtime_resume_and_get() which handles the usage-count cleanup on failure, check the return value, and unwind the already registered iommu device on error. Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com> Signed-off-by: Will Deacon <will@kernel.org>
12 daysiommu/qcom: Use devm_pm_runtime_enable() in qcom_iommu_device_probe()Mukesh Ojha
Switch from pm_runtime_enable() to devm_pm_runtime_enable() so that the matching pm_runtime_disable() is handled automatically via devres, both on probe failure and on device removal. This removes the err_pm_disable error label from the probe function and the explicit pm_runtime_disable() call from qcom_iommu_device_remove(). Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Will Deacon <will@kernel.org>
12 daysiommu/qcom: Fix inverted fault report check in qcom_iommu_fault()Mukesh Ojha
report_iommu_fault() returns 0 when a fault handler successfully handles the fault, and -ENOSYS when no handler is installed. The condition '!report_iommu_fault()' evaluates to true (printing "Unhandled context fault") precisely when the fault *was* handled, and stays silent when no handler is present — the opposite of what is intended. Remove the '!' so the driver logs unhandled faults correctly. Fixes: 049541e178d5 ("iommu: qcom: wire up fault handler") Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com> Signed-off-by: Will Deacon <will@kernel.org>
12 daysxfs: mark nonzero sb_gquotino as corrupt on metadir filesystemsDarrick J. Wong
On a metadir filesystem, the superblock gquotino field is always zero because we find the quota inodes through the metadata directory tree. A nonzero value is therefore a corruption (as pointed out by LOLLM) so mark the failure as such. Cc: stable@vger.kernel.org # v6.13 Fixes: 06b20ef09ba163 ("xfs: check pre-metadir fields correctly") Signed-off-by: "Darrick J. Wong" <djwong@kernel.org> Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Carlos Maiolino <cem@kernel.org>
12 daysxfs: zero i_nlink before repair puts inode on unlinked listDarrick J. Wong
LOLLM observes that we don't reset i_nlink if we encounter a file with no parent that isn't on the unlinked list. This causes unnecessary assertion trips on debugging kernels and an inconsistent file, so let's fix that. Cc: stable@vger.kernel.org # v6.10 Fixes: 669dfe883c8e20 ("xfs: update the unlinked list when repairing link counts") Signed-off-by: "Darrick J. Wong" <djwong@kernel.org> Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Carlos Maiolino <cem@kernel.org>
12 daysxfs: rtsummary scrub should treat rtbitmap corruption errors as an xref errorDarrick J. Wong
LOLLM notes the discrepancy between the comment saying that this is an xref error and the code, which marks a (non-xref) corruption error. This appears to be a regression. Cc: stable@vger.kernel.org # v6.13 Fixes: e3088ae2dcae3c ("xfs: move RT bitmap and summary information to the rtgroup") Signed-off-by: "Darrick J. Wong" <djwong@kernel.org> Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Carlos Maiolino <cem@kernel.org>
12 daysxfs: fix transaction block reservation in xrep_rtbitmapDarrick J. Wong
LOLLM pointed out an inconsistency in the block reservation code in xrep_rtbitmap. The first is that the reservation computation is not consistent between the code that sets up the repair and the code that tries to avoid exceeding the transaction reservation once we know how big the rtbitmap really must be. As a result, the logic doesn't work. In fixing that, a second problem emerges: if we do readjust, we ask for the entire reservation all over again. We really only need the delta, so ask only for that. Fix all these problems by hoisting the computation to a trivial helper so that it gets used in both places. Cc: stable@vger.kernel.org # v6.14 Fixes: 8defee8dff2b20 ("xfs: online repair of realtime bitmaps for a realtime group") Signed-off-by: "Darrick J. Wong" <djwong@kernel.org> Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Carlos Maiolino <cem@kernel.org>
12 daysxfs: check cowextsize in xrep_inode_cowextsizeDarrick J. Wong
LOLLM points out that the function that corrects cowextsize should check i_cowextsize, not i_extsize. Cc: stable@vger.kernel.org # v6.14 Fixes: a9600db96f74af ("xfs: detect and repair misaligned rtinherit directory cowextsize hints") Signed-off-by: "Darrick J. Wong" <djwong@kernel.org> Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Carlos Maiolino <cem@kernel.org>
12 daysxfs: update BDI {io,ra}_pages values based on the RT device limitsChristoph Hellwig
When using XFS with a main device on an SSD that stores metadata and a RT device to store data on a HDD, we fail to take the I/O sizes for the RT device into accounting, leading to up to 5% slower read performance when using an SSD for metadata vs storing data and metadata on the HDD. Fix this up by taking the RT settings into account at mount an restoring the old settings at unmount time, unless the BDI settings have changed from those set by XFS. Reported-by: Filip Blagojevic <filip.blagojevic@wdc.com> Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Carlos Maiolino <cmaiolino@redhat.com> Reviewed-by: Damien Le Moal <dlemoal@kernel.org> Signed-off-by: Carlos Maiolino <cem@kernel.org>
12 daysxfs: handle NULL b_addr in xfs_buf_freeYun Zhou
When xfs_buf_alloc_backing_mem() fails, xfs_buf_free() is called with bp->b_addr still NULL. The code falls through to the folio_put path which calls virt_to_folio(NULL), dereferencing an invalid address and causing a kernel crash. Call Trace: xfs_buf_free+0x25f/0x510 xfs_buf_alloc+0xc98/0x19b0 xfs_buf_find_insert+0x55/0x14d0 xfs_buf_get_map+0x122b/0x17c0 xfbtree_init_leaf_block+0x11c/0x4a0 xfbtree_init+0x1bb/0x460 xrep_rmap_setup_scan+0x100/0x1f0 xrep_rmapbt+0x41/0xc0 Fix this by skipping folio_put() when bp->b_addr is NULL. Fixes: 5076a6040ca1 ("xfs: support in-memory buffer cache targets") Reported-by: syzbot+94c22d92f72f5a235b7d@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=94c22d92f72f5a235b7d Signed-off-by: Yun Zhou <yun.zhou@windriver.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Carlos Maiolino <cem@kernel.org>
12 daysxfs: bounds-check buffer log item's dirty bitmapIbrahim Hashimov
xlog_recover_do_reg_buffer() replays each dirty region described by a buffer log item's bitmap into the buffer read for that item: memcpy(xfs_buf_offset(bp, (uint)bit << XFS_BLF_SHIFT), item->ri_buf[i].iov_base, nbits << XFS_BLF_SHIFT); The destination offset (bit/nbits, from the logged dirty bitmap) and the buffer size (from the logged blf_len) are both attacker-controlled and otherwise unrelated, yet the only thing bounding the copy is an ASSERT(), which compiles away on production kernels. A crafted image logging a small blf_len together with a bitmap bit past the end of that buffer drives the memcpy() past the buffer's allocation, corrupting adjacent kernel heap during mount-time log recovery. This is reachable by anyone who can get a crafted image mounted -- the malicious-filesystem threat model XFS already guards against elsewhere. Turn the ASSERT() into a real XFS_IS_CORRUPT() check that aborts recovery of the buffer with -EFSCORRUPTED, consistent with the validate-and-fail idiom already used in xlog_recover_do_inode_buffer() and xfs_dquot_item_recover.c. xlog_recover_do_reg_buffer() therefore becomes STATIC int and its three callers propagate the error. Found and confirmed with KASAN on a CONFIG_XFS_DEBUG=n build: the crafted image trips a slab-out-of-bounds write before this change and fails recovery cleanly with -EFSCORRUPTED after it. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org Signed-off-by: Ibrahim Hashimov <security@auditcode.ai> Reviewed-by: "Darrick J. Wong" <djwong@kernel.org> Reviewed-by: Brian Foster <bfoster@redhat.com> Signed-off-by: Carlos Maiolino <cem@kernel.org>
12 daysxfs: fix off-by-one in rtrefcount btree root level validationXiang Mei
xfs_rtrefcountbt_compute_maxlevels() sets mp->m_rtrefc_maxlevels = min(d_maxlevels, r_maxlevels) + 1; where the trailing "+ 1" already accounts for the inode-root level, so the deepest valid on-disk root level is m_rtrefc_maxlevels - 1 and a cursor must satisfy bc_nlevels <= bc_maxlevels (= m_rtrefc_maxlevels). The two on-disk validation paths, xfs_rtrefcountbt_verify() and xfs_iformat_rtrefcount(), check the root level with ">" instead of ">=", so a crafted rtreflink (metadir + realtime + reflink) image whose /rtgroups/N.refcount inode has bb_level == m_rtrefc_maxlevels is accepted on mount. xfs_rtrefcountbt_init_cursor() then sets bc_nlevels = bb_level + 1, exceeding bc_maxlevels by one. Since the xfs_rtrefcountbt_cur slab object is sized for exactly bc_maxlevels entries, the first btree op on such a cursor indexes bc_levels[m_rtrefc_maxlevels] past the end of the object. This is reached by the first rtrefcount cursor built after mount, via log/CoW recovery (xfs_reflink_recover_cow() during xfs_mountfs()) or an FS_IOC_GETFSMAP over the realtime device. Reject a root level equal to m_rtrefc_maxlevels, matching the ">=" form already used by the sibling data-device refcount/rmap verifiers and the in-memory rtrmap verifier. BUG: KASAN: slab-out-of-bounds in xfs_btree_lookup (fs/xfs/libxfs/xfs_btree.c:2101) Write of size 2 at addr ffff888018391658 by task exploit/144 xfs_btree_lookup (fs/xfs/libxfs/xfs_btree.c:2101) xfs_btree_query_range (fs/xfs/libxfs/xfs_btree.c:5308) xfs_refcount_recover_cow_leftovers (fs/xfs/libxfs/xfs_refcount.c:2113) xfs_reflink_recover_cow (fs/xfs/xfs_reflink.c:1085) xlog_recover_finish (fs/xfs/xfs_log_recover.c:3551) xfs_mountfs (fs/xfs/xfs_mount.c:1158) xfs_fs_fill_super (fs/xfs/xfs_super.c:1940) get_tree_bdev_flags (fs/super.c:1634) vfs_get_tree (fs/super.c:1694) path_mount (fs/namespace.c:4161) __x64_sys_mount (fs/namespace.c:4367) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) The buggy address belongs to the cache xfs_rtrefcountbt_cur of size 216 The buggy address is located 8 bytes to the right of allocated 216-byte region [ffff888018391578, ffff888018391650) Kernel panic - not syncing: Fatal exception Cc: stable@vger.kernel.org # v6.14 Fixes: 9abe03a0e4f978 ("xfs: introduce realtime refcount btree ondisk definitions") Reported-by: Weiming Shi <bestswngs@gmail.com> Signed-off-by: Xiang Mei <xmei5@asu.edu> Reviewed-by: "Darrick J. Wong" <djwong@kernel.org> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Carlos Maiolino <cem@kernel.org>
12 daysxfs: clear zapped attr fork state when bmap repair finds no attr forkQiang Ma
xfstests xfs/377 can make xfs_scrub repeatedly check and repair the attr block map after inode repair zaps an attr fork. When inode repair zaps an attr fork, it records XFS_SICK_INO_BMBTA_ZAPPED so that scrub/repair can revisit the attr fork block map. If the fork has been reset to an empty state and removed, BMBTA repair has no attr fork mappings to rebuild and can return success. The post-repair scrub then runs with XREP_ALREADY_FIXED set, which means xchk_file_looks_zapped() deliberately ignores the stale zapped health bit and asks xchk_bmap() to check the current attr fork. For an absent attr fork, xchk_bmap() returns -ENOENT. Returning that error prevents xchk_bmap_attr() from marking XFS_SICK_INO_BMBTA_ZAPPED healthy, leaving the zapped health state behind even though there are no attr fork mappings left to check. Treat -ENOENT during post-repair BMBTA revalidation as a clean result for the zapped attr fork: clear XFS_SICK_INO_BMBTA_ZAPPED and return success. Keep the existing -ENOENT behavior for ordinary scrubs of absent attr forks. Fixes: d9041681dd2f ("xfs: set inode sick state flags when we zap either ondisk fork") Cc: stable@vger.kernel.org # v6.8 Reviewed-by: "Darrick J. Wong" <djwong@kernel.org> Signed-off-by: Qiang Ma <maqianga@uniontech.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Carlos Maiolino <cem@kernel.org>
12 daysmailmap: Update Maíra Canal's email addressMaíra Canal
My university email will cease to exist in the next few days, so map it to a personal email address. Reviewed-by: André Almeida <andrealmeid@igalia.com> Acked-by: Maíra Canal <mairacanal@riseup.net> Link: https://patch.msgid.link/20260717111559.2759217-1-maira.canal@usp.br Signed-off-by: Maíra Canal <maira.canal@usp.br>
12 daysMAINTAINERS: Add Radu Rendec as reviewer for the interrupt subsystemThomas Gleixner
Radu stepped up some time ago to help reviewing patches for the generic interupt subsystem, interrupt domains and interrupt chip drivers. Make it official so submitters add him on Cc. Signed-off-by: Thomas Gleixner <tglx@kernel.org> Acked-by: Radu Rendec <radu@rendec.net> Link: https://patch.msgid.link/87h5lslpy9.ffs@fw13
12 daysiommu/qcom: Remove sysfs device on probe failure pathHaoxiang Li
In qcom_iommu_device_probe(), if iommu_device_register() fails, the sysfs device created by iommu_device_sysfs_add() is not released. Add a goto label to do the cleanup. Fixes: 0ae349a0f33f ("iommu/qcom: Add qcom_iommu") Signed-off-by: Haoxiang Li <haoxiang_li2024@163.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Reviewed-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com> Signed-off-by: Will Deacon <will@kernel.org>
12 dayssoc: aspeed: lpc-snoop: Fix usercopy overflow in snoop_file_readKarthikeyan KS
put_fifo_with_discard() acts as both producer and consumer on the kfifo: it calls kfifo_skip() (advances out) and kfifo_put() (advances in) from the IRQ handler without synchronizing with snoop_file_read(), which also consumes via kfifo_to_user(). On SMP systems this concurrent access can leave (in - out) larger than the ring buffer, so __kfifo_to_user()'s clamp to (in - out) is ineffective and kfifo_copy_to_user() can attempt a copy_to_user() past the kmalloc-2k backing store: usercopy: Kernel memory exposure attempt detected from SLUB object 'kmalloc-2k' (offset 0, size 2049)! kernel BUG at mm/usercopy.c! Call trace: usercopy_abort __check_heap_object __check_object_size kfifo_copy_to_user __kfifo_to_user snoop_file_read vfs_read Serialize kfifo access with a per-channel spinlock shared between the IRQ handler (producer) and the file reader (consumer). Annotate @fifo with __guarded_by(&lock) and opt the driver into context analysis so the compiler enforces that all fifo access holds the lock. Fixes: 3772e5da4454 ("drivers/misc: Aspeed LPC snoop output using misc chardev") Signed-off-by: Karthikeyan KS <karthiproffesional@gmail.com> Signed-off-by: Andrew Jeffery <andrew@codeconstruct.com.au>
12 daysiommu/amd: Fix undefined behavior in devid_write debugfs functionLi RongQing
When for_each_pci_segment() loop completes without finding a matching segment, the pci_seg pointer is not NULL but points to an invalid memory location (the list head). Accessing pci_seg->id after the loop causes undefined behavior. Fix this by handling the successful case inside the loop and returning -EINVAL after the loop if no matching segment is found. Fixes: 2e98940f123d9 ("iommu/amd: Add support for device id user input") Signed-off-by: Li RongQing <lirongqing@baidu.com> Reviewed-by: Ankit Soni <Ankit.Soni@amd.com> Signed-off-by: Will Deacon <will@kernel.org>
12 daysiommu/amd: Fix grammar and typos in commentsxiongweimin
Correct possessive "its", article before acpihid, and a couple of mangled sentences in IOMMU flush/irq comments. Signed-off-by: xiongweimin <xiongweimin@kylinos.cn> Reviewed-by: Ankit Soni <Ankit.Soni@amd.com> Signed-off-by: Will Deacon <will@kernel.org>