[RFC PATCH 0/3] liveupdate: Move to feature flags for LUO and memfd ABI compatibility

[Jason Gunthorpe]

On Wed, Sep 09, 2026 at 05:58:28PM -0700, Sean Christopherson wrote:
> On Fri, Sep 04, 2026, Jason Gunthorpe wrote:
> > On Fri, Sep 04, 2026 at 10:24:21PM +0000, David Matlack wrote:
> > 
> > > The proposal here (which is inspired by the KVM UAPI) is to ensure every
> > > LUO ABI struct has 2 properties:
> > > 
> > >  1. A field to encode options/features (e.g. u64 flags).
> > >  2. A way way to grow without breaking backward compatibility (e.g. so
> > >     we can add new fields).
> > > 
> > > Each flag can mean whatever it needs to. e.g. It can indicate the
> > > precence of one or more fields (i.e. new fields in the struct), or it
> > > can mean a field now has a different meaning (i.e. union in the struct).
> > > 
> > > This would enable adding support for new features without breaking
> > > backward compatibility. Downstream users would have to ensure their
> > > kernel does not start using a new feature while it can still rollback to
> > > a version that does not support the new feature.
> > 
> > This was never the biggest problem. The main issue was the functional
> > behaviors of the kernel that cannot be represented simply as data in a
> > struct with some flag bits.
> > 
> > Like for instance kernel A supports memfd folio sizes far larger than
> > kernel B because we fixed MAX_ORDER. You can't fix that just with
> > simplistic flags.
> 
> Can you elaborate on why the folio sizes matter?  Honest question, because I don't
> understand why the serialization format wouldn't express things as "N contiguous
> pages starting at PFN X".  Then the implementation would rebuild its folios as
> appropriate.

That's an idyllic view, yes, but my point is (IIRC) we didn't do
exactly that for memfd.

Sometimes you can do more and more work to try and be more and more
general but this is *alot* of work and even then eventually hits
problematic limits. Like what do you do with the sealing flags? That's
ABI breaking if the successor does not support them, and downgrades
make exactly that possible.

A CSPish user can do things like patch the new sealing flag into their
current kernel (while preventing userspace from using it), ensure
everything is updated to that, then jump ahead to a newer kernel and
enjoy the new flag with full downgrade support. There is so much more
control on their part that makes the problem far more managably simple
that upstream does not get to have.

This is why I think the very idea we can support any version pair is
too much to ask for. We should focus on supporting a small set of
version pairs and not making it too invasive or hard in the kernel or
on the maintainers.

Thus live update within a stable branch only is my proposal for
upstream support.

If it really succeeds at that and it becomes very popular, then let's
discuss upstreaming doing additional version combinations.

> I could see things like HugeTLB not working if someone booted the kernel with
> support for only 1GiB pages and then tried to feed it payload with sub-1GiB ranges.
> But to me, those sorts of things fall into the "well yeah, don't do that" category.

Okay, how about worse, todays kernel has hugetlbfs and there are
patches around to luo serialize that. Lots and lots of talks about a
post-hugetlbfs world out there.

Do we want to constrain what is possible to ensure we accomodate this
hugetlbfs serialization? I vote no. 

Do we want to reject the hugetlbfs serialization until we have a year
of debate outlining every possible ABI scenario? I also vote no.

Should we make a downgrade round trip a downstream problem? I think
so!

Jason