summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2026-07-07timekeeping: Move the vDSO update declarations into a private headerThomas Weißschuh
All architectures are now fully using the generic vDSO infrastructure. They don't need these declarations anymore to implement the functions in architecture-specific code. Move them to the private header. Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de> Signed-off-by: Thomas Gleixner <tglx@kernel.org> Link: https://patch.msgid.link/20260707-timekeeping-header-cleanup-v1-2-e85ad96409a9@linutronix.de
2026-07-07timekeeping: Fold vdso_time_update_aux() declarations into the generic ifdefferyThomas Weißschuh
The only caller of vdso_time_update_aux() is already gated behind CONFIG_POSIX_AUX. The additional check in the header files is not necessary. Remove it and then fold the declarations into the existing CONFIG_GENERIC_GETTIMEOFDAY ifdeffery. Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de> Signed-off-by: Thomas Gleixner <tglx@kernel.org> Link: https://patch.msgid.link/20260707-timekeeping-header-cleanup-v1-1-e85ad96409a9@linutronix.de
2026-07-07hrtimer: Remove inclusion of hrtimer_bases.h remove from hrtimer.hThomas Weißschuh (Schneider Electric)
hrtimer.h is used all over the kernel. Any change to hrtimer_bases.h effectively triggers a full rebuild. As all logical dependencies from hrtimer.h to hrtimer_bases.h have been removed, the inclusion is now unncessary. Remove it. Signed-off-by: Thomas Weißschuh (Schneider Electric) <thomas.weissschuh@linutronix.de> Signed-off-by: Thomas Gleixner <tglx@kernel.org> Link: https://patch.msgid.link/20260702-hrtimer-header-dependencies-v1-8-c50b19bda473@linutronix.de
2026-07-07x86/speculation: Explicitly include linux/types.hThomas Weißschuh (Schneider Electric)
The usage of 'bool' requires linux/types.h, which is currently only included through a transitive dependency chain. Include linux/types.h as that chain is going to go away. Signed-off-by: Thomas Weißschuh (Schneider Electric) <thomas.weissschuh@linutronix.de> Signed-off-by: Thomas Gleixner <tglx@kernel.org> Link: https://patch.msgid.link/20260702-hrtimer-header-dependencies-v1-7-c50b19bda473@linutronix.de
2026-07-07hrtimer: Explicitly include some necessary headers in hrtimer_rearm.hThomas Weißschuh (Schneider Electric)
Multiple used types and symbols are only visible through transitive dependency chains. Include the headers explicitly as those chains are going to go away. Signed-off-by: Thomas Weißschuh (Schneider Electric) <thomas.weissschuh@linutronix.de> Signed-off-by: Thomas Gleixner <tglx@kernel.org> Link: https://patch.msgid.link/20260702-hrtimer-header-dependencies-v1-6-c50b19bda473@linutronix.de
2026-07-07hrtimer: Explicitly include linux/hrtimer_bases.hThomas Weißschuh (Schneider Electric)
This header uses some definitions from linux/hrtimer_bases.h. Currently this header is included transitively, which will change. Include the header explicitly. Signed-off-by: Thomas Weißschuh (Schneider Electric) <thomas.weissschuh@linutronix.de> Signed-off-by: Thomas Gleixner <tglx@kernel.org> Link: https://patch.msgid.link/20260702-hrtimer-header-dependencies-v1-5-c50b19bda473@linutronix.de
2026-07-07tick: Explicitly include linux/hrtimer_bases.hThomas Weißschuh (Schneider Electric)
This header uses some definitions from linux/hrtimer_bases.h. Currently this header is included transitively, which will change. Include the header explicitly. Signed-off-by: Thomas Weißschuh (Schneider Electric) <thomas.weissschuh@linutronix.de> Signed-off-by: Thomas Gleixner <tglx@kernel.org> Link: https://patch.msgid.link/20260702-hrtimer-header-dependencies-v1-4-c50b19bda473@linutronix.de
2026-07-07hrtimer: Move hrtimer_update_function() to hrtimer.cThomas Weißschuh (Schneider Electric)
The usage of the hrtimer base forces hrtimer.h to also expose the base structure definitions. Move the function to hrtimer.c to avoid this. Signed-off-by: Thomas Weißschuh (Schneider Electric) <thomas.weissschuh@linutronix.de> Signed-off-by: Thomas Gleixner <tglx@kernel.org> Link: https://patch.msgid.link/20260702-hrtimer-header-dependencies-v1-3-c50b19bda473@linutronix.de
2026-07-07hrtimer: Move hrtimer_callback_running() to hrtimer_bases.hThomas Weißschuh (Schneider Electric)
The usage of the hrtimer base introduces a dependency on the timer base structure definitions from the widely-used hrtimer.h. Move the helper to hrtimer_bases.h to trim this dependency. Also adapt the two only callers to now include hrtimer_bases.h. Signed-off-by: Thomas Weißschuh (Schneider Electric) <thomas.weissschuh@linutronix.de> Signed-off-by: Thomas Gleixner <tglx@kernel.org> Link: https://patch.msgid.link/20260702-hrtimer-header-dependencies-v1-2-c50b19bda473@linutronix.de
2026-07-07hrtimer: Rename hrtimer_defs.h to hrtimer_bases.hThomas Weißschuh (Schneider Electric)
This header was originally added for #defines and was later extended with the hrtimer base structures. All the #defines have been removed in the meantime, so the naming is off now. Rename the header to fit its contents more. This will also make the upcoming addition of some functions nicer. Signed-off-by: Thomas Weißschuh (Schneider Electric) <thomas.weissschuh@linutronix.de> Signed-off-by: Thomas Gleixner <tglx@kernel.org> Link: https://patch.msgid.link/20260702-hrtimer-header-dependencies-v1-1-c50b19bda473@linutronix.de
2026-07-07hrtimer: Don't take cpu_base::lock in hrtimer_get_next_event() when hres_activeUsama Arif
hrtimer_get_next_event() runs on every tick-stop decision via get_next_timer_interrupt() -> cmp_next_hrtimer_event(). When high resolution timers are active it must return KTIME_MAX -- the caller documents and depends on this. The function takes cpu_base->lock, checks hres_active, and returns KTIME_MAX. Taking the lock is not required because cpu_base->hres_active is only written by the local CPU in hrtimer_switch_to_hres() from hard interrupt context and in hrtimers_cpu_starting() during bring-up. All callers of hrtimer_get_next_event() reach it from the tick-stop / cpuidle paths with interrupts disabled on that CPU. No writer can therefore race with the read, so an unlocked hres_active check is stable and the lock can be skipped in this case. On a 176-thread AMD EPYC 9D64 running a production workload, bucketing callers of native_queued_spin_lock_slowpath(), the slowpath had 199 samples in total, of which 54 are attributed to hrtimer_get_next_event(), i.e. this accounts for ~27% of slowpath hits on this specific workload. Move the hres_active check before the lock guard region to address this. [ tglx: Massaged change log and comments ] Signed-off-by: Usama Arif <usama.arif@linux.dev> Signed-off-by: Thomas Gleixner <tglx@kernel.org> Link: https://patch.msgid.link/20260707153800.542394-1-usama.arif@linux.dev
2026-07-07timer_list: Annotate print_cpu() diagnostic readsYu Peng
print_cpu() prints hrtimer_cpu_base and tick_sched state without synchronizing with concurrent updates. The output is diagnostic only, so use data_race(READ_ONCE()) for these scalar reads to document the intentional races and avoid KCSAN reports. Reported-by: syzbot+8f0e958900a14d08a51d@syzkaller.appspotmail.com Signed-off-by: Yu Peng <pengyu@kylinos.cn> Signed-off-by: Thomas Gleixner <tglx@kernel.org> Link: https://patch.msgid.link/20260707125813.2182532-1-pengyu@kylinos.cn Closes: https://syzkaller.appspot.com/bug?extid=8f0e958900a14d08a51d
2026-07-07time/namespace: Validate nanosecond field in proc_timens_set_offset()Malaya Kumar Rout
The function validates tv_sec to be within [-KTIME_SEC_MAX, KTIME_SEC_MAX] but never validates that tv_nsec is within the valid range of [0, NSEC_PER_SEC-1] before using it in timespec64_add(). timespec64_add() expects both timespec64 structures to have normalized values with tv_nsec in the range [0, 999999999]. If off->val.tv_nsec contains invalid values (negative or >= NSEC_PER_SEC), it could lead to incorrect calculations or unexpected behavior. Add validation to ensure tv_nsec is within the valid range before performing the addition. Fixes: 04a8682a71be ("fs/proc: Introduce /proc/pid/timens_offsets") Signed-off-by: Malaya Kumar Rout <malayarout91@gmail.com> Signed-off-by: Thomas Gleixner <tglx@kernel.org> Link: https://patch.msgid.link/20260704093429.89350-1-malayarout91@gmail.com
2026-07-07timers/migration: Fix memory leak in tmigr_setup_groups() error pathMalaya Kumar Rout
When the WARN_ON_ONCE(i >= tmigr_hierarchy_levels) assertion triggers, the function returns -EINVAL without freeing the 'stack' memory allocated via kzalloc_objs() at the beginning of the function. Add kfree(stack) before returning to prevent the memory leak. Fixes: 6c181b5667ee ("timers/migration: Convert "while" loops to use "for"") Signed-off-by: Malaya Kumar Rout <malayarout91@gmail.com> Signed-off-by: Thomas Gleixner <tglx@kernel.org> Link: https://patch.msgid.link/20260704085533.87098-1-malayarout91@gmail.com
2026-07-07timekeeping: Unwind aux clock sysfs children on failureYuho Choi
tk_aux_sysfs_init() creates one child kobject per auxiliary clock. If a later child or sysfs group creation fails, the current error path only puts the parent kobjects and leaves earlier children and groups behind. Store the child kobjects during init and remove the successfully created groups and kobjects on failure. Fixes: 7b5ab04f035f ("timekeeping: Fix resource leak in tk_aux_sysfs_init() error paths") Signed-off-by: Yuho Choi <dbgh9129@gmail.com> Signed-off-by: Thomas Gleixner <tglx@kernel.org> Link: https://patch.msgid.link/20260703165337.168445-1-dbgh9129@gmail.com
2026-07-07clocksource: Unregister subsystem on device registration failureYuho Choi
init_clocksource_sysfs() registers the clocksource subsystem before registering the clocksource device. If device_register() fails, the function returns the error while leaving the subsystem registered. Unregister the clocksource subsystem on that failure path so the successful subsystem registration is unwound before returning. Fixes: d369a5d8fc70 ("clocksource: convert sysdev_class to a regular subsystem") Signed-off-by: Yuho Choi <dbgh9129@gmail.com> Signed-off-by: Thomas Gleixner <tglx@kernel.org> Link: https://patch.msgid.link/20260702215733.84588-1-dbgh9129@gmail.com
2026-07-07selftests: timers: leap-a-day: Fix -w option and update usage commentJiangshan Yi
Commit 98b74e1f3104 ("kselftests: timers: leap-a-day: Change default arguments to help test runs") replaced the -s option with -w and made "wait for the leap second" the non-default behaviour, but it only updated the switch/case handling. Two things were left inconsistent: - The getopt() option string still lists 's' instead of 'w', so passing -w is rejected as an invalid option and the new behaviour cannot be selected at all. - The file header comment still documents the removed -s option and an outdated default for -i. Fix the getopt() string to accept 'w' (matching the existing case 'w': handler) and update the header comment to describe -w, -t and the current -i default. Fixes: 98b74e1f3104 ("kselftests: timers: leap-a-day: Change default arguments to help test runs") Signed-off-by: Jiangshan Yi <yijiangshan@kylinos.cn> Signed-off-by: Thomas Gleixner <tglx@kernel.org> Acked-by: John Stultz <jstultz@google.com> Link: https://patch.msgid.link/20260702093915.2652638-1-yijiangshan@kylinos.cn
2026-07-07drm/v3d: Use write_to_buffer() helper in performance query copyMaíra Canal
The copy of performance query results to the output buffer open-codes the 32-bit/64-bit selection with two nearly identical loops. As the write_to_buffer() helper already encapsulates the do_64bit decision, use it instead of open-coding it. Reviewed-by: Iago Toral Quiroga <itoral@igalia.com> Link: https://patch.msgid.link/20260703-v3d-cpu-job-fixes-v3-3-bc51b1f3eeb5@igalia.com Signed-off-by: Maíra Canal <mcanal@igalia.com>
2026-07-07irqchip/gic-v3-its: Fix its node leak in gic_acpi_parse_madt_its()Kemeng Shi
Fix its node leak when its_probe_one() failed in gic_acpi_parse_madt_its(). Fixes: 9585a495ac936 ("irqchip/gic-v3-its: Split allocation from initialisation of its_node") Signed-off-by: Kemeng Shi <shikemeng@huaweicloud.com> Signed-off-by: Thomas Gleixner <tglx@kernel.org> Reviewed-by: Radu Rendec <radu@rendec.net> Link: https://patch.msgid.link/20260702033050.1583-3-shikemeng@huaweicloud.com
2026-07-07irqchip/gic-v3-its: Fix memleak in its_probe_one()Kemeng Shi
Fix collection leak when its_init_domain() failed in its_probe_one(). Fixes: 4c21f3c26ecc2 ("irqchip: GICv3: ITS: DT probing and initialization") Signed-off-by: Kemeng Shi <shikemeng@huaweicloud.com> Signed-off-by: Thomas Gleixner <tglx@kernel.org> Reviewed-by: Radu Rendec <radu@rendec.net> Link: https://patch.msgid.link/20260702033050.1583-2-shikemeng@huaweicloud.com
2026-07-07Merge tag 'irq-chip-qcom-pdc-for-gpio-07-07-26' into irq/driversThomas Gleixner
Pull the changes in which were provided for the GPIO tree.
2026-07-07irqchip/qcom-pdc: Configure PDC to pass through modeMaulik Shah
All PDC hardware versions support pass-through mode in which both Direct SPIs and GPIO interrupts (as SPIs) are sent to the GIC without latching at the PDC level. Newer PDCs (v3.0 onwards) also support an additional secondary controller mode where PDC latches the GPIO interrupts and sends them to the GIC as level type interrupts. Direct SPIs works the same as pass-through mode without latching at PDC even in secondary controller mode. All the SoCs use pass-through mode with the exception of x1e. The x1e PDC may be set to secondary controller mode for builds on CRD boards whereas it may be set to pass through mode for IoT-EVK boards. The mode configuration is done in firmware and initially shipped windows firmware did not have a SCM interface to read or modify the PDC mode. Only later write access was opened up for the non-secure world. The availability of write access can be probed. Therefore try to modify the to modify the PDC mode to pass-through mode via SCM write. When the write fails on older firmware assume it to work in secondary mode. In secondary mode set the separate irqchip for the GPIOs to perform additional operations only for the GPIO interrupts. [ tglx: Massage change log ] Co-developed-by: Sneh Mankad <sneh.mankad@oss.qualcomm.com> Signed-off-by: Sneh Mankad <sneh.mankad@oss.qualcomm.com> Signed-off-by: Maulik Shah <maulik.shah@oss.qualcomm.com> Signed-off-by: Thomas Gleixner <tglx@kernel.org> Link: https://patch.msgid.link/20260707-hamoa_pdc_v3-v4-4-dfd1f4a3ae89@oss.qualcomm.com
2026-07-07irqchip/qcom-pdc: Differentiate between direct SPI and GPIO as SPIMaulik Shah
Before commit 4dc70713dc24 ("irqchip/qcom-pdc: Kill non-wakeup irqdomain") there were separate domains for direct SPIs and GPIOs used as SPIs. Separate domains can be useful to have separate interrupt chips for different functionalities. Since the commit unified both domains there is no way to differentiate. In preparation to add the second level interrupt controller support where GPIO interrupts get latched at PDC (but not direct SPIs) there is a need to differentiate between SPIs and GPIOs as SPIs. Reverting above commit does is not a good option as it leads to waste of resources. PDC hardware provides the IRQ_PARAM register to enumerate the number of direct SPIs and the number of GPIOs as SPIs. Further PDC allocates direct SPIs at the beginning and all GPIOs as SPIs are allocated at the end. This information can be used in the driver to differentiate them. Add the support to read this register and keep this information in struct pdc_desc. Later change utilizes it. [ tglx: Massage change log ] Signed-off-by: Maulik Shah <maulik.shah@oss.qualcomm.com> Signed-off-by: Thomas Gleixner <tglx@kernel.org> Link: https://patch.msgid.link/20260707-hamoa_pdc_v3-v4-3-dfd1f4a3ae89@oss.qualcomm.com
2026-07-07irqchip/qcom-pdc: Move all static variables to struct pdc_descMaulik Shah
There are multiple static variables used in the driver. Move all to struct pdc_desc to better align with versioning support. Document them. Add a new pdc->enable_intr() callback to point to the respective versions specific enable function. Remove pdc_enable_intr() and __pdc_enable_intr() and invoke pdc->enable_intr() from the call sites. Locking in pdc_enable_intr() applies lock to all version specific pdc->enable_intr() however lock is needed only for pdc_enable_intr_bank() which uses a shared bank across on PDC v2.7 and PDC v3.0. pdc_enable_intr_cfg() do not require locking as IRQ_CFG registers are one per interrupt. Move the locking to pdc_enable_intr_bank(). No functional impact intended [ tglx: Massage change log. ] Signed-off-by: Maulik Shah <maulik.shah@oss.qualcomm.com> Signed-off-by: Thomas Gleixner <tglx@kernel.org> Link: https://patch.msgid.link/20260707-hamoa_pdc_v3-v4-2-dfd1f4a3ae89@oss.qualcomm.com
2026-07-07irqchip/qcom-pdc: Restructure version supportMaulik Shah
The PDC irqchip driver updates IRQ_ENABLE and IRQ_CFG for three different versions v2.7, v3.0 and v3.2. These registers are organized in hardware as below on various SoCs: +---------------------------------------------------------------+ | SM8350, SM8450 | SM8550, Hamoa | SM8650, SM8750 | |---------------------------------------------------------------| | v2.7 | v3.0 | v3.2 | |---------------------------------------------------------------| | IRQ_ENABLE_BANK | IRQ_ENABLE_BANK | NA | |---------------------------------------------------------------| | IRQ_CFG | IRQ_CFG | IRQ_CFG | | | | | | | | [31:6] Unused | | | [31:5] Unused | [5] GPIO_STATUS | | | [4] GPIO_STATUS| [4] GPIO_MASK | | [31:3] Unused | [3] GPIO_MASK | [3] IRQ_ENABLE | | [0:2] Type | [0:2] Type | [0:2] Type | +---------------------------------------------------------------| All SoCs PDC chips support "pass through mode" in which all interrupts are forwarded to the GIC without any latching in the PDC hardware. So far the driver did not utilize GPIO_STATUS and GPIO_MASK from IRQ_CFG register for v3.0 and v3.2 since they are only needed to be configured when PDC runs in a specific mode named "second level interrupt controller". In that mode it can latch the GPIO interrupts in GPIO_STATUS and forward GPIO interrupts to GIC as LEVEL_HIGH type SPI interrupt. All the SoCs defaulted to pass through mode with the exception of some x1e types. x1e PDC may be set to secondary controller mode for builds on CRD boards whereas it may be set to pass through mode for IoT-EVK boards. Restructure in preparation to add the second level interrupt controller mode utilizing GPIO_STATUS and GPIO_MASK bits which changed the bit positions between v3.0 and v3.2. No functional change intended. [ tglx: Massaged change log ] Signed-off-by: Maulik Shah <maulik.shah@oss.qualcomm.com> Signed-off-by: Thomas Gleixner <tglx@kernel.org> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Link: https://patch.msgid.link/20260707-hamoa_pdc_v3-v4-1-dfd1f4a3ae89@oss.qualcomm.com
2026-07-07drm/v3d: Serialize jobs across queues when a perfmon is attachedMaíra Canal
A non-global perfmon is meant to count events generated by a specific submission, but the scheduler can run jobs from different queues concurrently on the same V3D core. Without explicit serialization, an unrelated job running in parallel with a perfmon-carrying job pollutes the counters and generates unusable results. To address such issue, we must enforce cross-queue serialization when we detect a perfmon-carrying submission. It's possible to implement serialization by enforcing two rules: 1. A job that carries a non-global perfmon must wait for every job currently in-flight across all HW queues to finish. 2. While a perfmon-carrying job is still in-flight, all subsequently submitted jobs must wait for it. Note that serialization is not needed in the global perfmon case, as the global perfmon tracks activity from all jobs, so concurrency is desirable. Therefore, check if serialization is needed during job submission and if so, attach fence dependences to enforce cross-queue serialization. Reviewed-by: Iago Toral Quiroga <itoral@igalia.com> Link: https://patch.msgid.link/20260706-v3d-perfmon-lifetime-v4-2-d7b312ff2c83@igalia.com Signed-off-by: Maíra Canal <mcanal@igalia.com>
2026-07-07drm/v3d: Refactor perfmon lockingMaíra Canal
v3d exposes a single set of performance counters per core, so at any moment at most one performance monitor can be programmed in HW. In software, this singleton is represented by v3d_dev->active_perfmon, but until now nothing actually serialized access to it: scheduler callbacks, the GPU-reset path, and perfmon ioctls all read and wrote that field lock-free. The existence of v3d_perfmon->lock mutex did not close the gap. It serialized start/stop of *one* perfmon object against itself, but the invariant that needs protection is device-wide: there can be exactly one active perfmon at any moment in HW. Two threads acting on different perfmon objects could race through v3d_dev->active_perfmon and the counter registers, leaving software and HW out of sync. This commit moves the locking to where the invariant actually lives. Group the active perfmon pointer with a device-wide spinlock and route every state transition (job start, job completion, set global, reset, suspend/resume, destruction) through a small set of locked entry points that are the only mutators of the HW counters. Some design improvements needed to be made for the refactor: 1. Stop the perfmon from the IRQ handler at job-completion time (the natural boundary for "active perfmon follows the active job"). This required a change from a mutex to a spinlock. This solves another issue of the existing design: perfmon start/stop was exclusively attached to run_job() callbacks, which means that if nothing was further queued up, a perfmon would never actually be stopped. 2. Pause/resume the HW counters across runtime-PM transitions without dropping the software reference. This preserves the perfmon state while the device is idle. 3. Move the global perfmon lifecycle management to the set_global IOCTL. This simplifies the logic in v3d_perfmon_start() and v3d_perfmon_stop(), as there is no need to always check if the global perfmon is enabled. 4. v3d_perfmon_get_values_ioctl() doesn't stop the perfmon when capturing the values. All lifecycle management is handled by the job (for per-job perfmons) or the set_global IOCTL (for global perfmons). Reviewed-by: Iago Toral Quiroga <itoral@igalia.com> Link: https://patch.msgid.link/20260706-v3d-perfmon-lifetime-v4-1-d7b312ff2c83@igalia.com Signed-off-by: Maíra Canal <mcanal@igalia.com>
2026-07-07dt-bindings: rockchip: grf: Narrow allowed reboot modesKrzysztof Kozlowski
syscon-reboot-mode schema allows arbitrary "mode-.* properties but only a subset actually makes sense and is valid. Provide negative look-ahead pattern to disallow any modes not supported by the device, which tightens the binding. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Acked-by: Rob Herring (Arm) <robh@kernel.org> Link: https://patch.msgid.link/20260701105849.197086-4-krzysztof.kozlowski@oss.qualcomm.com Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2026-07-07dt-bindings: rockchip: pmu: Narrow definition of reboot-modeKrzysztof Kozlowski
The 'reboot-mode' child of PMU node must be a syscon-reboot-mode one, so add missing $ref to enforce the validation and disallow other reboot-mode handlers. Defining 'type: object' is on the other hand not necessary when other schema is referenced. This can be further restricted to match hardware/firmware: syscon-reboot-mode schema allows arbitrary "mode-.* properties but only a subset actually makes sense and is valid. Provide negative look-ahead pattern to disallow any modes not supported by the device, which tightens the binding. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Acked-by: Rob Herring (Arm) <robh@kernel.org> Link: https://patch.msgid.link/20260701105849.197086-3-krzysztof.kozlowski@oss.qualcomm.com Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2026-07-07parisc: Remove unnecessary NULL check of the kstat_irqs fieldRadu Rendec
The kstat_irqs field of struct irq_desc is used to store a per-cpu count of interrupt events. It is initialized in init_desc(), along with all the other fields in struct irq_desc that need explicit initialization, and therefore it's always available (non-NULL) for any valid interrupt descriptor. On parisc, CONFIG_SPARSE_IRQ is disabled, interrupt descriptors are allocated statically in the irq_desc[] array, and kstat_irqs is initialized implicitly to NULL. The kstat_irqs field is initialized later, for all descriptors, via start_kernel() -> early_irq_init() -> init_desc(). smp_boot_one_cpu() is used only for CPU hotplugging. On a SMP system, the boot CPU initializes the interrupt descriptors as described above, and smp_boot_one_cpu() is called later, for the secondary CPU(s). A previous change made similar changes across the generic interrupt code in kernel/irq/irqdesc.c, and provides a more detailed explanation of why kstat_irqs is guaranteed to be non-NULL. Signed-off-by: Radu Rendec <radu@rendec.net> Signed-off-by: Thomas Gleixner <tglx@kernel.org> Link: https://patch.msgid.link/20260705210951.2717741-3-radu@rendec.net
2026-07-07genirq: Remove unnecessary NULL check of the kstat_irqs fieldRadu Rendec
The kstat_irqs field of struct irq_desc is used to store a per-cpu count of interrupt events. It is initialized in init_desc(), along with all the other fields in struct irq_desc that need explicit initialization, and therefore it's always available (non-NULL) for any valid interrupt descriptor (with a caveat - see below). When CONFIG_SPARSE_IRQ is enabled, all interrupt descriptors are always allocated dynamically via alloc_desc(), which calls init_desc(), so in that case kstat_irqs is guaranteed to be non-NULL before a valid struct irq_desc pointer is even returned. By contrast, when CONFIG_SPARSE_IRQ is disabled, interrupt descriptors are allocated statically in the irq_desc[] array, and kstat_irqs is initialized implicitly to NULL. The per-cpu pointer is initialized only later, for all descriptors, via start_kernel() -> early_irq_init() -> init_desc(). The kstat_irqs field is used mostly for printing interrupt statistics (i.e. reading /proc/interrupts), and that cannot happen until much later, when user-space is fully initialized. So, there is no concern with that use case. The list below includes all functions where the NULL check is removed, along with a list of all possible call chains and/or a brief explanation of why it's safe to remove the NULL check in that case. * irq_desc_kstat_cpu() [include/linux/irqdesc.h] - All direct call sites use it for printing IRQ statistics. - Indirect call site: per_cpu_count_show() - also used for printing interruptstatistics. * kstat_irqs_cpu() [kernel/irq/irqdesc.c] - Called by sun3_int7() and sun3_int5() [arch/m68k/sun3/sun3ints.c] These are interrupt handlers and cannot be called until their corresponding interrupts are initialized in sun3_init_IRQ(). The call chain leading to that is: start_kernel() -> init_IRQ() [arch/m68k/kernel/ints.c] -> mach_init_IRQ = sun3_init_IRQ() The init_IRQ() call happens right *after* the early_irq_init() call, which means the descriptors are already fully initialized by the time the interrupt handlers are even registered. - Called by show_interrupts() [arch/s390/kernel/irq.c] - used for printing interrupt statistics. * kstat_irqs() [kernel/irq/irqdesc.c] The only possible call chain is via fs/proc/stat.c: stat_open() -> show_stat() -> show_all_irqs() -> kstat_irqs_usr() -> kstat_irqs() It is used for printing interrupt statistics. * kstat_snapshot_irqs() The only possible call chain is via kernel/watchdog.c: watchdog_timer_fn() -> is_softlockup() -> start_counting_irqs() -> kstat_snapshot_irqs() The watchdog timer cannot fire early, before early_irq_init(). * kstat_get_irq_since_snapshot() The only possible call chain is via kernel/watchdog.c: watchdog_timer_fn() -> report_cpu_status() -> print_irq_counts() -> kstat_get_irq_since_snapshot() The watchdog timer cannot fire early, before early_irq_init(). Signed-off-by: Radu Rendec <radu@rendec.net> Signed-off-by: Thomas Gleixner <tglx@kernel.org> Link: https://patch.msgid.link/20260705210951.2717741-2-radu@rendec.net
2026-07-07selftests/lsm: Fix memory leak in attr_lsm_countWang Yan
The calloc-allocated buffer in attr_lsm_count() is never released on any exit path, including both the normal return path and the early return when read_sysfs_lsms fails, resulting in a heap memory leak. Add free() for the buffer on all return branches to fix the leak. Fixes: d3d929a8b0cd ("LSM: selftests for Linux Security Module syscalls") Signed-off-by: Wang Yan <wangyan01@kylinos.cn> Reviewed-by: William Roberts <bill.c.roberts@gmail.com> Tested-by: William Roberts <bill.c.roberts@gmail.com> Signed-off-by: Paul Moore <paul@paul-moore.com>
2026-07-07cred: delete task_euid()Alice Ryhl
task_euid() is a very weird operation. You can see how weird it is by grepping for task_euid() - binder is its only user. task_euid() obtains the objective effective UID - it looks at the credentials of the task for purposes of acting on it as an object, but then accesses the effective UID (which the credentials.7 man page describes as "[...] used by the kernel to determine the permissions that the process will have when accessing shared resources [...]"). Since usage in Binder has now been removed, get rid of the resulting dead code. Changes to the zh_CN translation was carried out with the help of Gemini and Google Translate, and since adjusted as per Alex Shi's feedback. Suggested-by: Jann Horn <jannh@google.com> Reviewed-by: Gary Guo <gary@garyguo.net> Signed-off-by: Alice Ryhl <aliceryhl@google.com> Signed-off-by: Paul Moore <paul@paul-moore.com>
2026-07-07rust: task: clarify comments on task UID accessorsJann Horn
Linux has separate subjective and objective task credentials, see the comment above `struct cred`. Clarify which accessor functions operate on which set of credentials. Also document that Task::euid() is a very weird operation. You can see how weird it is by grepping for task_euid() in the history - binder was its only user. Task::euid() obtains the objective effective UID - it looks at the credentials of the task for purposes of acting on it as an object, but then accesses the effective UID (which the credentials.7 man page describes as "[...] used by the kernel to determine the permissions that the process will have when accessing shared resources [...]"). For context: Arguably, binder's use of task_euid() is a theoretical security problem, which only has no impact on Android because Android has no setuid binaries executable by apps. commit 29bc22ac5e5b ("binder: use euid from cred instead of using task") originally fixed that by removing that only user of task_euid(), but the fix got reverted in commit c21a80ca0684 ("binder: fix test regression due to sender_euid change") because some Android test started failing. It was since fixed again by commit 65b672152289 ("binder: use current_euid() for transaction sender identity"), which uses current_euid() instead. Signed-off-by: Jann Horn <jannh@google.com> Reviewed-by: Gary Guo <gary@garyguo.net> Signed-off-by: Alice Ryhl <aliceryhl@google.com> Signed-off-by: Paul Moore <paul@paul-moore.com>
2026-07-07selftests/bpf: Fix memory leak in msg_alloc_iovFeng Yang
In the msg_alloc_iov function, the iov pointer is only assigned to msg->msg_iov after all memory allocations complete successfully. Therefore, when a calloc failure triggers the unwind_iov cleanup branch, we should use the local variable iov instead of msg->msg_iov. Fixes: 753fb2ee0934 ("bpf: sockmap, add msg_peek tests to test_sockmap") Signed-off-by: Feng Yang <yangfeng@kylinos.cn> Reviewed-by: John Fastabend <john.fastabend@gmail.com> Link: https://lore.kernel.org/bpf/20260707081434.539327-1-yangfeng59949@163.com Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
2026-07-07selftests/bpf: Drop tc/xdp/flow_dissector/socket_filter sockmap mutation testsSechang Lim
tc, xdp, socket_filter and flow_dissector programs can no longer update or delete a sockmap. Adjust the tests: - verifier_sockmap_mutate: the tc, xdp, socket_filter and flow_dissector cases now expect __failure with "cannot update sockmap in this context". - sockmap_basic: drop "sockmap update" / "sockhash update", which load a SEC("tc") program that copies a sock between maps. - fexit_bpf2bpf: drop "func_sockmap_update", whose freplace program updates a sockmap in the tc cls_redirect context. Remove the now-unused test_sockmap_update.c and freplace_cls_redirect.c. Signed-off-by: Sechang Lim <rhkrqnwk98@gmail.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Reviewed-by: John Fastabend <john.fastabend@gmail.com> Reviewed-by: Emil Tsalapatis <emil@etsalapatis.com> Link: https://lore.kernel.org/bpf/20260630145410.3648099-3-rhkrqnwk98@gmail.com Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
2026-07-07bpf, sockmap: Disallow update and delete from tc, xdp, socket_filter and ↵Sechang Lim
flow_dissector sock_map_update_common() and __sock_map_delete() hold stab->lock and call sock_map_unref() -> sock_map_del_link(), which takes sk_callback_lock for write. That gives the order stab->lock -> sk_callback_lock. The reverse order comes from the SK_SKB stream parser. sk_psock_strp_data_ready() holds sk_callback_lock for read, and after the verdict tcp_bpf_strp_read_sock() acks the consumed data inline via __tcp_cleanup_rbuf(). The ACK goes out egress, where a sched_cls program deletes from the sockmap and takes stab->lock: WARNING: possible circular locking dependency detected ------------------------------------------------------ syz.9.8824 is trying to acquire lock: (&stab->lock){+.-.}-{3:3}, at: __sock_map_delete net/core/sock_map.c:421 but task is already holding lock: (clock-AF_INET){++.-}-{3:3}, at: sk_psock_strp_data_ready net/core/skmsg.c:1173 -> #1 (clock-AF_INET){++.-}-{3:3}: _raw_write_lock_bh sock_map_del_link net/core/sock_map.c:167 sock_map_unref net/core/sock_map.c:184 sock_map_update_common net/core/sock_map.c:509 sock_map_update_elem_sys net/core/sock_map.c:588 map_update_elem kernel/bpf/syscall.c:1805 -> #0 (&stab->lock){+.-.}-{3:3}: _raw_spin_lock_bh __sock_map_delete net/core/sock_map.c:421 sock_map_delete_elem net/core/sock_map.c:452 bpf_prog_06044d24140080b6 tcx_run net/core/dev.c:4451 sch_handle_egress net/core/dev.c:4541 __dev_queue_xmit net/core/dev.c:4808 ... tcp_bpf_strp_read_sock net/ipv4/tcp_bpf.c:701 strp_data_ready net/strparser/strparser.c:402 sk_psock_strp_data_ready net/core/skmsg.c:1174 tcp_data_queue net/ipv4/tcp_input.c:5661 Possible unsafe locking scenario: CPU0 CPU1 ---- ---- rlock(clock-AF_INET); lock(&stab->lock); lock(clock-AF_INET); lock(&stab->lock); *** DEADLOCK *** A tc, xdp, socket_filter or flow_dissector program has no reason to update or delete a sockmap, and redirect does not go through here. Drop them from may_update_sockmap() so the verifier rejects it. It also closes the matching sockhash inversion. Suggested-by: John Fastabend <john.fastabend@gmail.com> Signed-off-by: Sechang Lim <rhkrqnwk98@gmail.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Reviewed-by: John Fastabend <john.fastabend@gmail.com> Reviewed-by: Emil Tsalapatis <emil@etsalapatis.com> Link: https://lore.kernel.org/bpf/20260630145410.3648099-2-rhkrqnwk98@gmail.com Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
2026-07-07KVM: selftests: Add xAPIC support in eventfd IRQ testDavid Matlack
Extend the eventfd IRQ test with a '-x' flag to let the user run the test in xAPIC mode instead of the default x2APIC mode. When using xAPIC mode, sanity check user input to ensure the test is being run with at most 255 vCPUs, as xAPIC can only address IDs 0-254 (255, i.e. 0xff, broadcasts to all CPUs). Signed-off-by: David Matlack <dmatlack@google.com> Co-developed-by: Josh Hilke <jrhilke@google.com> Signed-off-by: Josh Hilke <jrhilke@google.com> [sean: add sanity check on number of vCPUs] Link: https://patch.msgid.link/20260626213534.3866178-21-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-07-07KVM: selftests: Make number of vCPUs configurable in IRQ testDavid Matlack
Extend the eventfd IRQ test with a '-v' flag to allow the user to configure the number of vCPUs to create and run (versus only ever using a single vCPU). Update the routing logic to play nice with 32 bit IDs, enable x2APIC format in KVM (to enable 32-bit ID routing), and disable KVM's x2APIC broadcast quirk so that targeting vCPU 255 doesn't blast the interrupt to all vCPUs when in x2APIC mode. Signed-off-by: David Matlack <dmatlack@google.com> Co-developed-by: Josh Hilke <jrhilke@google.com> Signed-off-by: Josh Hilke <jrhilke@google.com> Co-developed-by: Sean Christopherson <seanjc@google.com> Link: https://patch.msgid.link/20260626213534.3866178-20-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-07-07KVM: selftests: Verify vCPU migration during IRQ delivery in IRQ testDavid Matlack
Extend the eventfd IRQ test with a '-m' flag to have the test migrate the target vCPU to a random physical CPU before triggering its interrupt, e.g. to validate KVM's ability to update device posted IRQ routing. Signed-off-by: David Matlack <dmatlack@google.com> Co-developed-by: Josh Hilke <jrhilke@google.com> Signed-off-by: Josh Hilke <jrhilke@google.com> [sean: pin one vCPU at a time to simplify things, use main()'s affinity] Link: https://patch.msgid.link/20260626213534.3866178-19-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-07-07KVM: selftests: Add a utility to pin a task to a random CPU, given a CPU setJosh Hilke
Add a helper function, pin_task_to_random_cpu(), to pin a task to a random CPU from a given cpu_set_t. This helper will be used eventfd IRQ test to migrate vCPUs to random pCPUs, to stress host-side interrupt routing and delivery. Suggested-by: Sean Christopherson <seanjc@google.com> Signed-off-by: Josh Hilke <jrhilke@google.com> [sean: massage changelog] Link: https://patch.msgid.link/20260626213534.3866178-18-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-07-07KVM: selftests: Add kvm_sched_getaffinity() wrapper and convert usersJosh Hilke
Add and use a KVM wrapper for the sched_getaffinity() syscall so that selftests don't need to manually assert that the syscall succeeded. Note, some tests didn't actually assert success, but they all obviously rely on the syscall to succeed. Suggested-by: Sean Christopherson <seanjc@google.com> Signed-off-by: Josh Hilke <jrhilke@google.com> [sean: massage changelog] Link: https://patch.msgid.link/20260626213534.3866178-17-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-07-07KVM: selftests: Add kvm_gettid() wrapper and convert usersJosh Hilke
Add a KVM wrapper for the gettid() syscall so that tests don't have to open code the syscall() themselves. Unfortunately, not all flavors of libc that KVM selftests support provide gettid(). Convert all existing users of the syscall to the new wrapper. Note, per the gettid() manpage[1], "This call is always successful", i.e. prefixing kvm_ to the syscall name is aligned with the goal of providing syscall wrappers that guarantee success. No functional changes intended. Link: https://man7.org/linux/man-pages/man2/gettid.2.html [1] Suggested-by: Sean Christopherson <seanjc@google.com> Signed-off-by: Josh Hilke <jrhilke@google.com> [sean: massage changelog] Link: https://patch.msgid.link/20260626213534.3866178-16-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-07-07KVM: selftests: Verify non-postable IRQ remapping in IRQ testSean Christopherson
Extend the eventfd IRQ test with an '-n' flag to route a subset of device interrupts as NMIs (Non-Maskable Interrupts) into the guest using an alternating pattern of 4 NMIs followed by 4 regular interrupts. While this adds coverage for NMI injection, the primary goal is to validate KVM's handling of non-postable interrupt delivery (AMD and Intel IOMMUs only support posting fixed IRQs targeting a single vCPU). KVM has historically bungled handling transitions between posted and remapped modes. Use NMIs to stress the transitions, because they are a reliable, architectural way to force these code paths. Signed-off-by: David Matlack <dmatlack@google.com> Co-developed-by: Josh Hilke <jrhilke@google.com> Signed-off-by: Josh Hilke <jrhilke@google.com> [sean: add GUEST_RECEIVED_INTERRUPT(), massage changelog] Link: https://patch.msgid.link/20260626213534.3866178-15-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-07-07KVM: selftests: Make number of IRQs configurable in IRQ testDavid Matlack
Extend the eventfd IRQ test with a '-i' flag to let the user specify the the number of IRQs to generate (instead of hardcoding the test to always generate 1000 interrupts). Signed-off-by: David Matlack <dmatlack@google.com> Co-developed-by: Josh Hilke <jrhilke@google.com> Signed-off-by: Josh Hilke <jrhilke@google.com> [sean: massage changelog] Link: https://patch.msgid.link/20260626213534.3866178-14-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-07-07KVM: selftests: Add option to set empty routing between IRQs in eventfd IRQ testDavid Matlack
Extend the eventfd IRQ test with an '-e' flag to set empty GSI routing between interrupts. Clobbering the GSI routing table verifies that KVM correctly handles CPUx => NULL => CPUy transitions, not just CPUx => CPUy transitions, and verifies that KVM can "rebuild" an entire routing setup. Signed-off-by: David Matlack <dmatlack@google.com> Co-developed-by: Josh Hilke <jrhilke@google.com> Signed-off-by: Josh Hilke <jrhilke@google.com> [sean: '-e' for "empty" instead of '-c' for "clear", massage changelog] Link: https://patch.msgid.link/20260626213534.3866178-13-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-07-07KVM: selftests: Verify interrupts are received when IRQ affinity changes in ↵David Matlack
IRQ test Extent the eventfd IRQ test with a '-a' flag to randomly affinitize the device's host IRQ to different physical CPUs throughout the test. This stresses the kernel's ability to maintain correct interrupt routing and delivery even as the underlying hardware IRQ affinity is changed dynamically via /proc/<irq>/smp_affinity{,_list}. Signed-off-by: David Matlack <dmatlack@google.com> Co-developed-by: Josh Hilke <jrhilke@google.com> Signed-off-by: Josh Hilke <jrhilke@google.com> [sean: massage changelog] Link: https://patch.msgid.link/20260626213534.3866178-12-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-07-07KVM: selftests: Add a helper to set proc IRQ affinity for IRQ testJosh Hilke
Add a utility, proc_irq_set_smp_affinity(), to set the CPU affinity of a Linux host IRQ via the proc filesystem. Use smp_affinity_list instead of smp_affinity to avoid having to convert the single CPU to a bitmask. The helper will be used by the eventfd IRQ test to verify delivery of IRQs when the affinity is randomized/modified. Signed-off-by: Josh Hilke <jrhilke@google.com> [sean: make the utility self-contained, drop "list", massage changelog] Link: https://patch.msgid.link/20260626213534.3866178-11-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-07-07KVM: selftests: Add VFIO device support to eventfd IRQ testDavid Matlack
Extend the eventfd IRQ test with a '-d' argument that takes a BDF (in the format segment:bus:device.function) of an interrupt-capable PCI(e) device bound to VFIO, and use said device to trigger interrupts instead of always synthesizing interrupts via direct writes to the eventfd. Using a VFIO device to trigger interrupts validates the end-to-end delivery of IRQs for "real" devices, and when supported by hardware (and KVM), also validates interrupt delivery via IRQ bypass, i.e. via device posted IRQs. Now that IOMMUFD is a thing, auto-probe IOMMUFD vs. "legacy" VFIO by temporarily opening /dev/iommufd, and skip the test if neither IOMMUFD nor legacy VFIO is available. Add a '-t' option to the user override the probe logic, e.g. in case IOMMUFD is available but the system is configured for legacy usage. Note, the device must have a VFIO selftest driver in order to work with the test. A helper script to list supported devices will hopefully be available in the near future at tools/testing/selftests/vfio/scripts/list_supported_devices.sh[1]. Example: $ ./tools/testing/selftests/kvm/irq_test -d 0000:06:0a.1 Link: https://lore.kernel.org/all/20260602222941.3133236-1-jrhilke%40google.com [1] Signed-off-by: David Matlack <dmatlack@google.com> Co-developed-by: Josh Hilke <jrhilke@google.com> Signed-off-by: Josh Hilke <jrhilke@google.com> Co-developed-by: Sean Christopherson <seanjc@google.com> Link: https://patch.msgid.link/20260626213534.3866178-10-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-07-07KVM: selftests: Add helper to get host IRQ from device MSI-X for IRQ bypass testDavid Matlack
Introduce proc_util.c and proc_util.h to house utility functions for interacting with the proc filesystem. Add vfio_msix_to_host_irq(), which parses /proc/interrupts, to get the host Linux IRQ for a given VFIO device BDF and MSI-X vector. This helper will be used by the eventfd IRQ test to print the host IRQ number when triggering IRQs via VFIO device, e.g. to aid in debugging if the test fails. Suggested-by: Sean Christopherson <seanjc@google.com> Signed-off-by: David Matlack <dmatlack@google.com> Co-developed-by: Josh Hilke <jrhilke@google.com> Signed-off-by: Josh Hilke <jrhilke@google.com> [sean: massage changelog] Link: https://patch.msgid.link/20260626213534.3866178-9-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
generated by cgit v1.2.3 (git 2.39.1) at 2026-09-08 16:42:52 +0000