summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2026-06-07bpf: Add struct bpf_tramp_node objectJiri Olsa
Adding struct bpf_tramp_node to decouple the link out of the trampoline attachment info. At the moment the object for attaching bpf program to the trampoline is 'struct bpf_tramp_link': struct bpf_tramp_link { struct bpf_link link; struct hlist_node tramp_hlist; u64 cookie; } The link holds the bpf_prog pointer and forces one link - one program binding logic. In following changes we want to attach program to multiple trampolines but we want to keep just one bpf_link object. Splitting struct bpf_tramp_link into: struct bpf_tramp_link { struct bpf_link link; struct bpf_tramp_node node; }; struct bpf_tramp_node { struct bpf_link *link; struct hlist_node tramp_hlist; u64 cookie; }; The 'struct bpf_tramp_link' defines standard single trampoline link and 'struct bpf_tramp_node' is the attachment trampoline object with pointer to the bpf_link object. This will allow us to define link for multiple trampolines, like: struct bpf_tracing_multi_link { struct bpf_link link; ... int nodes_cnt; struct bpf_tracing_multi_node nodes[] __counted_by(nodes_cnt); }; Cc: Hengqi Chen <hengqi.chen@gmail.com> Signed-off-by: Jiri Olsa <jolsa@kernel.org> Link: https://lore.kernel.org/r/20260606123955.345967-9-jolsa@kernel.org Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2026-06-07bpf: Add bpf_trampoline_add/remove_prog functionsJiri Olsa
Separate bpf_trampoline_add/remove_prog functions from __bpf_trampoline_link/unlink functions to be able to add/remove trampoline programs without the image being updated in following changes. No functional change is intended. Signed-off-by: Jiri Olsa <jolsa@kernel.org> Link: https://lore.kernel.org/r/20260606123955.345967-8-jolsa@kernel.org Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2026-06-07bpf: Move trampoline image setup into bpf_trampoline_ops callbacksJiri Olsa
Moving trampoline image setup into bpf_trampoline_ops callbacks, so we can have different image handling for multi attachment which is coming in following changes. Signed-off-by: Jiri Olsa <jolsa@kernel.org> Link: https://lore.kernel.org/r/20260606123955.345967-7-jolsa@kernel.org Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2026-06-07bpf: Add struct bpf_trampoline_ops objectJiri Olsa
In following changes we will need to override ftrace direct attachment behaviour. In order to do that we are adding struct bpf_trampoline_ops object that defines callbacks for ftrace direct attachment: register_fentry unregister_fentry modify_fentry The new struct bpf_trampoline_ops object is passed as an argument to __bpf_trampoline_link/unlink_prog functions. At the moment the default trampoline_ops is set to the current ftrace direct attachment functions, so there's no functional change for the current code. Signed-off-by: Jiri Olsa <jolsa@kernel.org> Link: https://lore.kernel.org/r/20260606123955.345967-6-jolsa@kernel.org Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2026-06-07bpf: Use mutex lock pool for bpf trampolinesJiri Olsa
Adding mutex lock pool that replaces bpf trampolines mutex. For tracing_multi link coming in following changes we need to lock all the involved trampolines during the attachment. This could mean thousands of mutex locks, which is not convenient. As suggested by Andrii we can replace bpf trampolines mutex with mutex pool, where each trampoline is hash-ed to one of the locks from the pool. It's better to lock all the pool mutexes (32 at the moment) than thousands of them. There is 48 (MAX_LOCK_DEPTH) lock limit allowed to be simultaneously held by task, so we need to keep 32 mutexes (5 bits) in the pool, so when we lock them all in following changes the lockdep won't scream. Removing the mutex_is_locked in bpf_trampoline_put, because we removed the mutex from bpf_trampoline. Suggested-by: Andrii Nakryiko <andrii@kernel.org> Signed-off-by: Jiri Olsa <jolsa@kernel.org> Link: https://lore.kernel.org/r/20260606123955.345967-5-jolsa@kernel.org Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2026-06-07ftrace: Add add_ftrace_hash_entry functionJiri Olsa
Renaming __add_hash_entry to add_ftrace_hash_entry and making it global, it will be used in following changes outside ftrace.c object. Signed-off-by: Jiri Olsa <jolsa@kernel.org> Link: https://lore.kernel.org/r/20260606123955.345967-4-jolsa@kernel.org Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2026-06-07ftrace: Add ftrace_hash_remove functionJiri Olsa
Adding ftrace_hash_remove function that removes all entries from struct ftrace_hash object without freeing them. It will be used in following changes where entries are allocated as part of another structure and are free-ed separately. Signed-off-by: Jiri Olsa <jolsa@kernel.org> Link: https://lore.kernel.org/r/20260606123955.345967-3-jolsa@kernel.org Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2026-06-07ftrace: Add ftrace_hash_count functionJiri Olsa
Adding external ftrace_hash_count function so we could get hash count outside of ftrace object. Signed-off-by: Jiri Olsa <jolsa@kernel.org> Link: https://lore.kernel.org/r/20260606123955.345967-2-jolsa@kernel.org Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2026-06-07fbdev: vesafb: fix memory leak in vesafb_probe()Abdun Nihaal
Since commit 73ce73c30ba9 ("fbdev: Transfer video= option strings to caller; clarify ownership") the string returned from fb_get_options() is expected to be freed by the caller. But the string is not freed in vesafb_probe(). Fix that by freeing the option string after setup. Fixes: 73ce73c30ba9 ("fbdev: Transfer video= option strings to caller; clarify ownership") Cc: stable@vger.kernel.org Signed-off-by: Abdun Nihaal <nihaal@cse.iitm.ac.in> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Helge Deller <deller@gmx.de>
2026-06-07fbdev: efifb: fix memory leak in efifb_probe()Abdun Nihaal
Since commit 73ce73c30ba9 ("fbdev: Transfer video= option strings to caller; clarify ownership") the string returned from fb_get_options() is expected to be freed by the caller, but the string is not freed in efifb_probe(). Fix that by freeing the option string after setup. Fixes: 73ce73c30ba9 ("fbdev: Transfer video= option strings to caller; clarify ownership") Cc: stable@vger.kernel.org Signed-off-by: Abdun Nihaal <nihaal@cse.iitm.ac.in> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Helge Deller <deller@gmx.de>
2026-06-07fbdev: uvesafb: fix potential memory leak in uvesafb_probe()Abdun Nihaal
Due to an incorrect goto label, memory allocated for modedb and modelist in uvesafb_vbe_init() is not freed in some error paths. Fix this by updating the goto label. Fixes: 8bdb3a2d7df4 ("uvesafb: the driver core") Cc: stable@vger.kernel.org Signed-off-by: Abdun Nihaal <nihaal@cse.iitm.ac.in> Signed-off-by: Helge Deller <deller@gmx.de>
2026-06-07fbdev: tridentfb: fix potential memory leak in trident_pci_probe()Abdun Nihaal
In trident_pci_probe(), the memory allocated for modelist using fb_videomode_to_modelist() is not freed in subsequent error paths. Fix that by calling fb_destroy_modelist(). Fixes: 6a5e3bd0c8bc ("tridentfb: Add DDC support") Cc: stable@vger.kernel.org Signed-off-by: Abdun Nihaal <nihaal@cse.iitm.ac.in> Signed-off-by: Helge Deller <deller@gmx.de>
2026-06-07fbdev: tdfxfb: fix potential memory leak in tdfxfb_probe()Abdun Nihaal
In tdfxfb_probe(), the memory allocated for modelist using fb_videomode_to_modelist() when CONFIG_FB_3DFX_I2C is defined, is not freed in the subsequent error paths. Fix that by calling fb_destroy_modelist(). Fixes: 215059d2421f ("tdfxfb: make use of DDC information about connected monitor") Cc: stable@vger.kernel.org Signed-off-by: Abdun Nihaal <nihaal@cse.iitm.ac.in> Signed-off-by: Helge Deller <deller@gmx.de>
2026-06-07fbdev: s3fb: fix potential memory leak in s3_pci_probe()Abdun Nihaal
In s3_pci_probe(), the memory allocated for modelist using fb_videomode_to_modelist() is not freed in subsequent error paths. Fix that by calling fb_destroy_modelist() Fixes: 86c0f043a737 ("s3fb: add DDC support") Cc: stable@vger.kernel.org Signed-off-by: Abdun Nihaal <nihaal@cse.iitm.ac.in> Signed-off-by: Helge Deller <deller@gmx.de>
2026-06-07fbdev: nvidia: fix potential memory leak in nvidiafb_probe()Abdun Nihaal
In nvidiafb_probe(), the memory allocated for modelist in nvidia_set_fbinfo() is not freed in the subsequent error paths. Fix that by calling fb_destroy_modelist(). Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org Signed-off-by: Abdun Nihaal <nihaal@cse.iitm.ac.in> Signed-off-by: Helge Deller <deller@gmx.de>
2026-06-07fbdev: i740fb: fix potential memory leak in i740fb_probe()Abdun Nihaal
In i740fb_probe(), the memory allocated in fb_videomode_to_modelist() for modelist is not freed in the error paths. Fix that by calling fb_destroy_modelist(). Fixes: 5350c65f4f15 ("Resurrect Intel740 driver: i740fb") Cc: stable@vger.kernel.org Signed-off-by: Abdun Nihaal <nihaal@cse.iitm.ac.in> Signed-off-by: Helge Deller <deller@gmx.de>
2026-06-07fbdev: carminefb: fix potential memory leak in alloc_carmine_fb()Abdun Nihaal
The memory allocated for modelist in fb_videomode_to_modelist() is not freed in the subsequent error path. Fix that by calling fb_destroy_modelist() Fixes: 2ece5f43b041 ("fbdev: add the carmine FB driver") Cc: stable@vger.kernel.org Signed-off-by: Abdun Nihaal <nihaal@cse.iitm.ac.in> Signed-off-by: Helge Deller <deller@gmx.de>
2026-06-07fbdev: radeon: fix potential memory leak in radeonfb_pci_register()Abdun Nihaal
The function radeonfb_pci_register() allocates memory for modelist (by calling radeon_check_modes() which calls fb_add_videomode()). The memory is appended to info->modelist, but is not freed in subsequent error paths. Fix this by calling fb_destroy_modelist(). Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org Signed-off-by: Abdun Nihaal <nihaal@cse.iitm.ac.in> Signed-off-by: Helge Deller <deller@gmx.de>
2026-06-07fbdev: metronomefb: fix potential memory leak in metronomefb_probe()Abdun Nihaal
The memory allocated for pagerefs in fb_deferred_io_init() is not freed on the error path. Fix it by calling fb_deferred_io_cleanup(). Fixes: 56c134f7f1b5 ("fbdev: Track deferred-I/O pages in pageref struct") Cc: stable@vger.kernel.org Signed-off-by: Abdun Nihaal <nihaal@cse.iitm.ac.in> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Helge Deller <deller@gmx.de>
2026-06-07fbdev: broadsheetfb: fix potential memory leak in broadsheetfb_probe()Abdun Nihaal
The memory allocated for pagerefs in fb_deferred_io_init() is not freed on the error path. Fix it by calling fb_deferred_io_cleanup(). Fixes: 56c134f7f1b5 ("fbdev: Track deferred-I/O pages in pageref struct") Cc: stable@vger.kernel.org Signed-off-by: Abdun Nihaal <nihaal@cse.iitm.ac.in> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Helge Deller <deller@gmx.de>
2026-06-07fbdev: hecubafb: fix potential memory leak in hecubafb_probe()Abdun Nihaal
The memory allocated for pagerefs in fb_deferred_io_init() is not freed on the error path. Fix it by calling fb_deferred_io_cleanup(). Fixes: 56c134f7f1b5 ("fbdev: Track deferred-I/O pages in pageref struct") Cc: stable@vger.kernel.org Signed-off-by: Abdun Nihaal <nihaal@cse.iitm.ac.in> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Helge Deller <deller@gmx.de>
2026-06-07fbdev: atmel_lcdfb: Use of_device_get_match_data()Rosen Penev
Use of_device_get_match_data() to retrieve the driver match data instead of open-coding the OF match lookup and dereferencing match->data. This also removes the deprecated of_device.h include from the driver. No need for NULL check as every compatible has a corresponding data component. Assisted-by: Codex:GPT-5.5 Signed-off-by: Rosen Penev <rosenp@gmail.com> Signed-off-by: Helge Deller <deller@gmx.de>
2026-06-07fbdev: imxfb: Use of_device_get_match_data()Rosen Penev
Use of_device_get_match_data() to fetch the platform ID entry directly instead of open-coding an of_match_device() lookup. No NULL check is needed as every compatible string has a corresponding data section. This also lets the driver drop the of_device.h include. Assisted-by: Codex:GPT-5.5 Signed-off-by: Rosen Penev <rosenp@gmail.com> Signed-off-by: Helge Deller <deller@gmx.de>
2026-06-07fbcon: Use correct type for vc_resize() return valueJiacheng Yu
The return value of vc_resize() is int, but fbcon_set_disp() stores it in an unsigned long variable. While the !ret check happens to work correctly by coincidence (negative values become large positive values), the types should match. Use int instead. Eliminates the following W=3 warning: drivers/video/fbdev/core/fbcon.c: In function 'fbcon_set_disp': drivers/video/fbdev/core/fbcon.c:1494:14: warning: implicit conversion from 'int' to 'unsigned long' [-Wconversion] Fixes: af0db3c1f898 ("fbdev: Fix vmalloc out-of-bounds write in fast_imageblit") Cc: stable@vger.kernel.org # v6.17+ Signed-off-by: Jiacheng Yu <yujiacheng3@huawei.com> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Helge Deller <deller@gmx.de>
2026-06-07fbdev: Consistently define pci_device_ids using named initializersUwe Kleine-König
... and PCI device helpers. The various struct pci_device_id arrays were initialized mostly by list expressions. This isn't easily readable if you're not into PCI. Using named initializers is more explicit and thus easier to parse. Also use PCI_DEVICE* helper macros to assign .vendor, .device, .subvendor and .subdevice where appropriate and skip explicit assignments of 0 (which the compiler takes care of). The secret plan is to make struct pci_device_id::driver_data an anonymous union (similar to https://lore.kernel.org/all/cover.1776579304.git.u.kleine-koenig@baylibre.com/) and that requires named initializers. But it's also a nice cleanup on its own. While touching all these arrays, unify usage of whitespace and comma in a few drivers. This change doesn't introduce changes to the compiled pci_device_id array. Tested on x86 and arm64. Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com> Signed-off-by: Helge Deller <deller@gmx.de>
2026-06-07fbdev: matroxfb/ssd1307fb: Use named initializers for struct i2c_device_idUwe Kleine-König
While being less compact, using named initializers allows to more easily see which members of the structs are assigned which value without having to lookup the declaration of the struct. And it's also more robust against changes to the struct definition. While touching all these arrays, unify usage of whitespace in the list terminator. This patch doesn't modify the compiled arrays, only their representation in source form benefits. The former was confirmed with x86 and arm64 builds. Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com> Signed-off-by: Helge Deller <deller@gmx.de>
2026-06-07Merge tag 'input-for-v7.1-rc6' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input Pull input fixes from Dmitry Torokhov: - two quirks for atkbd to deal with laptops that can not handle "deactivate" command on the keyboard PS/2 port * tag 'input-for-v7.1-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input: Input: atkbd - skip deactivate for HONOR BCC-N's internal keyboard Input: atkbd - add DMI quirk for Lenovo Yoga Air 14 (83QK)
2026-06-07KVM: arm64: Fix block mapping validity check in stage-1 walkerWei-Lin Chang
For the 64K granule size, FEAT_LPA determines whether a level 1 mapping is allowed. Using the result of has_52bit_pa() is too restrictive, as it also checks the selected output addressi size in TCR.(I)PS. Fix it by only checking FEAT_LPA. Fixes: 5da3a3b27a01 ("KVM: arm64: Expand valid block mappings to FEAT_LPA/LPA2 support") Signed-off-by: Wei-Lin Chang <weilin.chang@arm.com> Link: https://patch.msgid.link/20260605185255.2431996-1-weilin.chang@arm.com Signed-off-by: Marc Zyngier <maz@kernel.org>
2026-06-07KVM: arm64: Set a Linux errno on SMCCC error in kvm_call_hyp_nvhe()Vincent Donnefort
If kvm_call_hyp_nvhe() fails with an SMCCC error code, we WARN(). However, the returned value isn't initialized and the caller might get garbage or 0 which is likely to be interpreted as success. Set a default -EOPNOTSUPP error value, ensuring all callers get the message when hypercalls fail. Signed-off-by: Vincent Donnefort <vdonnefort@google.com> Acked-by: Will Deacon <will@kernel.org> Reviewed-by: Fuad Tabba <tabba@google.com> Link: https://patch.msgid.link/20260603110312.2909844-1-vdonnefort@google.com [maz: changed error value to -EOPNOTSUPP as suggested by Will, tidied up change log] Signed-off-by: Marc Zyngier <maz@kernel.org>
2026-06-07KVM: arm64: Roll back partial shares on kvm_share_hyp() failuretabba@google.com
kvm_share_hyp() shares a range one page at a time. If share_pfn_hyp() fails partway through, the pages already shared by this call are left shared, while the caller treats the whole range as failed and never unshares them. Unshare those pages before returning the error. If an unshare itself fails the page is leaked: it stays shared with the hypervisor and is no longer reusable for pKVM, but no isolation guarantee is broken, so WARN and continue. Not expected in practice. Fixes: a83e2191b7f1 ("KVM: arm64: pkvm: Refcount the pages shared with EL2") Suggested-by: Vincent Donnefort <vdonnefort@google.com> Signed-off-by: Fuad Tabba <tabba@google.com> Reviewed-by: Vincent Donnefort <vdonnefort@google.com> Link: https://patch.msgid.link/20260529121755.2923500-4-tabba@google.com Signed-off-by: Marc Zyngier <maz@kernel.org>
2026-06-07KVM: arm64: Avoid host/hyp share desync on unshare hypercall failuretabba@google.com
unshare_pfn_hyp() erases the tracking node from hyp_shared_pfns and frees it before invoking __pkvm_host_unshare_hyp. If the hypercall fails (e.g. EL2 refcount still held, or page-state mismatch), the host loses its record while EL2 still holds the share, breaking later share/unshare attempts on the same pfn. Invoke the hypercall first; erase and free only on success. Document at the kvm_unshare_hyp() call site that the WARN_ON() is left non-fatal: a failed unshare leaks the page (it stays shared with the hypervisor) but breaks no isolation guarantee. Fixes: 52b28657ebd7 ("KVM: arm64: pkvm: Unshare guest structs during teardown") Reported-by: Sashiko (local):gemini-3.1-pro Suggested-by: Vincent Donnefort <vdonnefort@google.com> Signed-off-by: Fuad Tabba <tabba@google.com> Reviewed-by: Vincent Donnefort <vdonnefort@google.com> Link: https://patch.msgid.link/20260529121755.2923500-3-tabba@google.com Signed-off-by: Marc Zyngier <maz@kernel.org>
2026-06-07KVM: arm64: Free hyp-share tracking node when share hypercall failstabba@google.com
share_pfn_hyp() inserts a tracking node into hyp_shared_pfns and then invokes __pkvm_host_share_hyp. If the hypercall rejects the share (page-state mismatch at EL2), the node stays in the tree with refcount 1: a phantom share that leaks the allocation and that a later unshare will trust. Erase the node and free it on hypercall failure. Fixes: a83e2191b7f1 ("KVM: arm64: pkvm: Refcount the pages shared with EL2") Reported-by: Sashiko (local):gemini-3.1-pro Suggested-by: Vincent Donnefort <vdonnefort@google.com> Signed-off-by: Fuad Tabba <tabba@google.com> Reviewed-by: Vincent Donnefort <vdonnefort@google.com> Link: https://patch.msgid.link/20260529121755.2923500-2-tabba@google.com Signed-off-by: Marc Zyngier <maz@kernel.org>
2026-06-07KVM: arm64: Flush HCR_EL2.VSE to deliver SErrors to pKVM gueststabba@google.com
With pKVM enabled, the host injects a virtual SError by setting HCR_EL2.VSE on its vCPU copy, but flush_hyp_vcpu() only flows TWI/TWE into the hyp vCPU that runs, so VSE never reaches it and a deferred (masked) SError is never delivered. VSE is a host-owned injection control, not a trap-configuration bit, so restricting the host's trap-register values should not have dropped it. Flow it on entry; sync_hyp_vcpu() already copies hcr_el2 back, so delivery is reflected to the host. THis makes it consistent with the existing forwarding of VSESR_EL2, which qualifies the Serror. Fixes: b56680de9c648 ("KVM: arm64: Initialize trap register values in hyp in pKVM") Reported-by: Sashiko (local):gemini-3.1-pro Signed-off-by: Fuad Tabba <tabba@google.com> Reviewed-by: Oliver Upton <oupton@kernel.org> Link: https://patch.msgid.link/20260531154548.1505799-1-tabba@google.com Signed-off-by: Marc Zyngier <maz@kernel.org>
2026-06-07KVM: arm64: Bound used_lrs when flushing the pKVM hyp vCPUHyunwoo Kim
flush_hyp_vcpu() copies the host vGIC state into the hyp's private vCPU on every run. The vGIC list register save and restore use used_lrs as their loop bound and expect it to stay within the number of implemented list registers. While this is generally the case, flush_hyp_vcpu() copies vgic_v3 verbatim and does not enforce this, so a value provided by the host is used at EL2 to index vgic_lr[] and access ICH_LR<n>_EL2 (host -> EL2). Fix by clamping used_lrs to the number of implemented list registers after the copy, as the trusted path already does in vgic_flush_lr_state(). The number of implemented list registers is constant after init, so it is replicated once from kvm_vgic_global_state.nr_lr into hyp_gicv3_nr_lr rather than read on every entry. Cc: stable@vger.kernel.org Fixes: be66e67f1750 ("KVM: arm64: Use the pKVM hyp vCPU structure in handle___kvm_vcpu_run()") Signed-off-by: Hyunwoo Kim <imv4bel@gmail.com> Reviewed-by: Fuad Tabba <tabba@google.com> Tested-by: Fuad Tabba <tabba@google.com> Link: https://patch.msgid.link/20260606175614.83273-3-imv4bel@gmail.com Signed-off-by: Marc Zyngier <maz@kernel.org>
2026-06-07KVM: arm64: Clear __hyp_running_vcpu when flushing the pKVM hyp vCPUHyunwoo Kim
flush_hyp_vcpu() copies the host vCPU context into the hyp's private vCPU on every run. ctxt_to_vcpu() expects a guest context to have a NULL __hyp_running_vcpu, which is only ever set on the host context, so that it resolves the vCPU via container_of(). While this is generally the case, flush_hyp_vcpu() copies the context verbatim and does not enforce this, so a value provided by the host is dereferenced at EL2 (host -> EL2). Fix by clearing __hyp_running_vcpu after the copy. Cc: stable@vger.kernel.org Fixes: be66e67f1750 ("KVM: arm64: Use the pKVM hyp vCPU structure in handle___kvm_vcpu_run()") Signed-off-by: Hyunwoo Kim <imv4bel@gmail.com> Reviewed-by: Fuad Tabba <tabba@google.com> Tested-by: Fuad Tabba <tabba@google.com> Link: https://patch.msgid.link/20260606175614.83273-2-imv4bel@gmail.com Signed-off-by: Marc Zyngier <maz@kernel.org>
2026-06-07riscv: also select ARCH_KEEP_MEMBLOCK if kexec is selectedHan Gao
On RISC-V, also select ARCH_KEEP_MEMBLOCK if kexec is selected, not only if ACPI is selected. This is because kexec requires the memblock areas to be kept after boot to initialize the secondary kernel. This is needed for both Device Tree and ACPI platforms. Signed-off-by: Han Gao <gaohan@iscas.ac.cn> Link: https://patch.msgid.link/20260519165546.123105-1-gaohan@iscas.ac.cn [pjw@kernel.org: change to add the dependency on kexec, rather than making it unconditional; rewrite the patch description accordingly] Signed-off-by: Paul Walmsley <pjw@kernel.org>
2026-06-07net/mlx5: Add sd_group_size bits for SD managementShay Drory
Currently, mlx5 is querying the MPIR register to get the number of PFs that should comprise the SD group. However, this register does not reflect the correct number in complex deployments. Hence, add an sd_group_size field to nic_vport_context to determine the correct number of PFs, and add an sd_group_size capability bit to indicate whether FW supports it. Signed-off-by: Shay Drory <shayd@nvidia.com> Reviewed-by: Moshe Shemesh <moshe@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Link: https://patch.msgid.link/20260529052359.389413-3-tariqt@nvidia.com Signed-off-by: Leon Romanovsky <leon@kernel.org>
2026-06-07net/mlx5: Update IFC allowed_list_size field bitsDragos Tatulea
The vport context allowed_list_size was increased from 12 to 16 bits. Writing to this field is protected by the log_max_current_uc/mc_list capabilities. On older FW versions these capabilities are limited to < 2K and only the high bits of the field are extended. This means that the change is backward compatible with older FW versions. Signed-off-by: Dragos Tatulea <dtatulea@nvidia.com> Reviewed-by: Cosmin Ratiu <cratiu@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Link: https://patch.msgid.link/20260529052359.389413-2-tariqt@nvidia.com Signed-off-by: Leon Romanovsky <leon@kernel.org>
2026-06-07ALSA: es18xx: check control allocation before private data setupRuoyu Wang
snd_es18xx_mixer() creates controls with snd_ctl_new1() and then stores bookkeeping pointers or sets private_free before calling snd_ctl_add(). snd_ctl_new1() can return NULL on allocation failure, so those writes can dereference a NULL control pointer. Check the returned control pointers before using them and return -ENOMEM on allocation failure. Signed-off-by: Ruoyu Wang <ruoyuw560@gmail.com> Link: https://patch.msgid.link/20260607074219.3-1-ruoyuw560@gmail.com Signed-off-by: Takashi Iwai <tiwai@suse.de>
2026-06-07filelock: fix break_lease() stub signature for CONFIG_FILE_LOCKING=nChristian Brauner
The CONFIG_FILE_LOCKING=n stub for break_lease() takes a 'bool wait' argument, whereas the CONFIG_FILE_LOCKING=y version and every caller pass an openmode as an 'unsigned int mode'. The mismatch was introduced when __break_lease() was reworked to use flags: only the stub was switched to 'bool wait', a stray leftover from the neighbouring break_layout() helper. The real prototype kept 'unsigned int mode'. This was harmless until O_WRONLY changed from the octal literal 00000001 to (1 << 0). clang's -Wtautological-constant-compare then fires on the implicit shift-to-bool conversion at the first FILE_LOCKING=n caller: fs/open.c:112:29: warning: converting the result of '<<' to a boolean always evaluates to true [-Wtautological-constant-compare] 112 | error = break_lease(inode, O_WRONLY); Restore the stub's parameter to 'unsigned int mode' so it matches the real prototype and every caller. The stub still just returns 0, so there is no functional change; it removes the type inconsistency and silences the warning. Root cause diagnosed by Nathan Chancellor. Fixes: 4be9f3cc582a ("filelock: rework the __break_lease API to use flags") Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202606071029.DKCs8WOs-lkp@intel.com/ Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
2026-06-07netfilter: nf_conntrack: use get_unaligned_be32() in tcp_sack()Rosen Penev
The timestamp-only fast path dereferences the option stream as *(__be32 *)ptr, which assumes 4-byte alignment that the TCP option stream does not guarantee. Use get_unaligned_be32() instead, which reads the value safely and already returns host byte order, so the htonl() on the comparison constant can be dropped. This matches the existing get_unaligned_be32() use later in the same function. Assisted-by: Claude:Opus-4.7 Signed-off-by: Rosen Penev <rosenp@gmail.com> Reviewed-by: Fernando Fernandez Mancera <fmancera@suse.de> Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
2026-06-07netfilter: flowtable: avoid num_encaps underflow on bridge VLAN untagDavid Carlier
The DEV_PATH_BR_VLAN_UNTAG case post-decrements info->num_encaps inside WARN_ON_ONCE(). num_encaps is u8, so if it's already 0 the decrement still happens and wraps it to 255. The break only leaves the inner switch -- a later path entry can set info->indev back to a real device, and we end up returning with num_encaps == 255. nft_dev_forward_path() then walks info.encap[] (size 2) up to num_encaps, which means an OOB stack read and a bogus count copied into the route descriptor. Should only happen on a malformed bridge path stack, hence the WARN, but worth handling sanely. Move the decrement out of the WARN. [ While at this, remove the WARN_ON_ONCE since this can only happen with a buggy bridge path stack --pablo ]. Fixes: e990cef6516d ("netfilter: flowtable: add bridge vlan filtering support") Signed-off-by: David Carlier <devnexen@gmail.com> Reviewed-by: Fernando Fernandez Mancera <fmancera@suse.de> Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
2026-06-07bpf: Reject sleepable BPF_LSM_CGROUP programs at load timeDavid Windsor
The cgroup shim runs under rcu_read_lock_dont_migrate(), so we should not attach any sleepable BPF programs there. Add support to the verifier to explicitly reject attempts to load sleepable BPF programs destined for LSM cgroup attachment. Without this, we get the following splat from a BPF_LSM_CGROUP program marked BPF_F_SLEEPABLE attached to file_open when it calls bpf_get_dentry_xattr(): BUG: sleeping function called from invalid context at kernel/locking/rwsem.c:1567 in_atomic(): 0, irqs_disabled(): 0, non_block: 0, pid: 34317, name: load preempt_count: 0, expected: 0 RCU nest depth: 2, expected: 0 Call Trace: down_read+0x76/0x480 ext4_xattr_get+0x11f/0x700 __vfs_getxattr+0xf0/0x150 bpf_get_dentry_xattr+0xbb/0xf0 bpf_prog_e76a298dac9218c6_test_open+0x6a/0x85 __cgroup_bpf_run_lsm_current+0x326/0x840 bpf_trampoline_6442534646+0x62/0x14d security_file_open+0x34/0x60 do_dentry_open+0x340/0x1260 vfs_open+0x7a/0x440 path_openat+0x1bac/0x30a0 libbpf provides a .s named section variant for every sleepable program type except lsm_cgroup, reflecting that per-cgroup LSM programs are intended to only run in a non-sleepable context. The above splat was obtained by bypassing libbpf by using bpf(2) directly. Fixes: 69fd337a975c ("bpf: per-cgroup lsm flavor") Signed-off-by: David Windsor <dwindsor@gmail.com> Acked-by: Yonghong Song <yonghong.song@linux.dev> Acked-by: Song Liu <song@kernel.org> Link: https://lore.kernel.org/bpf/20260605145707.608579-1-dwindsor@gmail.com Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
2026-06-07riscv: alternative: Also patch the CFI vDSOThomas Weißschuh
The dedicated vDSO for CFI-enabled userspace can also contain alternative entries. Patch those, too. Fixes: ccad8c1336b6 ("arch/riscv: add dual vdso creation logic and select vdso based on hw") Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de> Link: https://patch.msgid.link/20260504-riscv-cfi-vdso-alternative-v1-4-bcdf3d37f62e@linutronix.de Signed-off-by: Paul Walmsley <pjw@kernel.org>
2026-06-07riscv: alternative: Pass vDSO start as parameter to apply_vdso_alternatives()Thomas Weißschuh
The dedicated vDSO with CFI should also be patched in the same way. To prepare for that move the currently hardcoded vDSO start symbol into a parameter. Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de> Link: https://patch.msgid.link/20260504-riscv-cfi-vdso-alternative-v1-3-bcdf3d37f62e@linutronix.de Signed-off-by: Paul Walmsley <pjw@kernel.org>
2026-06-07riscv: alternative: Use IS_ENABLED() over ifdeffery for ↵Thomas Weißschuh
apply_vdso_alternatives() IS_ENABLED() allows better compilation coverage while still optimizing away all the dead code. Also it will make some upcoming changes easier. Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de> Link: https://patch.msgid.link/20260504-riscv-cfi-vdso-alternative-v1-2-bcdf3d37f62e@linutronix.de Signed-off-by: Paul Walmsley <pjw@kernel.org>
2026-06-07riscv: vdso: Always declare vdso_start symbolsThomas Weißschuh
Make the declarations of vdso_start and its related symbols always visible. With that their users don't have to use ifdeffery but can use the better IS_ENABLED() compile-time checks. Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de> Link: https://patch.msgid.link/20260504-riscv-cfi-vdso-alternative-v1-1-bcdf3d37f62e@linutronix.de Signed-off-by: Paul Walmsley <pjw@kernel.org>
2026-06-07Merge branch 'for-linus' into for-nextTakashi Iwai
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2026-06-07ALSA: seq: Clear variable event pointer on readKyle Zeng
snd_seq_read() copies a queued variable-length event header to userspace before expanding the payload. Queued variable-length events use SNDRV_SEQ_EXT_CHAINED internally, and data.ext.ptr points at the first extension cell. The read side strips SNDRV_SEQ_EXT_* bits from data.ext.len before the copy, but it leaves data.ext.ptr untouched. A userspace sequencer client can therefore write a direct variable event to itself and read back the extension-cell kernel address from the returned header. Clear the temporary header pointer before copy_to_user(). The original queued event remains unchanged and is still passed to snd_seq_expand_var_event(), so payload expansion keeps using the internal chain. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Kyle Zeng <kylebot@openai.com> Link: https://patch.msgid.link/20260607004129.61345-1-kylebot@openai.com Signed-off-by: Takashi Iwai <tiwai@suse.de>
2026-06-07ALSA: timer: Fix UAF at snd_timer_user_params()Takashi Iwai
At releasing a timer object, e.g. when a userspace timer (CONFIG_SND_UTIMER) gets closed and snd_timer_free() is called, it tries to detach the timer instances and release the resources. However, it's still possible that other in-flight tasks are holding the timer instance where the to-be-deleted timer object is associated, and this may lead to racy accesses. Fortunately, most of ioctls dealing with the timer instance list already have the protection with register_mutex, and this also avoids such races. But, SNDRV_TIMER_IOCTL_PARAMS isn't protected, hence the concurrent ioctl may lead to use-after-free. This patch just adds the guard with register_mutex to protect snd_timer_user_params() for covering the code path as a quick workaround. It's no hot-path but rather a rarely issued ioctl, so the performance penalty doesn't matter. Reported-by: Kyle Zeng <kylebot@openai.com> Tested-by: Kyle Zeng <kylebot@openai.com> Cc: <stable@vger.kernel.org> Link: https://patch.msgid.link/20260606161145.1933447-2-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>