stonking sauce-review — 145 patches on v7.2-rc2

Per-patch analysis

Group A — Packaging & build infrastructure (14 patches)

1. d2895c3c7c0c — UBUNTU: SAUCE: (no-up) Add support for ubuntu/ dir — 🟢 KEEP (High)

• Q1 Relevant? Yes — the ubuntu/ Kbuild/Kconfig plumbing is the mount point for all out-of-tree carries; in stonking it hosts ubuntu-host and the new igh-ecat import.
• Q2 Upstream version? None; inherently Ubuntu-specific (no-up).
• Q3 Other carriers? Every Ubuntu kernel (questing ✓, resolute ✓; jammy has an equivalent older form). No non-Ubuntu distro uses this mechanism (Debian/Fedora/SUSE patch drivers in-tree or use dkms/akmods instead).
• Q4 Dropped anywhere? No. Ubuntu has shrunk its contents over the years (aufs, zfs, hio… removed) but the mechanism stays.
• Q5 Regressions? None known; touches only Kbuild/Kconfig includes.
• Q6 Better fix? dkms is the alternative for out-of-tree code but changes support/signing semantics; for signed, always-available modules the in-tree dir is the working design.
• Q7 Ignore: yes — never in changelog.
• Q8 Nothing.

2. be6d9cf63a93 — (no-up) add support for installed header files to ubuntu directory — 🟡 REVIEW (Medium)

• Q1 Relevant? Questionable. Added in 2010 for aufs headers (LP: #684666). Today ubuntu/include/ contains only Kbuild + README — there are no headers left to install; the Makefile hunk is a no-op in practice.
• Q2 Upstream version? N/A.
• Q3 Other carriers? questing ✓, resolute ✓, jammy ✓ (inertia).
• Q4 Dropped anywhere? No, but its reason (aufs) left the kernel years ago.
• Q5 Regressions? None; dead code.
• Q6 Better fix? If a ubuntu/ module ever needs uapi headers again the hunk is trivially re-addable.
• Q7 One-line Makefile change; zero maintenance cost, zero function.
• Q8 Confirm linux-libc-dev contents show no ubuntu/include files (expected) — then this is safely droppable as a cleanup.

3. 4fe748186e36 — (no-up) version: Implement version_signature proc file — 🟢 KEEP (High)

• Q1 Relevant? Yes — /proc/version_signature is Ubuntu userspace ABI (used by uname26 tooling, apport, ubuntu-drivers, countless scripts to learn the exact Ubuntu kernel version + upstream stable level).
• Q2 Upstream version? No; upstream rejected distro-version proc files long ago (/proc/version is the canonical interface).
• Q3 Other carriers? All Ubuntu kernels since ~Hardy (questing ✓ resolute ✓ jammy ✓).
• Q4 Dropped anywhere? No.
• Q5 Regressions? None; had an FTBFS fix folded in historically.
• Q6 Better fix? None realistic — removing it would break userspace.
• Q7 Interacts with init/version-timestamp.c; watch that file at rebases (it changed in 6.x).
• Q8 Nothing.

4. 829ba3abe4a8 → analysed in Group B (cdrom)

4A. 6f493de97c09 — (no-up) kconfig: in debug mode some 0 length message prints occur — 🟢 KEEP (High)

• Q1 Relevant? Yes, technically: mainline scripts/kconfig/lkc.h still has assert(len != 0) in xfwrite() (verified in v7.2-rc2+), and zconfdump() still exists; the assert can still fire when kconfig parser debugging (cdebug) is enabled.
• Q2 Upstream version? No — never submitted as far as the record shows.
• Q3 Other carriers? questing ✓ resolute ✓ jammy ✓.
• Q4 Dropped anywhere? No.
• Q5 Regressions? None possible in normal builds (affects a debug-only path).
• Q6 Better fix? Upstreaming the guard (or a fix to the empty-string print sites) — trivial one-liner, good first-patch candidate for kbuild list.
• Q7 Only bites developers running kconfig with debug enabled; invisible otherwise.
• Q8 Nothing.

5. 841354fcdab0 — (no-up) Makefile: replace rsync with tar — 🟢 KEEP (Medium)

• Q1 Relevant? Yes. Mainline headers_install still uses rsync (Makefile:1487 in v7.2-rc2+). The original trigger — rsync removed from the i386 archive in lunar — still applies because linux-libc-dev is built for i386 from this source via headers_install; the patch also drops an entire build-dep on all arches.
• Q2 Upstream version? No. Upstream kept rsync; no merged tar-based replacement found.
• Q3 Other carriers? questing ✓ resolute ✓ (jammy predates lunar's rsync removal and doesn't carry it).
• Q4 Dropped anywhere? No.
• Q5 Regressions? None known; semantic difference vs rsync (only *.h copied, no dir metadata) has been in production since lunar.
• Q6 Better fix? Could be proposed upstream as a portability win (tar is in the base toolset, rsync is not); or drop once i386 linux-libc-dev is finally discontinued and rsync is acceptable as a build-dep.
• Q7 Self-described "for now, until we decide to drop i386 completely" — that decision still hasn't happened.
• Q8 Re-check when Ubuntu drops i386 binary packages entirely.

6. db3deab2f436 — (no-up) do not remove debian directory by 'make mrproper' — 🟢 KEEP (High)

• Q1 Relevant? Yes — protects developers' debian/ dirs on local make mrproper; debian is in the top Makefile's generated-dirs cleanup because Ubuntu adds it.
• Q2/Q4 N/A (Ubuntu-only problem). Q3 questing ✓ resolute ✓.
• Q5 Regressions? None; strictly less deletion.
• Q6 Better fix? None needed. Q7 Authored by Masahiro Yamada during his Canonical time — kbuild maintainer's own workaround. Q8 Nothing.

7. bac2251fe625 — (no-up) export some symbols for powerpc — 🟡 REVIEW → likely DROP (Medium)

• Q1 Relevant? Doubtful. Exports pci_find_hose_for_OF_device and early_find_capability. The only in-tree user that would need the export is mpc85xx_edac (32-bit FSL platform — not built on Ubuntu's ppc64el-only powerpc config). No ubuntu/ or packaging consumer. The original out-of-tree consumer (Trusty-era, likely IBM/OFED or lustre dkms) is lost to history.
• Q2 Upstream version? Mainline deliberately does not export these.
• Q3 Other carriers? questing ✓ resolute ✓ jammy ✓ — pure inertia.
• Q4 Dropped anywhere? Never dropped, but never justified since Trusty either.
• Q5 Regressions? None (exports are inert if unused).
• Q6 Better fix? Identify the consumer or drop. A dkms-package archive grep (nvidia, lustre, MOFED) for these symbols would settle it.
• Q7 2-line patch, but it's exactly the kind of unexplained divergence SAUCE review exists to kill.
• Q8 Grep current dkms packages in the archive for the two symbols; if clean → drop next cycle.

8. d2e969bbcf98 — (no-up) Add vmlinux.strip to BOOT_TARGETS1 — 🟢 KEEP (High)

• Q1 Relevant? Yes — load-bearing. debian.master/rules.d/ppc64el.mk sets build_image = vmlinux.strip; this patch is what makes make vmlinux.strip a valid top-level boot target on powerpc. (The commit message's "I'm not sure why" is answered by the packaging.)
• Q2 Upstream version? No; upstream BOOT_TARGETS1 = zImage zImage.initrd uImage only.
• Q3 Other carriers? questing ✓ resolute ✓ jammy ✓.
• Q4 Dropped anywhere? No. Q5 None.
• Q6 Better fix? Could plausibly go upstream (vmlinux.strip is produced by arch/powerpc/boot already), or the packaging could invoke the boot Makefile target directly — but not worth churn.
• Q7 Dropping it breaks the ppc64el image build outright — do not remove casually.
• Q8 Add a comment in-tree pointing at ppc64el.mk so the "not sure why" never recurs.

9. 26883365fb21 — tools -- add ability to disable libbfd — 🔴 DROP (High)

• Q1 Relevant? No longer. The SAUCE adds a HAVE_NO_LIBBFD knob forcing feature-libbfd := 0. Since v6.5 mainline gates all libbfd linking behind BUILD_NONDISTRO (Makefile.config:887,951 in v7.2-rc2+), default off, precisely because of the binutils licence/ABI problem this patch solved (LP: #1748922).
• Q2 Upstream version? Yes — the BUILD_NONDISTRO mechanism is the upstream version of this policy.
• Q3 Other carriers? questing ✓ resolute ✓ jammy ✓ (jammy, on 5.15, genuinely still needs it).
• Q4 Dropped anywhere? Equivalent distro hacks disappeared when BUILD_NONDISTRO landed.
• Q5 Regressions? None, but it's dead weight: nothing in stonking's debian/rules.d sets HAVE_NO_LIBBFD (verified — the perf build invocation passes NO_LIBPERL=1 WERROR=0 etc., no libbfd knob), and without BUILD_NONDISTRO libbfd is off anyway.
• Q6 Better fix? Rely on upstream default; nothing to do.
• Q7 Doubly dead: knob unset and redundant. Safe drop for ≥6.5 kernels; keep in jammy.
• Q8 After dropping, confirm linux-tools perf binary still doesn't link libbfd*.so (ldd).

10. 954aa64f8332 — Add selective signing of staging modules — 🟢 KEEP (High)

• Q1 Relevant? Yes — Ubuntu policy: staging modules are unsigned (hence unloadable under Secure Boot lockdown) unless listed in debian/signature-inclusion.
• Q2 Upstream version? No; upstream signs all-or-nothing (CONFIG_MODULE_SIG_ALL).
• Q3 Other carriers? questing ✓ resolute ✓ jammy ✓. Fedora/SUSE sign everything instead.
• Q4 Dropped anywhere? No.
• Q5 Regressions? The known sharp edge is by design: a staging module absent from signature-inclusion won't load under Secure Boot — occasionally surfaces as user bug reports.
• Q6 Better fix? Upstream MODULE_SIG_ALL + per-module allowlist doesn't exist; this stays.
• Q7 Pairs with 1c4bede75959 (below) — treat the two as one unit at rebases (both touch scripts/Makefile.modinst).
• Q8 Nothing.

11. 1c4bede75959 — Switch to using debian/scripts/sign-module — 🟢 KEEP (High)

• Companion of #10: delegates the "sign or not" decision to debian/scripts/sign-module (verified present in stonking). Same answers as #10 across Q1–Q8: Ubuntu-only, carried by questing/resolute/jammy, no upstream analogue, no regressions. Keep as a pair.

12. 8aeb23f44eae — uapi: Fixup strace compile error — 🟡 REVIEW (Medium)

• Q1 Relevant? The divergence is live: mainline include/uapi/asm-generic/fcntl.h still guards F_GETLK64/F_SETLK64/F_SETLKW64 with __BITS_PER_LONG == 32 || __KERNEL__ (verified v7.2-rc2+); the SAUCE removes the guard so 64-bit userspace sees them.
• Q2 Upstream version? Guo Ren pushed the identical fix to V3 (Mar 2023), Acked-by Palmer Dabbelt, replied-to by Christoph Hellwig — never merged. The guard itself came from his 5.19 commit 306f7cc1e906, which is what broke strace.
• Q3 Other carriers? questing ✓ resolute ✓ (jammy predates the 5.19 regression and needs nothing).
• Q4 Dropped anywhere? Never picked up by upstream or, as far as findable, by other distros — strace fixed it on its own side instead (modern strace builds without kernel-header F_*64).
• Q5 Regressions? Risk is subtle: 64-bit apps built against Ubuntu headers can use F_*64 constants that don't exist in other distros' headers → non-portable source. No functional kernel change.
• Q6 Better fix? Since the sole motivating consumer (strace) no longer needs it, dropping restores uapi parity with mainline — recommended once a test build of the archive strace against stonking headers passes.
• Q7 SAUCE originally landed for kinetic (patchwork: Dimitri Ledkov, Sep 2022).
• Q8 Test-build strace (and ltrace) against stonking linux-libc-dev without the patch; if green, drop.

13. 894bd1caa682 — rust: Fix rustc source path for the new rustc packaging — 🟠 REPLACE (High)

• Q1 Relevant? The goal is relevant (Ubuntu's rustc ships library sources at /usr/src/rustc-<version>/library, not in the sysroot). The implementation replaces rustc --print sysroot with an awk parse of rustc --version in both rust/Makefile and scripts/rust_is_available.sh.
• Q2 Upstream version? Upstream already provides the override point: both call sites honour RUST_LIB_SRC — which the patch itself keeps as ?=.
• Q3 Other carriers? questing ✓ resolute ✓.
• Q4 Dropped anywhere? N/A (Ubuntu toolchain-packaging specific).
• Q5 Regressions? Fragile by construction: parses rustc --version output; a version-string format change or a user-supplied non-Ubuntu toolchain silently computes a bogus /usr/src/... path (breaks e.g. rustup-based local builds that don't set RUST_LIB_SRC).
• Q6 Better fix? Set RUST_LIB_SRC=/usr/src/rustc-$(rustc-version)/library in debian/rules (verified: nothing in debian/ sets it today) and drop both hunks — zero source divergence, same effect, and local non-Ubuntu toolchains keep working.
• Q7 Timo's packaging bridge; revisit each time Ubuntu's rustc packaging moves.
• Q8 Confirm the kernel's rust build path in debian/rules.d (does it even build rust today?) and implement the env-var replacement next crank.

14. db70db0a5693 — Change RISC-V target to RVA23 (riscv64a23-unknown-linux-gnu) — 🟢 KEEP (Medium)

• Q1 Relevant? Yes while stonking's riscv64 baseline is RVA23 and Ubuntu's rust toolchain uses the custom riscv64a23-unknown-linux-gnu triple: perf's rust support hardcodes RUST_TARGET_FLAGS_riscv := riscv64gc-unknown-linux-gnu upstream, which doesn't exist in Ubuntu's RVA23 rustc.
• Q2 Upstream version? No — riscv64a23-… is not an upstream rustc triple; upstream perf keeps riscv64gc.
• Q3 Other carriers? resolute ✓ (introduced there); questing ✗ (pre-RVA23), jammy ✗. No other distro (RVA23 baseline is an Ubuntu 26.x decision).
• Q4 Dropped anywhere? No.
• Q5 Regressions? Only risk: building perf with a non-Ubuntu rust toolchain on riscv64 now targets a triple it doesn't have. Niche.
• Q6 Better fix? Make RUST_TARGET_FLAGS_riscv overridable from the make command line upstream (?= or documented var) and set it from debian/rules — small upstreamable cleanup that would delete this SAUCE.
• Q7 Own-team patch (Paolo Pisati); tracks the distro-wide RVA23 transition.
• Q8 Watch upstream rust for an official RVA23 target; revisit the triple name if rustc upstream standardises one.

Group B — Legacy quirks, Dell reboot, Clear Linux, i8042 (24 patches)

B1. 829ba3abe4a8 — (no-up) cdrom -- default to not locking the tray when in use — 🟠 REPLACE (Medium)

• Q1 The policy (eject button works while mounted; udisks unmounts on media-change) is still what Ubuntu wants; optical drives are near-extinct, so impact is tiny either way.
• Q2 No. Mainline still defaults lockdoor = 1 (verified v7.2-rc2+); Ubuntu flips to 0.
• Q3 questing/resolute/jammy all carry it (2009-era, LP: #397734).
• Q4 Never picked up by other distros as a kernel patch.
• Q5 Known trade-off since day one: burners must lock explicitly; no modern reports.
• Q6 Yes — this is runtime policy, settable in userspace: ship dev.cdrom.lock = 0 in a sysctl.d snippet (procps/systemd) exactly like Ubuntu already does for fs.protected_*. Kernel patch → config file.
• Q7 The LP bug itself quotes David Zeuthen recommending the sysctl, not a kernel default change.
• Q8 Coordinate with foundations to add the sysctl snippet before dropping.

B2–B6. Dell reboot=pci quirks (5 patches, 2011 hardware)

c1c7547bf3a0 Latitude E6520 (LP: #833705) · 611e3d19813e OptiPlex 790 (LP: #818933) · b5597f51067c OptiPlex 990 (LP: #768039) · 3a913f057f4c Latitude E6220 (LP: #838402) · a0f518b6ce60 OptiPlex 390 (LP: #800660)

• Q1 Hardware is 15 years old (Sandy Bridge desktops/laptops); still boots modern kernels, but the installed base on 26.x devel kernels is ~nil.
• Q2 OptiPlex 990: yes. Mainline carries its own entry — but deliberately narrowed to DMI_BIOS_VERSION "A0" ("Dell OptiPlex 990 BIOS A0x"), because later BIOSes fixed the reboot hang. The other four models have no mainline entry.
• Q3 questing/resolute/jammy all carry all five.
• Q4 Not dropped elsewhere; never submitted upstream despite Cc: stable in one of them.
• Q5 ⚠️ For the 990 our unconditional entry sits on top of upstream's BIOS-limited one and defeats the upstream refinement — machines with fixed BIOS get forced reboot=pci anyway. That is a (mild) live conflict with mainline intent.
• Q6 Either (a) submit the remaining four to reboot_dmi_table[] (siblings are accepted upstream routinely), or (b) drop all five as extinct-hardware quirks — affected users can pass reboot=pci.
• Q7 Verdicts: b5597f51067c (990) 🔴 DROP (High) — duplicated + contradicts upstream's narrowed match. Other four: 🟡 REVIEW (Medium) — upstream them or retire them; carrying is the worst of both options.
• Q8 If keeping, consider copying upstream's BIOS-version narrowing style.

B7. c9aec7954443 — (no-up) tools/hv: add basic manual pages — 🟢 KEEP (High)

B8. bd816ab493e5 — (no-up) tools/hv/lsvmbus -- add manual page — 🟢 KEEP (High)

• Q1 Yes — linux-cloud-tools ships hv_kvp_daemon(8) / lsvmbus(8); lintian wants manpages.
• Q2 Upstream tools still ship no manpages (Debian carries its own equivalents in the hyperv-daemons packaging rather than the kernel tree).
• Q3 questing/resolute/jammy ✓. Q4 No. Q5 None (doc-only).
• Q6 Could live in the packaging instead of the source tree (as Debian does) — cosmetic difference only. Q7/Q8 Nothing.

B9. 1b2ce62c7dc6 — (no-up) hv: Supply vendor ID and package ABI — 🟢 KEEP (High)

• Q1 Yes — reports Hyper-V guest ID with vendor 0x80 (Canonical's Microsoft-assigned ID, vs generic upstream 0x8100) and embeds the Ubuntu PKG_ABI so Microsoft/Azure can fingerprint exact Ubuntu kernels. Operationally significant for Azure support.
• Q2 No; upstream intentionally reports a generic Linux ID. Q3 All Ubuntu kernels. Q4 No. Q5 None known.
• Q6 None — this is identity policy, inherently distro-specific.
• Q7 Rebase hazard: the header moved (include/hyperv/hvgdk.h) recently; watch it.
• Q8 Confirm with the Azure team the vendor ID registration is still what Microsoft expects.

B10. 6c445a625a31 — (no-up) rds_ib_send() -- prevent local pings triggering BUG_ON() — 🟢 KEEP (High) — security-load-bearing

• Q1 Yes. CVE-2012-2372: local RDS-over-IB ping can hit BUG_ON(off % RDS_FRAG_SIZE) → DoS. Mainline net/rds/ib_send.c:508 still has the unguarded BUG_ON (verified v7.2-rc2+); our guard adds !conn->c_loopback &&.
• Q2 No upstream fix ever landed (fix was lifted from RHEL srpm comparison).
• Q3 questing/resolute/jammy ✓; RHEL carried the equivalent. Debian attacks the same threat with a different lever: rds-Disable-auto-loading-as-mitigation-against-local.patch (kill module autoload, verified in sid 7.1.3-1).
• Q4 No. Q5 None in 13 years.
• Q6 Upstream the guard (trivial, CVE-referenced) — this is the textbook "should have been sent up in 2012" patch.
• Q7 RDS is a recurring CVE factory; Ubuntu ships it as a module (blacklisted by default via kmod config).
• Q8 Send upstream this cycle; nothing else.

B11. 718b3ae3a817 — (no-up) Revert "VFS: don't do protected {sym,hard}links by default" — 🟢 KEEP (Medium)

• Q1 Partially. Ubuntu kernel defaults protected_symlinks/hardlinks = 1; upstream defaults 0 and defers to userspace. Ubuntu userspace also sets both via /usr/lib/sysctl.d/99-protect-links.conf (verified) — so on any normal boot the revert is redundant; it still covers initramfs, early boot, recovery shells, and sysctl-less minimal userspaces.
• Q2 No; upstream position (Linus, 2012) is unchanged: kernel defaults off, distros turn it on.
• Q3 questing/resolute/jammy ✓; Debian and Gentoo carry the identical kernel-default flip (fs-enable-link-security-restrictions-by-default.patch, verified in sid 7.1.3-1 and genpatches 7.1) — three distros agree the kernel default belongs on.
• Q4 No. Q5 None — protections-on is the universally deployed configuration.
• Q6 Userspace-only (drop the revert) is defensible, but the kernel default is free insurance; keeping is fine.
• Q7 2-line diff, zero rebase cost. Q8 Nothing.

B12. b34a9db79557 — (no-up) Input: Cypress PS/2 Trackpad simulated multitouch — 🔴 DROP (Medium-High)

• Q1 No. Targets the Cypress PS/2 pad in the 2012 Dell XPS 13 (L322X). Modern userspace (libinput) consumes SEMI_MT + finger count natively; the simulated-contact hack existed for pre-libinput consumers that "only count contact positions".
• Q2 No. Q4 The commit itself records the rejection: "Upstream doesn't like this patch." Upstream driver (still in tree) uses SEMI_MT.
• Q3 questing/resolute/jammy ✓ (inertia).
• Q5 Fabricated coordinates for fingers ≥3 are by definition wrong data to userspace; benign historically but it's synthetic input.
• Q6 Upstream SEMI_MT + libinput is the better fix and has existed for a decade.
• Q7 13-year-old UX patch for one EOL laptop model. Q8 Nothing — drop.

B13. a6ece59cb472 — (no-up) PCI: fix system hang issue of Marvell SATA host controller — 🔴 DROP (Medium)

• Q1 No. Masks BAR0–4 of Marvell 88SE9125 so lspci resource reads don't hang. The commit orders: "Hassle someone if this patch hasn't been removed by 13.10" — thirteen years overdue.
• Q2 No; mainline has DMA-alias quirks for 9120/9123/9125/9128 but never took BAR masking.
• Q3 questing/resolute/jammy ✓ (inertia). Q4 Never anywhere else.
• Q5 Actively lossy: zeroing resources hides the device's BARs from the whole PCI core, not just sysfs reads — collateral behaviour on a working controller.
• Q6 If the hang still exists on real 9125s, the right fix is a targeted sysfs-read quirk upstream; nobody has reported it in a decade.
• Q7 Textbook expired band-aid. Q8 Optionally check Launchpad for any post-2014 reports on LP: #1159863 before dropping (none expected).

B14. 369f10a88aca — (no-up) intel_ips: blacklist ASUSTek G60JX laptops — 🔴 DROP (High)

• Q1 No. intel_ips only binds on 2010 Ironlake platforms; the G60JX is a 2010 laptop; the patch only silences a log-spam warning.
• Q2 The commit note says "upstreamed" but the blacklist is absent from mainline intel_ips.c (verified) — the note is wrong or it was dropped upstream during driver cleanups; either way mainline lives happily without it.
• Q3 questing/resolute/jammy ✓ (inertia). Q4 See Q2. Q5 None.
• Q6 N/A — the hardware and the problem left the field together. Q7/Q8 Drop; nothing to check.

B15. 17158f0a6dd2 — (no-up) add compat_uts_machine= kernel command line override — 🟢 KEEP (High) — infrastructure-load-bearing

• Q1 Yes. Launchpad builds armhf packages in 32-bit chroots on arm64 buildds; compat_uts_machine=armv7l makes uname -m under the LINUX32 personality report armv7l. Removing it breaks distro armhf builds.
• Q2 No; never submitted (upstream would likely argue for userspace/container solutions).
• Q3 questing/resolute/jammy ✓. Q4 No. Q5 None.
• Q6 Alternatives (qemu-user, per-process uname override via personality extensions) are heavier; the boot parameter is the working design.
• Q7 Coordinate with Launchpad before ever touching this. Q8 Nothing.

B16. 29967acc3581 — (no-up) cgroup: Add documentation for cgroup namespaces — 🔴 DROP (High)

• Q1 No. Adds Documentation/cgroups/namespace.txt — a directory that hasn't existed upstream since 4.10 (moved to admin-guide/cgroup-v1/); ours is the only file in it. Content describes the pre-merge 4.6 cgroupns design.
• Q2 Yes — upstream documents cgroup namespaces properly (cgroup_namespaces(7) man page; cgroup-v2 admin guide).
• Q3 questing/resolute/jammy ✓ (inertia). Q4 The doc was part of the cgroupns patchset; upstream took the code, not this doc.
• Q5 None (doc-only), but it's stale/incorrect documentation shipped in the source. Q6 Point people at man7. Q7/Q8 Drop.

B17. e642aa25ce79 — (no-up) KEYS: Support for inserting a certificate into x86 bzImage — 🟡 REVIEW (Medium)

• Q1 Unclear — this is the question to answer. Extends scripts/insert-sys-cert to patch a cert into a compressed bzImage. CONFIG_SYSTEM_EXTRA_CERTIFICATE=y (4096 bytes) is enabled on all stonking arches, so the reserved space exists, but nothing in debian/ invokes insert-sys-cert — the consumer, if any, is an external signing flow.
• Q2 Mehmet Kayaalp's (IBM) patchset was posted upstream in 2016 and never merged; upstream went the MOK/platform-keyring way for post-build trust.
• Q3 questing/resolute/jammy ✓.
• Q4 Upstream ignored it (superseded by other key-injection mechanisms).
• Q5 None known (tool code only, plus 4 KiB reserved in vmlinux).
• Q6 If the goal is "add a cert post-build", the modern answer is MOK enrolment or the .machine keyring — no image surgery.
• Q7 If no internal consumer can be named, patch and SYSTEM_EXTRA_CERTIFICATE{,_SIZE} config should go together.
• Q8 Ask the signing/cert team whether anything still injects certs into shipped bzImages; decision follows directly.

B18. 22b947e07a52 — (no-up) Add ubuntu-host module — 🟢 KEEP (High)

• Q1 Yes — /proc/ubuntu-host/esm-token feeds Ubuntu Pro/ESM tokens to containers; CONFIG_UBUNTU_HOST=m on every arch.
• Q2/Q4 No; inherently Ubuntu. Q3 questing/resolute/jammy ✓.
• Q5 None known. Q6 virtiofs/agent alternatives exist for VMs but not for the container case this serves.
• Q7 Depends on the ubuntu/ dir infra (d2895c3c7c0c). Q8 Nothing.

B19. c9d63a8896d7 — Clear Linux: i8042: decrease debug message level to info — 🟡 REVIEW (Medium, lean DROP)

• Q1 Marginal: demotes five pr_err → pr_info for i8042 probe failures, to quiet boots on keyboard-less/i8042-less machines.
• Q2 No. Upstream keeps them as errors (they are errors when a controller exists).
• Q3 questing/resolute/jammy ✓. Clear Linux carried the original.
• Q4 Clear Linux itself was discontinued by Intel in July 2025 (repos archived read-only) — the upstream-of-this-patch no longer exists.
• Q5 Downside: on machines with a real broken i8042, the failure is now buried at info level — mildly hinders debugging.
• Q6 Upstream's i8042.nokbd/ACPI-based probe already avoids most phantom-controller spam; a targeted fix would silence only the no-controller case.
• Q7 Part of a 2016 "adopt Clear Linux boot-time tweaks" batch that should be re-evaluated as a set.
• Q8 Decide the fate of all four Clear Linux patches together.

B20. af49a1c01a0a — Clear Linux: ksm-wakeups — 🟡 REVIEW (Medium, lean DROP) — latent unit bug

• Q1 Only if KSM is enabled with ≥1 s sleep (Ubuntu default: KSM off; default sleep 20 ms) — i.e. almost never.
• Q2 No; upstream KSM has since grown ksm_advisor and other batching that address wakeup cost properly.
• Q3 questing/resolute/jammy ✓; origin (Clear Linux) discontinued July 2025.
• Q4 See Q3 — originating project dead; never submitted to mainline.
• Q5 ⚠️ The patch is buggy as written: it computes msecs_to_jiffies(round_jiffies_relative(sleep_ms)), feeding milliseconds into a function that expects jiffies. At HZ=1000 (amd64/arm64) ms==jiffies so it accidentally works; at HZ=250 (armhf/ppc64el/riscv64 — verified annotations) the rounding is nonsense (harmless direction, but not what it claims).
• Q6 Upstream's KSM advisor / simply leaving sleep at defaults; if the alignment idea is worth anything it should be round_jiffies_relative(msecs_to_jiffies(sleep_ms)) — and sent upstream.
• Q7 Classic example of an unreviewed vendor tweak surviving a decade of rebases.
• Q8 Drop, or at minimum fix the unit order if kept.

B21. 219bf5e37fdf — Clear Linux: Initialize ata before graphics — 🟡 REVIEW (Medium, lean DROP)

• Q1 Doubtful. Reorders drivers/Makefile so GPU links after ATA for boot-time parallelism. With async probe, initcall reordering value is unmeasured for ~8 years; NVMe (not ATA) is the common boot disk.
• Q2 No. Q3 questing/resolute/jammy ✓; Clear Linux (origin) discontinued 7/2025. Q4 See Q3.
• Q5 Link-order changes are a classic source of subtle init-dependency breakage at rebases (comment in the moved hunk itself warns about AGP-vs-DRM ordering); no active reports.
• Q6 Measure boot with/without on a SATA machine; upstream driver_async_probe or fw_devlink are the modern levers.
• Q7 Rebase friction: this file changes upstream regularly. Q8 Benchmarks or drop.

B22. fd70a0564e70 — Clear Linux: init: do_mounts: recreate /dev/root — 🟡 REVIEW (Medium, lean DROP)

• Q1 Barely. Creates a /dev/root node in the initramfs-less mount path. Ubuntu always boots with an initramfs (root mounted by initramfs, not mount_root()), so the hunk is dead code on every shipped configuration.
• Q2 No; upstream consensus is /dev/root is legacy (udev stopped creating it years ago; tools use /proc/self/mountinfo).
• Q3 questing/resolute/jammy ✓; Clear Linux (origin) discontinued. Q4 See Q3.
• Q5 None (dead path). Q6 N/A. Q7 init/do_mounts.c gets reworked upstream repeatedly — recurring rebase cost for a dead path. Q8 Drop with the Clear Linux batch.

B23. 9d87d62395cc — Input: i8042 - fix the selftest retry logic — 🟢 KEEP (Medium-High)

• Q1 Yes — the upstream bug is still there (verified v7.2-rc2+): i8042_controller_selftest() returns -ENODEV inside the retry loop on command timeout, so the "5 tries" comment is a lie on fragile systems (LP: #1866734, s2idle wake keyboard loss).
• Q2 No — vicamo's 2020 submission to linux-input (20200310033640.14440-1) stalled without a reply; nothing equivalent has landed since.
• Q3 questing/resolute/jammy ✓. Q4 Not merged upstream — apparently ignored, not rejected.
• Q5 None known in 6 years of Ubuntu carriage; also fixes the off-by-one (loop ran 6 times).
• Q6 The patch is the right shape; the better outcome is getting it merged — re-send to linux-input.
• Q7 Own-team patch (vicamo/ppisati sign-offs). Q8 Re-submit upstream this cycle.

B24. 469360abb038 — Input: i8042 - add dmi quirk — 🟠 REPLACE (Medium) (+ companion b5ff5245396c — 🟢 KEEP-with-parent)

• Q1 The problem (Dell Precision 5550: EC chokes on Sentelic probe → 10 s keyboard delay after s2idle) is real for that platform; hardware still in the field.
• Q2 Upstream now has the proper mechanism: SERIO_QUIRK_NOAUX in drivers/input/serio/i8042-acpipnpio.h (verified, 8 users) — but Precision 5550 is not listed there.
• Q3 questing/resolute/jammy ✓. Q4 AceLan's 2021 lkml submission wasn't merged; upstream later built the acpipnpio quirk table instead — our bespoke i8042_quirks[] DMI table duplicates infrastructure.
• Q5 The SAUCE originally introduced a modpost section mismatch — fixed by follow-up b5ff5245396c (which lives and dies with this patch).
• Q6 Migrate: one-line SERIO_QUIRK_NOAUX entry for Precision 5550 in upstream's table, submit to linux-input, then drop both SAUCE commits.
• Q7 Two commits maintained where one upstream line would do.
• Q8 Test on a Precision 5550 (or at minimum boot-test) when migrating.

Group C — Lockdown series + integrity/keys/IMA (18 patches)

C0. Series-level context (applies to all 13 (lockdown) patches)

The (lockdown) set implements automatic kernel lockdown when booted under Secure Boot

(x86 EFI, arm64 EFI, s390 secure IPL, PowerNV secure boot). The generic lockdown LSM is

upstream since v5.4, but the auto-trigger from Secure Boot was explicitly refused by Linus

(2018–2019, David Howells' series; Matthew Garrett's lockdown landed only after the EFI

coupling was stripped). Consequently every major Secure Boot distro carries this out of tree:

Fedora/RHEL (gitlab.com/cki-project/kernel-ark — the literal origin of our cherry-picks,

each marked Upstream Status: RHEL only), Debian (features/all/lockdown/ patch set),

SUSE (equivalent patches), Ubuntu. kernel-ark still actively maintains the set — the

newest member of our copy (CVE-2025-1272 fix) is from Jan 2025. Mainline v7.2-rc2+ still has

no EFI_SECURE_BOOT flag (verified) — nothing to rebase onto. Treat as one unit at rebases.

Cross-distro sweep 2026-07-09: verified current in Debian sid (features/all/lockdown/, 4 patches

incl. arm64) and SUSE kernel-source master (lockdown hook, EFI_SECURE_BOOT flag, SB lockdown,

integrity-level, arm64 — plus SUSE's own lockdown-fix-kernel-lockdown-enforcement-issue-when-secure.patch,

their counterpart to our CVE-2025-1272 fix).

C1. f1a1eab96f2a — (lockdown) Add efi_status_to_str() and rework efi_status_to_err() — 🟢 KEEP (High)

• Q1 Yes — helper used by the series' error reporting. Q2 No; RHEL-only. Q3 Fedora/RHEL (origin), Debian/SUSE equivalents. Q4 Never proposed seriously upstream. Q5 ⚠️ Shipped for years with swapped bsearch() arguments — found and fixed by Canonical (1c8126346708, see C11); keep the two together. Q6 N/A. Q7 Pure infrastructure. Q8 Nothing beyond C11 pairing.

C2. ab87aa21ce23 — (lockdown) Make get_cert_list() use efi_status_to_str() — 🟢 KEEP (High)

• Cosmetic consumer of C1; same carrier/provenance answers. No issues. Keep with series.

C3. 1bd985289b69 — (lockdown) security: lockdown: expose a hook to lock the kernel down — 🟢 KEEP (High)

• Q1 Yes — the entry point the arch triggers call. Q2 Reworked within our own stack by 1bed80283434 (C10), which de-LSM-hooks it; final code shape is the kernel-ark current one. Q3/Q4 As C0. Q5 The original hook form silently broke on v6.12+ (LSM init reorder) — that was CVE-2025-1272, fixed by C10. Q6 C10 is the better version, already applied on top. Q7 Series-internal churn candidate for squashing at next rebase. Q8 Nothing.

C4. 8b5832d394e0 — (lockdown) efi: Add an EFI_SECURE_BOOT flag — 🟢 KEEP (High)

• Q1 Yes — foundation flag (efi_enabled(EFI_SECURE_BOOT)), plus drivers/firmware/efi/secureboot.c. Q2 No (mainline: flag absent, verified). Q3/Q4 As C0 (David Howells authorship, Ard reviewed — yet upstream never took the trigger that needs it). Q5 None. Q6 None available. Q7 Several other SAUCE patches depend on it (arm64/s390 triggers, DMAR quirks group I). Q8 Nothing.

C5. feb19d6ddbf4 — (lockdown) efi: Lock down the kernel if booted in secure boot mode — 🟢 KEEP (High)

• The policy core (x86): CONFIG_LOCK_DOWN_IN_EFI_SECURE_BOOT. Same answers as C0; Ubuntu's Secure Boot security model (module signing enforcement etc.) depends on it. Keep.

C6. 3563c69c0126 — (lockdown) s390: Lock down when IPL secure flag is set — 🟢 KEEP (High)

• s390x secure-IPL parity; matters for Ubuntu on IBM Z with secure boot. kernel-ark origin. No issues known. Keep.

C7. 68f16f3c9e95 — (lockdown) KEYS: Make use of platform keyring for module signature verify — 🟢 KEEP (High)

• Q1 Yes. Without it, modules signed by MOK-enrolled keys don't load — the entire dkms/MOK story on Secure Boot machines rests on this patch. Q2 No — mainline kernel/module/signing.c still verifies against secondary keyring only (verified); the Fedora patch (R. Holmes) has been proposed and rejected/stalled upstream repeatedly (upstream worries about trusting firmware-controlled keys for modules). Q3 Fedora/RHEL, Debian, SUSE all carry an equivalent (verified 2026-07-09: Debian sid db-mok-keyring/KEYS-Make-use-of-platform-keyring-for-module-signature.patch, SUSE master KEYS-Make-use-of-platform-keyring-for-module-signatu.patch). Q4 Upstream refusal is deliberate (trust-model objection), not neglect. Q5 Known consequence of the design: any MOK key can sign modules — accepted Ubuntu policy. Q6 Upstream's .machine keyring (CONFIG_INTEGRITY_MACHINE_KEYRING, v5.18+) covers IMA/CA usage of MOK keys but not plain module signature verification — it is a partial, not full, replacement; worth re-evaluating in a cycle or two. Q7 Security-load-bearing. Q8 Track upstream machine keyring evolution.

C8. 2c05c2890e69 — (lockdown) arm64: Allow locking down under EFI secure boot — 🟢 KEEP (High)

• arm64 parity trigger (fdt params path). Partly Canonical-authored (Seth/Paolo). Same series answers; arm64 Secure Boot platforms (e.g. WoA laptops, servers) need it. Keep.

C9. 4e941996fd77 — (lockdown) Make CONFIG_LOCK_DOWN_IN_EFI_SECURE_BOOT more generic — 🟢 KEEP (High)

• Renames/generalises the Kconfig so s390 can use it; glue for C6. Canonical-authored. Keep with series.

C10a. c49e0681be60 — (lockdown) powerpc: lock down kernel in secure boot mode — 🟢 KEEP (High)

• PowerNV secure boot trigger (LP: #1855668, Daniel Axtens). Keep; ppc64el parity.

C10b. 10b404468f99 — (lockdown) security: use default hook return value — 🔴 DROP / squash (High)

• Q1 No — it is dead code in the final tree. It adapted the call_int_hook(lock_kernel_down, …) call to upstream 260017f31a8c's new convention; the later 1bed80283434 (C10c) deleted that call entirely (removed the LSM hook from security/security.c). Its net contribution to the built kernel is zero; it exists only as a bisect stepping stone inside the series.
• Q2–Q6 N/A (internal churn). Q7 questing carries the same pair. Q8 Squash into the series (or drop the commit) at the next rebase — zero functional change, one less patch.

C10c. 1bed80283434 — (lockdown) efi,lockdown: fix kernel lockdown on Secure Boot — 🟢 KEEP (High) — security-load-bearing (CVE-2025-1272)

• Q1 Yes, critically. Upstream 77b644c39d6a (v6.12) reordered early-LSM init; without this fix security_lock_kernel_down() from setup_arch() is a no-op and Secure Boot machines boot without lockdown — that was CVE-2025-1272 (RHEL bz#2333706). Makes lockdown a plain function, not an LSM hook.
• Q2 This is the current kernel-ark version (Ondrej Mosnacek). Q3 Fedora/RHEL; Debian/SUSE fixed equivalently. Q4 N/A. Q5 None known since. Q6 None (upstream has no lockdown-trigger to fix). Q7 Regression-test-worthy: verify /sys/kernel/security/lockdown shows [integrity] on a Secure Boot boot every cycle. Q8 Add that check to release testing if not already there.

C11. 1c8126346708 — (lockdown) efi: Fix swapped arguments to bsearch() — 🟢 KEEP (High)

• Q1 Yes — genuine bug fix to C1 (nmemb/size swapped since introduction; LP: #2141276). Canonical-found (Dongdong Tao), pushed into kernel-ark and cherry-picked back — the collaboration working as intended. Q5 none; Q7 proof the C1 helper had real latent bugs — argues for keeping the series in lock-step with kernel-ark rather than diverging. Keep.

C12. 6bf04e049a27 — Dump stack when X.509 certificates cannot be loaded — 🟢 KEEP (Medium)

• Q1 Marginal but real: identifies which loader fed a bad cert when the generic "Problem loading in-kernel X.509 certificate" error fires (mainline still bare pr_err, verified). 1-line debug aid. Q2 No. Q3 questing/resolute/jammy ✓. Q4 Never submitted. Q5 A stack dump in dmesg can alarm users/apport on cert issues — cosmetic. Q6 %pS-style caller annotation would be tidier; upstreamable either way. Q7 Tim-era (2016). Q8 Nothing.

C13. 56b2367fe9ce — ima: Downgrade error to warning — 🟢 KEEP (Medium)

C14. ff257ebebe10 — integrity: downgrade error to warning — 🟢 KEEP (Medium)

• Q1 Yes: both demote "Unable to open file" (ima_fs.c / digsig.c) from pr_err to warning for the routine "no IMA policy / no cert file present" boot case (LP: #1656908, #1766201) so error-scrapers (apport) don't file noise. Mainline still pr_err at both sites (verified v7.2-rc2+).
• Q2 No. Q3 questing/resolute/jammy ✓. (ff257ebebe10's message cites 58441dc86d7b — that's the Ubuntu hash of C13 in an older tree, not an upstream commit.)
• Q4 No. Q5 None. Q6 Upstream might accept a pr_notice for the file-absent case — low-effort submission. Q7 Cosmetic pair; keep together. Q8 Nothing.

C15. 5f57bdf679bc — integrity: Load mokx certs from the EFI MOK config table — 🟢 KEEP (High) — security-load-bearing (CVE-2020-26541)

• Q1 Yes. Loads MokListXRT (revocations/dbx) via the MOKvar config table. With Ubuntu shim ≥15.4, large revocation lists exist only as split MokListXRT{1,2,3} EFI variables which the upstream variable-path cannot read → without this patch revoked bootloader certs are not revoked (LP: #1928679).
• Q2 Still not upstream: mainline load_uefi.c reads MokListRT via mokvar table but MokListXRT only via the EFI variable (verified v7.2-rc2+). Marked Fixes: ebd9c2ae369a (the upstream mokx-via-variable commit) — a natural upstream submission that never happened.
• Q3 questing/resolute/jammy ✓; other distros' shims differ (Fedora shim exposes the full variable) so they don't need it as badly.
• Q4 No. Q5 None known since 2021. Q6 Upstreaming this is the better fix — mainline users of Ubuntu-style shims have the same hole. Q7 Dimitri Ledkov authored; owner gone — needs an adoptive owner for upstreaming. Q8 Submit upstream; add a boot-time check that blacklist: keyring gets populated on SB machines.

C16. 250977062222 — integrity: add informational messages when revoking certs — 🟢 KEEP (Medium)

• Q1 Yes — dmesg visibility of revocations mirroring the existing load messages; ops/support rely on it to verify dbx application. Q2 No; trivial candidate. Q3 questing/resolute/jammy ✓. Q4 No. Q5 None. Q6 Upstream with C15 as a pair. Q7 Companion of C15 (same BugLink). Q8 Nothing.

Group D — Selftests & test tooling (13 patches)

(Context: these exist to keep Ubuntu's autopkgtest/ADT kselftest runs green. All are carried by questing and jammy too unless noted.)

D1. 0ca189e4e4fd — selftests: net: replace AF_MAX with INT_MAX in socket.c — 🟢 KEEP (High)

• Q1 Yes — mainline still passes AF_MAX (verified), which fails when glibc's AF_MAX is lower than the kernel's (families added since the libc headers froze). Our INT_MAX probe tests the same EAFNOSUPPORT path robustly.
• Q2 No. Q3 questing ✓ jammy ✓. Q4 Never submitted, apparently. Q5 None. Q6 Upstream it — the libc/kernel AF_MAX skew hits everyone. Q7 2016-era. Q8 Send to netdev.

D2. 06b514b916a7 — selftests/ftrace: Fix tab expansion in trace_marker snapshot trigger test — 🟢 KEEP (High)

• Q1 Yes — quotes $line in two echos so tabs survive word-splitting; mainline still unquoted (verified). Q2 No. Q3 questing ✓ jammy ✓. Q4 No. Q5 None. Q6 Trivial upstream candidate. Q7/Q8 Send to linux-trace.

D3. 2fb524e1500b — prevent a glibc test failure when looking for obsolete types on headers — 🟢 KEEP (Medium)

• Q1 Yes — glibc's installed-headers conformance test greps for obsolete types (ulong etc.); mainline sysctl.h still says / ulong: … / in the KERN_PANIC_PRINT comment (verified). One-word comment change (ulong → unsigned long).
• Q2 No. Q3 questing ✓ jammy ✓. Q4 No. Q5 None (comment-only). Q6 The test is what's wrong (the commit says so) — but the path of least resistance is upstreaming the comment fix. Q7 Cascardo, LP: #1813060. Q8 Check whether current glibc still runs this check; if it stopped, drop.

D4. bbb21c3c9010 — usbip: add -Wno-address-of-packed-member to EXTRA_CFLAGS — 🟢 KEEP (Medium)

• Q1 Yes — usbip (built into linux-tools) still takes addresses of packed members by design; upstream configure.ac never gained the flag (verified); gcc still warns and Ubuntu builds with -Werror context.
• Q2 No. Q3 questing ✓ jammy ✓. Q4 No. Q5 None (warning suppression on intentionally-packed wire structs). Q6 Proper fix is memcpy-style accessors upstream; nobody has bothered. Q7 gcc-9 era but still applicable. Q8 Confirm the warning still fires with current gcc before ever dropping.

D5. 2cef384a288b — selftests/powerpc/ptrace: fix build failure — 🟡 REVIEW (Medium)

• Q1 Probably stale-able: adds -Wno-error=deprecated for a build failure of its era; upstream Makefile never needed it (verified: no such flag). The Makefile and toolchain have both moved substantially.
• Q2 No. Q3 questing ✓ jammy ✓. Q4 No. Q5 None. Q6 Test-build ppc64el selftests without it; if green, drop. Q7 Cascardo-era stopgap. Q8 That test build — cheap to do during the next crank.

D6. 0cb5168b6a84 — kselftest/runner: avoid using timeout if timeout is disabled — 🟢 KEEP (Medium-High)

• Q1 Yes — with timeout=0 upstream still execs the /usr/bin/timeout wrapper (verified); the wrapper's process-in-the-middle breaks the seccomp syscall_restart test's signal semantics (LP: #1870543). Ours skips the wrapper entirely when disabled.
• Q2 No. Q3 questing ✓ jammy ✓. Q4 No. Q5 None. Q6 Upstreamable QoL fix for runner.sh. Q7 Load-bearing for D7 (net settings timeout=0). Q8 Keep in sync with D7.

D7. 67d3ba6b3d10 — selftests/net -- disable timeout — 🟡 REVIEW (Medium)

• Q1 Weakening: sets net settings timeout=0 because slow ADT workers overran the then-default 45 s. Upstream has since raised net's timeout to 3600 s (verified) — likely sufficient for ADT.
• Q2 Yes in spirit — the 3600 s upstream value addresses the same pain. Q3 questing ✓ jammy ✓. Q4 N/A. Q5 Cost of ours: a genuinely-hung net test now hangs the whole suite run instead of being killed.
• Q6 Drop and inherit upstream's 3600 s; revisit only if ADT shows real overruns. Q7 Pairs with D6 conceptually but D6 stands on its own (any suite may set 0). Q8 One ADT cycle with the patch dropped.

D8. 202d7670937e — apply a workaround to re-enable CONFIG_CRYPTO_AEGIS128_SIMD — 🔴 DROP (High)

• Q1 No. Adds (uint8x16_t) casts to pacify GCC bug 96377, which affected GCC 10.0–10.2 and was fixed in GCC 10.3 (April 2021). Stonking builds with far newer gcc; upstream code (still cast-less, verified) compiles fine everywhere today.
• Q2 Upstream never needed it. Q3 questing ✓ jammy ✓ (jammy's gcc-11 doesn't need it either). Q4 N/A. Q5 None (casts are semantically no-ops) — it's just dead divergence in crypto code.
• Q6 Drop; CONFIG_CRYPTO_AEGIS128_SIMD=y (arm64/armhf) stays enabled on its own.
• Q7 The companion config-disable commit it references was already dropped long ago. Q8 One arm64+armhf build to confirm, then drop everywhere (incl. questing).

D9. b218078610e4 — selftests: memory-hotplug: bump timeout to 10min — 🟢 KEEP (High)

• Q1 Yes — upstream has no settings file at all for memory-hotplug (verified), so the 45 s default applies; the test legitimately takes minutes on large-memory machines.
• Q2 No. Q3 questing ✓ jammy ✓. Q4 No. Q5 None. Q6 Upstream the settings file — trivially acceptable, own-team authored (ppisati). Q7/Q8 Submit upstream.

D10. 2488f48b0cee — selftests: seccomp: bump up timeout to 5min — 🟡 REVIEW (Medium)

• Q1 Diminishing: upstream has since raised seccomp's timeout to 180 s (verified; ours: 300 s). seccomp_benchmark also got adaptive-scaling improvements upstream.
• Q2 Partially (the 180 s). Q3 questing ✓ jammy ✓. Q4 N/A. Q5 None. Q6 Try one ADT cycle on upstream's 180 s; drop if green. Q7 Colin King ack, 2020. Q8 The ADT trial.

D11. 06577dd807fc — Revert "net/tls(TLS_SW): Add selftest for 'chunked' sendfile test" — 🔴 DROP (High)

• Q1 No — obsolete. The revert existed because the test demonstrated a then-unfixed ktls sendfile hang. Upstream fixed the root cause in v5.19: d452d48b9f8b ("tls: prevent oversized sendfile() hangs by ignoring MSG_MORE"). The chunked test is alive and passing upstream (still present in tls.c, verified).
• Q2 The fix is the newer upstream resolution. Q3 questing ✓ jammy ✓ — both should drop it too (jammy 5.15 lacks the fix upstream… check 5.15.y backport status before dropping there).
• Q4 N/A. Q5 Ours removes coverage: we're skipping a working regression test for a bug class we shipped. Q6 Drop the revert, run the tls selftest once to confirm. Q7 Seth's lore inquiry (YMumgy19CXCk5rZD@ubuntu-x1) predates the fix by a year. Q8 The confirmation run.

D12. c5e330a41021 — selftest: rtcpie: Force passing unreliable subtest — 🟢 KEEP (Medium)

• Q1 Yes — the test still exists upstream (timers/rtcpie) with the same load-sensitive ±10% time-passage assertion; upstream was asked (Linaro thread) to raise tolerance and never replied; Linaro CI disables it outright.
• Q2 No. Q3 questing ✓ jammy ✓; Linaro (skip) — same conclusion, different mechanism. Q4 No. Q5 By design it can mask a real PIE-timing regression (it always reports pass) — acceptable trade recorded in the commit.
• Q6 A statistical/repeat-based assertion upstream would be right; nobody has done it. Q7 Rationale unusually well documented in the commit. Q8 Periodically grep upstream for tolerance changes.

D13. 3d7f84058e72 — selftests/net: increase socat timeout in gre_gso.sh — 🟢 KEEP (High)

• Q1 Yes — upstream still timeout 1 socat (verified); 1 s genuinely flakes on loaded runners (LP: #2136820).
• Q2 No. Q3 questing ✗ jammy ✗ (stonking/resolute only — new patch, Kuba Pawlak 2025). Q4 No. Q5 None. Q6 Upstream it — netdev takes this kind of flake fix readily. Q7 Own-team. Q8 Submit upstream; consider nominating for questing too if its ADT shows the same flake.

Group E — Security policy (8 patches)

E1. 127b29776d81 — add a sysctl to disable unprivileged user namespace unsharing — 🟢 KEEP (High)

• Q1 Yes — kernel.unprivileged_userns_clone is the admin/emergency kill-switch for unprivileged userns (the single richest local-privesc attack surface); default stays 1.
• Q2 No upstream equivalent (upstream offers only user.max_user_namespaces=0, which is per-user and semantically different). Ubuntu's newer layer is AppArmor's apparmor_restrict_unprivileged_userns mediation (23.10+) — complementary policy, not a replacement for the blunt sysctl.
• Q3 Debian sid still carries the sibling patch (this SAUCE self-describes as tweaked from Debian's); Arch dropped theirs when upstream max_user_namespaces landed; Fedora never carried one.
• Q4 Arch's drop (they judged upstream knobs sufficient) is the only notable abandonment.
• Q5 None; known ecosystem cost is software probing the sysctl's existence.
• Q6 Long-term, AppArmor mediation is Ubuntu's stated direction — but keeping the sysctl as CVE-mitigation lever remains cheap and occasionally decisive.
• Q7 Serge Hallyn heritage; rebased by four different maintainers — low but nonzero churn.
• Q8 Nothing.

E2. fef5b58d2361 — security,perf: Allow further restriction of perf_event_open — 🟢 KEEP (High)

• Q1 Yes — adds perf_event_paranoid=3+ (deny unprivileged perf entirely) + CONFIG_SECURITY_PERF_EVENTS_RESTRICT. Ubuntu ships paranoid=4 by default on some flavours and relies on the level existing.
• Q2 No. Upstream rejected the concept in 2016 (Ben Hutchings' submission; grsecurity extraction — LWN 696216) preferring CAP_PERFMON (v5.8) + the perf LSM hook (SELinux perf_event class) as the mechanism.
• Q3 Debian still carries the identical patch (verified in sources through 6.10.x); Android has shipped paranoid=3 default for years.
• Q4 Not dropped anywhere that carries it; upstream refusal was ideological (Ingo/PeterZ: capabilities+LSM, not magic sysctl levels).
• Q5 The historical wart (CAP_SYS_ADMIN-only) was fixed by our E3 below. Ecosystem cost: tools must know Ubuntu/Debian have a level upstream doesn't.
• Q6 Upstream's answer is the BPF-LSM/SELinux hook — Ubuntu (AppArmor) has no perf mediation, so the sysctl remains the practical control.
• Q7 Keep in lock-step with Debian's copy at rebases. Q8 Consider AppArmor perf mediation as the eventual replacement.

E3. 7661fabdd43d — perf/core: Allow CAP_PERFMON for paranoid level 4 — 🟢 KEEP (High)

• Q1 Yes — one-line fix to E2: !capable(CAP_SYS_ADMIN) → !perfmon_capable(), so CAP_PERFMON works at the restricted level as upstream intended when it created the capability (LP: #2131046).
• Q2 N/A (fix to a non-upstream feature). Q3 stonking/resolute; Debian's copy still has the old CAP_SYS_ADMIN-only check — worth offering them the fix.
• Q4 No. Q5 None — strictly widens to the designed capability. Q6 This is the better fix. Q7 Own-team (Pellizzer/Pisati). Q8 Forward to Debian kernel team.

E4. 4fc9711cb362 — binder: turn into module — 🟡 REVIEW (High) — largest ABI liability in the stack

• Q1 Functionally yes: Ubuntu ships binder_linux as a module (CONFIG_ANDROID_BINDER_IPC=m everywhere but s390x) for Waydroid/Anbox-style containers. Upstream binder is still bool (verified v7.2-rc2+) — can't be modular without this.
• Q2 No modularisation upstream, and Google has shown zero interest. ⚠️ New upstream development: CONFIG_ANDROID_BINDER_IPC_RUST (Rust rewrite) now exists — the C driver's days may be numbered, which would force a rewrite of this patch against the Rust driver.
• Q3 Debian carries the same approach (verified in sid 7.1.3-1: export-symbols-needed-by-binder.patch + android-enable-building-binder-as-module.patch) — a potential maintenance ally for the export set. Arch/openSUSE enable binder built-in (the "make it =y and drop the patch" model); Fedora doesn't enable binder at all.
• Q4 Anbox (the original motivation) is dead; Waydroid is the live consumer.
• Q5 The real cost: exports 15+ internal symbols including deep mm internals (lock_vma_under_rcu, zap_vma_range, get_vm_area, mmput_async) and security hooks. Every rebase has needed surgery (five different maintainers' fixup notes in the changelog, including 7.1's zap rename). Exported mm internals are ABI bait for out-of-tree modules and constrain upstream-driven refactors.
• Q6 Seriously evaluate =y built-in binder + binderfs (Arch model): kills all exports and both companion patches; cost is ~200 KB resident and binder always present (mitigable — binderfs devices appear only when mounted).
• Q7 Companions: c968ff765038, f422615515c0 live and die with it.
• Q8 Decide module-vs-builtin this cycle; watch the Rust binder transition upstream.

E5. c968ff765038 — binder: give binder_alloc its own debug mask file — 🟢 KEEP-with-parent (High)

• Fixes a real sysfs name collision that only exists because binder is modular (module params namespace). No upstream relevance (different module layout). Dies automatically if E4 goes built-in.

E6. f422615515c0 — allow to use __wake_up_pollfree() from GPL modules — 🟢 KEEP-with-parent (High)

• One-line EXPORT_SYMBOL_GPL(__wake_up_pollfree) needed only by modular binder. Same fate as E4. (Upstream deliberately keeps pollfree internal — epoll/binder are its only users.)

E7. 9ea2eb7f0cd1 — overlayfs: default to userxattr when mounted from non initial user namespace — 🟢 KEEP (High) — security-load-bearing

• Q1 Yes. This is the hardening that closed the GameOver(lay) class (CVE-2023-2640 / CVE-2023-32629): userns overlayfs mounts default to userxattr so trusted.overlay.* xattrs can't be smuggled; adds nouserxattr escape hatch.
• Q2 No — upstream never had Ubuntu's permissive history, so it has no such default-flip; upstream unprivileged overlayfs (5.11+) simply can't create trusted xattrs but also doesn't flip the default.
• Q3 Ubuntu-only (questing/resolute/jammy ✓) — it exists to keep Ubuntu's long-standing "overlayfs in userns" ecosystem (LXD et al.) working safely.
• Q4 No. Q5 Behaviour delta vs upstream for userns mounts (they get userxattr semantics implicitly); documented and intended.
• Q6 Converging on pure upstream semantics (no default flip) would break existing userns mount users; current shape is the pragmatic optimum.
• Q7 Cascardo authored post-incident; the CVE pair is the justification — do not drop casually.
• Q8 Re-check each rebase that overlayfs' new mount-api param table keeps ours applied (it's in params.c now).

E8. bc1b4bada662 — dma-buf: set SB_I_NOEXEC and SB_I_NODEV on dmabuf filesystem — 🟠 REPLACE-when-merged / 🟢 KEEP now (High)

• Q1 Yes — silences the v7.x VFS path_noexec() WARN when mmapping dmabufs (GStreamer v4l2src etc., LP: #2139656) and is correct hardening in itself.
• Q2 Own-team patch is upstream-in-flight: AceLan submitted to LKML 2026-01-14 (link in commit); not yet in v7.2-rc2+ (verified absent). Follows upstream precedent ce7419b6cf23 (anon_inode).
• Q3 stonking/resolute only. Q4 No. Q5 None known; semantics match the anon_inode precedent.
• Q6 The upstream submission is the better path — ping the thread, it may have simply been missed.
• Q7 Watch for it landing in 7.3 and drop the SAUCE then. Q8 Track the lore thread status each cycle.

Group F — AAEON ODM drivers (5 patches)

F0. Series context

16946ea66286 (hwmon) · ee8f130d0836 (leds) · 6292a86fd614 (gpio) · 4483877f08f7 (mfd core) · 3b7390cfec7f (mfd BFPI version check fix). One driver family: AAEON industrial x86 boards expose GPIO/LED/watchdog/HWMON through the ASUS WMI BFPI BIOS interface; the mfd driver is the parent, the rest are its cells. Authored by ASUS (Kunyang Fan), reviewed in by Canonical (LP: #1929504) under the ODM enablement program. Gated behind CONFIG_UBUNTU_ODM_DRIVERS — amd64 only.

F1–F5 (answers apply to the set; per-patch deltas noted)

• Q1 Relevant? Yes while the AAEON/ODM commercial commitment stands — these are certified-device enablement, not tech debt in the usual sense. The code itself is self-contained (4 new files + Kconfig/Makefile hooks) and rarely conflicts.
• Q2 Upstream version? No. These were never submitted upstream. ⚠️ Mainline has since gained other AAEON hardware support — the UP-board FPGA family (mfd/upboard-fpga, leds-upboard, pinctrl-upboard, v6.18+) — different interface (FPGA vs WMI), different boards; not a replacement, but proof upstream accepts AAEON enablement if sent.
• Q3 Other carriers? Ubuntu only (questing/resolute/jammy ✓) — definitionally, as ODM patches.
• Q4 Dropped anywhere? No.
• Q5 Regressions? One real field issue: boards with BFPI < 1.0 registered a zero-line gpiochip and spammed errors — fixed in-series by 3b7390cfec7f (LP: #1937897). Rebase-driven churn is visible (asus-wmi import changes, 6.11 build fix, new GPIO setter callbacks in the gpio driver) — Timo has had to touch them at almost every major rebase.
• Q6 Better fix? Upstream them (platform-drivers-x86 / hwmon / leds / gpio). ASUS-WMI-based vendor drivers are routinely accepted; that would end the per-rebase maintenance. Requires ASUS/AAEON cooperation for review bandwidth.
• Q7 Depends on asus_wmi; keep the five in lock-step. Verdicts: all five 🟢 KEEP (Medium) while the ODM program requires them, with an explicit action to pursue upstreaming.
• Q8 Confirm with the ODM/partner team that the AAEON engagement is still active in the stonking timeframe; if it lapsed, these become DROP candidates for the devel series while remaining in the LTS kernels the devices certified against.

Group G — Qualcomm venus/media + arm64 laptop enablement (14 patches)

G0. Venus sub-series context (8 patches)

cac14f491215 (dt-bindings) · 3db55129bac2 (trailing commas) · 74c7731318d9 (preset bits) · 40c5d36bffa2 (LLCC path) · 2d38a310b7da (SM8350 resources) · d307511fb759 (SC8280XP resources) · 9ea23628a741 (sc8280xp.dtsi Venus node) · 572df9ca78f6 (X13s enable). Video codec (Venus) enablement for the ThinkPad X13s (SC8280XP) and SM8350, cherry-picked from jhovold/linux (Johan Hovold's X13s staging tree), originally Konrad Dybcio's July-2023 linux-media series (LP: #2078929).

G1–G8. Venus patches — 🟠 REBASE-ON-NEWER (High) for the six driver/bindings patches; 🟢 KEEP (High) for the two dts patches

• Q1 Yes — without them the X13s has no hardware video encode/decode; hardware very much current.
• Q2 Yes: a v3 of the series is live on linux-media as of 2026-01-30 ("[PATCH v3 1/7] media: dt-bindings: Document SC8280XP/SM8350 Venus"), with Qualcomm venus maintainer (Dikshita Agarwal) engagement. Our copies are the 2023 v1. Mainline v7.2-rc2+ still has none of it (verified: no sc8280xp/sm8350 in venus, no preset/LLCC support, no dts node).
• Q3 jhovold/linux carries it (the de-facto X13s tree many distro/community kernels pull from); no major distro kernel otherwise.
• Q4 Not dropped — just a slow linux-media review pipeline (2.5 years and counting).
• Q5 None known in Ubuntu carriage. 3db55129bac2 (trailing commas) is cosmetic prep only — verify it's still needed by v3's context; drop it if not.
• Q6 Track and converge on the v3 series: diff our 8 against v3, adopt v3's shape at the next rebase, and drop the driver patches the moment they merge (likely 7.3/7.4). The dts additions typically land via qcom tree after the driver — keep them till then.
• Q7 Watch GDSC/clk dependencies (a related X13s venus clk fix went upstream separately).
• Q8 Subscribe to the v3 thread; re-check at 7.3-rc1.

G9. 08bf70dce998 — phy: qcom-edp: drop regulator loads — 🟡 REVIEW (Medium)

• Q1 Disputed. Reverts upstream a4888b2005d1 per Mark Brown's guidance ("don't set active-mode loads without idle-mode management") — but mainline still contains the loads (verified: regulator_set_load present in v7.2-rc2+): upstream never applied Johan's removal.
• Q2 No — this is the newer opinion, but it lost/stalled; mainline is the other way.
• Q3 jhovold/linux. Q4 Never merged upstream; not formally rejected.
• Q5 It's a live revert of mainline behaviour: power characteristics of eDP phy on qcom laptops differ from upstream — must be re-justified at every rebase.
• Q6 Either re-submit the removal upstream (with Mark Brown's rationale) or drop and match mainline; carrying a silent revert indefinitely is the worst option.
• Q7 Part of the X13s batch, but unlike the venus set there's no pending upstream version. Q8 Test display/PM on X13s with the patch dropped.

G10. 0db5c6b126b3 + G11. 723f6bfdb72b — Lenovo Yoga Slim 7x EC (bindings + driver) — 🟢 KEEP (Medium)

• Q1 Yes — Snapdragon X Elite Yoga Slim 7x: EC driver provides suspend notification and mic-mute key; hardware current, Ubuntu Concept images target it (LP: #2100858).
• Q2 Not merged. Upstream drivers/platform/arm64/ now hosts five EC drivers for sibling machines (acer-aspire1, huawei-gaokun, lenovo-thinkpad-t14s, lenovo-yoga-c630, qcom-hamoa) — the pattern is accepted; the Slim 7x driver (Maya Matuszczyk) just hasn't landed.
• Q3 Community X-Elite trees; not in other distro kernels.
• Q4 No. Q5 None known; driver is small (202 lines) and self-contained.
• Q6 Upstream it — with five in-tree precedents the review path is clear; check whether qcom-hamoa-ec (X-Elite CRD EC) has grown to cover Slim 7x, which would obsolete ours.
• Q7 Driver admits more EC features exist (fan, thermal) — upstreaming would attract contributors. Q8 Compare against qcom-hamoa-ec capabilities at next rebase.

G12. 313371dd6311 — firmware: qcom: scm: Allow QSEECOM on Acer Swift 14 models — 🟠 REPLACE / submit upstream (High)

• Q1 Yes — one-line allowlist entry (acer,swift-sf14-11) enabling QSEECOM (hence efivars) on that machine.
• Q2 Not upstream (verified absent), but upstream actively accepts identical one-liners — recent additions include Surface Pro 12", IdeaCentre Mini X, Mahua/Glymur CRDs. Most entries in our tree's list came from mainline already.
• Q3 Ubuntu only. Q4 No. Q5 None.
• Q6 Send the one-liner upstream — near-zero review risk; SAUCE disappears next rebase after it lands.
• Q7 Tobias Heider authored; trivially upstreamable. Q8 Submit this cycle.

G13. c42d9908e91f + G14. c8f1fd449160 — hack: efi/libstub: mitigate t14s exit_boot_services() failure (+ arm64-only gating) — 🟡 REVIEW (High attention)

• Q1 For the Snapdragon T14s with affected UEFI firmware, yes: without it ExitBootServices() intermittently fails and the machine doesn't boot. Author explicitly titles it "hack" — allocating (and immediately closing) an EFI event before EBS papers over a firmware bug.
• Q2 No upstream version; something like this would need Ard Biesheuvel's blessing and a firmware-quirk justification — never submitted as far as findable.
• Q3 Ubuntu (and derivatives of our tree) only.
• Q4 No. Q5 ⚠️ Yes — it already caused one regression: the ungated version broke boot on old x86 Macs (LP: #2105402), which is why c8f1fd449160 retro-gated it to arm64. That is the canonical warning sign for global boot-path hacks. Even on arm64 it runs on every EFI machine, not just T14s.
• Q6 In order of preference: (a) Lenovo firmware fix — check current T14s UEFI releases; if fixed, gate on firmware version or drop; (b) narrow the hack to DMI/DT-identified T14s only; (c) submit upstream as an explicit firmware quirk for discussion.
• Q7 Marked hack: by its own author (arighi) — the stack's most self-aware patch.
• Q8 Check Lenovo's T14s firmware changelog now; retest boot without the hack on current firmware — this is the top candidate for root-cause retirement in this whole group.

Group H — Net & storage (20 patches)

H1–H4. nvme-tcp error-recovery series — 🟡 REVIEW / keep-and-track (Medium-High)

85353f3283e4 (no terminate in RESETTING) · ee9a7deb3199 (err_work → delayed work) · 0e408bf0ff4f (delay recovery until KATO) · 392c602bb5b1 (recovery_delay sysfs)

• Q1 Yes — prevents premature I/O failure/failover on transient NVMe-over-TCP disconnects (matters for LXD/MicroCloud remote-storage users; Ubuntu bug LP: #2070048 "nvme-tcp: fix retry logic").
• Q2 Not upstream (recovery_delay absent from mainline, verified). Upstream deliberately parked the problem pending the NVMe spec fix (TP4129, transport timeouts) — the SUSE thread records "it will take a long time, so go with the temporary way".
• Q3 SUSE carries all four in SLES (they're Hannes Reinecke/Daniel Wagner patches; we cherry-picked from SUSE). Verified 2026-07-09: nvme-tcp-delay-error-recovery-until-the-next-kato.patch present in kernel-source SLE15-SP7; absent from SUSE's near-vanilla master/Tumbleweed branch — an enterprise-branch carry, exactly like ours.
• Q4 Not rejected outright — deferred by upstream nvme maintainers as spec-level work.
• Q5 The sysfs recovery_delay knob is Ubuntu/SUSE-only ABI — scripts using it are non-portable; behaviour delta vs mainline in fabric error handling must be re-validated each rebase (nvme-tcp churns heavily upstream).
• Q6 The real fix is upstream's eventual TP4129 implementation — watch linux-nvme for it and drop the set when it lands.
• Q7 Keep the four in lock-step (they're one logical series); stay aligned with SUSE's copy, which gets maintained by the original authors.
• Q8 Check each cycle whether SLES has dropped/replaced them — that's the leading indicator.

H5. 200ced9ab077 — net: ena: fix too long default tx interrupt moderation interval — 🔴 DROP (Medium-High)

• Q1 No. Forces default TX moderation to 0 µs; upstream ena deliberately ships 64 µs (ENA_INTR_INITIAL_TX_INTERVAL_USECS 64, verified) after Amazon's own moderation rework — our patch fights the vendor's chosen default from a 2019 snapshot of the argument (LP: #1853180).
• Q2 Yes — upstream's adaptive/64 µs default is the newer resolution (Amazon's referenced 2019 lore patch was superseded).
• Q3 questing/jammy carry it (inertia). AWS's own recommended kernels use upstream defaults.
• Q4 Never merged; Amazon moved on. Q5 Divergent latency/throughput trade-off vs every other distro on EC2; surprising to anyone tuning via documented defaults.
• Q6 Runtime ethtool -C tx-usecs (cloud image default if AWS wants it) — policy belongs in userspace/image config, not a kernel fork.
• Q7 Belongs, if anywhere, in linux-aws, not generic. Q8 Confirm with the AWS kernel team, then drop from generic.

H6. 16a17f7b5e8e — igc: wait for the MAC copy when enabled MAC passthrough — 🟢 KEEP (Medium)

• Q1 Yes — Thunderbolt-dock hotplug with BIOS MAC-passthrough needs up to ~800 ms before the MAC is valid; v2 bumps the probe wait to 1000 ms for newer Dell docks (LP: #1942999). No equivalent upstream (verified).
• Q2 No. Q3 questing/jammy carry v1 (600 ms). Q4 Never submitted as far as findable. Q5 Adds up to 1 s to igc probe on passthrough systems — bounded, acceptable; polling-with-timeout would be nicer than a fixed sleep.
• Q6 Poll the MAC-valid condition instead of sleeping, and submit to intel-wired-lan. Q7 OEM-enablement driven. Q8 Submit upstream.

H7. 2d8b8797d06c — iwlwifi: add new pci id for 6235 — 🟢 KEEP (Medium)

• Q1 Yes, narrowly: subdevice 0x088F/0x526A (Centrino Advanced-N 6235 variant) is still missing from mainline's PCI binding table (verified — the new masked IWL_DEV_INFO naming table would classify it, but the pci_device_id table won't bind it).
• Q2 No. Q3 questing/jammy ✓. Q4 No. Q5 None (1 line).
• Q6 Send the one-liner upstream — even for 2012 hardware, ID additions are accepted.
• Q7 LP: #1920180. Q8 Nothing.

H8. 4076a045c846 — [nf,v2] netfilter: x_tables: don't rely on well-behaving userspace — 🔴 DROP (High)

• Q1 No. This is Florian Westphal's 2016 v2 proposal (next_offset_ok() checks in arp/ip/ip6_tables mark_source_chains). Upstream merged a different, more comprehensive final series in v4.6 (offset/jump validation at translate time — netfilter: x_tables: validate targets of jumps, …don't move to non-existent next rule, etc., CVE-2016-3134 era). Our copy is the superseded draft carried for 10 years on top of the real fix.
• Q2 Yes — the merged 4.6 series. Q3 questing/jammy ✓ (inertia). Q4 The v2 itself was superseded on-list by the author's own final version.
• Q5 Redundant checks: no functional harm, but it patches three hot security-sensitive files and periodically conflicts at rebases — cost without benefit.
• Q6 Rely on mainline validation. Q7 LP: #1555338. Q8 None — drop.

H9. ffab526280cd — mwifiex: Switch WiFi LED state (Edge Gateway) — 🟡 REVIEW (Medium, lean DROP)

H10. 6857b4c408f7 — Bluetooth: Support for LED on Edge Gateways — 🟡 REVIEW (Medium, lean DROP)

• Q1 Only for the Dell Edge Gateway 5000/5100 (2016 IoT devices, "For Edge Gateway 5000/5100 only" per commits). Those shipped with 16.04-era kernels; whether any are entitled to run a 26.x kernel is the whole question.
• Q2 No; upstream would want LED-class triggers, not firmware pokes in driver paths. Q3 questing/jammy ✓ (inertia). Q4 Never submitted (device-specific).
• Q5 Touches 7 mwifiex files / btusb — a periodic rebase conflict source for EOL-adjacent hardware.
• Q6 Modern equivalent would be ledtrig-netdev (upstream) + firmware LED config — moot if the device program is over.
• Q7 Jesse Sung ODM-era work. Q8 Ask ODM/IoT team whether Edge Gateway support extends to stonking; drop from devel if not (keep in the LTS kernels the devices actually run).

H11. d47a50c07db7 — net: phy: marvell: Skip setting LED on Dell EMC board — 🟢 KEEP (Medium)

• Q1 Yes — Dell EMC (VEP/edge) boards need BIOS-configured PHY LED values preserved; the driver otherwise hardcodes LED config at probe (LP: #1971667).
• Q2 No. Q4-answered-in-commit: Kai-Heng's generic "don't touch LEDs" property was proposed upstream and went nowhere (Andrew Lunn wanted a generic approach that never materialised — lore link in commit); the quirk is the documented fallback.
• Q3 questing/jammy ✓. Q5 None known; quirk is DMI-scoped.
• Q6 Upstream's newer PHY LED / ledtrig-netdev framework (marvell.c now has full LED hw-control) might express "leave-as-BIOS-set" properly — re-attempt upstreaming through that lens.
• Q7 Dell EMC platform commitment. Q8 Re-test on the board with the new LED framework at next LTS.

H12. 9c281446a2c1 — rbd: bump RBD_MAX_PARENT_CHAIN_LEN to 128 — 🟡 REVIEW (Medium)

• Q1 Purpose (deep clone chains for fsx/teuthology parity with librbd, LP: #2032959) persists, but note: mainline still ships 16 three years after the ceph-client cherry-pick — the change never travelled from ceph-client.git to Linus.
• Q2 No newer version; the question is whether ceph maintainers dropped it from ceph-client (check their tree) or just never forwarded it.
• Q3 questing ✓; not in other distros. Q4 Unclear — needs the ceph-client check. Q5 Deeper chains = more memory/latency per map; bounded, but 8× upstream's chosen limit.
• Q6 Ask the ceph kernel maintainers (Ilya) to either land it or explain; align with their answer.
• Q7 Paired historically with H13 (same BugLink). Q8 The ceph-client.git check — one git log on their tree.

H13. 721b7ffcfcf3 — ceph: move mdsmap.h to fs/ceph/ — 🔴 DROP (High)

• Q1 No. Upstream did this move itself (fs/ceph/mdsmap.h exists in mainline, since v6.7). After the rebase our "patch" has degenerated into a single duplicate #include "mdsmap.h" in fs/ceph/mdsmap.c (verified: that's the entire remaining diff) — pure residue.
• Q2 Yes — the upstream move. Q3 questing carries the meaningful old version (pre-6.7 base). Q4 N/A. Q5 Harmless but literally pointless. Q6/Q7 N/A. Q8 Drop at the next opportunity; zero risk.

H14. abd6a0668001 + H15. cd0e97f74ced — Ubuntu Fan (tunnel multiple mapping v3 + VXLAN implementation) — 🟢 KEEP (High, with a strategy note)

• Q1 Yes — Ubuntu Fan networking is a shipped, documented product feature (LXD fan bridges; fanctl/iproute2 integration; sysctl feature markers) used in clustering deployments.
• Q2 No. Upstream rejected the Fan concept in 2015-era netdev discussions (overlapping VXLAN/geneve functionality; special-cased address mapping) — there is no upstream path in its current form.
• Q3 Ubuntu-only, everywhere (jammy/questing/resolute ✓).
• Q4 See Q2 — upstream never took it; no other distro adopted it.
• Q5 ⚠️ Maintenance heat: the changelog records ABI adaptations at 4.12, 6.4, 6.8, 6.11 and 6.17 — vxlan churns constantly and Fan hooks deep into vxlan_xmit. Every vxlan backport/rebase is a Fan re-validation. It also extends kernel netlink ABI (needs patched iproute2).
• Q6 Long-term: either sunset (LXD's modern alternatives: plain VXLAN/geneve overlays) or finally propose a minimal upstream mapping extension. Carrying forever is the default but the per-cycle cost is real.
• Q7 Jay Vosburgh is the domain owner; changes should go through him.
• Q8 Get a product decision on Fan's lifecycle (usage telemetry from LXD?) — this is a strategy item, not a patch-level one.

H16–H18. IgH EtherCAT master — 🟢 KEEP (Medium)

6cb1ba572b5a (import v1.6.8) · 701abbb1d759 (Kbuild glue) · 74cfca3a3e93 (6.19 build fix)

• Q1 Yes — fresh (2025/26) import of the etherlab.org EtherCAT master (industrial fieldbus) into ubuntu/igh-ecat, LP: #2138621 — evidently a current partner/IoT commitment; ~large self-contained codebase.
• Q2 Upstream project lives at gitlab.com/etherlab.org/ethercat; we pin 1.6.8 (tag commit recorded). Check for 1.6.x/1.7 releases each cycle — the 6.19 build fix (74cfca3a3e93) shows the import needs local fixes that upstream EtherLab may already have.
• Q3 No other distro ships it in-kernel (normal deployment is out-of-tree DKMS from EtherLab).
• Q4 N/A. Q5 The build fix proves the maintenance cost; also this code never had netdev review — treat as vendor-quality.
• Q6 DKMS packaging would decouple it from kernel rebases, at the cost of Secure-Boot signing convenience — presumably in-tree was chosen deliberately for signing; record that rationale.
• Q7 Keep the three in lock-step; re-import cleanly rather than patching locally where possible (send 74cfca3a3e93's fix to EtherLab upstream).
• Q8 Confirm the partner engagement and whether CONFIG_ETHERCAT (or its actual name) is enabled anywhere by default.

H19. 888fd68fbeb1 + H20a. d67f08c67612 — r8169: enable ASPM on Dell platforms (+ more platforms) — 🟡 REVIEW (Medium)

• Q1 Power-saving enablement on current Dell machines (LP: #2121200, #2133144): r8169 disables ASPM by default; these allowlist Dell product families (incl. broad prefixes like "XPS") for ASPM.
• Q2 No. Upstream's model is chip-based (rtl_aspm_is_safe(), LTR-based enablement) — AceLan's Sep 2025 lore submission has not been merged and upstream (Heiner Kallweit) has historically rejected DMI-based ASPM allowlists.
• Q3 stonking/resolute (+ OEM kernels presumably); nobody else.
• Q4 Effectively declined upstream — mechanism disagreement, not correctness.
• Q5 ⚠️ Risk profile: family-prefix matching sweeps future models automatically ("Dell will push RTL to fix any issues" is a promise, not a mechanism); r8169+ASPM failures historically present as random link death and system hangs — hard to triage in the field. Watch LP for regressions on matched families.
• Q6 Work with Realtek/upstream toward chip/LTR-based enablement covering these NICs — that's where upstream is heading; the DMI list then evaporates.
• Q7 Dell OEM commitment; the two commits are one logical allowlist — keep in lock-step.
• Q8 Audit which chip versions ship in the matched families and whether upstream rtl_aspm_is_safe() already covers newer ones (making entries redundant).

H20b. 931e090cc7bf — r8169: add quirk for RTL8116af SerDes — 🟢 KEEP (Medium)

• Q1 Yes — RTL8116af (8168fp variant with SerDes instead of PHY) needs SerDes status reflected into PHY reads; hardware ships in current platforms (LP: #2116144).
• Q2 Realtek's own submission (ChunHao Lin, July 2025 lore) — not merged yet (verified: no 8116af handling in mainline; mainline's SerDes code is the separate SFP-mode feature).
• Q3 stonking/resolute. Q4 No. Q5 None known; scoped to RTL_GIGA_MAC_VER_52 + SerDes detection.
• Q6 Nudge Realtek to repost; drop when merged. Q7 Vendor-authored, low risk. Q8 Track the lore thread.

Group I — PCI / IOMMU / thunderbolt (9 patches)

I1–I3. iommu: intel-ipu passthrough (base + RPL + MTL) — 🟡 REVIEW, lean DROP (Medium-High)

dbc9299673e3 (TGL/ADL-era IDs) · 02f15b3d914e (Raptor Lake) · 09fb787ba7d4 (Meteor Lake)

• Q1 Questionable now. These force IOMMU passthrough for Intel IPU devices because the out-of-tree intel/ipu6-drivers dkms stack (their literal cherry-pick origin) manages its own MMU and faults under DMAR. But the in-tree ipu6 driver (mainline since v6.10, present in our base) was reviewed to work with the Intel IOMMU — mainline has no such quirk (verified) and needs none.
• Q2 Upstream's "version" is: a proper driver that doesn't need the quirk.
• Q3 questing/jammy carry them (OEM enablement lineage); nobody upstream/other-distro.
• Q4 Intel never submitted the quirk upstream — it exists only in the dkms repo's patch directory, i.e. explicitly not upstreamable.
• Q5 ⚠️ Security cost: identity-maps the IPU (a DMA-capable device processing untrusted camera data) on every affected platform, even when the in-tree driver is in use.
• Q6 Determine whether stonking-era OEM images still install ipu6-dkms (vs in-tree ipu6/ipu7): if in-tree → drop all three; if dkms is still shipped for some platforms, keep only the IDs those platforms need and plan the exit.
• Q7 Three patches, one growing ID table — same treadmill pattern as the DMAR igfx quirks below.
• Q8 The dkms-vs-intree audit; ask the OEM enablement team (vicamo).

I4. b19ae843299f — PCI: vmd: guard device addition and removal — 🟢 KEEP (Medium-High)

• Q1 Yes — real race: vmd's own enumeration vs concurrent pci_rescan_bus() from other drivers (wwan) → duplicate sysfs files (LP: #2011389). Upstream vmd.c still has no rescan locking (verified: no pci_lock_rescan_remove there).
• Q2 No. Q3 questing ✓. Q4 Apparently never submitted upstream despite carrying a proper Fixes: tag against the original VMD commit.
• Q5 None known — takes the standard pci_lock_rescan_remove() around domain enable/disable.
• Q6 Submit upstream — it's the canonical lock for exactly this and the race is generic, not Ubuntu-specific.
• Q7 vicamo/Kai-Heng. Q8 Submit; low review risk.

I5. c8d21df63bc8 (SKL) + I6. ba78d04f589c (KBL/CML) — iommu/intel: disable DMAR for integrated gfx — 🟡 REVIEW (High attention)

• Q1 For affected users, yes: Gen9/9.5 iGPUs flicker with INTEL_IOMMU_DEFAULT_ON + scalable mode (which Ubuntu itself enabled in 6.8 via config — the quirks exist to fix Ubuntu's own config change; LP: #2062951, #2086587).
• Q2 No upstream fix: i915 issue #11504 is still open, and upstream's quirk_iommu_igfx list covers only ancient GM45-era IDs — upstream has not accepted Gen9 entries.
• Q3 Ubuntu only. Other distros mostly don't default Intel IOMMU on for these gens, so they don't see it.
• Q4 Not submitted upstream (would likely be rejected pending i915 root-cause).
• Q5 ⚠️ Security trade: silently removes IOMMU DMA protection for the iGPU on whole generations — thunderclap-style attacks via the iGPU become possible where users believe DMAR is on. Also the treadmill is live: LP: #2136958 (Coffee Lake/Whisky Lake, 2025) is already queueing the next batch of IDs.
• Q6 Options, best first: (a) push i915/#11504 upstream — it's an Intel bug needing an Intel fix; (b) adopt Debian's generic mechanism: sid carries intel-iommu-add-option-to-exclude-integrated-gpu-only.patch + intel-iommu-add-kconfig-option-to-exclude-igpu-by-default.patch (verified 7.1.3-1) — one runtime option that excludes the iGPU from the IOMMU on any platform, ending the per-ID treadmill; (c) at minimum consolidate one quirk covering the Gen9 family instead of chasing IDs per cycle.
• Q7 These exist to preserve the (security-motivated) DMAR-on default for everyone else — a defensible trade, but it must stay documented and deliberate.
• Q8 Re-check #11504 and the CFL bug each cycle; expect a third SAUCE if upstream stays silent.

I7. cb315c8c7cfd + I8. 2cc6f33a4c5e — PCI/ASPM + vmd: OS-controlled ASPM where BIOS is incapable — 🟡 REVIEW (Medium)

• Q1 Yes for power on VMD-mode Intel laptops whose FADT sets ACPI_FADT_NO_ASPM: upstream's own VMD ASPM quirk (f492edb40b54, in mainline with pci_enable_link_state_locked) is defeated by the FADT flag; this pair adds a per-device bypass so VMD children still get ASPM. Without it, SoC can't reach low package C-states on affected machines (LP: #2072679).
• Q2 Kai-Heng's May-2024 linux-pci submission (both patches' cherry-pick source) — not merged (verified: no aspm_os_control upstream); discussion stalled around whether ignoring FADT is safe.
• Q3 stonking/resolute (+OEM). Q4 Not rejected formally; stalled.
• Q5 Overriding firmware's "no ASPM" statement is exactly the kind of thing that breaks weird BIOSes — but scope is limited to devices under VMD (attribute set only by vmd driver), which the BIOS hid from itself anyway. Risk contained.
• Q6 Re-submit upstream with the VMD-only scoping argument front and centre; Bjorn/Mika feedback would settle it.
• Q7 Pair is one logical change; keep in lock-step. Q8 Track linux-pci; re-ping the thread.

I9. 07f1d7f0ac66 — thunderbolt: Fix PCIe device enumeration with delayed rescan — 🟡 REVIEW (Medium)

• Q1 For affected docks/hosts, yes: spurious unplug/plug events right after tunnel activation break pciehp link-up detection ~70% of the time; a 300 ms delayed pci_rescan_bus() papers over it (LP: #2139572).
• Q2 No upstream equivalent (upstream's only delayed rescan is the unrelated ICM resume path, verified).
• Q3 stonking/resolute only (recent). Q4 No.
• Q5 Band-aid characteristics: unconditional delayed rescan on every tunnel activation adds bus-walk churn; the spurious hotplug events (root cause) remain, so other symptoms may surface elsewhere.
• Q6 Root-cause with Mika Westerberg upstream (tb hotplug-event filtering, or pciehp debounce) — the commit itself contains excellent evidence to open that thread with.
• Q7 Idempotency argument in the commit is sound as mitigation engineering; it's still mitigation.
• Q8 Submit the analysis upstream; keep the patch until a real fix exists.

Group J — typec/ucsi + remaining singletons (17 patches)

J1. ef6bdf031cf7 — Revert "usb: typec: ps883x: fix missing accessibility check" — 🟡 REVIEW (High attention)

• Q1 For the HP EliteBook G1q 14 (Snapdragon), yes: upstream 9e7968c44248 blacks out the display at boot. But we are reverting a commit that is alive in mainline (verified) — a live divergence that silently re-introduces whatever the accessibility check fixed on other hardware.
• Q2 No fixed-up upstream version found; the offending commit stands upstream.
• Q3 stonking/resolute only. Q4 N/A.
• Q5 Both directions risky: keep the revert → other ps883x machines may regress the original bug; drop it → EliteBook G1q won't boot to display.
• Q6 Root-cause upstream: report the G1q regression to the ps883x author/linux-usb so the check can be made conditional — reverting-forever is the worst steady state. Every rebase must re-apply a revert of a commit that upstream may build on.
• Q7 LP: #2100858 (the X-Elite enablement bug). Q8 File the upstream regression report if not already done — check linux-usb archives first.

J2–J4. ucsi duplicate-altmode series — 🟢 KEEP (Medium-High), upstream-in-flight

afdc7c60b5b6 (core dedup helper) · 2251baa2cea7 (nvidia path, has Fixes: + Cc: stable) · 61d4e72699f5 (drop yoga_c630's local dedup)

• Q1 Yes — buggy UCSI firmware returns duplicate altmodes → sysfs duplicate-filename splats and typec-thunderbolt probe failures (LP: #2127960); dedup in the core fixes all paths.
• Q2 Not merged yet (no ucsi_altmode_is_duplicate in mainline, verified). AceLan authored them in upstream-ready form (proper Fixes/stable tags) — track the linux-usb submission.
• Q3 stonking/resolute. Q4 No.
• Q5 ⚠️ 61d4e72699f5 reverts upstream e0c48e42d818 (which is still in mainline, verified) — fine only while our core dedup patches are present; the three must move as one unit or the yoga_c630 loses its firmware workaround.
• Q6 Merge upstream — then all three (and upstream's own yoga workaround) resolve together.
• Q7 Treat as one series at every rebase. Q8 Ping the linux-usb thread; drop when merged.

J5. 831ef6f9a678 — ucsi: Fix workqueue destruction race during connector cleanup — 🟢 KEEP (Medium-High)

• Q1 Yes — real WARN/crash class (__queue_work on destroyed wq) when port registration fails or shutdown races delayed work (LP: #2127764, observed on Dell/6.17).
• Q2 Not identified in mainline as of v7.2-rc2; ucsi cleanup paths churn upstream, so verify at each rebase whether an equivalent landed.
• Q3 stonking/resolute. Q4 No. Q5 None known.
• Q6 Upstream it (linux-usb) — races like this affect everyone.
• Q7 AceLan-quality writeup in the commit; low review risk. Q8 Submit/track.

J6. 893b73c9c28a — USB: hub: call ACPI _PRR reset during port power-cycle on enumeration failure — 🟡 REVIEW (Medium)

• Q1 Yes for the motivating case: MT7925 Bluetooth on Dell laptops wedges with reset GPIO stuck low; VBUS cycling can't recover it; ACPI _PRR→_RST during the de-powered window does (LP: #2145164).
• Q2 No — mainline has no _PRR support in USB core at all (verified).
• Q3 stonking only (new). Q4 No.
• Q5 It adds an ACPI evaluation into the generic hub enumeration-retry path for all ports — a no-op without _PRR, but ordering assumptions (reset-while-depowered) are encoded in core hub code for one device's sake. Watch for odd interactions on other _PRR-exposing firmware.
• Q6 Submit to linux-usb: _PRR is standard ACPI; Alan Stern/Mathias review would either harden or relocate the hook (e.g., port-dev quirk). Upstreaming is the de-risking move.
• Q7 Excellent commit message (ordering rationale documented). Q8 Submit; meanwhile monitor LP for regressions on non-Dell ACPI machines.

J7. 0beda227c2fb — i2c: i801: Do not instantiate spd5118 under SPD Write Disable — 🟢 KEEP (Medium-High)

• Q1 Yes — with SPD Write Disable set, spd5118 devices break (resume errors, ENXIO writes, dead nvmem; LP: #2114963).
• Q2 Partially upstream: the infrastructure is mainline (i2c_register_spd_write_disable() exists in i2c-smbus, verified) but upstream i801 never wires its SMBHSTCFG_SPD_WD bit into it — it just logs "SPD Write Disable is set" and registers write-enabled anyway. Our patch adds exactly the missing wiring.
• Q3 stonking/resolute. Q4 No. Q5 None known; conservative direction (don't bind what can't work).
• Q6 Submit to linux-i2c — with the helper already upstream this is a natural completion; likely authored with that intent.
• Q7 Coordinates with hwmon/spd5118 (Guenter Roeck's domain). Q8 Submit/track.

J8. 558e3cf6b3e9 — drm/i915/xelpdp/tc: Convert TCSS power check WARN to a debug message — 🟢 KEEP (Medium)

• Q1 Yes — headless MTL boots hit a known BIOS-handoff state (HPD live bits set, TCSS power off) and splat a WARN the driver then handles correctly anyway (LP: #2144537).
• Q2 Own submission on lore (2026-03-16, AceLan); not yet in mainline. Follows upstream precedent d7fa5754e83c (same conversion for the AUX check — verified present).
• Q3 stonking/resolute. Q4 No. Q5 Only that a real TCSS power bug would now log at debug level — same trade upstream accepted for AUX.
• Q6 Merge upstream (precedent makes it likely). Q7/Q8 Track the lore thread; drop when merged.

J9. 485a328c495e — drm/i915/lnl+/tc: Fix false disconnect of active DP-alt TC port during long HPD pulse — 🟢 KEEP (Medium-High)

• Q1 Yes — LTTPR dongles' long HPD pulse makes intel_tc_port_connected() momentarily read disconnected → compositor kills eDP-1 (internal display disappears!) on LNL+ (LP: #2143879). Trusts the stable PHY-ownership register when link_refcount > 0 instead.
• Q2 Not in mainline (verified: no such logic in intel_tc.c); a fix of this class belongs with Imre Deak (i915 TC maintainer) — check intel-gfx for a submission.
• Q3 stonking/resolute. Q4 No. Q5 Trusting ownership over live-status could delay detection of a genuine unplug during an active link until the next real event — bounded, and far better than the current false-disconnect.
• Q6 Upstream via intel-gfx; the analysis in the commit is upstream-grade.
• Q7 User-visible severity (display loss) justifies carrying meanwhile. Q8 Submit/track.

J10. 26630c96cb94 — media: ipu-bridge: Support imx471 sensor — 🔴 DROP (High)

• Q1 No — upstream already has the identical SONY471A entry, and after the v7.2-rc2 rebase our tree literally contains the entry twice (verified: lines 98-99 upstream copy + 102-103 SAUCE copy in ipu-bridge.c). Harmless (first match wins) but pure residue.
• Q2 Yes — the upstream entry. Q3 questing carries the meaningful older copy. Q4 N/A. Q5 None beyond confusion. Q6 Drop; see J11 for the part that still matters. Q7/Q8 Drop at next opportunity.

J11. 8f323e914b83 — media: ipu-bridge: add TBE20A0 ACPI id for Sony IMX471 — 🟢 KEEP (Medium) + submit

• Q1 Yes — TBE20A0 (alternate ACPI HID for IMX471 modules) is absent upstream (verified); needed for the affected platforms (LP: #2138841; origin: intel/ipu6-drivers patch dir).
• Q2 No. Q3 stonking only. Q4 No. Q5 None (one table line) — but re-anchor it onto upstream's IMX471 line when J10 is dropped.
• Q6 One-liner for linux-media; sensor-ID additions are routinely accepted. Q7 Intel keeps these only in its dkms repo — Ubuntu can be the one to upstream. Q8 Submit with J10's cleanup.

J12. 72174b83c8b7 — ACPICA: avoid accessing operands out-of-bounds — 🔴 DROP (High)

• Q1 No — upstream ACPICA fixed the same UBSAN out-of-bounds (Timer op with zero operands) via the AML_NO_OPERAND_RESOLVE flag mechanism, which is in mainline (verified in amlcode.h/dswexec.c/psopcode.c) and in our base. Our NULL-parameter variant is the superseded alternative fix (LP: #1942215, 5.15-era).
• Q2 Yes — the upstream ACPICA fix. Q3 questing/jammy (where it's still needed pre-6.x!). Q4 ACPICA upstream chose the flag approach over this. Q5 Redundant code in a parser hot path; no known harm. Q6 Rely on upstream. Q7 ACPICA changes should go via the ACPICA project, not kernel SAUCE — moot now. Q8 Drop.

J13. b2d78e624492 — ACPI: respect items already in honor_dep before skipping — 🟢 KEEP (Medium)

• Q1 Yes while Ubuntu's MIPI-camera enablement needs it: upstream 4405a214df14 (v6.18, backported to stables) moved Intel CVS HIDs to acpi_ignore_dep_ids[], which broke sensor probe ordering for Ubuntu's out-of-tree camera stack (ov02c10 chip-id mismatch); this makes honor_dep win over ignore_dep for overlapping entries (LP: #2145171).
• Q2 No — this reconciles upstream's change with our enablement; upstream has no reason to take it as-is.
• Q3 questing (same subject present) / stonking. Q4 No.
• Q5 Alters generic _DEP handling semantics (honor-before-ignore) — theoretically visible on non-camera platforms with overlapping IDs; none reported.
• Q6 The durable fix is the same as I1–I3: converge on the in-tree IPU/camera stack so the special-casing evaporates. Audit together.
• Q7 vicamo's careful commit message maps the upstream interaction — good template. Q8 Include in the ipu6-dkms audit (see I1–I3).

J14. de8c97b4fa10 — powerpc/vio: drop bus_type from parent device — 🟡 REVIEW (Medium)

• Q1 Original trigger (2019: uevent write failure → early udevadm trigger fails → installer init panics, LP: #1845572) is from a userspace era long gone; mainline still has the fake vio parent with .dev.bus set (verified) and the world hasn't burned.
• Q2 No; never went upstream. Q3 questing/jammy ✓. Q4 No.
• Q5 Divergent sysfs layout on ppc64el (/sys/devices/vio/ attributes) vs every other distro — subtle tooling skew risk.
• Q6 Test current installers/udev with the patch dropped; either drop or finally send upstream with the rationale.
• Q7 Cascardo-era; carried 7 years without re-validation. Q8 The drop-test on ppc64el.

J15. 3b3034a8fa03 + J16. 390c59a386ae — objtool: make SLS / RETPOLINE validation fatal — 🟠 REPLACE (High)

• Q1 The intent (fail the build on missed mitigation coverage) is valid and security-relevant; the mechanism is obsolete.
• Q2 Yes — upstream CONFIG_OBJTOOL_WERROR (in lib/Kconfig.debug, verified) makes objtool warnings fatal generically, subsuming both patches. (Dimitri's 2023 lore submissions of these were superseded by that work.)
• Q3 questing/resolute ✓. Q4 Upstream went the generic-WERROR way instead.
• Q5 None known, but: upstream renamed the mitigations (CONFIG_MITIGATION_SLS, CONFIG_MITIGATION_RETPOLINE) — our unconditional return -warnings in those validators no longer matches the commit titles' claim of being config-gated; they are always-fatal for those checks now.
• Q6 Enable CONFIG_OBJTOOL_WERROR=y in the Ubuntu config and drop both patches — strictly better coverage (all objtool checks, not just two).
• Q7 FIPS/mitigation-assurance heritage (Dimitri). Q8 One test build with OBJTOOL_WERROR=y to shake out any latent warnings before flipping.

J17. 75da7ae99d46 — (no-up) Enable fips mode by default, in FIPS kernels only — 🟢 KEEP (High)

• Q1 Yes — FIPS-certified kernels must default to fips mode without bootloader edits (CONFIG_CRYPTO_FIPS=y builds only; fips=0 still honoured). Cornerstone of Ubuntu's FIPS product (LP: #2049082).
• Q2 No; upstream requires fips=1 on cmdline by design. Q3 All Ubuntu FIPS lineage kernels. Q4 No. Q5 None — no-op in non-FIPS builds (generic never sets CONFIG_CRYPTO_FIPS).
• Q6 None better; certification requires exactly this behaviour. Q7 Dimitri authored for cert workflow. Q8 Nothing.

J18. c7a17a4c8c22 — Revert "rfkill: make new event layout opt-in" — 🔴 DROP (Medium-High)

• Q1 No longer. The revert exists so jammy-era network-manager kept receiving extended rfkill events without calling the opt-in ioctl (LP: #1971418, 2022). Current NetworkManager (and bluez/g-s-d) handle mainline semantics — the opt-in ioctl exists because of the ecosystem breakage the big events caused.
• Q2 Mainline's opt-in design (RFKILL_IOCTL_MAX_SIZE, verified alive in v7.2-rc2+) is the resolved upstream answer, arrived at after upstream's own revert-and-rework cycle.
• Q3 questing carries it (inertia); no other distro diverges here.
• Q4 Upstream deliberately rejected always-on extended events (the reverted commit's comment documents bluez/g-s-d/NM breakage) — we are carrying the losing side of that decision.
• Q5 ⚠️ Dual uapi divergence: (a) non-opted-in readers get differently-sized events on Ubuntu than on every other kernel; (b) our revert removes the documented RFKILL_IOCTL_MAX_SIZE ioctl, so portable software calling it gets ENOTTY on Ubuntu.
• Q6 Drop the revert; verify current network-manager on a stonking image handles rfkill correctly (it will — upstream NM adapted in 2021).
• Q7 Timo had to fix conflicts at 6.12 — ongoing rebase cost for a stale shim.
• Q8 The one NM smoke test, then drop (questing too).