[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20240806175859.GT676757@ziepe.ca>
Date: Tue, 6 Aug 2024 14:58:59 -0300
From: Jason Gunthorpe <jgg@...pe.ca>
To: Al Viro <viro@...iv.linux.org.uk>
Cc: linux-fsdevel@...r.kernel.org,
Linus Torvalds <torvalds@...ux-foundation.org>,
Christian Brauner <brauner@...nel.org>, bpf@...r.kernel.org,
Amir Goldstein <amir73il@...il.com>, kvm@...r.kernel.org,
cgroups@...r.kernel.org, netdev@...r.kernel.org
Subject: Re: [PATCHSET][RFC] struct fd and memory safety
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?
> 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..
Jason
Powered by blists - more mailing lists