On Sat, Mar 08, 2025 at 12:09:53PM +0100, Christian Brauner wrote: > On Fri, Mar 07, 2025 at 11:14:17AM -0400, Jason Gunthorpe wrote: > > On Fri, Mar 07, 2025 at 10:31:39AM +0100, Christian Brauner wrote: > > > On Fri, Mar 07, 2025 at 12:57:35AM +0000, Pratyush Yadav wrote: > > > > The File Descriptor Box (FDBox) is a mechanism for userspace to name > > > > file descriptors and give them over to the kernel to hold. They can > > > > later be retrieved by passing in the same name. > > > > > > > > The primary purpose of FDBox is to be used with Kexec Handover (KHO). > > > > There are many kinds anonymous file descriptors in the kernel like > > > > memfd, guest_memfd, iommufd, etc. that would be useful to be preserved > > > > using KHO. To be able to do that, there needs to be a mechanism to label > > > > FDs that allows userspace to set the label before doing KHO and to use > > > > the label to map them back after KHO. FDBox achieves that purpose by > > > > exposing a miscdevice which exposes ioctls to label and transfer FDs > > > > between the kernel and userspace. FDBox is not intended to work with any > > > > generic file descriptor. Support for each kind of FDs must be explicitly > > > > enabled. > > > > > > This makes no sense as a generic concept. If you want to restore shmem > > > and possibly anonymous inodes files via KHO then tailor the solution to > > > shmem and anon inodes but don't make this generic infrastructure. This > > > has zero chances to cover generic files. > > > > We need it to cover a range of FD types in the kernel like iommufd and > > anonymous inode > > > vfio. > > anonymous inode Yes, I think Pratyush did not really capture that point, that it is really only for very limited FD types. Realistically probably only anonymous like things. > > It is not "generic" in the sense every FD in the kernel magicaly works > > with fdbox, but that any driver/subsystem providing a FD could be > > enlightened to support it. > > > > Very much do not want the infrastructure tied to just shmem and memfd. > > Anything you can reasonably want will either be an internal shmem mount, > devtmpfs, or anonymous inodes. Anything else isn't going to work. Yes. > I'm not yet sold that this needs to be a character device. Because > that's fundamentally limiting in how useful this can be. It is part of KHO, and I think KHO wants a character device for other reasons anyhow. The whole concept is tied to KHO intrinsically because this new file_operations callback is going to be calling KHO related functions to register the information contained in the FD with KHO. Also, I kind of expect it to be semi-destructive to the FDs in someway, especially for VFIO and iommufd. The FD will have to be prepared to go into the KHO first. > It might be way more useful if this ended up being a separate tiny > filesystem where such preserved files are simply shown as named entries > that you can open instead of ioctl()ing your way through character > devices. But I need to think about that. It could be possible, but I think this is more complex, and not really too useful. How do you store a iommufd anonymous inode in a new special filesystem? What permissions does it have after kexec? How does open work? What if you open the same path multiple times? What about the single-open rules of VFIO? How do you "open" co-linked FDs like VFIO & iommufd? A char device can give pretty reasonable answers to these questions when we don't have to pretend to be a filesytem.. Jason
