summaryrefslogtreecommitdiff
path: root/include
AgeCommit message (Collapse)Author
2026-05-13macsec: use rcu_work to defer RX SA crypto cleanup out of softirqJinliang Zheng
crypto_free_aead() can internally invoke vunmap() (e.g. via dma_free_attrs() in hardware crypto drivers such as hisi_sec2). vunmap() must not be called from softirq context, but free_rxsa() is an RCU callback that runs in softirq, leading to a kernel crash: vunmap+0x4c/0x70 __iommu_dma_free+0xd0/0x138 dma_free_attrs+0xf4/0x100 sec_aead_exit+0x64/0xb8 [hisi_sec2] crypto_destroy_tfm+0x98/0x110 free_rxsa+0x28/0x50 [macsec] rcu_do_batch+0x184/0x460 rcu_core+0xf4/0x1f8 handle_softirqs+0x118/0x330 Use rcu_work to defer the cleanup to a workqueue. rcu_work dispatches the worker asynchronously after the RCU grace period, so no thread blocks waiting, and concurrent releases of multiple SAs naturally share the same grace period. Fixes: c09440f7dcb3 ("macsec: introduce IEEE 802.1AE driver") Signed-off-by: Jinliang Zheng <alexjlzheng@tencent.com> Reviewed-by: Sabrina Dubroca <sd@queasysnail.net> Link: https://patch.msgid.link/20260511153102.2640368-3-alexjlzheng@tencent.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-13bpf: Report maximum combined stack depthPaul Chaignon
We've hit the 512 bytes limit on stack depth a few times in Cilium recently. As a result, we started reporting in CI our current maximum stack depth across all configurations for each BPF program. Unfortunately, that is not trivial to compute in userspace. The verifier reports the stack depths of individual subprogs at the end of the logs. However the maximum combined stack depth also depends on the callgraph of those subprogs (the max combined stack depth is the height of the callgraph weighted by per-subprog stack depths). We can compute a callgraph in userspace from the loaded instructions, but it often doesn't match the verifier's own callgraph because of dead code elimination. Our current approach relies on dumping the BPF_LOG_LEVEL2 logs, but this feels overkill considering the verifier already has the information we need. The patch lets the verifier dump the maximum combined stack depth in the logs, on the same line as the per-subprog stack depths: stack depth 16+256 max 272 The per-subprog stack depths and the new max stack depth are not directly comparable. The former is sometimes updated during fixups, while the latter is not. As a result, even with a single subprog, we may end up with two slightly different values. The aim of the new max value is to be closest to what is actually enforced by the verifier. Signed-off-by: Paul Chaignon <paul.chaignon@gmail.com> Acked-by: Eduard Zingerman <eddyz87@gmail.com> Link: https://lore.kernel.org/r/d3d23a0410f87f116f3bbaa98a815dbae113bda2.1778700777.git.paul.chaignon@gmail.com Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2026-05-13netconsole: move find_skb() from netpollBreno Leitao
find_skb() is the netconsole-specific entry into the netpoll skb pool: every other netpoll consumer (bonding, team, vlan, bridge, macvlan, dsa) builds its own sk_buff and never touches the pool. With netpoll_send_udp() (its only caller) now living in netconsole, find_skb() can join it. Move find_skb() into drivers/net/netconsole.c as a file-static helper, drop EXPORT_SYMBOL_GPL(find_skb) and remove its prototype from include/linux/netpoll.h. find_skb() drains TX completions via netpoll_zap_completion_queue(), which is already exported in the NETDEV_INTERNAL namespace, so netconsole picks up MODULE_IMPORT_NS("NETDEV_INTERNAL") to consume it. The skb pool's lifecycle (np->skb_pool, np->refill_wq, refill_skbs(), refill_skbs_work_handler(), skb_pool_flush()) stays in netpoll: it is initialised in __netpoll_setup() and torn down in __netpoll_cleanup(), both of which remain netpoll's responsibility. The refill work queued via schedule_work(&np->refill_wq) from the moved find_skb() runs refill_skbs_work_handler() in netpoll without any further plumbing. This is pure code motion: the function body is unchanged and its sole caller (netpoll_send_udp(), already moved by an earlier patch) keeps invoking it the same way. Pre-existing concerns about find_skb() running from NMI/printk context (zap_completion_queue() re-entry, skb_pool spinlocks, GFP_ATOMIC allocation, fallback skb sizing vs. MAX_SKB_SIZE, PREEMPT_RT semantics of __kfree_skb()) are inherited as-is and are not addressed here; they predate this series and are out of scope. Fixing them is left for follow-up work. Signed-off-by: Breno Leitao <leitao@debian.org> Link: https://patch.msgid.link/20260512-netconsole_split-v2-9-1191d14ad66d@debian.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-13netpoll: rename and export netpoll_zap_completion_queue()Breno Leitao
zap_completion_queue() drains the per-CPU softnet completion queue. Rename it with the netpoll_ prefix shared by the rest of the subsystem's public API, and promote it from file-static to EXPORT_SYMBOL_NS_GPL in the NETDEV_INTERNAL namespace so the upcoming netconsole-side find_skb() can call it once the function moves out. A forward declaration is added to include/linux/netpoll.h, and the old file-static forward declaration is dropped. No functional change. Suggested-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Breno Leitao <leitao@debian.org> Link: https://patch.msgid.link/20260512-netconsole_split-v2-8-1191d14ad66d@debian.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-13netconsole: move netpoll_udp_checksum() from netpollBreno Leitao
netpoll_udp_checksum() computes the UDP checksum for netconsole's packets. Move it into drivers/net/netconsole.c as a file-static helper; drop its EXPORT_SYMBOL_GPL and remove the prototype from include/linux/netpoll.h. This was the last csum_ipv6_magic() consumer in net/core/netpoll.c, so drop the now-stale <net/ip6_checksum.h> include there. Pull it into netconsole.c so the moved code keeps building. It was also the last udp_hdr() consumer in net/core/netpoll.c. The file no longer needs anything from <net/udp.h> (the UDP socket-layer helpers); MAX_SKB_SIZE only needs struct udphdr, which is provided by the lighter <linux/udp.h>. Swap the include accordingly. Signed-off-by: Breno Leitao <leitao@debian.org> Link: https://patch.msgid.link/20260512-netconsole_split-v2-7-1191d14ad66d@debian.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-13netconsole: move push_udp() from netpollBreno Leitao
push_udp() builds the UDP header (and triggers the checksum) for netconsole's UDP packets. Move it into drivers/net/netconsole.c as a file-static helper; drop its EXPORT_SYMBOL_GPL and remove the prototype from include/linux/netpoll.h. Signed-off-by: Breno Leitao <leitao@debian.org> Link: https://patch.msgid.link/20260512-netconsole_split-v2-6-1191d14ad66d@debian.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-13netconsole: move push_eth() from netpollBreno Leitao
push_eth() builds the Ethernet header for netconsole's UDP packets. Move it into drivers/net/netconsole.c as a file-static helper; drop its EXPORT_SYMBOL_GPL and remove the prototype from include/linux/netpoll.h. Signed-off-by: Breno Leitao <leitao@debian.org> Link: https://patch.msgid.link/20260512-netconsole_split-v2-5-1191d14ad66d@debian.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-13netconsole: move push_ipv4() from netpollBreno Leitao
push_ipv4() builds the IPv4 header for netconsole's UDP packets. Move it into drivers/net/netconsole.c as a file-static helper; drop its EXPORT_SYMBOL_GPL and remove the prototype from include/linux/netpoll.h. put_unaligned() is no longer used in net/core/netpoll.c, so drop the now-stale <linux/unaligned.h> include from there. Pull it into netconsole.c so the moved code keeps building. Signed-off-by: Breno Leitao <leitao@debian.org> Link: https://patch.msgid.link/20260512-netconsole_split-v2-4-1191d14ad66d@debian.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-13netconsole: move push_ipv6() from netpollBreno Leitao
push_ipv6() builds the IPv6 header for netconsole's UDP packets. Its only caller, netpoll_send_udp(), now lives in netconsole, so the helper can move there as a file-static function. Drop its EXPORT_SYMBOL_GPL and remove the prototype from include/linux/netpoll.h. Signed-off-by: Breno Leitao <leitao@debian.org> Link: https://patch.msgid.link/20260512-netconsole_split-v2-3-1191d14ad66d@debian.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-13netconsole: move netpoll_send_udp() from netpollBreno Leitao
Move netpoll_send_udp() from net/core/netpoll.c into drivers/net/netconsole.c as a static helper, drop EXPORT_SYMBOL(), and remove the prototype from include/linux/netpoll.h. netconsole was the only in-tree caller of this entry point. Every other netpoll consumer (bonding, team, vlan, bridge, macvlan, dsa) already builds its own sk_buff and hands it to netpoll_send_skb(), so the netpoll send-side interface is now skb-only. The helpers it depends on (find_skb(), push_ipv6(), push_ipv4(), push_udp(), push_eth(), netpoll_udp_checksum()) were exposed in the previous patches and stay in net/core/netpoll.c for now. Subsequent patches move each of them into netconsole one at a time and drop the corresponding EXPORT_SYMBOL_GPL. Pull <linux/ip.h>, <linux/ipv6.h> and <linux/udp.h> into netconsole.c so the moved code can name the header structures. Signed-off-by: Breno Leitao <leitao@debian.org> Link: https://patch.msgid.link/20260512-netconsole_split-v2-2-1191d14ad66d@debian.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-13netpoll: expose UDP packet builder helpers for netconsoleBreno Leitao
Promote each from file-static to EXPORT_SYMBOL_GPL and forward- declare them in include/linux/netpoll.h so netconsole can call them once netpoll_send_udp() moves out. These exports are kept until the end of the series, when al of them move into netconsole. No functional change. Signed-off-by: Breno Leitao <leitao@debian.org> Link: https://patch.msgid.link/20260512-netconsole_split-v2-1-1191d14ad66d@debian.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-13ptr_ring: move free-space check into separate helperSimon Schippers
This patch moves the check for available free space for a new entry into a separate function. Existing callers that only check for a non-zero return value are unaffected; __ptr_ring_produce() now returns -EINVAL for a zero-size ring and -ENOSPC when full, whereas before both cases returned -ENOSPC. The new helper allows callers to determine in advance whether subsequent __ptr_ring_produce() calls will succeed. This information can, for example, be used to temporarily stop producing until __ptr_ring_check_produce() indicates that space is available again. Co-developed-by: Tim Gebauer <tim.gebauer@tu-dortmund.de> Signed-off-by: Tim Gebauer <tim.gebauer@tu-dortmund.de> Signed-off-by: Simon Schippers <simon.schippers@tu-dortmund.de> Acked-by: Michael S. Tsirkin <mst@redhat.com> Link: https://patch.msgid.link/20260510151529.43895-4-simon.schippers@tu-dortmund.de Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-13vhost-net: wake queue of tun/tap after ptr_ring consumeSimon Schippers
Add tun_wake_queue() to tun.c and export it for use by vhost-net. The function validates that the file belongs to a tun/tap device and that the tfile exists, dereferences the tun_struct under RCU, and delegates to __tun_wake_queue(). vhost_net_buf_produce() now calls tun_wake_queue() after a successful batched consume of the ring to allow the netdev subqueue to be woken up. The point is to allow the queue to be stopped when it gets full, which is required for traffic shaping - implemented by the following "avoid ptr_ring tail-drop when a qdisc is present". Without the corresponding queue stopping, this patch alone causes no throughput regression for a tap+vhost-net setup sending to a qemu VM: 3.857 Mpps to 3.891 Mpps. Details: AMD Ryzen 5 5600X at 4.3 GHz, 3200 MHz RAM, isolated QEMU threads, XDP drop program active in VM, pktgen sender; Avg over 50 runs @ 100,000,000 packets. SRSO and spectre v2 mitigations disabled. Co-developed-by: Tim Gebauer <tim.gebauer@tu-dortmund.de> Signed-off-by: Tim Gebauer <tim.gebauer@tu-dortmund.de> Signed-off-by: Simon Schippers <simon.schippers@tu-dortmund.de> Acked-by: Michael S. Tsirkin <mst@redhat.com> Link: https://patch.msgid.link/20260510151529.43895-3-simon.schippers@tu-dortmund.de Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-14ASoC: sdw_utils: add soc_sdw_es9356Zhang Yi
Add a utility program for handling ES9356 in the universal machine driver Signed-off-by: Zhang Yi <zhangyi@everest-semi.com> Link: https://patch.msgid.link/20260513031554.5422-2-zhangyi@everest-semi.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-05-13mm/page_alloc: fix initialization of tags of the huge zero folio with ↵David Hildenbrand (Arm)
init_on_free __GFP_ZEROTAGS semantics are currently a bit weird, but effectively this flag is only ever set alongside __GFP_ZERO and __GFP_SKIP_KASAN. If we run with init_on_free, we will zero out pages during __free_pages_prepare(), to skip zeroing on the allocation path. However, when allocating with __GFP_ZEROTAG set, post_alloc_hook() will consequently not only skip clearing page content, but also skip clearing tag memory. Not clearing tags through __GFP_ZEROTAGS is irrelevant for most pages that will get mapped to user space through set_pte_at() later: set_pte_at() and friends will detect that the tags have not been initialized yet (PG_mte_tagged not set), and initialize them. However, for the huge zero folio, which will be mapped through a PMD marked as special, this initialization will not be performed, ending up exposing whatever tags were still set for the pages. The docs (Documentation/arch/arm64/memory-tagging-extension.rst) state that allocation tags are set to 0 when a page is first mapped to user space. That no longer holds with the huge zero folio when init_on_free is enabled. Fix it by decoupling __GFP_ZEROTAGS from __GFP_ZERO, passing to tag_clear_highpages() whether we want to also clear page content. Invert the meaning of the tag_clear_highpages() return value to have clearer semantics. Reproduced with the huge zero folio by modifying the check_buffer_fill arm64/mte selftest to use a 2 MiB area, after making sure that pages have a non-0 tag set when freeing (note that, during boot, we will not actually initialize tags, but only set KASAN_TAG_KERNEL in the page flags). $ ./check_buffer_fill 1..20 ... not ok 17 Check initial tags with private mapping, sync error mode and mmap memory not ok 18 Check initial tags with private mapping, sync error mode and mmap/mprotect memory ... This code needs more cleanups; we'll tackle that next, like decoupling __GFP_ZEROTAGS from __GFP_SKIP_KASAN. [akpm@linux-foundation.org: s/__GPF_ZERO/__GFP_ZERO/, per David] Link: https://lore.kernel.org/20260421-zerotags-v2-1-05cb1035482e@kernel.org Fixes: adfb6609c680 ("mm/huge_memory: initialise the tags of the huge zero folio") Signed-off-by: David Hildenbrand (Arm) <david@kernel.org> Reviewed-by: Catalin Marinas <catalin.marinas@arm.com> Tested-by: Lance Yang <lance.yang@linux.dev> Cc: Brendan Jackman <jackmanb@google.com> Cc: Dev Jain <dev.jain@arm.com> Cc: Johannes Weiner <hannes@cmpxchg.org> Cc: Liam Howlett <liam@infradead.org> Cc: Lorenzo Stoakes (Oracle) <ljs@kernel.org> Cc: Mark Brown <broonie@kernel.org> Cc: Michal Hocko <mhocko@suse.com> Cc: Mike Rapoport <rppt@kernel.org> Cc: Ryan Roberts <ryan.roberts@arm.com> Cc: Suren Baghdasaryan <surenb@google.com> Cc: Will Deacon <will@kernel.org> Cc: Zi Yan <ziy@nvidia.com> Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2026-05-13mm/damon: fix damos_stat tracepoint format for sz_appliedSeongJae Park
The print format is wrongly marking sz_applied as sz_tried. Fix it. Link: https://lore.kernel.org/20260426193119.88095-1-sj@kernel.org Fixes: 804c26b961da ("mm/damon/core: add trace point for damos stat per apply interval") Signed-off-by: SeongJae Park <sj@kernel.org> Cc: "Masami Hiramatsu (Google)" <mhiramat@kernel.org> Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com> Cc: Steven Rostedt <rostedt@goodmis.org> Cc: <stable@vger.kernel.org> # 7.0.x Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2026-05-13Drivers: hv: vmbus: Provide option to skip VMBus unload on panicMichael Kelley
Currently, VMBus code initiates a VMBus unload in the panic path so that if a kdump kernel is loaded, it can start fresh in setting up its own VMBus connection. However, a driver for the VMBus virtual frame buffer may need to flush dirty portions of the frame buffer back to the Hyper-V host so that panic information is visible in the graphics console. To support such flushing, provide exported functions for the frame buffer driver to specify that the VMBus unload should not be done by the VMBus driver, and to initiate the VMBus unload itself. Together these allow a frame buffer driver to delay the VMBus unload until after it has completed the flush. Ideally, the VMBus driver could use its own panic-path callback to do the unload after all frame buffer drivers have finished. But DRM frame buffer drivers use the kmsg dump callback, and there are no callbacks after that in the panic path. Hence this somewhat messy approach to properly sequencing the frame buffer flush and the VMBus unload. Fixes: 3671f3777758 ("drm/hyperv: Add support for drm_panic") Signed-off-by: Michael Kelley <mhklinux@outlook.com> Reviewed-by: Long Li <longli@microsoft.com> Signed-off-by: Wei Liu <wei.liu@kernel.org>
2026-05-13Merge tag 'sched_ext-for-7.1-rc3-fixes' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/tj/sched_ext Pull sched_ext fixes from Tejun Heo: "The bulk of this is hardening of the new sub-scheduler infrastructure. - UAFs and lifecycle bugs on the sub-sched attach/detach paths: parent sub_kset freed under a racing child, list_del_rcu on an uninitialized list head, ops->priv stomped by concurrent attach/detach, and a UAF in the init-failure error path - Task state-machine reorg closing concurrent enable-vs-dead races: a task exiting during the unlocked init window could trip NULL ops derefs or skip exit_task() cleanup - A scx_link_sched() self-deadlock on scx_sched_lock - isolcpus: stop dereferencing the now-RCU-protected HK_TYPE_DOMAIN cpumask without RCU, and stop rejecting BPF schedulers when only cpuset isolated partitions are active - PREEMPT_RT: disable irq_work runs in hardirq context so dumps show the failing task rather than the irq_work kthread - Assorted !CONFIG_EXT_SUB_SCHED, randconfig, and selftest build fixes" * tag 'sched_ext-for-7.1-rc3-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/sched_ext: sched_ext: Use HK_TYPE_DOMAIN_BOOT to detect isolcpus= domain isolation sched_ext: Defer sub_kset base put to scx_sched_free_rcu_work sched_ext: INIT_LIST_HEAD() &sch->all in scx_alloc_and_add_sched() sched_ext: Drop NONE early return in scx_disable_and_exit_task() sched_ext: Avoid UAF in scx_root_enable_workfn() init failure path sched_ext: Clear ops->priv on scx_alloc_and_add_sched() error paths sched_ext: Fix ops->priv clobber on concurrent attach/detach selftests/sched_ext: Fix build error in dequeue selftest sched_ext: Handle SCX_TASK_NONE in disable/switched_from paths sched_ext: Close sub-sched init race with post-init DEAD recheck sched_ext: Close root-enable vs sched_ext_dead() race with SCX_TASK_INIT_BEGIN sched_ext: Replace SCX_TASK_OFF_TASKS flag with SCX_TASK_DEAD state sched_ext: Inline scx_init_task() and move RESET_RUNNABLE_AT into scx_set_task_state() sched_ext: Cleanups in preparation for the SCX_TASK_INIT_BEGIN/DEAD work sched_ext: Use IRQ_WORK_INIT_HARD() to initialize sch->disable_irq_work sched_ext: Fix !CONFIG_EXT_SUB_SCHED build warnings sched_ext: Drop unused scx_find_sub_sched() stub sched_ext: Move scx_error() out of scx_link_sched()'s lock region
2026-05-14drm/virtio: Extend blob UAPI with deferred-mapping hintingDmitry Osipenko
If userspace never maps GEM object, then BO wastes hostmem space because VirtIO-GPU driver maps VRAM BO at the BO's creating time. Make mappings on-demand by adding new RESOURCE_CREATE_BLOB IOCTL/UAPI hinting flag telling that host mapping should be deferred until first mapping is made when the flag is set by userspace. Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com> Reviewed-by: Rob Clark <robdclark@gmail.com> Link: https://patch.msgid.link/20260501000043.2483678-1-dmitry.osipenko@collabora.com
2026-05-13Merge tag 'cgroup-for-7.1-rc3-fixes' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/tj/cgroup Pull cgroup fixes from Tejun Heo: - cpuset fixes: - Partition invalidation could return CPUs still in use by sibling partitions, producing overlapping effective_cpus - cpuset_can_attach() over-reserved DL bandwidth on moves that stayed within the same root domain - Pending DL migration state leaked into later attaches when a later can_attach() check failed - Reorder PF_EXITING and __GFP_HARDWALL checks so dying tasks can allocate from any node and exit quickly - dmem: propagate -ENOMEM instead of spinning forever when the fallback pool allocation also fails - selftests/cgroup: percpu test error-path leak, bogus numeric comparison of cpuset strings, and a zero-length read() that silently passed OOM-kill tests * tag 'cgroup-for-7.1-rc3-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/cgroup: cgroup/cpuset: Return only actually allocated CPUs during partition invalidation selftests/cgroup: Fix error path leaks in test_percpu_basic cgroup/cpuset: Reserve DL bandwidth only for root-domain moves cgroup/cpuset: Reset DL migration state on can_attach() failure selftests/cgroup: Fix string comparison in write_test selftests/cgroup: Fix cg_read_strcmp() empty string comparison cgroup/dmem: Return -ENOMEM on failed pool preallocation cgroup/cpuset: move PF_EXITING check before __GFP_HARDWALL in cpuset_current_node_allowed()
2026-05-13vfio/pci: Make VFIO_PCI_OFFSET_TO_INDEX() return unsignedMatt Evans
VFIO_PCI_OFFSET_TO_INDEX() is used in several places with a signed parameter (e.g. loff_t). Because it makes no sense for a BAR/resource index to be negative, enforce this in the macro. This fixes at least one current issue, where vfio_pci_ioeventfd() uses this macro with an unvalidated signed loff_t returned into a signed type, leading to a possible negative array access. This instance does test against an out-of-bounds positive value, so treating the index as unsigned fixes this issue. Fixes: 89e1f7d4c66d8 ("vfio: Add PCI device driver") Signed-off-by: Matt Evans <mattev@meta.com> Link: https://lore.kernel.org/r/20260511144642.2926799-1-mattev@meta.com Signed-off-by: Alex Williamson <alex@shazbot.org>
2026-05-13block: pass a minsize argument to bio_iov_iter_bounceChristoph Hellwig
When bouncing for block size > PAGE_SIZE file systems that require file system block size alignment (e.g. zoned XFS), the bio needs to be big enough to fit an entire block. Fixes: 8dd5e7c75d7b ("block: add helpers to bounce buffer an iov_iter into bios") Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Hannes Reinecke <hare@kernel.org> Link: https://patch.msgid.link/20260507050153.1298375-2-hch@lst.de Signed-off-by: Jens Axboe <axboe@kernel.dk>
2026-05-13thermal: hwmon: Use extra_groups for adding temperature attributesRafael J. Wysocki
Instead of passing NULL as the last argument to __hwmon_device_register() in hwmon_device_register_for_thermal() and then adding each temperature sysfs attribute to the hwmon device via device_create_file(), redefine hwmon_device_register_for_thermal() to take an extra_groups argument that will be passed to __hwmon_device_register(), define an attribute group with a proper .is_visible() callback for the temperature attributes and a related attribute groups pointer, and pass the latter to hwmon_device_register_for_thermal(). This causes the code to be way more straightforward and closer to what the other users of the hwmon subsystem do. No intentional functional impact. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Link: https://patch.msgid.link/8704209.T7Z3S40VBb@rafael.j.wysocki Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2026-05-13Merge tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvmLinus Torvalds
Pull kvm fixes from Paolo Bonzini: "arm64: - Add the pKVM side of the workaround for ARM's erratum 4193714, provided that the EL3 firmware does its part of the job. KVM will refuse to initialise otherwise - Correctly handle 52bit VAs for guest EL2 stage-1 translations when running under NV with E2H==0 - Correctly deal with permission faults in guest_memfd memslots - Fix the steal-time selftest after the infrastructure was reworked - Make sure the host cannot pass a non-sensical clock update to the EL2 tracing infrastructure - Appoint Steffen Eiden as a reviewer in anticipation of the KVM/s390 ability to run arm64 guests, which will inevitably lead to arm64 code being directly used on s390 - Make sure that EL2 is configured with both exception entry and exit being Context Synchronization Events - Handle the current vcpu being NULL on EL2 panic - Fix the selftest_vcpu memcache being empty at the point of donation or sharing - Check that the memcache has enough capacity before engaging on the share/donate path - Fix __deactivate_fgt() to use its parameter rather than a variable in the macro context s390: - Fix array overrun with large amounts of PCI devices x86: - Never use L0's PAUSE loop exiting while L2 is running, since it's unlikely that a nested guest will help solving the hypervisor's spinlock contention - Fix emulation of MOVNTDQA - Fix typo in Xen hypercall tracepoint - Add back an optimization that was left behind when recently fixing a bug - Add module parameter to disable CET, whose implementation seems to have issues. For now it remains enabled by default Generic: - Reject offset causing an unsigned overflow in kvm_reset_dirty_gfn() Documentation: - Update stale links Selftests: - Fix guest_memfd_test with host page size > guest page size" * tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm: (22 commits) KVM: VMX: introduce module parameter to disable CET KVM: x86: Swap the dst and src operand for MOVNTDQA KVM: x86: use again the flush argument of __link_shadow_page() KVM: selftests: Ensure gmem file sizes are multiple of host page size Documentation: kvm: update links in the references section of AMD Memory Encryption KVM: nSVM: Never use L0's PAUSE loop exiting while L2 is running KVM: x86: Fix Xen hypercall tracepoint argument assignment KVM: Reject wrapped offset in kvm_reset_dirty_gfn() KVM: arm64: Pre-check vcpu memcache for host->guest donate KVM: arm64: Pre-check vcpu memcache for host->guest share KVM: arm64: Seed pkvm_ownership_selftest vcpu memcache KVM: arm64: Fix __deactivate_fgt macro parameter typo KVM: arm64: Guard against NULL vcpu on VHE hyp panic path KVM: arm64: Make EL2 exception entry and exit context-synchronization events MAINTAINERS: Add Steffen as reviewer for KVM/arm64 KVM: arm64: Remove potential UB on nvhe tracing clock update KVM: selftests: arm64: Fix steal_time test after UAPI refactoring KVM: arm64: Handle permission faults with guest_memfd KVM: arm64: nv: Consider the DS bit when translating TCR_EL2 KVM: arm64: Work around C1-Pro erratum 4193714 for protected guests ...
2026-05-13KVM: Fix kvm_vcpu_map[_readonly]() function prototypesPeter Fang
kvm_vcpu_map() and kvm_vcpu_map_readonly() should take a gfn instead of a gpa. This appears to be a result of the original kvm_vcpu_map() being declared with the wrong function prototype in kvm_host.h, even though it was correct in the actual implementation in kvm_main.c. No actual harm has been done yet as all of the call sites are correctly passing in a gfn. Plus, both gfn_t and gpa_t are typedef'd to u64 so this change shouldn't have any functional impact. Compile-tested on x86 and ppc, which are the current users of these interfaces. Fixes: e45adf665a53 ("KVM: Introduce a new guest mapping API") Cc: KarimAllah Ahmed <karahmed@amazon.de> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Signed-off-by: Peter Fang <peter.fang@intel.com> Reviewed-by: Yosry Ahmed <yosry@kernel.org> Link: https://patch.msgid.link/20260408001137.3290444-2-peter.fang@intel.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-05-13crypto/ccp: export firmware supported vm typesTycho Andersen
In some configurations, the firmware does not support all VM types. The SEV firmware has an entry in the TCB_VERSION structure referred to as the Security Version Number in the SEV-SNP firmware specification and referred to as the "SPL" in SEV firmware release notes. The SEV firmware release notes say: On every SEV firmware release where a security mitigation has been added, the SNP SPL gets increased by 1. This is to let users know that it is important to update to this version. The SEV firmware release that fixed CVE-2025-48514 by disabling SEV-ES support on vulnerable platforms has this SVN increased to reflect the fix. The SVN is platform-specific, as is the structure of TCB_VERSION. Check CURRENT_TCB instead of REPORTED_TCB, since the firmware behaves with the CURRENT_TCB SVN level and will reject SEV-ES VMs accordingly. Parse the SVN, and mask off the SEV_ES supported VM type from the list of supported types if it is above the per-platform threshold for the relevant platforms. Signed-off-by: Tycho Andersen (AMD) <tycho@kernel.org> Acked-by: Herbert Xu <herbert@gondor.apana.org.au> Reviewed-by: Tom Lendacky <thomas.lendacky@amd.com> Tested-by: Tycho Andersen (AMD) <tycho@kernel.org> Link: https://patch.msgid.link/20260416232329.3408497-3-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-05-13KVM: Rename invalidate_begin to invalidate_start for consistencyTakahiro Itazuri
Rename kvm_mmu_invalidate_begin() to kvm_mmu_invalidate_start() to align with mmu_notifier_ops.invalidate_range_start(), which is the callback that ultimately drives KVM's MMU invalidation. While the naming within KVM itself is a close split between "_begin" and "_start": $ git grep -E "invalidate(_range)?_begin" **/kvm* | wc -l 12 $ git grep -E "invalidate(_range)?_start" **/kvm* | wc -l 21 All two of the begin() uses are in KVM: $ git grep -E "invalidate(_range)?_begin" * | wc -l 14 And those two holdouts are bugs in invalidate_range_start()'s comment, i.e. will also be fixed sooner or later[*]. On the other hand, use of _start() is pervasive throughout the kernel: $ git grep -E "invalidate(_range)?_start" * | wc -l 117 Even if that weren't the case, conforming to the mmu_notifier_ops naming is the right call since invalidate_range_start() is the external API that KVM hooks into. No functional change intended. Link: https://lore.kernel.org/all/20260513163546.1176742-1-seanjc@google.com [*] Signed-off-by: Takahiro Itazuri <itazur@amazon.com> Link: https://patch.msgid.link/20260420154720.29012-4-itazur@amazon.com [sean: massage changelog to provide more (accurate) numbers] Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-05-13dt-bindings: clock: qcom: Add Hawi global clock controllerVivek Aknurwar
Add device tree bindings for the global clock controller on the Qualcomm Hawi SoC. Acked-by: Rob Herring (Arm) <robh@kernel.org> Reviewed-by: Mike Tipton <mike.tipton@oss.qualcomm.com> Signed-off-by: Vivek Aknurwar <vivek.aknurwar@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260506-clk-hawi-v3-3-530b538679f1@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-05-13dt-bindings: clock: qcom: Add Hawi TCSR clock controllerVivek Aknurwar
Add bindings documentation for TCSR clock controller on the Qualcomm Hawi SoC. Acked-by: Rob Herring (Arm) <robh@kernel.org> Reviewed-by: Mike Tipton <mike.tipton@oss.qualcomm.com> Signed-off-by: Vivek Aknurwar <vivek.aknurwar@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260506-clk-hawi-v3-2-530b538679f1@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-05-13dt-bindings: clock: qcom-rpmhcc: Add RPMHCC bindings for HawiVivek Aknurwar
Update documentation for the RPMH clock controller on the Qualcomm Hawi SoC. Acked-by: Rob Herring (Arm) <robh@kernel.org> Reviewed-by: Mike Tipton <mike.tipton@oss.qualcomm.com> Signed-off-by: Vivek Aknurwar <vivek.aknurwar@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260506-clk-hawi-v3-1-530b538679f1@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-05-13soc: qcom: llcc-qcom: Capitalize LLCC/EDAC in comments and diagnosticsFrancisco Munoz Ruiz
Capitalize occurrences of the acronym "LLCC" and "EDAC" in comments and diagnostic text to improve consistency and readability. Signed-off-by: Francisco Munoz Ruiz <francisco.ruiz@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Reviewed-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260407-external_llcc_changes2set-v2-3-b5017ce2020b@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-05-13soc: qcom: llcc-qcom: get SCT descriptors from fw-populated memoryFrancisco Munoz Ruiz
Retrieve System Cache Table (SCT) descriptors from a shared memory region populated by firmware. SCT initialization and programming are performed entirely by firmware outside of Linux. The LLCC driver only consumes the pre-initialized descriptor data and does not configure SCT itself. Support this mechanism for future SoCs that provide SCT programming via firmware. Signed-off-by: Francisco Munoz Ruiz <francisco.ruiz@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260407-external_llcc_changes2set-v2-2-b5017ce2020b@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-05-13bpf,x86: Implement JIT support for stack argumentsYonghong Song
Add x86_64 JIT support for BPF functions and kfuncs with more than 5 arguments. The extra arguments are passed through a stack area addressed by register r11 (BPF_REG_PARAMS) in BPF bytecode, which the JIT translates to native code. The JIT follows the x86-64 calling convention for both BPF-to-BPF and kfunc calls: - Arg 6 is passed in the R9 register - Args 7+ are passed on the stack Incoming arg 6 (BPF r11+8) is translated to a MOV from R9 rather than a memory load. Incoming args 7+ (BPF r11+16, r11+24, ...) map directly to [rbp + 16], [rbp + 24], ..., matching the x86-64 stack layout after CALL + PUSH RBP, so no offset adjustment is needed. tail_call_reachable is rejected by the verifier and priv_stack is disabled by the JIT when stack args exist, so R9 is always available. When BPF bytecode writes to the arg-6 stack slot (offset -8), the JIT emits a MOV into R9 instead of a memory store. Outgoing args 7+ are placed at [rsp] in a pre-allocated area below callee-saved registers, using: native_off = outgoing_arg_base - outgoing_rsp - bpf_off - 16 The native x86_64 stack layout with stack arguments: high address +-------------------------+ | incoming stack arg N | [rbp + 16 + (N-7)*8] (from caller) | ... | | incoming stack arg 7 | [rbp + 16] +-------------------------+ | return address | [rbp + 8] | saved rbp | [rbp] +-------------------------+ | BPF program stack | (round_up(stack_depth, 8) bytes) +-------------------------+ | callee-saved regs | (r12, rbx, r13, r14, r15 as needed) +-------------------------+ | outgoing arg M | [rsp + (M-7)*8] | ... | | outgoing arg 7 | [rsp] +-------------------------+ rsp low address Acked-by: Puranjay Mohan <puranjay@kernel.org> Signed-off-by: Yonghong Song <yonghong.song@linux.dev> Link: https://lore.kernel.org/r/20260513045122.2393118-1-yonghong.song@linux.dev Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2026-05-13bpf: Prepare architecture JIT support for stack argumentsYonghong Song
Add bpf_jit_supports_stack_args() as a weak function defaulting to false. Architectures that implement JIT support for stack arguments override it to return true. Reject BPF functions with more than 5 parameters at verification time if the architecture does not support stack arguments. Acked-by: Puranjay Mohan <puranjay@kernel.org> Signed-off-by: Yonghong Song <yonghong.song@linux.dev> Link: https://lore.kernel.org/r/20260513045054.2390945-1-yonghong.song@linux.dev Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2026-05-13bpf: Add precision marking and backtracking for stack argument slotsYonghong Song
Extend the precision marking and backtracking infrastructure to support stack argument slots (r11-based accesses). Without this, precision demands for scalar values passed through stack arguments are silently dropped, which could allow the verifier to incorrectly prune states with different constant values in stack arg slots. Signed-off-by: Yonghong Song <yonghong.song@linux.dev> Link: https://lore.kernel.org/r/20260513045025.2387526-1-yonghong.song@linux.dev Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2026-05-13bpf: Refactor jmp history to use dedicated spi/frame fieldsYonghong Song
Move stack slot index (spi) and frame number out of the flags field in bpf_jmp_history_entry into dedicated bitfields. This simplifies the encoding and makes room for new flags. Previously, spi and frame were packed into the lower 9 bits of the 12-bit flags field (3 bits frame + 6 bits spi), with INSN_F_STACK_ACCESS at BIT(9) and INSN_F_DST/SRC_REG_STACK at BIT(10)/BIT(11). But this has no room for an INSN_F_* flag for stack arguments. To resolve this issue, bpf_jmp_history_entry field idx is narrowed to 20 bits (sufficient for insn indices up to 1M), and the freed bits hold spi (6 bits) and frame (3 bits) as dedicated struct fields. The flags enum is simplified accordingly: INSN_F_STACK_ACCESS -> BIT(0) INSN_F_DST_REG_STACK -> BIT(1) INSN_F_SRC_REG_STACK -> BIT(2) which allows more room for additional INSN_F_* flags. bpf_push_jmp_history() now takes explicit spi and frame parameters instead of encoding them into flags. The insn_stack_access_flags(), insn_stack_access_spi(), and insn_stack_access_frameno() helpers are removed. No functional change. Signed-off-by: Yonghong Song <yonghong.song@linux.dev> Link: https://lore.kernel.org/r/20260513045020.2385962-1-yonghong.song@linux.dev Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2026-05-13bpf: Support stack arguments for bpf functionsYonghong Song
Currently BPF functions (subprogs) are limited to 5 register arguments. With [1], the compiler can emit code that passes additional arguments via a dedicated stack area through bpf register BPF_REG_PARAMS (r11), introduced in an earlier patch ([2]). The compiler uses positive r11 offsets for incoming (callee-side) args and negative r11 offsets for outgoing (caller-side) args, following the x86_64/arm64 calling convention direction. There is an 8-byte gap at offset 0 separating two regions: Incoming (callee reads): r11+8 (arg6), r11+16 (arg7), ... Outgoing (caller writes): r11-8 (arg6), r11-16 (arg7), ... The following is an example to show how stack arguments are saved and transferred between caller and callee: int foo(int a1, int a2, int a3, int a4, int a5, int a6, int a7) { ... bar(a1, a2, a3, a4, a5, a6, a7, a8); ... } Caller (foo) Callee (bar) ============ ============ Incoming (positive offsets): Incoming (positive offsets): r11+8: [incoming arg 6] r11+8: [incoming arg 6] <-+ r11+16: [incoming arg 7] r11+16: [incoming arg 7] <-|+ r11+24: [incoming arg 8] <-||+ Outgoing (negative offsets): ||| r11-8: [outgoing arg 6 to bar] -------->-------------------------+|| r11-16: [outgoing arg 7 to bar] -------->--------------------------+| r11-24: [outgoing arg 8 to bar] -------->---------------------------+ If the bpf function has more than one call: int foo(int a1, int a2, int a3, int a4, int a5, int a6, int a7) { ... bar1(a1, a2, a3, a4, a5, a6, a7, a8); ... bar2(a1, a2, a3, a4, a5, a6, a7, a8, a9); ... } Caller (foo) Callee (bar2) ============ ============== Incoming (positive offsets): Incoming (positive offsets): r11+8: [incoming arg 6] r11+8: [incoming arg 6] <+ r11+16: [incoming arg 7] r11+16: [incoming arg 7] <|+ r11+24: [incoming arg 8] <||+ Outgoing for bar2 (negative offsets): r11+32: [incoming arg 9] <|||+ r11-8: [outgoing arg 6] ---->----------->-------------------------+||| r11-16: [outgoing arg 7] ---->----------->--------------------------+|| r11-24: [outgoing arg 8] ---->----------->---------------------------+| r11-32: [outgoing arg 9] ---->----------->----------------------------+ The verifier tracks outgoing stack arguments in stack_arg_regs[] and out_stack_arg_cnt in bpf_func_state, separately from the regular r10 stack. The callee does not copy incoming args — it reads them directly from the caller's outgoing slots at positive r11 offsets. Similar to stacksafe(), introduce stack_arg_safe() to do pruning check. Outgoing stack arg slots are invalidated when the callee returns (e.g. in prepare_func_exit), not at call time. This allows the callee to read incoming args from the caller's outgoing slots during verification. The following are a few examples. Example 1: *(u64 *)(r11 - 8) = r6; *(u64 *)(r11 - 16) = r7; call bar1; // arg6 = r6, arg7 = r7 call bar2; // expected with 2 stack arguments, failed Example 2: To fix the Example 1: *(u64 *)(r11 - 8) = r6; *(u64 *)(r11 - 16) = r7; call bar1; // arg6 = r6, arg7 = r7 *(u64 *)(r11 - 8) = r8; *(u64 *)(r11 - 16) = r9; call bar2; // arg6 = r8, arg7 = r9 Example 3: The compiler can hoist the shared stack arg stores above the branch: *(u64 *)(r11 - 16) = r7; if cond goto else; *(u64 *)(r11 - 8) = r8; call bar1; // arg6 = r8, arg7 = r7 goto end; else: *(u64 *)(r11 - 8) = r9; call bar2; // arg6 = r9, arg7 = r7 end: Example 4: Within a loop: loop: *(u64 *)(r11 - 8) = r6; // arg6, before loop call bar; // reuses arg6 each iteration if ... goto loop; A separate max_out_stack_arg_cnt field in bpf_subprog_info tracks the deepest outgoing slot actually written. This intends to reject programs that write to slots beyond what any callee expects. It is necessary for JIT. Similar to typical compiler generated code, enforce the following orderings: - all stack arg reads must be ahead of any stack arg write - all stack arg reads must be before any bpf func, kfunc and helpers This is needed as JIT may emit 'mov' insns for read/write with the same register and bpf function, kfunc and helper will invalidate all arguments immediately after the call. Callback functions with stack arguments need kernel setup parameter types (including stack parameters) properly and then callback function can retrieve such information for verification purpose. Global subprogs and freplace with >5 args are not yet supported. [1] https://github.com/llvm/llvm-project/pull/189060 [2] https://lore.kernel.org/bpf/20260423033506.2542005-1-yonghong.song@linux.dev/ Signed-off-by: Yonghong Song <yonghong.song@linux.dev> Link: https://lore.kernel.org/r/20260513045015.2385013-1-yonghong.song@linux.dev Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2026-05-13bpf: Add helper functions for r11-based stack argument insnsYonghong Song
Add three static inline helper functions — is_stack_arg_ldx(), is_stack_arg_st(), and is_stack_arg_stx() — that identify r11-based (BPF_REG_PARAMS) instructions used for stack argument passing. These helpers encapsulate the detailed encoding requirements (operand size, register, offset alignment and sign) and hide raw BPF_REG_PARAMS usage from the verifier, making call sites more readable and explicit. A later patch ("bpf: Enable r11 based insns") will wire these helpers into the verifier. Until then, check_and_resolve_insns() rejects any r11-based registers. Signed-off-by: Yonghong Song <yonghong.song@linux.dev> Link: https://lore.kernel.org/r/20260513045005.2383881-1-yonghong.song@linux.dev Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2026-05-13bpf: Convert bpf_get_spilled_reg macro to static inline functionYonghong Song
Convert the bpf_get_spilled_reg() macro to a static inline function for better type safety and readability. This also simplifies the macro definition in preparation for upcoming stack argument support which will introduce additional macros. No functional change. Signed-off-by: Yonghong Song <yonghong.song@linux.dev> Link: https://lore.kernel.org/r/20260513044954.2382693-1-yonghong.song@linux.dev Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2026-05-13drm/ttm: Support 52-bit PAs in ttm_placeFelix Kuehling
fpfn and lpfn in struct ttm_place are 32-bit page numbers. With 4KB page size this can support up to 44-bit physical addressing. Grow these to 64-bit (uint64_t) to support larger physical addresses. Signed-off-by: Felix Kuehling <felix.kuehling@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Arunpravin Paneer Selvam <Arunpravin.PaneerSelvam@amd.com> Link: https://patch.msgid.link/20260513141253.20410-1-felix.kuehling@amd.com
2026-05-13drbd: clean up UAPI headersChristoph Böhmwalder
Commit b1798910fc7f ("drbd: move UAPI headers to include/uapi/linux/") broke compilation on targets without a hosted libc: ./usr/include/linux/drbd.h:18:10: fatal error: sys/types.h: No such file or directory The underlying issue is that there were some constructs left over in those headers that don't belong in uapi. Drop the __KERNEL__-gated split in drbd.h. The !__KERNEL__ branch pulls in <sys/types.h>, <sys/wait.h> and <limits.h> for symbols that the header does not actually reference; they were carried over from when this lived in include/linux/. Replace <asm/types.h> and the entire #ifdef block with the standard UAPI combo <linux/types.h> + <asm/byteorder.h>, which provides __u32/__u64/__s32 and __{LITTLE,BIG}_ENDIAN_BITFIELD in both kernel and userspace contexts. drbd_limits.h references some enum values and the DRBD_PROT_C define from drbd.h, but does not include it. Add the missing include while we're here. Drop the unprefixed DEBUG_RANGE_CHECK from drbd_limits.h. It has no in-kernel users and pollutes the userspace namespace. Switch the drbd.h and drbd_limits.h include guards to the _UAPI_LINUX_* convention already used by drbd_genl.h. Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202605101346.V2wwJqv1-lkp@intel.com/ Fixes: b1798910fc7f ("drbd: move UAPI headers to include/uapi/linux/") Signed-off-by: Christoph Böhmwalder <christoph.boehmwalder@linbit.com> Link: https://patch.msgid.link/20260513110343.3170338-1-christoph.boehmwalder@linbit.com Signed-off-by: Jens Axboe <axboe@kernel.dk>
2026-05-13Merge tag 'ib-mfd-gpio-v7.2' of ↵Bartosz Golaszewski
git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd into gpio/for-next Immutable branch between MFD and GPIO due for the v7.2 merge window
2026-05-12stddef: Document designated initializer semantics for __TRAILING_OVERLAP()Gustavo A. R. Silva
Document the designated initializer behavior for overlapping storage between NAME and MEMBERS, and clarify the implications for static initialization to help avoid unintended overwrites. Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org> Link: https://patch.msgid.link/agD0R-kNbg9YMOCT@kspp Signed-off-by: Kees Cook <kees@kernel.org>
2026-05-12dpll: add fractional frequency offset to pin-parent-deviceIvan Vecera
Add both fractional-frequency-offset (PPM) and fractional-frequency-offset-ppt (PPT) attributes to the pin-parent-device nested attribute set, alongside the existing top-level pin attributes. Both carry the same measurement at different precisions. Introduce enum dpll_ffo_type and struct dpll_ffo_param to distinguish FFO contexts: DPLL_FFO_PORT_RXTX_RATE for the RX vs TX symbol rate offset reported at the top level, and DPLL_FFO_PIN_DEVICE for the pin vs parent DPLL offset reported in the pin-parent-device nest. Add a supported_ffo bitmask to struct dpll_pin_ops so drivers declare which FFO types they support. The core only calls ffo_get for types the driver has opted into, eliminating the need for per-driver NULL pointer guards. Validate at pin registration time that supported_ffo is not set without an ffo_get callback. Update mlx5 (DPLL_FFO_PORT_RXTX_RATE) and zl3073x (DPLL_FFO_PORT_RXTX_RATE) drivers to use the new API. Add documentation for both FFO types to dpll.rst. Changes v3 -> v4: - Replace dpll=NULL overloading with enum dpll_ffo_type and struct dpll_ffo_param (Jakub Kicinski) - Add supported_ffo opt-in bitmask in dpll_pin_ops for fail-close driver validation (Jakub Kicinski) - Add WARN_ON in dpll_pin_register for supported_ffo without ffo_get callback Reviewed-by: Jiri Pirko <jiri@nvidia.com> Signed-off-by: Ivan Vecera <ivecera@redhat.com> Link: https://patch.msgid.link/20260511155816.99936-2-ivecera@redhat.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-12net: constify sk_skb_reason_drop() sock parameterEric Dumazet
sk_skb_reason_drop() does not change sock parameter, make it const so that we can call it from TCP stack without a cast on a (const) listener socket. Signed-off-by: Eric Dumazet <edumazet@google.com> Reviewed-by: David Ahern <dsahern@kernel.org> Reviewed-by: Kuniyuki Iwashima <kuniyu@google.com> Link: https://patch.msgid.link/20260511072310.1094859-2-edumazet@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-12rtnetlink: add RTEXT_FILTER_NAME_ONLY supportEric Dumazet
iproute2 can spend considerable amount of time in ll_init_map() or ll_link_get() to dump verbose netdev attributes, contributing to RTNL pressure. Add RTEXT_FILTER_NAME_ONLY new flag so that rtnl_fill_ifinfo() limits its output to: - struct nlmsghdr - IFLA_IFNAME - IFLA_PROP_LIST (alternate names) We can later avoid using RTNL when RTEXT_FILTER_NAME_ONLY is requested, as none of these attributes need RTNL. Signed-off-by: Eric Dumazet <edumazet@google.com> Reviewed-by: Kuniyuki Iwashima <kuniyu@google.com> Link: https://patch.msgid.link/20260511070244.971028-1-edumazet@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-13Merge patch series "rust: auxiliary: replace drvdata() with registration data"Danilo Krummrich
Danilo Krummrich <dakr@kernel.org> says: When drvdata() was introduced in commit 6f61a2637abe ("rust: device: introduce Device::drvdata()"), its commit message already noted that a direct accessor to the driver's bus device private data is not commonly required -- bus callbacks provide access through &self, and other entry points (IRQs, workqueues, IOCTLs, etc.) carry their own private data. The sole motivation for drvdata() was inter-driver interaction, e.g. a parent driver deriving its bus device private data from the child driver via the auxiliary bus. However, drvdata() exposes the driver's bus device private data beyond the driver's own scope. This creates ordering constraints -- drvdata may not be set yet when the first caller of drvdata() can appear -- and forces the driver's bus device private data to outlive all registrations that access it; a requirement that causes unnecessary complications. Private data should be private to the entity that issues it; bus device private data belongs to bus callbacks, class device private data to class callbacks, IRQ private data to the IRQ handler, etc. This series replaces drvdata() with a dedicated registration_data pointer on struct auxiliary_device. The parent stores its private data explicitly during registration; the data is private to the registration and lives as long as the Registration object. On teardown, Registration::drop() first triggers auxiliary_device_delete() (unbinding the child), then frees the registration data. Ordering constraints are structural -- the child's lifecycle is scoped to the registration by construction, not by convention. With no remaining use case for drvdata(), drvdata(), match_type_id(), set_type_id() and struct driver_type are removed. This is a prerequisite for [1], which builds on the removal of drvdata() to enable Higher-Ranked Lifetime Types (HRT) for Rust device drivers. [1] https://lore.kernel.org/driver-core/20260427221155.2144848-1-dakr@kernel.org/ Link: https://patch.msgid.link/20260505152400.3905096-1-dakr@kernel.org Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-05-12Merge branch ↵Bjorn Andersson
'20260106-qcom_ipq5332_cmnpll-v2-2-f9f7e4efbd79@oss.qualcomm.com' into clk-for-7.2 Merge the introduction of qcom,ipq5332-cmn-pll DeviceTree binding through a topic branch, to make it available to DeviceTree source tree as well.
2026-05-12dt-bindings: clock: qcom: Add CMN PLL support for IPQ5332 SoCLuo Jie
Add device tree bindings for the CMN PLL block in IPQ5332 SoC, which shares similarities with IPQ9574 but has different output clock frequencies. Add a new header file to export CMN PLL output clock specifiers for IPQ5332 SoC. Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Signed-off-by: Luo Jie <jie.luo@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260106-qcom_ipq5332_cmnpll-v2-2-f9f7e4efbd79@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-05-12bpf: Add syscall common attributes support for map_createLeon Hwang
Many BPF_MAP_CREATE validation failures currently return -EINVAL without any explanation to userspace. Plumb common syscall log attributes into map_create(), create a verifier log from bpf_common_attr::log_buf/log_size/log_level, and report map-creation failure reasons through that buffer. This improves debuggability by allowing userspace to inspect why map creation failed and read back log_true_size from common attributes. Signed-off-by: Leon Hwang <leon.hwang@linux.dev> Link: https://lore.kernel.org/r/20260512153157.28382-7-leon.hwang@linux.dev Signed-off-by: Alexei Starovoitov <ast@kernel.org>