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:

quoted

	* 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.

quoted

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.