From: Thomas Zimmermann <tzimmermann@suse.de>
To: Neil Roberts <nroberts@igalia.com>,
Rob Herring <robh+dt@kernel.org>,
Tomeu Vizoso <tomeu@tomeuvizoso.net>,
Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>,
Steven Price <steven.price@arm.com>
Cc: dri-devel@lists.freedesktop.org
Subject: Re: [PATCH] drm/shmem-helper: Don't remove the offset in vm_area_struct pgoff
Date: Mon, 22 Feb 2021 15:24:17 +0100 [thread overview]
Message-ID: <8f3ea5bb-4bfa-a3de-2d45-ec7110338587@suse.de> (raw)
In-Reply-To: <20210217165910.3820374-1-nroberts@igalia.com>
[-- Attachment #1.1.1: Type: text/plain, Size: 2938 bytes --]
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.
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
[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]
[-- Attachment #2: Type: text/plain, Size: 160 bytes --]
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
next prev parent reply other threads:[~2021-02-22 14:24 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 [this message]
2021-02-22 16:21 ` Daniel Vetter
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=8f3ea5bb-4bfa-a3de-2d45-ec7110338587@suse.de \
--to=tzimmermann@suse.de \
--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=tomeu@tomeuvizoso.net \
/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