Op 12-05-2020 om 11:08 schreef Christian König: > Am 12.05.20 um 10:59 schrieb Daniel Vetter: >> 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. >> >> 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-gfx@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(); >> + > > I would rather like to see might_sleep() called here all the time even with > timeout==0. > > IIRC I removed the code in TTM abusing this in atomic context quite a while > ago, but could be that some leaked in again or it is called in atomic context > elsewhere as well.
Same, glad I'm not the only one who wants it. :) ~Maarten _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
