Re: [Intel-gfx] [PATCH] Revert "drm/i915: Propagate errors on awaiting already signaled fences"
On May 19, 2021 12:16:15 Daniel Vetter wrote: On Wed, May 19, 2021 at 5:06 PM Jason Ekstrand wrote: Once we no longer rely on error propagation, I think there's a lot we can rip out. I honestly did not find that much ... what did you uncover? When I was digging through this earlier today, I think I convinced myself that the cmdparser is the only user of the entire fence error architecture. I may have missed something, though. --Jason -Daniel --Jason On Wed, May 19, 2021 at 5:15 AM Daniel Vetter wrote: From: Jason Ekstrand This reverts commit 9e31c1fe45d555a948ff66f1f0e3fe1f83ca63f7. Ever since that commit, we've been having issues where a hang in one client can propagate to another. In particular, a hang in an app can propagate to the X server which causes the whole desktop to lock up. Error propagation along fences sound like a good idea, but as your bug shows, surprising consequences, since propagating errors across security boundaries is not a good thing. What we do have is track the hangs on the ctx, and report information to userspace using RESET_STATS. That's how arb_robustness works. Also, if my understanding is still correct, the EIO from execbuf is when your context is banned (because not recoverable or too many hangs). And in all these cases it's up to userspace to figure out what is all impacted and should be reported to the application, that's not on the kernel to guess and automatically propagate. What's more, we're also building more features on top of ctx error reporting with RESET_STATS ioctl: Encrypted buffers use the same, and the userspace fence wait also relies on that mechanism. So it is the path going forward for reporting gpu hangs and resets to userspace. So all together that's why I think we should just bury this idea again as not quite the direction we want to go to, hence why I think the revert is the right option here.Signed-off-by: Jason Ekstrand v2: Augment commit message. Also restore Jason's sob that I accidentally lost. Signed-off-by: Jason Ekstrand (v1) Reported-by: Marcin Slusarz Cc: # v5.6+ Cc: Jason Ekstrand Cc: Marcin Slusarz Cc: Jon Bloomfield Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/3080 Fixes: 9e31c1fe45d5 ("drm/i915: Propagate errors on awaiting already signaled fences") Signed-off-by: Daniel Vetter --- drivers/gpu/drm/i915/i915_request.c | 8 ++-- 1 file changed, 2 insertions(+), 6 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_request.c b/drivers/gpu/drm/i915/i915_request.c index 970d8f4986bb..b796197c0772 100644 --- a/drivers/gpu/drm/i915/i915_request.c +++ b/drivers/gpu/drm/i915/i915_request.c @@ -1426,10 +1426,8 @@ i915_request_await_execution(struct i915_request *rq, do { fence = *child++; - if (test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, &fence->flags)) { - i915_sw_fence_set_error_once(&rq->submit, fence->error); + if (test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, &fence->flags)) continue; - } if (fence->context == rq->fence.context) continue; @@ -1527,10 +1525,8 @@ i915_request_await_dma_fence(struct i915_request *rq, struct dma_fence *fence) do { fence = *child++; - if (test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, &fence->flags)) { - i915_sw_fence_set_error_once(&rq->submit, fence->error); + if (test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, &fence->flags)) continue; - } /* * Requests on the same timeline are explicitly ordered, along -- 2.31.0 -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] Revert "drm/i915: Propagate errors on awaiting already signaled fences"
On Wed, May 19, 2021 at 5:06 PM Jason Ekstrand wrote: > > Once we no longer rely on error propagation, I think there's a lot we > can rip out. I honestly did not find that much ... what did you uncover? -Daniel > > --Jason > > On Wed, May 19, 2021 at 5:15 AM Daniel Vetter wrote: > > > > From: Jason Ekstrand > > > > This reverts commit 9e31c1fe45d555a948ff66f1f0e3fe1f83ca63f7. Ever > > since that commit, we've been having issues where a hang in one client > > can propagate to another. In particular, a hang in an app can propagate > > to the X server which causes the whole desktop to lock up. > > > > Error propagation along fences sound like a good idea, but as your bug > > shows, surprising consequences, since propagating errors across security > > boundaries is not a good thing. > > > > What we do have is track the hangs on the ctx, and report information to > > userspace using RESET_STATS. That's how arb_robustness works. Also, if my > > understanding is still correct, the EIO from execbuf is when your context > > is banned (because not recoverable or too many hangs). And in all these > > cases it's up to userspace to figure out what is all impacted and should > > be reported to the application, that's not on the kernel to guess and > > automatically propagate. > > > > What's more, we're also building more features on top of ctx error > > reporting with RESET_STATS ioctl: Encrypted buffers use the same, and the > > userspace fence wait also relies on that mechanism. So it is the path > > going forward for reporting gpu hangs and resets to userspace. > > > > So all together that's why I think we should just bury this idea again as > > not quite the direction we want to go to, hence why I think the revert is > > the right option here.Signed-off-by: Jason Ekstrand > > > > > > v2: Augment commit message. Also restore Jason's sob that I > > accidentally lost. > > > > Signed-off-by: Jason Ekstrand (v1) > > Reported-by: Marcin Slusarz > > Cc: # v5.6+ > > Cc: Jason Ekstrand > > Cc: Marcin Slusarz > > Cc: Jon Bloomfield > > Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/3080 > > Fixes: 9e31c1fe45d5 ("drm/i915: Propagate errors on awaiting already > > signaled fences") > > Signed-off-by: Daniel Vetter > > --- > > drivers/gpu/drm/i915/i915_request.c | 8 ++-- > > 1 file changed, 2 insertions(+), 6 deletions(-) > > > > diff --git a/drivers/gpu/drm/i915/i915_request.c > > b/drivers/gpu/drm/i915/i915_request.c > > index 970d8f4986bb..b796197c0772 100644 > > --- a/drivers/gpu/drm/i915/i915_request.c > > +++ b/drivers/gpu/drm/i915/i915_request.c > > @@ -1426,10 +1426,8 @@ i915_request_await_execution(struct i915_request *rq, > > > > do { > > fence = *child++; > > - if (test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, &fence->flags)) { > > - i915_sw_fence_set_error_once(&rq->submit, > > fence->error); > > + if (test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, &fence->flags)) > > continue; > > - } > > > > if (fence->context == rq->fence.context) > > continue; > > @@ -1527,10 +1525,8 @@ i915_request_await_dma_fence(struct i915_request > > *rq, struct dma_fence *fence) > > > > do { > > fence = *child++; > > - if (test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, &fence->flags)) { > > - i915_sw_fence_set_error_once(&rq->submit, > > fence->error); > > + if (test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, &fence->flags)) > > continue; > > - } > > > > /* > > * Requests on the same timeline are explicitly ordered, > > along > > -- > > 2.31.0 > > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] Revert "drm/i915: Propagate errors on awaiting already signaled fences"
Once we no longer rely on error propagation, I think there's a lot we can rip out. --Jason On Wed, May 19, 2021 at 5:15 AM Daniel Vetter wrote: > > From: Jason Ekstrand > > This reverts commit 9e31c1fe45d555a948ff66f1f0e3fe1f83ca63f7. Ever > since that commit, we've been having issues where a hang in one client > can propagate to another. In particular, a hang in an app can propagate > to the X server which causes the whole desktop to lock up. > > Error propagation along fences sound like a good idea, but as your bug > shows, surprising consequences, since propagating errors across security > boundaries is not a good thing. > > What we do have is track the hangs on the ctx, and report information to > userspace using RESET_STATS. That's how arb_robustness works. Also, if my > understanding is still correct, the EIO from execbuf is when your context > is banned (because not recoverable or too many hangs). And in all these > cases it's up to userspace to figure out what is all impacted and should > be reported to the application, that's not on the kernel to guess and > automatically propagate. > > What's more, we're also building more features on top of ctx error > reporting with RESET_STATS ioctl: Encrypted buffers use the same, and the > userspace fence wait also relies on that mechanism. So it is the path > going forward for reporting gpu hangs and resets to userspace. > > So all together that's why I think we should just bury this idea again as > not quite the direction we want to go to, hence why I think the revert is > the right option here.Signed-off-by: Jason Ekstrand > > v2: Augment commit message. Also restore Jason's sob that I > accidentally lost. > > Signed-off-by: Jason Ekstrand (v1) > Reported-by: Marcin Slusarz > Cc: # v5.6+ > Cc: Jason Ekstrand > Cc: Marcin Slusarz > Cc: Jon Bloomfield > Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/3080 > Fixes: 9e31c1fe45d5 ("drm/i915: Propagate errors on awaiting already signaled > fences") > Signed-off-by: Daniel Vetter > --- > drivers/gpu/drm/i915/i915_request.c | 8 ++-- > 1 file changed, 2 insertions(+), 6 deletions(-) > > diff --git a/drivers/gpu/drm/i915/i915_request.c > b/drivers/gpu/drm/i915/i915_request.c > index 970d8f4986bb..b796197c0772 100644 > --- a/drivers/gpu/drm/i915/i915_request.c > +++ b/drivers/gpu/drm/i915/i915_request.c > @@ -1426,10 +1426,8 @@ i915_request_await_execution(struct i915_request *rq, > > do { > fence = *child++; > - if (test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, &fence->flags)) { > - i915_sw_fence_set_error_once(&rq->submit, > fence->error); > + if (test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, &fence->flags)) > continue; > - } > > if (fence->context == rq->fence.context) > continue; > @@ -1527,10 +1525,8 @@ i915_request_await_dma_fence(struct i915_request *rq, > struct dma_fence *fence) > > do { > fence = *child++; > - if (test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, &fence->flags)) { > - i915_sw_fence_set_error_once(&rq->submit, > fence->error); > + if (test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, &fence->flags)) > continue; > - } > > /* > * Requests on the same timeline are explicitly ordered, along > -- > 2.31.0 > ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] Revert "drm/i915: Propagate errors on awaiting already signaled fences"
From: Jason Ekstrand This reverts commit 9e31c1fe45d555a948ff66f1f0e3fe1f83ca63f7. Ever since that commit, we've been having issues where a hang in one client can propagate to another. In particular, a hang in an app can propagate to the X server which causes the whole desktop to lock up. Error propagation along fences sound like a good idea, but as your bug shows, surprising consequences, since propagating errors across security boundaries is not a good thing. What we do have is track the hangs on the ctx, and report information to userspace using RESET_STATS. That's how arb_robustness works. Also, if my understanding is still correct, the EIO from execbuf is when your context is banned (because not recoverable or too many hangs). And in all these cases it's up to userspace to figure out what is all impacted and should be reported to the application, that's not on the kernel to guess and automatically propagate. What's more, we're also building more features on top of ctx error reporting with RESET_STATS ioctl: Encrypted buffers use the same, and the userspace fence wait also relies on that mechanism. So it is the path going forward for reporting gpu hangs and resets to userspace. So all together that's why I think we should just bury this idea again as not quite the direction we want to go to, hence why I think the revert is the right option here.Signed-off-by: Jason Ekstrand v2: Augment commit message. Also restore Jason's sob that I accidentally lost. Signed-off-by: Jason Ekstrand (v1) Reported-by: Marcin Slusarz Cc: # v5.6+ Cc: Jason Ekstrand Cc: Marcin Slusarz Cc: Jon Bloomfield Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/3080 Fixes: 9e31c1fe45d5 ("drm/i915: Propagate errors on awaiting already signaled fences") Signed-off-by: Daniel Vetter --- drivers/gpu/drm/i915/i915_request.c | 8 ++-- 1 file changed, 2 insertions(+), 6 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_request.c b/drivers/gpu/drm/i915/i915_request.c index 970d8f4986bb..b796197c0772 100644 --- a/drivers/gpu/drm/i915/i915_request.c +++ b/drivers/gpu/drm/i915/i915_request.c @@ -1426,10 +1426,8 @@ i915_request_await_execution(struct i915_request *rq, do { fence = *child++; - if (test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, &fence->flags)) { - i915_sw_fence_set_error_once(&rq->submit, fence->error); + if (test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, &fence->flags)) continue; - } if (fence->context == rq->fence.context) continue; @@ -1527,10 +1525,8 @@ i915_request_await_dma_fence(struct i915_request *rq, struct dma_fence *fence) do { fence = *child++; - if (test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, &fence->flags)) { - i915_sw_fence_set_error_once(&rq->submit, fence->error); + if (test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, &fence->flags)) continue; - } /* * Requests on the same timeline are explicitly ordered, along -- 2.31.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] Revert "drm/i915: Propagate errors on awaiting already signaled fences"
Quoting Daniel Vetter (2021-03-11 16:01:46) > On Fri, Mar 05, 2021 at 11:05:46AM -0600, Jason Ekstrand wrote: > > This reverts commit 9e31c1fe45d555a948ff66f1f0e3fe1f83ca63f7. Ever > > since that commit, we've been having issues where a hang in one client > > can propagate to another. In particular, a hang in an app can propagate > > to the X server which causes the whole desktop to lock up. > > > > Signed-off-by: Jason Ekstrand > > Reported-by: Marcin Slusarz > > Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/3080 > > Fixes: 9e31c1fe45d5 ("drm/i915: Propagate errors on awaiting already > > signaled fences") > > Yeah I suggested to just go with the revert, so I guess on my to give you > the explainer to be added to the commit message. If you took the patch this was copied from and only revert on the dma-resv, things do not break horribly. > Error propagation along fences sound like a good idea, but as your bug > shows, surprising consequences, since propagating errors across security > boundaries is not a good thing. > > What we do have is track the hangs on the ctx, and report information to > userspace using RESET_STATS. And by the fence, which is far more precise. > That's how arb_robustness works. Also, if my > understanding is still correct, the EIO from execbuf is when your context > is banned (because not recoverable or too many hangs). And in all these > cases it's up to userspace to figure out what is all impacted and should > be reported to the application, that's not on the kernel to guess and > automatically propagate. > > What's more, we're also building more features on top of ctx error > reporting with RESET_STATS ioctl: Encrypted buffers use the same, and the > userspace fence wait also relies on that mechanism. So it is the path > going forward for reporting gpu hangs and resets to userspace. That ioctl is not a solid basis, it never did quite work as expected and we kept realising the limitations of the information and the accuracy that it could report. > So all together that's why I think we should just bury this idea again as > not quite the direction we want to go to, hence why I think the revert is > the right option here. No, as shown by igt it's a critical issue that we have to judicially chose which errors to ignore. And it's not just the ability to subvert gen7 and gen9, it's the error tracking employed for preempting contexts among others. Hence go with the original patch to undo the propagation along dma-resv. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] Revert "drm/i915: Propagate errors on awaiting already signaled fences"
On Fri, Mar 05, 2021 at 11:05:46AM -0600, Jason Ekstrand wrote: > This reverts commit 9e31c1fe45d555a948ff66f1f0e3fe1f83ca63f7. Ever > since that commit, we've been having issues where a hang in one client > can propagate to another. In particular, a hang in an app can propagate > to the X server which causes the whole desktop to lock up. > > Signed-off-by: Jason Ekstrand > Reported-by: Marcin Slusarz > Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/3080 > Fixes: 9e31c1fe45d5 ("drm/i915: Propagate errors on awaiting already signaled > fences") Yeah I suggested to just go with the revert, so I guess on my to give you the explainer to be added to the commit message. Error propagation along fences sound like a good idea, but as your bug shows, surprising consequences, since propagating errors across security boundaries is not a good thing. What we do have is track the hangs on the ctx, and report information to userspace using RESET_STATS. That's how arb_robustness works. Also, if my understanding is still correct, the EIO from execbuf is when your context is banned (because not recoverable or too many hangs). And in all these cases it's up to userspace to figure out what is all impacted and should be reported to the application, that's not on the kernel to guess and automatically propagate. What's more, we're also building more features on top of ctx error reporting with RESET_STATS ioctl: Encrypted buffers use the same, and the userspace fence wait also relies on that mechanism. So it is the path going forward for reporting gpu hangs and resets to userspace. So all together that's why I think we should just bury this idea again as not quite the direction we want to go to, hence why I think the revert is the right option here. Maybe quote the entire above thing in the commit message, if it makes some sense? Cheers, Daniel > --- > drivers/gpu/drm/i915/i915_request.c | 8 ++-- > 1 file changed, 2 insertions(+), 6 deletions(-) > > diff --git a/drivers/gpu/drm/i915/i915_request.c > b/drivers/gpu/drm/i915/i915_request.c > index e7b4c4bc41a64..870d6083bb57e 100644 > --- a/drivers/gpu/drm/i915/i915_request.c > +++ b/drivers/gpu/drm/i915/i915_request.c > @@ -1232,10 +1232,8 @@ i915_request_await_execution(struct i915_request *rq, > > do { > fence = *child++; > - if (test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, &fence->flags)) { > - i915_sw_fence_set_error_once(&rq->submit, fence->error); > + if (test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, &fence->flags)) > continue; > - } > > if (fence->context == rq->fence.context) > continue; > @@ -1333,10 +1331,8 @@ i915_request_await_dma_fence(struct i915_request *rq, > struct dma_fence *fence) > > do { > fence = *child++; > - if (test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, &fence->flags)) { > - i915_sw_fence_set_error_once(&rq->submit, fence->error); > + if (test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, &fence->flags)) > continue; > - } > > /* >* Requests on the same timeline are explicitly ordered, along > -- > 2.29.2 > > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] Revert "drm/i915: Propagate errors on awaiting already signaled fences"
Quoting Jason Ekstrand (2021-03-05 17:05:46) > This reverts commit 9e31c1fe45d555a948ff66f1f0e3fe1f83ca63f7. Ever > since that commit, we've been having issues where a hang in one client > can propagate to another. In particular, a hang in an app can propagate > to the X server which causes the whole desktop to lock up. The fence error handling is required to prevent user's circumventing incomplete work, such as security validation or escaping isolation. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] Revert "drm/i915: Propagate errors on awaiting already signaled fences"
This reverts commit 9e31c1fe45d555a948ff66f1f0e3fe1f83ca63f7. Ever since that commit, we've been having issues where a hang in one client can propagate to another. In particular, a hang in an app can propagate to the X server which causes the whole desktop to lock up. Signed-off-by: Jason Ekstrand Reported-by: Marcin Slusarz Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/3080 Fixes: 9e31c1fe45d5 ("drm/i915: Propagate errors on awaiting already signaled fences") --- drivers/gpu/drm/i915/i915_request.c | 8 ++-- 1 file changed, 2 insertions(+), 6 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_request.c b/drivers/gpu/drm/i915/i915_request.c index e7b4c4bc41a64..870d6083bb57e 100644 --- a/drivers/gpu/drm/i915/i915_request.c +++ b/drivers/gpu/drm/i915/i915_request.c @@ -1232,10 +1232,8 @@ i915_request_await_execution(struct i915_request *rq, do { fence = *child++; - if (test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, &fence->flags)) { - i915_sw_fence_set_error_once(&rq->submit, fence->error); + if (test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, &fence->flags)) continue; - } if (fence->context == rq->fence.context) continue; @@ -1333,10 +1331,8 @@ i915_request_await_dma_fence(struct i915_request *rq, struct dma_fence *fence) do { fence = *child++; - if (test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, &fence->flags)) { - i915_sw_fence_set_error_once(&rq->submit, fence->error); + if (test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, &fence->flags)) continue; - } /* * Requests on the same timeline are explicitly ordered, along -- 2.29.2 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx