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
