From: Dmitry Osipenko <dmitry.osipenko@collabora.com> To: "Christian König" <christian.koenig@amd.com>, "David Airlie" <airlied@linux.ie>, "Gerd Hoffmann" <kraxel@redhat.com>, "Gurchetan Singh" <gurchetansingh@chromium.org>, "Chia-I Wu" <olvaffe@gmail.com>, "Daniel Vetter" <daniel@ffwll.ch>, "Daniel Almeida" <daniel.almeida@collabora.com>, "Gert Wollny" <gert.wollny@collabora.com>, "Gustavo Padovan" <gustavo.padovan@collabora.com>, "Daniel Stone" <daniel@fooishbar.org>, "Tomeu Vizoso" <tomeu.vizoso@collabora.com>, "Maarten Lankhorst" <maarten.lankhorst@linux.intel.com>, "Maxime Ripard" <mripard@kernel.org>, "Thomas Zimmermann" <tzimmermann@suse.de>, "Rob Herring" <robh@kernel.org>, "Steven Price" <steven.price@arm.com>, "Alyssa Rosenzweig" <alyssa.rosenzweig@collabora.com>, "Rob Clark" <robdclark@gmail.com>, "Emil Velikov" <emil.l.velikov@gmail.com>, "Robin Murphy" <robin.murphy@arm.com>, "Qiang Yu" <yuq825@gmail.com>, "Sumit Semwal" <sumit.semwal@linaro.org>, "Pan, Xinhui" <Xinhui.Pan@amd.com>, "Thierry Reding" <thierry.reding@gmail.com>, "Tomasz Figa" <tfiga@chromium.org>, "Marek Szyprowski" <m.szyprowski@samsung.com>, "Mauro Carvalho Chehab" <mchehab@kernel.org>, "Alex Deucher" <alexander.deucher@amd.com>, "Jani Nikula" <jani.nikula@linux.intel.com>, "Joonas Lahtinen" <joonas.lahtinen@linux.intel.com>, "Rodrigo Vivi" <rodrigo.vivi@intel.com>, "Tvrtko Ursulin" <tvrtko.ursulin@linux.intel.com> Cc: intel-gfx@lists.freedesktop.org, linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, virtualization@lists.linux-foundation.org, linaro-mm-sig@lists.linaro.org, amd-gfx@lists.freedesktop.org, linux-tegra@vger.kernel.org, Dmitry Osipenko <digetx@gmail.com>, kernel@collabora.com, linux-media@vger.kernel.org Subject: Re: [PATCH v6 14/22] dma-buf: Introduce new locking convention Date: Mon, 30 May 2022 16:57:22 +0300 [thread overview] Message-ID: <7372dd1b-06f7-5336-4738-15f9b4d4d4b3@collabora.com> (raw) In-Reply-To: <02e7946b-34ca-b48e-1ba6-e7b63740a2d9@amd.com> On 5/30/22 16:41, Christian König wrote: > Hi Dmitry, > > Am 30.05.22 um 15:26 schrieb Dmitry Osipenko: >> Hello Christian, >> >> On 5/30/22 09:50, Christian König wrote: >>> Hi Dmitry, >>> >>> First of all please separate out this patch from the rest of the series, >>> since this is a complex separate structural change. >> I assume all the patches will go via the DRM tree in the end since the >> rest of the DRM patches in this series depend on this dma-buf change. >> But I see that separation may ease reviewing of the dma-buf changes, so >> let's try it. > > That sounds like you are underestimating a bit how much trouble this > will be. > >>> I have tried this before and failed because catching all the locks in >>> the right code paths are very tricky. So expect some fallout from this >>> and make sure the kernel test robot and CI systems are clean. >> Sure, I'll fix up all the reported things in the next iteration. >> >> BTW, have you ever posted yours version of the patch? Will be great if >> we could compare the changed code paths. > > No, I never even finished creating it after realizing how much work it > would be. > >>>> This patch introduces new locking convention for dma-buf users. From >>>> now >>>> on all dma-buf importers are responsible for holding dma-buf >>>> reservation >>>> lock around operations performed over dma-bufs. >>>> >>>> This patch implements the new dma-buf locking convention by: >>>> >>>> 1. Making dma-buf API functions to take the reservation lock. >>>> >>>> 2. Adding new locked variants of the dma-buf API functions for >>>> drivers >>>> that need to manage imported dma-bufs under the held lock. >>> Instead of adding new locked variants please mark all variants which >>> expect to be called without a lock with an _unlocked postfix. >>> >>> This should make it easier to remove those in a follow up patch set and >>> then fully move the locking into the importer. >> Do we really want to move all the locks to the importers? Seems the >> majority of drivers should be happy with the dma-buf helpers handling >> the locking for them. > > Yes, I clearly think so. > >> >>>> 3. Converting all drivers to the new locking scheme. >>> I have strong doubts that you got all of them. At least radeon and >>> nouveau should grab the reservation lock in their ->attach callbacks >>> somehow. >> Radeon and Nouveau use gem_prime_import_sg_table() and they take resv >> lock already, seems they should be okay (?) > > You are looking at the wrong side. You need to fix the export code path, > not the import ones. > > See for example attach on radeon works like this > drm_gem_map_attach->drm_gem_pin->radeon_gem_prime_pin->radeon_bo_reserve->ttm_bo_reserve->dma_resv_lock. Yeah, I was looking at the both sides, but missed this one. > Same for nouveau and probably a few other exporters as well. That will > certainly cause a deadlock if you don't fix it. > > I strongly suggest to do this step by step, first attach/detach and then > the rest. Thank you very much for the suggestions. I'll implement them in the next version. -- Best regards, Dmitry
WARNING: multiple messages have this Message-ID (diff)
From: Dmitry Osipenko <dmitry.osipenko@collabora.com> To: "Christian König" <christian.koenig@amd.com>, "David Airlie" <airlied@linux.ie>, "Gerd Hoffmann" <kraxel@redhat.com>, "Gurchetan Singh" <gurchetansingh@chromium.org>, "Chia-I Wu" <olvaffe@gmail.com>, "Daniel Vetter" <daniel@ffwll.ch>, "Daniel Almeida" <daniel.almeida@collabora.com>, "Gert Wollny" <gert.wollny@collabora.com>, "Gustavo Padovan" <gustavo.padovan@collabora.com>, "Daniel Stone" <daniel@fooishbar.org>, "Tomeu Vizoso" <tomeu.vizoso@collabora.com>, "Maarten Lankhorst" <maarten.lankhorst@linux.intel.com>, "Maxime Ripard" <mripard@kernel.org>, "Thomas Zimmermann" <tzimmermann@suse.de>, "Rob Herring" <robh@kernel.org>, "Steven Price" <steven.price@arm.com>, "Alyssa Rosenzweig" <alyssa.rosenzweig@collabora.com>, "Rob Clark" <robdclark@gmail.com>, "Emil Velikov" <emil.l.velikov@gmail.com>, "Robin Murphy" <robin.murphy@arm.com>, "Qiang Yu" <yuq825@gmail.com>, "Sumit Semwal" <sumit.semwal@linaro.org>, "Pan, Xinhui" <Xinhui.Pan@amd.com>, "Thierry Reding" <thierry.reding@gmail.com>, "Tomasz Figa" <tfiga@chromium.org>, "Marek Szyprowski" <m.szyprowski@samsung.com>, "Mauro Carvalho Chehab" <mchehab@kernel.org>, "Alex Deucher" <alexander.deucher@amd.com>, "Jani Nikula" <jani.nikula@linux.intel.com>, "Joonas Lahtinen" <joonas.lahtinen@linux.intel.com>, "Rodrigo Vivi" <rodrigo.vivi@intel.com>, "Tvrtko Ursulin" <tvrtko.ursulin@linux.intel.com> Cc: dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, virtualization@lists.linux-foundation.org, Dmitry Osipenko <digetx@gmail.com>, linux-tegra@vger.kernel.org, linux-media@vger.kernel.org, linaro-mm-sig@lists.linaro.org, amd-gfx@lists.freedesktop.org, intel-gfx@lists.freedesktop.org, kernel@collabora.com Subject: Re: [PATCH v6 14/22] dma-buf: Introduce new locking convention Date: Mon, 30 May 2022 16:57:22 +0300 [thread overview] Message-ID: <7372dd1b-06f7-5336-4738-15f9b4d4d4b3@collabora.com> (raw) In-Reply-To: <02e7946b-34ca-b48e-1ba6-e7b63740a2d9@amd.com> On 5/30/22 16:41, Christian König wrote: > Hi Dmitry, > > Am 30.05.22 um 15:26 schrieb Dmitry Osipenko: >> Hello Christian, >> >> On 5/30/22 09:50, Christian König wrote: >>> Hi Dmitry, >>> >>> First of all please separate out this patch from the rest of the series, >>> since this is a complex separate structural change. >> I assume all the patches will go via the DRM tree in the end since the >> rest of the DRM patches in this series depend on this dma-buf change. >> But I see that separation may ease reviewing of the dma-buf changes, so >> let's try it. > > That sounds like you are underestimating a bit how much trouble this > will be. > >>> I have tried this before and failed because catching all the locks in >>> the right code paths are very tricky. So expect some fallout from this >>> and make sure the kernel test robot and CI systems are clean. >> Sure, I'll fix up all the reported things in the next iteration. >> >> BTW, have you ever posted yours version of the patch? Will be great if >> we could compare the changed code paths. > > No, I never even finished creating it after realizing how much work it > would be. > >>>> This patch introduces new locking convention for dma-buf users. From >>>> now >>>> on all dma-buf importers are responsible for holding dma-buf >>>> reservation >>>> lock around operations performed over dma-bufs. >>>> >>>> This patch implements the new dma-buf locking convention by: >>>> >>>> 1. Making dma-buf API functions to take the reservation lock. >>>> >>>> 2. Adding new locked variants of the dma-buf API functions for >>>> drivers >>>> that need to manage imported dma-bufs under the held lock. >>> Instead of adding new locked variants please mark all variants which >>> expect to be called without a lock with an _unlocked postfix. >>> >>> This should make it easier to remove those in a follow up patch set and >>> then fully move the locking into the importer. >> Do we really want to move all the locks to the importers? Seems the >> majority of drivers should be happy with the dma-buf helpers handling >> the locking for them. > > Yes, I clearly think so. > >> >>>> 3. Converting all drivers to the new locking scheme. >>> I have strong doubts that you got all of them. At least radeon and >>> nouveau should grab the reservation lock in their ->attach callbacks >>> somehow. >> Radeon and Nouveau use gem_prime_import_sg_table() and they take resv >> lock already, seems they should be okay (?) > > You are looking at the wrong side. You need to fix the export code path, > not the import ones. > > See for example attach on radeon works like this > drm_gem_map_attach->drm_gem_pin->radeon_gem_prime_pin->radeon_bo_reserve->ttm_bo_reserve->dma_resv_lock. Yeah, I was looking at the both sides, but missed this one. > Same for nouveau and probably a few other exporters as well. That will > certainly cause a deadlock if you don't fix it. > > I strongly suggest to do this step by step, first attach/detach and then > the rest. Thank you very much for the suggestions. I'll implement them in the next version. -- Best regards, Dmitry
next prev parent reply other threads:[~2022-05-30 13:57 UTC|newest] Thread overview: 206+ 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 ` 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-05-26 23:50 ` Dmitry Osipenko 2022-06-28 20:12 ` Thomas Hellström (Intel) 2022-06-28 20:12 ` Thomas Hellström (Intel) 2022-06-28 20:12 ` [Intel-gfx] " Thomas Hellström (Intel) 2022-06-29 8:23 ` Dmitry Osipenko 2022-06-29 8:23 ` [Intel-gfx] " Dmitry Osipenko 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-05-26 23:50 ` Dmitry Osipenko 2022-06-29 6:40 ` Thomas Hellström (Intel) 2022-06-29 6:40 ` [Intel-gfx] " Thomas Hellström (Intel) 2022-06-29 6:40 ` Thomas Hellström (Intel) 2022-06-29 8:22 ` Dmitry Osipenko 2022-06-29 8:22 ` [Intel-gfx] " Dmitry Osipenko 2022-06-29 8:22 ` Dmitry Osipenko 2022-06-29 8:22 ` Dmitry Osipenko 2022-06-29 8:43 ` Thomas Hellström (Intel) 2022-06-29 8:43 ` Thomas Hellström (Intel) 2022-06-29 8:43 ` [Intel-gfx] " Thomas Hellström (Intel) 2022-06-29 8:43 ` Thomas Hellström (Intel) 2022-06-29 23:06 ` Dmitry Osipenko 2022-06-29 23:06 ` [Intel-gfx] " Dmitry Osipenko 2022-06-29 23:06 ` Dmitry Osipenko 2022-06-29 23:06 ` Dmitry Osipenko 2022-07-04 12:33 ` [Linaro-mm-sig] " Christian König 2022-07-04 12:33 ` [Intel-gfx] " Christian König 2022-07-04 12:33 ` Christian König 2022-07-04 12:33 ` Christian König 2022-07-04 12:33 ` Christian König via Virtualization 2022-07-04 22:44 ` Dmitry Osipenko 2022-07-04 22:44 ` [Intel-gfx] " Dmitry Osipenko 2022-07-04 22:44 ` Dmitry Osipenko 2022-07-04 22:44 ` 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 ` Dmitry Osipenko 2022-05-26 23:50 ` [PATCH v6 04/22] drm/panfrost: Fix shrinker list corruption by madvise IOCTL Dmitry Osipenko 2022-05-26 23:50 ` Dmitry Osipenko 2022-05-27 15:56 ` Alyssa Rosenzweig 2022-05-27 15:56 ` [Intel-gfx] " Alyssa Rosenzweig 2022-05-27 15:56 ` Alyssa Rosenzweig 2022-05-27 15:56 ` Alyssa Rosenzweig 2022-05-30 9:41 ` Steven Price 2022-05-30 9:41 ` [Intel-gfx] " Steven Price 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 ` 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 ` 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 ` Dmitry Osipenko 2022-05-26 23:50 ` [PATCH v6 08/22] drm/virtio: Unlock reservations on dma_resv_reserve_fences() error Dmitry Osipenko 2022-05-26 23:50 ` Dmitry Osipenko 2022-06-29 6:43 ` Thomas Hellström (Intel) 2022-06-29 6:43 ` [Intel-gfx] " Thomas Hellström (Intel) 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 ` 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 ` 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 ` 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 ` 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 ` Dmitry Osipenko 2022-05-26 23:50 ` [PATCH v6 14/22] dma-buf: Introduce new locking convention Dmitry Osipenko 2022-05-26 23:50 ` Dmitry Osipenko 2022-05-27 2:37 ` kernel test robot 2022-05-27 12:44 ` Dmitry Osipenko 2022-05-27 12:44 ` Dmitry Osipenko 2022-05-30 6:50 ` Christian König via Virtualization 2022-05-30 6:50 ` [Intel-gfx] " Christian König 2022-05-30 6:50 ` Christian König 2022-05-30 6:50 ` Christian König 2022-05-30 13:26 ` Dmitry Osipenko 2022-05-30 13:26 ` Dmitry Osipenko 2022-05-30 13:41 ` Christian König via Virtualization 2022-05-30 13:41 ` Christian König 2022-05-30 13:41 ` [Intel-gfx] " Christian König 2022-05-30 13:41 ` Christian König 2022-05-30 13:57 ` Dmitry Osipenko [this message] 2022-05-30 13:57 ` Dmitry Osipenko 2022-06-28 21:26 ` Thomas Hellström (Intel) 2022-06-28 21:26 ` Thomas Hellström (Intel) 2022-06-28 21:26 ` [Intel-gfx] " Thomas Hellström (Intel) 2022-07-01 10:43 ` Dmitry Osipenko 2022-07-01 10:43 ` [Intel-gfx] " Dmitry Osipenko 2022-07-01 10:43 ` Dmitry Osipenko 2022-07-04 22:38 ` Dmitry Osipenko 2022-07-04 22:38 ` [Intel-gfx] " Dmitry Osipenko 2022-07-04 22:38 ` Dmitry Osipenko 2022-07-04 22:38 ` Dmitry Osipenko 2022-07-05 10:52 ` Dmitry Osipenko 2022-07-05 10:52 ` [Intel-gfx] " Dmitry Osipenko 2022-07-05 10:52 ` 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 ` Dmitry Osipenko 2022-05-26 23:50 ` [PATCH v6 16/22] drm/shmem-helper: Use reservation lock Dmitry Osipenko 2022-05-26 23:50 ` Dmitry Osipenko 2022-05-26 23:50 ` [PATCH v6 17/22] drm/shmem-helper: Add generic memory shrinker Dmitry Osipenko 2022-05-26 23:50 ` Dmitry Osipenko 2022-06-05 16:47 ` Daniel Vetter 2022-06-05 16:47 ` Daniel Vetter 2022-06-05 16:47 ` [Intel-gfx] " Daniel Vetter 2022-06-05 16:47 ` Daniel Vetter 2022-06-05 16:47 ` Daniel Vetter 2022-06-05 18:32 ` [Intel-gfx] " Rob Clark 2022-06-05 18:32 ` Rob Clark 2022-06-05 18:32 ` Rob Clark 2022-06-05 18:32 ` Rob Clark 2022-06-05 18:32 ` Rob Clark 2022-06-05 18:45 ` Daniel Vetter 2022-06-05 18:45 ` Daniel Vetter 2022-06-05 18:45 ` [Intel-gfx] " Daniel Vetter 2022-06-05 18:45 ` Daniel Vetter 2022-06-05 18:45 ` Daniel Vetter 2022-06-06 10:57 ` Christian König 2022-06-06 10:57 ` Christian König 2022-06-06 10:57 ` Christian König 2022-06-06 10:57 ` Christian König 2022-06-07 15:33 ` Dmitry Osipenko 2022-06-07 15:33 ` Dmitry Osipenko 2022-06-07 15:33 ` Dmitry Osipenko 2022-06-19 17:53 ` Rob Clark 2022-06-19 17:53 ` Rob Clark 2022-06-19 17:53 ` [Intel-gfx] " Rob Clark 2022-06-19 17:53 ` Rob Clark 2022-06-19 17:53 ` Rob Clark 2022-06-20 14:08 ` Dmitry Osipenko 2022-06-20 14:08 ` Dmitry Osipenko 2022-06-20 14:08 ` Dmitry Osipenko 2022-06-20 15:18 ` Rob Clark 2022-06-20 15:18 ` Rob Clark 2022-06-20 15:18 ` Rob Clark 2022-06-20 15:18 ` [Intel-gfx] " Rob Clark 2022-06-20 15:18 ` Rob Clark 2022-06-24 20:23 ` Daniel Vetter 2022-06-24 20:23 ` Daniel Vetter 2022-06-24 20:23 ` [Intel-gfx] " Daniel Vetter 2022-06-24 20:23 ` Daniel Vetter 2022-06-24 20:23 ` Daniel Vetter 2022-06-24 20:21 ` Daniel Vetter 2022-06-24 20:21 ` Daniel Vetter 2022-06-24 20:21 ` [Intel-gfx] " Daniel Vetter 2022-06-24 20:21 ` Daniel Vetter 2022-06-24 20:21 ` Daniel Vetter 2022-06-20 15:37 ` Rob Clark 2022-06-20 15:37 ` Rob Clark 2022-06-20 15:37 ` Rob Clark 2022-06-20 15:37 ` Rob Clark 2022-06-20 15:37 ` [Intel-gfx] " Rob Clark 2022-06-21 16:39 ` Dmitry Osipenko 2022-06-21 16:39 ` Dmitry Osipenko 2022-06-21 16:39 ` [Intel-gfx] " Dmitry Osipenko 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 ` Dmitry Osipenko 2022-05-26 23:50 ` [PATCH v6 19/22] drm/virtio: Support memory shrinking Dmitry Osipenko 2022-05-26 23:50 ` Dmitry Osipenko 2022-05-26 23:50 ` [PATCH v6 20/22] drm/virtio: Use dev_is_pci() Dmitry Osipenko 2022-05-26 23:50 ` 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 ` Dmitry Osipenko 2022-05-26 23:50 ` [PATCH v6 22/22] drm/panfrost: Switch to generic memory shrinker Dmitry Osipenko 2022-05-26 23:50 ` Dmitry Osipenko 2022-05-27 11:48 ` Alyssa Rosenzweig 2022-05-27 11:48 ` [Intel-gfx] " Alyssa Rosenzweig 2022-05-27 11:48 ` Alyssa Rosenzweig 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-10 14:40 ` Dmitry Osipenko 2022-06-10 14:40 ` Dmitry Osipenko 2022-06-28 12:31 ` Robin Murphy 2022-06-28 12:31 ` Robin Murphy 2022-06-28 12:31 ` Robin Murphy 2022-06-28 12:50 ` Dmitry Osipenko 2022-06-28 12:50 ` [Intel-gfx] " Dmitry Osipenko 2022-06-28 12:50 ` Dmitry Osipenko 2022-06-28 16:48 ` Rob Clark 2022-06-28 16:48 ` Rob Clark 2022-06-28 16:48 ` Rob Clark 2022-06-28 16:48 ` [Intel-gfx] " Rob Clark 2022-06-28 16:48 ` Rob Clark 2022-06-28 23:11 ` Dmitry Osipenko 2022-06-28 23:11 ` [Intel-gfx] " Dmitry Osipenko 2022-06-28 23:11 ` Dmitry Osipenko 2022-06-28 23:11 ` Dmitry Osipenko 2022-06-28 12:51 ` Dmitry Osipenko 2022-06-28 12:51 ` [Intel-gfx] " Dmitry Osipenko 2022-06-28 12:51 ` Dmitry Osipenko 2022-06-28 13:11 ` Dmitry Osipenko 2022-06-28 13:11 ` [Intel-gfx] " Dmitry Osipenko 2022-06-28 13:11 ` Dmitry Osipenko 2022-05-27 12:21 [PATCH v6 14/22] dma-buf: Introduce new locking convention kernel test robot 2022-05-30 7:05 ` Dan Carpenter 2022-05-27 14:03 [PATCH v6 17/22] drm/shmem-helper: Add generic memory shrinker kernel test robot 2022-05-30 7:09 ` [kbuild] " Dan Carpenter 2022-05-30 7:09 ` Dan Carpenter 2022-05-30 13:27 ` Dmitry Osipenko 2022-05-30 13:27 ` Dmitry Osipenko 2022-05-27 22:08 [PATCH v6 14/22] dma-buf: Introduce new locking convention kernel test robot 2022-05-30 3:25 ` kernel test robot
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=7372dd1b-06f7-5336-4738-15f9b4d4d4b3@collabora.com \ --to=dmitry.osipenko@collabora.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=christian.koenig@amd.com \ --cc=daniel.almeida@collabora.com \ --cc=daniel@ffwll.ch \ --cc=daniel@fooishbar.org \ --cc=digetx@gmail.com \ --cc=dri-devel@lists.freedesktop.org \ --cc=emil.l.velikov@gmail.com \ --cc=gert.wollny@collabora.com \ --cc=gurchetansingh@chromium.org \ --cc=gustavo.padovan@collabora.com \ --cc=intel-gfx@lists.freedesktop.org \ --cc=jani.nikula@linux.intel.com \ --cc=joonas.lahtinen@linux.intel.com \ --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=m.szyprowski@samsung.com \ --cc=maarten.lankhorst@linux.intel.com \ --cc=mchehab@kernel.org \ --cc=mripard@kernel.org \ --cc=olvaffe@gmail.com \ --cc=robdclark@gmail.com \ --cc=robh@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=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: linkBe 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.