[PATCH] drm/atomic: Handle -EDEADLK with out-fences correctly

[PATCH] drm/atomic: Handle -EDEADLK with out-fences correctly

[Maarten Lankhorst]

complete_crtc_signaling is freeing fence_state, but when retrying
num_fences and fence_state are not zero'd. This caused duplicate
fd's in the fence_state array, followed by a BUG_ON in fs/file.c
because we reallocate freed memory, and installing over an existing
fd, or potential other fun.

Zero fence_state and num_fences correctly in the retry loop, which
allows kms_atomic_transition to pass.

Fixes: beaf5af48034 ("drm/fence: add out-fences support")
Cc: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Cc: Brian Starkey <brian.starkey@arm.com> (v10)
Cc: Sean Paul <seanpaul@chromium.org>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: David Airlie <airlied@linux.ie>
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: <stable@vger.kernel.org> # v4.10+
Testcase: kms_atomic_transitions.plane-all-modeset-transition-fencing
(with CONFIG_DEBUG_WW_MUTEX_SLOWPATH=y)
---
 drivers/gpu/drm/drm_atomic.c | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 1b755439f591..8ec9be4f5d50 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -2203,10 +2203,10 @@ int drm_mode_atomic_ioctl(struct drm_device *dev,
 	struct drm_atomic_state *state;
 	struct drm_modeset_acquire_ctx ctx;
 	struct drm_plane *plane;
-	struct drm_out_fence_state *fence_state = NULL;
+	struct drm_out_fence_state *fence_state;
 	unsigned plane_mask;
 	int ret = 0;
-	unsigned int i, j, num_fences = 0;
+	unsigned int i, j, num_fences;
 
 	/* disallow for drivers not supporting atomic: */
 	if (!drm_core_check_feature(dev, DRIVER_ATOMIC))
@@ -2247,6 +2247,8 @@ int drm_mode_atomic_ioctl(struct drm_device *dev,
 	plane_mask = 0;
 	copied_objs = 0;
 	copied_props = 0;
+	fence_state = NULL;
+	num_fences = 0;
 
 	for (i = 0; i < arg->count_objs; i++) {
 		uint32_t obj_id, count_props;
-- 
2.11.0

✓ Fi.CI.BAT: success for drm/atomic: Handle -EDEADLK with out-fences correctly

[Patchwork]

== Series Details ==

Series: drm/atomic: Handle -EDEADLK with out-fences correctly
URL   : https://patchwork.freedesktop.org/series/28747/
State : success

== Summary ==

Series 28747v1 drm/atomic: Handle -EDEADLK with out-fences correctly
https://patchwork.freedesktop.org/api/1.0/series/28747/revisions/1/mbox/

Test gem_exec_parallel:
        Subgroup basic:
                fail       -> PASS       (fi-ilk-650) fdo#101735
Test gem_ringfill:
        Subgroup basic-default:
                skip       -> PASS       (fi-bsw-n3050) fdo#101915
Test kms_pipe_crc_basic:
        Subgroup suspend-read-crc-pipe-b:
                dmesg-warn -> PASS       (fi-byt-n2820) fdo#101705

fdo#101735 https://bugs.freedesktop.org/show_bug.cgi?id=101735
fdo#101915 https://bugs.freedesktop.org/show_bug.cgi?id=101915
fdo#101705 https://bugs.freedesktop.org/show_bug.cgi?id=101705

fi-bdw-5557u     total:279  pass:268  dwarn:0   dfail:0   fail:0   skip:11  time:451s
fi-bdw-gvtdvm    total:279  pass:265  dwarn:0   dfail:0   fail:0   skip:14  time:437s
fi-blb-e6850     total:279  pass:224  dwarn:1   dfail:0   fail:0   skip:54  time:361s
fi-bsw-n3050     total:279  pass:243  dwarn:0   dfail:0   fail:0   skip:36  time:547s
fi-bxt-j4205     total:279  pass:260  dwarn:0   dfail:0   fail:0   skip:19  time:513s
fi-byt-j1900     total:279  pass:254  dwarn:1   dfail:0   fail:0   skip:24  time:522s
fi-byt-n2820     total:279  pass:251  dwarn:0   dfail:0   fail:0   skip:28  time:518s
fi-glk-2a        total:279  pass:260  dwarn:0   dfail:0   fail:0   skip:19  time:604s
fi-hsw-4770      total:279  pass:263  dwarn:0   dfail:0   fail:0   skip:16  time:446s
fi-hsw-4770r     total:279  pass:263  dwarn:0   dfail:0   fail:0   skip:16  time:423s
fi-ilk-650       total:279  pass:229  dwarn:0   dfail:0   fail:0   skip:50  time:419s
fi-ivb-3520m     total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  time:506s
fi-ivb-3770      total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  time:481s
fi-kbl-7500u     total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  time:473s
fi-kbl-7560u     total:279  pass:269  dwarn:0   dfail:0   fail:0   skip:10  time:580s
fi-kbl-r         total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  time:590s
fi-pnv-d510      total:279  pass:223  dwarn:1   dfail:0   fail:0   skip:55  time:521s
fi-skl-6260u     total:279  pass:269  dwarn:0   dfail:0   fail:0   skip:10  time:458s
fi-skl-6700k     total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  time:474s
fi-skl-6770hq    total:279  pass:269  dwarn:0   dfail:0   fail:0   skip:10  time:479s
fi-skl-gvtdvm    total:279  pass:266  dwarn:0   dfail:0   fail:0   skip:13  time:440s
fi-skl-x1585l    total:279  pass:269  dwarn:0   dfail:0   fail:0   skip:10  time:506s
fi-snb-2520m     total:279  pass:251  dwarn:0   dfail:0   fail:0   skip:28  time:549s
fi-snb-2600      total:279  pass:250  dwarn:0   dfail:0   fail:0   skip:29  time:404s

7a620d02bd0a7015fe8f6fc8ae830d47b101394d drm-tip: 2017y-08m-14d-09h-26m-51s UTC integration manifest
ef85eb2c273e drm/atomic: Handle -EDEADLK with out-fences correctly

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_5393/
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH] drm/atomic: Handle -EDEADLK with out-fences correctly

[Gustavo Padovan]

2017-08-14 Maarten Lankhorst <maarten.lankhorst@linux.intel.com>:

> complete_crtc_signaling is freeing fence_state, but when retrying
> num_fences and fence_state are not zero'd. This caused duplicate
> fd's in the fence_state array, followed by a BUG_ON in fs/file.c
> because we reallocate freed memory, and installing over an existing
> fd, or potential other fun.
> 
> Zero fence_state and num_fences correctly in the retry loop, which
> allows kms_atomic_transition to pass.
> 
> Fixes: beaf5af48034 ("drm/fence: add out-fences support")
> Cc: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
> Cc: Brian Starkey <brian.starkey@arm.com> (v10)
> Cc: Sean Paul <seanpaul@chromium.org>
> Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
> Cc: Jani Nikula <jani.nikula@linux.intel.com>
> Cc: David Airlie <airlied@linux.ie>
> Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
> Cc: <stable@vger.kernel.org> # v4.10+
> Testcase: kms_atomic_transitions.plane-all-modeset-transition-fencing
> (with CONFIG_DEBUG_WW_MUTEX_SLOWPATH=y)
> ---
>  drivers/gpu/drm/drm_atomic.c | 6 ++++--
>  1 file changed, 4 insertions(+), 2 deletions(-)

Reviewed-by: Gustavo Padovan <gustavo.padovan@collabora.com>

	Gustavo

Re: [PATCH] drm/atomic: Handle -EDEADLK with out-fences correctly

[Daniel Vetter]

On Fri, Aug 18, 2017 at 01:59:10PM -0300, Gustavo Padovan wrote:
> 2017-08-14 Maarten Lankhorst <maarten.lankhorst@linux.intel.com>:
> 
> > complete_crtc_signaling is freeing fence_state, but when retrying
> > num_fences and fence_state are not zero'd. This caused duplicate
> > fd's in the fence_state array, followed by a BUG_ON in fs/file.c
> > because we reallocate freed memory, and installing over an existing
> > fd, or potential other fun.
> > 
> > Zero fence_state and num_fences correctly in the retry loop, which
> > allows kms_atomic_transition to pass.
> > 
> > Fixes: beaf5af48034 ("drm/fence: add out-fences support")
> > Cc: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
> > Cc: Brian Starkey <brian.starkey@arm.com> (v10)
> > Cc: Sean Paul <seanpaul@chromium.org>
> > Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
> > Cc: Jani Nikula <jani.nikula@linux.intel.com>
> > Cc: David Airlie <airlied@linux.ie>
> > Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
> > Cc: <stable@vger.kernel.org> # v4.10+
> > Testcase: kms_atomic_transitions.plane-all-modeset-transition-fencing
> > (with CONFIG_DEBUG_WW_MUTEX_SLOWPATH=y)
> > ---
> >  drivers/gpu/drm/drm_atomic.c | 6 ++++--
> >  1 file changed, 4 insertions(+), 2 deletions(-)
> 
> Reviewed-by: Gustavo Padovan <gustavo.padovan@collabora.com>

Hm somehow this fell through, applied to drm-misc-fixes.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: [PATCH] drm/atomic: Handle -EDEADLK with out-fences correctly

[Daniel Vetter]

On Fri, Aug 18, 2017 at 01:59:10PM -0300, Gustavo Padovan wrote:
> 2017-08-14 Maarten Lankhorst <maarten.lankhorst@linux.intel.com>:
> 
> > complete_crtc_signaling is freeing fence_state, but when retrying
> > num_fences and fence_state are not zero'd. This caused duplicate
> > fd's in the fence_state array, followed by a BUG_ON in fs/file.c
> > because we reallocate freed memory, and installing over an existing
> > fd, or potential other fun.
> > 
> > Zero fence_state and num_fences correctly in the retry loop, which
> > allows kms_atomic_transition to pass.
> > 
> > Fixes: beaf5af48034 ("drm/fence: add out-fences support")
> > Cc: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
> > Cc: Brian Starkey <brian.starkey@arm.com> (v10)
> > Cc: Sean Paul <seanpaul@chromium.org>
> > Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
> > Cc: Jani Nikula <jani.nikula@linux.intel.com>
> > Cc: David Airlie <airlied@linux.ie>
> > Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
> > Cc: <stable@vger.kernel.org> # v4.10+
> > Testcase: kms_atomic_transitions.plane-all-modeset-transition-fencing
> > (with CONFIG_DEBUG_WW_MUTEX_SLOWPATH=y)
> > ---
> >  drivers/gpu/drm/drm_atomic.c | 6 ++++--
> >  1 file changed, 4 insertions(+), 2 deletions(-)
> 
> Reviewed-by: Gustavo Padovan <gustavo.padovan@collabora.com>

Hm somehow this fell through, applied to drm-misc-fixes.
-Daniel
-- 
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: [PATCH] drm/atomic: Handle -EDEADLK with out-fences correctly

[Daniel Vetter]

On Fri, Aug 18, 2017 at 10:13:08PM +0200, Daniel Vetter wrote:
> On Fri, Aug 18, 2017 at 01:59:10PM -0300, Gustavo Padovan wrote:
> > 2017-08-14 Maarten Lankhorst <maarten.lankhorst@linux.intel.com>:
> > 
> > > complete_crtc_signaling is freeing fence_state, but when retrying
> > > num_fences and fence_state are not zero'd. This caused duplicate
> > > fd's in the fence_state array, followed by a BUG_ON in fs/file.c
> > > because we reallocate freed memory, and installing over an existing
> > > fd, or potential other fun.
> > > 
> > > Zero fence_state and num_fences correctly in the retry loop, which
> > > allows kms_atomic_transition to pass.
> > > 
> > > Fixes: beaf5af48034 ("drm/fence: add out-fences support")
> > > Cc: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
> > > Cc: Brian Starkey <brian.starkey@arm.com> (v10)
> > > Cc: Sean Paul <seanpaul@chromium.org>
> > > Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
> > > Cc: Jani Nikula <jani.nikula@linux.intel.com>
> > > Cc: David Airlie <airlied@linux.ie>
> > > Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
> > > Cc: <stable@vger.kernel.org> # v4.10+
> > > Testcase: kms_atomic_transitions.plane-all-modeset-transition-fencing
> > > (with CONFIG_DEBUG_WW_MUTEX_SLOWPATH=y)
> > > ---
> > >  drivers/gpu/drm/drm_atomic.c | 6 ++++--
> > >  1 file changed, 4 insertions(+), 2 deletions(-)
> > 
> > Reviewed-by: Gustavo Padovan <gustavo.padovan@collabora.com>
> 
> Hm somehow this fell through, applied to drm-misc-fixes.

Actually it was merged already, I was on an old -fixes.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: [PATCH] drm/atomic: Handle -EDEADLK with out-fences correctly

[Daniel Vetter]

On Fri, Aug 18, 2017 at 10:13:08PM +0200, Daniel Vetter wrote:
> On Fri, Aug 18, 2017 at 01:59:10PM -0300, Gustavo Padovan wrote:
> > 2017-08-14 Maarten Lankhorst <maarten.lankhorst@linux.intel.com>:
> > 
> > > complete_crtc_signaling is freeing fence_state, but when retrying
> > > num_fences and fence_state are not zero'd. This caused duplicate
> > > fd's in the fence_state array, followed by a BUG_ON in fs/file.c
> > > because we reallocate freed memory, and installing over an existing
> > > fd, or potential other fun.
> > > 
> > > Zero fence_state and num_fences correctly in the retry loop, which
> > > allows kms_atomic_transition to pass.
> > > 
> > > Fixes: beaf5af48034 ("drm/fence: add out-fences support")
> > > Cc: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
> > > Cc: Brian Starkey <brian.starkey@arm.com> (v10)
> > > Cc: Sean Paul <seanpaul@chromium.org>
> > > Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
> > > Cc: Jani Nikula <jani.nikula@linux.intel.com>
> > > Cc: David Airlie <airlied@linux.ie>
> > > Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
> > > Cc: <stable@vger.kernel.org> # v4.10+
> > > Testcase: kms_atomic_transitions.plane-all-modeset-transition-fencing
> > > (with CONFIG_DEBUG_WW_MUTEX_SLOWPATH=y)
> > > ---
> > >  drivers/gpu/drm/drm_atomic.c | 6 ++++--
> > >  1 file changed, 4 insertions(+), 2 deletions(-)
> > 
> > Reviewed-by: Gustavo Padovan <gustavo.padovan@collabora.com>
> 
> Hm somehow this fell through, applied to drm-misc-fixes.

Actually it was merged already, I was on an old -fixes.
-Daniel
-- 
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