From: "Christian König" <christian.koenig@amd.com>
To: "Dmitry Osipenko" <dmitry.osipenko@collabora.com>,
"Thomas Hellström (Intel)" <thomas_os@shipmail.org>
Cc: "David Airlie" <airlied@linux.ie>,
dri-devel@lists.freedesktop.org,
virtualization@lists.linux-foundation.org,
"Thierry Reding" <thierry.reding@gmail.com>,
"Gerd Hoffmann" <kraxel@redhat.com>,
"Dmitry Osipenko" <digetx@gmail.com>,
kernel@collabora.com, "Sumit Semwal" <sumit.semwal@linaro.org>,
"Mauro Carvalho Chehab" <mchehab@kernel.org>,
"Steven Price" <steven.price@arm.com>,
"Gustavo Padovan" <gustavo.padovan@collabora.com>,
"Alyssa Rosenzweig" <alyssa.rosenzweig@collabora.com>,
linux-media@vger.kernel.org, intel-gfx@lists.freedesktop.org,
linaro-mm-sig@lists.linaro.org,
"Rodrigo Vivi" <rodrigo.vivi@intel.com>,
linux-tegra@vger.kernel.org,
"Gurchetan Singh" <gurchetansingh@chromium.org>,
"Tvrtko Ursulin" <tvrtko.ursulin@linux.intel.com>,
"Daniel Almeida" <daniel.almeida@collabora.com>,
amd-gfx@lists.freedesktop.org,
"Tomeu Vizoso" <tomeu.vizoso@collabora.com>,
"Gert Wollny" <gert.wollny@collabora.com>,
"Pan, Xinhui" <Xinhui.Pan@amd.com>,
linux-kernel@vger.kernel.org, "Tomasz Figa" <tfiga@chromium.org>,
"Qiang Yu" <yuq825@gmail.com>,
"Thomas Zimmermann" <tzimmermann@suse.de>,
"Alex Deucher" <alexander.deucher@amd.com>,
"Robin Murphy" <robin.murphy@arm.com>,
"Christian König" <christian.koenig@amd.com>,
"Emil Velikov" <"emil.l.veli kov"@gmail.com>
Subject: Re: [Linaro-mm-sig] Re: [PATCH v6 02/22] drm/gem: Move mapping of imported dma-bufs to drm_gem_mmap_obj()
Date: Mon, 4 Jul 2022 14:33:19 +0200 [thread overview]
Message-ID: <0335814b-dc11-4a54-9f24-bb4e9dbef35c@amd.com> (raw)
In-Reply-To: <467a1cee-ba8c-98f3-0398-2a7a5a90b5c3@collabora.com>
Am 30.06.22 um 01:06 schrieb Dmitry Osipenko:
> On 6/29/22 11:43, Thomas Hellström (Intel) wrote:
>> On 6/29/22 10:22, Dmitry Osipenko wrote:
>>> On 6/29/22 09:40, Thomas Hellström (Intel) wrote:
>>>> On 5/27/22 01:50, Dmitry Osipenko wrote:
>>>>> Drivers that use drm_gem_mmap() and drm_gem_mmap_obj() helpers don't
>>>>> handle imported dma-bufs properly, which results in mapping of
>>>>> something
>>>>> else than the imported dma-buf. For example, on NVIDIA Tegra we get a
>>>>> hard
>>>>> lockup when userspace writes to the memory mapping of a dma-buf that
>>>>> was
>>>>> imported into Tegra's DRM GEM.
>>>>>
>>>>> To fix this bug, move mapping of imported dma-bufs to
>>>>> drm_gem_mmap_obj().
>>>>> Now mmaping of imported dma-bufs works properly for all DRM drivers.
>>>> Same comment about Fixes: as in patch 1,
>>>>> Cc: stable@vger.kernel.org
>>>>> Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
>>>>> ---
>>>>> drivers/gpu/drm/drm_gem.c | 3 +++
>>>>> drivers/gpu/drm/drm_gem_shmem_helper.c | 9 ---------
>>>>> drivers/gpu/drm/tegra/gem.c | 4 ++++
>>>>> 3 files changed, 7 insertions(+), 9 deletions(-)
>>>>>
>>>>> diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
>>>>> index 86d670c71286..7c0b025508e4 100644
>>>>> --- a/drivers/gpu/drm/drm_gem.c
>>>>> +++ b/drivers/gpu/drm/drm_gem.c
>>>>> @@ -1038,6 +1038,9 @@ int drm_gem_mmap_obj(struct drm_gem_object *obj,
>>>>> unsigned long obj_size,
>>>>> if (obj_size < vma->vm_end - vma->vm_start)
>>>>> return -EINVAL;
>>>>> + if (obj->import_attach)
>>>>> + return dma_buf_mmap(obj->dma_buf, vma, 0);
>>>> If we start enabling mmaping of imported dma-bufs on a majority of
>>>> drivers in this way, how do we ensure that user-space is not blindly
>>>> using the object mmap without calling the needed DMA_BUF_IOCTL_SYNC
>>>> which is needed before and after cpu access of mmap'ed dma-bufs?
>>>>
>>>> I was under the impression (admittedly without looking) that the few
>>>> drivers that actually called into dma_buf_mmap() had some private
>>>> user-mode driver code in place that ensured this happened.
>>> Since it's a userspace who does the mapping, then it should be a
>>> responsibility of userspace to do all the necessary syncing.
>> Sure, but nothing prohibits user-space to ignore the syncing thinking
>> "It works anyway", testing those drivers where the syncing is a NOP. And
>> when a driver that finally needs syncing is tested it's too late to fix
>> all broken user-space.
>>
>>> I'm not
>>> sure whether anyone in userspace really needs to map imported dma-bufs
>>> in practice. Nevertheless, this use-case is broken and should be fixed
>>> by either allowing to do the mapping or prohibiting it.
>>>
>> Then I'd vote for prohibiting it, at least for now. And for the future
>> moving forward we could perhaps revisit the dma-buf need for syncing,
>> requiring those drivers that actually need it to implement emulated
>> coherent memory which can be done not too inefficiently (vmwgfx being
>> one example).
> Alright, I'll change it to prohibit the mapping. This indeed should be a
> better option.
Oh, yes please. But I would expect that some people start screaming.
Over time I've got tons of TTM patches because people illegally tried to
mmap() imported DMA-bufs in their driver.
Anyway this is probably the right thing to do and we can work on fixing
the fallout later on.
Regards,
Christian.
next prev parent reply other threads:[~2022-07-04 16:20 UTC|newest]
Thread overview: 62+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-05-26 23:50 [PATCH v6 00/22] Add generic memory shrinker to VirtIO-GPU and Panfrost DRM drivers Dmitry Osipenko
2022-05-26 23:50 ` [PATCH v6 01/22] drm/gem: Properly annotate WW context on drm_gem_lock_reservations() error Dmitry Osipenko
2022-06-28 20:12 ` Thomas Hellström (Intel)
2022-06-29 8:23 ` Dmitry Osipenko
2022-05-26 23:50 ` [PATCH v6 02/22] drm/gem: Move mapping of imported dma-bufs to drm_gem_mmap_obj() Dmitry Osipenko
2022-06-29 6:40 ` Thomas Hellström (Intel)
2022-06-29 8:22 ` Dmitry Osipenko
2022-06-29 8:43 ` Thomas Hellström (Intel)
2022-06-29 23:06 ` Dmitry Osipenko
2022-07-04 12:33 ` Christian König [this message]
2022-07-04 22:44 ` [Linaro-mm-sig] " Dmitry Osipenko
2022-05-26 23:50 ` [PATCH v6 03/22] drm/panfrost: Put mapping instead of shmem obj on panfrost_mmu_map_fault_addr() error Dmitry Osipenko
2022-05-26 23:50 ` [PATCH v6 04/22] drm/panfrost: Fix shrinker list corruption by madvise IOCTL Dmitry Osipenko
2022-05-27 15:56 ` Alyssa Rosenzweig
2022-05-30 9:41 ` Steven Price
2022-05-26 23:50 ` [PATCH v6 05/22] drm/virtio: Correct drm_gem_shmem_get_sg_table() error handling Dmitry Osipenko
2022-05-26 23:50 ` [PATCH v6 06/22] drm/virtio: Check whether transferred 2D BO is shmem Dmitry Osipenko
2022-05-26 23:50 ` [PATCH v6 07/22] drm/virtio: Unlock reservations on virtio_gpu_object_shmem_init() error Dmitry Osipenko
2022-05-26 23:50 ` [PATCH v6 08/22] drm/virtio: Unlock reservations on dma_resv_reserve_fences() error Dmitry Osipenko
2022-06-29 6:43 ` Thomas Hellström (Intel)
2022-05-26 23:50 ` [PATCH v6 09/22] drm/virtio: Use appropriate atomic state in virtio_gpu_plane_cleanup_fb() Dmitry Osipenko
2022-05-26 23:50 ` [PATCH v6 10/22] drm/shmem-helper: Add missing vunmap on error Dmitry Osipenko
2022-05-26 23:50 ` [PATCH v6 11/22] drm/shmem-helper: Correct doc-comment of drm_gem_shmem_get_sg_table() Dmitry Osipenko
2022-05-26 23:50 ` [PATCH v6 12/22] drm/virtio: Simplify error handling of virtio_gpu_object_create() Dmitry Osipenko
2022-05-26 23:50 ` [PATCH v6 13/22] drm/virtio: Improve DMA API usage for shmem BOs Dmitry Osipenko
2022-05-26 23:50 ` [PATCH v6 14/22] dma-buf: Introduce new locking convention Dmitry Osipenko
2022-05-30 6:50 ` Christian König
2022-05-30 13:26 ` Dmitry Osipenko
2022-05-30 13:41 ` Christian König
2022-05-30 13:57 ` Dmitry Osipenko
2022-06-28 21:26 ` Thomas Hellström (Intel)
2022-07-01 10:43 ` Dmitry Osipenko
2022-07-04 22:38 ` Dmitry Osipenko
2022-07-05 10:52 ` Dmitry Osipenko
2022-05-26 23:50 ` [PATCH v6 15/22] drm/shmem-helper: Don't use vmap_use_count for dma-bufs Dmitry Osipenko
2022-05-26 23:50 ` [PATCH v6 16/22] drm/shmem-helper: Use reservation lock Dmitry Osipenko
2022-05-26 23:50 ` [PATCH v6 17/22] drm/shmem-helper: Add generic memory shrinker Dmitry Osipenko
2022-06-05 16:47 ` Daniel Vetter
2022-06-05 18:32 ` Rob Clark
2022-06-05 18:45 ` Daniel Vetter
2022-06-06 10:57 ` Christian König
2022-06-07 15:33 ` Dmitry Osipenko
2022-06-19 17:53 ` Rob Clark
2022-06-20 14:08 ` Dmitry Osipenko
2022-06-20 15:18 ` Rob Clark
2022-06-24 20:23 ` Daniel Vetter
2022-06-24 20:21 ` Daniel Vetter
2022-06-20 15:37 ` Rob Clark
2022-06-21 16:39 ` Dmitry Osipenko
2022-05-26 23:50 ` [PATCH v6 18/22] drm/gem: Add drm_gem_pin_unlocked() Dmitry Osipenko
2022-05-26 23:50 ` [PATCH v6 19/22] drm/virtio: Support memory shrinking Dmitry Osipenko
2022-05-26 23:50 ` [PATCH v6 20/22] drm/virtio: Use dev_is_pci() Dmitry Osipenko
2022-05-26 23:50 ` [PATCH v6 21/22] drm/virtio: Return proper error codes instead of -1 Dmitry Osipenko
2022-05-26 23:50 ` [PATCH v6 22/22] drm/panfrost: Switch to generic memory shrinker Dmitry Osipenko
2022-05-27 11:48 ` Alyssa Rosenzweig
2022-06-10 14:40 ` [PATCH v6 00/22] Add generic memory shrinker to VirtIO-GPU and Panfrost DRM drivers Dmitry Osipenko
2022-06-28 12:31 ` Robin Murphy
2022-06-28 12:50 ` Dmitry Osipenko
2022-06-28 16:48 ` Rob Clark
2022-06-28 23:11 ` Dmitry Osipenko
2022-06-28 12:51 ` Dmitry Osipenko
2022-06-28 13:11 ` Dmitry Osipenko
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=0335814b-dc11-4a54-9f24-bb4e9dbef35c@amd.com \
--to=christian.koenig@amd.com \
--cc="emil.l.veli kov"@gmail.com \
--cc=Xinhui.Pan@amd.com \
--cc=airlied@linux.ie \
--cc=alexander.deucher@amd.com \
--cc=alyssa.rosenzweig@collabora.com \
--cc=amd-gfx@lists.freedesktop.org \
--cc=daniel.almeida@collabora.com \
--cc=digetx@gmail.com \
--cc=dmitry.osipenko@collabora.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=gert.wollny@collabora.com \
--cc=gurchetansingh@chromium.org \
--cc=gustavo.padovan@collabora.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=kernel@collabora.com \
--cc=kraxel@redhat.com \
--cc=linaro-mm-sig@lists.linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=linux-tegra@vger.kernel.org \
--cc=mchehab@kernel.org \
--cc=robin.murphy@arm.com \
--cc=rodrigo.vivi@intel.com \
--cc=steven.price@arm.com \
--cc=sumit.semwal@linaro.org \
--cc=tfiga@chromium.org \
--cc=thierry.reding@gmail.com \
--cc=thomas_os@shipmail.org \
--cc=tomeu.vizoso@collabora.com \
--cc=tvrtko.ursulin@linux.intel.com \
--cc=tzimmermann@suse.de \
--cc=virtualization@lists.linux-foundation.org \
--cc=yuq825@gmail.com \
/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;
as well as URLs for NNTP newsgroup(s).