On Mon, Oct 09, 2023, Al Viro wrote: > On Thu, Sep 28, 2023 at 07:22:16PM -0700, Sean Christopherson wrote: > > On Thu, 28 Sep 2023 14:06:51 -0400, Paolo Bonzini wrote: > > > Use a run-of-the-mill anonymous inode, there is nothing useful > > > being provided by kvm_gmem_fs. > > > > > > > > > > Applied to kvm-x86 guest_memfd, thanks! > > > > [1/1] kvm: guestmem: do not use a file system > > https://github.com/kvm-x86/linux/commit/0f7e60a5f42a > > Please, revert; this is completely broken. anon_inode_getfile() > yields a file with the same ->f_inode every time it is called. > > Again, ->f_inode of those things is shared to hell and back, > very much by design. You can't modify its ->i_op or anything > other field, for that matter. No information can be stored > in that thing - you are only allowed to use the object you've > passed via 'priv' argument. Yeah, we found that out the hard way. Is using the "secure" variant to get a per-file inode a sane approach, or is that abuse that's going to bite us too? /* * Use the so called "secure" variant, which creates a unique inode * instead of reusing a single inode. Each guest_memfd instance needs * its own inode to track the size, flags, etc. */ file = anon_inode_getfile_secure(anon_name, &kvm_gmem_fops, gmem, O_RDWR, NULL);
