[RFC PATCH] liveupdate: Allow multiple openers for /dev/liveupdate

[David Matlack]

On Fri, Jul 17, 2026 at 10:07 AM Pasha Tatashin
<pasha.tatashin at soleen.com> wrote:
>
> On 07-16 17:41, Pratyush Yadav wrote:
> > On Thu, Jul 16 2026, Pasha Tatashin wrote:
> >
> > > On 07-15 14:23, Jason Gunthorpe wrote:
> > >> On Wed, Jul 15, 2026 at 03:50:33PM +0200, Pratyush Yadav wrote:
> > >> > Hi David,
> > >> >
> > >> > On Tue, Jul 14 2026, David Matlack wrote:
> > >> >
> > >> > > Remove the single-opener restriction for /dev/liveupdate by removing the
> > >> > > atomic in_use tracking and the exclusive open check in luo_open() that
> > >> > > returned -EBUSY. Protect luo_session_deserialize() with a mutex guard so
> > >> > > that concurrent open attempts by multiple processes safely executes
> > >> > > deserialization only once. Update liveupdate selftest to verify that
> > >> > > multiple concurrent openers succeed.
> > >> > >
> > >> > > LUO does not inherently require a single opener. There is some
> > >> > > documentation about it simplifying state management, but the only thing
> > >> > > it actually protects is the session deserialization during first open,
> > >> > > which can be easily handled with a mutex.
> > >> > >
> > >> > > Relaxing the single-opener requirement avoids the kernel forcing a
> > >> > > design pattern on userspace that it itself does not require, e.g.
> > >> > > allowing multiple userspace processes to create and manage sessions.
> > >> >
> > >> > Agreed. When the kernel had a global state machine in the early versions
> > >> > of LUO, this might have been more relevant. With sessions, even if we
> > >> > later add a state machine, it likely will be per-session instead of
> > >> > being global. So I think letting userspace open /dev/liveupdate multiple
> > >> > times makes a lot of sense.
> > >> >
> > >> > Also, today's systemd only supports preserving individual files, and
> > >> > does not hand out sessions. To get sessions, userspace must open
> > >
> > > It should in the future, because of permissions issue, see below.
> > >
> > >> > /dev/liveupdate and create a session. This opens up room for one bad
> > >> > process to block every other process from creating sessions. It also
> > >> > imposes a need for userspace to add a polling/retry logic for getting
> > >> > sessions and serializes their execution around this point.
> > >>
> > >> Shouldn't systemd open and own /dev/liveupdate? That was at least what
> > >> I originally expected here, you'd talk to it and get a session FD
> > >> through dbus.
> > >>
> > >> Moving to multi-opening /dev/liveupdate and removing visibility of
> > >> what sessions are open from systemd is a different model
> > >>
> > >> Not saying this patch is wrong or anything, but that I don't really
> > >> understand what kind of model you are going for now.
> > >
> > > CC ca for systemd's take.
> > >
> > > /dev/liveupdate should only be accessed by a privileged process, and
> > > sessions should be accessed by whoever originally created them. While
> > > this patch does not change the permissions, it paves the road for us to
> > > move in the wrong direction: instead of having a privileged userspace
> > > manager that distributes the sessions to their rightful owners, it
> > > encourages userspace to work around the permissions so that VMMs access
> > > /dev/liveupdate to retrieve or store their sessions directly. This would
> > > also allow them to access sessions belonging to any other participant of
> > > the live update.
> >
> > But you can still do all this. In fact, systemd's release notes suggest
> > doing so [0]:
> >
> >     Units can also create their own LUO Sessions by talking to the
> >     kernel directly, and store them in their FD Stores, and those will
> >     also be preserved and passed down to the unit after kexec
>
> They should not. Ideally, systemd should be the sole entity
> communicating directly with /dev/liveupdate.
>
> >
> > Having a single opener does not in practice prevent userspace from
> > creating sessions directly. All it does is to force them to turn the
> > open into a polling loop. So I don't think single open achieves the goal
>
> That is a fragile design, and they should avoid it. To be clear, I do
> not see any functional bugs in this patch, but I still do not understand
> the underlying use case.
>
> LUO should rely on a single manager agent that interacts with clients to
> create, preserve across reboots, and restore session IDs on their behalf.
>
> In fact, systemd is the only userspace process that AFAIK survives
> across the reboot() boundary; all other processes are terminated before
> reboot() is invoked. Relying on multiple independent LUO managers is
> therefore architecturally, wrong as they will close sessionfds.
>
> While the kernel can technically allow multiple openers for
> /dev/liveupdate, I do not see what problem this actually solves.
> Instead, it seems to encourage bad architectural decisions in userspace.

> > you think it should. Userspace already works around this restriction.
> >
> > So as long as we keep access to /dev/liveupdate restricted to privileged
> > processes, I don't see why single open is any better.
>
> What is the concrete use case for this patch, once we live in the world
> where systemd is fully capable of creating, storing, and retrieving
> sessions?

I guess I would flip the question around: What problem does the kernel
requiring a single opener of /dev/liveupdate solve?

If systemd wants to have a single opener model it can certainly
enforce that itself without the kernel's help.

I'm not sure why the kernel needs to impose a restriction on userspace
that it doesn't require itself.

>
> >
> > [0] https://github.com/systemd/systemd/releases#release-v261
> >
> > >
> > > Instead, sessions should be created and retrieved by a privileged
> > > process that knows to send them back to their rightful owner after
> > > retrieval.
> > >
> > > Also, as a minor concern, each userspace LUO manager needs its own
> > > session to maintain state. This means that by allowing multiple
> > > managers, they may run into naming conflicts for those state sessions.
> >
> > --
> > Regards,
> > Pratyush Yadav