On Tue, 2021-11-30 at 11:01 +0100, Fabian Grünbichler wrote: [...] > possibly interesting in that context (I asked/posted the link in > #debian-kernel a few days ago as well) - these BTF sections now actually > reference the BTF info in the kernel image itself (as part of the > deduplication of shared information), which makes the latter part of the > ABI, and AFAICT this is not (yet?) tracked in Debian.. > > https://lore.kernel.org/all/1637926692.uyvrkty41j.astr...@nora.none/ > > an otherwise ABI compatible kernel upgrade thus has the potential to > break module loading altogether, and I'd recommend disabling the split > BTF feature for the time being unless you plan on bumping ABI for every > kernel update anyway.
Yes, that is interesting/concerning. If we continue to not bump the ABI number on every update, then I think: 1. In-tree modules should not be loadable between an upgrade and a reboot. (This can happen already for specific modules, due to symbol version changes that we think don't affect out-of-tree modules.) Alternatively, they could still be loadable but then their BTF info should be completely discarded. 2. Out-of-tree modules should be built without BTF deduplication, or without BTF info. The main reason for not bumping the ABI number every time is to avoid forcing an unnecessary rebuild of out-of-tree modules. We could try switching to something like RHEL's "weak-update" mechanism where ABI- compatible out-of-tree modules are automatically linked into a new version's modules directory without rebuilding them. In that case we would still need to implement item (2) above. Ben. -- Ben Hutchings This sentence contradicts itself - no actually it doesn't.
signature.asc
Description: This is a digitally signed message part
