On Tue, Aug 06, 2024 at 02:58:59PM -0300, Jason Gunthorpe wrote: > On Tue, Jul 30, 2024 at 06:09:27AM +0100, Al Viro wrote: > > > * ib_uverbs_open_xrcd(). FWIW, a closer look shows that the > > damn thing is buggy - it accepts _any_ descriptor and pins the associated > > inode. mount tmpfs, open a file there, feed it to that, unmount and > > watch the show... > > What happens? There is still an igrab() while it is in the red black > tree? ... which does not render the mount busy. > > AFAICS, that's done for the sake of libibverbs and > > I've no idea how it's actually used - all examples I'd been able to > > find use -1 for descriptor here. Needs to be discussed with infiniband > > folks (Sean Hefty?). For now, leave that as-is. > > The design seems insane, but it is what it is from 20 years ago.. > > Userspace can affiliate this "xrc domain" with a file in the > filesystem. Any file. That is actually a deliberate part of the API. > > This is done as some ugly way to pass xrc domain object from process A > to process B. IIRC the idea is process A will affiliate the object > with a file and then B will be able to access the shared object if B > is able to open the file. > > It looks like the code keeps a red/black tree of this association, and > holds an igrab while the inode is in that tree.. You need a mount (or file) reference to prevent fs destruction by umount. igrab() pins an _inode_, but the caller must arrange for the hosting filesystem to stay alive.
