Registration Currently Sold Out, We’re Trying to Add More Places

Linux Plumbers is now sold out and in-person registration is closed.

This year it happened not as fast as in 2022, but the registration is still sold out long before the event.

We are setting up a waitlist for in-person registration (virtual attendee places are still available). Please fill in this form and try to be clear about your reasons for wanting to attend. This year we’re giving waitlist priority to new attendees and people expected to contribute content.

Containers and Checkpoint/Restore MC CFP

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:

  • CGroupV2 feature parity with CGroupV1
  • Emulation of various files and system calls through FUSE and/or Seccomp
  • Dealing with the eBPF-ification of the world
  • Making user namespaces more accessible
  • VFS idmap improvements

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

  • Restoring FUSE services
  • Handling GPUs
  • Dealing with restartable sequences

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:

Use LPC abstract submission page to submit your proposals and select “Containers and Checkpoint/Restart” track.

Power Management and Thermal Control MC CFP

The Power Management and Thermal Control microconference focuses on power management and thermal control infrastructure, CPU and device power-management mechanisms, and thermal control methods.

In particular, we are interested in improving the thermal control infrastructure in the kernel to cover more use cases and utilizing energy-saving opportunities offered by modern hardware in new ways.

The goal is to facilitate cross-framework and cross-platform discussions that can help improve energy-awareness and thermal control in Linux.

The current list of topics proposed so far includes the following:

 

Confidential Computing MC CFP

Confidential Computing is continuing to remain a popular topic in computing industry. From memory encryption to trusted I/O, hardware has been constantly improving and broadening. In the past years,  confidential computing microconferences have brought together developers working on various features in hypervisors, firmware, Linux kernel, low level userspace up to container runtimes. We have  discussed a broad range of topics, ranging from, hardware enablement to generic attestation workflows.

Just in the last year, we have seen support for Intel TDX and AMD SEV-SNP guests merged into Linux. Support for unaccepted memory has also landed in mainline. We have also had support for running as a CVM under Hyper-V partially merged into the kernel. However, there is still a long way to go before a complete Confidential Computing stack with open source software and Linux as the hypervisor becomes a reality. We invite contributions to this microconference to help make progress to that goal.

Topics of interest include

Please use the LPC CfP process to submit your proposals. Submissions can be made via the LPC abstract submission page. Make sure to select “Confidential Computing MC” as the track.

IoT MC CFP

The IoT Microconference is a forum for developers to discuss all things IoT. Topics include tools, telemetry, device drivers, and protocols in not only the Linux kernel but also Real-Time Operating Systems such as Zephyr.

Since last year, there have been a number of new technical topics with significant updates.

  • Opportunities in IoT and Edge computing with the Linux /dev/accel API
  • Using the Thrift RPC framework between Linux and Zephyr
  • Zephyr’s new HTTP Server (a GSoC project)
  • Rust in the Zephyr RTOS: Benefits, Challenges and Missing Pieces
  • BeagleConnect Freedom Updates, Greybus, and the Linux Interface
  • Linux-wpan updates on 6lowpan, 802.15.4 PAN coordinators and UWB

Current Problems that require attention (stakeholders):

  • IEEE 802.15.4 SubGHz improvement areas in Zephyr, Linux (Florian Grandel, Stefan Schmidt, BeagleBoard.org)
  • WpanUSB upstreaming in the Linux kernel, potentially dropping Zephyr support (Andrei Emeltchenko, BeagleBoard.org)
  • IEEE 802.15.4 Linux subsystem device association handling (Miquel Raynal, Alexander Aring, Stefan Schmidt)
  • Zephyr potentially dropping Bluetooth IPSP?

On a slightly less technical topic.

  • Reflections after Two Years of Zephyr LTSv2

We are pleased to announce that the IoT Microconference is now accepting proposals!

If you are interested in presenting an IoT-related topic involving the Linux kernel, userspace tools, firmware, Zephyr, or frameworks, please upload your submission before September 15th.

Submissions can be made via the LPC Call for Proposals, by selecting Internet of Things MC for your track.

VFIO/IOMMU/PCI MC CFP

On behalf of the PCI sub-system maintainers, we would like to invite everyone to join the VFIO/IOMMU/PCI micro-conference (MC) this year.

We are hoping to bring together, both in person and online, everyone interested in the VFIO, IOMMU, and PCI space to talk about the latest developments and challenges in these areas.

The PCI interconnect specification, the devices that implement it, and the system IOMMUs that provide memory and access control to them are nowadays a de-facto standard for connecting high-speed components, incorporating more and more features such as:

These features are aimed at high-performance systems, server and desktop computing, embedded and SoC platforms, virtualisation, and ubiquitous IoT devices.

The kernel code that enables these new system features focuses on coordination between the PCI devices, the IOMMUs they are connected to, and the VFIO layer used to manage them (for userspace access and device passthrough) with related kernel interfaces and userspace APIs to be designed in-sync and in a clean way for all three sub-systems.

The VFIO/IOMMU/PCI MC focuses on the kernel code that enables these new system features, often requiring coordination between the VFIO, IOMMU and PCI sub-systems.

Following the success of LPC 2017, 2019, 2020, 2021, and 2022 VFIO/IOMMU/PCI MC, the Linux Plumbers Conference 2023 VFIO/IOMMU/PCI track will focus on promoting discussions on the PCI core but also current kernel patches aimed at VFIO/IOMMU/PCI sub-systems with specific sessions targeting discussions requiring the three sub-systems coordination.

See the following video recordings from 2022: LPC 2022 – VFIO/IOMMU/PCI MC

Older recordings can be accessed through our official YouTube channel at @linux-pci and the archived LPC 2017 VFIO/IOMMU/PCI MC web page at Linux Plumbers Conference 2017, where the audio recordings from the MC track and links to presentation materials are available.

The tentative schedule will provide an update on the current state of VFIO/IOMMU/PCI kernel sub-systems, followed by a discussion of current issues in the proposed topics.

The following was a result of last year’s successful Linux Plumbers MC:

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

  • PCI
  • VFIO
    • Write-combine on non-x86 architectures
    • I/O Page Fault (IOPF) for passthrough devices
    • Shared Virtual Addressing (SVA) interface
    • Single-root I/O Virtualization(SRIOV)/Process Address Space ID (PASID) integration
    • PASID in SRIOV virtual functions
    • Device assignment/sub-assignment
  • IOMMU
    • /dev/iommufd development
    • IOMMU virtualisation
    • IOMMU drivers SVA interface
    • DMA-API layer interactions and the move towards generic dma-ops for IOMMU drivers
    • Possible IOMMU core changes (e.g., better integration with the device-driver core, etc.)

If you are interested in participating in this MC and have topics to propose, please use the Call for Proposals (CfP) process.

Otherwise, join us to discuss helping Linux keep up with the new features added to the PCI interconnect specification. We hope to see you there!

Proposals can be submitted here here by selecting Track “VFIO/IOMMU/PCI MC

Tracing MC CFP

The Linux kernel has grown in complexity over the years. Complete understanding of how it works via code inspection has become virtually impossible. Today, tracing is used to follow the kernel as it performs its complex tasks. Tracing is used today for much more than simply debugging. Its framework has become the way for other parts of the Linux kernel to enhance and even make possible new features. Live kernel patching is based on the infrastructure of function tracing, as well as BPF function hooks. It is now even possible to model the behavior and correctness of the system via runtime verification which attaches to trace points. There is still much more that is happening in this space, and this microconference will be the forum to explore current and new ideas.

Results and accomplishments from the last Tracing microconference (2021):

  • User events were introduced, and have finally made it into the kernel.
  • The discussion around trace events to handle user faults initiated the event probe work around to the problem. That was to add probes on existing trace events to change their types. This works on synthetic events that can pass the user space file name of the entry of a system call to the exit of the system call which would have faulted in the file and make it available to the trace event.
  • Dynamically creating the events directory with the eventfs patch set is queued to be accepted. This will save memory as the dentries and inodes will only be allocated when accessed.
  • The discussion about function tracing with arguments has helped inspire both fprobes and function graph return value tracing.
  • There’s still ongoing effort in unifying the return path tracers of function graph and kretprobes and fprobes.

Possible ideas for topics for this year’s conference:

  • Use of sframes. How to get user space stack traces without requiring frame pointers.
  • Updating perf and ftrace to extract user space stack frames from a schedulable context (as requested by NMI).
  • Extending user events. Now that they are in the kernel, how to make them more accessible to users and applications.
  • Getting more use cases with the runtime verifier. Now that the runtime verifier is in the kernel (uses tracepoints to model against), what else can it be used for.
  • Wider use of ftrace_regs in fprobes and rethook from fprobes because rethook may not fill all registers in pt_regs too. How BPF handles this will also be discussed.
  • Removing kretprobes from kprobes so that kprobe can focus on handling software breakpoint.
  • Object tracing (following a variable throughout each function call). This has had several patches out, but has stopped due to hard issues to overcome. A live discussion could possibly come up with a proper solution.
  • Hardware breakpoints and tracing memory changes. Object tracing follows a variable when it changes between function calls. But if the hardware supports it, tracing a variable when it actually changes would be more useful albeit more complex. Discussion around this may come up with a easier answer.
  • MMIO tracer being used in SMP. Currently the MMIO tracer does not handle race conditions. Instead, it offlines all but one CPU when it is enabled. It would be great if this could be used in normal SMP environments. There’s nothing technically preventing that from happening. It only needs some clever thinking to come up with a design to do so.
  • Getting perf counters onto the ftrace ring buffer. Ftrace is designed for fast tracing, and perf is a great profiler. Over the years it has been asked to have perf counters along side ftrace trace events. Perhaps its time to finally accomplish that. It could be that each function can show the perf cache misses of that function.
For more information, feel free to contact the MC Leads:
Steven Rostedt <rostedt@goodmis.org>
Masami Hiramatsu <mhiramat@kernel.org>
Please follow the suggestions from this BLOG post when submitting a CFP for this track.
Submissions are made via LPC submission system, selecting Track “Tracing MC”

Kernel Testing & Dependability MC CFP

Once again The Kernel Testing & Dependability Micro-conference will be taking place at LPC 2023, to discuss testing and dependability related topics.

Please submit proposals for discussion via LPC submission system.

The Linux Plumbers 2023 Kernel Testing & Dependability track focuses on advancing the current state of testing of the Linux Kernel and its related infrastructure. The main purpose is to improve software quality and dependability for applications that require predictability and trust.

The goal of this micro-conference is making connections between folks working on similar projects, and help individual projects make progress.

This track is intended to promote collaboration between all the communities and people interested in the Kernel testing & dependability. This will help move the conversation forward from where we left off at the LPC 2022 Kernel Testing & Dependability MC.

We ask that any topic discussions focus on issues/problems they are facing and possible alternatives to resolving them. The Micro-conference is open to all topics related to testing on Linux, not necessarily in the kernel space.

Suggested topics:

  • KernelCI: Topics on improvements and enhancements for test coverage
  • Growing KCIDB, integrating more sources
  • Sanitizers
  • Using Clang for better testing coverage
  • How to spread KUnit throughout the kernel?
  • Building and testing in-kernel Rust code
  • Explore ways to improve testing framework and tests in the kernelwith a specific goal to increase traceability and code coverage
  • Explore how do SBOMs figure into dependability?

List of accomplishments this past year after LPC 2022:

  • Developed a new, modern API for KernelCI with Pub/Sub interface
  • Added Rust coverage in KernelCI
  • KCIDB is continuing to gather results from many test systems: KernelCI, Red Hat’s CKI, syzbot, ARM, Gentoo, Linaro’s TuxSuite etc. The current focus is on generating common email reports based  on this data and dealing with known issues.
  • KFENCE is continuing to aid in detecting Out-of-bound OOB accesses, use-after-free errors (UAF),  Double free and Invalid free and so on.
  • Clang: CFI, weeding out issues upstream, etc.
  • Kselftest continues to add coverage for new and existing features and subsystems.
  • KUnit is continuing to act as the standard for some drivers and a de facto unit testing framework in the kernel
  • The Runtime Verification (RV) interface from Daniel Bristot de Oliveira was merged.

Proposals can be submitted here, by August 20th:

MC leads can be reached for question and further information::
Shuah Khan (shuah@kernel.org)
Sasha Levin <sashal@kernel.org>
Guillaume Tucker <guillaume.tucker@collabora.com>

Live Patching MC CFP

After a three-year hiatus, the Live Patching Microconference is back for 2023.

Accomplishments post 2019 Microconference:

  • API enhancements: Livepatch pre/post (un)patch callback system state change tracking was added in v5.5. The new API enhances the safety of cumulative livepatch upgrades [v5.5]
  • KLP-relocations: To facilitate module_disable_ro() removal, arch-specific livepatch .klp.arg sections were deprecated. Special arch section KLP-relocations (like x86 jump labels) are still supported for vmlinux cases, and are now applied at the same time as normal relocations. [v5.8]
  • Documentation: Practical information on how to implement reliable stacktraces needed by the livepatching consistency model was added [v5.12]
  • Architecture: Implemented Power32 support [v5.18]
  • KLP-relocations: To support target module reloading, clear KLP-relocations in livepatch modules when their target module is unloaded. This satisfies a module loader sanity check when resolving relocations on the next target module load (x86_64 only) [v6.3]

Discussion Topics

The following topics have been proposed:

  • Shadow variables are considered a livepatching power-feature that can require careful management, especially across livepatch up and downgrades. Is garbage collection or a refactoring of callbacks a  better approach to manage these resources?
  • klp-relocations were originally introduced to resolve livepatch / kernel and module symbol scoping issues. Recent security features like CET and IBT suggest another use case and renewed interest in having an in-tree klp-relocation build support. Is a simple conversion utility sufficient, or does said tool require greater features?
  • The livepatching kselftests consist of test scripts under tools/testing/selftests and associated livepatch module code in lib/. Consolidating these under the former offers better flexibility in templating the livepatch modules as well as the benefits of building them out-of-tree.  Are there any outstanding blockers to implement these changes?
  • arm64 support is moving forward on several fronts: toolchain, reliable stack unwinding, user space, etc.  The Toolchains MC plans to address topics like CFG in ELF and handling of noinstr functions.  What issues remain in livepatching and the kernel at large to fully support arm64?
  • Rust looks to be a hot topic at this year’s LPC.  Its impact on kernel livepatching is relatively open ended as Rust code has only recently been merged in small parts.  That said, which features, problems, patchsets should we be paying attention to as we all learn more about this newly supported kernel language?

These potential discussion topics were selected from on-going livepatching mailing list threads, but additional livepatching related topics are welcome for consideration as well. For ideas on what makes for an ideal Microconference topic, checkout this post.

Build Systems MC CFP

In the Linux ecosystems, there are many ways to build all the software used to put together a running system. Whether it’s building all the binary packages for a binary Linux distribution, using a source-based distribution, or building an embedded system from scratch, there are a lot of shared challenges which each system solves in its own way.

This microconference is a way to get people who work on disparate build systems to discuss common problems and possible shared solutions across the entire problem space. The kinds of topics we want to discuss are the following:
  • Bootstrapping the build system
  • Cross building software
  • Make, autoconf, and other similar software build tools
  • Package build systems, bitbake, emerge/portage, pacman, etc
  • Packaging formats
  • Managing software with language-specific package managers
  • Patch sharing
  • Building within a container
  • Build systems for building containers
  • License gathering and verification
  • Security updates
  • SBOMS
  • Software chain-of-trust
  • Repeatable builds
  • Documentation and education
  • Finding the next generation of maintainers
  • Build-system visibility within the wider Plumbers attendeesThis is not a definitive list, and you are free to post abstracts for other related topics.
Build Systems micorconference would like to gather representatives (developers and maintainers) from all the various build systems and related technologies. This is not a definitive list of possible attendees.
  • Android
  • Arch Linux
  • Buildroot
  • ChromeOS
  • Gentoo
  • OpenEmbedded
  • OpenWRT/LEDE
  • Yocto Project
  • Other traditional Binary Packaged distributions
For more information, feel free to contact the MC Leads:
Philip Balister <philip@balister.org>
Please follow the suggestions from this BLOG post when submitting a CFP for this track.
Submissions are made via LPC submission system, selecting Track “Build Systems MC”
Diamond Sponsor

Platinum Sponsor


Gold Sponsors



Conference Services Provided by