Re: [PATCH] RFC: dma-buf: Require VM_SPECIAL vma for mmap

From: "Christian König" <christian.koenig@amd.com>
To: Jason Gunthorpe <jgg@ziepe.ca>, Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: DRI Development <dri-devel@lists.freedesktop.org>,
	Intel Graphics Development <intel-gfx@lists.freedesktop.org>,
	Suren Baghdasaryan <surenb@google.com>,
	Matthew Wilcox <willy@infradead.org>,
	John Stultz <john.stultz@linaro.org>,
	Daniel Vetter <daniel.vetter@intel.com>,
	Sumit Semwal <sumit.semwal@linaro.org>,
	"open list:DMA BUFFER SHARING FRAMEWORK" 
	<linux-media@vger.kernel.org>,
	"moderated list:DMA BUFFER SHARING FRAMEWORK" 
	<linaro-mm-sig@lists.linaro.org>
Subject: Re: [PATCH] RFC: dma-buf: Require VM_SPECIAL vma for mmap
Date: Fri, 5 Feb 2021 09:05:36 +0100	[thread overview]
Message-ID: <8e1de27f-9200-8748-730e-4bd7b94444b3@amd.com> (raw)
In-Reply-To: <20210204183808.GY4718@ziepe.ca>

Am 04.02.21 um 19:38 schrieb Jason Gunthorpe:
> On Thu, Feb 04, 2021 at 06:16:27PM +0100, Daniel Vetter wrote:
>> On Thu, Feb 4, 2021 at 5:13 PM Jason Gunthorpe <jgg@ziepe.ca> wrote:
>>> On Wed, Feb 03, 2021 at 10:19:48PM +0100, Daniel Vetter wrote:
>>>> tldr; DMA buffers aren't normal memory, expecting that you can use
>>>> them like that (like calling get_user_pages works, or that they're
>>>> accounting like any other normal memory) cannot be guaranteed.
>>>>
>>>> Since some userspace only runs on integrated devices, where all
>>>> buffers are actually all resident system memory, there's a huge
>>>> temptation to assume that a struct page is always present and useable
>>>> like for any more pagecache backed mmap. This has the potential to
>>>> result in a uapi nightmare.
>>>>
>>>> To stop this gap require that DMA buffer mmaps are VM_SPECIAL, which
>>>> blocks get_user_pages and all the other struct page based
>>>> infrastructure for everyone. In spirit this is the uapi counterpart to
>>>> the kernel-internal CONFIG_DMABUF_DEBUG.
>>> Fast gup needs the special flag set on the PTE as well.. Feels weird
>>> to have a special VMA without also having special PTEs?
>> There's kinda no convenient & cheap way to check for the pte_special
>> flag. This here should at least catch accidental misuse, people
>> building their own ptes we can't stop. Maybe we should exclude
>> VM_MIXEDMAP to catch vm_insert_page in one of these.
>>
>> Hm looking at code I think we need to require VM_PFNMAP here to stop
>> vm_insert_page. And looking at the various functions, that seems to be
>> required (and I guess VM_IO is more for really funky architectures
>> where io-space is somewhere else?). I guess I should check for
>> VM_PFNMAP instead of VM_SPECIAL?
> Well, you said the goal was to block GUP usage, that won't happen
> without the PTE special flag, at least on x86

When is that special flag being set?

> So, really, what you are saying is all dmabuf users should always use
> vmf_insert_pfn_prot() or something similar - and never insert_page/etc?

Exactly, yes.

Christian.

> It might make sense to check the vma flags in all the insert paths, eg
> vm_insert_page() can't work with VMAs that should not have struct
> pages in them (eg VM_SPECIAl, VM_PFNMAP, !VM_MIXEMAP if I understand
> it right)
>
> At least as some VM debug option
>
> Jason