24-28 August 2020
Canada/Newfoundland timezone

Accepted Microconferences

LPC 2020  Microconferences

 


Containers and Checkpoint/Restore MC

The Containers and Checkpoint/Restore MC at Linux Plumbers is the opportunity for runtime maintainers, kernel developers and others involved with containers on Linux to talk about what they are up to and agree on the next major changes to kernel and userspace.

Common discussions topic tend to be improvement to the user namespace, opening up more kernel functionalities to unprivileged users, new ways to dump and restore kernel state, Linux Security Modules and syscall handling and more. 

Last year's success has prompted us to reprise the microconference this year.

Topics we would like to cover include:

  • Next steps for uid/gid shifting for mounts and namespaces
  • pidfds and their use for containers
  • Handling of new mount APIs and unprivileged containers
  • Solutions to transition from CgroupV1 to CgroupV2
  • Use and limitations of the time namespace
  • Hardware assisted isolation of processes/containers
  • More to be added based on CfP for this microconference

If you are interested in participating in this microconference and have topics to propose, please use the CfP process. More topics will be added based on CfP for this microconference.

MC leads


Scheduler MC

The scheduler is an important functionality of the Linux kernel as it decides what gets to run, when and for how long. With different topologies and workloads this is no easy task to give the user the best experience possible.

Potential topics for this year include:

  • Core Scheduling - How do we merge?
  • Capacity Awareness - For busy systems
  • Interrupt Awareness
  • Proxy Execution - More cases
  • Latency Nice - What interfaces do our use cases like?
  • Load Balancing
  • NUMA load balancing
  • Status of the rework (that went in v5.5), new regressions
  • Formal specification of SCHED_DEADLINE
  • Flattening CPU RQ hierarchy

If you are interested in participating in this microconference and have topics to propose, please use the CfP process. More topics will be added based on CfP for this microconference.

MC leads


Real-Time MC

Since 2004 a project has improved the Real-time and low-latency features for Linux. This project has become know as PREEMPT_RT, formally the real-time patch. Over the past decade, many parts of the PREEMPT RT became part of the official Linux codebase. Examples of what came from PREEMPT_RT include: Mutexes, high-resolution timers, lockdep, ftrace, RT scheduling, SCHED_DEADLINE, RCU_PREEMPT, generic interrupts, priority inheritance futexes, threaded interrupt handlers, and more. The number of patches that needs integration has been reduced in the last years, and the pieces left are now mature enough to make its way into mainline Linux. For real, this year could possibly be the year PREEMPT_RT is merged™!

In the final lap of this race, the last patches are on the way to be merged, but there are still some very few pieces missing. When the merge occurs, the PREEMPT_RT will start to follow a new pace: the Linus one. So, it is possible to raise the following discussions:

  • The status of the merge, and how can we resolve the last issues that block the merge;
  • How can we improve the testing of the -rt, to follow the problems raised as Linus tree advances;

What’s next? Possible topics:

  • Status of the PREEMPT_RT Merge
  • Merge – what is missing and who can help?
  • New tools for PREEMPT_RT analysis.
  • How do we teach the rest of the kernel developers how not to break PREEMPT_RT?
  • Stable maintainers tools discussion & improvements.
  • The usage of PREEMPT_RT on safety critical-systems: what do we need to do?
  • Interrupt threads are RT and are not protected by the RT Throttling. How can we prevent interrupt thread starvation from a rogue RT task?

If you are interested in participating in this microconference and have topics to propose, please use the CfP process. More topics will be added based on CfP for this microconference.

MC leads

 


Kernel Dependability & Assurance MC

Linux is now being used in applications that are going to require a high degree of confidence that the kernel is going to behave as expected. Some of the key areas we’re seeing Linux now start to be used are in medical devices, civil infrastructure, caregiving robots, automotives, etc.

The kernel development is producing high-quality kernels, release by release, with an increasing speed of change and arguably also increasing software quality. The process of kernel development has been adapting to handle the increasing number of contributors over the years and ensure a sufficient software quality.

The kernel processes have evolved over time to produce a high quality kernel that is able to react to security and bug fixes in an effective manner.

However there are a few areas to explore as it pertains to safety critical space:

  • What sort of uptime can we count on?
  • How can we identify when safety analysis needs to be redone after bug fixes have been applied?
  • How can we efficiently assess whether the safety analysis needs to be reworked for a released product based on a specific version of the linux kernel, after a bug fix has been applied to the current release?
  • Are the system requirements that Linux is included in being satisfied?
  • Do we have adequate tooling and processes to help us answer these questions efficiently, so that Linux can be used in high assurance systems with the right levels of analysis to build up confidence that it is safe, and that the dependability properties are maintained over time.

In short, we would like this mini-conf to bring the safety critical user community and the kernel community together to start a dialogue and collaboration on making sure that the kernel is fit to be used in safety-critical systems and that questions from the safety community wrt. software quality can be answered adequately.

Topics:

  1. Kernel Quality Assurance beyond Testing and CI?
  2. Understanding the Users’ Expectations on Software Quality for business-critical systems
    1. Define safety requirements for overall kernel: features, tests etc.
    2. Define run-time characteristics and requirements
  3. Identify missing features necessary to operate in safety critical environments.
    1. Discuss safety features
  4. Regression Testing for safety: Identify configurations and tests critical and important for safety quality and dependability
    1. Discuss and identify gaps in tests.
    2. Add tests and add configurations to existing test rings.
  5. Understanding the Kernel Development Organisation and Management
  6. Assessing, Measuring and Evaluating the Development Process

MC leads


Testing and Fuzzing MC

The Testing and Fuzzing microconference focuses on advancing the current state of testing and validation of the Linux Kernel, with a focus on encouraging and facilitating collaboration between testing projects.

Suggested Topics:

  • Next steps for KernelCI (data formats, dashboards, etc)
  • Structured data feeds for cross-project collaboration
  • Integration with kernel.org tools (e.g. b4)
  • Continued defragmentation of testing infrastructure
  • Better sanitizers: KASAN improvements, KCSAN fallout, future plans.
  • Better hardware testing, hardware sanitizers: how the USB fallout was handled, are there efforts to poke at something besides USB?
  • Improving real-time testing: is there any testing for real time at all?

MC leads