Re: [PATCH v4 14/30] liveupdate: luo_session: Add ioctls for file preservation and state management
From: Pasha Tatashin <pasha.tatashin@soleen.com>
Date: 2025-10-29 20:57:47
Also in:
linux-doc, linux-fsdevel, linux-mm, lkml
On Wed, Oct 29, 2025 at 4:44 PM David Matlack [off-list ref] wrote:
On Wed, Oct 29, 2025 at 1:13 PM Pasha Tatashin [off-list ref] wrote:quoted
On Wed, Oct 29, 2025 at 3:07 PM Pratyush Yadav [off-list ref] wrote:quoted
Also, I think the model we should have is to only allow new sessions in normal state. Currently luo_session_create() allows creating a new session in updated state. This would end up mixing sessions from a previous boot and sessions from current boot. I don't really see a reason for that and I think the userspace should first call finish before starting new serialization. Keeps things simpler.It does. However, yesterday Jason Gunthorpe suggested that we simplify the uapi, at least for the initial landing, by removing the state machine during boot and allowing new sessions to be created at any time. This would also mean separating the incoming and outgoing sessions and removing the ioctl() call used to bring the machine into a normal state; instead, only individual sessions could be brought into a 'normal' state. Simplified uAPI Proposal The simplest uAPI would look like this: IOCTLs on /dev/liveupdate (to create and retrieve session FDs): LIVEUPDATE_IOCTL_CREATE_SESSION LIVEUPDATE_IOCTL_RETRIEVE_SESSION IOCTLs on session FDs: LIVEUPDATE_CMD_SESSION_PRESERVE_FD LIVEUPDATE_CMD_SESSION_RETRIEVE_FD LIVEUPDATE_CMD_SESSION_FINISHShould we drop LIVEUPDATE_CMD_SESSION_FINISH and do this work in close(session_fd)? close() can return an error. I think this cleans up a few parts of the uAPI: - One less ioctl. - The only way to get an outgoing session would be through LIVEUPDATE_IOCTL_CREATE_SESSION. The kernel does not have to deal with an empty incoming session "becoming" an outgoing session (as described below). - The kernel can properly leak the session and its resources by refusing to close the session file.
I was considering this. But, in AFAIK even if close() fails, the FD is still closed, therefore, I am not aware of any existing api that relies on close() to fail. The finish or (set event if we decide to expands events in the future) should be a separate ioctl() and close() should release FD unconditionally as it still would do even if return failure from release()