Quality in embargoed patches
summary
Embargoed fixes routinely land with minimal testing, produce regressions and performance cliffs, and sometimes break unrelated platforms; the concrete proposal is to create a dedicated embargo test lab (secure, NDA-backed machines hosted by vendors or Linux Foundation projects), require a mitigation to be code-complete weeks before disclosure, and run both the vendor‑supplied regression tests plus broad suites (kselftest, KUnit, workload harnesses) via a standardized Kernel CI API with results exposed to a restricted list and a staged rollout for fleet-scale validation.
AI-written summary · about
chapters (9)
- 0:00Introduction to embargoed patches
- 1:05Problems with embargoed fixes
- 3:53Testing challenges for embargoed code
- 8:13Infrastructure and ownership for testing
- 12:26Linux Foundation's role in testing
- 15:41Hardware access and geopolitical issues
- 18:53Standardizing test APIs and formats
- 20:22Unknown tests and use cases for hardware bugs
- 23:36Q&A and final remarks
related talks
26mImprove Upstream Code Quality by Bringing Testing to Patch Level
21mThe emerging of the virtual QA team for Linux kernel
30mHow Can We Effectively Test Transient Execution Mitigations?
14mThe Power of Backports : Business Impact and Automation Strategies
42mRawhide packages gating, things got real, for real
39mThe Life of a Kernel Bugfix
17mSustaining Yesterday’s Linux: Delivering Security for Today’s Workloads
19mUpstream kernel CI using patchew and TDC