> > 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 keeps the responsibilities clean: luod manages sessions and authorization, while the kernel provides the specific mechanism for resource attribution. I agree this is a must-have feature, but I think it can be cleanly added on top of the current foundation. Pasha > > [...] > > -- > Regards, > Pratyush Yadav
