From: Daniel Vetter <daniel@ffwll.ch>
To: DRI Development <dri-devel@lists.freedesktop.org>
Cc: "Intel Graphics Development" <intel-gfx@lists.freedesktop.org>,
linux-rdma@vger.kernel.org,
"Daniel Vetter" <daniel.vetter@ffwll.ch>,
"Jason Gunthorpe" <jgg@mellanox.com>,
"Felix Kuehling" <Felix.Kuehling@amd.com>,
"kernel test robot" <lkp@intel.com>,
"Thomas Hellström" <thomas.hellstrom@intel.com>,
"Mika Kuoppala" <mika.kuoppala@intel.com>,
linux-media@vger.kernel.org, linaro-mm-sig@lists.linaro.org,
amd-gfx@lists.freedesktop.org,
"Chris Wilson" <chris@chris-wilson.co.uk>,
"Maarten Lankhorst" <maarten.lankhorst@linux.intel.com>,
"Christian König" <christian.koenig@amd.com>,
"Daniel Vetter" <daniel.vetter@intel.com>
Subject: Re: [PATCH 02/25] dma-fence: prime lockdep annotations
Date: Thu, 9 Jul 2020 10:09:11 +0200 [thread overview]
Message-ID: <20200709080911.GP3278063@phenom.ffwll.local> (raw)
In-Reply-To: <20200707201229.472834-3-daniel.vetter@ffwll.ch>
Hi Jason,
Below the paragraph I've added after our discussions around dma-fences
outside of drivers/gpu. Good enough for an ack on this, or want something
changed?
Thanks, Daniel
> + * Note that only GPU drivers have a reasonable excuse for both requiring
> + * &mmu_interval_notifier and &shrinker callbacks at the same time as having to
> + * track asynchronous compute work using &dma_fence. No driver outside of
> + * drivers/gpu should ever call dma_fence_wait() in such contexts.
On Tue, Jul 07, 2020 at 10:12:06PM +0200, Daniel Vetter wrote:
> Two in one go:
> - it is allowed to call dma_fence_wait() while holding a
> dma_resv_lock(). This is fundamental to how eviction works with ttm,
> so required.
>
> - it is allowed to call dma_fence_wait() from memory reclaim contexts,
> specifically from shrinker callbacks (which i915 does), and from mmu
> notifier callbacks (which amdgpu does, and which i915 sometimes also
> does, and probably always should, but that's kinda a debate). Also
> for stuff like HMM we really need to be able to do this, or things
> get real dicey.
>
> Consequence is that any critical path necessary to get to a
> dma_fence_signal for a fence must never a) call dma_resv_lock nor b)
> allocate memory with GFP_KERNEL. Also by implication of
> dma_resv_lock(), no userspace faulting allowed. That's some supremely
> obnoxious limitations, which is why we need to sprinkle the right
> annotations to all relevant paths.
>
> The one big locking context we're leaving out here is mmu notifiers,
> added in
>
> commit 23b68395c7c78a764e8963fc15a7cfd318bf187f
> Author: Daniel Vetter <daniel.vetter@ffwll.ch>
> Date: Mon Aug 26 22:14:21 2019 +0200
>
> mm/mmu_notifiers: add a lockdep map for invalidate_range_start/end
>
> that one covers a lot of other callsites, and it's also allowed to
> wait on dma-fences from mmu notifiers. But there's no ready-made
> functions exposed to prime this, so I've left it out for now.
>
> v2: Also track against mmu notifier context.
>
> v3: kerneldoc to spec the cross-driver contract. Note that currently
> i915 throws in a hard-coded 10s timeout on foreign fences (not sure
> why that was done, but it's there), which is why that rule is worded
> with SHOULD instead of MUST.
>
> Also some of the mmu_notifier/shrinker rules might surprise SoC
> drivers, I haven't fully audited them all. Which is infeasible anyway,
> we'll need to run them with lockdep and dma-fence annotations and see
> what goes boom.
>
> v4: A spelling fix from Mika
>
> v5: #ifdef for CONFIG_MMU_NOTIFIER. Reported by 0day. Unfortunately
> this means lockdep enforcement is slightly inconsistent, it won't spot
> GFP_NOIO and GFP_NOFS allocations in the wrong spot if
> CONFIG_MMU_NOTIFIER is disabled in the kernel config. Oh well.
>
> v5: Note that only drivers/gpu has a reasonable (or at least
> historical) excuse to use dma_fence_wait() from shrinker and mmu
> notifier callbacks. Everyone else should either have a better memory
> manager model, or better hardware. This reflects discussions with
> Jason Gunthorpe.
>
> Cc: Jason Gunthorpe <jgg@mellanox.com>
> Cc: Felix Kuehling <Felix.Kuehling@amd.com>
> Cc: kernel test robot <lkp@intel.com>
> Reviewed-by: Thomas Hellström <thomas.hellstrom@intel.com> (v4)
> Cc: Mika Kuoppala <mika.kuoppala@intel.com>
> Cc: Thomas Hellstrom <thomas.hellstrom@intel.com>
> Cc: linux-media@vger.kernel.org
> Cc: linaro-mm-sig@lists.linaro.org
> Cc: linux-rdma@vger.kernel.org
> Cc: amd-gfx@lists.freedesktop.org
> Cc: intel-gfx@lists.freedesktop.org
> Cc: Chris Wilson <chris@chris-wilson.co.uk>
> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
> Cc: Christian König <christian.koenig@amd.com>
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> ---
> Documentation/driver-api/dma-buf.rst | 6 ++++
> drivers/dma-buf/dma-fence.c | 46 ++++++++++++++++++++++++++++
> drivers/dma-buf/dma-resv.c | 8 +++++
> include/linux/dma-fence.h | 1 +
> 4 files changed, 61 insertions(+)
>
> diff --git a/Documentation/driver-api/dma-buf.rst b/Documentation/driver-api/dma-buf.rst
> index 05d856131140..f8f6decde359 100644
> --- a/Documentation/driver-api/dma-buf.rst
> +++ b/Documentation/driver-api/dma-buf.rst
> @@ -133,6 +133,12 @@ DMA Fences
> .. kernel-doc:: drivers/dma-buf/dma-fence.c
> :doc: DMA fences overview
>
> +DMA Fence Cross-Driver Contract
> +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> +
> +.. kernel-doc:: drivers/dma-buf/dma-fence.c
> + :doc: fence cross-driver contract
> +
> DMA Fence Signalling Annotations
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c
> index 0005bc002529..af1d8ea926b3 100644
> --- a/drivers/dma-buf/dma-fence.c
> +++ b/drivers/dma-buf/dma-fence.c
> @@ -64,6 +64,52 @@ static atomic64_t dma_fence_context_counter = ATOMIC64_INIT(1);
> * &dma_buf.resv pointer.
> */
>
> +/**
> + * DOC: fence cross-driver contract
> + *
> + * Since &dma_fence provide a cross driver contract, all drivers must follow the
> + * same rules:
> + *
> + * * Fences must complete in a reasonable time. Fences which represent kernels
> + * and shaders submitted by userspace, which could run forever, must be backed
> + * up by timeout and gpu hang recovery code. Minimally that code must prevent
> + * further command submission and force complete all in-flight fences, e.g.
> + * when the driver or hardware do not support gpu reset, or if the gpu reset
> + * failed for some reason. Ideally the driver supports gpu recovery which only
> + * affects the offending userspace context, and no other userspace
> + * submissions.
> + *
> + * * Drivers may have different ideas of what completion within a reasonable
> + * time means. Some hang recovery code uses a fixed timeout, others a mix
> + * between observing forward progress and increasingly strict timeouts.
> + * Drivers should not try to second guess timeout handling of fences from
> + * other drivers.
> + *
> + * * To ensure there's no deadlocks of dma_fence_wait() against other locks
> + * drivers should annotate all code required to reach dma_fence_signal(),
> + * which completes the fences, with dma_fence_begin_signalling() and
> + * dma_fence_end_signalling().
> + *
> + * * Drivers are allowed to call dma_fence_wait() while holding dma_resv_lock().
> + * This means any code required for fence completion cannot acquire a
> + * &dma_resv lock. Note that this also pulls in the entire established
> + * locking hierarchy around dma_resv_lock() and dma_resv_unlock().
> + *
> + * * Drivers are allowed to call dma_fence_wait() from their &shrinker
> + * callbacks. This means any code required for fence completion cannot
> + * allocate memory with GFP_KERNEL.
> + *
> + * * Drivers are allowed to call dma_fence_wait() from their &mmu_notifier
> + * respectively &mmu_interval_notifier callbacks. This means any code required
> + * for fence completeion cannot allocate memory with GFP_NOFS or GFP_NOIO.
> + * Only GFP_ATOMIC is permissible, which might fail.
> + *
> + * Note that only GPU drivers have a reasonable excuse for both requiring
> + * &mmu_interval_notifier and &shrinker callbacks at the same time as having to
> + * track asynchronous compute work using &dma_fence. No driver outside of
> + * drivers/gpu should ever call dma_fence_wait() in such contexts.
> + */
> +
> static const char *dma_fence_stub_get_name(struct dma_fence *fence)
> {
> return "stub";
> diff --git a/drivers/dma-buf/dma-resv.c b/drivers/dma-buf/dma-resv.c
> index e7d7197d48ce..0e6675ec1d11 100644
> --- a/drivers/dma-buf/dma-resv.c
> +++ b/drivers/dma-buf/dma-resv.c
> @@ -36,6 +36,7 @@
> #include <linux/export.h>
> #include <linux/mm.h>
> #include <linux/sched/mm.h>
> +#include <linux/mmu_notifier.h>
>
> /**
> * DOC: Reservation Object Overview
> @@ -116,6 +117,13 @@ static int __init dma_resv_lockdep(void)
> if (ret == -EDEADLK)
> dma_resv_lock_slow(&obj, &ctx);
> fs_reclaim_acquire(GFP_KERNEL);
> +#ifdef CONFIG_MMU_NOTIFIER
> + lock_map_acquire(&__mmu_notifier_invalidate_range_start_map);
> + __dma_fence_might_wait();
> + lock_map_release(&__mmu_notifier_invalidate_range_start_map);
> +#else
> + __dma_fence_might_wait();
> +#endif
> fs_reclaim_release(GFP_KERNEL);
> ww_mutex_unlock(&obj.lock);
> ww_acquire_fini(&ctx);
> diff --git a/include/linux/dma-fence.h b/include/linux/dma-fence.h
> index 3f288f7db2ef..09e23adb351d 100644
> --- a/include/linux/dma-fence.h
> +++ b/include/linux/dma-fence.h
> @@ -360,6 +360,7 @@ dma_fence_get_rcu_safe(struct dma_fence __rcu **fencep)
> #ifdef CONFIG_LOCKDEP
> bool dma_fence_begin_signalling(void);
> void dma_fence_end_signalling(bool cookie);
> +void __dma_fence_might_wait(void);
> #else
> static inline bool dma_fence_begin_signalling(void)
> {
> --
> 2.27.0
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
next prev parent reply other threads:[~2020-07-09 8:09 UTC|newest]
Thread overview: 119+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-07 20:12 [PATCH 00/25] dma-fence annotations, round 3 Daniel Vetter
2020-07-07 20:12 ` [PATCH 01/25] dma-fence: basic lockdep annotations Daniel Vetter
2020-07-08 14:57 ` Christian König
2020-07-08 15:12 ` Daniel Vetter
2020-07-08 15:19 ` Alex Deucher
2020-07-08 15:37 ` Daniel Vetter
2020-07-14 11:09 ` Daniel Vetter
2020-07-09 7:32 ` [Intel-gfx] " Daniel Stone
2020-07-09 7:52 ` Daniel Vetter
2020-07-13 16:26 ` Daniel Vetter
2020-07-13 16:39 ` Christian König
2020-07-13 20:31 ` Dave Airlie
2020-07-07 20:12 ` [PATCH 02/25] dma-fence: prime " Daniel Vetter
2020-07-09 8:09 ` Daniel Vetter [this message]
2020-07-10 12:43 ` Jason Gunthorpe
2020-07-10 12:48 ` Christian König
2020-07-10 12:54 ` Jason Gunthorpe
2020-07-10 13:01 ` Christian König
2020-07-10 13:48 ` Jason Gunthorpe
2020-07-10 14:02 ` Daniel Vetter
2020-07-10 14:23 ` Jason Gunthorpe
2020-07-10 20:02 ` Daniel Vetter
2020-07-07 20:12 ` [PATCH 03/25] dma-buf.rst: Document why idenfinite fences are a bad idea Daniel Vetter
2020-07-09 7:36 ` [Intel-gfx] " Daniel Stone
2020-07-09 8:04 ` Daniel Vetter
2020-07-09 12:11 ` Daniel Stone
2020-07-09 12:31 ` Daniel Vetter
2020-07-09 14:28 ` Christian König
2020-07-09 11:53 ` Christian König
2020-07-09 12:33 ` [PATCH 1/2] dma-buf.rst: Document why indefinite " Daniel Vetter
2020-07-09 12:33 ` [PATCH 2/2] drm/virtio: Remove open-coded commit-tail function Daniel Vetter
2020-07-09 12:48 ` Gerd Hoffmann
2020-07-09 14:05 ` Sam Ravnborg
2020-07-14 9:13 ` Daniel Vetter
2020-08-19 12:43 ` Jiri Slaby
2020-08-19 12:47 ` Jiri Slaby
2020-08-19 13:24 ` Gerd Hoffmann
2020-08-20 6:32 ` Jiri Slaby
2020-08-21 7:01 ` Gerd Hoffmann
2020-07-10 12:30 ` [PATCH 1/2] dma-buf.rst: Document why indefinite fences are a bad idea Maarten Lankhorst
2020-07-14 17:46 ` Jason Ekstrand
2020-07-20 11:15 ` [Linaro-mm-sig] " Thomas Hellström (Intel)
2020-07-21 7:41 ` Daniel Vetter
2020-07-21 7:45 ` Christian König
2020-07-21 8:47 ` Thomas Hellström (Intel)
2020-07-21 8:55 ` Christian König
2020-07-21 9:16 ` Daniel Vetter
2020-07-21 9:24 ` Daniel Vetter
2020-07-21 9:37 ` Thomas Hellström (Intel)
2020-07-21 9:50 ` Daniel Vetter
2020-07-21 10:47 ` Thomas Hellström (Intel)
2020-07-21 13:59 ` Christian König
2020-07-21 17:46 ` Thomas Hellström (Intel)
2020-07-21 18:18 ` Daniel Vetter
2020-07-21 21:42 ` Dave Airlie
2020-07-21 22:45 ` Dave Airlie
2020-07-22 6:45 ` Thomas Hellström (Intel)
2020-07-22 7:11 ` Daniel Vetter
2020-07-22 8:05 ` Thomas Hellström (Intel)
2020-07-22 9:45 ` Daniel Vetter
2020-07-22 10:31 ` Thomas Hellström (Intel)
2020-07-22 11:39 ` Daniel Vetter
2020-07-22 12:22 ` Thomas Hellström (Intel)
2020-07-22 12:41 ` Daniel Vetter
2020-07-22 13:12 ` Thomas Hellström (Intel)
2020-07-22 14:07 ` Daniel Vetter
2020-07-22 14:23 ` Christian König
2020-07-22 14:30 ` Thomas Hellström (Intel)
2020-07-22 14:35 ` Christian König
2020-07-07 20:12 ` [PATCH 04/25] drm/vkms: Annotate vblank timer Daniel Vetter
2020-07-12 22:27 ` Rodrigo Siqueira
2020-07-14 9:57 ` Melissa Wen
2020-07-14 9:59 ` Daniel Vetter
2020-07-14 14:55 ` Melissa Wen
2020-07-14 15:23 ` Daniel Vetter
2020-07-07 20:12 ` [PATCH 05/25] drm/vblank: Annotate with dma-fence signalling section Daniel Vetter
2020-07-07 20:12 ` [PATCH 06/25] drm/amdgpu: add dma-fence annotations to atomic commit path Daniel Vetter
2020-07-07 20:12 ` [PATCH 07/25] drm/komdea: Annotate dma-fence critical section in " Daniel Vetter
2020-07-08 5:17 ` james qian wang (Arm Technology China)
2020-07-14 8:34 ` Daniel Vetter
2020-07-07 20:12 ` [PATCH 08/25] drm/malidp: " Daniel Vetter
2020-07-15 12:53 ` Liviu Dudau
2020-07-15 13:51 ` Daniel Vetter
2020-07-07 20:12 ` [PATCH 09/25] drm/atmel: Use drm_atomic_helper_commit Daniel Vetter
2020-07-07 20:37 ` Sam Ravnborg
2020-07-07 21:31 ` [PATCH] " Daniel Vetter
2020-07-14 9:55 ` Sam Ravnborg
2020-07-07 20:12 ` [PATCH 10/25] drm/imx: Annotate dma-fence critical section in commit path Daniel Vetter
2020-07-07 20:12 ` [PATCH 11/25] drm/omapdrm: " Daniel Vetter
2020-07-07 20:12 ` [PATCH 12/25] drm/rcar-du: " Daniel Vetter
2020-07-07 23:32 ` Laurent Pinchart
2020-07-14 8:39 ` Daniel Vetter
2020-07-07 20:12 ` [PATCH 13/25] drm/tegra: " Daniel Vetter
2020-07-07 20:12 ` [PATCH 14/25] drm/tidss: " Daniel Vetter
2020-07-08 9:01 ` Jyri Sarha
2020-07-07 20:12 ` [PATCH 15/25] drm/tilcdc: Use standard drm_atomic_helper_commit Daniel Vetter
2020-07-08 9:17 ` Jyri Sarha
2020-07-08 9:27 ` Daniel Vetter
2020-07-08 9:44 ` [PATCH] " Daniel Vetter
2020-07-08 10:21 ` Jyri Sarha
2020-07-08 14:20 ` Daniel Vetter
2020-07-10 11:16 ` Jyri Sarha
2020-07-14 8:32 ` Daniel Vetter
2020-07-07 20:12 ` [PATCH 16/25] drm/atomic-helper: Add dma-fence annotations Daniel Vetter
2020-07-07 20:12 ` [PATCH 17/25] drm/scheduler: use dma-fence annotations in main thread Daniel Vetter
2020-07-07 20:12 ` [PATCH 18/25] drm/amdgpu: use dma-fence annotations in cs_submit() Daniel Vetter
2020-07-07 20:12 ` [PATCH 19/25] drm/amdgpu: s/GFP_KERNEL/GFP_ATOMIC in scheduler code Daniel Vetter
2020-07-14 10:49 ` Daniel Vetter
2020-07-14 11:40 ` Christian König
2020-07-14 14:31 ` Daniel Vetter
2020-07-15 9:17 ` Christian König
2020-07-15 11:53 ` Daniel Vetter
2020-07-07 20:12 ` [PATCH 20/25] drm/amdgpu: DC also loves to allocate stuff where it shouldn't Daniel Vetter
2020-07-14 11:12 ` Daniel Vetter
2020-07-07 20:12 ` [PATCH 21/25] drm/amdgpu/dc: Stop dma_resv_lock inversion in commit_tail Daniel Vetter
2020-07-07 20:12 ` [PATCH 22/25] drm/scheduler: use dma-fence annotations in tdr work Daniel Vetter
2020-07-07 20:12 ` [PATCH 23/25] drm/amdgpu: use dma-fence annotations for gpu reset code Daniel Vetter
2020-07-07 20:12 ` [PATCH 24/25] Revert "drm/amdgpu: add fbdev suspend/resume on gpu reset" Daniel Vetter
2020-07-07 20:12 ` [PATCH 25/25] drm/amdgpu: gpu recovery does full modesets 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=20200709080911.GP3278063@phenom.ffwll.local \
--to=daniel@ffwll.ch \
--cc=Felix.Kuehling@amd.com \
--cc=amd-gfx@lists.freedesktop.org \
--cc=chris@chris-wilson.co.uk \
--cc=christian.koenig@amd.com \
--cc=daniel.vetter@ffwll.ch \
--cc=daniel.vetter@intel.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=intel-gfx@lists.freedesktop.org \
--cc=jgg@mellanox.com \
--cc=linaro-mm-sig@lists.linaro.org \
--cc=linux-media@vger.kernel.org \
--cc=linux-rdma@vger.kernel.org \
--cc=lkp@intel.com \
--cc=maarten.lankhorst@linux.intel.com \
--cc=mika.kuoppala@intel.com \
--cc=thomas.hellstrom@intel.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).