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

[Luca Boccassi <luca.boccassi@gmail.com>]

On Thu, 16 Jul 2026 at 16:23, Pratyush Yadav <pratyush@kernel.org> wrote:
>
> On Wed, Jul 15 2026, 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
> >> /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.
>
> AFAIK I doesn't do so today. You can either create FDs and save them via
> FDStore, and systemd will put them in its global session, or you grab a
> session directly from /dev/liveupdate and save the session via FDStore.
> Maybe in the future it will add the capability to vend out sessions
> through dbus as well, but at least today it doesn't do so.

I've added it after Pasha asked for it, will be in the next release:

https://www.freedesktop.org/software/systemd/man/devel/systemd.service.html#LUOSession=