Re: [PATCH RFC 00/10] RDMA/FS DAX truncate proposal
From: Jason Gunthorpe
Date: Fri Jun 07 2019 - 11:14:32 EST
On Fri, Jun 07, 2019 at 07:52:13AM -0700, Ira Weiny wrote:
> On Fri, Jun 07, 2019 at 09:17:29AM -0300, Jason Gunthorpe wrote:
> > On Fri, Jun 07, 2019 at 12:36:36PM +0200, Jan Kara wrote:
> > > Because the pins would be invisible to sysadmin from that point on.
> > It is not invisible, it just shows up in a rdma specific kernel
> > interface. You have to use rdma netlink to see the kernel object
> > holding this pin.
> > If this visibility is the main sticking point I suggest just enhancing
> > the existing MR reporting to include the file info for current GUP
> > pins and teaching lsof to collect information from there as well so it
> > is easy to use.
> > If the ownership of the lease transfers to the MR, and we report that
> > ownership to userspace in a way lsof can find, then I think all the
> > concerns that have been raised are met, right?
> I was contemplating some new lsof feature yesterday. But what I don't think we
> want is sysadmins to have multiple tools for multiple subsystems. Or even have
> to teach lsof something new for every potential new subsystem user of GUP pins.
Well.. it is a bit tricky, but you'd have to arrange for the lease
object to have a list of 'struct files' that are holding the
The first would be the file that did the fcntl, the next would be all
the files that did longterm GUP - which means longterm GUP has to have
a chardev file/etc as well (seems OK)
Then lsof could query the list of lease objects for each file it
encounters and print them out too.