From: "Christian König" <christian.koenig@amd.com>
To: Dmitry Osipenko <dmitry.osipenko@collabora.com>,
Sumit Semwal <sumit.semwal@linaro.org>
Cc: Mauro Carvalho Chehab <mchehab@kernel.org>,
Benjamin Gaignard <benjamin.gaignard@collabora.com>,
Thomas Zimmermann <tzimmermann@suse.de>,
Arnd Bergmann <arnd@arndb.de>,
Emil Velikov <emil.l.velikov@gmail.com>,
intel-gfx@lists.freedesktop.org,
Marek Szyprowski <m.szyprowski@samsung.com>,
linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org,
Tomasz Figa <tfiga@chromium.org>,
Tomi Valkeinen <tomba@kernel.org>,
Thierry Reding <thierry.reding@gmail.com>,
John Stultz <jstultz@google.com>,
Gerd Hoffmann <kraxel@redhat.com>,
linux-tegra@vger.kernel.org, kernel@collabora.com,
linux-media@vger.kernel.org
Subject: Re: [PATCH v4 5/6] dma-buf: Change locking policy for mmap()
Date: Wed, 21 Jun 2023 07:42:44 +0200 [thread overview]
Message-ID: <3ddf2152-392f-095d-3db6-c0c5c56e0cbf@amd.com> (raw)
In-Reply-To: <1a04706a-caee-114c-6b6e-e4fdb815e619@collabora.com>
Am 20.06.23 um 17:58 schrieb Dmitry Osipenko:
> On 5/31/23 22:58, Dmitry Osipenko wrote:
>> On 5/30/23 01:39, Dmitry Osipenko wrote:
>>> Change locking policy of mmap() callback, making exporters responsible
>>> for handling dma-buf reservation locking. Previous locking policy stated
>>> that dma-buf is locked for both importers and exporters by the dma-buf
>>> core, which caused a deadlock problem for DRM drivers in a case of
>>> self-imported dma-bufs which required to take the lock from the DRM
>>> exporter side.
>>>
>>> Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
>>> Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
>>> ---
>>> drivers/dma-buf/dma-buf.c | 17 +++--------------
>>> 1 file changed, 3 insertions(+), 14 deletions(-)
>> Christian, you acked the drm patch of this series sometime ago, perhaps
>> it also implies implicit ack to this patch, but I'd prefer to have the
>> explicit ack. I'll apply this series to drm-misc later this week if
>> you'll approve this dma-buf change. Thanks in advance!
> I'll merge the patches tomorrow. If there are any additional comments,
> then please don't hesitate to post them.
Sorry for not responding earlier, I have been moving both my office as
well as my household and still catching up.
I don't have time for an in-deep review, but my ack stands for the whole
series.
Regards,
Christian.
WARNING: multiple messages have this Message-ID (diff)
From: "Christian König" <christian.koenig@amd.com>
To: Dmitry Osipenko <dmitry.osipenko@collabora.com>,
Sumit Semwal <sumit.semwal@linaro.org>
Cc: Mauro Carvalho Chehab <mchehab@kernel.org>,
Benjamin Gaignard <benjamin.gaignard@collabora.com>,
Thomas Zimmermann <tzimmermann@suse.de>,
Arnd Bergmann <arnd@arndb.de>,
intel-gfx@lists.freedesktop.org,
Marek Szyprowski <m.szyprowski@samsung.com>,
linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org,
Tomasz Figa <tfiga@chromium.org>,
Tomi Valkeinen <tomba@kernel.org>,
John Stultz <jstultz@google.com>,
Gerd Hoffmann <kraxel@redhat.com>,
Daniel Vetter <daniel@ffwll.ch>,
linux-tegra@vger.kernel.org, kernel@collabora.com,
linux-media@vger.kernel.org
Subject: Re: [Intel-gfx] [PATCH v4 5/6] dma-buf: Change locking policy for mmap()
Date: Wed, 21 Jun 2023 07:42:44 +0200 [thread overview]
Message-ID: <3ddf2152-392f-095d-3db6-c0c5c56e0cbf@amd.com> (raw)
In-Reply-To: <1a04706a-caee-114c-6b6e-e4fdb815e619@collabora.com>
Am 20.06.23 um 17:58 schrieb Dmitry Osipenko:
> On 5/31/23 22:58, Dmitry Osipenko wrote:
>> On 5/30/23 01:39, Dmitry Osipenko wrote:
>>> Change locking policy of mmap() callback, making exporters responsible
>>> for handling dma-buf reservation locking. Previous locking policy stated
>>> that dma-buf is locked for both importers and exporters by the dma-buf
>>> core, which caused a deadlock problem for DRM drivers in a case of
>>> self-imported dma-bufs which required to take the lock from the DRM
>>> exporter side.
>>>
>>> Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
>>> Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
>>> ---
>>> drivers/dma-buf/dma-buf.c | 17 +++--------------
>>> 1 file changed, 3 insertions(+), 14 deletions(-)
>> Christian, you acked the drm patch of this series sometime ago, perhaps
>> it also implies implicit ack to this patch, but I'd prefer to have the
>> explicit ack. I'll apply this series to drm-misc later this week if
>> you'll approve this dma-buf change. Thanks in advance!
> I'll merge the patches tomorrow. If there are any additional comments,
> then please don't hesitate to post them.
Sorry for not responding earlier, I have been moving both my office as
well as my household and still catching up.
I don't have time for an in-deep review, but my ack stands for the whole
series.
Regards,
Christian.
WARNING: multiple messages have this Message-ID (diff)
From: "Christian König" <christian.koenig@amd.com>
To: Dmitry Osipenko <dmitry.osipenko@collabora.com>,
Sumit Semwal <sumit.semwal@linaro.org>
Cc: linux-media@vger.kernel.org, dri-devel@lists.freedesktop.org,
linux-kernel@vger.kernel.org, intel-gfx@lists.freedesktop.org,
linux-tegra@vger.kernel.org, kernel@collabora.com,
Benjamin Gaignard <benjamin.gaignard@collabora.com>,
Brian Starkey <Brian.Starkey@arm.com>,
John Stultz <jstultz@google.com>,
Gerd Hoffmann <kraxel@redhat.com>,
Daniel Vetter <daniel@ffwll.ch>,
Jani Nikula <jani.nikula@linux.intel.com>,
Arnd Bergmann <arnd@arndb.de>,
Thomas Zimmermann <tzimmermann@suse.de>,
Tomi Valkeinen <tomba@kernel.org>,
Thierry Reding <thierry.reding@gmail.com>,
Tomasz Figa <tfiga@chromium.org>,
Marek Szyprowski <m.szyprowski@samsung.com>,
Mauro Carvalho Chehab <mchehab@kernel.org>,
Emil Velikov <emil.l.velikov@gmail.com>
Subject: Re: [PATCH v4 5/6] dma-buf: Change locking policy for mmap()
Date: Wed, 21 Jun 2023 07:42:44 +0200 [thread overview]
Message-ID: <3ddf2152-392f-095d-3db6-c0c5c56e0cbf@amd.com> (raw)
In-Reply-To: <1a04706a-caee-114c-6b6e-e4fdb815e619@collabora.com>
Am 20.06.23 um 17:58 schrieb Dmitry Osipenko:
> On 5/31/23 22:58, Dmitry Osipenko wrote:
>> On 5/30/23 01:39, Dmitry Osipenko wrote:
>>> Change locking policy of mmap() callback, making exporters responsible
>>> for handling dma-buf reservation locking. Previous locking policy stated
>>> that dma-buf is locked for both importers and exporters by the dma-buf
>>> core, which caused a deadlock problem for DRM drivers in a case of
>>> self-imported dma-bufs which required to take the lock from the DRM
>>> exporter side.
>>>
>>> Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
>>> Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
>>> ---
>>> drivers/dma-buf/dma-buf.c | 17 +++--------------
>>> 1 file changed, 3 insertions(+), 14 deletions(-)
>> Christian, you acked the drm patch of this series sometime ago, perhaps
>> it also implies implicit ack to this patch, but I'd prefer to have the
>> explicit ack. I'll apply this series to drm-misc later this week if
>> you'll approve this dma-buf change. Thanks in advance!
> I'll merge the patches tomorrow. If there are any additional comments,
> then please don't hesitate to post them.
Sorry for not responding earlier, I have been moving both my office as
well as my household and still catching up.
I don't have time for an in-deep review, but my ack stands for the whole
series.
Regards,
Christian.
next prev parent reply other threads:[~2023-06-21 5:42 UTC|newest]
Thread overview: 56+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-29 22:39 [PATCH v4 0/6] Move dma-buf mmap() reservation locking down to exporters Dmitry Osipenko
2023-05-29 22:39 ` [Intel-gfx] " Dmitry Osipenko
2023-05-29 22:39 ` Dmitry Osipenko
2023-05-29 22:39 ` [PATCH v4 1/6] media: videobuf2: Don't assert held reservation lock for dma-buf mmapping Dmitry Osipenko
2023-05-29 22:39 ` [Intel-gfx] " Dmitry Osipenko
2023-05-29 22:39 ` Dmitry Osipenko
2023-05-29 22:39 ` [PATCH v4 2/6] dma-buf/heaps: " Dmitry Osipenko
2023-05-29 22:39 ` [Intel-gfx] " Dmitry Osipenko
2023-05-29 22:39 ` Dmitry Osipenko
2023-06-21 17:21 ` T.J. Mercier
2023-06-21 17:21 ` [Intel-gfx] " T.J. Mercier
2023-06-21 17:21 ` T.J. Mercier
2023-06-21 18:16 ` Dmitry Osipenko
2023-06-21 18:16 ` [Intel-gfx] " Dmitry Osipenko
2023-06-21 18:16 ` Dmitry Osipenko
2023-06-21 19:24 ` T.J. Mercier
2023-06-21 19:24 ` T.J. Mercier
2023-06-21 19:24 ` [Intel-gfx] " T.J. Mercier
2023-05-29 22:39 ` [PATCH v4 3/6] udmabuf: " Dmitry Osipenko
2023-05-29 22:39 ` [Intel-gfx] " Dmitry Osipenko
2023-05-29 22:39 ` Dmitry Osipenko
2023-05-29 22:39 ` [PATCH v4 4/6] drm: " Dmitry Osipenko
2023-05-29 22:39 ` [Intel-gfx] " Dmitry Osipenko
2023-05-29 22:39 ` Dmitry Osipenko
2023-05-29 22:39 ` [PATCH v4 5/6] dma-buf: Change locking policy for mmap() Dmitry Osipenko
2023-05-29 22:39 ` [Intel-gfx] " Dmitry Osipenko
2023-05-29 22:39 ` Dmitry Osipenko
[not found] ` <91466907-d4e1-1619-27a8-a49a01cbc8f1@collabora.com>
2023-06-20 15:58 ` Dmitry Osipenko
2023-06-20 15:58 ` [Intel-gfx] " Dmitry Osipenko
2023-06-20 15:58 ` Dmitry Osipenko
2023-06-21 5:42 ` Christian König [this message]
2023-06-21 5:42 ` Christian König
2023-06-21 5:42 ` [Intel-gfx] " Christian König
2023-06-21 18:17 ` Dmitry Osipenko
2023-06-21 18:17 ` Dmitry Osipenko
2023-06-21 18:17 ` Dmitry Osipenko
2023-05-29 22:39 ` [PATCH v4 6/6] drm/shmem-helper: Switch to reservation lock Dmitry Osipenko
2023-05-29 22:39 ` [Intel-gfx] " Dmitry Osipenko
2023-05-29 22:39 ` Dmitry Osipenko
2023-06-26 9:40 ` Boris Brezillon
2023-06-26 9:40 ` [Intel-gfx] " Boris Brezillon
2023-06-26 9:40 ` Boris Brezillon
2023-06-26 9:57 ` Boris Brezillon
2023-06-26 9:57 ` [Intel-gfx] " Boris Brezillon
2023-06-26 9:57 ` Boris Brezillon
2023-06-26 13:05 ` Dmitry Osipenko
2023-06-26 13:05 ` [Intel-gfx] " Dmitry Osipenko
2023-06-26 13:05 ` Dmitry Osipenko
2023-06-26 13:05 ` Dmitry Osipenko
2023-06-26 13:05 ` [Intel-gfx] " Dmitry Osipenko
2023-06-26 13:05 ` Dmitry Osipenko
2023-05-31 2:17 ` [Intel-gfx] ✗ Fi.CI.SPARSE: warning for Move dma-buf mmap() reservation locking down to exporters (rev4) Patchwork
2023-05-31 2:35 ` [Intel-gfx] ✗ Fi.CI.BAT: failure " Patchwork
2023-06-21 19:13 ` [PATCH v4 0/6] Move dma-buf mmap() reservation locking down to exporters Dmitry Osipenko
2023-06-21 19:13 ` [Intel-gfx] " Dmitry Osipenko
2023-06-21 19:13 ` 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=3ddf2152-392f-095d-3db6-c0c5c56e0cbf@amd.com \
--to=christian.koenig@amd.com \
--cc=arnd@arndb.de \
--cc=benjamin.gaignard@collabora.com \
--cc=dmitry.osipenko@collabora.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=emil.l.velikov@gmail.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=jstultz@google.com \
--cc=kernel@collabora.com \
--cc=kraxel@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=linux-tegra@vger.kernel.org \
--cc=m.szyprowski@samsung.com \
--cc=mchehab@kernel.org \
--cc=sumit.semwal@linaro.org \
--cc=tfiga@chromium.org \
--cc=thierry.reding@gmail.com \
--cc=tomba@kernel.org \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.