Messages in this thread | | | Subject | Re: [RFC PATCH v2 00/19] RDMA/FS DAX truncate proposal V1,000,002 ;-) | From | John Hubbard <> | Date | Mon, 19 Aug 2019 20:09:33 -0700 |
| |
On 8/19/19 6:20 PM, Dave Chinner wrote: > On Mon, Aug 19, 2019 at 05:05:53PM -0700, John Hubbard wrote: >> On 8/19/19 2:24 AM, Dave Chinner wrote: >>> On Mon, Aug 19, 2019 at 08:34:12AM +0200, Jan Kara wrote: >>>> On Sat 17-08-19 12:26:03, Dave Chinner wrote: >>>>> On Fri, Aug 16, 2019 at 12:05:28PM -0700, Ira Weiny wrote: >>>>>> On Thu, Aug 15, 2019 at 03:05:58PM +0200, Jan Kara wrote: >>>>>>> On Wed 14-08-19 11:08:49, Ira Weiny wrote: >>>>>>>> On Wed, Aug 14, 2019 at 12:17:14PM +0200, Jan Kara wrote: >> ... >> >> Any thoughts about sockets? I'm looking at net/xdp/xdp_umem.c which pins >> memory with FOLL_LONGTERM, and wondering how to make that work here. > > I'm not sure how this interacts with file mappings? I mean, this > is just pinning anonymous pages for direct data placement into > userspace, right? > > Are you asking "what if this pinned memory was a file mapping?", > or something else?
Yes, mainly that one. Especially since the FOLL_LONGTERM flag is already there in xdp_umem_pin_pages(), unconditionally. So the simple rules about struct *vaddr_pin usage (set it to NULL if FOLL_LONGTERM is not set) are not going to work here.
> >> These are close to files, in how they're handled, but just different >> enough that it's not clear to me how to make work with this system. > > I'm guessing that if they are pinning a file backed mapping, they > are trying to dma direct to the file (zero copy into page cache?) > and so they'll need to either play by ODP rules or take layout > leases, too.... >
OK. I was just wondering if there was some simple way to dig up a struct file associated with a socket (I don't think so), but it sounds like this is an exercise that's potentially different for each subsystem.
thanks, -- John Hubbard NVIDIA
| |