On Fri, Jul 21, 2023, Paolo Bonzini wrote: > On 7/19/23 01:44, Sean Christopherson wrote: > > + inode = alloc_anon_inode(mnt->mnt_sb); > > + if (IS_ERR(inode)) > > + return PTR_ERR(inode); > > + > > + err = security_inode_init_security_anon(inode, &qname, NULL); > > + if (err) > > + goto err_inode; > > + > > I don't understand the need to have a separate filesystem. If it is to > fully setup the inode before it's given a struct file, why not just export > anon_inode_make_secure_inode instead of security_inode_init_security_anon? Ugh, this is why comments are important, I can't remember either. I suspect I implemented a dedicated filesystem to kinda sorta show that we could allow userspace to provide the mount point with e.g. NUMA hints[*]. But my preference would be to not support a userspace provided mount and instead implement fbind() to let userspace control NUMA and whatnot. [*] https://lore.kernel.org/all/ef48935e5e6f947f6f0c6d748232b14ef5d5ad70.1681176340.git.ackerleytng@xxxxxxxxxx
