summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2026-08-13tools/mm: prevent page_owner_sort from truncating inputWarren Xiong1-2/+8
page_owner_sort opens the output file with "w" before reading the input. If both paths refer to the same file, this truncates the input and the tool silently processes zero records before returning success. Delay opening the output file until all input records have been loaded into memory. This allows the tool to sort a file in place without truncating data before it has been consumed. Link: https://lore.kernel.org/20260730015809.3819606-1-warren.xiong@ugreen.com Signed-off-by: Warren Xiong <warren.xiong@ugreen.com> Reviewed-by: Andrew Morton <akpm@linux-foundation.org> Cc: Vishal Moola <vishal.moola@gmail.com> Cc: Ye Liu <ye.liu@linux.dev> Cc: Zhen Ni <zhen.ni@easystack.cn> Cc: Zi Yan <ziy@nvidia.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2026-08-13hung_task: update DETECT_HUNG_TASK_BLOCKER Kconfig helpXibo Wang1-4/+4
The help text still says the feature only covers mutexes, but blocker tracking has since been extended to semaphores and rwsems. Update the description to match the supported lock types. Link: https://lore.kernel.org/20260730061854.176547-1-wangxb12@chinatelecom.cn Cc: Petr Mladek <pmladek@suse.com> Signed-off-by: Xibo Wang <wangxb12@chinatelecom.cn> Suggested-by: Lance Yang <lance.yang@linux.dev> Reviewed-by: Lance Yang <lance.yang@linux.dev> Cc: "Masami Hiramatsu (Google)" <mhiramat@kernel.org> Cc: Petr Mladek <pmladek@suse.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2026-08-13taskstats: fold the two cpumask handlers into oneBradley Morgan1-26/+12
cmd_attr_register_cpumask() and cmd_attr_deregister_cpumask() differed only in which attribute they parsed and which action they passed on, so take both as arguments. __free(free_cpumask_var) then removes the goto. No functional change. Link: https://lore.kernel.org/20260728202104.17839-3-include@grrlz.net Signed-off-by: Bradley Morgan <include@grrlz.net> Cc: Balbir Singh <bsingharora@gmail.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2026-08-13taskstats: drop the dead NULL attribute check in parse()Bradley Morgan1-2/+0
Patch series "taskstats: tidy up the cpumask command path". Two small cleanups from reading kernel/taskstats.c. No functional change in either one. This patch (of 2): taskstats_user_cmd() only calls the cpumask handlers after checking the same info->attrs[] entry, so parse() never sees a NULL attribute. Drop the check and its odd "return 1", which no caller tested for anyway. No functional change. Link: https://lore.kernel.org/20260728202104.17839-1-include@grrlz.net Link: https://lore.kernel.org/20260728202104.17839-2-include@grrlz.net Signed-off-by: Bradley Morgan <include@grrlz.net> Cc: Balbir Singh <bsingharora@gmail.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2026-08-13lib/xz: fix commentsLasse Collin1-6/+6
Link: https://lore.kernel.org/20260614160521.924710-2-lasse.collin@tukaani.org Signed-off-by: Lasse Collin <lasse.collin@tukaani.org> Cc: David Laight <david.laight.linux@gmail.com> Cc: Nathan Chancellor <nathan@kernel.org> Cc: Thorsten Blum <thorsten.blum@linux.dev> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2026-08-13lib/xz: use size_t instead of uint32_t in a few placesLasse Collin2-21/+21
Reduce the number of uint32_t <-> size_t conversions a little. Eliminating such conversions entirely would require changing almost all uint32_t to size_t, which would look confusing and increase the sizes of the structs even more. Going the other way, converting everything to uint32_t, isn't possible because the input and output buffers use size_t in struct xz_buf. Now both arguments to min() have the same type. This is required to for compatibility with PowerPC boot code[1] whose min() is strict like include/linux/minmax.h was before the commit d03eba99f5bf ("minmax: allow min()/max()/clamp() if the arguments have the same signedness."). Swap the order of the "state" and "len" in struct lzma_dec to avoid padding in the middle of the struct when size_t is 64 bits. The reordering doesn't change the size of the struct; the padding just appears at the end instead. dict_flush() used to truncate size_t to uint32_t when returning. This wasn't a bug; the value is always small enough. Link: https://lore.kernel.org/20260614160521.924710-1-lasse.collin@tukaani.org Signed-off-by: Lasse Collin <lasse.collin@tukaani.org> Reported-by: Nathan Chancellor <nathan@kernel.org> Closes: https://lore.kernel.org/lkml/20260610232323.GA1071374@ax162/ [1] Reviewed-by: Thorsten Blum <thorsten.blum@linux.dev> Cc: David Laight <david.laight.linux@gmail.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2026-08-13ipc: only destroy orphaned shm segments on sysctl writeJianlin Shi1-1/+1
proc_ipc_dointvec_minmax_orphans() currently calls shm_destroy_orphaned() whenever shm_rmid_forced is set, including on sysctl reads. Reading /proc/sys/kernel/shm_rmid_forced should not take shm_ids rwsem for write and walk all segments. Only run the cleanup when the sysctl is written and the forced RMID policy is enabled. When shm_rmid_forced=1, monitoring tools that read /proc/sys/kernel/shm_rmid_forced trigger the cleanup on every read. Link: https://lore.kernel.org/all/?q=only+destroy+orphaned+shm+segments+on+sysctl+write Link: https://lore.kernel.org/tencent_738A8BC6E9EA205F555E4B0DAA154D4F8E0A@qq.com Signed-off-by: Jianlin Shi <shijianlin11@foxmail.com> Acked-by: Davidlohr Bueso <dave@stgolabs.net> Cc: "Eric W. Biederman" <ebiederm@xmission.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2026-08-13lib/xz: replace min_t with minThorsten Blum3-9/+8
Use the simpler min() macro since the values are unsigned and compatible. Link: https://lore.kernel.org/20260609150030.634570-1-lasse.collin@tukaani.org Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev> Signed-off-by: Lasse Collin <lasse.collin@tukaani.org> Reviewed-by: Lasse Collin <lasse.collin@tukaani.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2026-08-13bpftool: Fix double close in map dumpYuan Chen1-3/+1
map_dump() closes the map fd in its error path, and do_dump() then closes the same fd again after a successful dump. Closing an already closed fd leaves errno set to EBADF, which poisons later errno checks such as the batch file read check in do_batch(). Let do_dump() own the fd and remove the close from map_dump(). The same double-close pattern exists in do_show_subset(): both show_map_close_json() and show_map_close_plain() already close the fd, so drop the extra close() there as well. Also propagate the error when bpf_map_get_info_by_fd() fails on a subsequent map in do_dump(): set err = -1 before breaking out of the loop, so a later failure is not silently hidden after an earlier iteration succeeded. Fixes: 99f9863a0c45f ("bpftool: Match maps by name") Signed-off-by: Yuan Chen <chenyuan@kylinos.cn> Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Link: https://lore.kernel.org/bpf/20260810142224.2907373-2-chenyuan_fl@163.com
2026-08-13bpf: Fix func_info_aux desync after dead code eliminationKumar Kartikeya Dwivedi1-1/+5
The verifier keeps per-subprogram metadata in three parallel arrays: subprog_info, func_info, and func_info_aux. Dead code elimination can remove whole subprograms, and adjust_subprog_starts_after_remove() shifts subprog_info and func_info to close the gap, but leaves func_info_aux in place. From that point on, func_info_aux[i] no longer describes subprogram i. Shift func_info_aux together with func_info so the three arrays stay aligned after subprogram removal. Reported-by: Sashiko <sashiko-bot@kernel.org> Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com> Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Link: https://lore.kernel.org/bpf/20260808064523.DE3E71F000E9@smtp.kernel.org Link: https://lore.kernel.org/bpf/20260812231506.3558128-1-memxor@gmail.com
2026-08-13tracing: Fix race between update_event_fields and, event_define_fieldsMichael Wu1-0/+2
The following sequence may leads race between event_define_fields() and update_event_fields(): CPU0 (loads module A) CPU1 (loads module B) =============================== =============================== load_module(A) load_module(B) notifier_call_chain notifier_call_chain trace_module_notify trace_module_notify mutex_lock(&event_mutex) trace_event_update_all() trace_module_add_events(A) down_write(&trace_event_sem) __register_event(call_A) __add_event_to_tracers(call_A) event_define_fields(call_A) for each f: list_for_each_entry(field, list_add(&f->link, &class->fields, link) &class->fields) field = class->fields->next; Where access to the class->fields is not protected by the event_mutex in trace_event_update_all(). This produces the following panic: Unable to handle kernel access ... at virtual address 0000000000000018 pc : update_event_fields+0xf8/0x368 Call trace: update_event_fields+0xf8/0x368 trace_event_update_all+0x7c/0x2b4 trace_module_notify+0x4c/0x1dc notifier_call_chain+0x84/0x168 blocking_notifier_call_chain_robust+0x64/0xd4 load_module+0x10c8/0x123c __arm64_sys_finit_module+0x230/0x31c Fix by taking event_mutex in trace_event_update_all() before trace_event_sem. Cc: stable@vger.kernel.org Fixes: b3bc8547d3be ("tracing: Have TRACE_DEFINE_ENUM affect trace event types as well") Link: https://patch.msgid.link/2e5730d2-c631-da41-3a3a-ae35bb4895f3@allwinnertech.com Signed-off-by: Michael Wu <michael@allwinnertech.com> Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
2026-08-13tracing: Fix NULL pointer dereference in module event cache removalHui Su1-1/+1
A module-only event filter such as ":mod:foo" is cached with a NULL event_mod->match when foo has not been loaded. If a later write tries to remove a specific match from the same module, remove_cache_mod() passes the NULL cached match to strcmp(), causing a NULL pointer dereference. The issue can be reproduced from userspace: echo ':mod:trace_events_kunit_missing' > /sys/kernel/tracing/set_event echo '!foo_bar:mod:trace_events_kunit_missing' >> /sys/kernel/tracing/set_event The second write must be a concatenation (">>") to not include O_TRUNC as that would cause ftrace_clear_events() to clear the cached modules lines. The crash was reproduced on x86_64 QEMU while KUnit workers contended on the event tracing path: BUG: kernel NULL pointer dereference, address: 0000000000000000 #PF: supervisor read access in kernel mode RIP: 0010:strcmp+0x10/0x30 Call Trace: __ftrace_set_clr_event_nolock+0x373/0x4a0 ftrace_set_clr_event+0xf0/0x180 ftrace_event_write+0xdf/0x110 vfs_write+0xf6/0x440 ksys_write+0x68/0xe0 do_syscall_64+0xf9/0x540 entry_SYSCALL_64_after_hwframe+0x77/0x7f Check event_mod->match before comparing it, consistent with the existing NULL checks for the cached system and event fields. The mismatched removal continues to return -EINVAL; a broad cached module filter is removed with "!:mod:<module>". Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260811173902.1927376-2-sh_def@163.com Fixes: b355247df104 ("tracing: Cache \":mod:\" events for modules not loaded yet") Reported-by: syzbot+4d3143c8e28f6266c636@syzkaller.appspotmail.com Closes: https://lore.kernel.org/lkml/6a7a6b7f.9c11d2ce.289b96.00f8.GAE@google.com/ Signed-off-by: Hui Su <sh_def@163.com> Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
2026-08-13Input: rmi4 - use platform data instead of query, when availableDavid Heidelberg1-4/+12
Platform data may define touchscreen-x-mm and touchscreen-y-mm, but these were quietly overridden by data provided by sensor. Signed-off-by: David Heidelberg <david@ixit.cz> Link: https://patch.msgid.link/20260731-respect-x-y-mm-v1-0-3e85a4bec745@ixit.cz Link: https://patch.msgid.link/20260806-respect-x-y-mm-v2-1-e0681ed3d63c@ixit.cz Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2026-08-13ASoC: tas2781: Refactor calibration start kcontrol creation to separate helperShenghao Ding1-30/+41
Move the tas2781-specific calibration start kcontrol initialization logic out of tasdevice_create_cali_ctrls() into a new dedicated helper function create_tas2781_cali_start_ktrl(). This change eliminates duplicate inline code in the main calibration control registration routine, improves code readability, and makes further extension for custom calibration parameters much easier. No functional behavior changes. Signed-off-by: Shenghao Ding <shenghao-ding@ti.com> Link: https://patch.msgid.link/20260813080540.1030-1-shenghao-ding@ti.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-08-13Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/netJakub Kicinski306-1479/+4304
Cross-merge networking fixes after downstream PR (net-7.2-rc8). No conflicts. Adjacent changes: drivers/net/ethernet/wangxun/ngbe/ngbe_main.c 5f3a13e0bb5e ("net: ngbe: fix NULL pointer dereference in non-MSI-X interrupt enabling") d661abdc30c2 ("net: ngbe: correct misleading interrupt comment") drivers/net/ipvlan/ipvlan_main.c e16e960d55a4 ("ipvlan: inherit needed_headroom and needed_tailroom from phy_dev") 00a40d809207 ("ipvlan: Support per-netns netdev unregistration.") Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-08-13vfio/pci: Remove the pcie check for VFIO_PCI_ERR_IRQ_INDEXFarhan Ali2-8/+3
The error signaling is configured for the vast majority of devices and it's extremely rare that it fires anyway. Removing the pcie check will allow userspace to be notified on errors for legacy PCI devices. The Internal Shared Memory (ISM) device on s390 is one such device. For PCI devices on IBM s390 error recovery involves platform firmware and notification to operating system is done by architecture specific way. So the ISM device can still be recovered when notified of an error. Reviewed-by: Julian Ruess <julianr@linux.ibm.com> Reviewed-by: Niklas Schnelle <schnelle@linux.ibm.com> Reviewed-by: Alex Williamson <alex@shazbot.org> Signed-off-by: Farhan Ali <alifm@linux.ibm.com> Link: https://lore.kernel.org/r/20260630165553.725-4-alifm@linux.ibm.com Signed-off-by: Alex Williamson <alex@shazbot.org>
2026-08-13vfio-pci/zdev: Add a device feature for error informationFarhan Ali7-2/+97
For zPCI devices, we have platform specific error information. The platform firmware provides this error information to the operating system in an architecture specific mechanism. To enable recovery from userspace for these devices, we want to expose this error information to userspace. Add a new device feature to expose this information. Userspace needs to be provide a buffer of fixed size. This size is provided to userspace via the VFIO_DEVICE_INFO_CAP_ZPCI_BASE capability. Reviewed-by: Matthew Rosato <mjrosato@linux.ibm.com> Reviewed-by: Niklas Schnelle <schnelle@linux.ibm.com> Signed-off-by: Farhan Ali <alifm@linux.ibm.com> Link: https://lore.kernel.org/r/20260630165553.725-3-alifm@linux.ibm.com Signed-off-by: Alex Williamson <alex@shazbot.org>
2026-08-13iommufd: Fix UAF in selftest IOPF reportingPeiyang He1-1/+30
IOMMUFD selftest TRIGGER_IOPF borrows an attach handle from group->pasid_array without synchronizing against PASID detach, then a concurrent iommu_report_device_fault() can dereference that borrowed handle's domain pointer after the detach erases the handle and frees the backing struct iommufd_attach_handle. TRIGGER_IOPF then dereferences the freed handle, causing a UAF. Fix by adding a iopf_rwsem in mock_dev to follow the expected design of a real driver. Hold its read side across the whole iommu_report_device_fault() call, and its write side around every path that attaches, detaches, or replaces a device domain. This can block new reports and drains in-flight reports before an old attach handle or the IOPF fault parameter can be removed. Also take the write side while registering a mock device, since it can invoke the mock driver's default-domain attach callback. Closes: https://lore.kernel.org/all/D5E3AA41600B2056+f4e15662-bd2b-43ea-91cb-518de429e72c@smail.nju.edu.cn/ Fixes: ddee19971081 ("iommufd/selftest: Add IOPF support for mock device") Cc: stable@vger.kernel.org Suggested-by: Jason Gunthorpe <jgg@ziepe.ca> Assisted-by: Codex:gpt-5.6-terra Signed-off-by: Peiyang He <peiyang_he@smail.nju.edu.cn> Link: https://patch.msgid.link/38C8DF0A118B7176+20260811095551.2756745-1-peiyang_he@smail.nju.edu.cn Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
2026-08-13Merge branch 'bpf-introduce-global-percpu-data'Andrii Nakryiko22-95/+725
Leon Hwang says: ==================== bpf: Introduce global percpu data This patch set introduces global percpu data, similar to commit 6316f78306c1 ("Merge branch 'support-global-data'"), to reduce restrictions in C for BPF programs. With this enhancement, it becomes possible to define and use global percpu variables, like the DEFINE_PER_CPU() macro in the kernel include/linux/percpu-defs.h. The section name for global peurcpu data is ".percpu". Even though, a one-byte percpu variable (e.g., char run SEC(".percpu") = 0;) can trigger a crash with Clang 17 [1], users are expected to use such small variables as global percpu data with newer Clang versions, which don't have the issue. The idea stems from the bpfsnoop [2], which itself was inspired by retsnoop [3]. During testing of bpfsnoop on the v6.6 kernel, two LBR (Last Branch Record) entries were observed related to the bpf_get_smp_processor_id() helper. Since commit 1ae6921009e5 ("bpf: inline bpf_get_smp_processor_id() helper"), the bpf_get_smp_processor_id() helper has been inlined on x86_64, reducing the overhead and consequently minimizing these two LBR records. However, the introduction of global percpu data offers a more robust solution. By leveraging the percpu_array map and percpu instruction, global percpu data can be implemented intrinsically. This feature also facilitates sharing percpu information between tail callers and callees or between freplace callers and callees through a shared global percpu variable. Previously, this was achieved using a 1-entry percpu_array map, which this patch set aims to improve upon. Links: [1] https://lore.kernel.org/bpf/fd1b3f58-c27f-403d-ad99-644b7d06ecb3@linux.dev/ [2] https://github.com/bpfsnoop/bpfsnoop [3] https://github.com/anakryiko/retsnoop Changes: v11 -> v12: * Improve feature check in bpf_object__create_maps() in libbpf. * Add percpu_array map support in bpf_map__set_value_size() in libbpf. * Exercise bpf_map__set_value_size() in selftest. * Drop dead warning in bpf_object__populate_internal_map() in libbpf. (Sashiko) * v11: https://lore.kernel.org/bpf/20260806163125.11172-1-leon.hwang@linux.dev/ v10 -> v11: * Drop env->prog->jit_requested check when inlining insns for global percpu data. * Do not autocreate percpu_array map when kernel does not have global percpu data support in libbpf. * Check map->btf_value_type_id in bpftool's is_skel_data(). * Exercise bpf_map__lookup_elem() in selftest. * Collect Reviewed-by tags from Emil, thanks. * Drop all duplicate blank lines in kernel/bpf/*.c. (Emil) * Factor out check_map_mem_read() helper. (Emil) * Check bpf_jit_supports_percpu_insn() first in percpu_array_map_direct_value_addr/meta(). (Emil) * Add comment for 'map->libbpf_type == LIBBPF_MAP_PERCPU' in libbpf's map_is_mmapable(). (Emil) * Init update_flags as a const var in libbpf's bpf_object__populate_internal_map(). (Emil) * Keep is_mmapable_map() beyond is_skel_data() in bpftool. (Emil) * Add 'run' and 'cpu_id' in selftest. (Emil) * Drop subskel test. Verify the generated subskel manually. (Emil) * Add comment to the raw insns in selftest. (Emil) * v10: https://lore.kernel.org/bpf/20260715153254.92010-1-leon.hwang@linux.dev/ v9 -> v10: * Rebase latest bpf-next tree to resolve code conflict in verifier in patch #1. * v9: https://lore.kernel.org/bpf/20260713154024.30851-1-leon.hwang@linux.dev/ v8 -> v9: * Use real name for percpu data maps in libbpf in patch #4. * Add long map name test in patch #6. * Move parse_cpu_mask_file() to test_percpu_data_on_cpus() in test in patch #6. * Validate map type in get_map_ident() for percpu data maps in patch #5. * Update code comment in verifier in patch #2. (per Andrii) * Pass 'type' to internal_map_name in libbpf in patch #4. (per Andrii) * Factor out the helper is_skel_data() in bpftool in patch #5. (per Quentin and Andrii) * v8: https://lore.kernel.org/bpf/20260629152406.52582-1-leon.hwang@linux.dev/ v7 -> v8: * Send patch #1 and #2 separately that fix interpreter fallback issues. (Andrii) * Use 'array->elem_size' to avoid 'range' local variable in percpu_array_map_direct_value_meta(). (Andrii) * Keep original map name for percpu data's map in libbpf. (Andrii) * Factor out helper bpf_map_is_skel_data() in bpftool. (Andrii) * Update commit message of direct access read-only percpu_array map. (Andrii) * Add test to verify that it is disallowed to directly write data of read-only percpu_array map. (Andrii) * Drop unused 'num_cpus' in test. (bot+bpf-ci) * Factor out helper test_percpu_data_on_cpus() in test. (bot+bpf-ci) * v7: https://lore.kernel.org/bpf/20260622143557.22955-1-leon.hwang@linux.dev/ v6 -> v7: * Use tgt_endian() in bpf_gen__map_update_elem() in patch #6. (Sashiko) * Use sizeof(args) in verifier_snprintf test in patch #10. (Sashiko) * Drop xlated test of v6. (Alexei) * v6: https://lore.kernel.org/bpf/20260615152646.27639-1-leon.hwang@linux.dev/ v5 -> v6: * Prevent running user addr_space_cast and addr_percpu insns in interpreter. (Sashiko) * Cast __percpu pointer to u64 with (__force unsigned long). (lkp) * Exclude BPF_MAP_TYPE_PERCPU_ARRAY in check_mem_access() before calling bpf_map_direct_read(), and add a test to verify it. (Sashiko, bot+bpf-ci) * Skip percpu data variables for subskeleton in bpftool. (Sashiko) * Protect skel->percpu using mprotect(..., PROT_READ) in light skeleton. (Sashiko, bot+bpf-ci) * Drop roundup() in tests. (Sashiko) * Call test_global_percpu_data_verifier_log() without test__start_subtest(). (Sashiko) * Cast insn->imm to __u64 with (__u32) in xlated test. (Sashiko) * Check cnt using the new idx in xlated test. (Sashiko) * v5: https://lore.kernel.org/bpf/20260608145113.65857-1-leon.hwang@linux.dev/ v4 -> v5: * Add prog->jit_requested check to prevent running percpu data in interpreter in patch #1. * Factor out verifier log tests using its own patch. * Address comments from Alexei: * Move map_type check from check_mem_access() to bpf_map_direct_read() in patch #2. * Move BPF_MAP_TYPE_INSN_ARRAY map_type check from const_reg_xfer() to bpf_map_direct_read() in patch #2. * Add a test to verify that the off of xlated ldimm64 insn matches the off encoded in the ELF ldimm64 insn. * Drop patch #5 of v4. * Address reviews from Sashiko: * Update commit message of patch #6 to indicate that maps.percpu->mmaped has been marked as read-only in libbpf. * Lookup elem on specified CPU using BPF_F_CPU in tests. * Drop unnecessary err == -EOPNOTSUPP in test. * Locate target field using its offset in the iter test. * v4: https://lore.kernel.org/bpf/20260414132421.63409-1-leon.hwang@linux.dev/ v3 -> v4: * Drop duplicate blank lines in verifier. * Add percpu data feature probe in libbpf. * Update percpu_array map using BPF_F_ALL_CPUS flag for lskel, if no cpu flag is set. * Add two tests to verify verifier log. * Add a test to verify mov64_percpu_reg instruction. * Add a test to verify bpf_iter for percpu data map. * Update percpu_array map using BPF_F_ALL_CPUS flag in libbpf (per Alexei and Andrii). * Address comments from Andrii: * Use .percpu as section identifier. * Use bpf_jit_supports_percpu_insn() instead of CONFIG_SMP. * Drop bpf_map__is_internal_percpu() API. * Drop unnecessary __aligned(8) in libbpf, verified by selftest. * Make mmap data read-only after loading prog. v3: https://lore.kernel.org/bpf/20250526162146.24429-1-leon.hwang@linux.dev/ v2 -> v3: * Use ".data..percpu" as PERCPU_DATA_SEC. * Address comment from Alexei: * Add u8, array of ints and struct { .. } vars to selftest. v2: https://lore.kernel.org/bpf/20250213161931.46399-1-leon.hwang@linux.dev/ v1 -> v2: * Address comments from Andrii: * Use LIBBPF_MAP_PERCPU and SEC_PERCPU. * Reuse mmaped of libbpf's struct bpf_map for .percpu map data. * Set .percpu struct pointer to NULL after loading skeleton. * Make sure value size of .percpu map is __aligned(8). * Use raw_tp and opts.cpu to test global percpu variables on all CPUs. * Address comments from Alexei: * Test non-zero offset of global percpu variable. * Test case about BPF_PSEUDO_MAP_IDX_VALUE. v1: https://lore.kernel.org/bpf/20250127162158.84906-1-leon.hwang@linux.dev/ rfc -> v1: * Address comments from Andrii: * Keep one image of global percpu variable for all CPUs. * Reject non-ARRAY map in bpf_map_direct_read(), check_reg_const_str(), and check_bpf_snprintf_call() in verifier. * Split out libbpf changes from kernel-side changes. * Use ".percpu" as PERCPU_DATA_SEC. * Use enum libbpf_map_type to distinguish BSS, DATA, RODATA and PERCPU_DATA. * Avoid using errno for checking err from libbpf_num_possible_cpus(). * Use "map '%s': " prefix for error message. rfc: https://lore.kernel.org/bpf/20250113152437.67196-1-leon.hwang@linux.dev/ ==================== Link: https://patch.msgid.link/20260813152324.97937-1-leon.hwang@linux.dev Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
2026-08-13selftests/bpf: Verify bpf_iter for global percpu dataLeon Hwang2-0/+77
Add a test to verify that it is OK to iter the percpu_array map used for global percpu data. Signed-off-by: Leon Hwang <leon.hwang@linux.dev> Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Reviewed-by: Emil Tsalapatis <emil@etsalapatis.com> Link: https://lore.kernel.org/bpf/20260813152324.97937-11-leon.hwang@linux.dev
2026-08-13selftests/bpf: Test verifier log for global percpu dataLeon Hwang2-0/+29
Add two tests to verify the verifier log "R%d points to percpu_array map which cannot be used as const string\n". Signed-off-by: Leon Hwang <leon.hwang@linux.dev> Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Reviewed-by: Emil Tsalapatis <emil@etsalapatis.com> Link: https://lore.kernel.org/bpf/20260813152324.97937-10-leon.hwang@linux.dev
2026-08-13selftests/bpf: Test direct reading/writing read-only percpu_array mapLeon Hwang1-0/+90
Verify these two cases: 1. Direct reading the data of read-only percpu data's percpu_array map is allowed. 2. Direct writing the data of read-only percpu data's percpu_array map is disallowed. Assisted-by: Codex:gpt-5.5-xhigh Signed-off-by: Leon Hwang <leon.hwang@linux.dev> Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Link: https://lore.kernel.org/bpf/20260813152324.97937-9-leon.hwang@linux.dev
2026-08-13selftests/bpf: Add tests to verify global percpu dataLeon Hwang3-1/+230
If the arch, like s390x, does not support percpu insn, these cases won't test global percpu data by checking FEAT_PERCPU_DATA support. The following APIs have been tested for global percpu data: 1. bpf_map__set_initial_value() 2. bpf_map__initial_value() 3. bpf_map__set_value_size() 4. generated percpu struct pointer pointing to internal map's mmaped data 5. bpf_map__lookup_elem() for global percpu data map 6. bpf_map_lookup_elem_flags() for global percpu data map At the same time, the case is also tested with 'bpftool gen skeleton -L'. Assisted-by: Codex:gpt-5.5-xhigh Signed-off-by: Leon Hwang <leon.hwang@linux.dev> Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Link: https://lore.kernel.org/bpf/20260813152324.97937-8-leon.hwang@linux.dev
2026-08-13bpftool: Generate skeleton for global percpu dataLeon Hwang2-14/+63
Enhance bpftool to generate skeletons that properly handle global percpu variables. The generated skeleton now includes a dedicated structure for percpu data, allowing users to initialize and access percpu variables more efficiently. For global percpu variables, the skeleton now includes a nested structure, e.g.: struct test_global_percpu_data { struct bpf_object_skeleton *skeleton; struct bpf_object *obj; struct { struct bpf_map *percpu; } maps; // ... struct test_global_percpu_data__percpu { int data; char run; struct { char set; int i; int nums[7]; } struct_data; int nums[7]; } *percpu; // ... }; * The "struct test_global_percpu_data__percpu *percpu" points to initialized data, which is actually "maps.percpu->mmaped". * Before loading the skeleton, updating the "struct test_global_percpu_data__percpu *percpu" modifies the initial value of the corresponding global percpu variables. * After loading the skeleton, "maps.percpu->mmaped" has been marked as read-only in libbpf. If users want to update the global percpu variables, they have to update the "maps.percpu" map instead. * For lightweight skeleton, "lskel->percpu" will be protected by "mprotect(p, sz, PROT_READ)". * For subskeleton, those variables of global percpu data will be skipped. Assisted-by: Codex:gpt-5.5-xhigh Signed-off-by: Leon Hwang <leon.hwang@linux.dev> Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Acked-by: Quentin Monnet <qmo@kernel.org> Link: https://lore.kernel.org/bpf/20260813152324.97937-7-leon.hwang@linux.dev
2026-08-13libbpf: Add support for global percpu dataLeon Hwang3-15/+72
Add support for global percpu data in libbpf by adding a new ".percpu" section, similar to ".data". It enables efficient handling of percpu global variables in bpf programs. When generating loader for lightweight skeleton, update the percpu_array map used for global percpu data using BPF_F_ALL_CPUS, in order to update values across all CPUs using one value slot. Unlike global data, the mmaped data for global percpu data will be marked as read-only after populating the percpu_array map. Thereafter, users can read those initialized percpu data after loading prog. If they want to update the percpu data after loading prog, they have to update the percpu_array map using key=0 instead. Signed-off-by: Leon Hwang <leon.hwang@linux.dev> Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Link: https://lore.kernel.org/bpf/20260813152324.97937-6-leon.hwang@linux.dev
2026-08-13libbpf: Probe percpu data featureLeon Hwang2-0/+37
libbpf needs a reliable way to distinguish kernels that can support global percpu data from those that cannot. Add a dedicated feature probe, so libbpf can make capability decisions early and fail predictably when global percpu data is unavailable. Signed-off-by: Leon Hwang <leon.hwang@linux.dev> Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Reviewed-by: Emil Tsalapatis <emil@etsalapatis.com> Acked-by: Andrii Nakryiko <andrii@kernel.org> Link: https://lore.kernel.org/bpf/20260813152324.97937-5-leon.hwang@linux.dev
2026-08-13bpf: Introduce global percpu dataLeon Hwang4-3/+84
Introduce global percpu data, inspired by the commit 6316f78306c1 ("Merge branch 'support-global-data'"). It enables the definition of global percpu variables in BPF, similar to the include/linux/percpu-defs.h::DEFINE_PER_CPU() macro. For example, in BPF, it is able to define a global percpu variable like: int data SEC(".percpu"); With this patch, tools like retsnoop [1] and bpfsnoop [2] can simplify their BPF code for handling LBRs. The code can be updated from static struct perf_branch_entry lbrs[1][MAX_LBR_ENTRIES] SEC(".data.lbrs"); to static struct perf_branch_entry lbrs[MAX_LBR_ENTRIES] SEC(".percpu.lbrs"); This eliminates the need to retrieve the CPU ID using the bpf_get_smp_processor_id() helper. Additionally, by reusing global percpu data map, sharing information between tail callers and callees or freplace callers and callees becomes simpler compared to reusing percpu_array maps. Links: [1] https://github.com/anakryiko/retsnoop [2] https://github.com/bpfsnoop/bpfsnoop Signed-off-by: Leon Hwang <leon.hwang@linux.dev> Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Acked-by: Eduard Zingerman <eddyz87@gmail.com> Link: https://lore.kernel.org/bpf/20260813152324.97937-4-leon.hwang@linux.dev
2026-08-13bpf: Factor out check_map_mem_read helper in verifierLeon Hwang1-32/+43
In the next commit, percpu_array map will add map_direct_value_addr support. IOW, it will add a map_type check in the iff condition of the bpf_map_direct_read() code block, which will reduce the code block readability. Hence, factor out check_map_mem_read helper to improve the readability, and the maintainability for the percpu_array map case. Signed-off-by: Leon Hwang <leon.hwang@linux.dev> Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Acked-by: Eduard Zingerman <eddyz87@gmail.com> Link: https://lore.kernel.org/bpf/20260813152324.97937-3-leon.hwang@linux.dev
2026-08-13bpf: Drop duplicate blank lines in kernel/bpf/Leon Hwang10-30/+0
There are many adjacent blank lines in kernel/bpf/ that have accumulated over time. Drop them for cleanup. No functional changes intended. Signed-off-by: Leon Hwang <leon.hwang@linux.dev> Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Reviewed-by: Emil Tsalapatis <emil@etsalapatis.com> Link: https://lore.kernel.org/bpf/20260813152324.97937-2-leon.hwang@linux.dev
2026-08-13x86/pkeys: Fix pkey_alloc() return value when pkeys are not supportedBijan Tabatabai1-0/+3
The man page for pkey_alloc(2) specifies that it should return -1 with the errno set to ENOSPC when pkeys are not supported [1]. However, on x86 pkey_alloc() sets errno to EINVAL when called for the first time on a CPU that does not support pkeys. The root cause of this is the x86 implementation of mm_pkey_alloc() not directly checking if pkeys are supported. It only checks if all the pkeys have been allocated by comparing the allocation map against all_pkeys_mask. When OSPKE is not enabled, init_new_context() skips the initialization of the allocation map, leaving it as 0, while all_pkeys_mask is 1. mm_pkey_alloc() interprets this as there being a pkey available and it returns pkey 0. Then, pkey_alloc() fails with -EINVAL from arch_set_user_pkey_access() instead of returning -ENOSPC. Subsequent calls to pkey_alloc() do return -ENOSPC because pkey 0 is left marked as allocated. Change mm_pkey_alloc() to directly check if OSPKE is enabled, and return -1 if it is not, which causes pkey_alloc() to return -ENOSPC. The arm64 and powerpc implementations of mm_pkey_alloc() already do this check. [1] https://man7.org/linux/man-pages/man2/pkey_alloc.2.html [ dhansen: use arch_pkeys_enabled() to follow arm ] Fixes: e8c24d3a23a4 ("x86/pkeys: Allocation/free syscalls") Signed-off-by: Bijan Tabatabai <btabatabai@wisc.edu> Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com> Link: https://patch.msgid.link/20260716220604.26452-1-bijan311@gmail.com
2026-08-13selftests/cgroup: Preserve CPU hotplug write errorsRui Qi1-2/+3
The cpuset partition root state selftest checks several CPU hotplug transitions. If writing to a CPU online file fails, the helper still runs pause afterwards and returns the status of pause instead of the failed write. This hides the real hotplug failure and can make later checks run against expectations for a transition that never happened. Move the write before the bookkeeping and return when it fails, so callers can observe the hotplug error and the test does not record a CPU as offline unless the offline operation actually succeeded. Also change the O* command handler in set_ctrl_state() to use "eval $COMM $REDIRECT" like all other handlers. The previous version set COMM but still called write_cpu_online directly, bypassing the redirect that captures stderr for error reporting. Changes since v1: - Use eval $COMM $REDIRECT in the O* handler instead of calling write_cpu_online directly (Waiman Long) Fixes: a8c52eba880a ("kselftest/cgroup: Add cpuset v2 partition root state test") Signed-off-by: Rui Qi <qirui.001@bytedance.com> Signed-off-by: Tejun Heo <tj@kernel.org>
2026-08-13workqueue: annotate racy p->wake_cpu accesses in kick_pool_pick()Breno Leitao1-2/+3
kick_pool_pick() reads and writes p->wake_cpu while the scheduler can update it concurrently. KCSAN reports: BUG: KCSAN: data-race in kick_pool_pick+0xf8/0x2d8 race at unknown origin, with read to 0xffff000663229da4 of 4 bytes by task 1817002 on cpu 40: kick_pool_pick+0xf8/0x2d8 process_scheduled_works+0x2bc/0x888 worker_thread+0x394/0x548 kthread+0x1b8/0x1f0 ret_from_fork+0x10/0x20 value changed: 0x0000002b -> 0x0000002f The race is harmless. wake_cpu is a best-effort placement hint: every writer stores a valid CPU id and the wakeup path validates it through select_task_rq(), so a stale value only affects which CPU the worker wakes up on. Mark both accesses with READ_ONCE() and WRITE_ONCE() to document that they are intentionally racy and to stop the compiler from reloading or tearing them. Signed-off-by: Breno Leitao <leitao@debian.org> Reviewed-by: Bradley Morgan <include@grrlz.net> Signed-off-by: Tejun Heo <tj@kernel.org>
2026-08-13PCI: Fix 32-bit config write in Intel PCH Root Port MPC ACS quirkMohamad Raizudeen1-1/+1
pci_quirk_enable_intel_rp_mpc_acs() reads a 32-bit DWORD from the MPC register, sets bit 26 (INTEL_MPC_REG_IRBNCE), but it writes it back using pci_write_config_word(). Because bit 26 resides in the upper 16 bits of the 32-bit register, a 16-bit write drops the newly set bit. The quirk logs that it is enabling IRBNCE, but the hardware never actually receives the command. Use pci_write_config_dword() to ensure the full 32-bit value is written back to the hardware. Fixes: d99321b63b1f ("PCI: Enable quirks for PCIe ACS on Intel PCH root ports") Signed-off-by: Mohamad Raizudeen <raizudeen.kerneldev@gmail.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com> Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260723171203.4892-1-raizudeen.kerneldev@gmail.com
2026-08-13ASoC: dt-bindings: es8316: Fix supply property constraintsHongyang Zhao1-3/+4
The DT meta-schema requires a `then` clause when an `if` condition has an `else` clause. Invert the compatible check and move the supply property restrictions to `then` so they remain allowed only for ES8316. Fixes: e9966d450b46 ("ASoC: dt-bindings: es8316: Add regulator supplies") Reported-by: Rob Herring <robh@kernel.org> Closes: https://lore.kernel.org/r/20260812194234.GA693895-robh@kernel.org Signed-off-by: Hongyang Zhao <hongyang.zhao@thundersoft.com> Link: https://patch.msgid.link/20260813-b4-es8316-binding-conditional-fix-v1-1-6cd56aa1370c@thundersoft.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-08-13s390/pci: Store PCI error information for passthrough devicesFarhan Ali4-54/+113
For a passthrough device we need co-operation from user space to recover the device. This would require to bubble up any error information to user space. Let's store this error information for passthrough devices, so it can be retrieved later. We can now have userspace drivers (vfio-pci based) on s390x. The userspace drivers will not have any KVM fd and so no kzdev associated with them. So we need to update the logic for detecting passthrough devices to not depend on struct kvm_zdev. Reviewed-by: Matthew Rosato <mjrosato@linux.ibm.com> Reviewed-by: Niklas Schnelle <schnelle@linux.ibm.com> Signed-off-by: Farhan Ali <alifm@linux.ibm.com> Link: https://lore.kernel.org/r/20260630165553.725-2-alifm@linux.ibm.com Signed-off-by: Alex Williamson <alex@shazbot.org>
2026-08-13Merge branch 'slot' of git://git.kernel.org/pub/scm/linux/kernel/git/pci/pci ↵Alex Williamson6-22/+83
into v7.3/vfio/s390x-pci-error-recovery PCI dependencies from shared branch supporting vfio-pci error recovery on s390x. Signed-off-by: Alex Williamson <alex@shazbot.org>
2026-08-13spi: virtio: mark device ready before registering the controllerJasper Wise1-0/+2
virtio_spi_probe() registers the SPI controller with devm_spi_register_controller(). spi_register_controller() binds a child inline unless its driver has asked for asynchronous probing, so a peripheral that performs a transfer during its own probe reaches virtio_spi_transfer_one(), which kicks the virtqueue before probe has returned. The driver never calls virtio_device_ready(), so DRIVER_OK is set on its behalf by virtio_dev_probe(), only once probe has returned. The virtio spec is explicit about that ordering in 3.1 Device Initialization: | The driver MUST NOT send any buffer available notifications to the | device before setting DRIVER_OK. A device that waits for DRIVER_OK before servicing the queue therefore leaves the transfer unanswered, and virtio_spi_transfer_one() waits for its completion with no timeout, so probe never returns. Mark the device ready before registering the controller, as done for the same reason in commit f5866db64f34 ("virtio_console: enable VQs early") and commit 1d774589f924 ("i2c: virtio: mark device ready before registering the adapter"). Fixes: f98cabe3f6cf ("SPI: Add virtio SPI driver") Signed-off-by: Jasper Wise <jaspwise@amazon.co.uk> Link: https://patch.msgid.link/20260813084618.613172-1-jaspwise@amazon.co.uk Signed-off-by: Mark Brown <broonie@kernel.org>
2026-08-13nvmet: fix max_qid race between configfs and controller allocationMaurizio Lombardi5-28/+39
The function nvmet_subsys_attr_qid_max_store() can race against nvmet_alloc_ctrl() when a subsystem's max_qid limit is modified. Suppose max_qid is currently 64. If nvmet_alloc_ctrl() executes: ctrl->sqs = kzalloc_objs(struct nvmet_sq *, subsys->max_qid + 1); and at this exact point, a userspace process changes max_qid to 128, nvmet_subsys_attr_qid_max_store() will set the new max_qid value. It attempts to delete active controllers to force a reconnect, but the new controller won't be deleted because it hasn't been added to the subsys->ctrls list yet. nvmet_alloc_ctrl() then proceeds and adds the new controller to the subsys->ctrls list. Later, when nvmet_install_queue() is called, it will see max_qid set to 128, but the memory allocated for sqs is only sized for 64 entries. This results in a KASAN out-of-bounds warning and potential memory corruptions. Fix this by protecting the queue allocations and list insertion in nvmet_alloc_ctrl() with down_read(&nvmet_config_sem). Because nvmet_subsys_attr_qid_max_store() acquires down_write(&nvmet_config_sem) to modify the attribute, this safely prevents the configfs writer from modifying max_qid during controller creation. Copy the max_qid from the subsystem to the controller's structure during the allocation; ctrl->max_qid never changes as long as the controller remains in LIVE state, so this will prevent similar race conditions. Fixes: 3e980f5995e0 ("nvmet: expose max queues to configfs") Reported-by: syzbot+2626e846cd2585c9aa67@syzkaller.appspotmail.com Signed-off-by: Maurizio Lombardi <mlombard@redhat.com> Signed-off-by: Keith Busch <kbusch@kernel.org>
2026-08-13nvme: nvme-fc: Fix nvme_fc_create_hw_io_queues() queue deletion in error pathEwan D. Milne1-1/+1
nvme_fc_create_hw_io_queues() will call __nvme_fc_delete_hw_queue() for the last queue on which __nvme_fc_create_hw_queue() reported an error when deleting all the io queues if they cannot all be created. This is incorrect since the last queue did not actually get created. The most recent change to this code was commit 17a1ec08ce70 ("nvme/fc: simplify error handling of nvme_fc_create_hw_io_queues") which moved the cleanup to the delete_queues: label and changed the loop bounds, however the code was not correct prior to this change in a different way. The original commit e399441de911 ("nvme-fabrics: Add host support for FC transport") had a different error which called __nvme_fc_delete_hw_queue() on queue index 0 which is used for the admin queue. Fix this by correcting the initial loop index when deleting the io queues. Fixes: 17a1ec08ce70 ("nvme/fc: simplify error handling of nvme_fc_create_hw_io_queues") Fixes: e399441de911 ("nvme-fabrics: Add host support for FC transport") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4-6 Reviewed-by: Maurizio Lombardi <mlombard@redhat.com> Reviewed-by: Laurence Oberman <loberman@redhat.com> Reviewed-by: Justin Tee <justin.tee@broadcom.com> Signed-off-by: Ewan D. Milne <emilne@redhat.com> Signed-off-by: Keith Busch <kbusch@kernel.org>
2026-08-13selftests/bpf: Fix chained_global_func_calls_success() for cpu v4Yonghong Song1-0/+5
The chained_global_func_calls_success() test hardcodes the instruction counts reported by the verifier's per-subprog stats: subprog {{[0-9]+}} (global_good) global insns_self 5 insns_total 5 stack processed 14 insns global_good() does 'return arr[0]', where arr[] is an int array and the return type is long. Without cpu v4 this is a zero-extending load followed by a <<32/s>>32 sign-extension pair. With -mcpu=v4 llvm emits a single sign-extending load instead: 18: (18) r1 = 0xffa00000008eb000 20: (81) r0 = *(s32 *)(r1 +0) 21: (95) exit so the subprog is 3 insns rather than 5, and the whole program is 12 processed insns rather than 14. test_progs-cpuv4 fails with: EXPECTED REGEX: 'subprog {{[0-9]+}} (global_good) global insns_self 5 insns_total 5 stack' #606/1 verifier_global_subprogs/chained_global_func_calls_success:FAIL Select the expected counts based on __BPF_CPU_VERSION__. Fixes: c2e6c7de8830 ("bpf: Show more useful info in stack depth stats") Signed-off-by: Yonghong Song <yonghong.song@linux.dev> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Link: https://lore.kernel.org/bpf/20260813150641.3347662-1-yonghong.song@linux.dev
2026-08-13ALSA: seq: midi: Serialize input teardown with event_inputJohn Keeping1-6/+31
snd_midi_input_event() must not be running while a rawmidi substream is closing, since this can lead to the trigger state becoming out-of-step through this sequence in snd_rawmidi_input_trigger(): snd_rawmidi_input_trigger(up=0) snd_midi_input_event() -> snd_rawmidi_kernel_read() -> snd_rawmidi_input_trigger(up=1) -> cancel_work_sync() which ends with the underlying device being active unexpectedly. When this is called from close_substream(), further input can re-trigger the input event leaving it running after rawmidi_release_priv() has set rfile->rmidi to NULL which leads to: Unable to handle kernel NULL pointer dereference at virtual address 00000000000000b0 Call trace: snd_midi_input_event+0x3c/0x134 [snd_seq_midi] (P) snd_rawmidi_input_event_work+0x1c/0x2c process_one_work+0x150/0x3a4 worker_thread+0x190/0x318 Apply a similar approach to commit ef7607ab1c8ad ("ALSA: seq: midi: Serialize output teardown with event_input") which fixed the same issue in the output direction, but updated to use RCU following Takashi Iwai's proposed follow-on patch [1]. With this change in place, midisynth_unsubscribe() clears the input file so snd_midi_input_event() will not re-trigger the stream and will be quiesced by the cancel_work_sync() in snd_rawmidi_input_trigger(). [1] https://lore.kernel.org/linux-sound/20260813144224.753399-1-tiwai@suse.de/ Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: John Keeping <jkeeping@inmusicbrands.com> Link: https://patch.msgid.link/20260813150810.795393-1-jkeeping@inmusicbrands.com Signed-off-by: Takashi Iwai <tiwai@suse.de>
2026-08-13ALSA: hda/intel: Add sanity check for BAR0 sizeTakashi Iwai1-0/+9
The recent reports from syzkaller showed that we can bind any wild PCI device to HD-audio controller, and if PCI BAR of the device is too small, it may lead to a crash, as the driver believes as if the full register range were accessible. For avoiding such a problem, add a safeguard before the actual probe to check the available BAR0 size. Note that the threshold (0x200) is chosen to cover all needed registers at probing. But this doesn't mean that it would cover fully for all features including the extended ones. Reported-by: syzbot+10cd2d1efe8eeb604bee@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=10cd2d1efe8eeb604bee Reported-by: syzbot+5ebe7cd17e48b4293660@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=5ebe7cd17e48b4293660 Link: https://patch.msgid.link/20260813150354.763502-1-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
2026-08-13ALSA: seq: midi: Optimize event_input locking with RCUTakashi Iwai1-13/+11
The recent fix for serializing the output teardown introduced a spinlock invocation at every MIDI output event via event_process_midi. Since this is a hot path, let's do performance optimization with RCU. The new output_substream __rcu pointer is published via rcu_assign_pointer() in midisynth_use() after output_rfile is set, and cleared in midisynth_unuse() before the resource teardown. event_process_midi() reads it under rcu_read_lock() and bumps output_use_lock inside that section, which is necessary to close the window between the pointer dereference and the refcount increment. midisynth_unuse() calls synchronize_rcu() before snd_use_lock_sync(): this guarantees that any reader who obtained a non-NULL pointer has already called atomic_inc (output_use_lock), so the subsequent snd_use_lock_sync() sees the correct in-flight count. Fixes: ef7607ab1c8a ("ALSA: seq: midi: Serialize output teardown with event_input") Link: https://patch.msgid.link/20260813144224.753399-1-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
2026-08-13clocksource/drivers/armada: Unwind timer clock on init failureYuho Choi1-3/+15
The Armada timer init paths enable their clock before calling the common initialization routine. If that routine returns an error, the clock is left enabled even though the timer was not initialized successfully. Fixes: 12549e27c63c ("clocksource/drivers/time-armada-370-xp: Convert init function to return error") Signed-off-by: Yuho Choi <dbgh9129@gmail.com> Signed-off-by: Daniel Lezcano <daniel.lezcano@kernel.org> Link: https://patch.msgid.link/20260802213545.565913-1-dbgh9129@gmail.com
2026-08-13clocksource/drivers/rtl-otto: Change driver to use __raw reads and writesRustam Adilov1-7/+7
As it stands, the driver uses ioread32 and iowrite32 for register access and it works fine. However this stops working when the SWAP_IO_SPACE config is enabled as this drivers expects ioread32 and iowrite32 to be in native endian (that is big endian for currently supported SoCs). RTL9607C is a big endian MIPS SoC that has identical timer as the already supported chips but needs to have SWAP_IO_SPACE to have a functioning little endian USB host. Fix this by replacing all instances of ioread32 and iowrite32 with __raw_readl and __raw_writel variants. Since they essentially do the same register access, this shouldn't affect anything on other machines. Signed-off-by: Rustam Adilov <adilov@disroot.org> Signed-off-by: Daniel Lezcano <daniel.lezcano@kernel.org> Reviewed-by: Chris Packham <chris.packham@alliedtelesis.co.nz> Link: https://patch.msgid.link/20260725175510.77240-1-adilov@disroot.org
2026-08-13clocksource/drivers/samsung_pwm: Switch to raw_spinlock_t typeMarek Szyprowski3-23/+23
Samsung PWM timer might be used as a clock source on some legacy systems. When PREEMPT_RT is enabled on ARM, regular spinlock is converted to a sleeping lock (mutex-based), which must not be used in atomic context such as hard interrupt handlers. Switch the samsung_pwm_lock to the raw_spinlock, which remains a true non-sleeping spinlock even under PREEMPT_RT. Fixes: 7aac482e6290 ("clocksource: samsung_pwm_timer: Make PWM spinlock global") Fixes: f11899894c0a ("clocksource: add samsung pwm timer driver") Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by: Daniel Lezcano <daniel.lezcano@kernel.org> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Reviewed-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Acked-by: Uwe Kleine-König <ukleinek@kernel.org> Link: https://patch.msgid.link/20260713085653.1145015-1-m.szyprowski@samsung.com
2026-08-13clocksource/drivers/clps711x: Do not unmap clocksource MMIOGuangshuo Li1-1/+1
clps711x_clksrc_init() stores the timer base address in the static tcd pointer and registers it as both the clocksource MMIO address and the sched_clock read address. The clocksource init path must therefore keep the mapping alive after clps711x_timer_init() returns. However, the shared unmap_io exit path is also reached after successful clocksource registration, so the MMIO mapping is torn down while the clocksource and sched_clock readers may still access it. Return directly after successful clocksource registration and leave the mapping alive for the registered readers. Keep the unmap_io path for the error paths and for the clockevent init path. Fixes: cd32e596f02f ("clocksource/drivers/clps711x: Fix resource leaks in error paths") Signed-off-by: Guangshuo Li <lgs201920130244@gmail.com> Signed-off-by: Daniel Lezcano <daniel.lezcano@kernel.org> Link: https://patch.msgid.link/20260704175451.256364-1-lgs201920130244@gmail.com
2026-08-13clocksource/drivers/nxp-pit: Fix IRQ leak on cpuhp_setup_state error pathWenTao Liang1-1/+3
When cpuhp_setup_state fails after pit_clockevent_per_cpu_init has successfully called request_irq, the error handling jumps directly to out_pit_clocksource_unregister without freeing the registered IRQ. This leaks the IRQ line and, since kfree(pit) follows, leaves a dangling pointer registered as the interrupt handler's dev_id, potentially leading to a use-after-free if the IRQ fires afterwards. Fix it by calling pit_clockevent_per_cpu_exit to properly release the IRQ before falling through to the existing cleanup chain. Suggested-by: Greg KH <gregkh@linuxfoundation.org> Fixes: bee33f22d7c3 ("clocksource/drivers/nxp-pit: Add NXP Automotive s32g2 / s32g3 support") Cc: stable@vger.kernel.org Signed-off-by: WenTao Liang <vulab@iscas.ac.cn> Signed-off-by: Daniel Lezcano <daniel.lezcano@kernel.org> Link: https://patch.msgid.link/20260628130700.45680-1-vulab@iscas.ac.cn
2026-08-13clocksource/drivers/timer-sun4i: Advertise a real minimum deltaFelix Yan1-1/+1
sun4i_clkevt_next_event() compensates for the timer stop/start synchronization delay by programming evt - TIMER_SYNC_TICKS into the hardware interval register. The clockevent device currently advertises TIMER_SYNC_TICKS as min_delta_ticks, so the clockevents core is allowed to call set_next_event() with evt == TIMER_SYNC_TICKS. That programs a zero-tick interval. With oneshot/highres/nohz timer operation this can leave the next event stuck, which was observed as a boot hang on Allwinner D1 after the clockevents core started reusing forced minimum-delta events. Advertise one extra tick instead, so the smallest event accepted by the core still programs at least one hardware tick after the synchronization compensation. Fixes: 12e1480bcb49 ("clocksource: sun4i: Report the minimum tick that we can program") Reported-by: Indrek Kruusa <indrek.kruusa@gmail.com> Closes: https://lore.kernel.org/linux-riscv/CA+fTLhgLmTY+exGujKf8OYYQvcEW5X5NJ_5sLq2AYL6zER2c0A@mail.gmail.com/ Assisted-by: Codex:gpt-5.5 Signed-off-by: Felix Yan <felixonmars@archlinux.org> Signed-off-by: Daniel Lezcano <daniel.lezcano@kernel.org> Tested-by: Indrek Kruusa <indrek.kruusa@gmail.com> Acked-by: Jernej Skrabec <jernej.skrabec@gmail.com> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/linux-riscv/CA+fTLhgLmTY+exGujKf8OYYQvcEW5X5NJ_5sLq2AYL6zER2c0A@mail.gmail.com/ Link: https://patch.msgid.link/20260624220434.4183732-1-felixonmars@archlinux.org
2026-08-13clocksource: Remove redundant dev_err()/dev_err_probe()Pan Chuang6-16/+6
Since commit 55b48e23f5c4 ("genirq/devres: Add error handling in devm_request_*_irq()"), devm_request_irq() automatically logs detailed error messages on failure. Remove the now-redundant driver-specific dev_err() and dev_err_probe() calls. Signed-off-by: Pan Chuang <panchuang@vivo.com> Signed-off-by: Daniel Lezcano <daniel.lezcano@kernel.org> Link: https://patch.msgid.link/20260713130740.293502-1-panchuang@vivo.com
generated by cgit (git 2.54.0.dirty) at 2026-09-29 04:30:07 +0000