From: tarunsahu@google.com
To: loganodell@google.com, alex@shazbot.org, dwmw2@infradead.org,
seanjc@google.com, Mike Rapoport <rppt@kernel.org>,
will@kernel.org, pbonzini@redhat.com, jgg@nvidia.com,
Pasha Tatashin <pasha.tatashin@soleen.com>,
arnd@arndb.de, linux-mm@kvack.org,
Andrew Morton <akpm@linux-foundation.org>,
oupton@kernel.org, baolu.lu@linux.intel.com,
David Matlack <dmatlack@google.com>,
robin.murphy@arm.com, maz@kernel.org,
Alexander Graf <graf@amazon.com>,
joro@8bytes.org, Bjorn Helgaas <bhelgaas@google.com>,
kevin.tian@intel.com, Pratyush Yadav <pratyush@kernel.org>
Cc: linux-kernel@vger.kernel.org, kexec@lists.infradead.org
Subject: Re: [RFC PATCH v3 0/4] liveupdate: Add feature header for fine-grained ABI compatibility
Date: Mon, 26 Oct 2026 18:58:47 +0000 [thread overview]
Message-ID: <9huz8q3k9tlk.fsf@tarunix.c.googlers.com> (raw)
In-Reply-To: <20261026174217.603114-1-tarunsahu@google.com>
Withdrawing this version because of the following reasons.
1. KHO also has versioning which can also share the same concept of the
feature flags, And the header can be shared amongst KHO and LUO. In next
version, I will include this.
2. If there are any open threads in the V2, Can be settled based on this V3
reference. This V3 has included the suggestion from V2, like updated
truth table, nr_features based flags array, ABI wrapper MACRO etc.
~Tarun
Tarun Sahu <tarunsahu@google.com> writes:
> Changes since RFC v2 [1]:
> - Dropped the file handler compatible rename and per-FD handler
> selection patches.
> - Replaced the fixed 128-byte header with an expandable struct
> luo_ser_hdr (size, nr_features, flags[]), kept separate from the
> payload structure. The header is 8 bytes with no features and 16 bytes
> for 1 to 32 features.
> - Each subsystem declares its wrapper once with DECLARE_LUO_SER_WRAP(),
> passing its feature enum MAX; the macro sizes the flags entries and
> generates name##_wrap_init(), so callers never pass sizes or counts.
> The target kernel reaches the payload with luo_ser_payload().
> - Feature bits describe only what each preserved object uses. The target
> kernel checks them against its own boolean supported table, and the
> header is trusted as the source of truth: validation only rejects a
> required feature the target kernel does not support. 0b10 is reserved.
> - Moved the __packed removal into its own patch (1/4) and added a KUnit
> test (4/4).
>
> Changes since RFC v1 [2]:
> - Replaced the 3-mask (supp, req, active) design with a header of 2-bit
> feature states.
>
> [1] https://lore.kernel.org/all/20261021152527.375070-1-tarunsahu@google.com/
> [2] https://lore.kernel.org/all/20260903023452.721732-1-loganodell@google.com/
>
> ==========COVER LETTER==============
>
> LUO and its file handlers rely only on coarse-grained compatibility
> strings (such as luo-v5 and memfd-v2) to validate handed-over state
> across kexec. Any change to a serialized structure, even an optional
> additive field, requires bumping the string and breaks live update
> between adjacent kernels.
>
> This series adds a feature header (struct luo_ser_hdr) ahead of
> serialized LUO structures so subsystems can evolve their serialized state
> per feature. Each subsystem groups its serialized fields under feature
> indices, with index 0 for the base fields. New capabilities append fields
> at the end of the payload under a new feature index, and retired fields
> stay in place so offsets never shift. Only a change that feature flags
> cannot express needs a new handler with a bumped compatibility string.
>
> Each feature has a 2-bit state set by the source kernel:
> - LUO_FEAT_ABSENT (0b00): not in the payload; a target kernel that
> supports it can use default values.
> - LUO_FEAT_OPTIONAL (0b01): in the payload; a target kernel that does not
> support it ignores the data.
> - LUO_FEAT_REQUIRED (0b11): in the payload; a target kernel that does not
> support it rejects the state with -EOPNOTSUPP.
> - LUO_FEAT_RESERVED (0b10): reserved, not checked by the target kernel.
>
> The target kernel checks the header against its own boolean supported
> table:
>
> Source hdr Target supported[i] Action
> ---------- ------------------- ----------------------------------
> 00 0 or 1 Accept: feature absent in payload
> 01 0 Accept: ignore the feature data
> 01 1 Accept: use the feature data
> 11 0 Reject: -EOPNOTSUPP
> 11 1 Accept: use the feature data
> 10 0 or 1 Reserved: not checked by target
>
> struct luo_ser_hdr holds the total size of the serialized structure
> (u32), the number of features (u32 nr_features), and 64-bit flags
> entries with 32 features each. With no features the header is 8 bytes;
> with 1 to 32 features it is 16 bytes.
>
> On the source side, a subsystem declares its wrapper once with
> DECLARE_LUO_SER_WRAP(name, expected_size, nr_features), passing its
> feature enum MAX, then calls name##_wrap_init(), marks the features the
> preserved object uses with luo_ser_set_feat(), and fills wrap->ser. On
> the target side, incoming state is never cast to the wrapper, since the
> source kernel may use a different number of flags entries. The target
> kernel calls luo_ser_hdr_validate(), finds the payload with
> luo_ser_payload(), and reads the fields of a feature only after
> luo_ser_get_feat() shows it present.
>
> Patch 1 removes __packed from the LUO and memfd ABI structures. Patch 2
> adds the header and converts struct luo_ser. Patch 3 converts memfd and
> bumps its compatibility string to memfd-v3. Patch 4 adds KUnit tests.
>
> Tarun Sahu (4):
> liveupdate: Remove __packed from LUO and memfd ABI structures
> liveupdate: Add feature header for fine-grained ABI compatibility
> mm: memfd_luo: Add the feature header
> liveupdate: Add KUnit test for the feature header helpers
>
> MAINTAINERS | 1 +
> include/linux/kho/abi/luo.h | 359 ++++++++++++++++++++++++---
> include/linux/kho/abi/memfd.h | 43 +++-
> kernel/liveupdate/luo_core.c | 62 +++--
> lib/Kconfig.debug | 16 ++
> lib/tests/Makefile | 1 +
> lib/tests/liveupdate_feature_kunit.c | 118 +++++++++
> mm/memfd_luo.c | 68 +++--
> 8 files changed, 577 insertions(+), 91 deletions(-)
> create mode 100644 lib/tests/liveupdate_feature_kunit.c
>
> --
> 2.56.0.307.g5fe7bd680c-goog
prev parent reply other threads:[~2026-10-26 18:58 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-26 17:42 Tarun Sahu
2026-10-26 17:42 ` [RFC PATCH v3 1/4] liveupdate: Remove __packed from LUO and memfd ABI structures Tarun Sahu
2026-10-26 17:42 ` [RFC PATCH v3 2/4] liveupdate: Add feature header for fine-grained ABI compatibility Tarun Sahu
2026-10-26 17:42 ` [RFC PATCH v3 3/4] mm: memfd_luo: Add the feature header Tarun Sahu
2026-10-26 17:42 ` [RFC PATCH v3 4/4] liveupdate: Add KUnit test for the feature header helpers Tarun Sahu
2026-10-26 18:58 ` tarunsahu [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=9huz8q3k9tlk.fsf@tarunix.c.googlers.com \
--to=tarunsahu@google.com \
--cc=akpm@linux-foundation.org \
--cc=alex@shazbot.org \
--cc=arnd@arndb.de \
--cc=baolu.lu@linux.intel.com \
--cc=bhelgaas@google.com \
--cc=dmatlack@google.com \
--cc=dwmw2@infradead.org \
--cc=graf@amazon.com \
--cc=jgg@nvidia.com \
--cc=joro@8bytes.org \
--cc=kevin.tian@intel.com \
--cc=kexec@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=loganodell@google.com \
--cc=maz@kernel.org \
--cc=oupton@kernel.org \
--cc=pasha.tatashin@soleen.com \
--cc=pbonzini@redhat.com \
--cc=pratyush@kernel.org \
--cc=robin.murphy@arm.com \
--cc=rppt@kernel.org \
--cc=seanjc@google.com \
--cc=will@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®