From b007c3fbce2655e56dec2860256ee971236f1357 Mon Sep 17 00:00:00 2001 From: Greg Kroah-Hartman Date: Wed, 28 Jul 2021 14:00:06 +0200 Subject: [PATCH] drop revert-drm-i915-propagate-errors-on-awaiting-already-signaled-fences.patch from 5.10 and 5.13 --- ...-on-awaiting-already-signaled-fences.patch | 88 ------------------- queue-5.10/series | 1 - ...-on-awaiting-already-signaled-fences.patch | 88 ------------------- queue-5.13/series | 1 - 4 files changed, 178 deletions(-) delete mode 100644 queue-5.10/revert-drm-i915-propagate-errors-on-awaiting-already-signaled-fences.patch delete mode 100644 queue-5.13/revert-drm-i915-propagate-errors-on-awaiting-already-signaled-fences.patch diff --git a/queue-5.10/revert-drm-i915-propagate-errors-on-awaiting-already-signaled-fences.patch b/queue-5.10/revert-drm-i915-propagate-errors-on-awaiting-already-signaled-fences.patch deleted file mode 100644 index 54d2a1edf70..00000000000 --- a/queue-5.10/revert-drm-i915-propagate-errors-on-awaiting-already-signaled-fences.patch +++ /dev/null @@ -1,88 +0,0 @@ -From 3761baae908a7b5012be08d70fa553cc2eb82305 Mon Sep 17 00:00:00 2001 -From: Jason Ekstrand -Date: Wed, 14 Jul 2021 14:34:16 -0500 -Subject: Revert "drm/i915: Propagate errors on awaiting already signaled fences" - -From: Jason Ekstrand - -commit 3761baae908a7b5012be08d70fa553cc2eb82305 upstream. - -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. - -For backporters: Please note that you _must_ have a backport of -https://lore.kernel.org/dri-devel/20210602164149.391653-2-jason@jlekstrand.net/ -for otherwise backporting just this patch opens up a security bug. - -v2: Augment commit message. Also restore Jason's sob that I -accidentally lost. - -v3: Add a note for backporters - -Signed-off-by: Jason Ekstrand -Reported-by: Marcin Slusarz -Cc: # v5.6+ -Cc: Jason Ekstrand -Cc: Marcin Slusarz -Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/3080 -Fixes: 9e31c1fe45d5 ("drm/i915: Propagate errors on awaiting already signaled fences") -Acked-by: Daniel Vetter -Reviewed-by: Jon Bloomfield -Signed-off-by: Daniel Vetter -Link: https://patchwork.freedesktop.org/patch/msgid/20210714193419.1459723-3-jason@jlekstrand.net -(cherry picked from commit 93a2711cddd5760e2f0f901817d71c93183c3b87) -Signed-off-by: Rodrigo Vivi -Signed-off-by: Greg Kroah-Hartman ---- - drivers/gpu/drm/i915/i915_request.c | 8 ++------ - 1 file changed, 2 insertions(+), 6 deletions(-) - ---- a/drivers/gpu/drm/i915/i915_request.c -+++ b/drivers/gpu/drm/i915/i915_request.c -@@ -1285,10 +1285,8 @@ i915_request_await_execution(struct i915 - - 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; -@@ -1386,10 +1384,8 @@ i915_request_await_dma_fence(struct i915 - - 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 diff --git a/queue-5.10/series b/queue-5.10/series index 38ac60c3c71..3db827d0f78 100644 --- a/queue-5.10/series +++ b/queue-5.10/series @@ -150,7 +150,6 @@ rbd-always-kick-acquire-on-acquired-and-released-notifications.patch misc-eeprom-at24-always-append-device-id-even-if-label-property-is-set.patch nds32-fix-up-stack-guard-gap.patch driver-core-prevent-warning-when-removing-a-device-link-from-unregistered-consumer.patch -revert-drm-i915-propagate-errors-on-awaiting-already-signaled-fences.patch drm-return-enotty-for-non-drm-ioctls.patch drm-amdgpu-update-golden-setting-for-sienna_cichlid.patch net-dsa-mv88e6xxx-enable-serdes-rx-stats-for-topaz.patch diff --git a/queue-5.13/revert-drm-i915-propagate-errors-on-awaiting-already-signaled-fences.patch b/queue-5.13/revert-drm-i915-propagate-errors-on-awaiting-already-signaled-fences.patch deleted file mode 100644 index 8ecc7d0b3b0..00000000000 --- a/queue-5.13/revert-drm-i915-propagate-errors-on-awaiting-already-signaled-fences.patch +++ /dev/null @@ -1,88 +0,0 @@ -From 3761baae908a7b5012be08d70fa553cc2eb82305 Mon Sep 17 00:00:00 2001 -From: Jason Ekstrand -Date: Wed, 14 Jul 2021 14:34:16 -0500 -Subject: Revert "drm/i915: Propagate errors on awaiting already signaled fences" - -From: Jason Ekstrand - -commit 3761baae908a7b5012be08d70fa553cc2eb82305 upstream. - -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. - -For backporters: Please note that you _must_ have a backport of -https://lore.kernel.org/dri-devel/20210602164149.391653-2-jason@jlekstrand.net/ -for otherwise backporting just this patch opens up a security bug. - -v2: Augment commit message. Also restore Jason's sob that I -accidentally lost. - -v3: Add a note for backporters - -Signed-off-by: Jason Ekstrand -Reported-by: Marcin Slusarz -Cc: # v5.6+ -Cc: Jason Ekstrand -Cc: Marcin Slusarz -Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/3080 -Fixes: 9e31c1fe45d5 ("drm/i915: Propagate errors on awaiting already signaled fences") -Acked-by: Daniel Vetter -Reviewed-by: Jon Bloomfield -Signed-off-by: Daniel Vetter -Link: https://patchwork.freedesktop.org/patch/msgid/20210714193419.1459723-3-jason@jlekstrand.net -(cherry picked from commit 93a2711cddd5760e2f0f901817d71c93183c3b87) -Signed-off-by: Rodrigo Vivi -Signed-off-by: Greg Kroah-Hartman ---- - drivers/gpu/drm/i915/i915_request.c | 8 ++------ - 1 file changed, 2 insertions(+), 6 deletions(-) - ---- 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 - - 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 - - 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 diff --git a/queue-5.13/series b/queue-5.13/series index 238de3af0d9..c3c26ae8065 100644 --- a/queue-5.13/series +++ b/queue-5.13/series @@ -205,7 +205,6 @@ rbd-always-kick-acquire-on-acquired-and-released-notifications.patch misc-eeprom-at24-always-append-device-id-even-if-label-property-is-set.patch nds32-fix-up-stack-guard-gap.patch driver-core-prevent-warning-when-removing-a-device-link-from-unregistered-consumer.patch -revert-drm-i915-propagate-errors-on-awaiting-already-signaled-fences.patch drm-return-enotty-for-non-drm-ioctls.patch drm-amdgpu-update-gc-golden-setting-for-dimgrey_cavefish.patch drm-amdgpu-update-the-golden-setting-for-vangogh.patch -- 2.47.3