[PATCH] liveupdate: add LIVEUPDATE_SESSION_GET_NAME ioctl

[Pasha Tatashin]

On Tue, Mar 31, 2026 at 3:07 PM Luca Boccassi <luca.boccassi at gmail.com> wrote:
>
> On Tue, 31 Mar 2026 at 19:34, Pasha Tatashin <pasha.tatashin at soleen.com> wrote:
> >
> > On Tue, Mar 31, 2026 at 1:56 PM <luca.boccassi at gmail.com> wrote:
> > >
> > > From: Luca Boccassi <luca.boccassi at gmail.com>
> > >
> > > Userspace when requesting a session specifies a name and gets a FD,
> > > but then there is no way to go back the other way and get the name
> > > given a LUO session FD. This is problematic especially when there
> > > is a userspace orchestrator that wants to check what FDs it is
> > > handling for clients.
> > >
> > > Resolving the /proc/self/fd/X is lossy as that has a hard limit
> > > of characters, so names might be truncated. Also requiring going
> > > through procfs and doing manual string mangling is not a nice
> > > pattern.
> >
> > Hi Luca,
> >
> > Thank you for working on this.
> >
> > This needs more explanation. The way I see it, the user orchestrator
> > can be the only one that has access to /dev/liveupdate (and this is
> > actually enforced by kernel). It opens it and creates session_fds for
> > any client out there. So, the orchestrator already has the FDs and
> > sends them to clients(e.g. via SCM_RIGHTS). It then monitors the PIDs
> > of the clients, and if they die, it closes the session_fds for them,
> > as their data does not need to be preserved.
> >
> > Could you please explain why the user orchestrator would need to query
> > the session_fds, since it is the one that creates them in the first
> > place and has to keep them open in order to preserve them during a
> > live update?
>
> The orchestrator cannot and will not hold on to all this state, that
> is not possible. It will simply hand out session FDs on-demand via an
> IPC, enforcing a naming convention for the client, and immediately
> forget about them. Clients will hold them and use them as they see
> fit, and then store them in the FD store on shutdown if they want to
> commit them, and that's where the orchestrator will get them back, and

I see. The idea is to expand the LUO Session API to be compatible with
the systemd FD store API.

> they need to be verified that they come from the right cgroup, what
> the client's portion of the name is to be able to hand them back after
> reboot, and so on.

So, if I understand correctly, the enforcement of who gets a systemd
stored fd returned to them is based on the cgroup name, right?
Presumably, after a reboot, each VMM would have to start in a separate
cgroup (using the same name as in the previous kernel) and request its
session FDs back from systemd. That is what will be used to verify
ownership, am I correct?