[PATCH] liveupdate: add LIVEUPDATE_SESSION_GET_NAME ioctl

[Luca Boccassi]

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
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.

Aside from all this, given the session name is input to the FD, it is
also good design to have a way to get it out of the FD again on
demand, regardless of the use case. Right now this is not possible,
since resolving /proc/fd/ is lossy and fails completely once the
session name goes above 52 characters.