[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20210208183348.GV4718@ziepe.ca>
Date: Mon, 8 Feb 2021 14:33:48 -0400
From: Jason Gunthorpe <jgg@...pe.ca>
To: David Hildenbrand <david@...hat.com>
Cc: Zhou Wang <wangzhou1@...ilicon.com>, linux-kernel@...r.kernel.org,
iommu@...ts.linux-foundation.org, linux-mm@...ck.org,
linux-arm-kernel@...ts.infradead.org, linux-api@...r.kernel.org,
Andrew Morton <akpm@...ux-foundation.org>,
Alexander Viro <viro@...iv.linux.org.uk>,
gregkh@...uxfoundation.org, song.bao.hua@...ilicon.com,
kevin.tian@...el.com, jean-philippe@...aro.org,
eric.auger@...hat.com, liguozhu@...ilicon.com,
zhangfei.gao@...aro.org, Sihang Chen <chensihang1@...ilicon.com>
Subject: Re: [RFC PATCH v3 1/2] mempinfd: Add new syscall to provide memory
pin
On Mon, Feb 08, 2021 at 09:14:28AM +0100, David Hildenbrand wrote:
> People are constantly struggling with the effects of long term pinnings
> under user space control, like we already have with vfio and RDMA.
>
> And here we are, adding yet another, easier way to mess with core MM in the
> same way. This feels like a step backwards to me.
Yes, this seems like a very poor candidate to be a system call in this
format. Much too narrow, poorly specified, and possibly security
implications to allow any process whatsoever to pin memory.
I keep encouraging people to explore a standard shared SVA interface
that can cover all these topics (and no, uaccel is not that
interface), that seems much more natural.
I still haven't seen an explanation why DMA is so special here,
migration and so forth jitter the CPU too, environments that care
about jitter have to turn this stuff off.
Jason
Powered by blists - more mailing lists