summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2026-08-10iommu/vt-d: Remove the 'force_on' variableKevin Tian2-20/+22
The force_on variable is now redundant - same information captured by "dmar_policy == DMAR_FORCE_ON". Replace all force_on checks with dmar_policy_force_on(). Signed-off-by: Kevin Tian <kevin.tian@intel.com> Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com> Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
2026-08-10iommu/vt-d: Call dmar_can_force_on() for tboot opt-inKevin Tian1-4/+8
So the policy of requesting ACS in detect_intel_iommu() is consistent with that in tboot_force_iommu(). Though tboot is the strongest override so far, dmar_can_force_on() may return false due to future extensions. In this case panic the kernel, as is already done when failing to initialize DMA remapping for tboot. No functional impact at this point. Signed-off-by: Kevin Tian <kevin.tian@intel.com> Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com> Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
2026-08-10iommu/vt-d: Use dmar_can_force_on() for platform opt-inKevin Tian1-7/+8
So the policy of requesting ACS in detect_intel_iommu() is consistent with that in platform_optin_force_iommu(). While at it, remove no_platform_optin which is unnecessary now. Signed-off-by: Kevin Tian <kevin.tian@intel.com> Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com> Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
2026-08-10iommu/vt-d: Consolidate dmar policy management and force_on logicKevin Tian3-4/+106
Currently the dmar on/off is carried by multiple variables (no_iommu, dmar_disabled, no_platform_optin, etc.) with error-prone force_on logic scattered in multiple places. Unify/centralize the policy/priority management for various force_on scenarios. No functional impact except one case - "intel_iommu=off" sets no_platform_optin which is checked in platform_optin_force_iommu() but not in detect_intel_iommu(), leading to ACS unnecessarily requested when iommu could not be forced on later. Now with the unified logic this becomes more consistent. Signed-off-by: Kevin Tian <kevin.tian@intel.com> Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com> Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
2026-08-10iommu/vt-d: Remove dead code when CONFIG_INTEL_IOMMU is not setKevin Tian1-15/+0
Those are leftovers and unreachable now: the entire intel directory is built only when CONFIG_INTEL_IOMMU is set. Signed-off-by: Kevin Tian <kevin.tian@intel.com> Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com> Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
2026-08-10iommu/vt-d: Force requesting ACS when tboot is enabledKevin Tian3-3/+16
Currently the conditions of requesting ACS in detect_intel_iommu() don't include tboot, leading to a possible misconfiguration with ACS disabled (e.g. due to user opts) while iommu is later forced on by tboot_force_iommu(). Fix it by checking tboot in detect_intel_iommu(). Fixes: 5d990b627537 ("PCI: add pci_request_acs") Cc: stable@vger.kernel.org Signed-off-by: Kevin Tian <kevin.tian@intel.com> Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com> Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
2026-08-10iommu/vt-d: Fix no_iommu to disable platform opt-inKevin Tian1-3/+3
If user explicitly requests to disable iommu (via "iommu=off" or "intel_iommu=off"), there is no reason to force enabling it due to platform opt-in (for external-facing devices). User should be aware of any security implication of doing so. "intel_iommu=off" implements this policy by setting no_platform_optin to skip platform opt-in in platform_optin_force_iommu(). However, "iommu=off" (no_iommu=1) doesn't set no_platform_optin hence is broken in this aspect: - detect_intel_iommu() doesn't request ACS if no_iommu=1 - platform_optin_force_iommu() forces iommu on if external-facing devices exist and no_platform_optin is not set This leads to a bad configuration with ACS disabled while DMA remapping is enabled. Instead of setting no_platform_optin (will soon be removed) for no_iommu=1, directly check no_iommu in platform_optin_force_iommu(). Fixes: 89a6079df791 ("iommu/vt-d: Force IOMMU on for platform opt in hint") Cc: stable@vger.kernel.org Signed-off-by: Kevin Tian <kevin.tian@intel.com> Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com> Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
2026-08-10iommu/vt-d: Use kstrtoint_from_user() in dmar_perf_latency_write()Dmitry Antipov1-12/+4
Simplify 'dmar_perf_latency_write()' by using the convenient 'kstrtoint_from_user()'. Signed-off-by: Dmitry Antipov <dmantipov@yandex.ru> Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com> Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
2026-08-10iommu/vt-d: Fix CACHE_TAG_NESTING_DEVTLB polluting shared variables in flush ↵Guanghui Feng1-3/+2
loop In cache_tag_flush_range(), the CACHE_TAG_NESTING_DEVTLB case modifies the shared local variables 'addr' and 'mask' before falling through to CACHE_TAG_DEVTLB. This causes all subsequent CACHE_TAG_DEVTLB entries in the same loop iteration to incorrectly use the full-range flush parameters (addr=0, mask=MAX_AGAW_PFN_WIDTH) instead of the precisely calculated PSI range. This is not the intended behavior, as regular DEVTLB entries should always perform targeted range-based invalidation. Fix this by having CACHE_TAG_NESTING_DEVTLB directly call cache_tag_flush_devtlb_psi() with the full-range constants and break, instead of modifying shared variables and falling through. This ensures CACHE_TAG_DEVTLB always uses the original calculated addr and mask for precise range flush. This change slightly affects trace_cache_tag_flush_range() behavior. Previously, after addr/mask were overwritten, the tracepoint could record a full-range flush even when the caller requested a narrower range. The tracepoint should reflect caller intent. Although this helper may widen the actual hardware invalidation range for implementation reasons, that does not change what the caller requested, so logging the requested range is the correct behavior. If the actual invalidation range sent to hardware is needed, it is already visible via the qi_submit trace event, which records the invalidation descriptors emitted by the driver. Signed-off-by: Guanghui Feng <guanghuifeng@linux.alibaba.com> Signed-off-by: Guixin Liu <kanie@linux.alibaba.com> Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com> Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
2026-08-10iommu/vt-d: Use logical OR operator for privilege mode checkLi RongQing1-1/+1
Replace bitwise OR (|) with logical OR (||) in the privilege mode validation check. While both operators produce the same result for boolean values (0 or 1), using logical OR is semantically correct and makes the intent clearer. No functional change, but improves code readability. Signed-off-by: Li RongQing <lirongqing@baidu.com> Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com> Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
2026-08-10iommu/vt-d: Fix UCTP context table slot when copying root entriesDesnes Nunes1-4/+6
When translation is already enabled at boot (e.g. kdump), the vt-d driver copies context tables from the previous kernel's root table. In scalable mode, buses that only populate the upper root half (UCTP, devfn >= 0x80) should be written to ctxt_tbls[tbl_idx + 1] through copy_context_table(). However, the current copy path always uses tbl[tbl_idx + 0] in this situa- tion. Since idx wraps to 0 at devfn 0x80 due to a zeroed LCTP, new_ce for LCTP will be NULL and keep pos equals to 0. Thus, UCTP entries will be co- pied into tbl[tbl_idx + 0] instead of tbl[tbl_idx + 1], and written after- wards to root_entry[bus].lo instead of .hi in copy_translation_tables(). In short, devices on bus 0x80 with devfn >= 0x80 fail DMA with fault 0x39, which will break drivers running in kernels with translation pre-enabled. This fixes NO_PASID DMAR faults for UCTP-only buses such as: DMAR: [DMA Read NO_PASID] Request device [80:14.0] fault addr 0xe81759000 [fault reason 0x39] SM: Present bit in Root Entry is clear For instance, this fault yielded to locking issues between systemd and xHCI, blocking a system's reboot after a vmcore was captured with kdump: systemd-udevd[246]: usb3: Worker [255] processing SEQNUM=2193 is taking a long time dracut-initqueue[277]: Timed out while waiting for udev queue to empty. systemd-udevd[246]: usb3: Worker [255] processing SEQNUM=2193 killed systemd-udevd[246]: usb3: Worker [255] terminated by signal 9 (KILL). ... kdump[569]: saving vmcore complete ... systemd-shutdown[1]: Rebooting. INFO: task kworker/0:1:11 blocked for more than 122 seconds. Not tainted 7.0.0-clean #1 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. task:kworker/0:1 state:D stack:0 pid:11 tgid:11 ppid:2 task_flags:0x4208160 flags:0x00080000 Workqueue: usb_hub_wq hub_event Call Trace: <TASK> __schedule+0x299/0x5c0 schedule+0x27/0x80 schedule_timeout+0xbd/0x100 __wait_for_common+0x97/0x1b0 ? __pfx_schedule_timeout+0x10/0x10 xhci_alloc_dev+0x9e/0x2b0 usb_alloc_dev+0x7a/0x3b0 hub_port_connect+0x285/0x960 hub_port_connect_change+0x94/0x290 port_event+0x4bb/0x840 hub_event+0x141/0x460 process_one_work+0x196/0x390 worker_thread+0x1af/0x320 ? __pfx_worker_thread+0x10/0x10 kthread+0xe3/0x120 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x199/0x260 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 </TASK> INFO: task systemd-shutdow:1 blocked for more than 122 seconds. Not tainted 7.0.0-clean #1 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. task:systemd-shutdow state:D stack:0 pid:1 tgid:1 ppid:0 task_flags:0x400100 flags:0x00080000 Call Trace: <TASK> __schedule+0x299/0x5c0 schedule+0x27/0x80 schedule_preempt_disabled+0x15/0x30 __mutex_lock.constprop.0+0x547/0xac0 device_shutdown+0xac/0x1b0 kernel_restart+0x3a/0x70 __do_sys_reboot+0x147/0x240 do_syscall_64+0x11b/0x6a0 ? handle_mm_fault+0x110/0x350 ? do_user_addr_fault+0x206/0x680 ? irqentry_exit+0x7a/0x4d0 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7fe2958da917 RSP: 002b:00007ffc5c458618 EFLAGS: 00000206 ORIG_RAX: 00000000000000a9 RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007fe2958da917 RDX: 0000000001234567 RSI: 0000000028121969 RDI: 00000000fee1dead RBP: 00007ffc5c458790 R08: 0000000000000069 R09: 00000000ffffffff R10: 0000000000000000 R11: 0000000000000206 R12: 0000000000000000 R13: 0000000000000000 R14: 00007ffc5c4588b8 R15: 0000000000000000 </TASK> INFO: task systemd-shutdow:1 is blocked on a mutex likely owned by task kworker/0:1:11. Fixes: 091d42e43d21 ("iommu/vt-d: Copy translation tables from old kernel") Signed-off-by: Desnes Nunes <desnesn@redhat.com> Tested-by: Tao Liu <ltao@redhat.com> Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com> Reviewed-by: Samiullah Khawaja <skhawaja@google.com> Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
2026-08-10Merge tag 'qcom-drivers-for-7.3-2' of ↵Arnd Bergmann21-102/+635
https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux into soc/drivers More Qualcomm driver updates for v7.3 Add SMEM parsing for DDR configuration data and use its highest bank address bit to select the appropriate UBWC configuration. Enable generic PAS trusted-zone APIs for the Iris and Venus media drivers. Fix SCM probe retry state, reserved-memory cleanup, and an early IRQ-handler NULL dereference. Enable QSEECOM EFI variable access on the Asus Zenbook A16. Correct GENI firmware-size validation using the hardware CFG RAM depth and correct the PMIC GLINK Thunderbolt extradata layout. Document the Nord AOSS side channel and the IMEM minidump SRAM property. Clean up Qualcomm statistics macros and the WCNSS binding schema. * tag 'qcom-drivers-for-7.3-2' of https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux: media: qcom: Switch to generic PAS TZ APIs dt-bindings: soc: qcom,aoss-qmp: Document Nord AOSS side channel dt-bindings: sram: qcom,imem: Add minidump-sram pattern property soc: qcom: qcom_stats: Replace CLIENT_VOTES_OFFSET macro with sizeof() soc: qcom: qcom_stats: Remove unused macro definitions soc: qcom: ubwc: Get HBB from SMEM soc: qcom: smem: Expose DDR data from SMEM soc: qcom: smem: Use 'unsigned int' instead of 'unsigned' firmware: qcom: scm: Fix tzmem state on probe retry firmware: qcom: scm: Fix reserved memory cleanup on probe failure firmware: qcom: scm: Fix NULL dereference in IRQ handler before __scm is published firmware: qcom: scm: Allow QSEECOM on Asus Zenbook A16 (UX3607OA) soc: qcom: geni-se: Use HW PROG_RAM_DEPTH to validate firmware size soc: qcom: pmic_glink_altmode: Define the TBT extradata properly dt-bindings: soc: qcom,wcnss: Drop redundant $ref of firmware-name property Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2026-08-10iommu/dma: Restore locking around msi_page_listAndrew Jones1-0/+13
Unlike a group's default domain, which is always freshly allocated and privately owned (iommu_group_alloc_default_domain()), VFIO type1's legacy container merges any newly attached group into an existing domain whenever their iommu_ops and cache-coherency enforcement match. iommu_dma_get_msi_page() only asserts the caller's own group mutex is held (iommu_group_mutex_assert()). On an IOMMU that publishes IOMMU_RESV_SW_MSI, e.g. ARM SMMU, a VM with two such devices assigned through the legacy container can have their guest drivers probe and allocate MSIs in parallel; each host-side VFIO_DEVICE_SET_IRQS lands on a different device fd and group mutex, but both devices' domains are the same merged domain, so both can enter iommu_dma_get_msi_page() concurrently and corrupt msi_page_list. commit 288683c92b1a ("iommu: Make iommu_dma_prepare_msi() into a generic operation") dropped the prior msi_prepare_lock on the reasoning that "each iommu_domain is unique to a group," which holds for default domains but not this VFIO type1 case. Restore the static lock, since it's only guarding a corner case and will likely never be contended. iommufd avoids the equivalent problem by having its own callers (iommufd_sw_map_msi()) take a ctx-wide sw_msi_lock before ever reaching the shared list. VFIO type1 can't mirror that since it dispatches to iommu_dma_sw_msi() which is outside VFIO's jurisdiction. Fixes: 288683c92b1a ("iommu: Make iommu_dma_prepare_msi() into a generic operation") Signed-off-by: Andrew Jones <andrew.jones@oss.qualcomm.com> Reviewed-by: Jason Gunthorpe <jgg@nvidia.com> Reviewed-by: Nutty Liu <nutty.liu@hotmail.com> Reviewed-by: Robin Murphy <robin.murphy@arm.com> Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
2026-08-10Merge tag 'qcomtee-for-v7.3' of ↵Arnd Bergmann1-1/+6
git://git.kernel.org/pub/scm/linux/kernel/git/jenswi/linux-tee into soc/drivers Drop unused assignment of platform_device_id driver data * tag 'qcomtee-for-v7.3' of git://git.kernel.org/pub/scm/linux/kernel/git/jenswi/linux-tee: tee: qcomtee: Drop unused assignment of platform_device_id driver data Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2026-08-10iommupt: Return zero for invalid iova_to_phys() rangesShuai Xue1-1/+1
DOMAIN_NS(iova_to_phys) returns a phys_addr_t and follows the IOMMU iova_to_phys() convention of returning 0 when there is no valid translation. make_range() returns a negative errno if the input IOVA cannot be represented by this page table format. Returning that errno directly casts it to phys_addr_t. Callers treat zero as no translation and use non-zero values as physical addresses, so this can make them consume a bogus physical address instead of seeing a failed translation. Match the page-table walk failure path and return 0 for range validation failures too. Fixes: 9d4c274cd7d5 ("iommupt: Add iova_to_phys op") Cc: stable@vger.kernel.org Assisted-by: Qoder:Qwen-3.8-MAX-Preview Signed-off-by: Shuai Xue <xueshuai@linux.alibaba.com> Reviewed-by: Lu Baolu <baolu.lu@linux.intel.com> Reviewed-by: Kevin Tian <kevin.tian@intel.com> Reviewed-by: Jason Gunthorpe <jgg@nvidia.com> Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
2026-08-10iommufd: Release current IOAS on xa_store() failureShuai Xue1-0/+2
iommufd_take_all_iova_rwsem() takes an object reference and the iova_rwsem write lock before storing the IOAS in the temporary ioas_list xarray. If xa_store() fails, the current IOAS has not been inserted into ioas_list yet. iommufd_release_all_iova_rwsem() only unwinds IOAS objects already present in that xarray, so it cannot release the current IOAS. Release the current IOAS rwsem and object reference before unwinding the previously stored entries. Fixes: 051ae5aa73d7 ("iommufd: Lock all IOAS objects") Cc: stable@vger.kernel.org Assisted-by: Qoder:Qwen-3.8-MAX-Preview Signed-off-by: Shuai Xue <xueshuai@linux.alibaba.com> Reviewed-by: Kevin Tian <kevin.tian@intel.com> Reviewed-by: Jason Gunthorpe <jgg@nvidia.com> Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
2026-08-10iommufd: Avoid locking internal accesses during unmapShuai Xue1-2/+2
iommufd_access_notify_unmap() skips internal accesses because they do not have an external unmap callback to invoke. However, the current test calls iommufd_lock_obj() before checking whether the access is internal. If iommufd_lock_obj() succeeds, the loop then sees the internal access and continues, bypassing the matching iommufd_put_object() used by the normal unmap path. This leaks the object reference taken by iommufd_lock_obj(). Check for internal accesses first so skipped entries are never locked. Fixes: 27b77ea5feaa ("iommufd/access: Bypass access->ops->unmap for internal use") Cc: stable@vger.kernel.org Assisted-by: Qoder:Qwen-3.8-MAX-Preview Signed-off-by: Shuai Xue <xueshuai@linux.alibaba.com> Reviewed-by: Kevin Tian <kevin.tian@intel.com> Reviewed-by: Jason Gunthorpe <jgg@nvidia.com> Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
2026-08-10iommu/sva: Set handle->dev before the SVA handle is visibleShuai Xue1-1/+1
iommu_attach_device_pasid() installs the new SVA attach handle in the group PASID lookup before iommu_sva_bind_device() returns. A concurrent bind can therefore find and reuse the same handle after iommu_sva_lock is dropped. handle->dev was initialized after dropping iommu_sva_lock. This leaves a window where a racing bind can return a handle whose dev pointer is still NULL. A subsequent iommu_sva_unbind_device() can then dereference it via handle->dev->iommu_group. Initialize handle->dev before releasing iommu_sva_lock so any visible SVA handle is fully initialized. Fixes: be51b1d6bbff ("iommu/sva: Refactoring iommu_sva_bind/unbind_device()") Cc: stable@vger.kernel.org Assisted-by: Qoder:Qwen-3.8-MAX-Preview Signed-off-by: Shuai Xue <xueshuai@linux.alibaba.com> Reviewed-by: Lu Baolu <baolu.lu@linux.intel.com> Reviewed-by: Kevin Tian <kevin.tian@intel.com> Reviewed-by: Jason Gunthorpe <jgg@nvidia.com> Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
2026-08-10Merge tag 'ti-driver-soc-for-v7.3' of ↵Arnd Bergmann4-5/+11
https://git.kernel.org/pub/scm/linux/kernel/git/ti/linux into soc/drivers TI SoC driver updates for v7.3 Minor bug fixes and cleanups across TI SoC and firmware drivers: - firmware: ti_sci: Fix a resource leak by undoing list publication when device populate fails, ensuring proper cleanup on error paths - soc: ti: knav_qmss: Remove debugfs file on teardown to avoid stale entries and potential use-after-free scenarios - soc: ti: wkup_m3_ipc: Remove redundant dev_err() call to avoid duplicate error reporting * tag 'ti-driver-soc-for-v7.3' of https://git.kernel.org/pub/scm/linux/kernel/git/ti/linux: soc: ti: wkup_m3_ipc: Remove redundant dev_err() soc: ti: knav_qmss: Remove debugfs file on teardown firmware: ti_sci: Undo list publication on populate failure Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2026-08-10Merge tag 'ti-k3-config-for-v7.3' of ↵Arnd Bergmann1-0/+5
https://git.kernel.org/pub/scm/linux/kernel/git/ti/linux into soc/defconfig TI K3 defconfig updates for v7.3 Board Specific Features AM62L BeagleBadge: - Enable drivers for components on BeagleBadge board * tag 'ti-k3-config-for-v7.3' of https://git.kernel.org/pub/scm/linux/kernel/git/ti/linux: arm64: defconfig: Enable drivers for BeagleBadge Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2026-08-10Merge tag 'tegra-for-7.2-arm64-dt-fixes-v2' of ↵Arnd Bergmann1-0/+2
git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux into arm/fixes arm64: tegra: Device tree fixes for v7.2 This contains a single fix adding an interrupt to the architected timer's device tree node for the EL2 virtual timer. This prevents a warning from the driver at boot time. * tag 'tegra-for-7.2-arm64-dt-fixes-v2' of git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux: arm64: tegra: Add EL2 virtual timer interrupt for Tegra194 Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2026-08-10rseq: Prevent hard lockup on granted time slice extensionNiels Pressel1-0/+1
__exit_to_user_mode_loop() invokes rseq_grant_timeslice_extension() with interrupts enabled. If the extension is granted it invokes hrtimer_rearm_deferred_tif() to ensure that a pending deferred hrtimer rearm is handled before exiting to user space. Though this invokes __hrtimer_rearm_deferred() which expects to be invoked with interrupts disabled as it takes hrtimer_cpu_base::lock with raw_spin_lock(). That's a livelock waiting to happen and caught by lockdep: WARNING: ./include/linux/hrtimer_rearm.h:17 at irqentry_exit, CPU#1: slice_test WARNING: inconsistent lock state inconsistent {IN-HARDIRQ-W} -> {HARDIRQ-ON-W} usage. Prevent this by disabling interrupts around the invocation of hrtimer_rearm_deferred_tif() in rseq_grant_timeslice_extension(). [ tglx: Massaged change log ] Fixes: 15dd3a948855 ("hrtimer: Push reprogramming timers into the interrupt return path") Signed-off-by: Niels Pressel <npressel@ethz.ch> Signed-off-by: Thomas Gleixner <tglx@kernel.org> Link: https://patch.msgid.link/20260802124423.51616-1-npressel@ethz.ch
2026-08-10Merge patch series "fs: don't warn when a mount is completed from another ↵Christian Brauner5-2/+254
user namespace" Christian Brauner <brauner@kernel.org> says: fsopen() records the caller's user namespace in fc->user_ns and hands back an ordinary file descriptor. The task that calls fsconfig(CMD_CREATE) doesn't have to be the one that created the context, and mount_capable() lets it through as long as the caller has CAP_SYS_ADMIN over fc->user_ns, which anyone in an ancestor namespace does. So fc->user_ns != current_user_ns() is something an unprivileged user can arrange. Both overlayfs and binfmt_misc WARN_ON() that. They're plain WARN_ON()s, so it can be done in a loop to taint the kernel and flood the log, and it panics a machine booted with panic_on_warn. Keep refusing the mount, just stop warning about it. Overlayfs already spells the same check as a plain error return in ovl_parse_param() for Opt_override_creds. And add a selftest for both cases. * patches from https://patch.msgid.link/20260802-work-fill_super-warn-v1-0-4e987911a39a@kernel.org: selftests/filesystems: test completing a context from another user namespace binfmt_misc: don't warn when the mount is completed from another user namespace ovl: don't warn when the mount is completed from another user namespace Link: https://patch.msgid.link/20260802-work-fill_super-warn-v1-0-4e987911a39a@kernel.org Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
2026-08-10selftests/filesystems: test completing a context from another user namespaceChristian Brauner3-0/+250
fsopen() records the caller's user namespace in fc->user_ns and hands back an ordinary file descriptor, so the task that issues FSCONFIG_CMD_CREATE need not be the one that created the context. mount_capable() authorizes that for a caller holding CAP_SYS_ADMIN in an ancestor of fc->user_ns, which any unprivileged user has over a user namespace it just created. binfmt_misc and overlayfs used to WARN_ON() the mismatch. Add a test for both. Also cover the handover within one user namespace. That is a supported thing to do and has to keep working. Link: https://patch.msgid.link/20260802-work-fill_super-warn-v1-3-4e987911a39a@kernel.org Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
2026-08-10binfmt_misc: don't warn when the mount is completed from another user namespaceChristian Brauner1-1/+2
fsopen() records the caller's user namespace in fc->user_ns and hands back an ordinary file descriptor. Nothing ties the task that calls fsconfig(FSCONFIG_CMD_CREATE) to the task that created the context. The fd is inherited across fork() and exec() and it can be passed over a unix socket. Completing a context from another user namespace is allowed on purpose. vfs_cmd_create() authorizes the create with mount_capable(), which for FS_USERNS_MOUNT checks ns_capable(fc->user_ns, CAP_SYS_ADMIN), and that succeeds for a task holding CAP_SYS_ADMIN in an ancestor of fc->user_ns. So an unprivileged task can reach the WARN_ON() in bm_fill_super(): create a user and a mount namespace in a child, call fsopen("binfmt_misc") there, send the fscontext fd to the parent and let the parent issue FSCONFIG_CMD_CREATE. Both namespaces come from a plain unshare(1) and no capability is needed anywhere: WARNING: fs/binfmt_misc.c:938 at bm_fill_super+0xa2/0xc0 [binfmt_misc] CPU: 15 UID: 1000 PID: 3243382 Comm: fswarn Call Trace: get_tree_keyed+0x7d/0xb0 bm_get_tree+0x34/0x90 [binfmt_misc] vfs_get_tree+0x2a/0x100 vfs_cmd_create+0x60/0xf0 __do_sys_fsconfig+0x4b2/0x500 The child needs the mount namespace because fsopen() itself gates on may_mount(), which asks for CAP_SYS_ADMIN in the user namespace owning the caller's mount namespace. fsconfig() doesn't repeat that check. It is a WARN_ON() and not a WARN_ON_ONCE(), so the condition can be raised in a loop to taint the kernel and flood the log, and it panics a kernel booted with panic_on_warn. Keep refusing the mount and stop warning about it. Nothing in bm_fill_super() depends on the two namespaces matching, it derives everything from sb->s_user_ns. Fixes: 21ca59b365c0 ("binfmt_misc: enable sandboxed mounts") Cc: stable@vger.kernel.org # v6.7+ Link: https://patch.msgid.link/20260802-work-fill_super-warn-v1-2-4e987911a39a@kernel.org Reviewed-by: Jan Kara <jack@suse.cz> Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
2026-08-10ovl: don't warn when the mount is completed from another user namespaceChristian Brauner1-1/+2
fsopen() records the caller's user namespace in fc->user_ns and hands back an ordinary file descriptor. Nothing ties the task that calls fsconfig(FSCONFIG_CMD_CREATE) to the task that created the context. The fd is inherited across fork() and exec() and it can be passed over a unix socket. Completing a context from another user namespace is allowed on purpose. vfs_cmd_create() authorizes the create with mount_capable(), which for FS_USERNS_MOUNT checks ns_capable(fc->user_ns, CAP_SYS_ADMIN), and that succeeds for a task holding CAP_SYS_ADMIN in an ancestor of fc->user_ns. So an unprivileged task can reach the WARN_ON() in ovl_fill_super(): create a user and a mount namespace in a child, call fsopen("overlay") there, send the fscontext fd to the parent and let the parent issue FSCONFIG_CMD_CREATE. Both namespaces come from a plain unshare(1) and no capability is needed anywhere: WARNING: fs/overlayfs/super.c:1551 at ovl_fill_super+0x7b9/0x1e20 [overlay] CPU: 3 UID: 1000 PID: 3243376 Comm: fswarn Call Trace: get_tree_nodev+0x71/0xa0 ovl_get_tree+0x15/0x20 [overlay] vfs_get_tree+0x2a/0x100 vfs_cmd_create+0x60/0xf0 __do_sys_fsconfig+0x4b2/0x500 The child needs the mount namespace because fsopen() itself gates on may_mount(), which asks for CAP_SYS_ADMIN in the user namespace owning the caller's mount namespace. fsconfig() doesn't repeat that check. It is a WARN_ON() and not a WARN_ON_ONCE(), so the condition can be raised in a loop to taint the kernel and flood the log, and it panics a kernel booted with panic_on_warn. Keep refusing the mount and stop warning about it. ovl_parse_param() already spells a user namespace check this way for Opt_override_creds. Fixes: 1784fbc2ed9c ("ovl: port to new mount api") Cc: stable@vger.kernel.org # v6.5+ Link: https://patch.msgid.link/20260802-work-fill_super-warn-v1-1-4e987911a39a@kernel.org Reviewed-by: Jan Kara <jack@suse.cz> Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
2026-08-10firmware: xilinx: Clear firmware notifiers across kexec transitionsJay Buddhabhatti2-0/+17
During a kexec restart, only the kernel is reloaded but notifier callbacks in firmware persist, causing state mismatches between kernel and firmware. To address this, introduce PM_ALL_NOTIFIERS node ID to unregister all notifier callbacks during kexec. On a graceful kexec restart, this occurs in zynqmp_firmware_shutdown(). On a crash kernel restart, it happens in zynqmp_firmware_probe() in the reloaded kernel. Unregistering all notifiers depends on firmware support for the PM_ALL_NOTIFIERS node ID. On firmware that does not implement it (the feature check reports a version below PM_API_VERSION_3) the step is skipped and a warning such as "Firmware doesn't support unregister all notifiers at once" is logged, e.g. on Versal NET firmware that predates this API. Signed-off-by: Jay Buddhabhatti <jay.buddhabhatti@amd.com> Reviewed-by: Radhey Shyam Pandey <radhey.shyam.pandey@amd.com> Reviewed-by: Prasanna Kumar T S M <ptsm@linux.microsoft.com> Link: https://patch.msgid.link/20260729122522.3732875-4-jay.buddhabhatti@amd.com Signed-off-by: Michal Simek <michal.simek@amd.com>
2026-08-10firmware: xilinx: Release all peripheral devices from firmwareJay Buddhabhatti2-1/+18
During a kexec restart, only the kernel is reloaded while devices allocated in firmware persist, causing state mismatches between the kernel and firmware. Introduce PM_DEV_ALL_PERIPH node ID (0x18224FFFU) to release all peripheral devices during kexec. On graceful restarts, this happens in zynqmp_firmware_shutdown(). On crash kernel restarts, it happens in zynqmp_firmware_probe() of the reloaded kernel. Releasing all peripherals depends on firmware support for the PM_DEV_ALL_PERIPH node ID. On firmware that does not implement it (the feature check reports a version below PM_API_VERSION_3) the release is skipped and a warning such as "Bulk device release is not supported by firmware" is logged, e.g. on Versal NET firmware that predates this API. Signed-off-by: Jay Buddhabhatti <jay.buddhabhatti@amd.com> Reviewed-by: Radhey Shyam Pandey <radhey.shyam.pandey@amd.com> Reviewed-by: Prasanna Kumar T S M <ptsm@linux.microsoft.com> Link: https://patch.msgid.link/20260729122522.3732875-3-jay.buddhabhatti@amd.com Signed-off-by: Michal Simek <michal.simek@amd.com>
2026-08-10firmware: xilinx: Add support to clear EL3 PM stateJay Buddhabhatti2-2/+51
Currently, during a kexec restart, only the kernel is reloaded, while EL3-specific data remain unchanged. This leads to a mismatch between the kernel state and secure firmware state like SGI number and shutdown scope variable. For example, the kernel registers an SGI number with EL3 firmware so that secure firmware can notify the kernel of events via that SGI. EL3 stores this SGI number in its internal state. After a kexec, the newly loaded kernel re-registers and may request a different SGI number, but the stale value programmed in EL3 remains, so event notifications are delivered on the old SGI and are missed by the new kernel. The shutdown scope variable has a similar stale state problem. To resolve this, the TF_A_CLEAR_PM_STATE PM API is introduced to clear EL3 PM subsystem state during kexec. On a graceful reboot, this API is triggered by zynqmp_firmware_shutdown(), while in a crash kernel scenario, it is invoked by zynqmp_firmware_probe() in the reloaded kernel. Signed-off-by: Jay Buddhabhatti <jay.buddhabhatti@amd.com> Reviewed-by: Radhey Shyam Pandey <radhey.shyam.pandey@amd.com> Reviewed-by: Prasanna Kumar T S M <ptsm@linux.microsoft.com> Link: https://patch.msgid.link/20260729122522.3732875-2-jay.buddhabhatti@amd.com Signed-off-by: Michal Simek <michal.simek@amd.com>
2026-08-10firmware: xilinx: Propagate actual error from feature checkJay Buddhabhatti1-4/+2
When do_fw_call() fails in __do_feature_check_call(), propagate the actual errno from zynqmp_pm_ret_code() instead of always returning -EOPNOTSUPP. This gives callers more precise error information. Existing callers only test ret < 0 and are unchanged by this. Signed-off-by: Jay Buddhabhatti <jay.buddhabhatti@amd.com> Reviewed-by: Radhey Shyam Pandey <radhey.shyam.pandey@amd.com> Reviewed-by: Prasanna Kumar T S M <ptsm@linux.microsoft.com> Link: https://patch.msgid.link/20260724095352.2890326-3-jay.buddhabhatti@amd.com Signed-off-by: Michal Simek <michal.simek@amd.com>
2026-08-10firmware: xilinx: Use TF-A feature check for TF-A-specific APIsJay Buddhabhatti1-10/+15
Currently, TF-A-specific APIs are validated using the firmware PM_FEATURE_CHECK API, even though TF-A provides a dedicated mechanism via PM_API_FEATURES API. Update the feature check logic for TF-A-specific API calls to use PM_API_FEATURES. If this check fails, fall back to the legacy PM_FEATURE_CHECK to support backward compatibility. Signed-off-by: Jay Buddhabhatti <jay.buddhabhatti@amd.com> Reviewed-by: Radhey Shyam Pandey <radhey.shyam.pandey@amd.com> Reviewed-by: Prasanna Kumar T S M <ptsm@linux.microsoft.com> Link: https://patch.msgid.link/20260724095352.2890326-2-jay.buddhabhatti@amd.com Signed-off-by: Michal Simek <michal.simek@amd.com>
2026-08-10Merge tag 'apple-soc-fixes-7.2' of ↵Arnd Bergmann1-15/+15
https://git.kernel.org/pub/scm/linux/kernel/git/sven/linux into arm/fixes Apple SoC fixes for 7.2 Just a single commit that fixes the i2c IRQ and MMIO ranges for the M3 SoC. Signed-off-by: Sven Peter <sven@kernel.org> * tag 'apple-soc-fixes-7.2' of https://git.kernel.org/pub/scm/linux/kernel/git/sven/linux: arm64: dts: apple: t8122: Fix I2C resources Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2026-08-10Merge tag 'optee-fix-for-v7.2' of ↵Arnd Bergmann1-0/+3
git://git.kernel.org/pub/scm/linux/kernel/git/jenswi/linux-tee into arm/fixes Add NULL check in optee_ffa_lend_protmem() * tag 'optee-fix-for-v7.2' of git://git.kernel.org/pub/scm/linux/kernel/git/jenswi/linux-tee: optee: ffa: Add NULL check in optee_ffa_lend_protmem Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2026-08-10xfs: validate attr entry pointer before field accessHongling Zeng1-0/+14
xfs_attr3_leaf_verify_entry() accesses lentry/rentry fields (namelen, valuelen) before checking if the entry pointer itself is within bounds. If nameidx is crafted to point near the end of the buffer, these field accesses can read out-of-bounds before the bounds check at name_end > buf_end is performed. Add explicit bounds checks for entry pointers before accessing their fields. Use offsetof() to check that the start of the flexible array member (nameval/name) is within bounds, which ensures all preceding fields are safe to access. Fixes: c84760659dcf2 ("xfs: check attribute leaf block structure") Cc: <stable@vger.kernel.org> # v5.5 Signed-off-by: Hongling Zeng <zenghongling@kylinos.cn> Reviewed-by: Darrick J. Wong <djwong@kernel.org> Signed-off-by: Carlos Maiolino <cem@kernel.org>
2026-08-10xfs: check split_sectors validity before bio_split callHongling Zeng1-1/+1
Change the split_sectors check from !split_sectors to split_sectors <= 0 to make the error handling explicit. While bio_split_rw_at() cannot return a negative error code for the current GC I/O path (GC I/O doesn't use REQ_ATOMIC/REQ_NOWAIT flags and has proper alignment), making the check explicit improves code clarity and makes the intent clear. This also makes the code more robust for future maintenance if different I/O patterns are introduced. Signed-off-by: Hongling Zeng <zenghongling@kylinos.cn> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Carlos Maiolino <cem@kernel.org>
2026-08-10xfs: use file target for post-log fsync fallback flushHongling Zeng1-10/+16
xfs_file_fsync() has a fallback flush for the case where the log force was a no-op, for example fdatasync/O_DSYNC writes that do not require metadata updates. The current fallback path is expressed in terms of the main data device and explicitly excludes realtime inodes. Realtime files with a separate realtime device are flushed before the log force, because their data must reach stable storage before the log commit. For the internal realtime device used by the zoned allocator, writes are out-of-place and update inode and bmap metadata from I/O completion, so the overwrite-without-metadata-update case does not apply in the same way. Even so, the current fallback condition is inconsistent because it is expressed as "non-realtime inode on the main data device" rather than in terms of the inode's actual file data target. Use xfs_inode_buftarg() to obtain the target that stores this file's data, and issue the fallback flush when the log force did not flush anything and the log target is the same as that file target. This preserves existing behavior for regular files while making the fallback logic consistent for files whose data target is selected by the inode. Fixes: bdc03eb5f98f ("xfs: allow internal RT devices for zoned mode") Signed-off-by: Hongling Zeng <zenghongling@kylinos.cn> Suggested-by: Christoph Hellwig <hch@infradead.org> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Carlos Maiolino <cem@kernel.org>
2026-08-10xfs: restore nofs context unconditionally in xfs_trans_rollYun Zhou1-7/+9
When __xfs_trans_commit() fails in xfs_trans_roll(), the NOFS context is cleared but only restored in the success path. This leaves the error path without nofs protection, causing a circular lock dependency between xfs_nondir_ilock_class and fs_reclaim: CPU0 CPU1 ---- ---- lock(&xfs_nondir_ilock_class); lock(fs_reclaim); lock(&xfs_nondir_ilock_class); lock(fs_reclaim); Fix this by moving xfs_trans_set_context() before the error check so that nofs context is always restored on the new transaction. Reported-by: syzbot+59178abfeb0ea3f0ab20@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=59178abfeb0ea3f0ab20 Fixes: a1ca658d649a ("xfs: fix incorrect context handling in xfs_trans_roll") Cc: stable@vger.kernel.org Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Yun Zhou <yun.zhou@windriver.com> Reviewed-by: Darrick J. Wong <djwong@kernel.org> Signed-off-by: Carlos Maiolino <cem@kernel.org>
2026-08-10xfs: add lockless xfs_buf_readahead_map fast pathChristoph Hellwig1-3/+13
Readahead currently always locks the buffer, which can cause contention with actual users of the buffer. Add a fast path without taking any locks if the buffer is uptodate and not stale. Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Darrick J. Wong <djwong@kernel.org> Signed-off-by: Carlos Maiolino <cem@kernel.org>
2026-08-10xfs: move buffer locking out of xfs_find_get_bufChristoph Hellwig1-11/+22
To prepare for buffer loookups that don't lock the buffer, move the call to xfs_buf_find_lock from xfs_find_get_buf to its callers. Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Darrick J. Wong <djwong@kernel.org> Signed-off-by: Carlos Maiolino <cem@kernel.org>
2026-08-10xfs: merge xfs_buf_reverify into xfs_buf_read_mapChristoph Hellwig1-43/+36
xfs_buf_read_map is the only caller of xfs_buf_reverify that is left. Merge it into that so that the comments can be moved closer to the logic, and redundant asserts can be removed. Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Darrick J. Wong <djwong@kernel.org> Signed-off-by: Carlos Maiolino <cem@kernel.org>
2026-08-10xfs: use goto based error unwinding in xfs_buf_read_mapChristoph Hellwig1-23/+24
This keeps the I/O error handling contained at the end of the function and removes the indentation for it. It also allows to reorder the comments so that they are closer to the logic that they describe. Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Darrick J. Wong <djwong@kernel.org> Signed-off-by: Carlos Maiolino <cem@kernel.org>
2026-08-10xfs: don't reverify buffers in xfs_buf_readahead_mapChristoph Hellwig1-1/+0
xfs_buf_read_map calls xfs_buf_reverify to ensure the verifier has run for a buffer before the data can be used when an earlier readahead read the data before the buf_ops were assigned. There is no point in doing this in xfs_buf_readahead_map for a buffer already in memory as a later xfs_buf_read will do the same and can actually propagate the error to the caller. Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Darrick J. Wong <djwong@kernel.org> Signed-off-by: Carlos Maiolino <cem@kernel.org>
2026-08-10xfs: use WRITE_ONCE to update b_flagsChristoph Hellwig1-35/+51
Prepare for limited lockless reading of flags by using WRITE_ONCE to prevent the compiler from doing non-standard read-modify-write operations. Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Darrick J. Wong <djwong@kernel.org> Signed-off-by: Carlos Maiolino <cem@kernel.org>
2026-08-10xfs: hide b_flags manipulation from code outside of xfs_buf.cChristoph Hellwig7-13/+29
Add helpers for the remaining buffer flags manipulation not done in the core buffer cache code. Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Darrick J. Wong <djwong@kernel.org> Signed-off-by: Carlos Maiolino <cem@kernel.org>
2026-08-10xfs: remove _XBF_LOGRECOVERYChristoph Hellwig7-19/+10
Adding _XBF_LOGRECOVERY to every buffer write from log recovery is error prone. Instead key off the behavior on log recovery being active with indirecting that through a flag. Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Darrick J. Wong <djwong@kernel.org> Signed-off-by: Carlos Maiolino <cem@kernel.org>
2026-08-10xfs: remove spurious XBF_DONE clearing on readahead validation failureChristoph Hellwig2-12/+11
Both callers of ->verify_read already do this, so don't duplicate the flag manipulation. Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Darrick J. Wong <djwong@kernel.org> Signed-off-by: Carlos Maiolino <cem@kernel.org>
2026-08-10xfs: split out a lower-level xfs_buf_get_map helper from xfs_find_get_bufChristoph Hellwig1-12/+29
xfs_buf_get_map is currently reused to implement xfs_buf_read_map and xfs_buf_readahead_map. This causes double accounting of buf_get stat and leads to some ugly overload of the flags. Split out a slightly lower-level xfs_find_get_buf helper and use that to implement xfs_buf_get_map, xfs_buf_read_map and xfs_buf_readahead_map. Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Darrick J. Wong <djwong@kernel.org> Signed-off-by: Carlos Maiolino <cem@kernel.org>
2026-08-10xfs: consolidate buffer locking in xfs_buf_get_mapChristoph Hellwig2-41/+23
Consolidate the code to lock the buffer based on the passed in flags into xfs_buf_get_map instead of having two different sites for buffer lookup vs insertation. This requires initializing b_lock to unlocked on allocation and doing an atomic for locking it for newly allocated buffers, but greatly simplifies the logic. Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Brian Foster <bfoster@redhat.com> Signed-off-by: Carlos Maiolino <cem@kernel.org>
2026-08-10xfs: don't get a pag reference in xfs_buf_get_mapChristoph Hellwig1-34/+10
As of commit 497560b9ef42 ("xfs: switch (back) to a per-buftarg buffer hash"), buffer lookups don't require the perag structure. Stop looking it up in xfs_buf_get_map, and instead only find it when allocating a new buffer. Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Darrick J. Wong <djwong@kernel.org> Signed-off-by: Carlos Maiolino <cem@kernel.org>
2026-08-10fbdev: clps711x-fb: Remove unreachable unregister_framebuffer() callKarl Mehltretter1-2/+0
The unregister_framebuffer() call in clps711x_fb_probe() is unreachable. register_framebuffer() failure jumps to the unwind label, while success returns immediately. Remove it. Found with Clang's -Wunreachable-code. Fixes: 36462ac193088 ("fbdev: clps711x-fb: Replace check_fb in favor of struct fb_info.lcd_dev") Assisted-by: Claude:claude-fable-5 Signed-off-by: Karl Mehltretter <kmehltretter@gmail.com> Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Helge Deller <deller@gmx.de>
generated by cgit (git 2.54.0.dirty) at 2026-09-29 13:43:00 +0000