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-media@xxxxxxxxxxxxxxx >> Cc: linaro-mm-sig@xxxxxxxxxxxxxxxx >> Cc: linux-rdma@xxxxxxxxxxxxxxx >> Cc: amd-gfx@xxxxxxxxxxxxxxxxxxxxx >> Cc: intel-gfx@xxxxxxxxxxxxxxxxxxxxx >> Cc: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> >> Cc: Maarten Lankhorst <maarten.lankhorst@xxxxxxxxxxxxxxx> >> Cc: Christian König <christian.koenig@xxxxxxx> >> Signed-off-by: Daniel Vetter <daniel.vetter@xxxxxxxxx> >> --- >> 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 _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
