On Tue, Aug 26, 2025 at 2:24 PM Jason Gunthorpe <jgg@xxxxxxxxxx> wrote: > > On Tue, Aug 26, 2025 at 01:54:31PM +0000, Pasha Tatashin wrote: > > > > https://github.com/googleprodkernel/linux-liveupdate/tree/luo/v3 > > > > > > > > Changelog from v2: > > > > - Addressed comments from Mike Rapoport and Jason Gunthorpe > > > > - Only one user agent (LiveupdateD) can open /dev/liveupdate > > > > - With the above changes, sessions are not needed, and should be > > > > maintained by the user-agent itself, so removed support for > > > > sessions. > > > > > > If all the FDs are restored in the agent's context, this assigns all the > > > resources to the agent. For example, if the agent restores a memfd, all > > > the memory gets charged to the agent's cgroup, and the client gets none > > > of it. This makes it impossible to do any kind of resource limits. > > > > > > This was one of the advantages of being able to pass around sessions > > > instead of FDs. The agent can pass on the right session to the right > > > client, and then the client does the restore, getting all the resources > > > charged to it. > > > > > > If we don't allow this, I think we will make LUO/LiveupdateD unsuitable > > > for many kinds of workloads. Do you have any ideas on how to do proper > > > resource attribution with the current patches? If not, then perhaps we > > > should reconsider this change? > > > > Hi Pratyush, > > > > That's an excellent point, and you're right that we must have a > > solution for correct resource charging. > > > > I'd prefer to keep the session logic in the userspace agent (luod > > https://tinyurl.com/luoddesign). > > > > For the charging problem, I believe there's a clear path forward with > > the current ioctl-based API. The design of the ioctl commands (with a > > size field in each struct) is intentionally extensible. In a follow-up > > patch, we can extend the liveupdate_ioctl_fd_restore struct to include > > a target pid field. The luod agent, would then be able to restore an > > FD on behalf of a client and instruct the kernel to charge the > > associated resources to that client's PID. > > This wasn't quite the idea though.. > > The sessions sub FD were intended to be passed directly to other > processes though unix sockets and fd passing so they could run their > own ioctls in their own context for both save and restore. The ioctls > available on the sessions should be specifically narrowed to be safe > for this. > > I can understand not implementing session FDs in the first version, > but when sessions FD are available they should work like this and > solve the namespace/cgroup/etc issues. > > Passing some PID in an ioctl is not a great idea... Hi Jason, I'm trying to understand the drawbacks of the PID-based approach. Could you elaborate on why passing a PID in the RESTORE_FD ioctl is not a good idea?
