Quoting Daniel Vetter (2020-05-12 09:59:28) > But only for non-zero timeout, to avoid false positives. > > One question here is whether the might_sleep should be unconditional, > or only for real timeouts. I'm not sure, so went with the more > defensive option. But in the interest of locking down the cross-driver > dma_fence rules we might want to be more aggressive.
You can argue for enforcing might_sleep() as internal queries should be using dma_fence_is_signaled() and not dma_fence_wait_timeout(0). > Cc: linux-me...@vger.kernel.org > Cc: linaro-mm-...@lists.linaro.org > Cc: linux-r...@vger.kernel.org > Cc: amd-...@lists.freedesktop.org > Cc: intel-...@lists.freedesktop.org > Cc: Chris Wilson <ch...@chris-wilson.co.uk> > Cc: Maarten Lankhorst <maarten.lankho...@linux.intel.com> > Cc: Christian König <christian.koe...@amd.com> > Signed-off-by: Daniel Vetter <daniel.vet...@intel.com> > --- > drivers/dma-buf/dma-fence.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c > index 052a41e2451c..6802125349fb 100644 > --- a/drivers/dma-buf/dma-fence.c > +++ b/drivers/dma-buf/dma-fence.c > @@ -208,6 +208,9 @@ dma_fence_wait_timeout(struct dma_fence *fence, bool > intr, signed long timeout) > if (WARN_ON(timeout < 0)) > return -EINVAL; > > + if (timeout > 0) > + might_sleep(); might_sleep_if(timeout > 0); -Chris _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
