Linux Plumbers Conference 2026

5 Oct 2026, 10:00 → 7 Oct 2026, 19:00 Europe/Prague

507 October, Prague, Czechia

The Linux Plumbers Conference is the premier event for developers working at all levels of the plumbing layer and beyond.

Monday 5 October

Android MC

The Android Micro Conference brings the upstream community and Android systems developers together to discuss issues and changes to the Android platform and their dependencies and interactions with the Linux kernel, allowing for collaboration on solutions for upstream.

Some highlights of progress made since last year’s MC:

• On 16k kernels, a set of recommendations were put together about how to reduce the memory footprint on 16kb kernels
  Also related to 16k kernels, work on writing a memory driver that will be used during debugging to allocate any type of memory on the kernel (UNMOVABLE, MOVABLE, RECLAIMABLE, CMA, etc), which was proposed at LPC Tokyo 2025.
• Discussions with attendees who had solved similar 4k / 16k compatibility issues pointed toward using a minimal VM. This feedback shifted the approach away from dynamic linker workarounds and led to investigations around AArch64 per-process page sizes to provide a more robust compatibility mode.
• HW/SW Design Recommendations for 16kB Devices also delivered actionable design recommendations to our industry partners, helping ensure their future hardware is natively 16kB compatible.
• The talk on Pixel upstreaming talk helped improve visibility of the project. There was a great conversation with Mark Brown during the talk about regulators which helped nail down the solution and move things along on the list. Connecting with maintainers and developers during the conference helped increase the project's credibility.
• At LPC, we got a chance to communicate detailed plans to transition from ashmem to memfd, and as there were no objections, that work is progressing as outlined and is expected to release in an upcoming version of Android.

Potential discussion topics for this year include:

• How Android is dealing with the memory crunch (likely multiple talks/discussions)
• Android USB Stack Updates: Userspace AOA and Multiport Device Mode
• Cuttlefish in Debian
• Wattson for power analysis
• Increasing Rust kernel driver usage with Android
• Debugging GBL with EFI debug support
• Pixel upstreaming updates
• …and more!

Key Attendees:

• Suren Baghdasaryan
• Kalesh Singh
• T.J. Mercier
• Juan Yescas
• William McVicker
• Alice Ryhl
• Matthew Maurer
• Yifan Hong
• Neill Kapron
• Paul Liu
• Peter Griffin

MC leads:

• Suren Baghdasaryan surenb@google.com
• Amit Pundir amit.pundir@linaro.org
• Mostafa Saleh smostafa@google.com
• Sumit Semwal sumit.semwal@linaro.org
• John Stultz jstultz@google.com
• Karim Yaghmour karim.yaghmour@opersys.com

11:30 Coffee Break

Device and Specific Purpose Memory MC

The Device and Specific Purpose Memory Microconference is proposed as a space to discuss topics that cross MM, Virtualization, and Memory device-driver boundaries. Beyond CXL this includes software methods for device-coherent memory via ZONE_DEVICE, physical memory pooling / sharing, and specific purpose memory application ABIs like device-dax, hugetlbfs, and guest_memfd. Some suggested topic areas include, but not limited to:

NUMA vs Specific Purpose Memory challenges
Core-MM services vs page allocator isolation
CXL use case challenges
Hotness Tracking and Migration Offloads
ZONE_DEVICE future for Accelerator Memory
ZONE_DEVICE future for CXL Memory Expansion
PMEM, NVDIMM, and DAX "legacy" challenges
Memory hotplug vs Device Memory
Memory RAS and repair gaps and challenges
Dynamic Capacity Device ABI (sparse memfd?)
Confidential Memory challenges
DMABUF beyond DRM use cases
virtiomem and virtiofs vs DAX and CXL challenges
Peer-to-peer DMA challenges
CXL Memory Pool Management
Device Memory testing

Why not the MM uConf for these topics? One of the observations from MM track at LSF/MM/BPF is that there is consistently an overflow of Device Memory topics that are of key interest to Memory device-driver developers, but lower priority to core MM developers.

Key Attendees:
Dan Williams
John Groves
Jason Gunthorpe
David Hildenbrand
John Hubbard
Alistair Popple
Gregory Price
Jonathan Cameron
Dave Jiang
Ira Weiny

Progress made on topics discussed at 2025 Plumbers:
Patches available: To online or not online CXL memory?: https://lore.kernel.org/all/20260321150404.3288786-1-gourry@gourry.net/
Patches available: CXL HDM-DB support for Linux: https://lore.kernel.org/all/20260315202741.3264295-1-dave@stgolabs.net/
Patches available: Unifying sources of page hotness information: https://lore.kernel.org/all/20260323095104.238982-1-bharata@amd.com/
Patches available: Protected DMAbufs and its dynamic memory assignment woes: https://lore.kernel.org/all/20250911135007.1275833-1-jens.wiklander@linaro.org/
Patches available: DAMON-based Pages Migration for {C,G,X}PU [un]attached NUMA nodes: https://lore.kernel.org/all/20251208062943.68824-1-sj@kernel.org/
Partially merged: FAMFS Update: Status, DAX Challenges & Use Cases: https://lore.kernel.org/all/69e7d1949ebcc_7d12a10098@iweiny -mobl.notmuch/

"Device Memory" Background:
"Device Memory" is a catch-all term for the collection of platform
technologies that add memory to a system outside of the typical "System RAM" default pool. Compute Express Link (CXL), a coherent interconnect that allows memory and caching-agent expansion over PCIe phys, is one such technology. GPU/AI accelerators with hardware coherent memory, or software coherent memory (ZONE_DEVICE::DEVICE_PRIVATE), are another example technology.

The problem is how to keep Device / Specific Purpose memory contained to its specific consumers while also offering typical core-mm services. Solutions to that problem potentially intersect mechanisms like numactl, hugetlbfs, memfd, and guest_memfd. For example, guest_memfd is a kind of specific-purpose memory allocator.

11:30 Coffee Break

LPC Refereed Track

1 Nova: Building an NVIDIA GPU Driver in Rust Upstream

Nova is an open-source NVIDIA GPU driver being developed entirely upstream from day one — and in Rust. This talk presents the current status and roadmap of the project, describes the upstream development process, and dives into the driver's architecture and how Rust shapes it.

Developing a complex GPU driver fully upstream while simultaneously building out the Rust kernel infrastructure it depends on creates a unique development dynamic. The driver consumes new subsystem abstractions (such as Driver Model, PCI, DMA, I/O, etc.) as they land, providing immediate and continuous feedback from a demanding real-world user back into the infrastructure itself. We discuss the motivation for this approach, how the feedback loop between driver and infrastructure works in practice, and what challenges and advantages it brings compared to an out-of-tree development model.

On the technical side, we present Nova's architecture: the split into nova-core, nova-drm, vGPU support, and fwctl, the rationale behind this decomposition, and how the components interact across bare-metal and virtualized environments. We follow up with implementation details showing how Rust's type system and ownership model help enforce the boundaries between these components at compile time.

Finally, we examine the Hardware Abstraction Layer (HAL) architecture common in GPU drivers, where multiple generations of hardware must be supported through composable abstraction layers. We discuss how Rust's trait system and generics provide stronger compositional guarantees than C when building and maintaining these layered abstractions.

Speakers: Danilo Krummrich, John Hubbard (NVIDIA)

2 The slab allocator sheaves post-mortem

Sheaves are a new percpu caching layer for the Linux kernel's slab allocator (specifically, its only remaining implementation, SLUB). To some extent it's a return to the former SLAB implementation's percpu arrays (callled magazines in the original Bonwick's paper), but avoiding the pitfalls that the SLAB implementation had, thus attempting to get the best of both SLAB and SLUB approaches.

In 6.18 sheaves were merged and enabled for maple node and VMA caches. Later in 7.0 they were enabled for all caches and the original cpu slabs and cpu partial slabs caching layer was removed. This talk will discuss the new implementation, explain the tradeoffs involved, the challenges and performance regression reports encountered on the way. We'll also look at the lessons learned, and ongoing/future work that the sheaves caching has enabled.

Speaker: Vlastimil Babka (SUSE Labs)

11:30 Coffee Break

3 Modern Developments with NFS in Linux

The Linux Kernel's NFS server and client has been undergoing a lot of changes recently. This talk will cover some of the latest developments in the Linux NFS Client and Server in the last few years. Including:

• Dynamic threading
• New iomodes (buffered, direct and dontcache)
• Directory delegations
• POSIX ACLs for NFSv4
• Signed filehandles
• Delegated timestamps
• Multigrain timestamps
• Netlink upcalls

Speaker: Jeffrey Layton

4 Modernizing Kernel Boot Options: Resolving cmdline and Bootconfig Discrepancies

The current Linux kernel command-line subsystem is very simple and easy to define, but it seems to have several problems, such as inconsistent API naming, drivers and the kernel sharing the same command-line options, and discrepancies between documentation and command-line option definitions. Furthermore, some options require special handling and cannot be supported by Bootconfig, an extension of kernel command-line options, but there is no way to indicate which options these are.

This session will present ideas for solving these problems, or discuss whether to continue as is.

Speaker: Mr Masami Hiramatsu (Google)

13:30 Lunch Break

5 Untangling convoluted performance regression

In this talk I will speak about a performance regression in DB2 backup speed reported by one of SUSE's customer last year. Due to various reasons the analysis was rather convoluted so I will go through the dead ends we have explored as well as leads which eventually allowed us to track down and fix the problem. Overall we demonstrate on a practical example how various tools for analyzing IO related performance regressions can be used.

Speaker: Jan Kara

6 Long-term latency monitoring of real-time Linux systems

With the PREEMPT_RT configuration being merged for the 6.12 release a milestone of a twenty years lasting journey was reached: Linux officially became an RTOS! During that time many technical issues have been resolved and many features have been added that made Linux even better even for non real-time users. A specific challenge which had to be tackled was testing and proving the real-time behavior. While for classical RTOSes traditionally a path analysis was carried out, this is close to impossible for a modern operating system such as Linux - not just because of the complexity of the software: Modern processors do come with a lot of performance with the price of being non-deterministic due to several levels of caches, speculation engines and other techniques. As a result the real-time behavior of modern systems has to be evaluated. This is why the OSADL QA Farm was born, doing comparable measurements on a huge variety of systems collecting long-term data to prove stability in the field. But even after 20 years of operation work is not done yet. Linux is evolving rapidly and the test scenarios (also for real-time) have to adopt. Apart from that Open Source RTOSes are also approaching small processors. This is why the OSADL QA Farm was recently extended with Zephyr tests.
This presentation gives an overview on best practices for evaluating the real-time behavior of Linux (and other) systems, sharing the experience from the OSADL QA Farm. It also wants to serve as a basis for discussion on how measurements shall be carried out in future and how data can be efficiently shared.

Speaker: Jan Altenberg

16:30 Coffee Break

7 Firmware-mediated accelerators for edge AI

A well-represented class of accelerators for AI in edge deployments aren't programmed directly by the Linux kernel in the host CPU, but by firmware running on a companion core.

During the first half of 2026 alone, we have seen three different drivers submitted to the mailing list for this specific type of hardware, by their respective vendors or on their behalf (TI C7x, NXP Neutron and Qualcomm QDA).

This talk will describe in detail a proposal that aligns with the upstreaming requirements in the drm/accel subsystem and streamlines the functionality that is needed inside the Linux kernel and the UAPI. The architecture will be described in detail: firmware, kernel and userspace.

An important benefit of the approach is that users will be able to accelerate their workloads without having to integrate any vendor BSPs or vendor-specific software.

Speaker: Tomeu Vizoso (NPU drivers - Independent contractor)

8 20 years of pahole : alive and kicking!

The first cset for pahole is from October 24, 2006, a long time ago, from the first goals of helping reorganize the Linux kernel networking data structures, that was done beyond my expectations, helping countless open source projects to view its data structures with great precision and flexibility, to becoming a swiss army knife tool to convert type information from DWARF to CTF and, crucially, to BTF, becoming part of the kernel build process to enable BPF CO-RE, it has kept earning its keep.

Recent advances in DWARF tag and language support, plus features that exist but aren't well publicized, are subjects I want to communicate.

Coverage analysis, a quickly growing set of regression tests, support for DWARF tags for C++ and Rust concepts, support for DWZ, partial units, supporting modern DWARF present in distro userlands are topics of recent improvement that, by the 20th anniversary, will surely be ready to talk about.

Integration with perf, namely in having pahole and perf work together in areas such as data-type profiling has been a perennial source of requests that, by now, with some help from new and controversial friends, should finally become a reality.

Speakers: Alan Maguire (Oracle), Arnaldo Carvalho de Melo (Red Hat Inc.)

Linux System Monitoring and Observability MC

The Linux System Monitoring and Observability MC brings together developers, maintainers, system engineers, and researchers to tackle unsolved problems in understanding, monitoring, and maintaining the health of Linux systems at scale.

Engineers managing millions of Linux servers face monitoring and observability challenges that no single team can solve alone. This track provides a forum to surface those challenges, share partial approaches, and leave with concrete next steps.

The goal is to have these engineers together to discuss the direction and strategy for better monitoring of Linux systems.

Track Objectives

• Surface the most pressing unsolved problems in Linux monitoring and observability
• Identify gaps in existing kernel interfaces, tooling, and infrastructure
• Build consensus on priorities and approaches for the upstream community
• This track invites participants to bring their hardest open questions, pain points, and gaps in current tooling, so the community can collaboratively work toward solutions.

Target Audience

• Hyperscaler Engineers: System reliability engineers who encounter monitoring gaps at scale that others may share
• Kernel Developers: Contributors working on tracing, performance counters, and diagnostic interfaces who want to understand real-world pain points
• Monitoring Tool Developers: Creators of observability platforms who have hit kernel or infrastructure limitations
• System Administrators: Operations teams who can articulate what breaks, what's missing, and what's too hard
• Performance Engineers: Specialists who can identify where current observability falls short for optimization work

Problems involving any of the following (but not limited to) are in scope:

• eBPF/BPF: Tracing and monitoring programs: limitations, missing features, safety constraints
• ftrace/perf: Kernel tracing infrastructure gaps
• Runtime Sanitizers: KFENCE, KASAN: coverage gaps, performance trade-offs, production usability
• Hardware Interfaces: EDAC, MCE, ACPI error reporting, missing integrations, inadequate interfaces
• bpftrace, systemd, netconsole: usability and scalability issues
• kdump/crash/drgn: crash analysis workflow pain points
• perf, memory profilers, below, strobelight, OpenTelemetry: analysis gaps and scaling challenges

Things that made progress given and were discussed in the Micro conference:

• Lack of NMI on some architecture and how to collect information about it. (Breno)
  https://lore.kernel.org/all/rs4igmsjrm6r2aio4nbe5jos3vcqk2u4bjhltjwtj2pn3cquip@kv3grgec7qrb/
  https://lkml.org/lkml/2026/3/30/1280

• Improvements in the LAVD monitoring system (Gavin Guo)

• Page owner tracking (Mauricio)
  https://lore.kernel.org/all/20251205231721.104505-1-mfo@igalia.com/

• Kmemleak detection in the fleet (Breno)
  https://lore.kernel.org/all/20260323-kmemleak_report-v1-1-ba2cdd9c11b9@debian.org/

• Memory failure and clean crashes
  https://lore.kernel.org/all/20260413-ecc_panic-v3-0-1dcbb2f12bc4@debian.org/

• Track kernels doing kexec
  https://lore.kernel.org/all/20260309-kho-v8-0-c3abcf4ac750@debian.org/

• TCP Reset Observibility (Jason)
  https://mailarchive.ietf.org/arch/msg/tcpm/d27ntz9UM4tb4-cxJNxfYw8zCSE/

• Always-on 7x24 network latency monitor (Jason)

• Who is planning to submit topics being discussed in the MC to SOSP 2026

• Relay monitoring (Jason)

• Diagnostic check and api in relay and future upstreaming discussion

• Improving memcg statistics collection (JP)
  https://lore.kernel.org/all/20260401203752.643259-1-jp.kobryn@linux.dev/

• General improvements for DAMON (SJ)

11:30 Coffee Break

Nova GPU & DRM Rust Workshop

This workshop will center on Nova, the upstream Rust-based kernel driver for NVIDIA GPUs, and on Rust in the DRM subsystem in general.

On the Nova side, discussion topics will include the design and evolution of the firmware APIs exposed by the GPU System Processor (GSP), in particular the new GMC APIs, as well as user-space submission interfaces, compute APIs, and interactions with the core kernel (device / driver APIs; locking and lifetimes; memory management APIs). Beyond Nova, the workshop will cover the shared Rust DRM infrastructure — device / driver core and initialization, TTM/GEM, GPUVM, job submission and scheduling — and how to properly tie these components into driver lifecycle design.

Potential key participants are members of the Nova team at NVIDIA and Red Hat, contributors from the DRM and Rust-for-Linux communities, and developers of parallel Rust driver efforts such as Tyr (Arm, Collabora, Google), the Asahi AGX driver, and rvkms.

The workshop aims to keep Nova and the Rust DRM infrastructure closely tied to the needs of the graphics / compute stack in Linux, and to foster collaboration around shared challenges in GPU driver design.

Safe Systems with Linux MC

Description/Motivation

As Linux continues to be deployed in systems with varying criticality constraints, the need for consistent linkage between requirements, code, and tests becomes increasingly important at the higher assurance levels. Establishing such traceability can improve development and testing efficiency, supports necessary analysis, and reduces long‑term maintenance risks.

This MC addresses key challenges in expectation management, documentation, testing, and artifact sharing within the Linux kernel ecosystem. While tests are commonly contributed alongside code, the underlying requirements they validate are typically not documented in a structured manner. This creates significant “tribal knowledge” within subsystems, leading to technical debt when maintainers stop working on subsystems or subsystem expertise is lost in other ways.

Given the feedback from last year's "Safe Systems with Linux" miniconference[1], we are pivoting away from the original guidance in 2024 of publicly documenting the kernel design in the code, and focusing on expressing the requirements and traceability as side car data structures. This makes the information machine‑readable, maintainable, and scalable without inhibiting kernel development velocity.

Building on the 2025 discussions and the progress made over the past year, the goal of this MC is to gather wider input from maintainers and developers across different subsystems on the proposed approach and its practical adoption in upstream workflows.

Potential Topics

• Technical Debt Reduction
  How capturing expected behavior and design intent as structured requirements enables maintainers to validate functionality during refactoring (e.g., language transitions such as C→Rust) and supports onboarding of new contributors.

• Requirements-Driven Testing
  How linking requirements to specific tests and code paths can increase test efficiency, improve coverage understanding, and allow automated validation of expected behavior.

• Semantic Aspects of Kernel Requirements
  How to document expected kernel behavior while accounting for design constraints, architectural dependencies, and interactions between subsystems.

• Progress on Linux Kernel Requirements Framework
  How the SPDX‑based template for low-level requirements is evolving, what has been learned from early pilots, and how broader adoption as sidecar metadata could be enabled.

• Practical Implementation Challenges
  How to balance detailed requirements documentation with the realities of fast‑paced kernel development, and what workflows or structures can minimize friction.

• Required tools for automation
  How tooling can generate, validate, and track requirements, tests, and other work products, increasing dependability and reducing manual effort throughout kernel development.

• Connecting with Other Kernel Quality Initiatives
  How the requirements approach can integrate with existing kernel quality, testing, and sustainability initiatives, and where collaboration can reduce duplication and improve adoption.

• Industry Adoption
  How safety-critical industries are beginning to leverage these developments for certification and compliance purposes.
  How their safety engineers can participate in contributing formalized requirements to the kernel and providing linkage.

• Requirements as an Education Tool
  How linux kernel documentation can mine the requirements, and help new contributors understand kernel functionality and design intent and attract new upstream developers

Objective

The MC aims to bring together kernel maintainers, developers, safety architects, and industry stakeholders to advance the adoption of structured requirements and traceability practices to complement the Linux kernel existing development workflows. It will focus on aligning documentation, testing, and tooling in a coherent workflow, and addressing remaining technical and organizational challenges in building dependable and safety‑relevant systems with Linux.

Potential Participants

• Gabrielle Paoloni
• Chuck Wolber
• Luigi Pellecchia
• Alessandro Carminati
• Paul McKenney
• Julia Lawall
• Sasha Levin
• Steve Rostedt
• Thomas Gleixner
• Shuah Khan
• Gustavo Padovan
• Wolfram Sang (Renesas BSP)
• Kate Stewart
• Philipp Ahmann
• Nicole Pappler

References

[1] LPC 2025 Safe Systems with Linux MC: https://lpc.events/event/19/sessions/221/#20251212

9 Aspects of Dependable Linux Systems

In regulated industries, Linux is widely used due to its strong software capabilities in areas such as dependability, reliability, and robustness. These industries follow best practices in terms of processes for requirements, design, verification, and change management. These processes are defined in standards that are typically not accessible to the open source kernel community.

However, since these standards represent best practices, they can be incorporated into structured development environments like the Linux kernel even without the knowledge of such standards. The kernel development process is trusted in critical infrastructure systems as it already covers many process elements directly or indirectly.

The purpose of this session is to initiate a discussion on what is currently available and what may be missing in order to enhance the dependability and robustness of Linux kernel-based systems. How can the artifacts be connected? Where are the appropriate places to maintain them? And who is the best responsible for each element of the development lifecycle?

Speakers: Kate Stewart (Linux Foundation), Philipp Ahmann (Etas GmbH (BOSCH))

10 Towards Program Verification of the Linux Kernel Library XArray

XArray is a data structure used in many Linux kernel components, most notably the page cache. Its API contracts are not precisely documented, making it challenging to understand caller obligations and which invariants any changes to the implementation must maintain over the structure. Since its integration into the Linux source tree in 2019, errors in the use of the library have caused bugs such as memory leaks [1, 2], and the library code itself has suffered from bugs like race conditions and null pointer dereferences [3, 4]. Recent case studies [5, 6] suggest that applying program verification to Linux kernel source code is a promising means to make requirements structured, explicit, and machine-checkable against the implementation.
This talk presents progress verifying the core load and store APIs of the XArray library. So far, we have verified the xa_load() function and its callees, and are working on the verification of xa_store(). We will discuss how the structured specification of the original library can be used to build confidence in the Rust re-implementation that is under active development [7]. By formalizing and checking the API’s precise contracts, we can validate the parity of the Rust port’s behavior in critical kernel clients.

[1] Matthew Wilcox. “mm/huge_memory: Fix xarray node memory leak.” url: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v6.19&id=69a37a8ba1b4

[2] Yang Yang. “swap_state: update shadow_nodes for anonymous page.” url: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v6.19&id=5649d113ffce

[3] Matthew Wilcox. “XArray: Disallow sibling entries of nodes.” url: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v6.19&id=63b1898fffcd

[4] Matthew Wilcox. XArray: Fix xas_create_range() when multi-order entry present. url: https://github.com/torvalds/linux/commit/3e3c658055c002900982513e289398a1aad4a488

[5] Julia Lawall, Keisuke Nishimura, and Jean-Pierre Lozi. 2024. Should We Balance? Towards Formal Verification of the Linux Kernel Scheduler. SAS 2024.

[6] Julia Lawall, Keisuke Nishimura, and Jean-Pierre Lozi. 2025. Understanding Linux Kernel Code through Formal Verification: A Case Study of the Task-Scheduler Function select_idle_core. OLIVIERFEST '25.

[7] Daniel Gomez, "rxarray," commit 0ae6dd57e31d, Linux kernel development tree. url:
https://git.kernel.org/pub/scm/linux/kernel/git/da.gomez/linux.git/commit/?id=0ae6dd57e31d9e436ee935288767f53e118db8c0

Speaker: Corinn Tiffany (Inria)

11 Common pitfalls and errors, when using Linux in Safety Applications

Safety-oriented use of the Linux Kernel presents a class of obstacles that are normally absent from other types of use, and therefore can be easily overlooked. Sometimes what would normally constitute a strength can actually turn into a weakness. Or aspects that are peculiar of creation of physical products (e.g. cars, robots) can present unexpected challenges.
This talk wants to raise awareness about these uncommon aspects.

Speaker: Igor Stoppa (nvidia)

11:30 Coffee Break

12 Scaling the Design Definition

The fundamental unit of design is a requirement (i.e. "testable expectation"). All forms of design can be expressed as a (directed acyclic) knowledge graph of requirements. A software project that documents its design in this manner can derive both source code and automated test from the same idea. Without this, there is no guarantee that test and implementation reliably reflects the same idea.

In virtually all open-source projects, documenting the design to this level of detail is rarely (if ever) considered. While the benefits are easy to understand, retrofitting a design on an existing project and then keeping it up to date is a barrier to entry that few are willing to consider.

In this troubleshooting session, Chuck will describe the problem in more detail, answer relevant background questions, and solicit ideas for potential approaches to retrofitting designs and keeping them updated.

Speaker: Chuck Wolber

13 Defining Linux Kernel Requirements and Test Specifications out of the Kernel Tree

Following the objections in having requirements and even code documentation traceable to Kernel testing as optional part of the Linux Kernel development process, the ELISA project decided to start defining requirements and test specifications in a separate repository.
This session will present the current status for the requirements and test specifications framework and traceability to upstream code and test case implementations.

Speakers: Gabriele Paoloni (Red Hat), Kate Stewart (Linux Foundation)

14 From Manual Argument to Machine-Readable Graph: Toward a Safety SBOM for Linux

A safety case is the structured argument that a system is acceptably safe: claims, the evidence supporting them, and the assumptions under which the argument holds. Building and maintaining one is largely manual, and keeping it consistent as a design evolves is harder still.
SPDX 3.1's Functional Safety profile changes the starting point by giving the safety case a machine-readable form. It models requirements and their refinement, verification activities, pass/fail evaluations, evidence, and assumptions of use—the same structure safety practitioners already reason about, now expressed as a graph that tools can produce, exchange, and check.
This talk introduces the profile and its data model: what each element means, and how claims link to the evidence that supports them and the assumptions they depend on. We show how this representation can be used to generate a safety SBOM for Linux—a safety case generated and recomputed from project content rather than assembled by hand—building on the work of the ELISA Architecture working group and its current efforts on requirements. We argue this graph-based approach is the foundation for an automated handshake between upstream evidence and downstream safety arguments, enabling the kind of contract-style consumption of Linux components that safety-critical projects need.

Speaker: Nicole Pappler

15 Wrap up

Speakers: Kate Stewart (Linux Foundation), Philipp Ahmann (Etas GmbH (BOSCH))

Toolchains Track

16 Security Features status update

Another year of work is behind us, with lots of progress across GCC, Clang, and Rust to provide the Linux kernel with a variety of security features. Let's review and discuss where we are with parity between toolchains, approaches to solving open problems, and exploring new features.

Parity reached since last year:
- Various little behavioral corner-case bug fixes

In progress:
- Overflow Behavior Types (needed in GCC)
- forward-edge CFI (GCC KCFI at v14)
- coverage-sanitizer stack-depth tracking (needed in GCC)

Stalled / needs attention:
- -fbounds-safety language extension (slow in Clang)
- __strong typedef (needs design finalized)
- Link Time Optimization for GCC kernel support
- backward-edge CFI (x86 CET shadow stack, kernel mode)

Speakers: Justin Stitt (Google), Kees Cook (Google)

17 Compiler-Based Context Analysis for Compile-Time Lock Safety

Compiler-Based Context Analysis is a language extension which enables statically checking that required contexts are active (or inactive) by acquiring and releasing user-definable “context locks”. An obvious application of this feature is lock-safety checking for the kernel's various synchronization primitives, verifying at compile time that locking rules are not violated. This session will begin with a brief overview of this new infrastructure that relies on Clang's Thread Safety Analysis (-Wthread-safety), but the focus will be on how developers can use it to annotate locking requirements to catch concurrency bugs before they ever make it into a kernel binary.

Currently, the analysis is opt-in by default and requires declaring which modules and subsystems should be analyzed, as enabling it tree-wide currently results in numerous false positive warnings. In the remainder of the talk, we will discuss strategies and best practices on broadening Context Analysis coverage across the entire kernel tree.

Reference: https://docs.kernel.org/dev-tools/context-analysis.html

Speaker: Marco Elver (Google)

18 BPF support in the GNU Toolchain

In this activity we will first provide a very brief update on the status of the port of GNU binutils and GCC to the BPF target, with emphasis on the level of support for extant BPF programs and the kernel BPF selftests. Then we will address a set of particular issues for which we need feedback and/or consensus from the BPF kernel and clang/LLVM hackers.

Speakers: Cupertino Miranda, David Faust, Jose E. Marchesi (GNU Project, Oracle Inc.), Vineet Gupta

11:30 Coffee Break

19 Are your types the same as mine?

This session is aimed at discussing the benefits (and requirements) of having a unified type representation that can be used in tracing tools to facilitate type management, type compatibility checks, etc. With type info from the kernel, type info from userspace, and types that may be defined in tracing scripts, the hoops that one may need to jump through to make it all work as a single environment where cross-stack tracing can be done are a bit excessive.

Let's discuss ongoing efforts to work on this, and look at the needs, wants, etc to help drive this in the right direction where a single type management system can satisfy all requirements, and avoid duplication of effort, and painful conversions between systems.

Speaker: Kris Van Hees (Oracle USA)

20 Towards real-time ABI compatibility assurance with libctf

The CTFv4 extension of the CTF file format into a superset of BTF is nearly complete. Once it's working, what can we do with systemwide type information for all C programs?

One possibility we explore in this talk is to use some simple linker extensions to provide real-time, linear-time ABI checking in ld.so to determine for every running program whether any of the C libraries it uses has changed incompatibly since the program was linked in a way that breaks the program, without linking ld.so with libctf or requiring it to do anything more difficult than a few equality comparisons and strcmps.

The end goal is to be able to see something like this

emacs

warning: libxml.so.2.13.9: incompatible symbol: linked against
xmlDocPtr xmlReadMemory (const char , int, const char , const char , int)
but running against
xmlDocPtr xmlReadMemory (const char , int, const char , const char )

(a contrived example: xmlReadMemory has not actually broken ABI. ld.so invokes a helper program that uses libctf to print that output, but does not itself need to use libctf.)

This is only partly written so far: we explore the design of this scheme in part so that the audience can spot any serious errors before it causes widespread breakage, and to see if people can suggest improvements to the general design.

Speaker: Nick Alcock

21 Adding C library wrappers for all Linux syscalls - The Return

At Linux Plumbers Conference 2025 in Tokyo I gave part 1 of this talk, this year I want to revisit progress made against the use cases presented last year including progress made on raw futex.

In review we'll look at systemd and if we were able to solve their most thorny calls to syscall with actual libc wrappers.

I'll include a more formal review of what is currently missing in glibc, collecting the list of syscalls for x86_64, and aarch64 and comparing to the kernel.

I will close again with a call to action for always having syscalls available as C library calls even if they could be used behind the back of the implementation.

I will propose a formal mentoring program. If you want to get a syscall wrapper into glibc I'll work with you to make it happen.

Speakers: Mr Carlos O'Donell (Red Hat), Florian Weimer (Red Hat)

13:30 Lunch Break

22 Kernel module support for PGO AutoFDO and Propeller

Recent support for profile-based optimizations—specifically PGO, AutoFDO, and Propeller—has delivered double-digit performance gains to the core kernel. However, kernel modules do not automatically inherit these benefits. Since a significant portion of execution time can be spent inside these modules depending on configuration, their lack of optimization remains a drawback compared to builtin kernels. This presentation covers the implementation details for extending LLVM's PGO, AutoFDO, and Propeller build support to kernel modules. We will explore the required changes to the build pipeline for profile collection and ingestion, as well as the unique adjustments needed for each optimization mode. With these changes, profile-based optimizations are fully supported across the entire kernel ecosystem.

Speaker: Rong Xu (Google)

23 Upgrading Runtime Leaks to Compile-Time Errors: Adopting Clang’s require_explicit_initialization

The Linux kernel makes heavy use of aggregate struct initializers to configure subsystem interfaces, driver registries, and object lifecycles (such as struct kobj_type and struct device_type). However, omitting mandatory struct members—such as a kobject's release callback—may result in silent memory leaks or deferred runtime panics.

Clang offers a static alternative attribute ‘require_explicit_initialization’, which triggers the -Wuninitialized-explicit-init warning if a designated field is left uninitialized during aggregate construction . This talk is proposed as a collaborative discussion to brainstorm how we can adopt this safety mechanism in kernel headers (e.g., via a macro like __required_init) . We will discuss the candidate structures that would benefit most, evaluate the engineering friction of enforcing this across cross-tree refactors, and address compiler parity issues—specifically how to handle GCC fallback and whether a similar diagnostic can be proposed for GCC.

Speaker: Ian Rogers (Google)

24 Kage: device driver isolation in the Linux kernel with LFI

Drivers in Linux run with full kernel privileges and account for a significant share of exploitable vulnerabilities. Kage is an experimental kernel subsystem that runs kernel modules inside of in-kernel sandboxes using LLVM's Lightweight Fault Isolation (LFI) feature. Kaged drivers still run in the same hardware privilege level and address space as the rest of the kernel, but are compiled such that control-flow and memory accesses are confined to a subset of virtual memory. This keeps transition costs cheap and reduces the engineering effort needed to retrofit isolation onto existing drivers. LFI is designed to provide secure isolation even for arbitrarily malicious code through the use of a machine code verifier that keeps the compiler out of the trusted code base.

This talk will walk through a prototype version of Kage, which can load LFI-built kernel modules into an isolated portion of the address space, and demonstrate how drivers can be ported to run in sandboxes. Kage uses BTF type information to automatically check call signatures and replace kernel pointers with opaque handles on calls between the kernel and the module. The current prototype can sandbox simple computational kernel modules, and is expected to grow in capabilities in order to handle MMIO, buffer sharing, DMA (via the IOMMU), and interrupt routing, with the end goal of being able to isolate real, complex drivers, such as USB, network, or possibly even GPU drivers.

Speaker: Zachary Yedidia (Stanford University and Google)

16:30 Coffee Break

25 GCC Rust support for Linux

A conversation about the Linux kernel requirements from GCC Rust and how to promote GCC Rust as another compiler for the Rust components of the Linux kernel. The technical and community issue.

Speakers: David Edelsohn (NVIDIA), Philip Herron (Embecosm)

26 Crossing borders between user space and kernel space: GDB/Valgrind/drgn close cooperation

While is GDB is primarily a user space tool, drgn is a kernel space one. Using them together may improve user experience as drgn can help GDB to get access to various kernel structures. Right now, GDB can show what a thread is doing in user space, drgn can show what it is doing in the kernel — but the two tools do not talk to each other. I would like to discuss what it would mean to cross that border.

The crossing is technically straightforward: drgn is a Python library, and GDB already has a Python API, making it natural to call drgn from GDB scripts. As a concrete demonstration, I wrote a small GDB Python command, drgn_why_sleeping, which retrieves the kernel stack of a sleeping thread via drgn and displays it alongside GDB's user-space backtrace — showing the full kernel path where bt alone shows only a generic syscall frame.

This raises further questions: could drgn's per-frame register and local variable access allow GDB users to inspect kernel frames interactively? Is a remote variant worth pursuing for kgdb setups? Could drgn help trace where in the kernel an error originates when stepping over a failing syscall? Valgrind could also benefit — since drgn does not use ptrace, it could attach to a Valgrind-instrumented process simultaneously and resolve invalid memory addresses to named kernel structures. And in the other direction: could user-space tools like GDB or Valgrind offer anything useful back to drgn?

Speaker: Alexandra Petlanova Hajkova

27 Beyond Coverage: Per-Task Function Boundary Extraction for Kernel Contract Verification

KCOV's trace-pc provides edge coverage feedback for kernel fuzzers, but captures no data-flow context. Two syscalls hitting identical basic blocks with different argument values (e.g., vfs_open with O_RDONLY vs O_WRONLY|O_TRUNC) are indistinguishable to the fuzzer. This "semantic gap" causes coverage saturation on value-dependent state transitions in complex subsystems (binder, io_uring, ksmbd).

ftrace function graph tracer support arg/ret values tracing during runtime. But their is a couple of challenge(FTRACE_REGS_MAX_ARGS 6) regarding architecture calling convention from register, and currently can't support structure and their members on the function.

On the other hands, Rust For Linux kernel modules can't supported by current tracing framework.

We need consensus on extending LLVM's SanitizerCoverage to capture function arguments and return values, including automatic struct field decomposition from DWARF metadata, with a kernel-resident per-task ring buffer.

What I Implemented

Two new SanitizerCoverage modes in LLVM:

1. Emits LLVM RFC submitted __sanitizer_cov_trace_args(pc, arg_idx, arg_size, ptr, offsets, num_fields) at function entry for each parameter.

2. Emits LLVM RFC submitted __sanitizer_cov_trace_ret(pc, ret_size, ptr, offsets, num_fields) before each return.

The pass uses DICompositeType metadata to extract struct field offsets/sizes at compile time and emits them as global constant arrays. At runtime, the kernel backend reads fields via copy_from_kernel_nofault() into a per-task lock-free mmap'd buffer at /sys/kernel/debug/kcov_dataflow.

A native rustc path (rustc built against the custom LLVM) enables Rust kernel module instrumentation without a post-compilation pipeline — the only known method for capturing Rust function arguments at runtime given -O2 DWARF elision.

Discussion Topics Needing Agreement

1. Callback ABI stability
   Should __sanitizer_cov_trace_args/ret be considered stable SanitizerCoverage API, or experimental? What's the path from -fsanitize-coverage=trace-args to an accepted upstream flag?

2. DWARF metadata dependency
   The pass requires -g for struct expansion. Currently it gracefully degrades: without -g, F.getSubprogram() returns null and the function is silently skipped. With -g but missing type info for a param, it records as scalar (offsets=NULL, num_fields=0). Should this behavior be documented as the contract?

3. Interaction with optimizations
   At -O2, scalar arguments are spilled to alloca so the kernel callback receives a uniform pointer. Should the pass mark these as side-effecting to prevent DSE, or accept the current behavior (compiler preserves them because the call itself is a side effect)?

4. Rust integration path
   Currently requires building rustc against the custom LLVM (native path) or using a wrapper (rustc emit-llvm-ir then opt). Is there appetite for native -Zsanitizer-coverage=trace-args support in upstream rustc? The kernel's Kbuild does not expose intermediate IR for external instrumentation, making the native path mandatory for Rust kernel modules.

5. Kernel-side callback design
   The kernel backend uses copy_from_kernel_nofault() for safe pointer reads and a bit-31 recursion guard (needed because copy_from_kernel_nofault itself is instrumented under INSTRUMENT_ALL). Should the LLVM pass remain fully target-agnostic, or emit hints for the runtime?

6. Scope control
   Per-module opt-in (KCOV_DATAFLOW_file.o := y) vs. global (CONFIG_KCOV_DATAFLOW_INSTRUMENT_ALL). The pass currently instruments all functions with DISubprogram. Should it support function-level filtering via attributes (e.g., __attribute__((no_sanitize("dataflow"))))?

7. Performance implications
   With INSTRUMENT_ALL: +9.5% .text, +133% syscall latency. Per-module: +8.3% on instrumented paths. The per-callback cost is ~27ns dominated by copy_from_kernel_nofault. Is this acceptable for the SanitizerCoverage framework, or should it be a separate pass?

Why Rust Kernel Modules Need This

Existing observability tools completely fail on Rust kernel code:

• ftrace: Cannot hook Rust functions (no __fentry__ prologue — rustc doesn't emit -mfentry)
• kprobes/fprobe: Rust symbol mangling makes targeting impractical; even with correct names, only captures raw register values (no struct expansion)
• drgn/vmcore: rustc -O2 elides DW_AT_location for all parameters — frame.locals() returns {}
• eBPF: Requires manual struct layout specification; Rust #[repr(Rust)] types have no stable ABI

Our LLVM pass operates on Rust-generated IR before codegen — the only point where both debug metadata and argument values coexist.

Verified: Rust eight_struct_args_rust selftest produces correct output at -O2 on CI result: https://github.com/yskzalloc/kcov-dataflow/actions/runs/29659128011/job/88119068007

do_el0_svc({0x4, 0x4, 0xffffffff, 0x0, 0x0, 0x0})
0x0 = B...
sb_start_write()
file_start_write()
0x0 = _RNvCsdfZGIOKgjaD_22eight_struct_args_rust13write_handler() [eight_struct_args_rust]
  0x11 = rsf_1(0x11) [eight_struct_args_rust]
  0x33 = rsf_2(0x11, {0x11, 0x22}) [eight_struct_args_rust]
  ...
  0x30c = rnsf_8({0xa8, 0x11, 0x11, 0x11, 0x11, 0x11, 0x11, 0x11, 0x11}) [eight_struct_args_rust]
    0xaa = rsf_fwd_inner(0x11, {0x11, 0x22}, {0x11, 0x22, 0x33}, {0x11, 0x22, 0x33, 0x44}) [eight_struct_args_rust]
  0xaa = rsf_fwd(0x11, {0x11, 0x22}, {0x11, 0x22, 0x33}, {0x11, 0x22, 0x33, 0x44}) [eight_struct_args_rust]
  rsf_ret_struct(0x0, {0x11, 0x11}, 0x11) [eight_struct_args_rust]
  0xfffffdffc0356e80 = rust_helper_krealloc_node_align(0x0, 0x8, 0x8, 0xcc0, 0xffffffff)
  0x6f00000009 = rust_helper_krealloc_node_align(0x0, 0x10, 0x8, 0xcc0, 0xffffffff)
  0xf200006e00000011 = rust_helper_krealloc_node_align(0x0, 0x18, 0x8, 0xcc0, 0xffffffff)
  0x2500006e00000011 = rust_helper_krealloc_node_align(0x0, 0x20, 0x8, 0xcc0, 0xffffffff)
  0xaa = rsf_heap(0x11, {0x11, 0x22}, {0x11, 0x22, 0x33}, {0x11, 0x22, 0x33, 0x44}) [eight_struct_args_rust]
  0x0 = rust_helper_krealloc_node_align(0x11, 0x0, 0x1, 0x0, 0xffffffff)
  0x0 = rust_helper_krealloc_node_align(0x11, 0x0, 0x1, 0x0, 0xffffffff)
  0x0 = rust_helper_krealloc_node_align(0x11, 0x0, 0x1, 0x0, 0xffffffff)
  0x0 = rust_helper_krealloc_node_align(0x11, 0x0, 0x1, 0x0, 0xffffffff)
0x1 = _RNvCsdfZGIOKgjaD_22eight_struct_args_rust13write_handler(0xffffa64d1231, 0x1, 0x0) [eight_struct_args_rust]
...

Implementation vs. ftrace funcgraph-args

ftrace's funcgraph-args (available since 6.x) captures 6 raw register values but:
- Requires -mfentry (no Rust support)
- No struct field expansion (just pointer addresses)
- Shared per-CPU ring buffer with preempt_disable per event
- Under load: events silently overwritten/dropped
- Stack-passed args (> 6) not captured

kcov-dataflow:
- Per-task private mmap buffer (no contention, no preempt_disable)
- Automatic struct field expansion from DWARF
- All args including stack-passed (alloca'd at compile time)
- Works on both C and Rust identically
- Zero-copy consumer via mmap

Current Status

• Repository (kernel + LLVM + rustc + selftests + CI):
  https://github.com/yskzalloc/kcov-dataflow
• CI (x86_64 + arm64, 6 selftests):
  https://github.com/yskzalloc/kcov-dataflow/actions
• Tested on linux-next 7.2.0-rc3 with custom clang/LLVM 23 and rustc 1.99-nightly
• All selftests pass on both x86_64 (KVM) and arm64 (native) Github CI

Why This Needs Face-to-Face Discussion

• This work crosses 3 communities (LLVM, kernel, Rust-for-Linux) that rarely meet simultaneously.
• The callback ABI, optimization interaction, and Rust pipeline decisions require input from all 3.
• LPC Toolchains Track is the only venue where clang/LLVM developers, kernel maintainers, and Rust-for-Linux contributors are in the same room.

References

• LLVM RFC: https://discourse.llvm.org/t/rfc-sanitizercoverage-add-fsanitize-coverage-trace-args-trace-ret/91026
• LLVM PR: https://github.com/llvm/llvm-project/pull/201410
• Kernel patch (v2): https://lore.kernel.org/all/20260611-b4-kcov-dataflow-v2-v2-0-0a261da3987c@est.tech/
• arXiv paper: https://arxiv.org/pdf/2606.00455
• LWN: https://lwn.net/Articles/1077606/

Speaker: Mr Yunseong Kim (Ericsson Software Technology)

eBPF Track

The eBPF Track is going to bring together developers, maintainers, and other contributors from all around the globe to discuss improvements to the Linux kernel’s eBPF subsystem and its surrounding user space ecosystem such as libraries, loaders, compiler backends, related system tooling as well as eBPF use cases.

The gathering is designed to foster collaboration and face to face discussion of ongoing development topics as well as to encourage bringing new ideas into the development community for the advancement of the eBPF subsystem.

The track will be composed of talks, 30 minutes in length (including Q&A discussion).

eBPF Track's technical committee: Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko

28 Rust-BPF updates

Support for all of Rust required rethinking of how the verifier processes instructions. Stack liveness, SCEV, indirect calls are known building blocks while more fundamental rewrite is still necessary. The talk will cover completed and upcoming work areas in the verifier, LLVM, GCC, rustc, libbpf.

Speaker: Alexei Starovoitov

29 Support large-size arguments and Rust based exception handling

Large-size Arguments

Current bpf verifier will reject a function if one of its arguments
is a union/struct or more than one register size (except __int128 type).
Such limitation forces users to work around codes to fit bpf prog
requirement, but such limitation does not exists for other languages,
like normal C, rust, etc. Without such limitation, users will be able
to write more elegant codes.

Rust Based Exception Handling

Current C based bpf prog do not have language level exception
handling. The bpf echosystem added bpf_throw() kfunc to allow
exception which does architecture unwinding and allows some
code at main prog level.

Rust bpf supports more flexible exception handling at language
level. It allows bpf callbacks at individual function exception
level, e.g. to release certain references etc. At each function
level, it is possible there are multiple possible exception
handling, e.g., A -> B -> C. If C tiggered exception, bpf
callbacks can be called for C, then B, then A.

In any case, Rust can provide lots of flexibility when something
wrong during verification.

Speaker: Yonghong Song

30 Extending the BPF Type Format to support more languages

Now that kernel modules can be built in Rust [1],[2], it seems timely to look at programming language constructs outside of C to assess their applicability to BTF representation. Suggestions include

• slices/"fat pointers" with type and size
• tagged unions
• generics
• interfaces
• lifetime tags

Rough suggestions will be made for how to represent these as BTF kinds to trigger discussion.

[1] https://docs.kernel.org/rust/index.html
[2] https://lwn.net/Articles/991719/

Speaker: Alan Maguire (Oracle)

11:30 Coffee Break

31 Slaying the BPF Verifier: Safe & Static Kernel Extensions Using Rust

While the BPF verifier ensures kernel safety, its rigid static rules heavily bottleneck the development of complex kernel extensions. Last year’s LPC introduced Rex (Rust Extensions) to address these gaps. By leveraging Rust, Rex aims to guarantee memory and type safety at compile time rather than relying on the restrictive verifier. While this initial iteration utilized runtime protection to manage panics and address the halting problem, it resulted in considerable architectural and performance trade-offs.

This talk introduces the revamped, statically compiled panic-free Rex. By fully leaning into Rust’s static typing, borrow checker, and a dedicated compiler pass, this new architecture closely mirrors the verifier’s safety profile but at compile time. It empowers developers to build large-scale kernel programs using dynamic loops, complex data structures, and natural programming patterns.

To prove this model's viability, we will present a successful Proof of Concept integrating the new Rex with the ghOSt scheduler. We will walk through the implementation details, demonstrating how Rex handles complex scheduling logic safely and efficiently entirely in Rust.

Ultimately, we seek to engage the community in a dialogue regarding the robustness of this architectural framework and the strategic roadmap for upstream integration. We are eager to assess the broader interest in the evolved Rex and solicit feedback on potential refinements to further optimize our model.

Speaker: Aniket Gattani (Google Inc.)

32 blitmus: Litmus-testing the eBPF memory model on real hardware

The eBPF instruction set has quietly grown a concurrency surface: load_acquire/store_release instructions, arena atomics now JIT-compiled across x86, arm64, riscv and powerpc, resilient queued spinlocks, and lock-free ring buffers. eBPF programs routinely run concurrently across CPUs and increasingly coordinate through shared memory. Yet unlike the Linux kernel — which has a formal, herd7-executable memory model (LKMM) and the klitmus7 tool to exercise it — eBPF has no formal memory model and no way to check that the ordering a program requests actually survives the verifier and each architecture's JIT.

This talk presents blitmus (https://github.com/puranjaymohan/blitmus), a tool that converts standard LKMM litmus tests into eBPF programs and runs them on real hardware. Each process of a litmus test becomes a BPF program pinned to a specific CPU; a userspace harness races them across millions of iterations, histograms the outcomes, and compares them against the test's exists clause and expected result — the same methodology klitmus7 and herd7 use, but exercising the BPF runtime end to end. Because the same litmus test can be run unchanged on every architecture, blitmus can surface JIT ordering bugs (e.g. a missing barrier for cmpxchg) that are otherwise silent and catastrophic for concurrent BPF code.

I will demo the tool converting and running the LKMM litmus suite through BPF, walk through the results on aarch64 and x86-64 (including weak behaviors observed for store-buffering and a Result: Never test that blitmus flags as violated), and use that case to discuss tool fidelity: how faithfully a batched, test-run-based harness models true multi-CPU races, and where the current barrier/interleaving strategy needs to improve.

I would like to use the session to discuss next steps with the community:

(1) growing the harness to cover BPF-specific primitives — arena spinlocks, rqspinlock, ring buffer reserve/commit ordering, per-CPU maps;

(2) a proper litmus parser and cross-architecture CI (qemu on riscv/ppc/s390/loongarch) wired into selftests/bpf as a memory-model conformance suite;

Speaker: Puranjay Mohan (Meta)

33 Adding KASAN support for JIT-compiled BPF Programs

KASAN (Kernel Address Sanitizer) is a powerful developer tool for detecting
use-after-free and out-of-bounds memory accesses in the kernel code.
However, not all memory accesses performed by the kernel are covered by
KASAN monitoring. BPF programs are a major example: when they are
translated by the in-kernel JIT compiler, the kernel directly emits new
native instructions that then escape KASAN instrumentation. Closing this
gap would shed some light on potential bugs in the eBPF verifier or JIT
compilers that would be hard to investigate otherwise.

This talk will present the current effort funded by the eBPF Foundation
aiming to introduce KASAN support for eBPF programs: we will discuss the
main architectural points, going over how the JIT compiler emits calls to
__asan_*() functions before each memory access, discussing the register
save/restore strategy, and the interactions with the BPF verifier.

As a first draft of this work has been introduced at the LSFMMBPF
conference 2026 (Zagreb, Croatia), and as many revisions have been sent and
discussed on the BPF mailing list since then, this talk will also act as an
update, highlighting the main changes since the first draft, as well as the
remaining difficulties and issues to solve.

Speaker: Alexis Lothoré (Bootlin)

13:30 Lunch Break

34 BPF Kernel Verifier meets GCC: A saga of arranged marriage

BPF Verifier has troubles grok'ing GCC generated code (having evolved with LLVM over time). This talk is about my recent work on BPF GCC and the kernel verifier and efforts to make them like each other more.

Speaker: Vineet Gupta

35 Evolution of Value Tracking in the BPF Verifier

While safety and performance get most of the credit for BPF's success, a safe and fast program that couldn't do anything interesting would be rather useless. Much of the flexibility that makes BPF programs interesting today (e.g. indexing into a map value at a computed offset, walking packet data, reading a stack array at a variable index) was actually not there at the start.

In this talk, we'll give a thousand-foot overview that goes from the initial tracking of constant/unknown all the way to cnum, covering topics like scalar IDs, sub-register bounds, bounds syncing, as well as value-tracking bugs along the way.

Speaker: Shung-Hsi Yu (SUSE)

36 Proof-Carrying Verification for eBPF

Abstract

eBPF provides a safe way to extend the kernel functionality. To ensure safety, the kernel verifies the memory safety and termination of eBPF programs and is thus the security boundary for eBPF. It must accept untrusted programs from userspace and determine, under strict time and memory limits, whether they are safe to execute.

Today, the verifier symbolically executes program paths, tracks abstract register and memory states, and uses state pruning and repeated loop exploration to establish safety. Keeping both proof discovery and proof checking in the kernel has the important advantage that the kernel does not need to trust the compiler or any userspace component.

The cost of this design is that the kernel has to employ a sophisticated analysis capable of reconstructing invariants from eBPF bytecode. Compilers may already discover source-level relationships and loop invariants, but these facts are not normally conveyed to the kernel. When the verifier cannot recover invariants, it must conservatively reject the program. At the same time, the complexity of the analysis makes it difficult to audit and maintain this security boundary, and verifier bugs can result in malicious programs being accepted. Verification failures can also be difficult to predict and relate back to the source program.

We are exploring a proof-carrying verification architecture that separates proof generation from proof checking. An untrusted userspace proof generator analyzes the program, discovers invariants, and uses an SMT solver to discharge safety obligations. If successful, it emits a certificate containing the invariants and proof steps needed to validate the program. If an obligation cannot be proved, the tool can use compiler metadata and solver output to distinguish concrete counterexamples from unsupported reasoning or missing invariants, and produce source-oriented diagnostics.

Inside the kernel, a domain-specific checker validates the program and certificate together. The certificate supplies facts such as basic-block and loop invariants, pointer bounds, and relationships between program values. The checker does not search for invariants or invoke an SMT solver. It validates each claimed state transition and entailment using a restricted set of eBPF-specific reasoning rules.

For example, a loop certificate may provide an invariant relating an induction variable, a packet pointer, and data_end. The checker verifies that the invariant holds on entry, is preserved across the back edge, and is strong enough to justify each memory access. It does not need to infer the invariant or repeatedly explore the loop.

We have built a preliminary end-to-end prototype that generates and checks certificates for a subset of eBPF programs, including examples with control flow, loops, scalar relationships, and memory-safety obligations. Our early experiments indicate that certificate checking can perform particularly well on larger programs for which abstract interpretation requires extensive path exploration, state merging, or repeated loop analysis. In these cases, the checker benefits from being given the required invariants directly and can avoid much of the search performed by the existing verifier. These results are still preliminary and currently apply only to the supported subset. At LPC, we will present the supported feature set, representative examples, and an initial comparison of verification behavior and runtime, together with the cases where the approach does not yet apply.

A central design problem is defining the safety policy shared by the proof generator and checker. This policy must cover instructions, helper calls, kfuncs, program contexts, pointer accesses, and kernel-managed resources, while evolving with eBPF and its kernel interfaces. Its format, maintenance model, and relationship to existing verifier semantics are part of the research question.

The talk will present the architecture, certificate language, prototype, and initial results. We will also discuss certificate size, malformed or adversarial certificates, unsupported features, policy evolution, verifier transformations, and the relationship between checked bytecode and JIT semantics.

We seek feedback from the eBPF community on whether this is a useful and technically plausible way to structure safety checking, which parts of current verifier semantics are hardest to express as explicit proof obligations, and whether a maintainable shared safety policy is possible.

Relation to Prior Work

Proof-carrying verification for eBPF was previously explored by Exoverifier, which separates proof generation from proof checking and emits general proof objects based on a Lean formalization of eBPF semantics. More recently, VEP proposed an annotation-guided toolchain with userspace verification, a specialized compiler, and a lightweight bytecode-level proof checker. BCF takes a hybrid approach: it retains the kernel verifier’s abstract interpretation, while using machine-checkable proofs generated in userspace to guide abstraction refinement and improve precision.

Our work explores another point in this design space. Rather than relying on general theorem-prover objects, source annotations, or refinement of the existing verifier analysis, we are designing a restricted certificate language around eBPF-specific invariants and state transitions. The checker accepts only a fixed set of reasoning steps, with explicit limits on certificate structure and checking work. Our preliminary prototype suggests that this model is sufficient for a useful subset of programs while remaining closely aligned with current eBPF concepts. The talk will compare these approaches and discuss which parts of eBPF verification fit restricted certificate checking and which may require richer reasoning.

Speaker: Martin Fink (Technical University of Munich)

16:30 Coffee Break

37 kops and rejit: Safely Optimizing eBPF for Hardware and Workloads

eBPF users pay for verified safety with performance. Across 27 microbenchmarks extracted from production programs, code that reaches native speed when compiled directly is up to 2x slower through the eBPF pipeline. The gap is structural and cannot be closed by LLVM optimization passes or source code rewrites: every deployment runs on specific hardware under a specific workload, yet the pipeline is a single-pass JIT deliberately kept simple to keep a minimal trusted computing base (TCB), without many optimizations. For example, a 64-bit rotate costs 15 machine instructions in the eBPF JIT instead of one ROL. Hardware features and registers, and workload facts such as stable input patterns, map contents, and biased branches remain under-explored. Improving the JIT in place needs upstream acceptance, enlarges the TCB that years of formal-methods work have hardened, and grows per-architecture kernel code.

The talk covers two pieces that try to approach this problem with minimal additions to the kernel TCB. BpfReJIT is a userspace library built on LLVM: an in-process shim intercepts an unmodified application's load and attach calls, rewrites the bytecode based on configs, workloads, and the kernel version, and resubmits every candidate through the original verifier and JIT. It can perform runtime speculative optimization similar to V8 or the JVM, but separates correctness (ensured in userspace) from safety (ensured in the kernel). Kops is the part that needs a kernel patch and discussion. A small one-time patch adds an interface through which kernel modules can register new hardware-specific operations without further core changes. Each operation carries a proof sequence of vanilla eBPF instructions that the verifier checks on every load, plus a native emit that the JIT compiles. We can further leverage Lean 4 proofs to establish that the two compute the same result, so the emit is the only per-operation addition to the TCB. Seven hardware-idiom operations yield speedups of up to 24% on x86-64 and 22% on ARM64, and add up to 12% datapath throughput on Cilium and Katran. We would like feedback on the interface design, on where module-supplied emits sit in the kernel's trust story, and on when to apply an operation at all, since naively applying every matched site can regress.

Speakers: YUSHENG ZHENG, Hao Sun (ETH Zurich)

38 BPF, sysctls and programmable kernel decision points

Traditionally the kernel community have introduced new sysctl tunables in places in the code where there is no "one-size-fits-all" answer. With BPF we have the opportunity to make such decision points programmable. A simple example of this is the kernel socket acceptq length, set via a combination of the listen() backlog and somaxconn sysctl. While the traditional advice has been to set this to a very high value to allow for connection bursts, doing so can lead to unacceptable connection latencies for applications, particularly when the application is doing CPU-intensive processing that limits connection acceptance rate. We only drop SYNs when the acceptq is full, but in such cases it would be beneficial to drop earlier to allow the service to recover. Having a BPF program attached could detect such conditions and handle this case by dropping SYNs. Having a dynamic response - potentially informed by wider system state - would be helpful here and in other cases. Investigation of decision points like these for BPF programmability - perhaps via a general sysctl()-centric BPF attachment - would be worth exploring.

Speaker: Alan Maguire (Oracle)

39 eBPF Security: The Uneven Landscape

Although eBPF is widely used to extend the Linux kernel, running programs in kernel space introduces critical security risks. Existing technical work often overlooks eBPF's entire security lifecycle. This talk aims to address this gap by systematically analyzing eBPF vulnerabilities, mitigations, and architectural limits. By reviewing research papers and CVEs, we will map real-world exploits to specific components, revealing that current defenses target isolated attacks rather than systemic architectural risks. Finally, we will present key takeaways, outline open directions toward lifecycle-aware, composition-safe security models, and highlight understudied non-verifier components.

Speaker: Gürkan Gür (Zurich University of Applied Sciences ZHAW)

Birds of a Feather (BoF): No A/V

40 Debugging CPU isolation / nohz_full

Installing a CPU isolated workload for extreme low-latency expectations can be challenging. Requirements and settings have been recently documented upstream but practice is another story. Let's discuss that around a live example.

Speaker: Frederic Weisbecker (Suse)

41 Rust for Linux Office Hours

A Rust-related BoF to work together on several topics, to answer questions or resolve pain points from attendees, to get to know people interested in Rust and Rust for Linux and generally to have some more time for discussion on top of the Rust MC.

The list of topics will be developed closer to the conference (and more may be added during the conference too), but some examples of potential topics would be:

• Review and discussion of particular patch series.
• Prototyping of a small project, e.g. implementing a kernel module.
• Providing assistance with pin-init and Klint.

Please feel free to join!

Speakers: Alice Ryhl (Google), Mr Andreas Hindborg (Samsung), Benno Lossin, Boqun Feng, Danilo Krummrich, Dr Gary Guo, Miguel Ojeda

16:30 Coffee Break

42 BoF: Memory Efficiency on Modern Linux Systems

Discussion on how organizations are managing the complex tradeoffs related to efficient use of memory resources in heterogeneous workload, large-scale datacenter environments. Especially, as DRAM prices have exploded.

What guidance and future feature development should the community provide to support efficient use of this resource?

• zswap
• proactive reclaim agents
• DAMON
• PSI
• memory tiering
• memcg
• etc.

Speaker: Mykolas Krupauskas (Uber Technologies Inc.)

43 Updates and Future Directions for Resctrl RDT/MPAM/AMD/RISC-V

Significant progress has been made on the resctrl subsystem recently, driven by architectural evolutions across multiple hardware vendors. Key developments include Intel's separate control and monitor domains, ARM's IOMMU, NVIDIA's CPU-less MPAM support and MBW MAX hard limits, AMD's monitor counter assignment, and initial RISC-V inclusion.

Following last year's highly productive BoF, which successfully guided upstream development over the past several months, this session will bring the broader resctrl ecosystem together again—including maintainers and developers from Intel, ARM, NVIDIA, AMD, RISC-V, Google, Fujitsu, and Alibaba. While we will briefly review recent milestones, the primary focus of this session will be face-to-face discussion to address current architectural bottlenecks, maintain a clean cross-architecture abstraction layer, and reach consensus on future upstream design paths.

Speakers: Fenghua Yu (NVIDIA), Ben Horgan, Reinette Chatre

Gaming on Linux MC

The Gaming on Linux Microconference welcomes the community to discuss a broad range of topics around improvements for Gaming devices running Linux. Gaming on Linux has pushed the kernel to improve in several areas and has helped create new features for Linux, such as the futex_waitv() syscall, the Unicode subsystem, HDR support, sched_ext, and much more. Although some of these were initially created for gaming use cases, they now have more generalized use.

The potential topics for this year are around a lot of subsystems in the kernel, including:

• Tracking workchain-granularity deadline detection in sched_ext for improved latency and frame rates
• The current state of upstreaming a GPU cgroup controller
• Using the cgroup v2 MM controller to manage GPU-mapped DRAM
• Autonomous kernel-level performance monitoring and improvement for gaming on Linux workloads
• Resource management on gaming devices using Orchestrator
• Improvements in debug data collection
• Current challenges in standardized benchmarking of gaming on Linux
• Distro support for Gaming on Linux

Last year was the first edition of the Gaming on Linux MC, and the focus was fairly broad across various parties and subsystems in the kernel. Since last year, Linux has continued to increase its footprint in the global market share of gaming platforms. Thanks to advancements in the kernel and the larger ecosystem in e.g. Valve Proton, the vast majority of games now run on Linux at equal parity to Windows, or better.

As this MC continues to mature and find its rhythm, we hope to emphasize this year's discussions on concrete problems in the kernel and surrounding ecosystems that need to be addressed to enable Linux to become the preeminent gaming platform.

16:30 Coffee Break

Kernel Memory Management MC

Some people say that 2026 is the year of Linux Memory Management. Others weirdly disagree.

In any case, there is plenty to discuss, as MM is as busy as ever.

We are looking for topics that would be of interest to the kernel memory-management community.

In particular, we are also interested in topic suggestions from outside the core kernel community, including userspace, drivers, architectures, and other areas that affect memory management in the kernel.

Example topics that might be worth discussing this year include:

• Making (m)THP/large folios first-class citizens
• Supporting gigabyte THPs: allocators, compaction, policies
• Better policies: applying eBPF and friends sensibly in MM
• Polishing memory reclaim: making MGLRU less special
• Ongoing challenges with memdescs conversion
• Can we make device memory less special?
• Letting the kernel manage special-purpose memory
• Improving page promotion/demotion for memory tiering
• Challenges with hypervisor live-update integration
• Towards deprecating hugetlb: mshare, memory reserves
• The future of swap: missing pieces, cleanups, and do we still need zram?
• The future of memcg: new resources, optimizations, and cleanups
• Doing more with less memory (RAM is getting expensive ...)

A microconference talk should provide enough context to enable an open discussion about the topic being presented. In particular, presentation-focused talks with little room for discussion are not what we are looking for.

44 Reducing kernel stack memory (on arm64)

There have been a bunch of attempts [1] to reduce the memory consumed by kernel stacks for x86 and arm64, largely based around the idea of dynamically growing the kernel stack allocation based on page faults. This poses what appear to be insurmountable challenges, as it introduces complexity into the architecture exception entry code (which needs to be able to transition cleanly to a new stack) but also means that the kernel must be able to allocate memory from any context at all.

I would like to discuss and explore alternatives to dynamic stack allocation based on some initial rework I have started of the arm64 exception entry code[2]. Specifically:

• Revisiting the decision to move from 8k to 16k stacks
• Changing the kernel stack size at boot time
• Changing the kernel stack size per task
• Controlling the kernel stack size from userspace

I think it would also be useful to talk briefly about the sticking points with dynamic kernel stacks and whether there is anything that can be carried forward from that work.

My motivation is based on Android vendors having various out-of-tree implementations of the dynamic kernel stack series and I would like to see if there are alternatives that we can provide upstream so that we can all stop carrying the broken stuff around in our pockets.

[1] https://lore.kernel.org/all/20260424191456.2679717-1-stevensd@google.com/
[2] https://git.kernel.org/pub/scm/linux/kernel/git/will/linux.git/log/?h=overflow-stack

Speaker: Will Deacon

45 Better Anon (Swap) Readahead

When handling swap page faults, the kernel often don't reads just a single page. For legacy HDDs, an entire cluster is read in. For SSDs, we check the VMA and page tables to see if nearby pages are likely to be needed soon, using a basic statistic-driven heuristic. For compressed RAM (like zram, and potentially soon zswap), traditional readahead is skipped entirely. Meanwhile, enabling (m)THP swap-in currently acts as kind of a speculative fetching.

The current implementation is not really ideal. For example, why can't we extend (m)THP support to SSDs by merging readahead detection with (m)THP lookaround? Why can't we enable a lightweight readahead for compressed RAM as well? We also need a smarter heuristic, where workingset shadow entries could provide a much better hint than basic per-VMA statistics?

With so much active development in the swap subsystem, the goal of this session is to consolidate these scattered paths, and explore whether the swap readahead mechanism can share common, useful infrastructure.

Speaker: Kairui Song (Tencent)

46 DMA-buf cgroup accounting for proxy allocators: attributing buffers to the right consumer

On embedded and automotive Linux systems, a single daemon often allocates DMA-buf memory on behalf of other clients. Today, most of that memory is invisible to cgroup accounting, only system-heap buffers can carry a charge via __GFP_ACCOUNT, and even then it lands on the allocator’s cgroup rather than the app that requested the buffer.

The misattribution has real consequences on any system that uses cgroup memory limits to drive reclaim or enforce resource budgets, as untracked buffers silently skew pressure signals. For example, on Android, where app memory limits depend on per-app accounting; or on automotive systems, where strict Freedom From Interference (FFI) is a key requirement and a central allocator absorbing the charge of its clients across domains breaks any meaningful resource isolation argument.

In this session we will discuss the design space for fixing the proxy-allocator problem, presenting the context from our proposal in upstream. Should the charge be attributed at allocation time, or before export time? Should the allocator identify the target via a pidfd (natural for approaches like Binder, where the allocator already knows the sender_pid) or a cgroupfd? What happens with buffers that may belong to different cgroups across their lifetime?

Speakers: Albert Esteve (Red Hat), T.J. Mercier (Google)

47 Page fault locking

In 2023 we introduced per-VMA locks to solve contention and priority inversion on the mmap_lock for multithreaded programs. While successful, the initial implementation did not solve every case of contention and some workloads can still demonstrate problems. This session will discuss ways of fixing the remaining problems.

Speaker: Matthew Wilcox (Oracle)

16:30 Coffee Break

48 Direct map fragmentation

On supported configurations, the direct map is built using large
PMD/PUD-level block mappings. This is expected to bring many of the
benefits of hugepages: improved TLB hit rate, less page table walking,
smaller page table memory footprint.

This optimisation is most effective when the direct map gives access to
the entire physical memory with uniform permissions. Unfortunately, a
growing number of features need to remove pages from the direct map or
modify permissions/attributes at page granularity, causing PMD/PUD
blocks to be split down to PTEs.

According to results presented by Mike Rapoport at LSF/MM 2023 [1], the
performance impact of such fragmentation is negligible for data
accesses. However, recent measurements on x86 and arm64 suggest a more
nuanced picture, and other factors such as power consumption should also
be considered.

This session will briefly summarise key results, and then discuss
possible ways to reduce fragmentation.

Questions for discussion:

• Should direct map permissions be modelled as an allocation property
  in the buddy allocator, or managed by higher-level interfaces such as
  execmem or secretmem?
• Can x86 and arm64 use common logic for splitting and coalescing pages?

A few interesting sources of direct map fragmentation:

• execmem (may use PMD-sized pools; direct map PMDs will still be split
  if writing code)
• secretmem
• Confidential VMs including guest_memfd (encrypted/unmapped pages)
• pkeys-based page table protection

Proposals to reduce fragmentation:

• 2021/01 - PMD-sized pools for secretmem [2]
• 2021/04 - Grouped vmalloc [3]
• 2023/03 - __GFP_UNMAPPED based on dedicated cache [4]
• 2026/02 - pkeys-protected page table pools [5]
• 2026/03 - __GFP_UNMAPPED based on migratype/pageblock [6]
• 2026/06 - Collapsing blocks in secretmem [7]
• 2026/06 - EXECMEM_ROX_CACHE for arm64 with direct map PMD coalescing [8]

[1] https://lwn.net/Articles/931406/
[2] https://lore.kernel.org/lkml/20210121122723.3446-8-rppt@kernel.org/
[3] https://lore.kernel.org/lkml/20210405203711.1095940-1-rick.p.edgecombe@intel.com/
[4] https://lore.kernel.org/all/20230308094106.227365-1-rppt@kernel.org/
[5] https://lore.kernel.org/linux-hardening/20260227175518.3728055-1-kevin.brodsky@arm.com/
[6] https://lore.kernel.org/lkml/20260320-page_alloc-unmapped-v2-0-28bf1bd54f41@google.com/
[7] https://lore.kernel.org/all/20260603104624.36390-1-lance.yang@linux.dev/
[8] https://lore.kernel.org/all/20260611130144.1385343-1-abarnas@google.com/

Speaker: Kevin Brodsky (Arm)

49 Accelerating Page Migration and Making the Migration Core Composable

As the memory hierarchy deepens at both ends, with HBM adding a faster tier on top and CXL adding cheaper, slower capacity below, keeping hot data in the fast tier and shedding cold data downward makes page migration central to NUMA, tiered-memory and coherent CPU-GPU systems (where device memory is exposed as NUMA nodes).

Profiling move_pages(2) shows the folio copy dominates (~97% of migration time for a 2MB THP), making it the primary scaling bottleneck. Today this path is largely sequential: folios are copied one at a time by a single CPU, leaving DMA engines, idle cores and memory bandwidth underused.

To tap that idle hardware, this work separates the folio content copy from the rest of migration behind a pluggable migrator. The batch path:
- unmaps a batch of folios and flushes the TLB once,
- asks a migrator to copy the eligible folios,
- marks copied folios so the move phase skips the per-folio copy,
- completes the move through the existing flow [1].

The goal is not just the faster copy, but simplification and making different optimizations plug in as composable pieces rather than as special cases. So, the work proceeds in two directions: accelerating the dominant copy phase of migration and restructuring the migration core so that this and other independent optimizations can be added without further complicating it.

Accelerating the copy

Three complementary, measured directions:
1. dcbm - a DMA-based migrator using dmaengine devices, for bulk copy across multiple channels.
2. mtcopy - multi-threaded CPU copy across idle cores, a software fallback where no DMA/offload engine is available.
3. folio_copy() bulk copy for large folios (one bulk copy over the contiguous range); helps even without offload, independent of the batch framework [2].

I measured this with move_pages() on 1GB anonymous memory, dual-socket EPYC Zen 3, node 0 -> 1. Batch copy offload speeds up migration by several times for large folios: up to ~6x for a 2MB THP via DMA (dcbm, 16 channels) and ~3.8x via multi-threaded CPU copy (mtcopy, 8 threads).

Separately, a related demotion effort uses non-temporal stores to reduce cache pollution and CXL-side read traffic [3].

Beyond the copy: the rmap phase

Once the copy is offloaded, per-base-page rmap work dominates for PTE-mapped large folios (mTHP). The unmap and restore rmap walks each run once per subpage. Batching those walks is the next lever, and its payoff grows with folio size: in this setup a 1MB folio reaches ~5.6x over vanilla with DMA offload, compared to ~2x with offload alone [7].

Reworking the core so these compose

Several ongoing efforts optimize different migration phases, and each one adds flags or special cases to the current monolithic path [1][3][4]. They run into the same limitation: ->migrate_folio() only gets enum migrate_mode, which describes the blocking semantics but not the migration intent (for example, promotion versus demotion). So, new behaviour ends up either extending migrate_mode or going through a side channel. For example, non-temporal demotion added MIGRATE_ASYNC_NON_TEMPORAL_STORES, while the DMA offload encoded FOLIO_CONTENT_COPIED in migrate_info.

I am prototyping two changes:

1. Pass a small context struct into ->migrate_folio() carrying mode, reason, and future attributes. This separates blocking behavior from migration intent and makes "how to copy" (cached, non-temporal, offload, and so on) be its own field.

2. Express migration as explicit phases:
   lock -> unmap -> [copy] -> move -> remap -> release

A shared engine categorizes the folios into separate lists: LRU folios, hugetlb folios and movable_ops pages each provide their migrate implementation. This gets rid of the folio_test_hugetlb() and page_has_movable_ops() checks scattered through the path today and makes the flow easier to follow.

Discussion

I'd like to use the session to validate the direction of the migration core work and how ongoing efforts should compose.

Key questions:

• Interface evolution: should ->migrate_folio() take a context struct? It touches every callback. Is that acceptable, and is it the right shape?
• Core structure: is an explicit phased migration engine with per-class callbacks a reasonable model for composability and maintainability? How far should movable_ops be decoupled from migrate_pages()?
• Copy helpers: The folio_copy() bulk path can regress without FSRM. Is the fix to improve memcpy() for !FSRM, or to add a dedicated copy_pages() helper?
• Batching trade-offs: What batch-sizes are acceptable when balancing throughput against first-folio latency? Should this be a tunable depending on hardware?

Roadmap:

Scatter-gather copy (DMA_MEMCPY_SG); additional migrators (SDXI [6]); topology-aware thread placement for multi-threaded copy; hot page promotion (pghot [5]) reusing the offload path; migration-side rmap batching; continued simplification of the migration core.

References:
[1] Migrator/offload RFC: https://lore.kernel.org/all/20260630-shivank-batch-migrate-offload-v6-0-da95d7e8b8a2@amd.com
[2] folio_copy optimization: https://lore.kernel.org/all/20260427142036.111940-4-shivankg@amd.com
[3] Non-temporal demotion RFC: https://lore.kernel.org/all/20260526-rfc-nt-demote-v1-0-eb9c9422daef@zptcorp.com
[4] migrate_mode/migrate_folio() ABI extensibility (Memory Hotness and Promotion call):
https://lore.kernel.org/linux-mm/37010218-ecad-4f75-961d-686d51b6677d@amd.com
[5] pghot: https://lore.kernel.org/all/20260504060924.344313-2-bharata@amd.com
[6] SDXI: https://lore.kernel.org/all/20260605-sdxi-base-v3-0-4d38ca2bdffe@amd.com
[7] rmap walk batch: https://lore.kernel.org/linux-mm/20260712-migrate-rmap-batch-v1-0-872a734431d1@amd.com/

Speakers: Shivank Garg (AMD), Zi Yan (NVIDIA)

50 Tackling Isolation Issues Due to Memory Pressure

On a densely shared host, a routine event breaks tenant isolation: a task holding a shared kernel lock (filesystem metadata, a control-plane mutex/rwsem) allocates inside the critical section, the allocation falls into memory reclaim, and until reclaim finishes every other task waiting on that lock — from any cgroup — pays the stall. Shared kernel locks aren't mediated by cgroups or memcg limits, so this is cross-tenant priority inversion, and overcommit makes it worse.

In this talk we will present the data we have gathered across the Meta fleet on this problem, and share how we think the solution should take shape. Rather than a finished design or patch series, the goal is to lay out the problem space, the constraints any fix must satisfy, our current direction, and the open questions and to get early feedback from the upstream community.

Speaker: Shakeel Butt

System Boot and Security MC

The System Boot and Security Microconference remains a key venue for engineers and researchers focused on the intersection of firmware, bootloaders, and kernel security. For 2026, we continue our mission to address the persistent friction encountered when upstreaming security-focused boot improvements. Our goal is to bridge the gap between low-level hardware initialization and the Linux kernel requirements.

Experience shows that integrating complex security technologies - like TrenchBoot or advanced attestation frameworks - often stalls due to architectural disagreements or a lack of cross-project coordination. We want to bring together developers from different layers of the stack (firmware, bootloaders, and kernel) to identify these bottlenecks.
We are interested in deep technical deep-dives, but also in the legal, licensing, and organizational aspects that often dictate how-and if-security standards can be integrated into the open-source ecosystem.

We invite proposals covering technical updates, work-in-progress, and strategic discussions on:

• TrenchBoot, tboot,
• TPMs, HSMs, secure elements,
• Roots of Trust: SRTM and DRTM,
• Intel TXT, SGX, TDX,
• AMD SKINIT, SEV,
• ARM DRTM,
• Growing Attestation ecosystem,
• IMA,
• TianoCore EDK II (UEFI), SeaBIOS, coreboot, U-Boot, LinuxBoot, hostboot,
• Measured Boot, Verified Boot, UEFI Secure Boot, UEFI Secure Boot Advanced Targeting (SBAT),
• shim,
• boot loaders: GRUB, systemd-boot/sd-boot, network boot, PXE, iPXE,
• UKI,
• u-root,
• OpenBMC, u-bmc,
• legal, organizational, and other similar issues relevant to people interested in system boot and security.

---

Progress in various areas after LPC 2025:

• Design Space and Challenges in Design of Attested TLS Protocols
  General Discussions

CVE (CVE-2026-33697) of score 7.8/10 discovered and responsibly disclosed
Security advisory

Public acknowledgement

CVE Record

NIST database

Discussions

Presentations, Slides, Videos etc. after LPC'25

• Who Authenticates Linux? Rethinking PAM & NSS in the Age of Cloud Identity

• The Future of Platform Security Measurement in Linux

• TrenchBoot Linux Kernel Developments

v15 patch set

v16 patch set

• Android Boot, DRTM, UKIs As an alternative solution to DRTM for ARM Mobile systems, Android's Virtualization team has delivered an EL2 stub

16:30 Coffee Break

VFIO/IOMMU/PCI MC

The PCI interconnect specification, the devices that implement it, and the system IOMMUs that provide memory and access control to them have become the de-facto standard for connecting high-speed components. The specification continues to expand with features spanning address translation (ATS/PRI), I/O virtualisation (SR-IOV/PASID/SVA), high-performance data movement (RDMA, P2PDMA, CXL/DOE), and hardware security (CMA, IDE, SPDM), targeting everything from server and desktop computing to embedded SoC platforms, virtualisation, and IoT devices.

The kernel code that enables these features requires tight coordination between PCI devices, the IOMMUs they sit behind, and the VFIO layer that exposes them to userspace for direct access and device passthrough. Kernel interfaces and userspace APIs across all three subsystems must evolve together to keep the overall design coherent.

Following the success of the VFIO/IOMMU/PCI MC at LPC 2017, 2019, 2020, 2021, 2022, 2023, 2024 and 2025, the 2026 edition will continue to bring together PCI, IOMMU, and VFIO developers to resolve cross-subsystem design questions that cannot be settled on individual mailing lists alone.

Video recordings from 2025 are available: LPC 2025 - VFIO/IOMMU/PCI MC. Older recordings can be found on the official Linux Plumbers Conference YouTube channel and the archived LPC 2017 VFIO/IOMMU/PCI MC web page at Linux Plumbers Conference 2017.

The tentative schedule will provide an update on the current state of the VFIO/IOMMU/PCI kernel subsystems, followed by focused discussion of current issues related to the proposed topics.

The following were outcomes of last year's successful Linux Plumbers MC:

• The TEE I/O initiative for confidential compute advanced through a phased plan spanning PCI, VFIO, IOMMUFD, and KVM. Phase 1 (PCI core support for authenticated and encrypted links via the TEE Security Manager) is largely complete, and most of the dma_buf, VFIO, and IOMMUFD infrastructure for Phase 3 (host-side private MMIO and DMA) has been merged. The critical remaining issue is KVM integration: an RFC for mapping from KVM's guest_memfd within IOMMUFD is under active review. The community also reached consensus on using Sub-Stream IDs (PASID) for hardware-level isolation when transitioning devices between shared and secure states.

• A new generic IOMMU page table infrastructure was merged in 6.19 for AMD and Intel VT-d, replacing six architecture-specific implementations with a unified codebase. Since the merge, RISC-V Svpbmt support, small VA support for AMD, and preserve/unpreserve/restore callbacks have been posted, with fixes flowing through the IOMMU tree for v7.1.

• Building on the generic page tables, design consensus was reached on the Hyper-V pvIOMMU and an RFC v1 has been posted. Key decisions: simple gIOVA without PASID is acceptable, the HV IOMMU driver will not cover ARM SMMU, per-device PASID space is required, and hypercall-based enumeration without ACPI tables is acceptable. Follow-up work is addressing IOTLB tagging with domain ID differences on Intel VT-d and AMD IOMMU.

• SDXI (Smart Data Acceleration Interface) and Smart Data Cache Injection (SDCI) via PCIe TLP Processing Hints (TPH) were presented, demonstrating up to 70% memory bandwidth reduction in 100G NIC benchmarks. Since the conference, a SDXI driver series has been posted and VFIO PCIe TPH support patches are under review.

• The PCI power control (pwrctrl) framework rework reached design consensus and has since been merged, resolving timing flaws where host controller drivers deasserted PERST# signal before endpoints were powered. The new API restores PCIe spec compliance and enables proper D3cold suspend flows, with controller drivers already adopting the new interface.

Tentative topics that are under consideration for this year include (but are not limited to):

PCI: CCIX/CXL expansion memory and accelerator management; DOE; IDE; CMA; SPDM; IOASID allocation; INTX/MSI IRQ domain consolidation; Gen-Z interconnect fabric; error handling and management (AER, DPC, APEI, EDR); power management and ASPM; P2PDMA; resource claiming/assignment consolidation; DMA ownership models; Thunderbolt, DMA, RDMA, and USB4 security.

VFIO: I/O Page Fault (IOPF) for passthrough devices; SVA interface; SR-IOV/PASID integration; PASID in SR-IOV virtual functions.

IOMMU: /dev/iommufd development; IOMMU virtualisation; IOMMU driver SVA interface; DMA-API layer interactions and the move towards generic dma-ops for IOMMU drivers; IOMMU core changes (e.g., tighter integration with the device-driver core).

If you are interested in participating in this MC and have topics to propose, please use the Call for Proposals (CfP) process. Additional topics may be added based on CfP submissions.

Otherwise, join us in discussing how to help Linux keep up with the new features added to the PCI interconnect specification. We hope to see you there!

Key Attendees:

Alex Williamson, Benjamin Herrenschmidt, Bjorn Helgaas, Dan Williams, Ilpo Järvinen, Jacob Pan, James Gowans, Jason Gunthorpe, Jonathan Cameron, Jörg Rödel, Kevin Tian, Krzysztof Wilczyński, Lorenzo Pieralisi, Lu Baolu, Manivannan Sadhasivam.

Contacts:

• Alex Williamson (alwilliamson@nvidia.com)
• Bjorn Helgaas (helgaas@kernel.org)
• Jörg Rödel (joro@8bytes.org)
• Lorenzo Pieralisi (lpieralisi@kernel.org)
• Krzysztof Wilczyński (kwilczynski@kernel.org)

16:30 Coffee Break

Tuesday 6 October

AI-Assisted Open Source Development MC

Overview

AI coding tools (LLMs, code assistants, AI agents) are rapidly becoming part of the developer workflow across the software industry. Open source communities are beginning to grapple with how these tools intersect with their development processes — from code generation and review assistance to documentation, debugging, and large-scale refactoring. This microconference will bring together maintainers, developers, and tooling experts to discuss the practical realities, policies, risks, and opportunities of AI-assisted development in the open source ecosystem.

The goal is not to debate whether AI tools will be used — developers are already using them — but to align on how communities should adapt their processes, what guardrails are needed, and where these tools can deliver the most value with the least risk.

Example Subtopics

• AI-assisted code generation and review — practical experiences, failure modes, and disclosure norms
• Large-scale refactoring with AI assistance, such as C-to-Rust conversions
• AI for debugging, crash analysis, and root cause identification
• Policy and process implications: attribution, copyright, licensing, and trust in AI-generated contributions
• AI-powered test case generation and fuzzing guidance
• Building project-aware AI tooling with domain-specific context and integration with existing development infrastructure

Key People Who Should Attend

• Major subsystem and project maintainers who are receiving AI-assisted contributions and need to make policy decisions
• Developers actively using AI tools in their open source workflows who can share real-world experiences
• AI tooling developers building tools targeted at open source and systems-level development
• Linux Foundation / legal experts for the policy, licensing, and attribution discussion

Previous Related Sessions

While there has not been a dedicated AI microconference at LPC before, related discussions have touched on adjacent topics in microconferences such as Kernel Testing & Dependability, Rust for Linux, and Toolchain. This would be the first session to bring together the AI-specific cross-cutting concerns that span all of these areas.

Expected Outcomes

• Community alignment on disclosure and attribution requirements for AI-assisted contributions
• Identification of high-value, low-risk use cases where AI tools should be encouraged
• Concrete next steps for building project-aware AI tooling
• Framework for evaluating AI-generated code in the review process

11:30 Coffee Break

Birds of a Feather (BoF): No A/V

51 Kernel Sanitizers Office Hours

The Linux kernel has numerous tools to detect bugs, among them a family of dynamic program analysis called "sanitizers": Kernel Address Sanitizer (KASAN), Kernel Memory Sanitizer (KMSAN), Kernel Concurrency Sanitizer (KCSAN), and the Undefined Behaviour Sanitizer (UBSAN). Although not a bug-detecting sanitizer itself, we will also cover Kernel Coverage (KCOV), which utilizes similar compiler instrumentation to collect and expose execution feedback.

Knowing when to apply which sanitizer in the kernel development process may not always be obvious: each sanitizer is dedicated to finding a different class of bugs, and each introduces some amount of performance and/or memory overhead. Not only that, each sanitizer also provides a range of options to tweak their abilities.

This session is dedicated to briefly introducing each kernel sanitizer, the bug classes they help detect, and important gotchas when using them.

The rest of the session is dedicated to answering questions around each of the sanitizers, KASAN, KMSAN, KCSAN, and UBSAN. Feel free to also share success stories that may give other attendees only starting out with some of the sanitizers ideas how to best apply them.

Speakers: Aleksandr Nogikh (Google), Alexander Potapenko (Google), Dmitry Vyukov (Google), Justin Stitt (Google), Kees Cook (Google), Marco Elver (Google), Pimyn Girgis (Google)

52 Linux CVEs, vulnerability management and agentic security workflows

This year has been marked by the rise of cyber-capable AI models, flooding maintainers with increasingly better vulnerability reports. More vulnerabilities have been reaching the headlines, resulting in emergency mitigations across different deployments. In response, many organizations have adopted agentic solutions to scan, triage, reproduce, and patch vulnerabilities.

During this year's BoF, we plan to not only update the community on our ongoing efforts with CVE triaging (https://github.com/cloud-lts/linux-cve-analysis), but also to discuss these common agentic efforts. Our objective is to boost cross-organizational collaboration and support the security community in navigating these new challenges.

Speaker: Damiano Melotti (Google)

11:30 Coffee break

53 DRM Fabric: Vendor-Neutral Topology Infrastructure for Scale-Up Accelerator Interconnects

Modern GPUs and dedicated AI accelerators are increasingly connected through scale-up interconnect fabrics such as AMD xGMI today and UALink in the near future. Yet Linux lacks common topology infrastructure for reporting, vendor-neutrally, which accelerators are directly connected, through which ports, and in what state. Vendors expose fragments privately — e.g. amdgpu's xGMI sysfs — and prior per-driver proposals, such as XeLink, never became shared Linux infrastructure. As a result, topology semantics are being defined by vendor-private uAPIs rather than by a shared Linux control-plane contract for monitoring and fabric management.

Building on the LPC 2025 "Toward Mainline Linux Support for UALink" BoF, we propose DRM Fabric: a vendor-neutral, protocol-agnostic DRM topology infrastructure for scale-up interconnects, using the model:

fabric → endpoint → port → peer

Vendor drivers populate it through a thin provider API; userspace queries it through drm-fabric, a YAML-defined generic-netlink family consumed through ynl tooling, following the netlink uAPI pattern drm_ras introduced to DRM. No data path: load/store traffic and memory semantics remain in the vendor driver, so the infrastructure remains valid across vendors and fabrics.

The implementation is split into two RFC series. Phase 1 targets provider-owned fabrics, such as an xGMI-like implementation, where the driver discovers topology and reports it read-only to userspace, including notifications, optional port statistics, and consistent multipart enumeration. Phase 2 adds privileged provisioning for software-defined, UALink-style fabrics: creating fabric containers, attaching orphan endpoints, setting administrative state, and provisioning peers on userspace-managed ports, while providers continue to report actual hardware state. The RFCs include the core infrastructure, an in-tree synthetic provider (fabricsim, modeled on netdevsim), and KUnit plus pyynl/kselftests exercising the infrastructure and uAPI end-to-end without hardware. The next step is a hardware-backed provider for an already-shipping scale-up fabric.

We want LPC feedback on the DRM representation, the boundary between provider-owned topology and privileged userspace provisioning, whether the proposed provisioning primitives are sufficient, and how AMD, Intel, UALink Consortium members, and other accelerator vendors should co-develop the common infrastructure and provider interfaces.

Speaker: Mr Konstantin Sinyuk (Intel)

13:30 Lunch

54 Bridging the Linux Tux and the FreeBSD Beastie – Linuxulator, LinuxKPI, and LLM-Assisted Porting Challenges on License Issue

The boundary between the Linux and FreeBSD ecosystems is often loose and porous,while developers continuously building bridges to maximize hardware support and software availability across both platforms.

Two mechanisms carry that weight on shoulders: the Linuxulator, a native
implementation of the Linux syscall ABI that runs unmodified Linux binaries,
and LinuxKPI, a shim layer that lets FreeBSD build largely unmodified Linux
drivers -- the DRM drivers via drm-kmod, mac80211-based wireless drivers, and a growing set of others -- against a subset of the Linux in-kernel API.

Depending directly on the ripples from Linux's advancements, Linuxulator tracks syscall, vDSO, /proc, netlink and seccomp behaviors and LinuxKPI tracks an in-kernel API that is explicitly not stable, which makes every DRM or wireless driver during release cycle into an aerobics workout.

Hence, this Birds of a Feather (BoF) session is then hereby proposed to serve as an information exchange hub for developers working at the intersection of Linux and FreeBSD kernel mechanisms.

Furthermore, FreeBSD is not the only Frankenstein here: Fuchsia's starnix and illumos LX zones reimplement parts of the exposed surface of Linux userspace, and several BSDs have maintained downstream of DRM shims of their own. So if you are also an amphibian developer other operating systems. Don't hesitate to join us :-)

During this session, we may discuss topics including but not limited to :

• Linuxulator (Linux Emulation Layer): The current state, limitations, and future enhancements of running unmodified Linux binaries on FreeBSD. E.g. RISC-V architecture.
• LinuxKPI: The compatibility framework designed to ease the porting of complex Linux kernel drivers (such as DRM and wireless drivers) to FreeBSD. We will discuss the friction points driver maintainers face and how the Linux community's API changes impact downstream compatibility.
• The LLM Porting and License Issues: With the rise of Large Language Models (LLMs), developers are actively experimenting with AI to assist in translating or porting drivers from Linux to FreeBSD. However, this introduces complex license compatibility questions i.e. GPLv2 vs. BSD. And thus shall deserve a chat with beers in my humble opinion. And here's the living witness of such kind of work : aqtion-freebsd-aq2 work.

Related discussions could be found in AsiasBSDCon 2026

Speaker: "Ruinland" ChuanTzu Tsai (Andes Technology)

16:30 Coffee break

55 Improving THP placement policies

Transparent Huge Page placement has historically been (and is) quite simplistic and overeager. This normally results in users turning off THP completely, or for selected workloads using any number of available toggles.

I'd like to discuss realistic ways in which we could meaningfully improve this, including past ideas such as thp=auto.

Several relevant aspects would include:
- adapting THP placement based on filesystem/storage needs
- adapting THP placement based on userspace memory accesses
- adjusting and improving expectations on MADV_COLLAPSE
- getting rid of hard-to-tune heuristics like max_ptes_none & others

Speaker: Pedro Falcato (SUSE Labs)

56 DAMON Nano Conference

DAMON is a kernel subsystem for efficient data access/attributes monitoring and memory operations. It received many updates last year. Many more updates are in progress. Multiple ideas for future works are flooding. In this session, multiple people who work on DAMON will present and discuss what changes have recently been made, what changes are ongoing, and what should be the next work.

Schedule

Note that the schedule could be updated until the last minute.

17:45-17:48 Opening
17:48-17:55 Breaking through Accessed Bit Limits of DAMON, SJ Park, Ravi Jonnalagadda, Akinobu Mita
17:55-18:05 Beyond Weighted Interleaving: Bandwidth-Driven Memory Tiering with DAMON, Ravi Jonnalagadda
18:05-18:15 DAMON for Huge Pages
- Guiding THP Decisions with DAMON Memory Monitoring, Asier Gutierrez
- Host-side DAMON Hotness under KVM/THP: Granularity Gaps and Evidence for Demotion, Lian Wang, Kunwu Chan
18:15-18:25 DAMON in the AI Cloud: Monitoring Real-World GPU Workloads, Krishna Iyer
18:25-18:30 Joint QnA and Closing

Authors (Alphanetically sorted)

Akinobu Mita
Software engineer at Fixstars Corporation.

Asier Gutierrez
Senior Software Engineer at Huawei. Experienced Senior Software Developer specializing in Linux development, kernel-level debugging, and high-load, high-availability systems. I currently work for Huawei. I have worked for Intel, IBM and Yandex in the past.

Krishna Iyer
Krishna Iyer is a Software Engineer at Crusoe specializing in low-level systems, driver development, and Linux build systems. Previously at Cisco-Meraki, he now focuses on researching memory access patterns using DAMON for AI workloads on GPU infrastructure.

Kunwu Chan
Kunwu Chan works on the Linux kernel, with a focus on DAMON, huge pages, swap, and RCU.

Lian Wang
Lian Wang is a Software Engineer at Process Mission (Shanghai) Technology Co., Ltd. He works on Linux kernel memory management, with a focus on DAMON, huge pages, and memory management for virtualized and large-memory Systems.

Ravi Jonnalagadda
Ravi Jonnalagadda is a Sr Manager at Micron working on Linux kernel memory management for CXL and tiered-memory systems. He co-developed the weighted interleaving memory policy and added the node_eligible_mem_bp DAMOS quota goal. His current work lets DAMON take access samples from hardware sampling units.

SJ Park
SJ is a kernel programmer with a strong focus on memory management. He develops and maintains DAMON, a Linux kernel subsystem designed for efficient data access monitoring and access-aware system operations.

Speaker: SJ Park

Devicetree MC

The Devicetree Microconference focuses on discussing and solving problems present in the systems using Devicetree as firmware representation. This notably is Linux kernel and U-Boot, which share the Devicetree bindings and sources, but also can cover topics relevant to Zephyr or System Devicetrees. Systems using Devicetree are majority of embedded boards, mobile devices and ARM64 laptops.

Ongoing problems, being discussed last year in LPC 2025 or previous years:

1. Status of DTS validation against DT schema among SoC platforms: are we getting to error-free dtbs_check anywhere? What are the blockers in achieving compliance, what is the progress.

2. Hot-pluggable hardware with Devicetree overlays (addons) - on-going efforts, discussed also on LPC 2024. Current work includes changing the DTB format (RFC patches posted).

3. Sharing DT bindings and DTS sources with U-Boot (aka OF_UPSTREAM): progress and what are the obstacles?

4. Shall we migrate all of_property_read_xxx() calls in Linux drivers to device_property_read_xxx() to handle also ACPI?

5. Fixing common pattern of unconditional device_init_wakeup() in drivers which makes it impossible to disable it via Devicetree, since wakeup-source is bool.

6. Style-checker (aka checkpatch) for DTS - tool automating all style related reviews. Discussed in 2025, but no tool got wide acceptance.

7. Power sequencing for enumerable busses - is it done yet? Discussion in 2025 suggested that at least MDIO is suffering from lack of generic solution for power sequencing.

8. How to choose and apply overlays, when vendor wants to ship many of them with single image. Many Android builds follow such approach. No generic properties/bindings were accepted so far. Discussed also in 2025.

9. DTB selection on EFI systems like arm64 laptops or embedded boards: How to store, update and choose the DTB to pass to the Linux kernel? The problem might be solved by Ubuntu Stubble, so is it considered a community consensus? What is still missing?

Key attendees:
AngeloGioacchino Del Regno, Arnd Bergmann, Bartosz Golaszewski, Bjorn Andersson, Chen-Yu Tsai, Conor Dooley, Douglas Anderson, Geert Uytterhoeven, Hervé Codina, Konrad Dybcio, Luca Ceresoli, Michal Simek, Nishanth Menon, Rob Herring, Saravana Kannan, Thierry Reding, Wolfram Sang

Expected attendees (very likely to come): Arnd Bergmann, Bartosz Golaszewski, Bjorn Andersson, Chen-Yu Tsai, Conor Dooley, Geert Uytterhoeven, Hervé Codina, Konrad Dybcio, Luca Ceresoli, Michal Simek, Wolfram Sang

57 DT bindings and sources shared with U-Boot: current status and ongoing work

Since early 2024, U-Boot has been synchronizing the DTS and bindings of each Linux release into the U-Boot source tree using git subtree functionality. Since this transition, some platforms like Amlogic or Qualcomm have immediately switched, and some older platforms have been actively migrating to upstream Linux DT sources and bindings while maintaining minimal local U-Boot DTS modifications.

Neil will summarize the current state of U-Boot's integration of these upstream DTS, provide an update on ongoing migrations, and outline the remaining work required to fully eliminate local U-Boot DTS modifications.

Speaker: Neil Armstrong (Linaro)

58 Status of the DTS Validation in the Linux Kernel

The great benefit of Devicetree bindings in the current DT schema format is the ability to validate the correctness of DTS (Devicetree sources) against those bindings. However, once validation was introduced, we discovered that many in-kernel DTS files simply did not pass.

Continuing such summary from 2025, what is the status of dtbs_check now? Which platforms have the most warnings and which are warning-free? What improved over last year?

This is a similar talk to one in 2025 LPC showing current stage of dtbs_check.

Speaker: Krzysztof Kozlowski (Qualcomm)

59 ACPI and Devicetrees

Last year's LPC discussion explored whether ACPI-defined hardware descriptions could be reused on systems booting with Devicetree, and where the boundary should exist between the two firmware ecosystems.

Since then, several related efforts have continued across the kernel community, having intermediate representation for MIPI DISCO tables for SDCA, emerging ACPI-DT hybrid approaches. At the same time, new platform requirements—particularly on ARM64 laptops and embedded systems—continue to challenge the traditional "ACPI or DT" model.

This session will review the current state of these efforts, How should systems without ACPI tables should work with drivers like SDCA, discuss practical use cases where combining ACPI and Devicetree provides value, examine ongoing hybrid firmware work, and identify remaining technical ad architectural challenges. The goal is to gather feedback on whether the community should continue evolving hybrid solutions, standardize common mechanisms, or pursue alternative directions given that we have more data points.

Key Highligths:
- Ongoing efforts.
- Current Status of work on SDCA.
- ACPI-DT hybrid mode and future.
- Systems without ACPI tables(mobile devices).

Speaker: Srini Kandagatla

60 Streamlining DT Bindings to Protect Upstreaming Momentum

Corporate adoption of an "upstream-first" strategy is gaining traction, with companies increasingly willing to allocate engineering bandwidth to contribute hardware support directly to the Linux kernel. However, integrating these contributions smoothly remains a practical challenge. The review process frequently experiences friction during Device Tree (DT) binding discussions, which can extend timelines, consume allocated engineering bandwidth, and occasionally discourage newcomers to the open-source ecosystem.

This discussion explores ways to accelerate DT binding adoption so developers can maintain their focus on driver implementation. We will discuss current friction points and propose solutions to streamline the process. Specifically, we will evaluate the concept of "experimental bindings"—exploring whether provisional bindings could be used under certain circumstances to unblock driver development and maintain contributor momentum without compromising the long-term quality of hardware descriptions.

Speaker: Amit Kucheria

11:30 Coffee Break

61 Device Tree Addons: Describe hot-pluggable extension boards

Device Tree has been extremely successful at describing non-discoverable hardware in Linux and other embedded systems. However, it remains fundamentally monolithic: each Device Tree describes a complete system, and reuse across independently developed hardware components is limited.

This becomes problematic for modular platforms where expansion boards, mezzanines, daughter cards, or hot-pluggable hardware are expected to work across multiple base boards. While Device Tree Overlays provide a mechanism to modify an existing hardware description, they require detailed knowledge of the target system. They do not offer a robust way to describe addon boards independently of the base platform nor a way to use the same addon board description to describe the same board connected on multiple connectors available on a single base board.

The recently proposed Device Tree Addon format [1] aims to address those limitations. It allows a single addon DTB to describe an extension board that can be used on different connectors of a given base board, or on different base boards, without requiring board-specific customization.

The design goal of Device Tree Addon is illustrated in slides used for a talk given at ELCE 2025 [2]. The relevant slides sections are the following:
- Use case and goals
- The connector abstraction.

The "Connector: current status" section available in [2] is now obsolete. The Device Tree Addon concept emerged from discussions [3] that followed the ELCE 2025 conference.

This session will briefly present Device Tree Addon concepts recently
introduced and available in the RFC implementation [1]. Beyond introducing the format, the focus will be on the remaining challenges that must be addressed before broader adoption.

Topics for discussion include remaining design questions, integration with
Device Tree bindings and validation rules, standardization efforts in Devicetree Specification (DTSpec). We will also examine the work still required in dtc, libfdt, bootloaders, and the Linux kernel.

The goal of the session is to gather feedback from Device Tree maintainers,
kernel developers, bootloader developers, and users of modular hardware platforms to help shape the future direction of Device Tree Addons.

[1] https://lore.kernel.org/all/20260112142009.1006236-1-herve.codina@bootlin.com/
[2] https://bootlin.com/pub/conferences/2025/elce/ceresoli-hotplug-status.pdf
[3] https://lore.kernel.org/all/20250902105710.00512c6d@booty/

Speaker: Hervé Codina

62 Using DT overlays to manage a collection of related boards

It is commonplace that many boards in the real world have many sibling or cousin boards that are 95-99% the same as each other. Some examples:

• During development, most boards go through several revisions. A board might have proto0, proto1, evt0, evt1, evt1.1, dvt1, pvt, and mp revisions. These revisions almost the same with just small changes. While only "mp" (mass production) devices should end up in the public's hands, old prototype devices continue to be used for many years within the companies supporting the hardware.
• Many boards have several small variants that are nearly the same. As an example, the Pixel 10, Pixel 10 Pro, and Pixel 10 Pro XL are based on the same design and are nearly the same.
• Many boards are based on a reference design and only make small changes from that reference design. Chromebooks are one example of this. "sc7180-trogdor" was a reference design and a pile of different ODMs took this design and made small changes. Outside of Chromebooks, many phones are heavily based on the reference design of the SoC vendor.

Products that are highly similar to each other usually end up sharing a single binary image that is shipped out. That single image contains all needed device trees. Firmware on the product can figure out which specific device it's running on and can pick the correct device tree.

The common practice in the upstream device tree repository today is that each of these very similar boards needs its own complete device tree. The device tree is often shared using #includes of .dtsi files, but the final result is a pile of .dtb files that are mostly the same.

There are a few problems we have today. Two of them that are perhaps the most important:

1. All of those device trees take up a lot of space. It would be nice if we didn't need a whole pile of .dtb files that are nearly the same.
2. While firmware has all the details about the exact device it's running on, there is no standard way to mark device tree files so firmware can find the right one.

The device-tree overlay concept should help with point #1 in reducing the amount of space things take up. Trying to get agreement about how this should look has been difficult, though. One question that came up is if a "base" device tree was required to be a board or not. For supporting Pixel 10 hardware, it was most convenient for the base device tree to represent the SoC itself since some Pixel 10 devices had a different revision of the SoC. A second question that came up is how to deal with the top-level device-tree "compatible" in this case. It was unclear if we needed some way to "merge" the compatible based on all the overlays included which then led into questions about what needed to be in this top-level "compatible" to begin with.

Trying to solve point #2 has come up again and again, but somehow we never end up with any resolution. The typical refrain is that we need a grand unified design that all device-tree loaders will agree to use, but this always fails to materialize.

Both problems have downstream solutions. As an example, Pixel phones ship with devicetree overlays to avoid some of the duplication. Device trees and their overlays on Pixel phones have special properties in them that are used to help firmware pick the right one at boot time. Trying to upstream these solutions has met with difficulty though.

Let's have a discussion where we look at prior attempts and see if we can make some more forward progress.

Some threads I've been involved in (this is by no means a complete list of threads about the topic):

• [PATCH 1/4] dt-bindings: arm: google: Add bindings for frankel/blazer/mustang
• [PATCH 4/4] arm64: dts: google: Add initial dts for frankel, blazer, and mustang
• Proposal: Officially allow "incomplete" trees as a base
• Proposal: document where SoC info belongs

Speaker: Doug Anderson

63 OS managed Devicetree overlays through UKI add-ons

SBCs like the Arduino UNO Q can have a number of extension boards, like the UNO Media Carrier or an Arduino shield connected. On top of this extra hardware may be connected through e.g. CSI camera connectors and DSI display connectors.

Each of these possible hardware addons needs a DT overlay to work. This requires some method for the user to select which DT overlays to use.

There have been several attempts a decade ago to allow loading DT overlays from Linux userspace for this, but non has ever been accepted upstream.

UKI addons can provide an updated DTB, the purpose of this session is to present and discuss a proposal to use this to manage DT overlays from userspace through UKI addons:

Phase 1: UKI addons with a replacement DTB file embedded

• For systems booting with secureboot, create DTBs with overlays merged in for popular hardware addon combinations and build a signed UKI addon for each such DTB on the distros build-system.

• For systems without secureboot any overlay combination can be supported by building a merged DTB locally and creating an UKI addon from that DTB.

Phase 2: UKI addons with a DTBO file embedded

• For this phase the UKI stub needs to be extended with the capability to merge DTBOs from addons into an earlier loaded DTB, allowing any combination of overlays by the distro providing a signed UKI addon for each available overlay.

Speakers: Agathe Porte (Qualcomm), Hans de Goede (Qualcomm)

KVM MC

KVM (Kernel-based Virtual Machine) enables the use of hardware features to
improve the efficiency, performance, and security of virtual machines
created and managed by userspace. KVM was originally developed to host
and accelerate "full" virtual machines running a traditional kernel and
operating system, but has long since expanded to cover a wide array of use
cases, e.g. hosting real time workloads, sandboxing untrusted workloads,
deprivileging third party code, reducing the trusted computed base of
security sensitive workloads, etc. As KVM's use cases have grown, so too
have the requirements placed on KVM and the interactions between it and
other kernel subsystems.

The KVM Microconference will focus on how to evolve KVM and adjacent
subsystems, with a strong emphasis on all things guest_memfd.

Potential Topics:
- 1GiB hugepage support for guest_memfd[1]
- KVM Userfault, or: demand paging support for guest_memfd[2]
- Removing guest memory from the host kernel's direct map[3]
- Eliminating "struct page" for guest_memfd
- Paravirtual scheduling
- Nested virtualizaton optimizations, e.g. PV APIs for "nested" VMs

Successes from LPC 2024:
- KVM x86's mediated virtual PMU support landed in 7.0[4]
- pKVM support for protected anonymous memory landed in 7.1[5]
- In-place private<=>shared conversion for guest_memfd[6] is nearing
inclusion (likely 7.2 or 7.3)

[1] https://lore.kernel.org/all/cover.1747264138.git.ackerleytng@google.com
[2] https://lore.kernel.org/all/20250618042424.330664-1-jthoughton@google.com
[3] https://lore.kernel.org/all/20260410151746.61150-1-kalyazin@amazon.com
[4] https://lore.kernel.org/all/20251206001720.468579-1-seanjc@google.com
[5] https://lore.kernel.org/all/177505732748.363663.16964917665296494635.b4-ty@kernel.org
[6] https://lore.kernel.org/all/20260507-gmem-inplace-conversion-v6-0-91ab5a8b19a4@google.com

11:30 Coffee Break

Kernel Summit Track

64 Kernel CVEs at AWS Scale: Two Years of Empirical Findings

Since the Linux kernel project became a CVE Numbering Authority (CNA) in February 2024, organizations maintaining custom kernels have faced a flood of CVE disclosures.

We present empirical findings, lessons learned, and the key challenges that the kernel team responsible for Amazon Web Services fleet infrastructure encountered over the following two years while handling the steady flow of kernel CVEs.

We summarize our approach to assessing kernel CVEs in a warehouse-scale environment, pruning our code base to reduce the attack surface, along with quantitative results from field data. Specifically, we examine

• how NVD/CVSS scores and third-party assessments correlate with our final in-house ratings;
• how community guidance, including stable tree tracking and domain-specific risk assessment, measurably improved our development velocity, kernel maintenance, and kernel adoption strategy; and
• how backporting practices introduce regressions and compound risk.

We then present data on patching velocity and CVE-related trends across LTS versions. Although our data comes from a single environment, we believe these findings generalize to any organization that maintains in-house or custom kernels.

We will close with an open discussion on emerging developments (including where AI-assisted tooling fits into the CVE triage and patching pipeline) and invite attendees to challenge, extend, or contradict our findings with their own data.

Speakers: Mr Dylan Johnson (Amazon Web Services), Mr Justinien Bouron (Amazon Web Services)

65 Regressions & tracking them: current state, plans, and what do you want?

Provide a quick "state of the union" about the Linux kernel regression ecosystem in the first part of the session before spending the second discussing what improvement the members of the audience wish for in this area.

The first part is meant to take less then half of the allotted time and will cover things like:

• KernelCI and regzbot joined forces -- what this means for the future.
• Tracking regressions with regzbot, the regression tracking bot: status and future plans.
• Linux development workflow patters that lead to regressions or delay resolving them.
• Brief "what to do and what not" when reporting regressions.

The second half will be audience driven and might discuss details in the areas raised earlier, things like the following, or whatever the audience is interested it:

• Regression tracking with regzbot still useful in the age of AI?
• How to improve interaction with parties interested in the space of CI, regressions, and tracking them – like kernel maintainers of distros that regularly update their kernels to latest stable or longterm series.
• Is there interest in trees with "pending" and "wip" regression fixes?

In case I'm invited to the kernel maintainers summit I'll also collect topics with regards to regressions the audience wants me to bring up at kernel maintainer summit a few days later.

Speaker: Thorsten Leemhuis

11:30 Coffee Break

66 Challenges in multi-tenant GPU sharing

We would like to share some of the challenges we have encountered in a multi-tenant GPU environment, discuss the solutions we have explored, and gather feedback from the community.

To provide context for the audience, we will start by giving an overview of our multi-tenant architecture. We then plan to discuss several areas where we have encountered challenges, including:

• GPU reset and debugging
• Identifying the problematic tenant session among many concurrent sessions
• Missing resource management capabilities, especially around memory cgroups
• Lock contention in drivers
• Power distribution across different system components

We would like to close the session with an open discussion on the issues and solutions presented. If the right audience is present, we would also like to discuss what a reasonable roadmap could look like for improving Linux support for multi-tenant GPU platforms.

Speakers: Boqun Feng, Gregoire Pean, Jatin Kataria

67 Maintainer-oriented features of b4

B4 is already a well-known tool for retrieving and applying series from lore.kernel.org. Recently, it gained several new features that can make the life of a maintainer a bit easier:

• b4 review - helps with code review and full series lifecycle management
• b4 bugs - integrates distributed bug tracking into your workflow

This session will go over the new features and how they can assist overloaded maintainers in keeping a handle on the stream of incoming changes.

Speaker: Konstantin Ryabitsev (The Linux Foundation)

13:30 Lunch Break

68 Rust for Linux

Rust for Linux is the project adding support for the Rust language to the Linux kernel. This talk will give a high-level overview of the status and the latest news around Rust in the kernel since LPC 2025.

Speaker: Miguel Ojeda

69 Leveraging Rust's Field Projections in the Kernel and Beyond

Several Rust contributors and I have been collaborating on a novel language feature called "Field Projections". The feature is still being designed and implemented, so now is a good opportunity to experiment with it to see what new APIs it unlocks for the Kernel and other projects. We also want to investigate any gaps in our current design that prevent important use-cases from being supported.

Rust makes heavy use of custom pointers filling the gap (& going beyond) between references (&T and &mut T) and raw pointers (*const T and *mut T). Currently, they have two major issues: ergonomics and feature parity with builtin references and Box<T>. Raw pointers and their extensions (e.g. NonNull<T>) have especially bad ergonomics. Our Field Projection language feature aims to remedy these shortcomings of custom (dumb & smart) pointers; our current approach is an ambitious generalization of Deref that supports a plethora of custom pointers from MyBox<T> (that has all the properties of Box<T>) to VolatilePtr<T> (which is only using {read,write}_volatile to access the pointee). Our proposal integrates tightly with existing features such as place expressions, operations on places, the borrow-checker, and autoref.

Speaker: Benno Lossin

16:30 Coffee Break

70 DRM: handling runtime requirements for device components.

The DRM susbsytem grew up from the desktop GPUs, where the device is a single unit, powered on and off only at the important runtime points. For the embedded display controllers it's no longer true. The display pipeline can consist of several different devices, each having its own runtime power up and down code points. Handling device power on and off in the existing atomic callbacks makes the code fragile: it's too easy to create a disbalance of calls or to miss a register access from one of the points.

In this talk I would like to point out these issues and trigger a discussion about possible ways to solve the issue.

Speaker: Mr Dmitry Baryshkov (Qualcomm)

71 Bringing Linux DRM Display Panel support in the modern age

Since the introduction of the first Samsung DSI panel, the Linux DRM panel API has been a crucial piece of software for enabling displays across diverse architectures, but it has not evolved alongside modern graphics stacks. Currently, the API lacks atomic DRM API support and the ability to adapt power setups during mode changes. Furthermore, it fails to support advanced Display Driver IC (DDIC) features that modern hardware heavily relies on, including:
- Standby and advanced power states
- Advanced color management
- Dynamic rate switching
- Command mode self-refresh

This lack of evolution has led to severe fragmentation between upstream and vendor downstream trees for advanced devices support, creating a heavy maintenance burden and making native hardware support incredibly difficult.

The goal would be to outline these architectural limitations and trigger a discussion on how to collaboratively modernize the panel API. By standardizing advanced DDIC capabilities and fully embracing the atomic DRM API, we hope to establish a unified path forward for the entire Linux community.

Speaker: Neil Armstrong (Linaro)

LPC Refereed Track

72 RCU Transactions: Bridging the gap between RCU and STM

RCU data structures are notoriously complex to design mainly due to the
need to carefully manage how mutations are made observable to concurrent
readers.

As a general solution to this problem, I am proposing a novel
transaction-based synchronisation mechanism: "RCU Transactions"
(urcu_txn).

It applies both to userspace and kernel. It allows publishing complex
data structure mutations atomically to RCU readers, and synchronizing
updates from multiple writers, with minimal overhead on the read-side
(low-bit pointer tag check, predicted branch on rcu_dereference), and no
size overhead on the data structure nodes. It is composable: an object
can belong to multiple transaction-aware data structures, and
transactions allow it to become visible (or hidden) atomically.

Speaker: Mathieu Desnoyers (EfficiOS Inc.)

73 Checkpoint/Restore for RDMA: Saving and Restoring Live Queue Pairs with CRIU

RDMA delivers high-throughput, low-latency networking by bypassing the kernel and letting applications communicate directly with the hardware. CRIU, by contrast, works by freezing running processes and serializing their state so they can be restored later. Bringing the two together is difficult precisely because of what makes RDMA fast: RDMA bypasses the kernel abstractions CRIU would normally use to checkpoint. CRIU already migrates live TCP connections but relies on filesystem attributes and a hook in the socket interface. RDMA is conceptually similar but the interfaces required to save/restore look very different. Our work aims to close this gap with an approach we demonstrate on NVIDIA ConnectX and BlueField devices using existing SRIOV VF migration support, as well as on RXE/Soft-RoCE. In both cases the RDMA connection survives checkpoint/restore intact: when peers are checkpointed together, the connection is never torn down and neither side sees QP errors or forced reconnects.

This matters most for machine learning, where RDMA carries communication for large distributed training and inference jobs that are expensive to start and stop. The ability to checkpoint and restore these jobs enables defragmenting a cluster to improve utilization, recovering seamlessly from hardware failures, time-sharing expensive resources between seasonal workloads (for example, inference by day and training by night), and migrating jobs to cheaper resources as availability changes. It also standardizes the save/restore workflow across frameworks, simplifying resource management for infra owners. Crucially, these jobs typically run on bare metal, so virtual machine live migration—the main existing alternative—will not be adopted by many would-be users.

To get there, the talk will first propose the concrete kernel interfaces required to support checkpoint/restore for RDMA, and explain how our implementation in CRIU uses them to checkpoint and restore a connection. Then we will then turn to mlx5, which has supported live migrating RDMA connections inside of QEMU VMs for some time. By reusing the same device capabilities and firmware APIs that already power SRIOV VM live migration, we show how realistic machine learning workloads can be checkpointed and restored on Linux using networking hardware available today.

Speaker: Raphael Norwitz (nvidia)

11:30 Coffee Break

74 Improving kernel test coverage using stress-ng

The Linux kernel is constantly growing and evolving; unfortunately, corner-case regressions can creep into code in every release. Gcov test coverage can find infrequently used code paths that may contain issues. This presentation discusses how such techniques are used to improve kernel testing with stress-ng and the challenges in reaching full test coverage.

Speaker: Colin King (stress-ng)

75 Rust SPDM in the Kernel

Security Protocols and Data Models (SPDM) is used for authentication, attestation and key exchange. SPDM is generally used over a range of transports, such as PCIe, MCTP/SMBus/I3C, ATA, SCSI, NVMe or TCP.

From the kernels perspective SPDM is used to authenticate and attest devices. In this threat model a device is considered untrusted until it can be verified by the kernel and userspace using SPDM. As such SPDM data is untrusted data that is possibly from a mallicious device. The SPDM specification is also complex, with the 1.2.1 spec being almost 200 pages and the 1.3.0 spec being almost 250 pages long.

As such we have the kernel parsing untrusted responses from a complex specification, which sounds like a possible exploit vector. This is the type of place where Rust excels!

Over the last few years there has been gradual momentum building for SPDM support in the kernel and an implementation written in Rust. This implementation is in charge of authenticating and attesting untrusted and potentially malicious devices in the kernel using Rust code. The kernel also needs to allow userspace to apply security policies and allow remote verifiers to verify the running system, even with a possible malicious kernel.

This talk is going to cover the current status of the SPDM Rust implementation, how and why we got here and then discuss next steps for getting it merged into mainline.

It's not even over once SPDM is supported in the kernel though, as there are a range of more complex features that need to be supported. We can also talk about future features and what they might look like, ensuring we don't step on any PCI TSM feet.

Speaker: Alistair Francis

13:30 Lunch Break

76 Virtio-GPU for Automotive: Implementing Libkrun + Vhost-User.

Automotive hardware architectures are consolidating standalone Electronic Control Units (ECUs) into centralized compute platforms. A major challenge in this architecture is safely and efficiently sharing a single GPU across multiple isolated virtual machines. For example, systems must run critical instrument clusters, infotainment setups, and ADAS pipelines simultaneously without risking cross-domain interference.

This presentation tackles this challenge by introducing an architecture that combines libkrun, a process-based KVM virtualization library, with the vhost-user protocol to split device emulation into separate processes. By executing the virtio-gpu backend independently via virglrenderer, this approach achieves fault isolation, zero-copy transfers, and a reduced attack surface compared with traditional Type-1 hypervisors. We have implemented headless GPU compute acceleration, verified using AMD Radeon graphics via virgl, allowing offscreen rendering and ADAS sensor preprocessing. We have also implemented software scanout display output using the gfxstream backend, with DMABUF zero-copy scanout for virglrenderer in progress.

However, productizing this architecture has revealed concrete specification gaps, where the virtio-gpu specification and Linux kernel implementation diverge. During our ongoing implementation of display output paths, such as UPDATE and cursor paths, we encountered some blockers where the written specification and the kernel driver handle headless state and display configurations differently.

This talk focuses on two concrete topics from our implementation experience:

1. Spec vs. Kernel Reality on Headless Operation: The Virtio-GPU Spec (v1.4 §5.7.4) requires a minimum of 1 scanout, yet the Linux kernel (virtgpu_kms.c) gracefully accepts and handles 0. We will discuss how to reconcile the specification to natively support headless, compute-only automotive workloads without forcing VMMs to waste resources on dummy display allocations.
2. Display Output & Device Infrastructure in libkrun: We will present the two GPU display scanout paths we are implementing: Software scanout via gfxstream (pixel copy in message payload) and DMABUF zero-copy scanout via virglrenderer and also covering their tradeoffs in latency, memory usage, and backend compatibility. We will discuss how implementing GPU display support required adding generic SHMEM region mapping and BACKEND_REQ protocol features to libkrun's vhost-user framework, and how this infrastructure then enabled support for other vhost-user devices like virtio-media (camera/decoder passthrough) with minimal additional effort.

Eventually, we want to engage kernel maintainers, virtio specification editors, and VMM developers to discuss how the specification and its implementation can be improved to build a way forward for automotive virtualized graphics.

Session Timeline & Core Discussion Points (45 Minutes)

• Architecture & Status (10 mins): High-level overview of the libkrun + vhost-user-gpu stack, where it stands relative to Type-1 hypervisors, and a status update on PR #717 (working headless compute vs. pending display paths).
• Spec vs. Kernel: num_scanouts Divergence (20 mins): Open discussion on the conflict where the kernel accepts num_scanouts == 0 while the spec forbids it. Questions: Should the spec be amended to support headless operation? Should the kernel enforce spec compliance? When spec and implementation conflict, which is authoritative? What are the implications for VMM developers and automotive use cases?
• Display Output & Device Infrastructure in libkrun (10 mins): The two GPU scanout paths: Software scanout (gfxstream, full-frame pixel copy) vs DMABUF zero-copy (virglrenderer, FD passing via SCM_RIGHTS), their tradeoffs and current status. How implementing GPU display required adding generic SHMEM region and BACKEND_REQ protocol support to libkrun, which then enabled vhost-user support for virtio-media with minimal additional work.
• Q&A and Upstream Planning (5 mins)

Speaker: Dorinda Bassey (Red Hat)

77 The State of the Kconfig Ecosystem

Part 1: Tooling
Researchers continue to be fascinated by the Linux kernel’s usage of Kconfig, and academic papers have been regularly published on it for almost 20 years now. And with these papers often comes tools. Some examples include detecting dead configuration options, unmet dependency bugs, and generating config files that compile affected lines of C code from patches, among many others. We take a look at which tools are still being maintained post-publication, and discuss interesting tools that have since been abandoned. Can they be picked up by the open source community? And what kind of tooling is still missing?

Part 2: The Many Implementations of Kconfig
Kconfig, a language originally introduced for use in the Linux build system, has grown to over 200,000 lines of usage in Linux itself, and has been adopted by many other open source projects, like coreboot, BusyBox, Zephyr, and more. However, Kconfig does not have a specification like other languages, and is implemented differently in each of these projects that uses it. We take a look at how these implementations differ, and discuss the feasibility of a unified spec and implementation.

Speaker: Julian Braha

16:30 Coffee Break

78 Devicetree-ACPI hybrid mode

Currently when booting in Devicetree mode the kernel will fully disable the ACPI subsystem. On WoA Snapdragon laptops where the factory Windows OS actually boots using the ACPI tables this is not necessarily desirable.

The purpose of this session is to present and discuss a proposal for a new DT-ACPI hybrid mode, in which while booting with Devicetree:

1. The ACPI tables are still parsed and ACPI fwnodes are made available for device-drivers to use for (extra) information.

2. Some devices may even be fully enumerated through ACPI e.g. enumerate I2C clients through ACPI for an I2C controller which itself is described in DT.

3. Going futher: use ACPI GPIO-IRQ event handlers + I2C opregion support to let ACPI handle a laptops embedded controller connected over I2C and using the ACPI battery device (backed by the EC) to expose battery state information in a laptop-model agnostic way like how laptop batteries are handled on x86 laptops.

Note on current laptops Linux cannot boot using ACPI due to some information missing from the ACPI tables. People are working on changing this so that for future WoA Snapdragon laptops Linux can boot using ACPI only without requiring Devicetree.

An early RFC patch-series implementing 1. + 2. has been posted upstream.

Speaker: Hans de Goede (Qualcomm)

Tracing MC

Description:
Visibility into the Linux kernel has always been critical for debugging and validating the execution of the code. The never ending challenge is to be able to trace the code without causing extra overhead, as tracing is most useful in a production environment.

Possible topics for this year include:

• Updating the deferred stack tracer for sframes.
• A light weight lock stat tracer
• More read1ng of user space from syscall tracepoints
• Additions to the persistent ring buffer
• Adding error injection via trace points and kprobes
• Doing more with synthetic events
• Rewriting the histogram/trigger/synthetic event code

And much more

What has been done before
Here's the enhancements that were added to Linux tracing that were derived from the previous Tracing MC session:

• libside has been released for better user space tracepoint hooking
• Faultable system call tracepoints
• We have a new Runtime Verification maintainer!

Key Attendees:

• Steven Rostedt
• Masami Hiramatsu
• Mathieu Desnoyers
• Ian Rogers
• Gabriele Monaco
• Namhyung Kim
• Arnaldo Carvalho de Melo
• Tomas Glozar
• Peter Zijlstra
• Jens Remus

11:30 Coffee Break

79 Sharing trace infrastructure between in-tree and OOT tracers

The current situation regarding LTTng vs upstream Linux:

1) There are maintainers who push for everything to be in tree
2) There are maintainers who are proponents for no-GPL-export when there are no in-tree users
3) Most of the tracer common facilities are used by tracers which do not compile as modules (only builtin)
4) Linus Torvalds stated that LTTng will stay out of tree

As a consequence, LTTng has no way to use common tracer facilities
without kernel patches.

This context is not favorable for collaboration of LTTng developers with upstream. It is hard to justify spending time on kernel infrastructure collaboration when the resulting APIs cannot be used by out-of-tree tracers.

I am open to suggestions to improve this situation.

Speaker: Mathieu Desnoyers (EfficiOS Inc.)

eBPF Track

The eBPF Track is going to bring together developers, maintainers, and other contributors from all around the globe to discuss improvements to the Linux kernel’s eBPF subsystem and its surrounding user space ecosystem such as libraries, loaders, compiler backends, related system tooling as well as eBPF use cases.

The gathering is designed to foster collaboration and face to face discussion of ongoing development topics as well as to encourage bringing new ideas into the development community for the advancement of the eBPF subsystem.

The track will be composed of talks, 30 minutes in length (including Q&A discussion).

eBPF Track's technical committee: Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko

80 eBPF Research: What's Going On In Academia?

The body of academic work on eBPF is growing so large and scattered that it’s hard to see the forest for the trees. Papers span all kinds of topics and conferences, vary wildly in quality, and are often dense and hard to parse.

This talk will present the dominant trends of research. To that end, we will first explain academia's heuristics to identify "high-quality papers"—it is not the number of citations!—and what it means for a paper to be considered high-quality. We’ll then show that a handful of teams are behind most of these standout eBPF papers.

Finally, we will see that only specific research topics are leading to contributions upstream and explain why that might be. We will discuss how the kernel community could encourage research on specific problems, should it choose to do so.

Speaker: Paul Chaignon (Isovalent)

81 bpf_fault: Custom Page Fault Handling with eBPF

Page faults, which occur when a program accesses a virtual memory page that is not mapped to physical memory, are traditionally handled by the operating system. However, many applications benefit from running custom page fault handling logic. For example, some applications may seek to prefill newly-faulted pages with content, or intercept writes in order to make a copy of the original contents. Linux’s userfaultfd interface enables some of these use cases by offloading fault handling to userspace. Unfortunately, it suffers from significant limitations, namely high overhead, poor scalability, and a design that precludes its use in libraries.

We present bpf_fault, an experimental framework that allows applications to run page fault handlers directly within the Linux kernel using eBPF. By eliminating the overheads and complexity associated with userfaultfd, bpf_fault reduces fault latency by 2.8-6.1x and eliminates userfaultfd’s scalability bottleneck. We integrate bpf_fault with several applications, including VM live snapshots in Firecracker and QEMU (eliminating tail latency spikes caused by snapshots), JVM garbage collection, and more. We also design a novel lazy dynamic linking mechanism for Linux that defers relocations to fault time using bpf_fault, a use case impossible with userfaultfd, which reduces dirty memory usage of widely-used applications like Chrome and Clang by up to 50%. Together, these results demonstrate that eBPF-based fault handling can improve performance and reduce resource usage in widely-deployed applications.

Speaker: Tal Zussman (Columbia University)

82 Programming Across the VM Boundary with eBPF: Lessons from Revisiting Phantom Tracker

eBPF programs can exchange data efficiently with other programs and userspace through maps, ring buffers, and kfuncs, but these mechanisms stop at the boundary of a kernel instance. The Linux kernel has no generic, safe, low-latency mechanism for eBPF programs in a guest and host to communicate through shared memory across the VM boundary. Roy’s Google Summer of Code (GSoC) project [1] reimplements Himadri’s in-kernel thesis [2] prototype of Phantom Tracker using eBPF and, in turn, highlights the need for paravirtualized shared-memory drivers that expose reliable communication APIs to eBPF programs across the VM boundary.

The thesis models vCPU lifecycle states using the distinction between phantom and viable vCPUs. A phantom vCPU satisfies two conditions: (1) it is runnable but waiting in the run queue of a pCPU on the host, and (2) a worker thread of the guest parallel application that had been running on that vCPU is now stalled because the vCPU is not executing. Conversely, any vCPU that does not satisfy both conditions is considered viable. Across the VM boundary, Phantom Tracker correlates guest-side information about which vCPUs are running worker threads of the parallel application with host-side scheduler wake-up and context-switch events involving those vCPUs. The GSoC project uses a configurable eBPF timer that aggregates these observations and computes a per-VM metric called the phantom average. Guest userspace parallel runtime libraries, such as libgomp, can use this metric to adapt the application’s degree of parallelism at runtime and minimize the number of phantom vCPUs.

Communication between the host and guest is implemented using QEMU’s Inter-VM Shared Memory (IVSHMEM) device [3]. While the thesis prototype relied on custom IVSHMEM drivers tied to custom kernels, the eBPF implementation resulted in the development of new eBPF-compatible drivers [4]. By presenting the lessons learned while working on this GSoC project, this talk discusses the broader applicability of our eBPF-compatible IVSHMEM drivers within the QEMU/KVM virtualization stack and invites discussion on the scope for upstreaming them.

[1] https://summerofcode.withgoogle.com/programs/2026/projects/iXbp42du
[2] https://inria.hal.science/tel-05438117v3
[3] https://www.qemu.org/docs/master/system/devices/ivshmem.html
[4] https://github.com/himadrics/phantom-tracker/tree/main/pvsched-shmem

Speaker: Roy Nchang (National Advanced School of Engineering (ENSPY), Yaoundé)

11:30 Coffee Break

83 shirudo: BPF live-patching infra for the agentic era

In times of Fable/Mythos or equivalent LLMs, security fixes and attack-surface hardening increasingly needs to land on production systems now, but data-center fleets, Kubernetes nodes, or embedded/air-gapped devices all typically share long patch-and-reboot cycles.

BPF is the natural vehicle for on-the-fly live mitigations and runtime visibility - to the kernel itself as well as to userspace apps - and in the age of AI-assisted engineering the natural author of those patches is an agent working in a close loop with the operator. We'll present shirudo, which is an agentless BPF-based security platform tailored for exactly this: There is deliberately no config DSL, because agents work far better with code directly. shirudo also fully embraces xattrs, signed BPF and seals all its assets via BPF LSM in order to defend against untrusted root tampering with bpf. In this talk we walk through the operator/target node workflow, architecture internals, demo its capabilities, and discuss gaps and next steps on shirudo, BPF kernel and libbpf loader side.

Speakers: Daniel Borkmann (Isovalent), John Fastabend (Isovalent)

84 One Layer of the Onion: A Daemonless eBPF LSM for Confidential VMs in a WhatsApp TEE

Host-side hardening for a confidential VM is not one control, it's an onion. AMD SEV protects guest memory, MetalOS and a measured/verified boot chain establish the platform, signing and provisioning gate what lands on disk, and process isolation constrains the runtime. This talk is about one specific layer of that onion, the eBPF LSM that enforces binary identity and process protection at runtime. WhatsApp runs user workloads inside AMD SEV-backed TEEs where the guest is a QEMU process; eBPF LSM is how we add a defense-in-depth layer for that host without becoming a new single point of trust.
The core of the talk is the BPF and the goal is to give attendees a full picture of how we use BPF at Meta to supplement confidential workloads in WhatsApp. Specifically, we attach a set of LSM programs bprm_creds_from_file for exec-time identity, ptrace_access_check/ptrace_traceme for anti-trace, and task_kill for anti-signal and drive them entirely from BPF maps keyed by role. The design choice we want to dig into is persistence through pinning that has been discussed in other talks from Tetragon discussed in this lwn article and fully explore how we pin, configure our maps, set up keychains used for binary identification and how we track processes. We will also talk about the need for options for logging as is done in the initial article, but it will be a small portion to ask for opinions and discuss some other options that we are exploring, as opposed to standing exclusively behind UDP packet sending that has been discussed previously. We will mention potential malware opportunities from this approach. Our method will be contrasted with pros and cons of a typical resident daemon. In the use case at Meta, a run-to-completion init binary loads the programs, pins every program, link, and map into bpffs, and exits. Because the LSM links survive pivot root, enforcement is live before the confidential workload starts. We'll walk through the map layout, how policy is expressed per-role, and how pinned state lets the enforcement layer survive independently of any userspace processes. We will also discuss some of the strategies we use to disallow malicious userspace processes from removing these programs once they are in place and how we manage the potential fallout from this.
On identity, we'll show the in-kernel verification path in detail. At exec, the bprm_creds_from_file hook reads an extended attribute on the binary user.bpfj.policy.exec naming its role, which forces calls to bpf_get_fsverity_digest and bpf_verify_pkcs7_signature to check the binary's fs-verity digest and detached PKCS7 signature against a kernel keyring seeded from that role's certificates enrolling the process into a role only if its on-disk contents are signed for that role. Here the BPF layer leans on fs-verity, the keyring subsystem, and our custom signing pipeline do the heavy cryptographic lifting. Our programs make the runtime authorization decision from that verified identity. We'll cover the kfuncs we depend on, the sleepable-LSM constraints, and the pitfalls we eliminated by moving to signature-gated, exec-time enrollment.
Finally, we show what verified identity buys at runtime with QEMU pinned to a verified role, the ptrace and task_kill hooks enforce per-role allow-lists so nothing on the host can attach a debugger to, or signal, the confidential VM closing common paths for extracting or faulting guest state. We'll be explicit about the layer's limits what it does not defend against and which sibling controls cover those gaps — so the audience sees where a focused eBPF LSM fits in a real confidential-computing threat model.

Speakers: Mr Joshua Lilly (Meta), Liam Wisehart

85 Scaling BPF LSM hooks and error injection across the kernel

In the modern era, Linux kernel CVEs might accumulate faster than fleets can reboot into patched kernels. In some cases, this takes not even days. BPF-based mitigations can block vulnerable code paths at runtime, no reboot needed.

However, at the moment, BPF is far from being a golden bullet. Two mechanisms on how BPF can alter an execution path, LSM Hooks and error injection, are naturally limited: by the set of existing LSM hooks and by the [short] whitelist of ALLOW_ERROR_INJECTION functions. Many subsystems, such as different parts of net/, device drivers, etc., have no BPF security coverage.

In the first part of the talk, we investigate how subsystems currently lacking BPF hook coverage can be equipped with it and present tooling and guidelines to support adding that coverage more systematically.

In the second part, we discuss the error injection topic. One recent radical attempt, killswitch, allows any function to be altered. While this ultimately solves the problem, this is not really a solution which can be kept under control. Thus we discuss what might be done to substantially extend the set of functions eligible for error injection, while keeping the mechanism firmly under control.

Speaker: Anton Protopopov (Isovalent at Cisco)

13:30 Lunch Break

86 Parsing L7 Protocols in eBPF

Recent advances in the Linux kernel have enabled increasingly complex kernel offloads with eBPF. Despite this, parsing application-layer protocols, e.g. HTTP, remains a challenge. The reason for this is the self-describing structure of such protocols, which typically requires more state and more complex control flow than a transport-layer protocol. This is unfortunate because supporting L7 protocols in eBPF opens up new opportunities to optimize many applications that were previously deemed too complex, e.g. web servers, web application firewalls, or L7 service proxies.

This talk introduces HTTBPF, a novel architecture to parse HTTP directly in eBPF, without the need for kernel modules. To circumvent eBPF’s stringent limitations, it constructs Aho-Corasick-like DFAs in user space, and leverages them in kernel space to identify and extract relevant headers from the message buffer. We fully implement HTTBPF, with support for HTTP/1.1 and HTTP/2, and show its advantage by serving HTTP requests directly from eBPF.

Speaker: Laurin Brandner (ETH Zürich)

87 Inline DDoS protection for cloud-native game servers at PlayStation with eBPF/XDP

At PlayStation, we see DDoS attacks of multiple terabits per second targeting game servers. Traditional DDoS mitigation systems can be costly, slow to react, and difficult to place close enough to the ingress points of the network.

This talk presents a token-based eBPF/XDP architecture for inline DDoS protection. We show how distributing short lived tokens to legitimate clients allows us to make the most of XDP’s position early in the stack for whitelisting and minimise wasted cycles on unwanted traffic. We also complement the overall architecture with an eBPF based agent on the K8s workers that i) removes the need to expose backend clusters directly to the Internet ii) forms a transparent overlay between the public-facing DDoS protection layer and private game-server clouds and iii) solves challenges in integrating with Kubernetes CNIs and cloud environments. In order to tackle the unique requirements of frequently changing routing state that needs to be globally distributed, we also propose a control plane architecture built on CNCF xDS that allows us to propagate tokens at high rates close to our network ingress points, constantly updating the eBPF maps that drive our routing decisions.

Finally, we share lessons from building and operating an eBPF based DDoS protection architecture at global scale. We discuss the challenges of integration with cloud providers and their CNIs, as well as return path optimisations that make the most of Playstation’s backbone network.

Speakers: Babis Stylianopoulos (Sony Interactive Entertainment), Jeffrey Barendse (Sony Interactive Entertainment)

88 BPF ksock: bringing network sockets to BPF

BPF-based agents aim to be as transparent as possible while minimizing CPU and memory overhead. Real-world experience from projects such as Cilium’s Tetragon has shown that moving more functionality directly into the kernel is an effective strategy. However, one remaining limitation for observability and logging is the lack of an API for sending data over the network directly from BPF programs, keeping user space in the critical path.

Efforts to provide BPF programs with networking capabilities through new kfuncs have been discussed at the past two LSF/MM/BPF summits in Montreal and Zagreb. An initial approach based on the netpoll infrastructure was proposed but ultimately rejected.

This talk will recap the motivation behind the current patch sets, summarize the discussions so far, and introduce the current design. We will then demonstrate several ways BPF programs can use the new API, ranging from basic examples to practical and more unexpected use cases. Finally, we will discuss possible future extensions to the API, such as support for additional BPF program types and TCP sockets.

Speakers: Kornilios Kourtis (Isovalent), Mahé Tardy (Isovalent)

16:30 Coffee Break

89 BPF-RBACd: Delegating BPF permissions with high granularity

BPF usage has traditionally required system-wide capabilities, and giving an application access to using BPF is an all-or-nothing proposition. With BPF tokens, we gained the ability to delegate BPF capabilities to user namespaces with more granularity, and with an LSM we can increase granularity further.

Both BPF token usage, and an LSM, require a userspace implementation of the policy enforcement mechanism. bpf-rbacd (the "BPF Role-Based Access Control daemon") is such an implementation, which runs as a system service and supports granting permissions to applications or containers on the system using either BPF token delegation or syscall proxying. A policy language restricts which subset of BPF an application is allowed to use, with high granularity, enforced through an LSM written in BPF.

We are working on making bpf-rbacd a core part of the Fedora and RHEL distributions. In this talk we'll present the architecture of bpf-rbacd and solicit feedback from the community on the design of the system, in the hope that this can prove useful to other distributions and operators as well.

Speaker: Toke Høiland-Jørgensen (Red Hat)

90 eBPF on Wheels - Automotive and Industrial Use Cases

The industry increasingly adopts Linux for automotive and industrial use cases, since companies like Red Hat or Canonical engaged in development of Linux platforms in safety-critical domains. Using container technologies or just a bootable images on restricted silicon, now software operates cyber-physical processes. Those platforms are often cloud-connected because of maintainability, attracting new threat actors to that domain. Defenses in this area are limited, because of blind spots in endpoint protection solutions regarding electronics.

The missing integrations can be found in non-IP bus systems, such as the CAN bus as well as on-board interfaces to flash chips, FPGA or the protocols themselves like SPI or I2C. While less common in the IT world those missing capabilities are missing out in comprehensive observability resulting in unnoticed cyber attacks against IOT platforms.

This talk showcases the use of eBPF for protocols like CAN, DMA and SPI to create observability as well as defenses against cyber attacks in automotive or industrial contexts, such as secure updates, injection attacks and non-IP filters.

Speaker: Mr Reinhard Kugler (SBA Research)

91 Pluggable Runtime Verification (RV) monitors with BPF

RV is a lightweight method for verifying system behavior at runtime using, for instance, deterministic automata. Currently, RV monitors must be implemented in-kernel, meaning any new monitor requires going through the upstream kernel development process.
We can replicate the existing monitor infrastructure in BPF mapping kernel primitives to BPF equivalents such as maps and ring buffers, while reusing common logic where possible.
This allows to develop, test, and deploy domain-specific monitors entirely from userspace, with all the perks of the BPF tracing infrastructure.

In the talk we will cover an implementation using BPF struct_ops for mostly seamless integration with the in-kernel RV framework and tools, BPF monitor lifecycle control via the rv command line tool (i.e. registration, activation, and tracing), and various tradeoffs to keep a similar experience between different monitor implementations.

Speaker: Gabriele Monaco (Red Hat Inc.)

Kernel Testing & Dependability MC

The Kernel Testing & Dependability Micro-Conference (a.k.a. Testing MC) focuses on advancing the current state of testing of the Linux kernel and its related infrastructure.

Building upon the momentum from previous years, the Testing MC's main purpose is to promote collaboration between all communities and individuals involved with kernel testing and dependability. We aim to create connections between people working on related projects across the wider ecosystem and foster their development. This should serve applications and products that require predictability and trust in the kernel.

We ask that all discussions focus on identified issues, aiming to find potential solutions, alternatives, and concrete next steps. The Testing MC is open to all topics related to testing and dependability on Linux, not necessarily limited to the kernel itself.

In particular, topics of interest for Linux Plumbers Conference 2026 include:

• KernelCI and related infrastructure: Maestro, kci-dev, dashboard and API improvements, KCIDB-ng, pull-mode lab support, and integration with Tuxmake, TuxRun, and related tooling
• Expanding production use of testing infrastructure and improving how developers consume, triage, and act on test results
• Improving interoperability between KUnit and kselftest, including UAPI testing, running kernelspace tests from userspace, and unified reporting workflows
• Continued evolution of KUnit itself, including better support for parameterized tests, improved tooling, and broader adoption throughout the kernel
• Improving kselftest and related frameworks, including output consistency, KTAP compliance, parser and tooling improvements, and better handling of skips, nesting, and other real-world test results
• Building, running, and testing in-kernel Rust code, including Rust doctests and other Rust-oriented test workflows
• Improving sanitizers and dynamic analysis tools, including KFENCE, KCSAN, KASAN, UBSAN, and related debugging infrastructure
• Using Clang and compiler-assisted features to improve test coverage, diagnostics, and reproducibility
• Consolidating toolchains, build environments, and reference setups to improve reproducibility, consistency, and quality control
• Targeted fuzzing of internal kernel functions and other techniques to extend coverage beyond traditional syscall fuzzing
• Patch-series fuzzing, regression detection during review, and other ways to shift testing and fuzzing earlier into the development cycle
• Kernel benchmarking, performance evaluation, and shared infrastructure for tracking and bisecting performance regressions
• Determining which test coverage infrastructures are most effective for kernel quality assurance, and how coverage should be measured
• Improving traceability between requirements, code, tests, results, and hardware or lab metadata
• Regression testing for safety and dependability, including prioritization of critical configurations, platforms, and test suites
• Identifying missing features needed to support assurance in safety-critical systems
• Moving toward more test-driven kernel release practices for both mainline and stable trees
• Exploring how SBOMs and related metadata contribute to kernel dependability and assurance
• Better ways to share, normalize, store, and analyze test results across projects, labs, and communities
• AI-assisted testing and review workflows, including patch triage, regression-risk estimation, test selection, test generation, bug localization, and evidence-based validation of LLM-assisted results

Things accomplished since LPC 2025:

• KernelCI reached the last KCIDB-ng milestone, moving KCIDB submission ingestion closer to the Django backend and decoupling the KCIDB schema from the dashboard database
• KernelCI improved project health with API and system-resource monitoring, and increased backend test coverage from about 40% to nearly 70%, including benchmark tests
• Progress was made on pull-mode lab support in Maestro, enabling labs behind firewalls or with different internal setups to participate more easily in KernelCI
• Tuxmake, TuxRun, and TuxSuite/LAVA-related tooling continued to be integrated more closely with KernelCI, with tuxmake, tuxrun, and tuxlava moved under the KernelCI GitHub namespace
• kci-dev continued to mature as a developer-facing CLI, with v0.1.9 and v0.1.10 adding packaging improvements, better regression comparison and issue triage workflows, improved validation and reporting ergonomics, and general workflow fixes
• Continued work on KUnit and kselftest integration was discussed on the linux-kselftest mailing list, including the KUnit UAPI testing framework series for running UAPI-oriented tests under KUnit
• KUnit tooling and parser follow-up also continued on the linux-kselftest mailing list, including fixes for nested test result handling and better parsing of skipped tests from kselftest output
• KTAP standardization work continued, with ongoing discussion around aligning kselftest and KUnit output formats and the KTAP v1 format now documented in the official kernel documentation

16:30 Coffee Break

Live Update MC

Proposal

Live Update is a specialized reboot process where selected devices are kept operational and kernel state is preserved and recreated across a kexec. For devices, DMA and interrupts may continue during the reboot.

The primary use-case of Live Update is to enable hypervisor updates in cloud environments with minimal disruption to running virtual machines. During a Live Update, a VM can pause and its state is stored to memory while the hypervisor reboots. PCIe devices attached to those VMs (such as GPUs, NICs, and SSDs), are kept running during the Live Update. After the reboot, VMs are recreated and restored from memory, reattached to devices, and resumed. The disruption is limited to the time it takes to complete this entire process.

With Live Update infrastructure in place, other use-cases may emerge, like for example preserving the state of GPU doing LLM, freezing running containers with CRIU, and preserving large in-memory databases.

The Live Update and state persistence functionality touch on different parts of the kernel and this microconference aims to bring together people from different subsystems. Upstream support for Live Updates is still in its infancy and there are a lot of unsolved aspects that will benefit from direct communication.

Key problems that will be discussed:

Support for memfd/guest_memfd/hugetlb/tmpfs Preserving the state of VFIO, IOMMUFD, and IOMMU drivers. Preserving vCPUs and Orphaned Virtual Machines LUO systemd integration Integration of Live Update with PCI and Device Model Leveraging suspend/resume functionality for device state preservation Optimizing kernel shutdown and boot times.

Last year achievements:

Following “Memory persistence over kexec” BoF at LPC 2024 we we landed support for Kernel KHO, LUO, and memfd preservation.

Expanding the BoF to a full blown MC helped defining key data structures required for Live Update stability and isolating them into a dedicated kho/abi/ directory under include/linux.

Duing 2025 edition of Live Update MC we finalized the objectives and design for making KHO stateless and it’s now transitioned to a radix tree for memory preservation.

Key attendees:

• Alex Graf
• Alex Williamson
• Ben Herrenschmidt
• Bjorn Helgaas
• David Matlack
• David Rientjes
• David Woodhouse
• Evangelos Petrongonas
• Jason Gunthorpe
• Josh Hilke
• Luca Boccassi
• Michał Cłapiński
• Mike Rapoport
• Pasha Tatashin
• Pratyush Yadav
• Samiullah Khawaja
• Vipin Sharma

16:30 Coffee Break

Power Management and Thermal Control MC

The Power Management and Thermal Control micro-conference is about all things related to saving energy and managing heat. Among other things, we care about CPU, platform and device power-management mechanisms, thermal control support, and power capping. In particular, we are interested in improving and extending thermal control support in the Linux kernel and utilizing energy-saving features of modern hardware.

The general goal is to facilitate cross-framework and cross-platform discussions in order to improve energy-awareness and thermal control in Linux.

Since the previous iteration of this micro-conference, several topics covered by it have been addressed or work is in progress to address them, including:

• Thermal zones suspend and resume relocation closer to device suspend and resume, respectively: https://lore.kernel.org/linux-pm/12871778.O9o76ZdvQC@rafael.j.wysocki/
• Step-wise thermal governor improvements: https://lore.kernel.org/linux-pm/12745610.O9o76ZdvQC@rafael.j.wysocki/
• Support for latency limits in system-wide power management idle states: https://lore.kernel.org/linux-pm/20260205-topic-lpm-pmdomain-device-constraints-v2-0-61f7be7d35ac@baylibre.com/
• Support for fine-grained sync_state in generic PM domains: https://lore.kernel.org/linux-pm/20260410104058.83748-1-ulf.hansson@linaro.org/
• Support for remote processor cooling: https://lore.kernel.org/linux-pm/20260127155722.2797783-1-gaurav.kohli@oss.qualcomm.com/ and https://lore.kernel.org/linux-pm/20260419182203.4083985-1-daniel.lezcano@oss.qualcomm.com/

The topics that we would like to cover this year include, but are not limited to:

• Support for sync_state in more subsystems beyond generic PM domains
• Remaining rough edges in kernel thermal control support
• Cooling devices and thermal zones with parents
• thermald improvements, enhancements and development process
• Latency-focused QoS for kernel devices - implementation and experiments
• A lacking policy for power/perf-management of NVMe/UFS/eMMC/SD storage

The key people we would like to participate in the session are Rafael Wysocki, Ulf Hansson, Daniel Lezcano, Lukasz Luba, Srinivas Pandruvada, and Viresh Kumar.

92 Thermal Framework Corner Cases: Bugs or Undefined Behavior?

The Linux thermal framework has proven to be flexible and robust over the years. However, some aspects of its event handling have become increasingly difficult to reason about, resulting in inconsistent behaviors and corner cases.

Examples include trip point updates while the temperature has already fallen within the hysteresis range after the notification was generated, inconsistent handling of thermal zones across system suspend and resume, and other situations where the expected behavior is not clearly defined or documented.

Some of these issues have been reported over the years, while others have surfaced as new users and platforms have adopted the framework. Addressing them individually without a common understanding of the expected semantics risks introducing further inconsistencies.

The goal of this discussion is to identify the current limitations of the thermal framework, establish which behaviors are considered bugs versus intentional design choices, prioritize the issues that should be addressed, and agree on a roadmap for improving the framework while preserving compatibility with existing users.

Speaker: Dr Daniel Lezcano (Qualcomm)

93 Power Cooling Devices: Bridging Thermal and Powercap

The Linux thermal management and power capping frameworks currently evolve independently, despite relying on the same Energy Model (EM) to describe the power-performance characteristics of devices.

The thermal framework regulates temperature by estimating a sustainable power budget using the power_allocator governor. A PID control loop computes the power reduction required to maintain a target temperature, and the Energy Model translates this budget into Operating Performance Point (OPP) constraints applied through thermal cooling devices.

The powercap framework, and in particular the Dynamic Thermal Power Management (DTPM) controller, also relies on the Energy Model to enforce power budgets. However, instead of manipulating OPPs directly, it distributes power limits across a hierarchy of power domains.

Although both frameworks address closely related problems and use the same underlying model, there is currently no mechanism to connect them. This raises the question of whether a common abstraction could allow the thermal framework to express power constraints through the powercap hierarchy rather than through device-specific OPP constraints.

One possible direction is the introduction of a power cooling device, acting as a bridge between the thermal and powercap frameworks. Such an abstraction could enable thermal governors to allocate power budgets to powercap domains while leaving power distribution and enforcement to the powercap subsystem. This approach may also open the door to hierarchical power budgeting and more coordinated thermal management across heterogeneous devices.

The goal of this discussion is to explore whether this direction makes sense from an architectural perspective, identify the challenges involved, and agree on a set of incremental milestones that would allow such an integration to be developed and upstreamed progressively.

Speaker: Dr Daniel Lezcano (Qualcomm)

94 Introducing Hardware Thermal Governor

Modern System-on-Chip designs increasingly incorporate built-in hardware thermal controllers to manage thermal conditions efficiently. Intel platforms, beginning with the Lunar Lake generation, feature integrated platform temperature controllers capable of autonomous thermal management. However, not all platform designs directly interface temperature readings and thermal thresholds with these hardware governors, limiting their effectiveness.

This presentation introduces a kernel-level approach that leverages existing thermal zone infrastructure to provide temperature data and threshold information directly through a new hardware thermal governor, bypassing user space interactions.

A proof-of-concept implementation will be demonstrated, showcasing the integration of thermal zones with hardware-based thermal control mechanisms.

Speaker: Srinivas Pandruvada

95 Devfreq for uncore DVFS

SoC uncore components, such as interconnects, system-level caches, and memory controllers, can account for a substantial share of package power, and their operating frequency bounds the achievable bandwidth and latency. Core DVFS is well supported by cpufreq, but there is no generic upstream mechanism for uncore DVFS - a gap felt most on server platforms. We propose building uncore DVFS on top of devfreq, the DVFS framework for non-CPU devices. The device model fits, but driving it from real utilization data exposes challenges worth discussing.

This topic intends to cover:
1. Motivation - why we need kernel-side uncore DVFS.
2. Existing upstream techniques - devfreq and vendor drivers.
3. Issues encountered - no way for a driver to obtain uncore PMU IDs and create perf events; no suitable events or scaling policy for uncore.
4. Proposals and analysis - a perf core helper, an event monitoring and scaling policy, and prototype measurements.

Speaker: Jie Zhan (HiSilicon)

16:20 Coffee Break

96 Autonomous CPU performance selection: a new cpufreq governor?

ACPI CPPC "autonomous selection" lets the platform pick the CPU performance level itself, within OS-provided min/max bounds and guided by an Energy Performance Preference (EPP) hint. Today cppc_cpufreq exposes this as a per-policy auto_select sysfs toggle layered on top of whatever scaling governor is attached. The result is confusing: once autonomous mode is on, the attached governor (schedutil, ondemand, ...) keeps issuing frequency requests that the hardware ignores, and scaling_governor no longer reflects what actually drives frequency.

cpufreq provides two ways to drive frequency, and CPPC autonomous mode fits neither. Scaling governors use the driver's ->target() callback to apply OS-selected operating points. setpolicy drivers (intel_pstate and amd-pstate "active"/EPP modes) instead let the hardware choose, but CPPC has requirements it does not cover. With setpolicy, the mode is selected globally for all CPUs at the driver level, whereas CPPC's registers are per-CPU and can be controlled per policy. setpolicy also exposes only the performance and powersave policies and provides no ->target() path, while the CPPC spec allows an OS desired_perf hint even when autonomous selection is enabled. So CPPC maps cleanly onto neither model.

This session proposes a third option: modelling autonomous, EPP-biased operation as a per-policy cpufreq governor. Selecting the governor enables autonomous mode and programs the EPP and min/max bounds; switching away restores OS frequency control. EPP is exposed as a per-policy governor tunable, and the autonomous state is reported read-only.

The broader question for the micro-conference is how cpufreq should represent hardware-autonomous selection in general:

• Is a new cpufreq governor the right way to expose autonomous selection at all?
• If a governor is the right model, should it be CPPC-specific or generalized so other drivers can share it?
• How should it relate to the existing setpolicy model used by intel_pstate and amd-pstate?
• Should such a governor also pass utilization-based desired_perf hints to the hardware?
• How should the EPP control be exposed to userspace (naming, accepted values, and consistency with the existing energy_performance_preference interface)?
• What is the migration path away from the current sysfs toggle without breaking existing users?

Speaker: Sumit Gupta

97 Amortizing CPU wakeup costs with lazy wakeups

Transitioning a CPU into and out of idle has a non-negligible energy overhead. This "wakeup tax" is frequently triggered by background tasks with low utilization but a high number of wakeups. Furthermore, these tasks largely escape detection from existing energy-aware mechanisms like PELT and EAS, which are optimized for continuous execution rather than transient hardware states.

This talk explores a new scheduling heuristic: wakeup laziness. A live profile can be built for each task, aggregating stats such as: wakeups per unit time, idle exit/entry costs, and running time per wakeup. By evaluating these historical wakeup costs, the scheduler can classify tasks that are "efficient" (they justify the energy cost of waking the hardware) from those that are "inefficient" (they consume disproportionate energy with minimal execution time).

Instead of allowing inefficient tasks to wake a sleeping CPU, the scheduler enforces wakeup laziness- delaying their execution until an efficient or latency-critical task naturally wakes the hardware. This effectively amortizes the idle-exit cost across batched tasks.

Discussion points:

• How can we classify “wakeup efficiency” of tasks?
• How can we determine tasks that can be delayed without priority inversion or other performance concerns?
• sched_ext can be a natural extension of on-device Wattson, a live power estimation tool, since they are both BPF based. However, can this feature be generalized to a kernel space scheduler?
• Do we need to use energy (such as via on-device Wattson) or is using time as a proxy of energy sufficient for evaluating idle transition costs?

Speaker: Samuel Wu (Google)

98 Current developments in the Common Clk Framework

At last year's Linux Plumbers Conference, we had some great discussions about how to fix clock tree propagation in the Common Clk Framework (https://lpc.events/event/19/contributions/2152/). Taking that feedback into account, a v8 patch set has been posted that solves the problem in a simple manner.

https://lore.kernel.org/linux-clk/20260327-clk-scaling-v8-0-86cd0aba3c5f@redhat.com/

The KUnit tests demonstrate the problem where a clock can unknowingly change the rate of its parent and siblings to suboptimal frequencies. This can have adverse effects on subsystems that need precise rates, such as DRM and sound. The patch set needs more eyes from the community to get across the finish line. We’d like to use part of this session to go over the approach and figure out how to get it merged.

We can use the remainder of the time to discuss suggestions for ways to replace the clk subsystem's global prepare lock with a more fine-grained locking mechanism.

Speaker: Mr Brian Masney

17:45 Short Break

99 Hardware Pressure on x86: Does the Linux Scheduler Need to Know When You're Throttled?

The scheduler's task wake-up logic and capacity-aware load balancing rely on arch_scale_cpu_capacity() to determine how much work a CPU can absorb. It also has logic to account for the effects of transient thermal- and power-driven capacity loss. This mechanism, known as hardware pressure, is currently not used on x86: arch_scale_cpu_capacity() returns a fixed constant on non-hybrid systems, and even on hybrid systems it is a self-normalizing ratio that hides uniform, proportional capacity loss across all cores, since the reference CPU used for normalization throttles along with the rest. No plumbing exists to feed x86 thermal/power status signals (PROCHOT, RAPL power-limitation bits, HWP capability changes) into capacity accounting.

This gap has consequences. Task placement at wake-up and EAS's
overutilized-detection gate can silently keep placing or retaining tasks on a throttled CPU, because the capacity term used for comparison never reflects the throttling; the load balancer may likewise
move tasks onto throttled CPUs. This is not a purely theoretical
concern: single-core thermal throttling is common even on non-hybrid parts, and Intel Speed Select Technology’s Core Power makes persistent, policy-driven asymmetric power allocation across cores.

This talk proposes a design for exposing hardware pressure on x86 and demonstrates it against concrete use cases on real hardware. The goal is not to present a finished solution, but to solicit feedback on whether this problem is worth solving, and if so, whether the proposed solution makes sense.

Speaker: Ricardo Neri (Intel Corporation)

100 Dynamic Runtime Prediction of CPU Idle-State Exit Latency

Benefits of Accurate Exit Latency can have:

More Accurate hrtimer Expiration
Better CPU Idle level Selection
Improved Support for Latency-Sensitive Systems

Cpu different low power state can have different exit latency. And the exit latency may be affected by:

1. current cpu frequency
2. Different firmware version
3. Different hardware difference and etc.

So compile time static idle exit latency is not sufficient. Hence propose to have dynamic Runtime Prediction of CPU Idle-State Exit Latency

More Accurate hrtimer Expiration
Due to exit latency, the actual execution time of a timer interrupt is often later than the programmed expiration time. With an accurate estimate of exit latency, the timer expiration can be advanced accordingly, improving timer firing precision.

QQ Music
Version Max Delay (ns)  Average Delay (ns)
Original    2,446,254   618,558
Original    2,859,657   664,312
Original    1,916,403   466,087
Optimized   629,050 86,448
Optimized   674,887 107,095
Optimized   868,674 102,682
Honor of Kings (30 Hz)
Version Max Delay (ns)  Average Delay (ns)
Original    2,309,583   14,470
Optimized   360,256 8,234

Note that data is collected from an old kernel version and legacy qcom platform.

Better CPU Idle-State Selection
The current TOE cpuidle governor estimates idle duration using Exit Latency / 2. A more accurate exit latency estimation allows the governor to derive an idle duration closer to the actual value, leading to more appropriate idle-state selection.

Improved Support for Latency-Sensitive Systems
Accurate exit latency prediction is particularly beneficial for latency-sensitive workloads, such as:
• PREEMPT_RT systems
• Real-time applications
• Interactive workloads like audio scenario

Obtaining Accurate Exit Latency at Runtime (Monitor)
• Exit latency is fundamentally defined as:
Exit Latency = System Resume Timestamp − Wakeup Event Timestamp
• The current cpuidle governor already compares predicted idle duration against actual idle duration. However, the existing measurement only covers the interval between the last instruction before entering idle and the first instruction after wakeup. Exit latency itself is typically estimated using a static value defined in the device tree.
• In practice, exit latency varies dynamically depending on runtime conditions and system state.
• There are many possible wakeup sources. To accurately determine the wakeup-event timestamp, measurements are restricted to timer-based wakeups because the timer expiration time is known.
• To ensure measurement accuracy, only idle exits triggered exclusively by timer interrupts should be considered, i.e., the timer interrupt is the only pending interrupt when the CPU wakes up.
• CPU idle states are also dynamic. As additional CPUs enter idle, the cluster-level idle state may change. Therefore, the actual idle state must be determined dynamically both when entering and exiting idle, ensuring that collected historical data is correctly associated with the corresponding idle level.

Exit Latency Prediction (Predict)
• Exit latency is influenced by multiple factors and continuously changes during runtime.
• A sliding-window-based approach can be used to collect multiple exit-latency samples.
• Outliers are filtered out, and the average of the remaining samples is used as the predicted exit latency.

Utilizing Exit Latency (Control)
More Accurate Idle-Time Estimation
The cpuidle governor can use the predicted exit latency to improve idle-duration estimation accuracy, resulting in better idle-state selection.

Improved Timer Accuracy on Broadcast-Timer Platforms
On platforms supporting a broadcast timer, multiple CPUs may need to wake up simultaneously. Since a broadcast timer interrupt can only be delivered to a single CPU initially, additional wakeup delay is introduced for the remaining CPUs.
To compensate for this effect, the exit latencies of multiple CPUs can be accumulated and applied to the first awakened CPU, producing a more accurate timer expiration schedule.

Summary of Benefits
Accurate exit latency prediction provides the following advantages:
• More accurate idle-time estimation for the cpuidle governor.
• Improved CPU idle-state selection.
• Higher timer firing accuracy through compensation for exit latency.
• Reduced wakeup latency on broadcast-timer platforms.
• Better performance for latency-sensitive systems such as PREEMPT_RT.

Open Discussions
• During evaluation, a certain percentage of outlier samples is still observed within the sampling window. Currently, these samples are removed directly to reduce their impact on prediction accuracy.
• On platforms running multiple virtual machines, the timer virtualization mechanism may affect the effectiveness and accuracy of exit-latency prediction and compensation. Further investigation is required.

Speakers: Aiqun Yu (Qualcomm), Mr Cong Zhang (Qualcomm)

RISC-V MC

LPC 2026: RISC-V Microconference

The RISC-V ecosystem continues to expand rapidly, with new silicon like the RVA23-compatible SpacemiT K3, a steady cadence of ratified and vendor-defined ISA extensions, and platform classes reaching from embedded parts to server-class SoCs. Session topics cover architecture work, platform and vendor enablement, firmware/SBI coordination, and userspace behavior, with the aim of arriving at concrete next steps that participants can act on after the conference.

Accomplishments since LPC 2025

Results and follow-ups from the 2025 microconference and the broader ecosystem since December 2025:

• Control Flow Integrity (CFI): user-mode CFI support, Zicfilp (forward-edge landing pads) and Zicfiss (shadow stack), was merged for v7.0 window

• ACPI enablement: System MSI and RIMT (RISC-V IO Mapping Table) support landed; additional tables and platform features are being wired up. A new RQSC (Quality of Service Controller) table is under review.

• RVA23 profile: preparatory work in the kernel for safely enabling RVA23-assuming code paths has continued following Charlie Jenkins's 2025 talk.

• Control Transfer Records (CTR): kernel and QEMU support is maturing.

• SBI / firmware messaging: the Message Proxy (MPXY) mailbox driver and related SBI extensions for firmware-mediated device access have been merged / refined.

• Platform enablement: expanded SoC peripheral support (SpacemiT, Eswin, etc.), and progress toward generic distro boot on RISC-V.

• QoS: the Ssqosid + CBQRI + RQSC resctrl series has significantly matured following the 2025 talk.

Proposed topics for 2026

Topics are targeted at ~15-30 minutes. Each session should only have a couple of slides to inform and stimulate discussion among the people attending the session.

• RVA23 in practice - what it means once distros begin assuming it, remaining gaps in discovery, compatibility fallbacks for older hardware, and testing strategy.

• Vendor-specific extensions - strategy for merging and enabling vendor extensions without fragmenting arch/riscv.

• Kernel CFI: next steps - forward-edge kernel CFI, indirect branch tracking, etc

• ACPI on RISC-V - what is still missing for ACPI-first platforms (power, thermal, PCIe quirks, etc)?

• RISC-V QoS and resctrl - Ssqosid + CBQRI + RQSC series status, resctrl integration, open review items, and how this plugs into the cross-architecture resctrl rework.

• SBI firmware messaging (MPXY and beyond) - when MPXY-style firmware mediation is the right answer, how it interacts with mailbox/RPMsg, and the bindings/API stability story.

• IOMMU / RIMT and DMA - RISC-V IOMMU driver maturity, ATS/PRI, SVA on RISC-V, nested translation, DMA coherence and CMO.

• KVM / hypervisor topics - Smrnmi handling, nested virt, Supervisor Software Events (SSE), H-extension adoption across silicon.

• Vector - Vector usage in kernel like crypto and memcpy; should kernel try to support SoC where some cores have longer vector length than others like K3?

• Pre-silicon upstream methodology — continuing from Yuning Liang's 2025 talk: what worked, what didn't, and a shared checklist for bring-up in simulation/emulation environments.

• Debug and crash tooling - kdump and crash follow-ups to Austin Kim's 2025 talk; kgdb, perf, and on-target debug

• RV32 and small cores - follow-up to the "schism" discussion at LPC 2025; what is the sustainable plan for RV32 in-tree?

Key participants

As in 2025, the microconference draws organizers, maintainers, and contributors from across the RISC-V Linux community. Expected key participants: Paul Walmsley, Anup Patel, Conor Dooley, Andrew Jones, Deepak Gupta, Charlie Jenkins, Sunil V L, Samuel Holland, Radim Krcmar, Guo Ren, Inochi Amaoto, Yixun Lan, Ruinland, Austin Kim, Yuning Liang, Andy Chiu, Mikey Neuling, Andy Gross, Joel Stanley, Michael Ellerman, Anirudh Srinivasan, Drew Fustini

16:30 Coffee Break

Birds of a Feather (BoF)

101 Camera & ISP MC

While cameras have been ubiquitous in Linux systems for more than a decade, vendors have historically been very reluctant to disclose any information about Image Signal Processors (ISP), leading to the proliferation of out-of-tree kernel drivers and closed-source userspace stacks. The situation started to change with the launch of the libcamera project at the end of 2018, and progress has accelerated over the past couple of years with more and more vendors jumping on board. Even Qualcomm recently posted an initial ISP driver in a timid but very real first step, a move that was unthinkable just a couple of years ago.

There is plenty of work left to do, as the increased interest from vendors lays bare the lack of investment of the previous decade that leaves many technical issues unsolved. This microconference will bring representatives of kernel subsystems (mainly V4L2, but also DRM), userspace frameworks (libcamera, GStreamer, PipeWire, ...), image sensor vendors and ISP vendors in the same room to discuss and solve open issues.

Example Topics

The following example topics have already been proposed by potential participants.

Low (sub-frame) video pipeline latency

In a typical video pipeline, a sink (e.g. encoder or compositor) waits until a camera finishes writing a frame to memory before stating to consume it. This latency can be reduced by starting the consumer before the frame is fully available. Lack of standardized hardware synchronization primitives for sub-frame latency makes this particularly tricky. Kernel APIs need to be designed, in collaboration with userspace components such as libcamera, GStreamer, PipeWire and Wayland.

Real‑time for camera

Cameras and ISPs have intrinsic real-time constraints, as control algorithms running on the CPU need to produce parameters and schedule jobs with the hardware in time to process frames produced by image sensors. This requires precise timestamping, job scheduling policies, bounded processing latency, and standardized latency/jitter measurement, which are all new areas for the V4L2 API.

Enumeration for ISP parameters and statistics

The last few years saw multiple new ISP drivers being merged in the Linux kernel, in cooperation with SoC vendors. As cameras and ISPs remain an area where vendors are particularly cautious, it is crucial to give vendors a way to upstream drivers with limited scope that can then be extended incrementally. The V4L2 ISP extensible parameters API has been developed for this purpose, and a V4L2 ISP extensible statistics API has also been proposed. Both are however missing a scheme to discover the features supported by a particular driver version.

V4L2 ISP helpers

Now that the kernel includes multiple ISP drivers, we start to see common patterns with duplicated code across drivers. To scale to more ISPs without suffering from cargo-cult mistakes and inconsistent behaviours between drivers, analyzing common patterns and factoring them to helpers is needed. This requires cooperation between developers and maintainers of ISP drivers.

Scaling the media controller graph

The Media Controller API is a key component of kernel drivers involved in camera pipelines. Modern SoCs increasingly include hardware pipelines made of IP cores from different vendors, assembled in different ways. The media controller subsystem does not support this well as it assumes that all pipelines are built around one principal component. Discussions on how to address this issue have just started, and should progress enough by the time of LPC to benefit from a face-to-face session.

Results from previous editions

A Complex Cameras MC took place at LPC 2024. The discussions have mostly focussed on strategies to encourage vendors to participate in mainline development and open their camera stacks, at least partly. This was a piece of a larger outreach effort that produced results: drivers for ISPs from Amlogic, Arm, DreamChip, NXP, Qualcomm, Raspberry Pi, Rockchip and VeriSilicon are now actively developed, and either available in the mainline kernel or under review on public mailing lists.

The camera & ISP microconference stems from this outreach effort but takes a new form. With a critical mass of vendors participating in upstream development, we can now switch the focus from diplomacy and politics to solving technical problems.

Speaker: Laurent Pinchart (Ideas on Board Oy)

Wednesday 7 October

LPC Refereed Track

102 TAB Q&A

The Linux Foundation Technical Advisory Board (TAB) represents Linux Kernel project interests to the Linux Foundation. It also uses the pooled influence of its elected members to support the long term health of the project.

This open forum / panel discussion is an opportunity to learn about and discuss TAB initiatives and ongoing project needs.

Speakers: Dave Hansen, David Hildenbrand (Arm), Greg Kroah-Hartman, Julia Lawall (Inria), Kees Cook (Google), Miguel Ojeda, Shuah Khan (The Linux Foundation), Steven Rostedt, Theodore Ts'o (Google)

103 Cryptographic Proofs of Personhood: Solving the Kernel Web of Trust Problem in a Privacy-Preserving Manner

In any open source software project, maintainer identity is becoming a critical problem. How can you be confident that someone contributing a patch (or PR) is not a malicious adversary? Attacks like the XZUtils compromise have heightened the concern around this sort of software supply chain attack, and the “North Korean developer” problem plagues both companies and open source projects.

Today, the kernel uses the kernel.org PGP web of trust to mitigate this problem. However, the technology that is used is outdated, leading to a system that is neither scalable nor private. In this talk, we propose using a system built on cryptographic proofs of personhood as a better alternative for a cryptographic web of trust. Informally speaking, cryptographic proofs of personhood allow us to build a decentralized, private reputation system, giving us all of the power of the existing web of trust, plus a whole new suite of functionalities.

We will explain the cryptographic principles behind proofs of personhood at a high level in a way that non-cryptographers can understand. Then, we will explain how this technology can be applied to solve the web of trust problem. Finally, we will demonstrate a fully functional, large implementation of proofs of personhood using entirely open source technology (standards and code) hosted in Linux Foundation Decentralized Trust. The demonstration will show that such a solution is ready to be adopted by kernel.org for the web of trust.

Speakers: Mr Drummond Reed (First Person Cooperative), Mr Glenn Gore (Affinidi), Hart Montgomery (Linux Foundation)

104 A Loadable Crypto Module for FIPS Certification

Many organizations require US Federal Information Processing Standard (FIPS) certification of the crypto code they are running. The certification process is lengthy (typically 12–18 months), but the bigger problem is that the way the crypto subsystem is built into the kernel makes the result unable to be reused across kernel updates. This is because FIPS certification is granted at the binary level by NIST. In current kernels, the crypto subsystem is built directly into the main kernel image, so even a non-crypto kernel update — a scheduler fix, a driver addition — produces a new binary and invalidates the existing certification. Distributions are then forced through the full validation cycle again, making it extremely difficult to deliver timely kernel updates while maintaining FIPS compliance.

This talk presents a solution that has shipped in kernel 6.18 on Amazon Linux 2023 and is covered in an LWN.net feature article: decoupling the crypto subsystem from the main kernel and building it as a separate loadable module. The module, rather than the entire kernel, becomes the unit of certification. A subsequent kernel update that does not touch the module leaves the existing certification intact, and loading that certified module onto the updated kernel makes it FIPS-compliant automatically. When the crypto code itself needs updating, a new module can be submitted for certification while users continue running the previously certified one on newer kernels; the old module acts as a bridge, so users never have to choose between an updated kernel and FIPS compliance.

While the existing kernel's module system already allows code to live outside the main kernel, this talk will present why the same approach cannot simply be used here, what falls short, and how the approach overcomes these obstacles in its design and implementation as shipped in production. It will also discuss what it needs to be as a unified upstream foundation that distributions can customize to satisfy different certification setting requirements.

References:

• Patch series: https://lwn.net/ml/all/20260418002032.2877-1-wanjay@amazon.com/
• LWN article: https://lwn.net/SubscriberLink/1073759/95b3d4cd28506836/
• AWS compute blog: https://aws.amazon.com/blogs/compute/introducing-modularized-kernel-cryptography-in-amazon-linux/

Speaker: Jay Wang (Amazon)

11:30 Coffee Break

105 From CVE to Fix in Minutes: AI-Augmented Security Lifecycle Management for Linux Distributions

Linux Plumbers Conference 2026 — Proposal

---

Recommended Track

Distributions Microconference

Why this track: The proposal centers on distro-level CVE lifecycle management — scanning, triage, patching, backporting, and release engineering — which sits squarely in the Distributions MC's scope. It addresses pain points shared by every LTS distro maintainer (Debian, Fedora, openSUSE, Alpine, etc.) and invites cross-distro collaboration on AI-assisted tooling.

Alternative tracks (if Distributions MC is not available):
- Security MC — the CVE rescoring methodology and SLA-driven release model are directly relevant.
- Tooling MC / Refereed Track — the AI backporting agent and automated review pipeline are novel developer tooling contributions.

---

Title

From CVE to Fix in Minutes: AI-Augmented Security Lifecycle Management for Linux Distributions

---

Abstract

Every day, hundreds of new CVEs are disclosed. For Linux distribution maintainers, the challenge is not whether vulnerabilities will arrive — it is how fast you can triage, patch, test, and ship fixes at scale. This session presents a production-proven, end-to-end pipeline that automates the full CVE lifecycle for a Linux distribution serving millions of deployed systems.

We cover five key stages and the design decisions behind each:

1. Detection & Ingestion

CVEs are continuously ingested from the National Vulnerability Database and cross-referenced against distro-specific package versions using scanning pipelines. Raw CVE feeds are noisy, so an automated triage layer checks whether a CVE actually affects the distribution by examining build configurations, internal dependency graphs, and shipped code paths.

2. Distro-Specific Rescoring

Upstream CVSS scores frequently misrepresent actual risk for a given distribution. We present a principled methodology for rescoring CVEs against your own build configuration and hardening posture — a vulnerability rated HIGH upstream may genuinely be LOW risk due to compiler flags (-fstack-protector-strong, -D_FORTIFY_SOURCE=2), disabled features, or sandboxing that neutralizes the attack vector. This directly combats alert fatigue and misallocated engineering effort.

3. Automated Patching & AI-Powered Backporting

Once a CVE is confirmed, the pipeline automatically attempts the fix — preferring minor version (patch-level) upgrades when available, falling back to cherry-picking upstream patches. When neither works cleanly, an AI-powered SWE (Software Engineering) Agent backports patches to the distro's specific version, resolving merge conflicts, adapting to API renames, struct layout changes, and conditional compilation differences. The agent operates in an iterative build-feedback loop: apply patch → build → analyze errors → refine — producing a complete, buildable patch set with full provenance.

Case studies we'll share:
- Patches requiring adaptation across 3+ major version gaps
- Handling renamed functions and refactored code paths
- Fallback strategies when AI backporting fails and how we route to human experts with maximum context

4. Automated Review Pipeline

Reviewing CVE patches is one of the most time-consuming bottlenecks in distro maintenance (15–30 min per PR). We built a multi-stage automated review pipeline that reduces human review time to ~1 minute:

Stage	Method	What It Checks
Spec Validation	Deterministic	Version bumps, patch declarations, changelog format, signature updates
Build Log Analysis	Heuristic	Errors, warnings, test failures from CI
Semantic Patch Comparison	LLM-driven	Classifies match against upstream fix (exact / minor diff / clean backport / significant divergence), generates risk score
Structured Report	Template (Jinja2)	Renders Markdown review posted directly to the PR

We share accuracy metrics, prompt engineering techniques for reliable semantic diff analysis, and lessons learned from production deployment.

5. SLA-Driven Release Engineering

We enforce strict SLAs tied to severity:

Severity	Fix SLA	Release Channel
Critical	5 business days	Fasttrack RPM release
High	10 business days	Fasttrack RPM release
Medium	30 business days	Monthly cadence
Low	Next release	Monthly cadence

We share the operational framework for tying CVE severity to release cadence and how end-to-end observability (CVE inflow trends, severity distribution, package hotspots, fix throughput) enables data-driven security posture management.

---

Why This Matters to the Plumbers Community

1. Reproducible, Distro-Agnostic Blueprint — The architecture (scan → triage → rescore → patch → AI-backport → test → review → ship) is not tied to any single distribution. Maintainers of Debian, Fedora, Alpine, Gentoo, or any custom enterprise distro can adopt the same pipeline patterns.

2. Tackles the Maintainer Shortage — The Linux ecosystem faces a chronic shortage of security-focused maintainers. By automating 80%+ of the CVE lifecycle, small teams can maintain the security posture of a large distribution — directly addressing the sustainability crisis in open-source maintenance.

3. AI Backporting as a Shared Community Tool — We want to start a conversation about building a community-maintained backporting agent that could serve multiple distributions. Every LTS distro, every stable kernel branch, and every enterprise vendor deals with backporting; a shared tool benefits everyone.

4. Distro-Specific Rescoring Should Be Standard Practice — Most organizations blindly consume upstream CVSS scores. We propose a methodology that any distro can adopt to prioritize what truly matters for their configuration.

5. Faster Backporting = Smaller Exposure Windows — AI-assisted backporting means vulnerabilities are patched sooner in stable releases, directly improving security for billions of deployed systems.

---

Session Format

Preferred: 30-minute presentation + 15-minute discussion
Alternate: 20-minute presentation (can condense to focus on backporting agent + review pipeline)

We can provide a live demo of:
- The automated patching pipeline processing a real CVE
- The AI backporting agent resolving a non-trivial merge conflict
- The review pipeline generating a structured review report
- The CVE observability dashboard

---

Discussion Topics for the Microconference

If accepted as part of a broader discussion slot, we'd like to explore:

• Could distros share a common AI backporting agent, and what would the interface/API need to be?
• How do other distros handle the tension between automated patching speed and review thoroughness?
• What test infrastructure is needed to validate AI-generated patches with high confidence?

---

Speaker Bio

Kanishk Bansal is a Software Engineer working on Azure Linux distribution security infrastructure at Microsoft. His work spans CVE triage, AI-powered patch backporting, and intelligent code review systems for a production Linux distribution. He is passionate about applying AI to the critical but under-resourced work of open-source supply chain security.

---

Speaker: Kanishk Bansal

106 BPF_PROG_TEST_RUN: the hidden perils of testing.

BPF_PROG_TEST_RUN has been a crucial tool for testing eBPF programs. Although it has been instrumental for XDP, as BPF spreads to other hookpoints (e.g., TC, sock_ops, struct_ops) that rely on complex data structures such as the SKB, we found that it provides an environment that diverges significantly from the kernel: it does not model these structures and instead defaults their state to zero. This leads to unfaithful test replication and test cases that may miss bugs that would occur in production. We verified three such scenarios in which a single zeroed field hides an entire branch of real kernel behavior.

A simple, concrete instance is skb->cloned, which the harness hard-wires to zero so that every clone-branching helper only ever takes its fast path. Testing against open-source eBPF programs, we confirmed this produces silent semantic divergence: bpf_skb_ecn_set_ce returns success but never sets the CE bit when an skb is cloned and its IP header is unwritable: a path the harness cannot reach. The test therefore reports a pass while the corresponding production behavior differs, illustrating how one unmodeled bit lets both unit tests and verification tools built on BPF_PROG_TEST_RUN overlook real bugs.

Speakers: Lucas Castanheira (CMU), Prof. Theophilus Benson (Carnegie Mellon University)

13:30 Lunch Break

107 When Embedded Codecs Meet Graphics

In the current Linux kernel, video codecs split into two categories. Accelerators built into GPUs are implemented as thin drivers with userspace components exposing APIs such as Vulkan Video or VA-API. Everything else falls under the Video4Linux kernel API. This fragmentation adds complexity for both kernel and userspace developers. VA-API has stagnated and carries historical assumptions tied to Intel hardware, while Video4Linux, despite remaining relevant and widely deployed, has an aging memory model and resource queue mechanism that limits modern use cases. Vulkan Video, by contrast, is actively developed and designed with hardware-specific extensions in mind, making it a strong candidate for embedded use cases.

This talk proposes introducing a new class of embedded video codec drivers into Linux: thin, vendor-specific drivers modeled after GPU drivers, where the V4L2 kernel API is replaced by Vulkan Video, with the userspace driver implemented in Mesa. The goal is not to reinvent the wheel, but to replace an aging one. Such an approach would bring better buffer management through existing DRM memory helpers, modern explicit synchronization primitives already used by GPU drivers, and reduced kernel complexity by pushing codec-specific logic into userspace where it belongs.

Speaker: Nicolas Dufresne (Collabora Ltd.)

Build Systems MC

The Linux ecosystem supports a diverse set of methods for assembling complete, bootable systems—ranging from binary distributions to source-based systems, embedded platforms, and container-native environments. Despite differences in tooling and architecture, all of these systems face shared challenges: managing build complexity, ensuring security and reproducibility, maintaining cross-platform compatibility, and responding to increasing regulatory and supply chain scrutiny.

Building on the success of last year’s microconference, we invite the community to continue the conversation with a broadened scope in 2025. This year, we aim to explore the intersection of build systems with CI/CD pipelines, supply chain security, critical infrastructure, secure development practices, and the potential use of machine learning and AI techniques to improve build systems, CI/CD pipelines, and supply chain analysis. With legislation such as the Cyber Resilience Act, rising expectations for Software Bill of Materials (SBOMs), and mandates for reproducible and auditable builds, collaboration across the ecosystem has never been more essential.

This microconference provides a venue for architects, maintainers, and practitioners from all facets of the Linux build and distribution ecosystem to come together and share ideas, discuss pain points, and identify potential shared solutions.

Target communities and projects include (but are not limited to):

• General-purpose distributions: Debian, Fedora, Ubuntu, Arch Linux, openSUSE, Red Hat
• Source-based systems: Gentoo, NixOS, Guix, CRUX
• Embedded platforms: Yocto Project, OpenEmbedded, Buildroot, OpenWRT/LEDE, Android
• Container ecosystems: Docker, Podman, OCI, BuildKit, distrobuilders
• Immutable, image-based distributions: Flatcar, ParticleOS, Fedora Silverblue, Talos
• RTOS and hybrid build systems: Zephyr, RIOT, Mbed OS, FreeRTOS
• CI/CD and build orchestration: BuildStream, Buildbarn, Bazel, Jenkins, GitLab CI, GitHub Actions
• ML/AI-assisted tooling and infrastructure: anomaly detection, dependency analysis, build optimization, and CI/CD intelligence systems
• Compliance and supply chain security: SPDX, OSI, SBOM tooling, sigstore
• Broader open-source infrastructure efforts and standards bodies

Proposed discussion topics:

• Bootstrapping build systems and managing cross-compilation
• Integration of CI/CD pipelines into build workflows
• Securing the build lifecycle: from developer systems to package publication
• SBOM generation, license auditing, and legal/policy alignment
• Attestation, signing, and ensuring software chain-of-trust
• Handling insecure or volatile upstream language-specific ecosystems (e.g., PyPI, npm, crates.io)
• Reproducible builds and deterministic output across toolchains
• Secure and scalable container build systems and image validation
• Immutable build pipelines for image-based systems and update strategies
• Applying ML/AI to build systems (failure prediction, caching strategies, scheduling, test selection)
• Anomaly detection in build pipelines and supply chain events
• Dependency analysis, risk scoring, and automated patch or update prioritization
• Resilience in build infrastructure for critical systems and edge deployments
• Patch sharing, lifecycle tracking, and cross-distro patch coordination
• Documentation, onboarding, and reducing the learning curve of complex build systems
• Long-term sustainability: mentoring, diversity, and community health of build toolchains

We welcome proposals beyond this list, particularly those that address emerging issues in the creation, validation, maintenance, and secure delivery of Linux-based software systems.

Improving coordination across build systems strengthens the foundations of the open-source ecosystem. Whether you’re maintaining a distro, building firmware, managing containers, applying intelligent systems to improve build and release workflows, or designing infrastructure for high-assurance or real-time systems, this microconference is your forum to advance the state of Linux software construction and security.

11:30 Coffee Break

Containers and checkpoint/restore MC

The Containers and Checkpoint/Restore micro-conference focuses on both userspace and kernel related work.

The micro-conference targets the wider container ecosystem ideally with participants from all major container runtimes as well as init system developers.

The microconference will be discussing recent advancements in container technologies with some of the usual candidates being:

• VFS API improvements (new system calls, idmap, …)
• CGroupV2 feature parity with CGroupV1 and migration path
• Dealing with the eBPF-ification of the world
• Mediating and intercepting complex system calls
• Making user namespaces more accessible
• Verifying the integrity of containers
• Improving the set of resource limits available

On the checkpoint/restore front, some of the potential topics include:

• Making CRIU work with modern Linux distributions
• Handling GPUs
• Restoring FUSE daemons
• Dealing with restartable sequences
• Use of eBPF
• Support of new kernel features
• Supporting shadow stack (x86, arm64)
• Support for madvise(MADV_GUARD_INSTALL)
• Support for mseal()
• Support for pidfd C/R, including process exit information

And quite likely a variety of other container and checkpoint/restore topics as things evolve between now and the event.

Past editions of this micro-conference have been the source of many developments in the Linux kernel, including:

• PIDfds
• VFS idmap (and adding it to a slew of filesystems)
• FUSE in user namespaces
• Unprivileged overlayfs
• Time namespace
• A variety of CRIU features and checkpoint/restore kernel interfaces with the latest among them being
• Unpriviledged checkpoint/restore
• Support of rseq(2) checkpointing
• IMA/TPM attestation work

108 Constraints of process migrations

Triggered by:
Subject: [PATCH 0/4] bpf: add a few hooks for sandboxing
Message-Id: 20260220-work-bpf-namespace-v1-0-866207db7b83@kernel.org

Problem statements:
- Users (admins) are sometimes confused by some entity (PAM, systemd, container
runtimes) migrating their processes away from intended cgroup.
- Coarse-grained DAC doesn't express well who (migrating process) can operate
on what (cgroup) to what (migrated task).
- Limited immutability of membership assignment after certain point.

Proposed solution:
BPF LSM hook for cgroup_attach_permissions
(combination with other existing migration vetting mechanisms
association of permissions with PIDs instead of UIDs?)

Alternate solutions:
- stick with regular cgroup FS permissions
- utilization of other existing LSM hooks

Speaker: Michal Koutný (SUSE)

109 Upgrade restrictions for file descriptors

For quite a while there has been a wish from container runtime to be able to restrict how we can reuse a particular file descriptor. For instance, CVE-2019-5736 showcased a privilege escalation in runc, whereby the possibility of reopening /proc/self/exe as writeable allowed a malicious image to overwrite the runc binary. That was patched on the user space side by copying runc to a sealed memfd_create() file before executing the target. However, it would be better if we could just set restrictions on how some file descriptor can be used (via procfs or O_EMPTYPATH) to reopen a file as writeable in the first place. Thus we would like to have some kind of upgrade mask for file descriptors.

Effort has been spent in the past to implement something like this. For instance, by David Drysdale in 2013 and later by Aleksa Sarai as part of openat2(2) in 2019. I want to take some time to summarize some of these past ideas and see why they were unsuccessful, and what makes this in particular a hairy problem. We can finish with some discussion about what a merge-able patchset would look like.

Speaker: Jori Koolstra (N/A)

110 Memory Tracking in forensic checkpointing: what soft-dirty bits can’t tell us

CRIU’s incremental checkpointing is being used for forensic container snapshot(Stoyanov et al., DFRWS 2026) chains. Soft-dirty tracking cuts snapshot size by about 10× and makes high-frequency capture practical. Live migration only needs a correct final state. Forensics needs the path that led there. Soft-dirty was built for migration and is now being reused for forensics.

A forensic snapshot chain starts with one full snapshot, then stores only later changes. Hash-chaining makes tampering detectable, as long as the host kernel and CRIU stay trusted.

This talk brings the discusion of the challenges with the existing memory tracking mechanism and improvements for forensic use.

Soft-dirty answers one question: did this page change since the last reset? It cannot say when, how many times, in what order, or by whom. Tracking makes pages read-only and catches the first write to each but a page written once and a page written ten thousand times are indistinguishable. Every intermediate value is gone, along with any ordering or context. Even when two pages change, the kernel walks page tables.

Some ways to improve this tracking for forensic checkpointing at container level, have been inspired from several of live migration, hypervisor specific and hardware trapping techniques. One such direction might be maintaining a kernel level dirty set of pages. PAGEMAP_SCAN already helps here, but CRIU mainly uses it as a faster way to read soft-dirty. The tracking mechanism is unchanged, and the kernel-side still walks the range, there is no maintained dirty set, only a faster way to report the outcome of a walk.

Another direction can be to finally start utilising the first-write page fault data rather than discarding almost everything it exposes. Today’s interfaces force a choice: async uffd-wp is cheap but reports one bit, while sync uffd-wp can report richer data at a userspace round trip per fault. Forensics needs rich-and-cheap: capture at the fault, kernel-side, without that round trip.

A separate, lighter option is to recover changed bytes by diffing a captured page against its parent and storing only the difference.

At last, soft-dirty is not broken. It does what live migration needed, well enough that forensic snapshot chains already use it. The problem is that forensics asks a different question, and the interface has no answer for it. Upstream work so far has made the answer cheaper to retrieve without making it richer.

Speaker: Shailja Shaktawat

111 Addressing Challenges for Container Migration in Heterogeneous Clusters

Checkpoint/Restore (C/R) is increasingly used for both startup acceleration (restoring pre-warmed snapshot instances on demand) and live migration. However, deploying static snapshots or migrating tasks across heterogeneous clusters creates severe runtime bottlenecks when source and target nodes possess differing CPU capabilities. While CRIU and container runtimes can accurately preserve memory state, handling CPU feature consistency and safe architectural state restoration across diverse hardware remains an unsolved problem at the kernel boundary.

This session will focus on two critical kernel/userspace interaction challenges:. While CRIU and container runtimes can accurately capture and restore process states and kernel resources, handling CPU feature consistency and safe architectural state restoration across diverse hardware remains an unsolved problem at the kernel boundary.

This session will focus on two critical kernel/userspace interaction challenges:
1. HWCAP Inheritance & Feature Discovery: Examining feature detection failures when restoring snapshots on target nodes with different CPU features, and reviewing proposed mechanisms to inherit or mask hardware capabilities (HWCAP/HWCAP2 via auxv) across execve().
2. Restoring Extended Signal Frame States: Analyzing edge cases where tasks contain in-flight signal frames with architecture-specific CPU state on their stack. We will discuss why rigid kernel-side frame validation during rt_sigreturn causes restoration failures across hardware generations, and propose flexible validation strategies that prevent state corruption while preserving ABI safety.

Goal: Align kernel, container, and language runtime maintainers on kernel-assisted CPU feature control and flexible signal-context restoration to make snapshot-based fast-booting and live migration robust across heterogeneous fleets.

Speaker: Andrei Vagin

11:30 Coffee Break

112 Enabling Incremental Checkpointing for GPU Workloads

With the increased adoption of AI workloads, efficient GPU checkpointing mechanisms are becoming crucial for inference, training, fine-tuning, and reinforcement learning workloads. One of the key challenges with GPU checkpointing today is the lack of memory-tracking support that enables incremental snapshots. When the GPU state is checkpointed into host memory, all pages appear modified, preventing CRIU from identifying which pages have changed since the previous checkpoint and resulting in full snapshot of the GPU memory for every iteration. In this talk, we will discuss extending the GPU plugins for CRIU with support for memory tracking that enables efficient incremental checkpointing. We will explore the benefits of this approach and the trade-offs between performance overhead and storage efficiency across different GPU workloads.

Speaker: Radostin Stoyanov (University of Oxford)

113 Checkpoint/Restore of Device Cgroup eBPF Programs

After moving OpenVZ containers to cgroup-v2 we are struggling a bit to reach
feature parity with what we had before. One such feature is running nested
Docker containers inside an OpenVZ (system) container — part of making our
containers behave as close to a regular server as possible.

In cgroup-v2 the device controller was reformed drastically: device
availability can only be controlled by special BPF_PROG_TYPE_CGROUP_DEVICE
programs attached to cgroups. Docker naturally relies on this, and systemd also
employs it for its own services — so a migrated container without these
programs comes back with its device policy silently dropped. The problem is
that the BPF interface is asymmetric: the kernel accepts a program, but gives
no way to get it back in a reloadable form. The verified/JITed instructions it
can report are not portable — the verifier rewrites context accesses and helper
calls into offsets and addresses specific to the running kernel, so they can
neither pass verification again nor work on another kernel. Mainstream solved
the same problem for seccomp a decade ago — commit f8e529ed941ba ("seccomp,
ptrace: add support for dumping seccomp filters") added an API to retrieve
loaded filters specifically for C/R — but for general BPF programs no such interface
exists to this day.

We took the seccomp approach for cgroup device programs in the Virtuozzo
kernel: keep a copy of the original, pre-verification instructions at load time
and report it through BPF_OBJ_GET_INFO_BY_FD in a new
bpf_prog_info::orig_prog_insns field. The encoding (struct bpf_insn) and the
CGROUP_DEVICE context are stable UAPI, so on restore the program is simply
reloaded and the destination kernel re-verifies and re-JITs it. On top of this
API, CRIU now dumps programs and their per-cgroup attachments (via
BPF_PROG_QUERY), the bpf-prog anon-inode fds held by processes, and on restore
re-attaches everything once the cgroup tree is recreated, preserving the
original sharing topology.

In this talk we will go over the kernel and CRIU sides of the design and
discuss whether such an interface could be accepted in mainstream, along with
the open problems on the way to generic BPF checkpoint/restore: original
instructions for arbitrary program types, maps and their contents, links, and
pinned objects.

Speaker: Pavel Tikhomirov

114 dm-qcow2: device-mapper-based QCOW2 storage for containers

Container storage commonly relies on directory overlays, filesystem-native subvolumes, or thin-provisioned block devices. We will explore another approach: exposing QCOW2 images directly as Linux block devices through a device-mapper target. QCOW2 is the standard virtual-disk format across much of the QEMU/KVM ecosystem. Its widespread adoption, mature tooling, and features such as backing-file chains, persistent bitmaps, and sparse allocation make it an attractive option for container storage as well.

But just having a nice loop device is not a complete solution. Container storage must also support essential operations such as snapshots, backups, and migration. This talk will show how we map these requirements onto existing device-mapper and Linux kernel capabilities, what is still missing, and which problems remain unsolved.

Speaker: Andrei Zhadchenko (Virtuozzo)

Networking Track

11:30 Coffee Break

13:30 Lunch Break

16:30 Coffee Break

Rust MC

Rust is a systems programming language that is making great strides in becoming the next big one in the domain. Rust for Linux is the project adding support for the Rust language to the Linux kernel.

Rust has a key property that makes it very interesting as the second language in the kernel: it guarantees no undefined behavior takes place (as long as unsafe code is sound). This includes no use-after-free mistakes, no double frees, no data races, etc. It also provides other important benefits, such as improved error handling, stricter typing, sum types, pattern matching, privacy, closures, generics, etc.

This microconference intends to cover talks and discussions on both Rust for Linux as well as other non-kernel Rust topics.

Possible Rust for Linux topics:

• Rust in the kernel: status updates and discussion on next steps.
• Use cases for Rust around the kernel: subsystems, drivers, other modules...
• Developing-related discussions: how to abstract existing subsystems safely and API design, coding guidelines, safety guidelines...
• Upstreaming process: guidance on how to get into mainline, strategies that have worked for Rust code in the past, getting involved...
• Maintenance: the new subentries and branches, the proposed cross-subsystem subteams (e.g. the safety team), scaling work for the future, any cross-subsystem issues...
• Infrastructure: build system, documentation, testing and CIs, maintenance, unstable features, architecture support, stable/LTS releases, Rust versioning, third-party crates...
• klint.
• pin-init.
• The future of GCC builds.

Possible Rust topics:

• Language and standard library: discussion on upcoming features, stabilization of the remaining features the kernel needs, memory model, the 2024 edition...
• Compilers and codegen: rustc improvements, LLVM and Rust, rustc_codegen_gcc, gccrs...
• Other tooling and new ideas: Coccinelle for Rust, bindgen, Compiler Explorer, Cargo, Clippy, Miri...
• Educational material.
• Any other Rust topic within the Linux ecosystem.

Please remember that submissions for microconferences (like the Rust MC) should be discussion oriented. Please see "The Ideal Microconference Topic Session".

Last year was the 4th edition of the Rust MC. We had technical discussions around Rust abstractions for the kernel (Overflowing with Fear: Detecting and Mitigating Implicit Panics in Rust, External locking for internally synchronized data structures, Tackling challenges with HID and related device driver support in Rust, Exploring a real life RCU use case for Rust), as well as a presentation and discussion around Rust language features needed by the kernel (Rust language evolutions for better kernel developer experience) and about a Rust-based kernel extension framework (Rex and its integration with Rust-for-Linux). In addition, we had a tutorial session again (Initialization in Rust with pin-init). Finally, we also had a "Birds of a Feather" slot (Rust for Linux Office Hours) for open discussion on other topics.

Suggested attendees: the Rust for Linux team (Miguel Ojeda, Boqun Feng, Gary Guo, Benno Lossin, Andreas Hindborg, Alice Ryhl, Trevor Gross, Danilo Krummrich), Abdiel Janulgue, Alexandre Courbot, Alexei Starovoitov, Alistair Francis, Arnaldo Carvalho de Melo, Bjorn Helgaas, Burak Emir, Christian Brauner, Christian Schrefl, Daniel Almeida, Dave Airlie, David Gow, Dirk Behme, Fiona Behrens, Frederic Weisbecker, FUJITA Tomonori, Greg Kroah-Hartman, Igor Korotin, Ingo Molnar, Jocelyn Falempe, Joel Fernandes, Julia Lawall, Kees Cook, Liam R. Howlett, Lorenzo Stoakes, Luis Chamberlain, Lyude Paul, Masahiro Yamada, Matthew Maurer, Nathan Chancellor, Onur Özkan, Paolo Bonzini, Paul E. McKenney, Peter Zijlstra, Remo Senekowitsch, Rob Herring, Robin Murphy, Sami Tolvanen, Stephen Boyd, Tamir Duberstein, Tathagata Roy, Tejun Heo, Thomas Gleixner, Viresh Kumar, Will Deacon, Yury Norov...

115 Creating self references safely

Self-reference is a common need in kernel code. In fact, this is what motivates the development of pin-init. So far, self-references can only be created with unsafe code with explicit use of Opaque. This is a discussion about on-going working to support safe creation of self references in the pin-init crate.

Speaker: Dr Gary Guo (Red Hat)

116 Reworking `Request` reference counting in the Rust block device driver API

The kernel::block::mq::Request type [1] sits on the I/O hot path of every Rust block device driver. A Request is jointly referenced by the block layer and the driver, with completion arriving on multiple asynchronous paths, so the type has to encode a non-trivial sharing and lifecycle model with minimal runtime cost.

The introduction of Ownable [2] gave us a general mechanism for types that oscillate between owned and reference-counted forms, and applying it to Request cleaned up parts of the API [3]. However, the resulting scheme remains hard to reason about for reviewers [4]. We would like to use an LPC session to walk through the proposed changes with the wider Rust-for-Linux audience to further the review process.

To anchor the discussion, we plan to bring the following content to the session:

• A walk-through of the reworked reference counting scheme.
• Benchmark results from rnull that quantify the cost of the scheme on representative I/O workloads.

The goal of the session is to surface concerns from the community, iron out pain points in the API shape, and build shared understanding of why the scheme looks the way it does — so that when the next version hits the list, the basic design is already broadly understood and accepted.

[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/rust/kernel/block/mq/request.rs?h=v7.1-rc5#n24
[2] https://lore.kernel.org/r/20260224-unique-ref-v16-0-c21afcb118d3@kernel.org
[3] https://lore.kernel.org/r/20260216-rnull-v6-19-rc5-send-v1-5-de9a7af4b469@kernel.org
[4] https://lore.kernel.org/r/87qzopwttw.fsf@kernel.org

Speaker: Mr Andreas Hindborg (Samsung)

117 dma_fence abstractions: Design and Challenges

The kernel's dma_fence subsystem lays at the heart of every graphics processing unit (GPU) driver. It is a primitive for synchronizing the state of jobs running on GPUs with receiver parties, notably userspace. A number of circumstances make the correct implementation and usage of both C and Rust dma_fence very challenging:

• The highly asynchronous nature of GPUs, including the fact that they can hang and need to be reset.
• The fact that fences can have an arbitrary number of consumers, both in other drivers and in userspace.
• Various, partially optional, callbacks exist, with which a consumer can run into the code of a producer, whose module might unload at any time.

Since GPUs can directly access system memory, an incorrect or racing representation of GPU job state by DmaFence could result in memory corruption regardless of Rust's memory safety guarantees.

Moreover, dma_fences have so far not only been involved in various UAF and refcounting bugs, but are also often involved in deadlock conditions. While making memory bugs impossible was the primary design goal for the Rust abstractions, much attention was also paid to preventing deadlock.

In 2026, a shared design, development and upstreaming effort by various parties, notably the Nova and Tyr GPU drivers, has seen much progress. This talk shall give an overview over the general design, solved and persisting problems, and special challenges with Rust regarding these abstractions.

Speaker: Philipp Stanner

118 Tyr: A Status Update

Briefly cover the status of the Tyr project and discuss the current blockers in upstream, specially those related to missing Rust abstractions. This presentation intends to discuss and validate the job submission model, including the proposed GPUVM/JobQueue Rust abstractions and their current upstream status, showcasing the different designs between Tyr's initial implementation and what is actually likely to land on mainline.

Speaker: Daniel Almeida (Collabora)

11:30 Coffee Break

119 Bridging the C/Rust Divide: Replicating the PWM Subsystem's Success

Problem Statement:
Independent developers driving new Rust bindings often face a major bottleneck: getting their work mainlined by hesitant C subsystem maintainers, and just as importantly, sustaining that collaboration post-merge. Translating modern Rust architectures to maintainers who evaluate designs strictly through C paradigms remains a massive hurdle.

Session Focus:
The PWM subsystem recently proved to be a refreshing exception. Using the TH1520 SoC as a hardware target, I successfully upstreamed new PWM bindings by iterating extensively on RFCs and working closely with a supportive C maintainer.

However, the work doesn't stop at the initial merge. The goal of this working session is to use the PWM experience to establish a repeatable playbook for cross-language collaboration. I will start by presenting concrete solutions that worked for PWM, and then open the floor to brainstorm how to replicate this success across the kernel.

Discussion Points:
After a brief (10-minute) overview of the specific strategies that worked during the PWM review process, we will spend the rest of the session brainstorming solutions to the following:

• Technical Mapping & The "C Lens": Concrete strategies for mapping established C expectations (callbacks, structs) to modern Rust traits. How do we design and explain these API boundaries so they intuitively click for a C maintainer and reduce their review burden?

• Post-Merge Collaboration: How to maintain momentum after the bindings land. I will share my experience coordinating abstraction and driver fixes via IRC with the C maintainer. We will debate strategies for getting maintainers heavily involved and comfortable reviewing the Rust side on an ongoing basis.

• "Marketing" the Abstractions: Once the initial bindings and driver are merged, how do we effectively market these new abstractions to the wider community? We will brainstorm how to encourage other developers to write new Rust drivers for the subsystem.

https://mwilczynski.dev/posts/bringing-rust-to-the-pwm-subsystem/

Speaker: Michał Wilczyński

120 Using Rust for out-of-tree kernel drivers

Rust is expanding into more and more places, and it's becoming clear that Rust creates some unique challenges when it comes to drivers that are out-of-tree.

Like all other Rust drivers, out-of-tree drivers written in Rust require abstractions for the subsystems they interact with. If the driver requires a subsystem that does not yet have abstractions, or if the abstractions exist but are missing some part of the API, then the driver may have to implement the abstraction directly within the driver. However, it can be tricky to implement abstractions (or extend existing abstractions) from outside of the kernel crate.

In this topic I would like to discuss approaches for tackling these issues, and also discuss ways in which we are unnecessarily making it more difficult to extend abstractions from drivers.

Speaker: Alice Ryhl (Google)

121 BPF CO-RE support in Rust

Writing BPF programs in the long past meant wrestling with Linux kernel version fragmentation. That problem was solved, many years ago, thanks to CO-RE (Compile Once, Run Everywhere) relocations. CO-RE is a mechanism that uses the BTF type format and its relocation entries (BTF.ext) to handle layout differences, by patching the loaded BPF bytecode with correct offsets that match the running kernel version.

However, as of today, only C compilers (Clang, GCC) are able to emit these relocations, while the Rust ecosystem has been missing that final piece for 100% developer experience parity.

In this talk, we'll dive into the design and experimental implementation of native CO-RE support in the Rust compiler — from the #[btf_relocatable] attribute and core::btf field-info macros, through compiler lowering to the llvm.bpf.preserve.field.info intrinsic, to the final BTF.ext emission. We'll also discuss the trade-offs behind requiring explicit relocation queries rather than making ordinary field projection relocatable.

Speaker: Michal Rostecki (Anza)

Scheduler and Real-Time MC

Building upon the success of last year, we propose a combined microconference focused on the Real-Time and Scheduler subsystems. These two areas are fundamentally intertwined and continue to drive cross-cutting changes, especially following the upstream integration of PREEMPT_RT. The Linux scheduler is central to overall system performance. Addressing the challenges of modern computing—from achieving low latency to maximizing high throughput across diverse topologies and workloads, and scaling from small, power-constrained devices to large-scale HPC systems—is key to delivering the optimal user experience.

Since last year’s microconference, progress has been made on the following topics:
- Cache aware scheduler
- Paravirt Scheduling: Framework for better physical CPU utilization
- CPU Isolation and IPI interference
- Push callback for fair scheduler
- Runtime verification
- Proxy execution

Discussions on certain topics were also carried forward at the OSPM 2026 conference.

Ideas of topics to be discussed include (but are not limited to):
- Responsiveness of fair tasks
- Improve PREEMPT_RT
- Locking and priority inversion
- Improve SCHED_DEADLINE
- CPU isolation
- New topology, including hybrid or heterogeneous system
- Tooling for debugging low latency analysis

This is not an exhaustive list. We welcome all proposals related to process scheduling.
The goal is to discuss open problems, preferably with patch set submissions already being discussed on the mailing list. Presentations are meant to be limited to 2 or 3 slides intended to seed a discussion and debate - allowing for high bandwidth discussion with key stakeholders in the same room.

Key attendees:
- Ingo Molnar
- Peter Zijlstra
- Juri Lelli
- Vincent Guittot
- Dietmar Eggemann
- Steven Rostedt
- Ben Segall
- Mel Gorman
- Valentin Schneider
- K Prateek Nayak
- Thomas Gleixner
- John Stulz
- Sebastian Andrzej Siewior
- Shrikanth Hegde
- Phil Auld
- Dhaval Giani
- Clark Williams

11:30 Coffee Break

Confidential Computing MC

Confidential Computing MC

Over the last few years, the Confidential Computing microconferences at LPC have been a key driver in advancing support for trusted execution workloads across the Linux virtualization and software ecosystem.

As a result of the previous confidential computing microconference, the following major features were merged:

• SEV-SNP support
• TDX support
• TDISP Infrastructure
• SEV-TIO support
• SVSM guest-side support

The microconference at LPC serves as the key in-person event for Linux-related developments, as well as an important platform for standardizing confidential computing features across different platforms.

The open source software stack for confidential computing is still far from being complete. There remain many problems to be solved and functionality to enable. Some of the most important ongoing developments are:

• Enhancements to CVM memory backing via guest_memfd
• KVM Support for ARM CCA
• Privilege separation features in KVM
• CVM live migration.
• Secure VM Service Module architecture and Linux support
• Trusted I/O software architecture

Further topics to discuss are:

• Solutions for the full CVM (remote) attestation problem
• Linux as a CVM operating system across hypervisors
• CVM Performance

The Confidential Computing microconference of 2026 wants to bring open source developers and industry experts together into productive discussions and to collaborate on solutions for the open problems.
Key attendees:
- Ashish Kalra ashish.kalra@amd.com
- Borislav Petkov bp@alien8.de
- Dan Williams dan.j.williams@intel.com
- Daniel P. Berrangé berrange@redhat.com
- David Hansen dhansen@linux.intel.com
- David Kaplan David.Kaplan@amd.com
- David Rientjes rientjes@google.com
- Dhaval Giani dhaval.giani@gmail.com
- Elena Reshetova elena.reshetova@intel.com
- James Bottomley James.Bottomley@HansenPartnership.com
- Joerg Roedel joro@8bytes.org
- Jon Lange jlange@microsoft.com
- Michael Roth michael.roth@amd.com
- Mike Rapoport rppt@kernel.org
- Paolo Bonzini pbonzini@redhat.com
- Peter Fang peter.fang@intel.com
- Peter Gonda pgonda@google.com
- Sean Christopherson seanjc@google.com
- Stefano Garzarella sgarzare@redhat.com
- Tom Lendacky thomas.lendacky@amd.com

16:30 Coffee Break

Driver Core MC

Driver Core Microconference focuses on general problems of the linux kernel driver model.

The goal is to discuss the various aspects and problems of device driver core, platform and auxiliary devices, subsystem architecture, firmware description, fw_devlink, API design and object life-time issues.

Current problems:

Object life-time issues and proposed solutions

Decades-long problem. There have been several attempts at addressing the multiple issues and a few previous talks at LPC and other conferences.

a) Revocable: there's an ongoing effort to provide a unified API for protecting resources against sudden removal of their dependencies. Example: unbinding a resource provider driver to which consumers still hold references. (current revision on the list)

b) I2C bus unbind path: Bartosz Golaszewski proposed a way for a gradual rework of I2C core in order to remove the wait_for_completion() call blocking the kernel thread removing the bus driver until all consumers put their references. Johan Hovold argued the rework can be more in-depth and result in a better outcome. It would be useful to discuss the current state. Work on this seems to be ongoing.. Previous email from Wolfram

Provider/consumer/device API best practices

When discussing the i2c changes, Johan and Bartosz argued about the approach to linux subsystem API design. It would make sense to discuss if there's an "idiomatic" way to design driver interfaces and what it should be. Discussion.

Firmware devlinks

a) Should fw_devlink be enforced for everyone? (Saravana Kannan floated the idea during the Devicetree MC at LPC 25).

b) Adding support for fw_devlink to software nodes. Bartosz Golaszewski is working on this to decrease the number of probe deferrals for software node GPIO lookups which are used extensively on some older but still maintained platforms as well as on x86 platform drivers for which devices are not well described in ACPI.

c) Ulf Hansson proposed a talk titled: "Evolving sync state support to other subsystems beyond genpd".

Device/subsystem API abuse

a) When documentation says one thing and users do another. How to deal with API abuse.

b) Patches using legacy APIs that can't always be spotted by relevant maintainers in time. How to better deprecate APIs.

Platform/auxiliary/faux buses

Let's discuss using dynamically instantiated, "virtual" devices for handling of various corner-cases. There have been several such changes in recent months, for example: in reset and GPIO subsystems.

Firmware node API and its implementations

a) There's an ongoing effort in the GPIO subsystem to remove the string-matching behavior of software node lookup. Let's discuss why attaching software nodes to target devices and enforcing real firmware node links when setting up references is better.

b) Dynamically referencing "real" firmware nodes (OF-nodes, ACPI nodes) from software nodes.

c) Using software nodes as primary firmware nodes for certain devices. This is already done for MFD cells and some auxiliary devices. Is allowing to match devices to drivers by software nodes something worth considering?

d) Converting subsystems to be "fwnode-agnostic". (Example rework)

Devres

It still appears that quite frequently developers seem to misunderstand how devres interfaces work and when exactly the unwinding of resources will happen. Patches are being sent where drivers try to schedule devres actions on devices they don't control or on ones that aren't even bound to drivers. This has led people to blame devres for life-time issues the culprit of which lies with incorrect usage of the API. Can we replicate the Bound context from rust in C?

Key attendees:

Confirmed: Geert Uytterhoeven, Laurent Pinchart, Ulf Hansson, Chen-Yu Tsai, Neil Armstrong, Krzysztof Kozlowski, Hans de Goede, Kevin Hilman, Greg Kroah-Hartman, Marek Vasut, Abel Vesa, Manivannan Sadhasivam, Herve Codina, Danilo Krummrich, Rafael J. Wysocki, Dmitry Baryshkov, Vinod Koul, Srinivas Kandagatla

Likely: Wolfram Sang, Conor Dooley, Dmitry Torokhov, Andy Shevchenko, Drew Fustini

122 Power Sequencing for Enumberable Busses - Driver Core Integrations?

On x86 / ACPI platforms, devices on enumerable busses can normally be seen directly by the OS. On device tree platforms, these devices sometimes require extra power sequencing like toggling regulator supplies or GPIO lines. Over the years most of these cases have been solved, but there are still some gaps.

As of kernel version v7.0, support for power sequencing generic PCI devices, ones that have no extra toggles that are not part of PCI specification, and M.2 M-key slots is available [link]. v7.1 then adds support for the PCI part of E-key slots [link].

Support for the USB part of M.2 E-key slots is WIP by the author [link]. Support for onboard USB devices and USB type A connectors is provided
by the onboard device driver.

This session intends to give a quick overview of the current status and discuss whether parts of this could be moved or integrated at the driver core level. These include:

• Bus code integration for acquiring power sequencers
• Creating stub platform devices to provide power control functionality
• USB onboard devices
• PCI pwrctrl devices

Such mechanisms could then be reused for the MDIO bus.

Speaker: Chen-Yu Tsai (Google, LLC)

123 Reviving early platform drivers

Certain critical subsystems - clocks, timers and interrupt controllers - sometimes need to be initialized before driver core is made available in driver_init(). To that end, we provide a set of macros: IRQCHIP_DECLARE(), CLK_OF_DECLARE(), TIMER_OF_DECLARE() which allow the kernel to call initialization functions based on compatibles either before reaching the point where actual platform devices matching these compatibles can be created or instead of creating them essentially bypassing the driver model entirely.

This results in the initialization routines not being able to use many APIs only available to real drivers and - for many modules - never registering with the driver core.

I've worked on the idea of unifying these paths with a concept of "early platform drivers" back in 2018. That work never got anywhere but the "hacky" approach for early setup remains.

I'd like to re-discuss the idea, it's pros and cons and provide possible solutions for the main contention point raised last time: the fact that my series did nothing to automatically convert existing invocations of the _DECLARE() macros to using early platform drivers.

[1] https://lore.kernel.org/all/20180511162028.20616-1-brgl@bgdev.pl/

Speaker: Bartosz Golaszewski (Qualcomm)

124 Evolving support for sync_state to subsystems beyond genpd

At last LPC in Tokyo we discussed about the limitations of the sync_state support that quite recently was added to the generic PM domain (genpd) subsystem. The conclusion was to mainly focus on making it more fine grained, as this should address most of the problems. Attempts to implement this has been submitted to LKML [1]. Discussion and iterations of the series are moving forward, but a solution is yet to be landed.

In this regards, we also have the need to extend the support for sync_state to more subsystems beyond genpd, to move away from the broken the "disable unused" features that each subsystem currently provides. Moreover, ideally we prefer the support for sync_state to be adopted on a subsystem basis, rather than relying on a per driver based implementation, which isn't scaling. Attempts have been made to add support to the regulator and clock subsystems, while the support in the interconnect subsystem needs improvements.

Let's discuss these topics and in particular how we can make allow subsystem specific implementations to coexist and play along with each other.

[1]
[PATCH v3 00/13] driver core / pmdomain: Add support for fined grained sync_state
https://lore.kernel.org/all/20260508123910.114273-1-ulf.hansson@linaro.org/

Speaker: Ulf Hansson (Qualcomm)

125 Constification of sysfs attribute structures

Sysfs attributes are used throughout the kernel to implement UAPI.
Subsystems either use common attributes, like kobj_attribute and device_attr or define their own wrapper structures.
These structures are only descriptors defining the behavior of an attribute and normally never change.

Historically the attribute however are not marked as const and could be modified through their various callbacks. Such modifications are inherently racy and therefore bug-prone or even a vector for attackers to redirect control-flow.

For some time I have been working on making it possible to mark all the different attribute structures as const to fix these issues.

Agenda:
* Problem statement (see above)
* Current state
* Which attributes can be marked const today?
* Which attributes are already converted.
* Discussion (see below)

• Discussion

Discussion topics:
* Which attribute types are still missing?
* How can subsystem maintainers convert their custom attribute types?
* How to actually convert all the structure instances throughout the tree?

Speaker: Thomas Weißschuh (Linutronix)

16:40 Coffee Break

126 Hardware Cross-Dependencies - Solving the Unsolvable

We are seeing hard to solve cross-dependencies between different SoC subsystems (Rockchip, MediaTek, etc.). For example a power domain needing an I2C regulator, but the I2C regulator needing the I2C bus and the I2C bus driver needing a (different) power domain. This creates a cyclic dependency, since the power domains (or clocks) are usually all behind a single device.

Speakers: AngeloGioacchino Del Regno (Collabora Ltd.), Sebastian Reichel (Collabora)

127 Synx: Cross-core synchronization

Abstract

Modern SoCs increasingly run parts of a single pipeline (AI/ML,
vision, camera, graphics, sensors) across a mix of Linux drivers
and firmwares on remote processors (NPUs and AI processors, ISPs,
companion cores). Coordinating that pipeline requires
synchronization objects that can be created, synchronously or
asynchronously waited on, signaled, and released by any
participant core, Linux and non-Linux, with lifetime tracked
somewhere no single core owns outright.

dma_fence solves the local version of this problem well, but its
lifetime and callback model assumes a single kernel's view of the
world. We've developed Synx, a global handle/refcount table for
this exact cross-processor case, and posted an RFC to dri-devel
and linux-arm-msm describing the model and the specific properties
dma-fence doesn't currently cover (refer supporting links).

Letting any two remote processors signal each other directly,
without routing through the Linux host, cuts latency and avoids an
unnecessary CPU wake-up. The solution has shown power and
performance benefits in the last few generations of Qualcomm
mobile and XR chipsets, and is gathering more use cases,
specifically ones involving AI pipelines.

Christian König redirects us to solve remote signaling in
userspace: a userspace fence/signaling point model based on
dma-buf, citing XE's userspace wait support, eventfd, and ROCm
events as precedent, with possible common ground centered around
eventfd.

Discussion points

(Supposed to evolve as email thread develops)
- the viability of a userspace vs. kernel-space fence model
- the current remote-signaling solutions from other vendors
- scope as standalone or extend current framework. Define
interfaces.
- model the subsystem crash recovery and cleanup

Key people

• Bartosz Golaszewski
• Dmitry Baryshkov, Srinivas Kandagatla (Driver Core MC; also
  Qualcomm colleagues who reviewed Synx internally)
• Christian König (engaged on the RFC thread)
• Faith Ekstrand / Xe authors (cited by König)

Supporting links

• https://lore.kernel.org/dri-devel/5f90bb35-994e-48bd-bf49-3001dcefa2ee@amd.com/
• https://lore.kernel.org/linux-arm-msm/20260806051915.2234481-1-pravinku@quicinc.com/
• formatted duplicate @ https://lore.kernel.org/dri-devel/20260806051915.2234481-1-pravinku@quicinc.com/

Speaker: Pravin Kumar Ravi (Qualcomm Innovation Center, Inc.)

128 Managing IRQ mapping and deferred probing for ACPI static tables devices

In ACPI based system,devices can be created out of ACPI static tables entries (eg ARM64 IORT, GTDT). For those devices, the GSI HW interrupt number is retrieved by reading table specific fields that are different for different static tables. Devices created out of static ACPI tables might be created before the interrupt controller drivers their GSI interrupt is routed to is probed, which means that when the platform device is created the IRQ domain that should be used to map the GSI into a virtual IRQ may not be registered yet.

This leaves us with two issues:

• device drivers for devices created out of static tables can probe only after the interrupt controller driver their IRQ is routed to has probed
• In order to map the virtual IRQ for those devices at device driver probe time, the static table GSI HW IRQ number must be stashed somewhere in the device object so that it can be retrieved and mapped to a virtual IRQ when the device driver is actually probed

Prototyping for this solution is under way and a solution for ACPI namespace devices was already posted[1] (but that can't solve the problem for devices that are created out of static table entries).

This session would help define a way forward.

[1] https://lore.kernel.org/lkml/20260505-gic-v5-acpi-iwb-probe-deferral-v1-0-b37b85998362@kernel.org/

Speaker: Lorenzo Pieralisi

Live Patching MC

Kernel Live Patching allows fixing kernel bugs without rebooting
or stopping the workload. It is an essential tool to keep modern
data centers health with fast evolving kernels and workloads.

The Live Patching MC at Linux Plumbers 2026 aims to gather
stakeholders and interested parties to discuss proposed features
and outstanding issues in live patching.

Possible topics for this year:
- Test framework for livepatch subsystem and the new klp-build
toolchain
- Live Patch compatibility with tracing solutions (kprobe, ftrace,
BPF trampoline, etc.)
- Split a live patch module into submodules
- SFrame and livepatch
- Hybrid live patch idea
- Use AI to help build live patch

Work landed based on previous versions of the Live Patching MC:
- Live patching for arm64
- Live patching for Loongarch64
- Live patching for LTO (with klp-build tool chain)

Key Attendees:
- Josh Poimboeuf
- Jiri Kosina
- Miroslav Benes
- Petr Mladek
- Joe Lawrence
- Song Liu
- Dylan Hatch
- Yafang Shao

16:30 Coffee Break

sched_ext: The BPF extensible scheduler class MC

sched_ext[1] is a Linux kernel feature that enables implementing safe task schedulers in BPF and dynamically loading them at runtime. Its key strength is flexibility, allowing rapid iteration of scheduling policies, deploying changes on the fly and quickly addressing topology inefficiencies or workload-specific issues.

This MC provides a space for the community to discuss the evolution of sched_ext, its impact and future strategies aimed at improving integration with other Linux kernel subsystems.

Last year the sched_ext MC proved highly productive in facilitating coordination with other kernel maintainers, allowing us to address open issues and limitations of this technology (see for example the introduction of a dedicated DL server for the SCHED_EXT scheduling class [2]).

Topics for discussion include (but are not limited to):
- Hierarchical cgroup sub-schedulers
- Integration with SCHED_DEADLINE (DL server interface and related improvements)
- Proxy execution support
- Device-aware scheduling policies (e.g., GPU auto-affinitization)
- Composable schedulers and reusable scheduler libraries (leveraging BPF arenas)
- Scheduling strategies for gaming and latency-sensitive workloads
- Tickless scheduling and CPU isolation
- Improved tooling for tracing and visualizing scheduler performance

A public CFP will follow to gather additional topics that may be relevant to the Linux community.

Key attendees:
- Andrea Righi
- Changwoo Min
- Tejun Heo
- Peter Zijlstra
- Juri Lelli
- Vincent Guittot
- Dietmar Eggemann
- Steven Rostedt
- K Prateek Nayak
- John Stulz
- Shrikanth Hegde
- Emil Tsalapatis
- Daniel Hodges
- Christian Loehle
- Ryan Newton

[1] https://github.com/sched-ext/scx
[2] https://lore.kernel.org/all/20260126100050.3854740-1-arighi@nvidia.com

129 Intro / Welcome

130 Bridging the VM Boundary: Scheduling Passthrough via pvsched and sched_ext

As production workloads increasingly transition to virtual machines for security isolation and resource consolidation in multi-tenant environments, traditional CPU scheduling faces a critical M:N preemption challenge. The host operating system schedules opaque virtual CPUs rather than the actual workload threads. Consequently, the host scheduler remains blind to the varying priorities and latency sensitivities of the guest threads running inside the VM. This leads to severe priority inversion; for instance, the host scheduler cannot differentiate between a vCPU running a low-priority batch or kernel system thread and one executing a latency-sensitive task (such as a critical helper daemon) nested within the same VM. Consequently, critical latency-sensitive work is starved, and physical resources are wasted under host CPU contention.

To resolve this, we propose a bidirectional VM Scheduling Passthrough architecture to bridge the VM boundary from a scheduling perspective. This model relies on cooperative, paravirtualized communication to enable host-side awareness and control:
1. Guest-to-Host: The guest kernel exposes scheduling metadata (potential signals include thread-level priorities and latency requirements) to the host.
2. Host-to-Guest / Host Control: The host leverages these guest signals to either (a) intelligently prioritize the execution of a given vCPU, or (b) in a more complete solution, directly select both the vCPU and the specific guest thread running on that vCPU to execute (this latter proposal is more aspirational, and would effectively give the host full scheduling control over the guest, voiding the need for guest scheduling or load balancing).

Implementing such a model requires a clean separation of mechanism and policy. In line with upstream maintainer feedback, KVM should remain policy-free, acting purely as the communication conduit. We propose sched_ext as the ideal framework to house the scheduling policy, and pvsched as the communication mechanism to share data between host and guest. Running the policy in a host BPF scheduler allows for rapid iteration and workload-specific customization without modifying KVM or the core kernel.

Current upstream efforts, notably the IBM patch series "Introduce cpu_preferred_mask and steal-driven vCPU backoff", attempt to address host preemption purely from the guest side. In this model, the guest monitors hypervisor steal time and flags heavily preempted vCPUs as "non-preferred" to guide guest-side task migration. While this provides a defensive mechanism, it is unidirectional and reactive. Furthermore, as highlighted by upstream maintainers, this approach faces significant limitations: it risks embedding scheduling policy within the hypervisor, and in high-overcommit scenarios where steal time is elevated across all cores, the guest-side mask degrades, leaving the guest scheduler with no viable execution targets.

pvsched (https://github.com/pvsched/) has undergone some discussion on the list already, and v3 is being prepared.

In this session, we want to discuss:
- Interface Design: The updates in pvsched v3
- sched_ext Integration: How sched_ext can ingest these guest signals to influence host scheduling decisions, and conversely, how it can export host scheduling desires back to the guest

Speakers: Josh Don (Google), Mr Vineeth Remanan Pillai (Google)

131 BPF-based Composable Idle cpumask Selection

All sched_ext schedulers currently use kfuncs to manage their idle cpumask using a hardcoded policy provided by the kernel. This lack of configurability of the current cpumask requires us to add policy through explicit masking operations directly in the scheduler code. This in turn leads to duplicating idle CPU selection logic across schedulers as it is difficult to factor it out.

This session discusses a new BPF-based subsystem for idle CPU mask selection. This subsystem abstracts the representation of the idle CPU set behind a common API that exposes explicit alternative policies to the user. The API is portable between schedulers and requires little code to adopt. Internally, the subsystem stores idle CPU information in arena-based data structures. Different structures (e.g., radix trees) provide different performance/scalability tradeoffs and can be tailored to different idle CPU selection policies.

Topics for this session:
- Overview of the idle CPU selection subsystem
- Data structures for representing the idle CPU set, tradeoffs for each
- Representing policy in a flexible, extensible fashion through the idle selection API
- Using alternative CPU selection strategies as part of load balancing

Speaker: Emil Tsalapatis (Meta Platforms)

132 Taming latency spikes caused by lock holder and lock waiter preemption

Preempting a lock holder — or failing to promptly schedule a just-woken
lock waiter — extends the serialized critical section and produces severe
tail-latency (P99) spikes: degraded server throughput, frame-time
spikes and dropped frames in games. Applications hit this on both
kernel-space locks and user-space primitives backed by futexes and SysV
semaphores. Existing techniques help but leave gaps: proxy execution
addresses kernel-mutex priority inversion but not user-space futex waiters
or counting semaphores, and time-slice extension protects a detected holder
while doing nothing for the delayed waiter.

We define lock waiter preemption (LWP) as the dual of lock holder
preemption (LHP): the scheduling delay a woken waiter suffers before it
runs, which we have measured at 2–16 ms in production game and server
workloads. We will present these measurements and a prototype LHP/LWP
mitigation built in a production sched_ext scheduler, then open three
challenges for community discussion:

• efficiently identifying lock-related preemption from BPF;
• exposing synchronization state between libc and sched_ext;
• designing lightweight scheduler-assisted locking that improves latency
  without sacrificing scalability.

Speaker: Changwoo Min (Igalia)

133 Making proxy execution compatible with sched_ext

Proxy execution allows a waiting task (the "donor") to donate its execution context to a mutex owner, enabling the owner to continue running while the donor remains eligible on the runqueue.

Today, proxy execution and sched_ext are mutually exclusive build-time options: a kernel cannot be built with both CONFIG_SCHED_PROXY_EXEC=y and CONFIG_SCHED_CLASS_EXT=y.

This limitation is problematic for Linux distributions and anyone who wants to ship a single kernel image while selecting features at runtime.

An RFC series proposing support for this integration has already been posted: https://lore.kernel.org/all/20260506174639.535232-1-arighi@nvidia.com/

However, several design questions remain open. This session aims to discuss those issues, reach agreement on the overall approach, and define a concrete plan for moving the integration forward.

Speaker: Andrea Righi (NVIDIA)

16:30 Coffee Break

134 Stickiness: Keeping tasks cache-warm in work-conserving LAVD scheduler

Work-conserving schedulers prefer running tasks on idle CPUs
immediately, ensuring no processing capacity is wasted while work is
waiting. In the lavd select_cpu process, when a task wakes, the
scheduler will do its best to seek an idle core and run the task over
there. However, this idle-oriented CPU selection generally prioritizes
idle cores over the cache-warm cores, leading to more migrations,
making the tasks cache-cold, and requiring L1/L2 caches and TLBs to be
refilled frequently.

The work-conserving mechanism works well in some scenarios. However,
there are cache-sensitive workloads such as edge routers using routing
tables as in-memory KV stores. The migrations to the cold CPU have a
global impact, and the cache refilling evicts the other cache lines
and pulls the new ones in, making the cache contention worse and further
impacting the tail latency.

---

We will present our measurements and open the floor on topics
including:

• Warmth estimation: How long does L1/L2/TLB state realistically
  survive on a CPU, and could the kernel expose hardware signals
  (e.g., PMU counters, cache-occupancy registers) usable at
  scheduling-decision frequency?

• The wait-or-migrate decision: Waiting requires predicting when
  a busy CPU will become available (remaining slice + queue service
  time, or queue load?). Which metrics should a scheduler maintain to
  make that prediction accurate?

• The scheduler/userspace interface: Userspace structures (such
  as allocator per-CPU caches) suffer heavily from core migrations.
  Should applications hint their locality needs to the scheduler, or
  should the scheduler expose warmth and migration state to userspace?

Speaker: Gavin Guo

135 HFI plug in to scx_ext

This presentation explores how Intel HFI can be integrated with a sched_ext to improve task placement and power-performance efficiency on hybrid Intel systems. HFI provides real-time hardware guidance on which CPUs are better suited for performance- or efficiency-oriented work, or which to avoid, while sched_ext like LAVD supplies an adaptive scheduling framework capable of using that guidance at runtime. By converting HFI output into scheduler-readable CPU hints, the system can bias wakeup placement, avoid degraded cores, and better match task type to CPU capability without hard pinning or manual tuning.

Speaker: Srinivas Pandruvada

136 Automatic placement of accelerator workloads

Proposal

On modern multi-socket, multi-GPU systems, application performance is often limited not by compute availability but by poor CPU/GPU locality. Today, customers are frequently instructed to rely on strict node pinning (numactl) and disabling NUMA balancing in order to avoid costly cross-node memory accesses. While effective in some cases, this approach can be suboptimal, since it limits workloads to a subset of available resources and it also requires deep system knowledge from the user.

In this talk, we will explore how GPU-aware auto-affinitization can be implemented directly in the Linux scheduler using sched_ext, enabling dynamic and transparent placement of CPU tasks close to the GPUs they actively use. We discuss the challenges of integrating scheduler-driven task migration with NUMA balancing, handling mixed CPU/GPU thread groups, and avoiding resource over-concentration. Finally, we present design principles showing how scheduler-level techniques can outperform static affinity policies, while simplifying the user experience.

Key Challenges

Interaction with NUMA Balancing

Naively migrating a task closer to its GPU can backfire if the task's memory remains allocated on a remote NUMA node. In such cases, migration may increase memory access latency instead of reducing it.
Key questions explored:
How can sched_ext and NUMA balancing cooperate rather than conflict?
When should migration be deferred or paired with memory migration?

Thread Aggregation and Shared State

Many GPU-enabled applications use multi-threaded CPU components, where:
Only a subset of threads directly interacts with the GPU
Other threads share memory, locks, or cache lines with GPU-driving threads
Migrating only GPU-active threads may introduce new inefficiencies due to cross-node communication among threads of the same process.

We need to explore strategies for:

Selective thread aggregation, migrating related threads together
Avoiding overload of a single NUMA node or LLC
Balancing locality benefits against parallel resource contention

Resource Saturation and Fairness

Automatically clustering tasks near GPUs risks oversubscribing CPUs, LLCs, or memory bandwidth on specific NUMA nodes. The scheduler must therefore avoid overloading a certain LLC or NUMA node, make optimal use of system resources and maintain fairness.

Speakers: Balbir Singh, Lee Trager (NVIDIA)

137 Closing / Final Q&A

Birds of a Feather (BoF)

138 FUSE mostly-passthrough filesystems

Many production FUSE filesystems do not need to reimplement the full filesystem stack. They need to mirror an existing directory with full fidelity while intercepting only a small subset of operations for caching, tiering, HSM stub manifestation, or auditing.

To make these filesystems easier to build, we introduce libfuse_passthrough - a C++ library that handles all FUSE plumbing and exposes a lightweight module API where only the intercepted operations need to be implemented where everything else passes through automatically.

The library makes use of upstream kernel FUSE read/write passthrough, which allows open files to bypass the FUSE daemon entirely, and provides an experimental playground for the development of more FUSE kernel passthrough operations.

We invite contributors and users with FUSE passthrough workloads to learn about our experience, discuss open problems, kernel interface requirements, and help shape the future of FUSE.

Speaker: Amir Goldstein (CTERA Networks)

16:30 Coffee

139 Defining the pkeys ABI

We have been supporting pkeys [1] on Linux for 10 years now, and they
are no longer specific to x86: arm64 and powerpc support them too.
Unfortunately, important gaps remain in the kernel-user ABI, making it
difficult to deploy pkeys robustly for key use-cases.

pkeys work in a fairly simple way: the user allocates a new pkey and
then assigns that pkey to a VMA. Access to that VMA is then restricted
by a user-controlled register, which defines RWX permissions for every
pkey. The restrictions apply to both user and kernel accesses (uaccess
and GUP).

Difficulties arise when the kernel interrupts a user thread and then
accesses its memory, or invokes a signal handler. In those cases, it is
unclear which pkeys authority the kernel should use, whether userspace
should be able to configure it, and how to avoid spurious crashes or
confused deputy situations. This is what the current ABI is lacking.

This BoF is especially intended for arch/mm maintainers, libc/runtime
developers, and userspace developers already familiar with pkeys or
deploying pkey-based isolation. The goal is not to present a finished
design, but to agree on the programming model that future ABI work
should follow.

A few important use-cases are currently difficult or impossible to
implement robustly:

• Isolating the alternate signal stack: mapping it with a non-default
  pkey that only signal handlers are allowed to access.

• Sandboxing with pkeys: preventing some context from accessing
  even the default pkey (0).

Problematic situations include:

• Signal delivery [2]: signal handlers may be called asynchronously and
  are conceptually independent of the interrupted context.
  Userspace may need the pkey register to be reset to a specific value
  both for writing the signal frame and invoking the signal handler.

• rseq [3]: the kernel writes to the registered struct rseq when context
  switching, which can happen at any point. This is again independent of
  the interrupted context, which may not be allowed to write to that
  struct.

• io_uring worker threads: these are kernel threads that access user
  memory asynchronously. They have their own pkey register value
  restricting those accesses, but userspace is not currently able to
  configure it.

• Other cases, such as BPF helpers accessing user memory and
  process_vm_readv(self) bypassing pkeys completely.

All these issues lead to a set of questions that we need to answer to
create a consistent and unsurprising ABI:

• Which contexts need a dedicated or userspace-configurable pkey
  register value?

• Are there accesses that should intentionally bypass pkeys, and if so,
  how should that be documented?

• Can these issues be handled with targeted fixes, or do we need a more
  unified ABI design for asynchronous kernel access to pkey-protected
  memory?

As Thomas Gleixner put it:

We really need to sit down and actually define a proper programming
model first instead of trying to duct tape the current ill defined
mess forever.

The intended outcome of this BoF is a shared direction for documenting
and extending the pkeys ABI, so that pkeys can be used reliably as
intra-process privilege boundaries rather than only as a best-effort
hardening mechanism.

[1] https://docs.kernel.org/core-api/protection-keys.html
[2] https://inbox.sourceware.org/libc-alpha/fc31e639-f1eb-42d6-9dea-3665d9507f12@arm.com/
[3] https://lore.kernel.org/all/87ikexhbah.ffs@tglx/

Speaker: Kevin Brodsky (Arm)

140 Virtio and Vhost-User Ecosystem for Production and Automotive Systems

The vhost-user protocol started as a simple QEMU feature, but it has grown into a standard used across the entire Linux virtualization community. Today, it powers production workloads in the cloud (e.g. QEMU and cloud-hypervisor), lightweight environments like libkrun, and modern automotive systems.

However, as the ecosystem expands, we are hitting new "plumbing" bottlenecks. For example, the protocol specification is still stored inside the QEMU documentation, which makes it harder for other projects to participate in its growth. At the same time, automotive deployments are introducing strict new needs, such as safety certification, real-time performance, and long-term support, that impact everyone.

This BoF will bring developers and users together to address these challenges and other emerging topics across the ecosystem. Our goal is to establish better coordination, align technical roadmaps for both cloud and automotive, and build shared tests and tools to ensure all implementations work together.

Key Discussion Topics:
- Official location for the vhost-user specification
- Improvements needed to the vhost-user specification
- Integration testing infrastructure for vhost-user backends and multiple VMM frontends (QEMU, libkrun, cloud-hypervisor, crosvm)
- Automotive Virtualization Requirements and Reference Platform Coordination[1]
- Automotive Usecases: For example Android Automotive's use of crosvm and potential adoption of vhost-device backends; Red Hat Automotive's software-defined vehicle architecture using libkrun; and Panasonic Automotive's priorities for vhost-user implementations.
- Safety/certification requirements for vhost-user implementations
- Real-time performance needs (camera, display, CAN)
- Ongoing work on vhost-user device (virtio-Media, virtio-can, virtio-rtc, etc)[2][3]
- Graphics Stack Coordination: Discuss Roadmap decisions on rutabaga_gfx which is shared by crosvm, libkrun, and vhost-device-gpu [4]
- vDPA/VDUSE overlap with vhost-user protocol
- POSIX (or other OS) support for vhost-user implementations

[1] https://source.android.com/docs/automotive/virtualization/reference_platform
[2] https://lore.kernel.org/virtualization/ab2FlQTWUxl0KmlT@fedora/
[3] https://github.com/rust-vmm/vhost-device/pull/944
[4] https://github.com/magma-gpu/rutabaga_gfx/issues/24

Key Participants:
- Albert Esteve aesteve@redhat.com
- Stefano Garzarella sgarzare@redhat.com
- Sergio Lopez slp@redhat.com
- Manos Pitsidianakis manos.pitsidianakis@linaro.org
- Alex Bennee alex.bennee@linaro.org
- Matej Hrica mhrica@redhat.com
- Milan Zamazal mzamazal@redhat.com
- Gurchetan Singh gurchetansingh@google.com
- Jorge E. Moreira jemoreira@google.com
- Matias Vara Larsen mvaralar@redhat.com
- Dorinda Bassey dbassey@redhat.com
- Alberto Ruiz aruiz@redhat.com
- Erico Nunes ernunes@redhat.com
- John Ferlan jferlan@redhat.com
- Michael Tsirkin mst@redhat.com
- German Maglione gmaglion@redhat.com
- Stefan Hajnoczi stefanha@redhat.com
- Timos Ampelikiotis t.ampelikiotis@virtualopensystems.com
- Harald Mommer harald.mommer@oss.qualcomm.com

Speakers: Dorinda Bassey (Red Hat), Albert Esteve (Red Hat), Stefano Garzarella (Red Hat)