dri-devel Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel Vetter <daniel@ffwll.ch>
To: Thomas Zimmermann <tzimmermann@suse.de>
Cc: dri-devel@lists.freedesktop.org,
	Steven Price <steven.price@arm.com>,
	Neil Roberts <nroberts@igalia.com>,
	Rob Herring <robh+dt@kernel.org>,
	Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Subject: Re: [PATCH] drm/shmem-helper: Don't remove the offset in vm_area_struct pgoff
Date: Mon, 22 Feb 2021 17:21:42 +0100	[thread overview]
Message-ID: <YDPaFmG+swkP1QfJ@phenom.ffwll.local> (raw)
In-Reply-To: <8f3ea5bb-4bfa-a3de-2d45-ec7110338587@suse.de>

On Mon, Feb 22, 2021 at 03:24:17PM +0100, Thomas Zimmermann wrote:
> Hi
> 
> Am 17.02.21 um 17:59 schrieb Neil Roberts:
> > When mmapping the shmem, it would previously adjust the pgoff in the
> > vm_area_struct to remove the fake offset that is added to be able to
> > identify the buffer. This patch removes the adjustment and makes the
> > fault handler use the vm_fault address to calculate the page offset
> > instead. Although using this address is apparently discouraged, several
> > DRM drivers seem to be doing it anyway.
> > 
> > The problem with removing the pgoff is that it prevents
> > drm_vma_node_unmap from working because that searches the mapping tree
> > by address. That doesn't work because all of the mappings are at offset
> > 0. drm_vma_node_unmap is being used by the shmem helpers when purging
> > the buffer.
> 
> I just want to ask if this is how the mmap callbacks are supposed to work
> now?
> 
> I have a number of patches in here that convert several drivers to the GEM
> object's mmap callback. They might not be affected by the vm_pgoff bug, but
> I'd like to submit something that could work in the longer term.

Yeah we pretty much require the uniq vm_pgoff for runtime unmapping.
Especially with more dynamic memory managers like ttm that move buffers
around - for more static ones (most of the armsoc ones) it's just a bit a
security issue since you can potentially access memory after it's gone.
-Daniel

> Best regards
> Thomas
> 
> > 
> > It looks like panfrost is using drm_gem_shmem_purge so this might fix a
> > potential bug there.
> > 
> > Signed-off-by: Neil Roberts <nroberts@igalia.com>
> > ---
> >   drivers/gpu/drm/drm_gem_shmem_helper.c | 12 +++++++-----
> >   1 file changed, 7 insertions(+), 5 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/drm_gem_shmem_helper.c b/drivers/gpu/drm/drm_gem_shmem_helper.c
> > index 9825c378dfa6..4b14157f1962 100644
> > --- a/drivers/gpu/drm/drm_gem_shmem_helper.c
> > +++ b/drivers/gpu/drm/drm_gem_shmem_helper.c
> > @@ -526,11 +526,16 @@ static vm_fault_t drm_gem_shmem_fault(struct vm_fault *vmf)
> >   	struct drm_gem_shmem_object *shmem = to_drm_gem_shmem_obj(obj);
> >   	loff_t num_pages = obj->size >> PAGE_SHIFT;
> >   	struct page *page;
> > +	pgoff_t page_offset;
> > -	if (vmf->pgoff >= num_pages || WARN_ON_ONCE(!shmem->pages))
> > +	/* We don't use vmf->pgoff since that has the fake offset */
> > +	page_offset = (vmf->address - vma->vm_start) >> PAGE_SHIFT;
> > +
> > +	if (page_offset < 0 || page_offset >= num_pages ||
> > +	    WARN_ON_ONCE(!shmem->pages))
> >   		return VM_FAULT_SIGBUS;
> > -	page = shmem->pages[vmf->pgoff];
> > +	page = shmem->pages[page_offset];
> >   	return vmf_insert_page(vma, vmf->address, page);
> >   }
> > @@ -581,9 +586,6 @@ int drm_gem_shmem_mmap(struct drm_gem_object *obj, struct vm_area_struct *vma)
> >   	struct drm_gem_shmem_object *shmem;
> >   	int ret;
> > -	/* Remove the fake offset */
> > -	vma->vm_pgoff -= drm_vma_node_start(&obj->vma_node);
> > -
> >   	if (obj->import_attach) {
> >   		/* Drop the reference drm_gem_mmap_obj() acquired.*/
> >   		drm_gem_object_put(obj);
> > 
> 
> -- 
> Thomas Zimmermann
> Graphics Driver Developer
> SUSE Software Solutions Germany GmbH
> Maxfeldstr. 5, 90409 Nürnberg, Germany
> (HRB 36809, AG Nürnberg)
> Geschäftsführer: Felix Imendörffer
> 




> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel


-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

      reply	other threads:[~2021-02-22 16:21 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-17 16:59 [PATCH] drm/shmem-helper: Don't remove the offset in vm_area_struct pgoff Neil Roberts
2021-02-17 19:33 ` kernel test robot
2021-02-18 15:26 ` Steven Price
2021-02-18 15:30   ` Daniel Vetter
2021-02-18 15:45     ` Alyssa Rosenzweig
2021-02-18 16:15       ` Steven Price
2021-02-18 16:38         ` Rob Herring
2021-02-18 16:52           ` Steven Price
2021-02-18 17:15             ` Rob Herring
2021-02-18 18:20               ` Daniel Vetter
2021-02-19 13:36                 ` Steven Price
2021-02-19 15:13                   ` Daniel Vetter
2021-02-19 16:18                     ` Steven Price
2021-02-19 17:45                       ` Daniel Vetter
2021-02-22  8:34                         ` Boris Brezillon
2021-02-22 16:20                           ` Daniel Vetter
2021-02-23 12:42     ` Neil Roberts
2021-02-23 12:54       ` Daniel Vetter
2021-02-23 15:59         ` Neil Roberts
2021-02-23 16:40           ` Daniel Vetter
2021-02-22 14:24 ` Thomas Zimmermann
2021-02-22 16:21   ` Daniel Vetter [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YDPaFmG+swkP1QfJ@phenom.ffwll.local \
    --to=daniel@ffwll.ch \
    --cc=alyssa.rosenzweig@collabora.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=nroberts@igalia.com \
    --cc=robh+dt@kernel.org \
    --cc=steven.price@arm.com \
    --cc=tzimmermann@suse.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox