Re: [RFC PATCH 1/5] misc: introduce FDBox

[Jason Gunthorpe]

On Tue, Mar 18, 2025 at 03:25:25PM +0100, Christian Brauner wrote:

> > It is not really a stash, it is not keeping files, it is hardwired to
> 
> Right now as written it is keeping references to files in these fdboxes
> and thus functioning both as a crippled high-privileged fdstore and a
> serialization mechanism. 

I think Pratyush went a bit overboard on that, I can see it is useful
for testing, but really the kho control FD should be in either
serializing or deserializing mode and it should not really act as an
FD store.

However, edge case handling makes this a bit complicated. 

Once a FD is submitted to be serialized that FD has to be frozen and
can't be allowed to change anymore.

If the kexec process aborts then we need to unwind all of this stuff
and unfreeze all the FDs.

It sure would be nice if the freezing process could be managed
generically somehow.

One option for freezing would have the kernel enforce that userspace
has closed and idled the FD everywhere (eg check the struct file
refcount == 1). If userspace doesn't have access to the FD then it is
effectively frozen.

In this case the error path would need to bring the FD back out of the
fdbox.

Jason