Re: [RFC PATCH 0/6] Introduce file handler dependency level

[Pratyush Yadav]

Hi Sami,

I've skimmed the patches. I didn't dive too deep into the code, but here
is at least my first reaction.

On Thu, Oct 01 2026, Samiullah Khawaja wrote:

> LUO allows preservation of FDs into sessions. An FD can depend on other
> FDs, and for some FDs this can mean the dependency must be preserved
> before it due to various reasons including immutability and performance.
> See discussion on FD dependency patch series [1] and documentation [2]
> for details. Also see the Liveupdate IOMMU [3] and guest_memfd
> preservation [4] patch series for examples. These dependencies are
> enforced by the file handlers, and userspace is responsible for
> preserving the FDs in the correct order.
>
> This RFC proposes a mechanism that allows userspace to preserve the FDs
> as a batch, and the kernel preserves them in the required order. This
> allows the VMM to preserve a bag of FDs without worrying about the
> order. A new ioctl is added that allows userspace to provide an array of
> FDs and tokens for preservation. This gives the kernel the token and the
> intent to preserve every FD in the batch up front.
>
> This RFC introduces the concept of file handler levels. Each file
> handler offers a certain type of resource or functionality that relates
> to other file handlers. These can be represented by levels. This RFC
> adds the following levels and more can be added later:
>
>  - Default (no level set)
>  - Memory Providers
>  - Memory Mappers (or users)
>  - Devices
>
> The levels are optional static configurations of how the file handlers
> relate to each other. Each level represents a class of file handler,
> which fixes the order of preservation between them.
>
> The levels are spaced out to allow addition of new levels. LUO can use
> these levels to deduce the order of preservation of a batch of FDs.

I think you need to explain what problem you actually solve here.

This seems like a lot of complexity to essentially turn file handler
dependencies into heuristics. Because you basically assign a "priority
number" to each file type. But dependencies can really be complicated
and I think modelling them as absolute integers is going to paint us in
a corner real quick.

And I don't get what this buys us. Why not take the much much simpler
path where a file handler just rejects a file if its dependency isn't
there? This would force userspace to preserve files in the right order.

And userspace doesn't necessarily have to to anything complicated
either. It just needs to write the code in a way that a memfd is
preserved before its iommufd. So we leave it up to userspace to figure
out the order, and in the kernel we only _enforce_ it.

This also lets us express the real dependencies and we don't have to do
the dance of giving each file type a number and trying to make sure the
number sits in the right place on the list for all use cases.

Or, if you _don't_ want to burden userspace with this work, why not take
the files in any order and do the final check at freeze()?

>
> The batch is atomic: either all FDs are preserved or none are, and on
> failure the index of the failing FD is returned to userspace. The
> existing LIVEUPDATE_SESSION_PRESERVE_FD ioctl is unchanged and behaves
> as a batch of one. Note that this does not break compatibility and
> userspace can still attempt to preserve FDs individually using the
> existing preservation ioctl.
>
> The patch series builds on top of the Liveupdate IOMMU series [3] to
> demonstrate the FD dependency. The full tree, including the
> dependencies, is available at:
> https://github.com/samikhawaja/linux/tree/luo/fd-dependency-rfc
>
> I will present this at the Live Update MC at LPC 2026. I will also talk
> about alternative solutions I considered.
>
> Future work:
>
>  - Allow file handlers to be preserved at multiple levels to allow
>    resolving circular dependencies.
>
> Looking forward to your feedback on this.
>
> [1] https://lore.kernel.org/all/alrDpAMknlYN9jL9@xxxxxxxxxx/#t
> [2] https://lore.kernel.org/all/20260910173659.1945246-2-skhawaja@xxxxxxxxxx/
> [3] https://lore.kernel.org/all/20260921004834.2601285-1-skhawaja@xxxxxxxxxx/
> [4] https://lore.kernel.org/all/20260728121138.1103610-9-tarunsahu@xxxxxxxxxx/
>
> Samiullah Khawaja (6):
>   liveupdate: Introduce file handler dependency level
>   mm/memfd_luo: Set Liveupdate level of a memfd file handler
>   iommufd: Set liveupdate file handler level
>   vfio/pci: Set live update file handler level
>   selftests/liveupdate: Add API to preserve a batch of FDs
>   iommufd/selftests: Preserve all the FDs in a batch
>
>  drivers/iommu/iommufd/liveupdate.c            |   1 +
>  drivers/vfio/pci/vfio_pci_liveupdate.c        |   1 +
>  include/linux/liveupdate.h                    |  24 ++
>  include/uapi/linux/liveupdate.h               |  39 +++
>  kernel/liveupdate/luo_file.c                  | 316 ++++++++++++------
>  kernel/liveupdate/luo_internal.h              |   2 +
>  kernel/liveupdate/luo_session.c               |  45 +++
>  mm/memfd_luo.c                                |   1 +
>  .../iommu/iommufd_liveupdate_kexec_test.c     |  27 +-
>  .../liveupdate/lib/include/libliveupdate.h    |   2 +
>  .../selftests/liveupdate/lib/lu_utils.c       |  20 ++
>  11 files changed, 379 insertions(+), 99 deletions(-)
>
>
> base-commit: 945d61765894dda2f0344de50cb1ade2e51b66fd

-- 
Regards,
Pratyush Yadav