Slide 1

Slide 1 text

1 BPF in Stable Kernels LSF/MM/BPF Summit 2025 Shung-Hsi Yu

Slide 2

Slide 2 text

- Purpose - Stable Kernel - Challenges & Improvements - Remarks - Discussion 2 Agenda

Slide 3

Slide 3 text

1. Have a better guarantee of BPF quality in stable kernels - stable kernels have the largest user base - bug-free experience - vulnerability-free 2. Find other that are interested/have stake in BPF in stable 3 Purpose Discuss How To Provide

Slide 4

Slide 4 text

4 Stable Kernels Definition

Slide 5

Slide 5 text

- stable/linux.git - Distro Kernels - Vendor Kernels - Android Common Kernel - Civil Infrastructure Platform Kernel 5 Stable Kernels

Slide 6

Slide 6 text

- stable/linux.git - non-LTS (every release) - LTS (v6.12, v6.6, v6.1, v5.15, v5.10, …) 6 Stable Kernels Definition

Slide 7

Slide 7 text

- Distro Kernels - RHEL, SLES, Ubuntu, … (LTS-like, alphanumeric order) - Vendor Kernels - Hardware-specific (e.g. SteamOS, probably LTS-based) 7 Stable Kernels Definition

Slide 8

Slide 8 text

- Android - Android Common Kernel (LTS-based, extended by ? yrs) - Civil Infrastructure Platform cip/linux-cip.git - SLTS (LTS-based, extended by ~8 yrs) 8 Stable Kernels Definition

Slide 9

Slide 9 text

- stable/linux.git - LTS (v6.12, v6.6, v6.1, v5.15, v5.10, …) - large user base - common ground - more code deviation (compared to non-LTS stables) 9 Stable Kernels Focus

Slide 10

Slide 10 text

10 LTS in stable/linux.git

Slide 11

Slide 11 text

- How does a patch ended up in stable/linux.git? (i.e. how are patch selected for backporting) 1. CCed [email protected] 2. AUTOSEL selection (usually those that had Fixes tag) 3. Ask stable team explicitly for backporting 11 LTS in stable/linux.git

Slide 12

Slide 12 text

- Additional criterias 1. Patch applies as-is (e.g. no merge conflict) 2. Builds after applying 12 LTS in stable/linux.git

Slide 13

Slide 13 text

- Assumption 1. Patch works as-is, or 2. If it doesn’t, will be caught by stable release testers Tested-by: Some One 13 LTS in stable/linux.git

Slide 14

Slide 14 text

14 Challenges

Slide 15

Slide 15 text

- Does it really work? - patches receives less thorough review, if any - (AFAIK) not tested with BPF selftests - v6.6 BPF selftests fails to compile & pass - does it changes existing behavior (verifier rejection)? 15 Challenges Elephant in the Room

Slide 16

Slide 16 text

- Test LTS in BPF CI (and Agni, etc.) - v6.12 (hopefully v6.6 & v6.1 as well) - Error reported to where? - stable mailing list - interest group / volunteer (not necessary ML) 16 Improvements A Low Hanging Fruit?

Slide 17

Slide 17 text

- Less-than-idea BPF selftests coverage - most fixes has a corresponding BPF selftests test case - while a fixes is add to stable, such test case are ignored 17 Challenges

Slide 18

Slide 18 text

- Backport BPF selftests - Greg would take them - Finding the commits takes time and effort 18 Improvements Nice to Have

Slide 19

Slide 19 text

- Not all fixes are backported - patch may fail to apply, build, or work due to missing dependencies 19 Challenges

Slide 20

Slide 20 text

- How does a patch ended up in stable/linux.git? 1. CCed [email protected] 2. AUTOSEL selection (usually those that had Fixes tag) 3. Ask stable team explicitly for backporting 4. Send patch to stable mailing list - the only way to send modified patches 20 LTS in stable/linux.git

Slide 21

Slide 21 text

- Not all fixes are backported - patch may fail to apply, build, or work due to missing dependencies 21 Challenges

Slide 22

Slide 22 text

- Not all fixes are backported - patch may fail to apply, build, or work due to missing dependencies - fix as side effect of feature, e.g. support non-r10 register spill/fill to/from stack in precision tracking 22 Challenges

Slide 23

Slide 23 text

- Backport missing fixes 23 Improvements The Unlikely Ones

Slide 24

Slide 24 text

- Backport missing fixes - time-intensive, mechanical work - more likely to run into issues - if nobody complains, then it probably doesn’t matter - unless it’s security vulnerability (80%+) 24 Improvements The Unlikely Ones

Slide 25

Slide 25 text

25 Remarks

Slide 26

Slide 26 text

- Problems in stable often aren’t BPF-specific - BPF-specific low hanging fruits - Quality of BPF in stable kernels ultimately depends on the quality of bpf-next - diverting existing maintainers’ attention - get others involved 26 Remarks

Slide 27

Slide 27 text

- Technical Improvements 1. Test LTS in BPF CI 2. Backport BPF selftests 3. Backport missing fixes 27 Remarks Overview

Slide 28

Slide 28 text

- Non-technical Improvements 1. Find volunteers/stakeholders/interested 2. ? 28 Remarks Overview

Slide 29

Slide 29 text

29 ?

Slide 30

Slide 30 text

- Run bpf-next BPF selftests on stable kernels? - kABI breakage due to struct bpf_verifier* changes - LTS v6.1 need some more love? - Where to share stable backports after stable/linux.git branch reach EOL? - Possibility of aligning BPF subsystem across the Stable Kernels 30 Miscellaneous