On Tue, Jul 06, 2021 at 10:05:59AM +0100, Matthew Auld wrote:

dma_fence_might_wait is more interesting here, since it also teaches lockdep about the fence critical section and wait_migration dependency.

Suggested-by: Daniel Vetter daniel.vetter@ffwll.ch Signed-off-by: Matthew Auld matthew.auld@intel.com Cc: Thomas Hellström thomas.hellstrom@linux.intel.com

Reviewed-by: Daniel Vetter daniel.vetter@ffwll.ch

Ofc assuming nothing goes boom with lockdep :-) -Daniel

---

drivers/gpu/drm/i915/gem/i915_gem_wait.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_wait.c b/drivers/gpu/drm/i915/gem/i915_gem_wait.c index f909aaa09d9c..190e221eaf81 100644 --- a/drivers/gpu/drm/i915/gem/i915_gem_wait.c +++ b/drivers/gpu/drm/i915/gem/i915_gem_wait.c @@ -305,7 +305,7 @@ i915_gem_wait_ioctl(struct drm_device *dev, void *data, struct drm_file *file) int i915_gem_object_wait_migration(struct drm_i915_gem_object *obj, unsigned int flags) {

• might_sleep();

• dma_fence_might_wait(); /* NOP for now. */ return 0;

}

2.26.3

On Tue, Jul 06, 2021 at 11:14:01AM +0200, Daniel Vetter wrote:

On Tue, Jul 06, 2021 at 10:05:58AM +0100, Matthew Auld wrote:

...

It might be useful for drivers to annotate a path where hitting the actual wait path might be difficult or unlikely through normal testing.

Suggested-by: Daniel Vetter daniel.vetter@ffwll.ch Signed-off-by: Matthew Auld matthew.auld@intel.com Cc: Thomas Hellström thomas.hellstrom@linux.intel.com

---

drivers/dma-buf/dma-fence.c | 19 ++++++++++++++++--- include/linux/dma-fence.h | 2 ++ 2 files changed, 18 insertions(+), 3 deletions(-)

diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c index ce0f5eff575d..f2cd036b5243 100644 --- a/drivers/dma-buf/dma-fence.c +++ b/drivers/dma-buf/dma-fence.c @@ -335,6 +335,21 @@ void __dma_fence_might_wait(void) } #endif

+/**

• • dma_fence_might_wait - entering a section which might wait on DMA fence
• • critical section.
• • This is also potentially useful for drivers to call directly, when annotating
• • a path where hitting the actual wait path might be difficult or unlikely
• • through normal testing.

Maybe also add a

"See also dma_fence_begin_signalling() and dma_fence_end_signalling."

here and a similar note the these two functions pointing at dma_fence_might_wait()? I do like to link things together when there's a group of functions.

With that: Reviewed-by: Daniel Vetter daniel.vetter@ffwll.ch

Also ack for merging through drm-intel-gt-next, I don't think anything in drm-misc plans to use this anytime soon. But please add the dma-buf Cc: lines for the next round (dim add-missing-cc should cover you). -Daniel

...

• */

+void dma_fence_might_wait(void) +{

• might_sleep();
• __dma_fence_might_wait();

+} +EXPORT_SYMBOL(dma_fence_might_wait);

/**

• dma_fence_signal_timestamp_locked - signal completion of a fence

@@ -495,9 +510,7 @@ dma_fence_wait_timeout(struct dma_fence *fence, bool intr, signed long timeout) if (WARN_ON(timeout < 0)) return -EINVAL;

• might_sleep();
• __dma_fence_might_wait();

• dma_fence_might_wait();

  trace_dma_fence_wait_start(fence); if (fence->ops->wait)

diff --git a/include/linux/dma-fence.h b/include/linux/dma-fence.h index 6ffb4b2c6371..37bf4beed93f 100644 --- a/include/linux/dma-fence.h +++ b/include/linux/dma-fence.h @@ -370,6 +370,8 @@ static inline void dma_fence_end_signalling(bool cookie) {} static inline void __dma_fence_might_wait(void) {} #endif

+void dma_fence_might_wait(void);

int dma_fence_signal(struct dma_fence *fence); int dma_fence_signal_locked(struct dma_fence *fence); int dma_fence_signal_timestamp(struct dma_fence *fence, ktime_t timestamp); -- 2.26.3

-- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch