summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2026-07-07KVM: selftests: Add an irqfd send+receive (and later IRQ bypass) testDavid Matlack
Add a new test, irq_test to verify that KVM correctly delivers interrupts to a running vCPU, when triggered via an eventfd bound to a KVM GSI using KVM's irqfd mechanism. This test is intentionally simple, for now. Support for sending interrupts via VFIO devices, for IRQ bypass, and for other features will be added in the near future. Add the test in common code, even though it currently will only build and run on x86, as the concept and the bulk of the host-side code isn't specific to x86. Suggested-by: Sean Christopherson <seanjc@google.com> Link: https://lore.kernel.org/kvm/20250404193923.1413163-68-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: use while() and TEST_ASSERT() instead of if-statement => TEST_FAIL()] Link: https://patch.msgid.link/20260626213534.3866178-8-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-07-07KVM: selftests: Add helper to generate random u64 in range [min,max]Josh Hilke
Introduce kvm_random_u64_in_range(state, min, max). This function returns a random u64 in the inclusive range of [min, max] using a struct kvm_random_state. Suggested-by: Sean Christopherson <seanjc@google.com> Signed-off-by: Josh Hilke <jrhilke@google.com> Link: https://patch.msgid.link/20260626213534.3866178-7-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-07-07KVM: selftests: Seed libc's RNG before using it to generate a seed for KVM's ↵Sean Christopherson
pRNG Seed the RNG used by random() using the de facto standard method of srand(time(0)), so that a different seed is actually used in each test run. E.g. without seeding the RNG, literally every test on x86 will use 0x6b8b4567 to seed the KVM RNG. Link: https://patch.msgid.link/20260626213534.3866178-6-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-07-07KVM: selftests: Initialize the default/global pRNG during kvm_selftest_init()Sean Christopherson
Initialize the default kvm_rng during selftest initialization so that the pRNG can be used by tests before creating a VM. As pointed out by Sashiko, failure to actually initialize the generate makes it decidedly not random. Link: https://patch.msgid.link/20260626213534.3866178-5-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-07-07KVM: selftests: Rename guest_rng to kvm_rngJosh Hilke
Rename functions prefixed with 'guest_random_' to 'kvm_random_' and the global random state variable 'guest_rng' to 'kvm_rng', as the pRNG isn't strictly limited to guest code. This will allow using the pRNG in host code without creating confusing/misleading function calls. No functional changes are intended. 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-4-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-07-07KVM: selftests: Add macros to read/write+sync to/from guest memoryDavid Matlack
Add SYNC_FROM_GUEST_AND_READ(vm, variable), to read a variable value from the guest. Add WRITE_AND_SYNC_TO_GUEST(vm, variable, value) to write a value to a guest variable. These macros improve the readability of code which reads and writes data between host and guest in tests. Use the new macro in existing tests that do back-to-back write+sync. No functional changes are intended. 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-3-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-07-07KVM: selftests: Build and link selftests/vfio/lib into KVM selftestsDavid Matlack
Include libvfio.mk into the KVM selftests Makefile and link it into all KVM selftests by adding it to LIBKVM_OBJS. This lays the groundwork for future changes to utilize VFIO devices to verify IRQ bypass in KVM selftests. Note that KVM selftests build their own copy of selftests/vfio/lib and the resulting object files are placed in $(OUTPUT)/lib. This allows the KVM and VFIO selftests to apply different CFLAGS when building without conflicting with each other. Signed-off-by: David Matlack <dmatlack@google.com> Signed-off-by: Josh Hilke <jrhilke@google.com> Link: https://patch.msgid.link/20260626213534.3866178-2-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-07-07nilfs2: handle corrupted checkpoint count gracefully during deletionIgor Putko
Syzkaller reported a kernel warning in nilfs_cpfile_delete_checkpoints() due to a corrupted checkpoint count on the storage medium where le32_to_cpu(cp->cp_checkpoints_count) is less than the number of checkpoints being deleted. Triggering a WARN_ON() for disk image corruption is suboptimal. Fix this by returning -EIO and reporting a filesystem error via nilfs_error() instead of interrupting execution with a kernel warning. Reported-by: syzbot+79b815da3aec0a6a4d02@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=79b815da3aec0a6a4d02 Signed-off-by: Igor Putko <igorpetindev@gmail.com> Fixes: 1f5abe7e7dbc ("nilfs2: replace BUG_ON and BUG calls triggerable from ioctl") Cc: stable+noautosel@kernel.org # Warning suppression primarily; will request backport individually if needed Signed-off-by: Ryusuke Konishi <konishi.ryusuke@gmail.com> Signed-off-by: Viacheslav Dubeyko <slava@dubeyko.com>
2026-07-07tracing/synthetic: Free type string on error pathYu Peng
parse_synth_field() builds a "__data_loc ..." type string before assigning it to field->type. If the seq_buf check fails, the common cleanup cannot free the temporary string. Free it before leaving. Link: https://patch.msgid.link/20260603062533.1096320-2-pengyu@kylinos.cn Signed-off-by: Yu Peng <pengyu@kylinos.cn> Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
2026-07-07tracing/user_events: Fix use-after-free in user_event_mm_dup()Michael Bommarito
user_event_mm_dup() walks the parent mm's enabler list locklessly under rcu_read_lock() during fork() (from copy_process()); it does not take event_mutex: rcu_read_lock(); list_for_each_entry_rcu(enabler, &old_mm->enablers, mm_enablers_link) enabler->event = user_event_get(orig->event); user_event_enabler_destroy() removes an enabler from that list with list_del_rcu() and then, without waiting for a grace period, drops the enabler's user_event reference with user_event_put() and frees the enabler with kfree(). A reader that loaded the enabler before the list_del_rcu() can still be walking it, which leads to two use-after-frees: - kfree(enabler) frees the enabler while that reader dereferences enabler->event. - user_event_put() may drop the last reference to the user_event, which is then freed (via delayed_destroy_user_event() on a work queue), while the same reader does user_event_get(orig->event) on it. Both are reachable by an unprivileged task that can open user_events_data: one multithreaded process that registers an enabler and then concurrently unregisters it and calls fork() triggers the race. KASAN reports a slab-use-after-free in user_event_mm_dup() during clone(), with a "refcount_t: addition on 0" warning when the user_event is freed. The enabler use-after-free was found first; the user_event one was reported by XIAO WU, and the earlier enabler-only fix did not address it. Defer both the user_event_put() and the kfree(enabler) to a work item queued with queue_rcu_work(), so they run only after an RCU grace period, once all readers walking the enabler list have finished. The put must run in process context because user_event_put() takes event_mutex on the last reference, so a work queue is used rather than call_rcu(). The now-unlocked put lets the locked argument of user_event_enabler_destroy() be removed; all callers are updated. Fixes: 7235759084a4 ("tracing/user_events: Use remote writes for event enablement") Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260707165912.2560537-2-michael.bommarito@gmail.com Reported-by: XIAO WU <xiaowu.417@qq.com> Closes: https://lore.kernel.org/all/tencent_89647CE40DC452B891C65C94D1B271DE8E07@qq.com/ Suggested-by: Beau Belgrave <beaub@linux.microsoft.com> Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Michael Bommarito <michael.bommarito@gmail.com> Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
2026-07-07platform/x86: amd-pmc: Use correct IP block table for AMD 1Ah M80H SoCShyam Sundar S K
PMFW reports the S0i3 subsystem accounting per SoC, and the set of IP blocks and their bit ordering differ across SoC generations. Family 1Ah, Model 80h accounts for a distinct set of 19 IP blocks, which does not match the ordering in soc15_ip_blk[]. Commit 043af31c8d30 ("platform/x86/amd/pmc: Add PMC driver support for AMD 1Ah M80H SoC") wired amd_1ah_m80_cpu_info to soc15_ip_blk[], so M80H has been reporting incorrect S0i3 accounting via debugfs. Add soc15_ip_blk_v3[] with the correct ordering and point amd_1ah_m80_cpu_info at it. Fixes: 043af31c8d30 ("platform/x86/amd/pmc: Add PMC driver support for AMD 1Ah M80H SoC") Signed-off-by: Shyam Sundar S K <Shyam-sundar.S-k@amd.com> Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org> Link: https://patch.msgid.link/20260707122852.2066987-1-Shyam-sundar.S-k@amd.com Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2026-07-07platform/x86: asus-armoury: update power limits for G614PRMarco Scardovi
The previously integrated power limits for the ASUS ROG Strix G16 G614PR laptop model were incorrect and too low compared to the windows counterparts. Update the power limits to the correct specifications based on the platform's hardware capabilities: - Increase AC PL1/SPL max limit from 90W to 120W. - Increase AC PL2/SPPT default/max from 110W/125W to 140W/145W. - Increase AC PL3/FPPT default/max from 110W/125W to 140W/145W. Fixes: 6b3bbe770f4ca0439710b7c42f88b9f6eeebabd0 (platform/x86: asus-armoury: add support for G614PR) Fixes: https://lore.kernel.org/platform-driver-x86/20260610152130.25892-1-scardracs@disroot.org/ Signed-off-by: Marco Scardovi <scardracs@disroot.org> Link: https://patch.msgid.link/20260630142957.7751-1-scardracs@disroot.org Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2026-07-07accel/amdxdna: Fix hardware context race in amdxdna_update_heap()Lizhi Hou
amdxdna_update_heap() iterates over hardware contexts while holding xdna->dev_lock. During the iteration, amdxdna_pm_resume_get_locked() may temporarily release and reacquire the lock, allowing hardware contexts to be modified concurrently. Fix the race by calling amdxdna_pm_resume_get_locked() before iterating over hardware contexts. Fixes: dbc8fd7a03cb ("accel/amdxdna: Add expandable device heap support") Reviewed-by: Max Zhen <max.zhen@amd.com> Signed-off-by: Lizhi Hou <lizhi.hou@amd.com> Link: https://patch.msgid.link/20260707055818.479165-1-lizhi.hou@amd.com
2026-07-07accel/amdxdna: Fix deadlock on debug BO command timeoutLizhi Hou
Both amdxdna_hwctx_sync_debug_bo() and amdxdna_drm_config_hwctx_ioctl() hold xdna->dev_lock while invoking backend operations. If the hardware hangs, aie2_cmd_wait() blocks waiting for a firmware response. When the DRM scheduler timeout expires, aie2_sched_job_timedout() is invoked to reset the hardware. However, the timeout handler also attempts to acquire dev_lock, resulting in a deadlock. Avoid this by releasing dev_lock before waiting for the firmware response and reacquiring it after the wait completes. This allows the timeout handler to proceed with device recovery when a debug BO command times out. Fixes: 7ea046838021 ("accel/amdxdna: Support firmware debug buffer") Reviewed-by: Max Zhen <max.zhen@amd.com> Signed-off-by: Lizhi Hou <lizhi.hou@amd.com> Link: https://patch.msgid.link/20260707055732.479103-1-lizhi.hou@amd.com
2026-07-07accel/amdxdna: fix open_ref leak and stale client pointer on dma map failureLizhi Hou
amdxdna_gem_obj_open() increments open_ref before attempting to set up the DMA address mapping. When amdxdna_dma_map_bo() fails, the function returned immediately without rolling back either change made on the first open (open_ref == 1 path). Fix it by decrementing open_ref and clearing abo->client on the error path. Fixes: ece3e8980907 ("accel/amdxdna: Allow forcing IOVA-based DMA via module parameter") Reviewed-by: Max Zhen <max.zhen@amd.com> Signed-off-by: Lizhi Hou <lizhi.hou@amd.com> Link: https://patch.msgid.link/20260707055658.479049-1-lizhi.hou@amd.com
2026-07-07accel/amdxdna: Fix potential amdxdna_umap lifetime raceLizhi Hou
amdxdna_umap_release() calls the blocking mmu_interval_notifier_remove() before removing the object from abo->mem.umap_list. If aie2_populate_range() runs concurrently, it may obtain a reference to an amdxdna_umap that is being released, leading to a potential use-after-free. Use kref_get_unless_zero() in aie2_populate_range() when acquiring a reference. If the reference count has already dropped to zero, release is in progress and the entry is skipped. Fixes: e486147c912f ("accel/amdxdna: Add BO import and export") Reviewed-by: Max Zhen <max.zhen@amd.com> Signed-off-by: Lizhi Hou <lizhi.hou@amd.com> Link: https://patch.msgid.link/20260706221228.434099-1-lizhi.hou@amd.com
2026-07-07KVM: arm64: Fix propagation of TLBI level in kvm_pgtable_stage2_relax_perms()Marc Zyngier
Assigning the invalidation level (an s8 value) with TLBI_TTL_UNKNOWN (a 32bit signed value) is not ideal, to say the least. Instead of this, only pass TLBI_TTL_UNKNOWN to __kvm_tlb_flush_vmid_ipa_nsh() when we know for sure that we don't have a provided level. Fixes: 100baf0184896 ("KVM: arm64: Ensure level is always initialized when relaxing perms") Reported-by: Mark Brown <broonie@kernel.org> Reviewed-by: Oliver Upton <oupton@kernel.org> Link: https://lore.kernel.org/r/akztC7H2IsEKaq4i@sirena.org.uk Link: https://patch.msgid.link/20260707162935.1900874-1-maz@kernel.org Signed-off-by: Marc Zyngier <maz@kernel.org>
2026-07-07x86/virt/sev: Revert "Drop WBINVD before setting MSR_AMD64_SYSCFG_SNP_EN"Tycho Andersen (AMD)
Revert 99cf1fb58e68 ("x86/virt/sev: Drop WBINVD before setting MSR_AMD64_SYSCFG_SNP_EN"). Section 8.8 of the SNP spec says: Before invoking SNP_INIT_EX with INIT_RMP set to 1, software must ensure that no CPUs contain dirty cache lines for the memory containing the RMP. Cachelines can be moved from cache to cache in a dirty state. The wbinvd_on_all_cpus() before SNP_INIT_EX flushes the caches for each CPU, but if the IPIs for WBINVD race with this dirty cacheline movement, it is possible that they may not get flushed, violating the firmware requirement. Doing wbinvd_on_all_cpus() before setting SNPEn is safer since the RMP table is not yet in use. [ Heroically bisected by Srikanth. ] [ bp: Massage commit message. ] Fixes: 99cf1fb58e68 ("x86/virt/sev: Drop WBINVD before setting MSR_AMD64_SYSCFG_SNP_EN") Reported-by: Srikanth Aithal <Srikanth.Aithal@amd.com> Signed-off-by: Tycho Andersen (AMD) <tycho@kernel.org> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Tested-by: Srikanth Aithal <Srikanth.Aithal@amd.com> Reviewed-by: Tom Lendacky <thomas.lendacky@amd.com> Cc: <stable@kernel.org> Link: https://patch.msgid.link/20260707150033.2364758-1-tycho@kernel.org
2026-07-07selftests/bpf: Add test for bpf_get_smp_processor_idMaxim Khmelevskii
Add a test which checks on each CPU that the bpf_get_smp_processor_id BPF helper is returning the correct CPU number. Signed-off-by: Maxim Khmelevskii <max@linux.ibm.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Reviewed-by: Ilya Leoshkevich <iii@linux.ibm.com> Link: https://lore.kernel.org/bpf/20260703125648.919196-6-max@linux.ibm.com Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
2026-07-07s390/bpf: Replace ly instruction with llgfMaxim Khmelevskii
cpu_nr is a 32 bit value and BPF_REG_0 is a 64 bit register, when ly loads the cpu_nr into BPF_REG_0 it does not zero the upper bits, but llgf does. Fixes: 9012cf2491e3 ("s390/bpf: Inline smp_processor_id and current_task") Signed-off-by: Maxim Khmelevskii <max@linux.ibm.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Reviewed-by: Ilya Leoshkevich <iii@linux.ibm.com> Link: https://sashiko.dev/#/patchset/20260414142930.528751-1-max%40linux.ibm.com Link: https://lore.kernel.org/bpf/20260703125648.919196-5-max@linux.ibm.com Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
2026-07-07docs/bpf: Document BPF_STRICT_BUILD=0 to tolerate test build failuresRicardo B. Marlière
When the kernel config does not fully match the BPF selftest config fragment, some tests may fail to compile. BPF_STRICT_BUILD (defaulting to 1) makes any such failure fatal. Mention the option so that developers are aware they can set it to 0 to skip broken tests and keep the build going, which is particularly useful during bringup or when testing on constrained (e.g. distribution) configurations. Signed-off-by: Ricardo B. Marlière <rbm@suse.com> Reviewed-by: Emil Tsalapatis <emil@etsalapatis.com> Link: https://lore.kernel.org/bpf/20260706-b4-bpf_strict_build_docs-v1-1-5324d605c7b0@suse.com Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
2026-07-07Merge branch 'bpf-reject-mem_alloc-btf-accesses-past-bounds'Kumar Kartikeya Dwivedi
Yiyang Chen says: ==================== bpf: Reject MEM_ALLOC BTF accesses past bounds BTF struct walks can relax the top-level struct-size check for trailing flexible arrays. That relaxation must not let a PTR_TO_BTF_ID | MEM_ALLOC access escape the bytes allocated by bpf_obj_new() or bpf_percpu_obj_new(). Patch 1 rejects MEM_ALLOC BTF walks whose access range reaches past the current struct size before applying the flexible-array relaxation. This now also applies to struct ID matching used by kfunc and kptr type checks. Patch 2 adds a linked_list negative loader case for this path. Changes in v3: - Pass the flexible-array walk policy through btf_struct_ids_match() callers, so MEM_ALLOC kfunc/kptr type checks use the same bounds rule. - Rename the btf_struct_walk() parameter to walk_flex_arrays. - Rebase onto current bpf-next. v2: https://lore.kernel.org/bpf/cover.1782197377.git.chenyy23@mails.tsinghua.edu.cn/ v1: https://lore.kernel.org/bpf/cover.1782100805.git.chenyy23@mails.tsinghua.edu.cn/ ==================== Link: https://patch.msgid.link/cover.1782807039.git.chenyy23@mails.tsinghua.edu.cn Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
2026-07-07selftests/bpf: Cover MEM_ALLOC access past object boundsYiyang Chen
Add a linked_list negative loader case for a program-BTF type whose last member is a zero-length flexible array. The program writes through the first flexible-array element of an object allocated by bpf_obj_new(). The verifier should reject the access when the BTF walk reaches beyond the static size of the allocated object. Signed-off-by: Yiyang Chen <chenyy23@mails.tsinghua.edu.cn> Acked-by: Eduard Zingerman <eddyz87@gmail.com> Link: https://lore.kernel.org/bpf/e36fd5d2f4047809f0e5da46a7077083297e64db.1782807039.git.chenyy23@mails.tsinghua.edu.cn Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
2026-07-07bpf: Reject MEM_ALLOC BTF accesses past object boundsYiyang Chen
BTF struct walks relax the struct-size check for accesses through a trailing flexible array. That is valid for ordinary BTF type walking, but PTR_TO_BTF_ID | MEM_ALLOC values point to objects allocated with the static BTF type size. When walking a MEM_ALLOC object, reject the access before applying the flexible-array relaxation if the access range extends past the struct size. Apply the same policy to struct ID matching so kfunc and kptr type checks do not walk past the allocated object bounds either. Fixes: 958cf2e273f0 ("bpf: Introduce bpf_obj_new") Fixes: 36d8bdf75a93 ("bpf: Add alloc/xchg/direct_access support for local percpu kptr") Signed-off-by: Yiyang Chen <chenyy23@mails.tsinghua.edu.cn> Reviewed-by: Amery Hung <ameryhung@gmail.com> Acked-by: Eduard Zingerman <eddyz87@gmail.com> Link: https://lore.kernel.org/bpf/4b8c8a81102ba4b595011434c881194f264ddc59.1782807039.git.chenyy23@mails.tsinghua.edu.cn Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
2026-07-07selftests/bpf: Fix memory leak in msg_alloc_iov error pathMalaya Kumar Rout
In msg_alloc_iov(), when calloc() fails for an individual iov_base allocation, the error path frees all previously allocated iov_base entries but fails to free the iov array itself that was allocated with calloc() at the beginning of the function. This results in a memory leak of the iov array. Add free(iov) in the unwind_iov error path to ensure proper cleanup of all allocated memory. Fixes: 753fb2ee0934 ("bpf: sockmap, add msg_peek tests to test_sockmap") Signed-off-by: Malaya Kumar Rout <malayarout91@gmail.com> Reviewed-by: Emil Tsalapatis <emil@etsalapatis.com> Link: https://lore.kernel.org/bpf/20260704122936.102394-1-malayarout91@gmail.com Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
2026-07-07Merge branch 'selftests-bpf-libarena-cleanup-and-bitmap-struct'Kumar Kartikeya Dwivedi
Emil Tsalapatis says: ==================== selftests/bpf: libarena cleanup and bitmap struct Cleanup patches for libarena, along with a new bitmap data type that is in use by sched-ext. Patch 1 is an NFC that properly renames the buddy selftests for consistency. Patch 2 fixes the zero variable used in libarena for can_loop based looping, and afterwrds removes all bpf_for() instances from the code. Patch 3 fixes an (untriggered) edge case that could cause spurious selftest failures. Finally, patches 4 to 6 introduce the bitmap data structure along with selftests. Signed-off-by: Emil Tsalapatis <emil@etsalapatis.com> CHANGELOG ========= v3 was resent as the first submission was missing the first patch. v2 -> v3: (https://lore.kernel.org/bpf/20260701185235.4516-1-emil@etsalapatis.com) - Remove unused macros and fix typo in commit message (AI) v1 -> v2: (https://lore.kernel.org/bpf/20260618085626.19633-1-emil@etsalapatis.com) - Added acks by Ihor and Eduard - Fix missing commit message (Ihor) - Enforce 64 bits per cell with BITS_TO_LONG_LONG (Sashiko) - Add test for bmp_copy (Ihor) - Add atomic versions of _set() and _clear() (Ihor) and add a parallel selftest for them. ==================== Link: https://patch.msgid.link/20260706181730.21731-1-emil@etsalapatis.com Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
2026-07-07selftests/bpf: libarena: Add parallel bitmap selftestEmil Tsalapatis
Add a selftest for testing the atomic bitmap set/clear/ test_and_set/test_and_clear operations. The selftest checks atomicity by spawning two threads, each of which either only works on even bits or with odd bits. The test checks that threads do not affect each other's bits. Signed-off-by: Emil Tsalapatis <emil@etsalapatis.com> Link: https://lore.kernel.org/bpf/20260706181730.21731-7-emil@etsalapatis.com Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
2026-07-07selftests/bpf: libarena: Add bitmap selftestsEmil Tsalapatis
Add testing for the new arena bitmap data structure. Signed-off-by: Emil Tsalapatis <emil@etsalapatis.com> Acked-by: Ihor Solodrai <ihor.solodrai@linux.dev> Link: https://lore.kernel.org/bpf/20260706181730.21731-6-emil@etsalapatis.com Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
2026-07-07selftests/bpf: Add arena-based bitmap data structureEmil Tsalapatis
Add an arena-based word-aligned bitmap data struture. The structure is useful as a building block, e.g., sched-ext uses it to represent cpumask structures. Signed-off-by: Emil Tsalapatis <emil@etsalapatis.com> Link: https://lore.kernel.org/bpf/20260706181730.21731-5-emil@etsalapatis.com Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
2026-07-07selftests/bpf: libarena: Clean up allocation state before buddy testsEmil Tsalapatis
Summary: The buddy allocator requires the global BPF buddy allocator to not be already initialized. However, the test currently merely resets the allocator before the buddy tests instead of destroying it, and the test worked because the buddy test happened to run first. Properly destroy the allocator instead of resetting it. Fixes: b1487dc1b181 ("selftests/bpf: Add selftests for libarena buddy allocator") Signed-off-by: Emil Tsalapatis <emil@etsalapatis.com> Acked-by: Ihor Solodrai <ihor.solodrai@linux.dev> Link: https://lore.kernel.org/bpf/20260706181730.21731-4-emil@etsalapatis.com Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
2026-07-07selftests/bpf: libarena: Fix can-loop zero variable definitionEmil Tsalapatis
BPF can_loop based loops require the index variable to stay imprecise. This means we must initialize them from a currently imprecise variable instead of directly assigning 0 to them, like so: static volatile u32 zero = 0; for (i = zero; i < NUM_LOOPS; i++) { /* loop body */ } The libarena implementation of this technique is currently faulty. For the technique to work, the variable must not be in a map. This includes the .rodata DATASEC map used for const variables. However, libarena still defines the zero variable as constant. Modify the zero variable definition into a volatile variable. This change adds a complication caused by the compiler optimizing array derefences from for (i = zero; i < NUM_LOOPS; i++) { val = *(ptr + i); } into for (i = zero; i < NUM_LOOPS; i++) { val = *ptr++; } and causing verification failures. Use the barrier_var() clobber macro to prevent this optimization from taking place. Using barrier_var() is the only way to break the optimization, as annotating the index as volatile does not suffice. After that, remove the bpf_for() invocations introduced in libarena for parallel spmc testing. Reported-by: Eduard Zingerman <eddyz87@gmail.com> Signed-off-by: Emil Tsalapatis <emil@etsalapatis.com> Acked-by: Eduard Zingerman <eddyz87@gmail.com> Link: https://lore.kernel.org/bpf/20260706181730.21731-3-emil@etsalapatis.com Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
2026-07-07selftests/bpf: libarena: Replace leftover st_ prefix with test_Emil Tsalapatis
The st_ (selftests_) prefix is confusing and has been replaced with the more descriptive test_. However, last patch did not properly move all files to the new prefix. Rename the existing files to complete the move. Acked-by: Ihor Solodrai <ihor.solodrai@linux.dev> Signed-off-by: Emil Tsalapatis <emil@etsalapatis.com> Link: https://lore.kernel.org/bpf/20260706181730.21731-2-emil@etsalapatis.com Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
2026-07-07drm/syncobj: Use kmalloc_objs for chainsJonathan Cavitt
Use kmalloc_objs instead of kmalloc_array when initializing chains in drm_syncobj_timeline_signal_ioctl. Concern caught by static analysis. Suggested-by: Christian König <christian.koenig@amd.com> Signed-off-by: Jonathan Cavitt <jonathan.cavitt@intel.com> Cc: Tobias Hector <Tobias.Hector@amd.com> Cc: Jason Ekstrand <jason@jlekstrand.net> Cc: Dave Airlie <airlied@redhat.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Chunming Zhou <david1.zhou@amd.com> Cc: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Reviewed-by: Christian König <christian.koenig@amd.com> Link: https://patch.msgid.link/20260701143111.1410442-1-jonathan.cavitt@intel.com
2026-07-07serial: msm: Disable DMA for kernel console UARTStephan Gerhold
At the moment, concurrent writes from userspace and the kernel to the console can trigger a race condition that results in an infinite loop of the same messages printed over and over again. This is most likely to happen during system startup or shutdown when the init system starts/stops a large number of system services that interact with various kernel code. When userspace writes to the TTY device, the driver initiates an asynchronous DMA transfer and releases the port lock. At the same moment, the kernel printk path might grab the port lock and re-configure the UART controller for PIO, without waiting for the DMA operation to complete. It seems like this collision results in zero progress being reported for the DMA engine, so the same text is printed to the console over and over again. For the kernel console, we want a reliable output path that will be functional even during crashes etc. So rather than implementing complex code to synchronize the kernel console write routines with the userspace DMA write routines, simply disable DMA for the console UART instance. Similar checks exist in many other serial drivers, e.g. 8250_port.c, imx.c, sh-sci.c etc. Cc: stable <stable@kernel.org> Fixes: 3a878c430fd6 ("tty: serial: msm: Add TX DMA support") Signed-off-by: Stephan Gerhold <stephan.gerhold@linaro.org> Acked-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Link: https://patch.msgid.link/20260706-serial-msm-console-dma-collision-v1-1-3179b8cb1d89@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-07-07serial: max310x: implement gpio_chip::get_direction()Tapio Reijonen
It's strongly recommended for GPIO drivers to always implement the .get_direction() callback - even when the direction is tracked in software. The GPIO core emits a warning when the callback is missing and a user reads the direction of a line, e.g. via /sys/kernel/debug/gpio. The MAX310X keeps the GPIO direction in the GPIOCFG register (a set bit selects output), which the existing direction_input/output callbacks already program, so the current direction can be read back directly. Fixes: f65444187a66 ("serial: New serial driver MAX310X") Cc: stable <stable@kernel.org> Signed-off-by: Tapio Reijonen <tapio.reijonen@vaisala.com> Reviewed-by: Linus Walleij <linusw@kernel.org> Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com> Reviewed-by: Hugo Villeneuve <hvilleneuve@dimonoff.com> Link: https://patch.msgid.link/20260615-b4-serial-max310x-gpio-get-direction-v2-1-4704ba2b181a@vaisala.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-07-07tty: tty_jobctrl: use guard() in tiocgsid()John de la Garza
guard()s express more clearly what the lock protects and let the function return immediately instead of jumping to an unlock label. Signed-off-by: John de la Garza <john@jjdev.com> Reviewed-by: Jiri Slaby <jirislaby@kernel.org> Link: https://patch.msgid.link/20260701231215.4092457-1-john@jjdev.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-07-07tty: tty_jobctrl: use guard()s in tiocspgrp()John de la Garza
Convert the manual spin_lock_irq()/rcu_read_lock() nesting in tiocspgrp() to scoped guard()s. This drops the out_unlock and out_unlock_ctrl labels and lets the error paths return directly. No functional change intended. Signed-off-by: John de la Garza <john@jjdev.com> Reviewed-by: Jiri Slaby <jirislaby@kernel.org> Link: https://patch.msgid.link/20260701030139.3189030-1-john@jjdev.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-07-07serial: max310x: honour rs485 properties from per-channel DT subnodeTapio Reijonen
The MAX310x DT binding pulls in /schemas/serial/rs485.yaml via its allOf list, advertising the rs485-* properties defined there - none of which were honoured at runtime, because the driver never called uart_get_rs485_mode(). All channels share the parent SPI/I2C device, so uart_get_rs485_mode() called directly on each port would read the same chip-level fwnode for every call. Walk dev->of_node's children for the "serial@N" subnode with matching reg, and temporarily retarget the parent device's fwnode while uart_get_rs485_mode() runs, so each channel picks up its own subnode's properties. Probe is serialised, so the swap is safe. For single-channel variants (max3107, max3108), fall back to the chip's own fwnode when no subnode is present, so existing DTs that declare rs485 properties at the top level keep working. Signed-off-by: Tapio Reijonen <tapio.reijonen@vaisala.com> Link: https://patch.msgid.link/20260615-b4-max310x-rs485-dt-v3-3-7e79f064bdd7@vaisala.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-07-07dt-bindings: serial: maxim,max310x: describe per-channel rs485 subnodesTapio Reijonen
The MAX310x is a family of one- (max3107, max3108), two- (max3109) and four-channel (max14830) UARTs. The binding pulls in /schemas/serial/rs485.yaml at the chip level, describing a single set of RS-485 properties - enough for the single-channel parts, but a multi-channel chip can wire RS-485 differently on each channel. Split the binding per compatible: - single-channel parts (max3107, max3108): the chip node is itself the serial port and carries the RS-485 properties, as before; - multi-channel parts (max3109, max14830): the chip node is only a container and is no longer a serial node; each channel is a "serial@N" subnode that carries the standard serial.yaml/rs485.yaml properties (and may host a serial slave device). max3109 has channels 0-1, max14830 has 0-3. This avoids a chip node that is simultaneously a serial node and the parent of serial nodes. The driver still reads chip-level RS-485 for single-channel and legacy device trees, so existing users are unaffected. Signed-off-by: Tapio Reijonen <tapio.reijonen@vaisala.com> Reviewed-by: Rob Herring (Arm) <robh@kernel.org> Link: https://patch.msgid.link/20260615-b4-max310x-rs485-dt-v3-2-7e79f064bdd7@vaisala.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-07-07serial: max310x: register GPIO controller before adding UART portsTapio Reijonen
The MAX310x exposes four GPIOs per UART port via an in-driver gpio_chip. devm_gpiochip_add_data() used to run after the per-port uart_add_one_port() loop, so a device-tree consumer referencing one of the chip's own GPIOs (for example rs485-term-gpios = <&max310x 0 ...>) could not resolve it during port registration: the GPIO provider it waits for is the very driver still trying to register, and the lookup returns -EPROBE_DEFER on its own provider, deferring probe forever. Split the per-port setup into two passes around the gpio_chip registration: 1. Initialise per-port state - port struct fields, regmap binding, IRQ disable, work queues. The gpio_chip callbacks dereference s->p[i].regmap via to_max310x_port() and become callable as soon as the chip is visible to gpiolib, so every entry must be populated first. 2. devm_gpiochip_add_data() - register the gpio_chip. 3. Allocate a line, uart_add_one_port(), set_bit(), max310x_power(). Keeping line allocation, registration and set_bit() together preserves the existing "bit set <=> port registered" rollback invariant that out_uart relies on. Signed-off-by: Tapio Reijonen <tapio.reijonen@vaisala.com> Link: https://patch.msgid.link/20260615-b4-max310x-rs485-dt-v3-1-7e79f064bdd7@vaisala.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-07-07vc_screen: replace __get_free_pages() with kmalloc()Mike Rapoport (Microsoft)
vcs_read() and vcs_write() allocate staging buffers with __get_free_pages(). These buffers can be allocated with kmalloc() as there's nothing special about them to go directly to the page allocator. kmalloc() provides a better API that does not require ugly casts and it's a modern way of saying "I need a page-sized buffer" Replace use of __get_free_page() with kmalloc() and drop unused now DEFINE_FREE(free_page_ptr ...) Link: https://lore.kernel.org/all/700c5a5f-3128-4671-99aa-827ca73f5cdf@kernel.org Link: https://lore.kernel.org/all/635405e4-9423-4a25-a6e7-e03c8ea0bcbe@redhat.com Signed-off-by: Mike Rapoport (Microsoft) <rppt@kernel.org> Reviewed-by: Jiri Slaby <jirislaby@kernel.org> Link: https://patch.msgid.link/20260528-b4-tty-v1-4-9da9f7aec5f2@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-07-07tty: serial: men_z135_uart: replace __get_free_page() with kmalloc()Mike Rapoport (Microsoft)
men_z135_probe() allocates a receive staging buffer filled by the CPU via memcpy_fromio() from the device MMIO region. This buffer can be allocated with kmalloc() as there's nothing special about it to go directly to the page allocator. kmalloc() provides a better API that does not require ugly casts and kfree() does not need to know the size of the freed object. Replace use of __get_free_page() with kmalloc() and free_page() with kfree(). Link: https://lore.kernel.org/all/635405e4-9423-4a25-a6e7-e03c8ea0bcbe@redhat.com Signed-off-by: Mike Rapoport (Microsoft) <rppt@kernel.org> Link: https://patch.msgid.link/20260528-b4-tty-v1-3-9da9f7aec5f2@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-07-07tty: amiserial: replace get_zeroed_page() with kzalloc()Mike Rapoport (Microsoft)
rs_startup() allocates a transmit ring buffer that is used to buffer reads and writes from/to serial data register. This buffer can be allocated with kmalloc() as there's nothing special about it to go directly to the page allocator. kmalloc() provides a better API that does not require ugly casts and kfree() does not need to know the size of the freed object. Replace use of get_zeroed_page() with kzalloc() and free_page() with kfree(). Link: https://lore.kernel.org/all/635405e4-9423-4a25-a6e7-e03c8ea0bcbe@redhat.com Signed-off-by: Mike Rapoport (Microsoft) <rppt@kernel.org> Link: https://patch.msgid.link/20260528-b4-tty-v1-2-9da9f7aec5f2@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-07-07serial: pch: replace __get_free_page() with kmalloc()Mike Rapoport (Microsoft)
pch_uart_init_port() allocates a staging buffer for non-DMA receive path using __get_free_page(). This buffer can be allocated with kmalloc() as there's nothing special about it to go directly to the page allocator. kmalloc() provides a better API that does not require ugly casts and kfree() does not need to know the size of the freed object. Replace use of __get_free_page() with kmalloc() and free_page() with kfree(). Link: https://lore.kernel.org/all/635405e4-9423-4a25-a6e7-e03c8ea0bcbe@redhat.com Signed-off-by: Mike Rapoport (Microsoft) <rppt@kernel.org> Link: https://patch.msgid.link/20260528-b4-tty-v1-1-9da9f7aec5f2@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-07-07drm/exec: Use kvmalloc_objs for exec->objectsJonathan Cavitt
Use kvmalloc_objs instead of kvmalloc_array when initializing exec->objects in drm_exec_init. Concern caught by static analysis. Signed-off-by: Jonathan Cavitt <jonathan.cavitt@intel.com> Cc: Rob Clark <robdclark@chromium.org> Cc: Christian König <christian.koenig@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Link: https://patch.msgid.link/20260701172458.1416930-1-jonathan.cavitt@intel.com
2026-07-07x86/video: Only fall back to vga_default_device() without screen infoMario Limonciello
Some multi GPU systems may have a VGA compatible device, but that might not be used for display. If due to enumeration order this device is found before the one actually used for display then multiple devices may show the boot_display attribute, confusing userspace. When screen info is valid, use it exclusively to find the primary device so that only the device backing the framebuffer is reported. Only when no framebuffer has been set up does it make sense to fall back to the default VGA device. This ensures at most one primary graphics device, preferably the one with the framebuffer. Fixes: ad90860bd10ee ("fbcon: Use screen info to find primary device") Closes: https://lore.kernel.org/linux-pci/20260618081803.2790848-1-aaron.ma@canonical.com/#t Reported-by: Aaron Ma <aaron.ma@canonical.com> Suggested-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Tested-by: Aaron Ma <aaron.ma@canonical.com> Cc: <stable@kernel.org> Link: https://patch.msgid.link/20260623141505.1816786-1-mario.limonciello@amd.com
2026-07-07tracing: Add a no-rcu-check version of trace_##event##_enabled()Steven Rostedt
Tracepoints require that RCU is watching. To prevent them from being used in places that RCU is not watching, the trace_##event() macro always calls rcu_is_watching() even when the event is not enabled and warns if RCU is not watching. This is to make sure a warning is triggered even if the tracepoint is never enabled (as it is only a bug when it is). It was noticed that tracepoints could be hidden within trace_#event#_enabled() calls, which are used to do extra work for the tracepoint only if the tracepoint is enabled. But this also can hide the fact that a tracepoint is placed in a location that can be called when RCU is not watching. Commit 9764e731ef6ab ("tracepoint: Add lockdep rcu_is_watching() check to trace_##name##_enabled()") added a check to the trace_##event##_enabled() macro to make sure RCU is watching when it is called to make sure not to hide the bug of a tracepoint being called when RCU is not watching. There is one case in the irq_disable tracepoint where it is within a trace_irq_disable_enabled() block, but it checks if RCU is watching, and if it isn't, it makes a call to ct_irq_enter() that makes RCU watch again. But because trace_irq_disable_enabled() now checks if RCU is watching and will trigger if it isn't. This is a false warning as the code within the block handles this case. Add a new internal macro __trace_##event##_enabled() that doesn't check if RCU is watching, and convert the irq_enable/disable tracepoints over to it. Link: https://patch.msgid.link/20260701132744.6a7fc68b@robin Reported-by: Geert Uytterhoeven <geert@linux-m68k.org> Closes: https://lore.kernel.org/all/CAMuHMdXud_RpWag_hFqa2ByBGRxg6KnxGL1ObCWZrpTsk3TfAw@mail.gmail.com/ Fixes: 9764e731ef6ab ("tracepoint: Add lockdep rcu_is_watching() check to trace_##name##_enabled()") Tested-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
2026-07-07tracing: Prevent out-of-bounds read in glob matchingHuihui Huang
String event fields are not necessarily NUL-terminated, so the filter predicate functions (filter_pred_string(), filter_pred_strloc() and filter_pred_strrelloc()) pass the field length to the regex match callbacks, and the length-aware matchers honour it. regex_match_glob() was the exception: it ignored the length and called glob_match(), which scans the string until it hits a NUL byte. Some string fields are not NUL-terminated. One example is the dynamic char array of the xfs_* namespace tracepoints, which is copied without a trailing NUL. For such a field, glob matching reads past the end of the event field, causing a KASAN slab-out-of-bounds read in glob_match(), reached via regex_match_glob() and filter_match_preds() from the xfs_lookup tracepoint. Add a length-bounded glob_match_len() and use it from regex_match_glob() so glob matching always stops at the field boundary. The matching loop is factored into a shared helper so glob_match() keeps its behaviour. Fixes: 60f1d5e3bac4 ("ftrace: Support full glob matching") Cc: stable@vger.kernel.org Link: https://patch.msgid.link/da1aaf125fc3b63320b0c540fd6afa7c3d5b4f1a.1782836943.git.hhhuang@smu.edu.sg Reported-by: Yuan Tan <yuantan098@gmail.com> Reported-by: Yifan Wu <yifanwucs@gmail.com> Reported-by: Juefei Pu <tomapufckgml@gmail.com> Reported-by: Zhengchuan Liang <zcliangcn@gmail.com> Reported-by: Xin Liu <bird@lzu.edu.cn> Assisted-by: Codex:GPT-5.4 Signed-off-by: Huihui Huang <hhhuang@smu.edu.sg> Signed-off-by: Ren Wei <n05ec@lzu.edu.cn> Acked-by: Masami Hiramatsu (Google) <mhiramat@kernel.org> Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
2026-07-07ufs: core: tracing: Do not dereference pointers in TP_printk()Steven Rostedt
The trace events in drivers/ufs/core/ufs_trace.h were converted to take a pointer to the hba structure as an argument for the tracepoint and then in TP_printk() the printing of the dev_name from the ring buffer was converted to using the dev dereferenced pointer from the hba saved pointer. This is not allowed as the TP_printk() is executed at the time the trace event is read from /sys/kernel/tracing/trace file. That can happen literally, seconds, minutes, hours, weeks, days, or even months later! There is no guarantee that the hba pointer will still exist by the time it is dereferenced when the "trace" file is read. Instead, save the device name from the hba pointer at the time the tracepoint is called and place it into the ring buffer event. Then the TP_printk() can read the name directly from the ring buffer and remove the possibility that it will read a freed pointer and crash the kernel. This was detected when testing the trace event code that looks for TP_printk() parameters doing illegal derferences[1] [1] https://lore.kernel.org/all/20260630184836.74d477b6@gandalf.local.home/ Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260630185412.283c26c5@gandalf.local.home Fixes: 583e518e71003 ("scsi: ufs: core: Add hba parameter to trace events") Reviewed-by: Peter Wang <peter.wang@mediatek.com> Reviewed-by: Bart Van Assche <bvanassche@acm.org> Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
2026-07-07tracing: Fix NULL pointer dereference in func_set_flag()Yuanhe Shu
func_set_flag() dereferences tr->current_trace_flags before verifying that the current tracer is actually the function tracer. When the active tracer has been switched away from "function" (e.g., to "wakeup_rt"), tr->current_trace_flags can be NULL, leading to a NULL pointer dereference and kernel crash. The call chain that triggers this is: trace_options_write() -> __set_tracer_option() -> trace->set_flag() /* func_set_flag */ In func_set_flag(), the first operation is: if (!!set == !!(tr->current_trace_flags->val & bit)) This dereferences tr->current_trace_flags unconditionally. The safety check that guards against a non-function tracer: if (tr->current_trace != &function_trace) return 0; is placed *after* the dereference, which is too late. This was observed with the following crash dump: BUG: unable to handle page fault at 0000000000000000 RIP: func_set_flag+0xd Call Trace: __set_tracer_option+0x27 trace_options_write+0x75 vfs_write+0x12a ksys_write+0x66 do_syscall_64+0x5b RIP: ffffffff914c973d RSP: ff67ec88b01dfdf0 RFLAGS: 00010202 RAX: 0000000000000000 RBX: ff3a826e80354580 RCX: 0000000000000001 RDX: 0000000000000001 RSI: 0000000000000000 RDI: ffffffff93918080 The disassembly confirms the fault: func_set_flag+0: mov 0x1f08(%rdi), %rax ; RAX = tr->current_trace_flags = NULL func_set_flag+13: mov (%rax), %eax ; page fault: dereference NULL At the time of the crash: tr->current_trace_flags = 0x0 (NULL) tr->current_trace = wakeup_rt_tracer (not function_trace) The scenario is that a process opens a function tracer option file (such as "func_stack_trace"), then the current tracer is switched to another tracer (e.g., "wakeup_rt"), which sets current_trace_flags to NULL. When the process subsequently writes to the option file, func_set_flag() is invoked and crashes on the NULL dereference. Fix this by moving the current_trace check before the current_trace_flags dereference, so that func_set_flag() returns early when the function tracer is not active. Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260624061715.1445655-1-xiangzao@linux.alibaba.com Fixes: 76680d0d2825 ("tracing: Have function tracer define options per instance") Signed-off-by: Yuanhe Shu <xiangzao@linux.alibaba.com> Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
generated by cgit v1.2.3 (git 2.39.1) at 2026-09-08 09:22:14 +0000