OSS + ELC EU 2026

While most instructions the Linux kernel executes come from a standard compiler like GCC or Clang, the kernel can also patch itself at runtime: ftrace, kprobes, eBPF programs... Debugging these runtime-generated instructions is a whole new challenge, as we lack the usual debug data: symbol names, offsets, debug info. Fortunately, we can adapt our tooling to observe them.

This talk explores practical debugging techniques for runtime-generated instructions, using eBPF as a concrete example: when a user loads an eBPF program, the kernel's JIT compiler emits native machine code. After a brief eBPF introduction, we will debug these programs and the surrounding generated code (trampolines, dynamic instrumentation, verifier patches...). Starting from standard debug information in bare binaries or exposed at runtime, we will gradually build up our toolkit: running a custom kernel under QEMU, taking control with GDB, debugging userspace and kernel space together, adding TUI and GDB scripts, and finally stepping through raw machine instructions. Aimed at developers familiar with C/kernel
development, attendees will gain hands-on techniques and confidence for any kind of low-level analysis.

Every Linux engineer knows the moment: a process is misbehaving, so you reach for strace, get a wall of text, and start grepping. It works - until the problem spans multiple processes, the output is too much to read, or you need to correlate what a process did to the system with what it did on the network. strace and bpftrace are excellent at capturing syscalls. They give you much less help analyzing them.

Stratoshark, the Wireshark Foundation's newer tool, takes a different approach: it captures system calls and logs system-wide through the Falco libraries, then hands them to the same analysis engine that has served packet analysts for 25 years — display filters, coloring rules, follow-stream views, time correlation, and shareable capture files.

In this talk I'll show, live, how a Wireshark user's instincts transfer directly to syscall troubleshooting, where Stratoshark beats reaching for strace, and — just as importantly — where the older tools are still the right call. Expect real debugging scenarios, honest limitations, and a clear picture of when this newer approach earns its place in your toolbox.

In April 2026, the Civil Infrastructure Platform (CIP) reached a historic milestone—its 10th anniversary—and delivered on its founding promise: a full 10-year support lifecycle for the CIP Super Long-Term Support (SLTS) Kernel. CIP is believed to be the first open-source community to sustain a 10-year kernel support commitment in practice. It is also the first OSS project to conform to both IEC 62443-4-1 and 4-2.
At OSS Japan in December 2025, we looked "towards" this decade. This talk marks its completion—and turns to the next one. AI is accelerating software development at unprecedented speed while introducing new complexity and supply-chain risk into infrastructure that must run safely for decades. How do we sustain trust, security, and longevity when the software landscape shifts daily?
We will revisit the strategies and engineering behind CIP's 10-year support and security certifications, then examine why this proven framework matters more than ever in the AI era. Attendees will leave with practical insight into protecting supply-chain integrity, navigating compliance, and building open-source foundations that endure technological disruption.

You maintain a kernel fork. Maybe it's an LTS branch, a distro kernel, or an embedded platform. You push a patch and wonder, will it boot? Will it break something that worked yesterday? Most CI solutions either need a full test lab you can't afford, or give you a virtme smoke test that won't catch real failures.

We faced the same problem. 5 engineers, multiple kernels, no test lab budget. So we built a kernel CI pipeline that does real boot, real tests using nothing but GitHub Actions.
The key difference from other CIs is that we don't use virtme. We boot a full disk image. The bugs that only show up during a real boot, module loading failures, get caught here.

In this talk, I'll walk through how we boot real disk images in CI, run test suites against every patch, and catch regressions before they hit your branch, all without a test lab.
I'll explain the pipeline design, demo the full cycle from patch to test results, and cover what it takes to go from "nothing" to a working multi-arch kernel CI.
We're also making this pipeline portable and open for others to use.

If you maintain a kernel and want real integration testing without the overhead of a test lab, this talk is for you.

Every time you write data to or read data from a storage device in Linux, multiple caches are involved: the page cache (located in the memory) on the VFS layer, different kinds of caches on the storage devices (SSDs, HDDs) and controllers, and maybe filesystem-level or device mapper-level caches, too.

The caches help you to boost the I/O performance, but they also increase the risk of data loss in case of a sudden power outage. Understanding and configuring these caches correctly can be challenging, in particular if you are running virtualized systems and you have to set QEMU caching parameters (writeback, none, writethrough, directsync, unsafe), too.

In this talk, Werner explains how these caches work and shows you how to tune them for optimal performance while still being safe in case of a power outage.