[PATCH] drm/core: Do not preserve framebuffer on rmfb, v2.

[PATCH] drm/core: Do not preserve framebuffer on rmfb, v2.

[Maarten Lankhorst]

It turns out that preserving framebuffers after the rmfb call breaks
vmwgfx userspace. This was originally introduced because it was thought
nobody relied on the behavior, but unfortunately it seems there are
exceptions.

drm_framebuffer_remove may fail with -EINTR now, so a straight revert
is impossible. There is no way to remove the framebuffer from the lists
and active planes without introducing a race because of the different
locking requirements. Instead call drm_framebuffer_remove from a
workqueue, which is unaffected by signals.

Changes since v1:
- Add comment.

Cc: stable@vger.kernel.org #v4.4+
Fixes: 13803132818c ("drm/core: Preserve the framebuffer after removing it.")
Testcase: kms_flip.flip-vs-rmfb-interruptible
References: https://lists.freedesktop.org/archives/dri-devel/2016-March/102876.html
Cc: Thomas Hellstrom <thellstrom@vmware.com>
Cc: David Herrmann <dh.herrmann@gmail.com>
---
 drivers/gpu/drm/drm_crtc.c | 25 ++++++++++++++++++++++++-
 1 file changed, 24 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index e08f962288d9..aaf6ab42f2c1 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -3434,6 +3434,18 @@ int drm_mode_addfb2(struct drm_device *dev,
 	return 0;
 }
 
+struct drm_mode_rmfb_work {
+	struct work_struct work;
+	struct drm_framebuffer *fb;
+};
+
+static void drm_mode_rmfb_work_fn(struct work_struct *w)
+{
+	struct drm_mode_rmfb_work *arg = container_of(w, typeof(*arg), work);
+
+	drm_framebuffer_remove(arg->fb);
+}
+
 /**
  * drm_mode_rmfb - remove an FB from the configuration
  * @dev: drm device for the ioctl
@@ -3454,6 +3466,7 @@ int drm_mode_rmfb(struct drm_device *dev,
 	struct drm_framebuffer *fbl = NULL;
 	uint32_t *id = data;
 	int found = 0;
+	struct drm_mode_rmfb_work arg;
 
 	if (!drm_core_check_feature(dev, DRIVER_MODESET))
 		return -EINVAL;
@@ -3474,7 +3487,17 @@ int drm_mode_rmfb(struct drm_device *dev,
 	mutex_unlock(&dev->mode_config.fb_lock);
 	mutex_unlock(&file_priv->fbs_lock);
 
-	drm_framebuffer_unreference(fb);
+	/*
+	 * drm_framebuffer_remove may fail with -EINTR on pending signals,
+	 * so run this in a separate stack as there's no way to correctly
+	 * handle this after the fb is already removed from the lookup table.
+	 */
+	INIT_WORK_ONSTACK(&arg.work, drm_mode_rmfb_work_fn);
+	arg.fb = fb;
+
+	schedule_work(&arg.work);
+	flush_work(&arg.work);
+	destroy_work_on_stack(&arg.work);
 
 	return 0;
 
-- 
2.1.0

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

✗ Fi.CI.BAT: failure for drm/core: Do not preserve framebuffer on rmfb, v2.

[Patchwork]

== Series Details ==

Series: drm/core: Do not preserve framebuffer on rmfb, v2.
URL   : https://patchwork.freedesktop.org/series/4743/
State : failure

== Summary ==

Series 4743v1 drm/core: Do not preserve framebuffer on rmfb, v2.
http://patchwork.freedesktop.org/api/1.0/series/4743/revisions/1/mbox/

Test gem_exec_suspend:
        Subgroup basic-s3:
                pass       -> DMESG-WARN (bsw-nuc-2)
Test kms_flip:
        Subgroup basic-flip-vs-dpms:
                dmesg-warn -> PASS       (ilk-hp8440p) UNSTABLE
        Subgroup basic-flip-vs-wf_vblank:
                pass       -> FAIL       (byt-nuc)
        Subgroup basic-plain-flip:
                dmesg-warn -> PASS       (bdw-ultra)
Test kms_frontbuffer_tracking:
        Subgroup basic:
                pass       -> DMESG-WARN (snb-x220t)
Test kms_pipe_crc_basic:
        Subgroup suspend-read-crc-pipe-c:
                dmesg-warn -> PASS       (bsw-nuc-2)
Test kms_setmode:
        Subgroup basic-clone-single-crtc:
                pass       -> DMESG-WARN (snb-dellxps)
Test pm_rpm:
        Subgroup basic-pci-d3-state:
                pass       -> DMESG-WARN (bsw-nuc-2)
                pass       -> DMESG-WARN (byt-nuc)
        Subgroup basic-rte:
                dmesg-warn -> PASS       (snb-x220t)
                dmesg-warn -> PASS       (snb-dellxps)
                dmesg-warn -> PASS       (byt-nuc) UNSTABLE

bdw-nuci7        total:192  pass:180  dwarn:0   dfail:0   fail:0   skip:12 
bdw-ultra        total:192  pass:171  dwarn:0   dfail:0   fail:0   skip:21 
bsw-nuc-2        total:192  pass:153  dwarn:2   dfail:0   fail:0   skip:37 
byt-nuc          total:192  pass:155  dwarn:1   dfail:0   fail:1   skip:35 
hsw-brixbox      total:192  pass:170  dwarn:0   dfail:0   fail:0   skip:22 
ilk-hp8440p      total:192  pass:129  dwarn:0   dfail:0   fail:0   skip:63 
ivb-t430s        total:192  pass:167  dwarn:0   dfail:0   fail:0   skip:25 
skl-i5k-2        total:192  pass:169  dwarn:0   dfail:0   fail:0   skip:23 
skl-i7k-2        total:192  pass:169  dwarn:0   dfail:0   fail:0   skip:23 
snb-dellxps      total:192  pass:157  dwarn:1   dfail:0   fail:0   skip:34 
snb-x220t        total:192  pass:157  dwarn:1   dfail:0   fail:1   skip:33 

Results at /archive/results/CI_IGT_test/Patchwork_1671/

4b39223f6e3bef4dfa678f7239dcd87c38e20e96 drm-intel-nightly: 2016y-03m-21d-18h-43m-18s UTC integration manifest
0584a277f33ed99384ba7395a504a778f827faf1 drm/core: Do not preserve framebuffer on rmfb, v2.

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[PATCH] drm/core: Do not preserve framebuffer on rmfb, v3.

[Maarten Lankhorst]

It turns out that preserving framebuffers after the rmfb call breaks
vmwgfx userspace. This was originally introduced because it was thought
nobody relied on the behavior, but unfortunately it seems there are
exceptions.

drm_framebuffer_remove may fail with -EINTR now, so a straight revert
is impossible. There is no way to remove the framebuffer from the lists
and active planes without introducing a race because of the different
locking requirements. Instead call drm_framebuffer_remove from a
workqueue, which is unaffected by signals.

Changes since v1:
- Add comment.
Changes since v2:
- Add fastpath for refcount = 1. (danvet)

Cc: stable@vger.kernel.org #v4.4+
Fixes: 13803132818c ("drm/core: Preserve the framebuffer after removing it.")
Testcase: kms_flip.flip-vs-rmfb-interruptible
References: https://lists.freedesktop.org/archives/dri-devel/2016-March/102876.html
Cc: Thomas Hellstrom <thellstrom@vmware.com>
Cc: David Herrmann <dh.herrmann@gmail.com>
---
 drivers/gpu/drm/drm_crtc.c | 29 ++++++++++++++++++++++++++++-
 1 file changed, 28 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 55ffde5a3a4a..743bece1f579 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -3434,6 +3434,18 @@ int drm_mode_addfb2(struct drm_device *dev,
 	return 0;
 }
 
+struct drm_mode_rmfb_work {
+	struct work_struct work;
+	struct drm_framebuffer *fb;
+};
+
+static void drm_mode_rmfb_work_fn(struct work_struct *w)
+{
+	struct drm_mode_rmfb_work *arg = container_of(w, typeof(*arg), work);
+
+	drm_framebuffer_remove(arg->fb);
+}
+
 /**
  * drm_mode_rmfb - remove an FB from the configuration
  * @dev: drm device for the ioctl
@@ -3474,7 +3486,22 @@ int drm_mode_rmfb(struct drm_device *dev,
 	mutex_unlock(&dev->mode_config.fb_lock);
 	mutex_unlock(&file_priv->fbs_lock);
 
-	drm_framebuffer_unreference(fb);
+	/*
+	 * drm_framebuffer_remove may fail with -EINTR on pending signals,
+	 * so run this in a separate stack as there's no way to correctly
+	 * handle this after the fb is already removed from the lookup table.
+	 */
+	if (atomic_read(&fb->refcount.refcount) > 1) {
+		struct drm_mode_rmfb_work arg;
+
+		INIT_WORK_ONSTACK(&arg.work, drm_mode_rmfb_work_fn);
+		arg.fb = fb;
+
+		schedule_work(&arg.work);
+		flush_work(&arg.work);
+		destroy_work_on_stack(&arg.work);
+	} else
+		drm_framebuffer_unreference(fb);
 
 	return 0;
 
-- 
2.1.0

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/core: Do not preserve framebuffer on rmfb, v3.

[Maarten Lankhorst]

Op 31-03-16 om 13:26 schreef Maarten Lankhorst:
> It turns out that preserving framebuffers after the rmfb call breaks
> vmwgfx userspace. This was originally introduced because it was thought
> nobody relied on the behavior, but unfortunately it seems there are
> exceptions.
>
> drm_framebuffer_remove may fail with -EINTR now, so a straight revert
> is impossible. There is no way to remove the framebuffer from the lists
> and active planes without introducing a race because of the different
> locking requirements. Instead call drm_framebuffer_remove from a
> workqueue, which is unaffected by signals.
>
Ping?
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/core: Do not preserve framebuffer on rmfb, v3.

[Daniel Vetter]

On Thu, Mar 31, 2016 at 01:26:03PM +0200, Maarten Lankhorst wrote:
> It turns out that preserving framebuffers after the rmfb call breaks
> vmwgfx userspace. This was originally introduced because it was thought
> nobody relied on the behavior, but unfortunately it seems there are
> exceptions.
> 
> drm_framebuffer_remove may fail with -EINTR now, so a straight revert
> is impossible. There is no way to remove the framebuffer from the lists
> and active planes without introducing a race because of the different
> locking requirements. Instead call drm_framebuffer_remove from a
> workqueue, which is unaffected by signals.
> 
> Changes since v1:
> - Add comment.
> Changes since v2:
> - Add fastpath for refcount = 1. (danvet)
> 
> Cc: stable@vger.kernel.org #v4.4+
> Fixes: 13803132818c ("drm/core: Preserve the framebuffer after removing it.")
> Testcase: kms_flip.flip-vs-rmfb-interruptible
> References: https://lists.freedesktop.org/archives/dri-devel/2016-March/102876.html
> Cc: Thomas Hellstrom <thellstrom@vmware.com>
> Cc: David Herrmann <dh.herrmann@gmail.com>

Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>

But definitely want a t-b from Thomas before applying, since he reported
this regression.
-Daniel

> ---
>  drivers/gpu/drm/drm_crtc.c | 29 ++++++++++++++++++++++++++++-
>  1 file changed, 28 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index 55ffde5a3a4a..743bece1f579 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -3434,6 +3434,18 @@ int drm_mode_addfb2(struct drm_device *dev,
>  	return 0;
>  }
>  
> +struct drm_mode_rmfb_work {
> +	struct work_struct work;
> +	struct drm_framebuffer *fb;
> +};
> +
> +static void drm_mode_rmfb_work_fn(struct work_struct *w)
> +{
> +	struct drm_mode_rmfb_work *arg = container_of(w, typeof(*arg), work);
> +
> +	drm_framebuffer_remove(arg->fb);
> +}
> +
>  /**
>   * drm_mode_rmfb - remove an FB from the configuration
>   * @dev: drm device for the ioctl
> @@ -3474,7 +3486,22 @@ int drm_mode_rmfb(struct drm_device *dev,
>  	mutex_unlock(&dev->mode_config.fb_lock);
>  	mutex_unlock(&file_priv->fbs_lock);
>  
> -	drm_framebuffer_unreference(fb);
> +	/*
> +	 * drm_framebuffer_remove may fail with -EINTR on pending signals,
> +	 * so run this in a separate stack as there's no way to correctly
> +	 * handle this after the fb is already removed from the lookup table.
> +	 */
> +	if (atomic_read(&fb->refcount.refcount) > 1) {
> +		struct drm_mode_rmfb_work arg;
> +
> +		INIT_WORK_ONSTACK(&arg.work, drm_mode_rmfb_work_fn);
> +		arg.fb = fb;
> +
> +		schedule_work(&arg.work);
> +		flush_work(&arg.work);
> +		destroy_work_on_stack(&arg.work);
> +	} else
> +		drm_framebuffer_unreference(fb);
>  
>  	return 0;
>  
> -- 
> 2.1.0
> 
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: [PATCH] drm/core: Do not preserve framebuffer on rmfb, v3.

[Daniel Vetter]

On Thu, Mar 31, 2016 at 01:26:03PM +0200, Maarten Lankhorst wrote:
> It turns out that preserving framebuffers after the rmfb call breaks
> vmwgfx userspace. This was originally introduced because it was thought
> nobody relied on the behavior, but unfortunately it seems there are
> exceptions.
> 
> drm_framebuffer_remove may fail with -EINTR now, so a straight revert
> is impossible. There is no way to remove the framebuffer from the lists
> and active planes without introducing a race because of the different
> locking requirements. Instead call drm_framebuffer_remove from a
> workqueue, which is unaffected by signals.
> 
> Changes since v1:
> - Add comment.
> Changes since v2:
> - Add fastpath for refcount = 1. (danvet)
> 
> Cc: stable@vger.kernel.org #v4.4+
> Fixes: 13803132818c ("drm/core: Preserve the framebuffer after removing it.")
> Testcase: kms_flip.flip-vs-rmfb-interruptible
> References: https://lists.freedesktop.org/archives/dri-devel/2016-March/102876.html
> Cc: Thomas Hellstrom <thellstrom@vmware.com>
> Cc: David Herrmann <dh.herrmann@gmail.com>

Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>

But definitely want a t-b from Thomas before applying, since he reported
this regression.
-Daniel

> ---
>  drivers/gpu/drm/drm_crtc.c | 29 ++++++++++++++++++++++++++++-
>  1 file changed, 28 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index 55ffde5a3a4a..743bece1f579 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -3434,6 +3434,18 @@ int drm_mode_addfb2(struct drm_device *dev,
>  	return 0;
>  }
>  
> +struct drm_mode_rmfb_work {
> +	struct work_struct work;
> +	struct drm_framebuffer *fb;
> +};
> +
> +static void drm_mode_rmfb_work_fn(struct work_struct *w)
> +{
> +	struct drm_mode_rmfb_work *arg = container_of(w, typeof(*arg), work);
> +
> +	drm_framebuffer_remove(arg->fb);
> +}
> +
>  /**
>   * drm_mode_rmfb - remove an FB from the configuration
>   * @dev: drm device for the ioctl
> @@ -3474,7 +3486,22 @@ int drm_mode_rmfb(struct drm_device *dev,
>  	mutex_unlock(&dev->mode_config.fb_lock);
>  	mutex_unlock(&file_priv->fbs_lock);
>  
> -	drm_framebuffer_unreference(fb);
> +	/*
> +	 * drm_framebuffer_remove may fail with -EINTR on pending signals,
> +	 * so run this in a separate stack as there's no way to correctly
> +	 * handle this after the fb is already removed from the lookup table.
> +	 */
> +	if (atomic_read(&fb->refcount.refcount) > 1) {
> +		struct drm_mode_rmfb_work arg;
> +
> +		INIT_WORK_ONSTACK(&arg.work, drm_mode_rmfb_work_fn);
> +		arg.fb = fb;
> +
> +		schedule_work(&arg.work);
> +		flush_work(&arg.work);
> +		destroy_work_on_stack(&arg.work);
> +	} else
> +		drm_framebuffer_unreference(fb);
>  
>  	return 0;
>  
> -- 
> 2.1.0
> 
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
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

[REBASED PATCH] drm/core: Do not preserve framebuffer on rmfb, v3.

[Maarten Lankhorst]

It turns out that preserving framebuffers after the rmfb call breaks
vmwgfx userspace. This was originally introduced because it was thought
nobody relied on the behavior, but unfortunately it seems there are
exceptions.

drm_framebuffer_remove may fail with -EINTR now, so a straight revert
is impossible. There is no way to remove the framebuffer from the lists
and active planes without introducing a race because of the different
locking requirements. Instead call drm_framebuffer_remove from a
workqueue, which is unaffected by signals.

Changes since v1:
- Add comment.
Changes since v2:
- Add fastpath for refcount = 1. (danvet)

Cc: stable@vger.kernel.org #v4.4+
Fixes: 13803132818c ("drm/core: Preserve the framebuffer after removing it.")
Testcase: kms_flip.flip-vs-rmfb-interruptible
References: https://lists.freedesktop.org/archives/dri-devel/2016-March/102876.html
Cc: Thomas Hellstrom <thellstrom@vmware.com>
Cc: David Herrmann <dh.herrmann@gmail.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
---
Rebased version.

 drivers/gpu/drm/drm_crtc.c | 32 ++++++++++++++++++++++++++++++--
 1 file changed, 30 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 9626a0cc050a..88f85c90bbed 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -3440,6 +3440,18 @@ int drm_mode_addfb2(struct drm_device *dev,
 	return 0;
 }
 
+struct drm_mode_rmfb_work {
+	struct work_struct work;
+	struct drm_framebuffer *fb;
+};
+
+static void drm_mode_rmfb_work_fn(struct work_struct *w)
+{
+	struct drm_mode_rmfb_work *arg = container_of(w, typeof(*arg), work);
+
+	drm_framebuffer_remove(arg->fb);
+}
+
 /**
  * drm_mode_rmfb - remove an FB from the configuration
  * @dev: drm device for the ioctl
@@ -3480,8 +3492,24 @@ int drm_mode_rmfb(struct drm_device *dev,
 	list_del_init(&fb->filp_head);
 	mutex_unlock(&file_priv->fbs_lock);
 
-	/* we now own the reference that was stored in the fbs list */
-	drm_framebuffer_unreference(fb);
+	/*
+	 * we now own the reference that was stored in the fbs list
+	 *
+	 * drm_framebuffer_remove may fail with -EINTR on pending signals,
+	 * so run this in a separate stack as there's no way to correctly
+	 * handle this after the fb is already removed from the lookup table.
+	 */
+	if (atomic_read(&fb->refcount.refcount) > 1) {
+		struct drm_mode_rmfb_work arg;
+
+		INIT_WORK_ONSTACK(&arg.work, drm_mode_rmfb_work_fn);
+		arg.fb = fb;
+
+		schedule_work(&arg.work);
+		flush_work(&arg.work);
+		destroy_work_on_stack(&arg.work);
+	} else
+		drm_framebuffer_unreference(fb);
 
 	/* drop the reference we picked up in framebuffer lookup */
 	drm_framebuffer_unreference(fb);
-- 
2.5.5

[REBASED PATCH] drm/core: Do not preserve framebuffer on rmfb, v3.

[Maarten Lankhorst]

It turns out that preserving framebuffers after the rmfb call breaks
vmwgfx userspace. This was originally introduced because it was thought
nobody relied on the behavior, but unfortunately it seems there are
exceptions.

drm_framebuffer_remove may fail with -EINTR now, so a straight revert
is impossible. There is no way to remove the framebuffer from the lists
and active planes without introducing a race because of the different
locking requirements. Instead call drm_framebuffer_remove from a
workqueue, which is unaffected by signals.

Changes since v1:
- Add comment.
Changes since v2:
- Add fastpath for refcount = 1. (danvet)

Cc: stable@vger.kernel.org #v4.4+
Fixes: 13803132818c ("drm/core: Preserve the framebuffer after removing it.")
Testcase: kms_flip.flip-vs-rmfb-interruptible
References: https://lists.freedesktop.org/archives/dri-devel/2016-March/102876.html
Cc: Thomas Hellstrom <thellstrom@vmware.com>
Cc: David Herrmann <dh.herrmann@gmail.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
---
Rebased version.

 drivers/gpu/drm/drm_crtc.c | 32 ++++++++++++++++++++++++++++++--
 1 file changed, 30 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 9626a0cc050a..88f85c90bbed 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -3440,6 +3440,18 @@ int drm_mode_addfb2(struct drm_device *dev,
 	return 0;
 }
 
+struct drm_mode_rmfb_work {
+	struct work_struct work;
+	struct drm_framebuffer *fb;
+};
+
+static void drm_mode_rmfb_work_fn(struct work_struct *w)
+{
+	struct drm_mode_rmfb_work *arg = container_of(w, typeof(*arg), work);
+
+	drm_framebuffer_remove(arg->fb);
+}
+
 /**
  * drm_mode_rmfb - remove an FB from the configuration
  * @dev: drm device for the ioctl
@@ -3480,8 +3492,24 @@ int drm_mode_rmfb(struct drm_device *dev,
 	list_del_init(&fb->filp_head);
 	mutex_unlock(&file_priv->fbs_lock);
 
-	/* we now own the reference that was stored in the fbs list */
-	drm_framebuffer_unreference(fb);
+	/*
+	 * we now own the reference that was stored in the fbs list
+	 *
+	 * drm_framebuffer_remove may fail with -EINTR on pending signals,
+	 * so run this in a separate stack as there's no way to correctly
+	 * handle this after the fb is already removed from the lookup table.
+	 */
+	if (atomic_read(&fb->refcount.refcount) > 1) {
+		struct drm_mode_rmfb_work arg;
+
+		INIT_WORK_ONSTACK(&arg.work, drm_mode_rmfb_work_fn);
+		arg.fb = fb;
+
+		schedule_work(&arg.work);
+		flush_work(&arg.work);
+		destroy_work_on_stack(&arg.work);
+	} else
+		drm_framebuffer_unreference(fb);
 
 	/* drop the reference we picked up in framebuffer lookup */
 	drm_framebuffer_unreference(fb);
-- 
2.5.5


_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/core: Do not preserve framebuffer on rmfb, v3.

[Thomas Hellstrom]

Hi,

Sorry for the late response, been very busy with other stuff lately.

I've tested this version against drm-fixes and it indeed fixes the
problem, as far as I can tell.

Tested-by: Thomas Hellstrom <thellstrom@vmware.com>


On 03/31/2016 01:26 PM, Maarten Lankhorst wrote:
> It turns out that preserving framebuffers after the rmfb call breaks
> vmwgfx userspace. This was originally introduced because it was thought
> nobody relied on the behavior, but unfortunately it seems there are
> exceptions.
>
> drm_framebuffer_remove may fail with -EINTR now, so a straight revert
> is impossible. There is no way to remove the framebuffer from the lists
> and active planes without introducing a race because of the different
> locking requirements. Instead call drm_framebuffer_remove from a
> workqueue, which is unaffected by signals.
>
> Changes since v1:
> - Add comment.
> Changes since v2:
> - Add fastpath for refcount = 1. (danvet)
>
> Cc: stable@vger.kernel.org #v4.4+
> Fixes: 13803132818c ("drm/core: Preserve the framebuffer after removing it.")
> Testcase: kms_flip.flip-vs-rmfb-interruptible
> References: https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.freedesktop.org_archives_dri-2Ddevel_2016-2DMarch_102876.html&d=BQIBAg&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=vpukPkBtpoNQp2IUKuFviOmPNYWVKmen3Jeeu55zmEA&m=_2qOX1NGnSnJOTgqvu1Ud574i5T3fLDlX91oUS3WXXI&s=9D34PFYdb1PT2vzX_M_7lNVoSebfM9-KsAqe5AXAQbQ&e= 
> Cc: Thomas Hellstrom <thellstrom@vmware.com>
> Cc: David Herrmann <dh.herrmann@gmail.com>
> ---
>  drivers/gpu/drm/drm_crtc.c | 29 ++++++++++++++++++++++++++++-
>  1 file changed, 28 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index 55ffde5a3a4a..743bece1f579 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -3434,6 +3434,18 @@ int drm_mode_addfb2(struct drm_device *dev,
>  	return 0;
>  }
>  
> +struct drm_mode_rmfb_work {
> +	struct work_struct work;
> +	struct drm_framebuffer *fb;
> +};
> +
> +static void drm_mode_rmfb_work_fn(struct work_struct *w)
> +{
> +	struct drm_mode_rmfb_work *arg = container_of(w, typeof(*arg), work);
> +
> +	drm_framebuffer_remove(arg->fb);
> +}
> +
>  /**
>   * drm_mode_rmfb - remove an FB from the configuration
>   * @dev: drm device for the ioctl
> @@ -3474,7 +3486,22 @@ int drm_mode_rmfb(struct drm_device *dev,
>  	mutex_unlock(&dev->mode_config.fb_lock);
>  	mutex_unlock(&file_priv->fbs_lock);
>  
> -	drm_framebuffer_unreference(fb);
> +	/*
> +	 * drm_framebuffer_remove may fail with -EINTR on pending signals,
> +	 * so run this in a separate stack as there's no way to correctly
> +	 * handle this after the fb is already removed from the lookup table.
> +	 */
> +	if (atomic_read(&fb->refcount.refcount) > 1) {
> +		struct drm_mode_rmfb_work arg;
> +
> +		INIT_WORK_ONSTACK(&arg.work, drm_mode_rmfb_work_fn);
> +		arg.fb = fb;
> +
> +		schedule_work(&arg.work);
> +		flush_work(&arg.work);
> +		destroy_work_on_stack(&arg.work);
> +	} else
> +		drm_framebuffer_unreference(fb);
>  
>  	return 0;
>  

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[PATCH i-g-t] tests/kms: Add test for testing rmfb framebuffer removal handling.

[Maarten Lankhorst]

Add some tests to BAT to ensure rmfb/lastclose handling doesn't break again.

The test will set framebuffers on each crtc, and then try rmfb or close.
Afterwards it rechecks to make sure the framebuffers are removed.

Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
---
diff --git a/tests/Makefile.sources b/tests/Makefile.sources
index b73f48d95568..92c84d697ded 100644
--- a/tests/Makefile.sources
+++ b/tests/Makefile.sources
@@ -97,6 +97,7 @@ TESTS_progs_M = \
 	kms_plane \
 	kms_psr_sink_crc \
 	kms_render \
+	kms_rmfb_basic \
 	kms_rotation_crc \
 	kms_setmode \
 	kms_universal_plane \
diff --git a/tests/kms_rmfb_basic.c b/tests/kms_rmfb_basic.c
new file mode 100644
index 000000000000..a3fde9f43788
--- /dev/null
+++ b/tests/kms_rmfb_basic.c
@@ -0,0 +1,180 @@
+/*
+ * Copyright © 2016 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ */
+
+#include "igt.h"
+#include "drmtest.h"
+#include <errno.h>
+#include <stdbool.h>
+#include <stdio.h>
+#include <string.h>
+#include <time.h>
+
+#ifndef DRM_CAP_CURSOR_WIDTH
+#define DRM_CAP_CURSOR_WIDTH 0x8
+#endif
+#ifndef DRM_CAP_CURSOR_HEIGHT
+#define DRM_CAP_CURSOR_HEIGHT 0x9
+#endif
+
+struct rmfb_data {
+	int drm_fd;
+	igt_display_t display;
+};
+
+/*
+ * 1. Set primary plane to a known fb.
+ * 2. Make sure getcrtc returns the correct fb id.
+ * 3. Call rmfb on the fb.
+ * 4. Make sure getcrtc returns 0 fb id.
+ *
+ * RMFB is supposed to free the framebuffers from any and all planes,
+ * so test this and make sure it works.
+ */
+static bool
+test_rmfb(struct rmfb_data *data, igt_output_t *output, enum pipe pipe, bool reopen)
+{
+	struct igt_fb fb, argb_fb;
+	drmModeModeInfo *mode;
+	igt_plane_t *plane;
+	drmModeCrtc *crtc;
+	uint64_t cursor_width, cursor_height;
+
+	igt_output_set_pipe(output, pipe);
+	igt_display_commit(&data->display);
+
+	if (!output->valid) {
+		igt_output_set_pipe(output, PIPE_ANY);
+		return false;
+	}
+
+	mode = igt_output_get_mode(output);
+
+	igt_create_fb(data->drm_fd, mode->hdisplay, mode->vdisplay,
+		      DRM_FORMAT_XRGB8888, LOCAL_DRM_FORMAT_MOD_NONE, &fb);
+
+	igt_create_fb(data->drm_fd, mode->hdisplay, mode->vdisplay,
+		      DRM_FORMAT_ARGB8888, LOCAL_DRM_FORMAT_MOD_NONE, &argb_fb);
+
+	do_or_die(drmGetCap(data->drm_fd, DRM_CAP_CURSOR_WIDTH, &cursor_width));
+	if (cursor_width > mode->hdisplay)
+		cursor_width = mode->hdisplay;
+
+	do_or_die(drmGetCap(data->drm_fd, DRM_CAP_CURSOR_HEIGHT, &cursor_height));
+	if (cursor_height > mode->vdisplay)
+		cursor_height = mode->vdisplay;
+
+	/*
+	 * Make sure these buffers are suited for display use
+	 * because most of the modeset operations must be fast
+	 * later on.
+	 */
+	for_each_plane_on_pipe(&data->display, pipe, plane) {
+		if (plane->is_cursor) {
+			igt_plane_set_fb(plane, &argb_fb);
+			igt_fb_set_size(&argb_fb, plane, cursor_width, cursor_height);
+			igt_plane_set_size(plane, cursor_width, cursor_height);
+		} else {
+			igt_plane_set_fb(plane, &fb);
+		}
+	}
+
+	igt_display_commit2(&data->display, data->display.is_atomic ? COMMIT_ATOMIC : COMMIT_UNIVERSAL);
+
+	crtc = drmModeGetCrtc(data->drm_fd, output->config.crtc->crtc_id);
+
+	igt_assert_eq(crtc->buffer_id, fb.fb_id);
+
+	drmModeFreeCrtc(crtc);
+
+	if (reopen) {
+		close(data->drm_fd);
+
+		data->drm_fd = drm_open_driver_master(DRIVER_ANY);
+		drmSetClientCap(data->drm_fd, DRM_CLIENT_CAP_UNIVERSAL_PLANES, 1);
+		drmSetClientCap(data->drm_fd, DRM_CLIENT_CAP_ATOMIC, 1);
+	} else {
+		igt_remove_fb(data->drm_fd, &fb);
+		igt_remove_fb(data->drm_fd, &argb_fb);
+	}
+
+	crtc = drmModeGetCrtc(data->drm_fd, output->config.crtc->crtc_id);
+
+	igt_assert_eq(crtc->buffer_id, 0);
+
+	drmModeFreeCrtc(crtc);
+
+	for_each_plane_on_pipe(&data->display, pipe, plane) {
+		drmModePlanePtr planeres = drmModeGetPlane(data->drm_fd, plane->drm_plane->plane_id);
+
+		igt_assert_eq(planeres->fb_id, 0);
+
+		drmModeFreePlane(planeres);
+	}
+
+	igt_output_set_pipe(output, PIPE_ANY);
+	igt_display_commit2(&data->display, data->display.is_atomic ? COMMIT_ATOMIC : COMMIT_UNIVERSAL);
+
+	return true;
+}
+
+static void
+run_rmfb_test(struct rmfb_data *data, bool reopen)
+{
+	igt_output_t *output;
+	int valid_tests = 0;
+	enum pipe pipe;
+
+	for_each_connected_output(&data->display, output) {
+		for_each_pipe(&data->display, pipe) {
+			if (test_rmfb(data, output, pipe, reopen))
+				valid_tests++;
+		}
+	}
+
+	igt_require_f(valid_tests, "no valid crtc/connector combinations found\n");
+}
+
+igt_main
+{
+	struct rmfb_data data = {};
+
+	igt_skip_on_simulation();
+
+	igt_fixture {
+		data.drm_fd = drm_open_driver_master(DRIVER_ANY);
+
+		kmstest_set_vt_graphics_mode();
+
+		igt_display_init(&data.display, data.drm_fd);
+	}
+
+	igt_subtest_f("rmfb-ioctl")
+		run_rmfb_test(&data, false);
+
+	igt_subtest_f("close-fd")
+		run_rmfb_test(&data, true);
+
+	igt_fixture {
+		igt_display_fini(&data.display);
+	}
+}

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[PATCH] drm/core: Do not preserve framebuffer on rmfb, v4.

[Maarten Lankhorst]

It turns out that preserving framebuffers after the rmfb call breaks
vmwgfx userspace. This was originally introduced because it was thought
nobody relied on the behavior, but unfortunately it seems there are
exceptions.

drm_framebuffer_remove may fail with -EINTR now, so a straight revert
is impossible. There is no way to remove the framebuffer from the lists
and active planes without introducing a race because of the different
locking requirements. Instead call drm_framebuffer_remove from a
workqueue, which is unaffected by signals.

Changes since v1:
- Add comment.
Changes since v2:
- Add fastpath for refcount = 1. (danvet)
Changes since v3:
- Rebased.
- Restore lastclose framebuffer removal too.

Cc: stable@vger.kernel.org #v4.4+
Fixes: 13803132818c ("drm/core: Preserve the framebuffer after removing it.")
Testcase: kms_rmfb_basic
References: https://lists.freedesktop.org/archives/dri-devel/2016-March/102876.html
Cc: Thomas Hellstrom <thellstrom@vmware.com>
Cc: David Herrmann <dh.herrmann@gmail.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Tested-by: Thomas Hellstrom <thellstrom@vmware.com> #v3
---
 drivers/gpu/drm/drm_crtc.c | 63 ++++++++++++++++++++++++++++++++++++++++------
 1 file changed, 56 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 9626a0cc050a..9a3d17b70091 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -3440,6 +3440,24 @@ int drm_mode_addfb2(struct drm_device *dev,
 	return 0;
 }
 
+struct drm_mode_rmfb_work {
+	struct work_struct work;
+	struct list_head fbs;
+};
+
+static void drm_mode_rmfb_work_fn(struct work_struct *w)
+{
+	struct drm_mode_rmfb_work *arg = container_of(w, typeof(*arg), work);
+
+	while (!list_empty(&arg->fbs)) {
+		struct drm_framebuffer *fb =
+			list_first_entry(&arg->fbs, typeof(*fb), filp_head);
+
+		list_del_init(&fb->filp_head);
+		drm_framebuffer_remove(fb);
+	}
+}
+
 /**
  * drm_mode_rmfb - remove an FB from the configuration
  * @dev: drm device for the ioctl
@@ -3480,12 +3498,29 @@ int drm_mode_rmfb(struct drm_device *dev,
 	list_del_init(&fb->filp_head);
 	mutex_unlock(&file_priv->fbs_lock);
 
-	/* we now own the reference that was stored in the fbs list */
-	drm_framebuffer_unreference(fb);
-
 	/* drop the reference we picked up in framebuffer lookup */
 	drm_framebuffer_unreference(fb);
 
+	/*
+	 * we now own the reference that was stored in the fbs list
+	 *
+	 * drm_framebuffer_remove may fail with -EINTR on pending signals,
+	 * so run this in a separate stack as there's no way to correctly
+	 * handle this after the fb is already removed from the lookup table.
+	 */
+	if (drm_framebuffer_read_refcount(fb) > 1) {
+		struct drm_mode_rmfb_work arg;
+
+		INIT_WORK_ONSTACK(&arg.work, drm_mode_rmfb_work_fn);
+		INIT_LIST_HEAD(&arg.fbs);
+		list_add_tail(&fb->filp_head, &arg.fbs);
+
+		schedule_work(&arg.work);
+		flush_work(&arg.work);
+		destroy_work_on_stack(&arg.work);
+	} else
+		drm_framebuffer_unreference(fb);
+
 	return 0;
 
 fail_unref:
@@ -3635,7 +3670,6 @@ out_err1:
 	return ret;
 }
 
-
 /**
  * drm_fb_release - remove and free the FBs on this file
  * @priv: drm file for the ioctl
@@ -3650,6 +3684,9 @@ out_err1:
 void drm_fb_release(struct drm_file *priv)
 {
 	struct drm_framebuffer *fb, *tfb;
+	struct drm_mode_rmfb_work arg;
+
+	INIT_LIST_HEAD(&arg.fbs);
 
 	/*
 	 * When the file gets released that means no one else can access the fb
@@ -3662,10 +3699,22 @@ void drm_fb_release(struct drm_file *priv)
 	 * at it any more.
 	 */
 	list_for_each_entry_safe(fb, tfb, &priv->fbs, filp_head) {
-		list_del_init(&fb->filp_head);
+		if (drm_framebuffer_read_refcount(fb) > 1) {
+			list_move_tail(&fb->filp_head, &arg.fbs);
+		} else {
+			list_del_init(&fb->filp_head);
 
-		/* This drops the fpriv->fbs reference. */
-		drm_framebuffer_unreference(fb);
+			/* This drops the fpriv->fbs reference. */
+			drm_framebuffer_unreference(fb);
+		}
+	}
+
+	if (!list_empty(&arg.fbs)) {
+		INIT_WORK_ONSTACK(&arg.work, drm_mode_rmfb_work_fn);
+
+		schedule_work(&arg.work);
+		flush_work(&arg.work);
+		destroy_work_on_stack(&arg.work);
 	}
 }
 
-- 
2.5.5


_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/core: Do not preserve framebuffer on rmfb, v4.

[Tvrtko Ursulin]

On 04/05/16 13:38, Maarten Lankhorst wrote:
> It turns out that preserving framebuffers after the rmfb call breaks
> vmwgfx userspace. This was originally introduced because it was thought
> nobody relied on the behavior, but unfortunately it seems there are
> exceptions.
>
> drm_framebuffer_remove may fail with -EINTR now, so a straight revert
> is impossible. There is no way to remove the framebuffer from the lists
> and active planes without introducing a race because of the different
> locking requirements. Instead call drm_framebuffer_remove from a
> workqueue, which is unaffected by signals.
>
> Changes since v1:
> - Add comment.
> Changes since v2:
> - Add fastpath for refcount = 1. (danvet)
> Changes since v3:
> - Rebased.
> - Restore lastclose framebuffer removal too.
>
> Cc: stable@vger.kernel.org #v4.4+
> Fixes: 13803132818c ("drm/core: Preserve the framebuffer after removing it.")
> Testcase: kms_rmfb_basic
> References: https://lists.freedesktop.org/archives/dri-devel/2016-March/102876.html
> Cc: Thomas Hellstrom <thellstrom@vmware.com>
> Cc: David Herrmann <dh.herrmann@gmail.com>
> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
> Tested-by: Thomas Hellstrom <thellstrom@vmware.com> #v3

Can't be 100% since apparently eDP regressed a lot recently for me, but 
seems to be effective in getting rid of stale planes in my test cases.

Tested-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>

Regards,

Tvrtko

> ---
>   drivers/gpu/drm/drm_crtc.c | 63 ++++++++++++++++++++++++++++++++++++++++------
>   1 file changed, 56 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index 9626a0cc050a..9a3d17b70091 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -3440,6 +3440,24 @@ int drm_mode_addfb2(struct drm_device *dev,
>   	return 0;
>   }
>
> +struct drm_mode_rmfb_work {
> +	struct work_struct work;
> +	struct list_head fbs;
> +};
> +
> +static void drm_mode_rmfb_work_fn(struct work_struct *w)
> +{
> +	struct drm_mode_rmfb_work *arg = container_of(w, typeof(*arg), work);
> +
> +	while (!list_empty(&arg->fbs)) {
> +		struct drm_framebuffer *fb =
> +			list_first_entry(&arg->fbs, typeof(*fb), filp_head);
> +
> +		list_del_init(&fb->filp_head);
> +		drm_framebuffer_remove(fb);
> +	}
> +}
> +
>   /**
>    * drm_mode_rmfb - remove an FB from the configuration
>    * @dev: drm device for the ioctl
> @@ -3480,12 +3498,29 @@ int drm_mode_rmfb(struct drm_device *dev,
>   	list_del_init(&fb->filp_head);
>   	mutex_unlock(&file_priv->fbs_lock);
>
> -	/* we now own the reference that was stored in the fbs list */
> -	drm_framebuffer_unreference(fb);
> -
>   	/* drop the reference we picked up in framebuffer lookup */
>   	drm_framebuffer_unreference(fb);
>
> +	/*
> +	 * we now own the reference that was stored in the fbs list
> +	 *
> +	 * drm_framebuffer_remove may fail with -EINTR on pending signals,
> +	 * so run this in a separate stack as there's no way to correctly
> +	 * handle this after the fb is already removed from the lookup table.
> +	 */
> +	if (drm_framebuffer_read_refcount(fb) > 1) {
> +		struct drm_mode_rmfb_work arg;
> +
> +		INIT_WORK_ONSTACK(&arg.work, drm_mode_rmfb_work_fn);
> +		INIT_LIST_HEAD(&arg.fbs);
> +		list_add_tail(&fb->filp_head, &arg.fbs);
> +
> +		schedule_work(&arg.work);
> +		flush_work(&arg.work);
> +		destroy_work_on_stack(&arg.work);
> +	} else
> +		drm_framebuffer_unreference(fb);
> +
>   	return 0;
>
>   fail_unref:
> @@ -3635,7 +3670,6 @@ out_err1:
>   	return ret;
>   }
>
> -
>   /**
>    * drm_fb_release - remove and free the FBs on this file
>    * @priv: drm file for the ioctl
> @@ -3650,6 +3684,9 @@ out_err1:
>   void drm_fb_release(struct drm_file *priv)
>   {
>   	struct drm_framebuffer *fb, *tfb;
> +	struct drm_mode_rmfb_work arg;
> +
> +	INIT_LIST_HEAD(&arg.fbs);
>
>   	/*
>   	 * When the file gets released that means no one else can access the fb
> @@ -3662,10 +3699,22 @@ void drm_fb_release(struct drm_file *priv)
>   	 * at it any more.
>   	 */
>   	list_for_each_entry_safe(fb, tfb, &priv->fbs, filp_head) {
> -		list_del_init(&fb->filp_head);
> +		if (drm_framebuffer_read_refcount(fb) > 1) {
> +			list_move_tail(&fb->filp_head, &arg.fbs);
> +		} else {
> +			list_del_init(&fb->filp_head);
>
> -		/* This drops the fpriv->fbs reference. */
> -		drm_framebuffer_unreference(fb);
> +			/* This drops the fpriv->fbs reference. */
> +			drm_framebuffer_unreference(fb);
> +		}
> +	}
> +
> +	if (!list_empty(&arg.fbs)) {
> +		INIT_WORK_ONSTACK(&arg.work, drm_mode_rmfb_work_fn);
> +
> +		schedule_work(&arg.work);
> +		flush_work(&arg.work);
> +		destroy_work_on_stack(&arg.work);
>   	}
>   }
>
>
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH i-g-t] tests/kms: Add test for testing rmfb framebuffer removal handling.

[Tvrtko Ursulin]

Hi,

On 04/05/16 13:10, Maarten Lankhorst wrote:
> Add some tests to BAT to ensure rmfb/lastclose handling doesn't break again.
>
> The test will set framebuffers on each crtc, and then try rmfb or close.
> Afterwards it rechecks to make sure the framebuffers are removed.
>
> Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
> ---
> diff --git a/tests/Makefile.sources b/tests/Makefile.sources
> index b73f48d95568..92c84d697ded 100644
> --- a/tests/Makefile.sources
> +++ b/tests/Makefile.sources
> @@ -97,6 +97,7 @@ TESTS_progs_M = \
>   	kms_plane \
>   	kms_psr_sink_crc \
>   	kms_render \
> +	kms_rmfb_basic \
>   	kms_rotation_crc \
>   	kms_setmode \
>   	kms_universal_plane \
> diff --git a/tests/kms_rmfb_basic.c b/tests/kms_rmfb_basic.c
> new file mode 100644
> index 000000000000..a3fde9f43788
> --- /dev/null
> +++ b/tests/kms_rmfb_basic.c
> @@ -0,0 +1,180 @@
> +/*
> + * Copyright © 2016 Intel Corporation
> + *
> + * Permission is hereby granted, free of charge, to any person obtaining a
> + * copy of this software and associated documentation files (the "Software"),
> + * to deal in the Software without restriction, including without limitation
> + * the rights to use, copy, modify, merge, publish, distribute, sublicense,
> + * and/or sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following conditions:
> + *
> + * The above copyright notice and this permission notice (including the next
> + * paragraph) shall be included in all copies or substantial portions of the
> + * Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
> + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
> + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
> + * IN THE SOFTWARE.
> + */
> +
> +#include "igt.h"
> +#include "drmtest.h"
> +#include <errno.h>
> +#include <stdbool.h>
> +#include <stdio.h>
> +#include <string.h>
> +#include <time.h>
> +
> +#ifndef DRM_CAP_CURSOR_WIDTH
> +#define DRM_CAP_CURSOR_WIDTH 0x8
> +#endif
> +#ifndef DRM_CAP_CURSOR_HEIGHT
> +#define DRM_CAP_CURSOR_HEIGHT 0x9
> +#endif
> +
> +struct rmfb_data {
> +	int drm_fd;
> +	igt_display_t display;
> +};
> +
> +/*
> + * 1. Set primary plane to a known fb.
> + * 2. Make sure getcrtc returns the correct fb id.
> + * 3. Call rmfb on the fb.
> + * 4. Make sure getcrtc returns 0 fb id.
> + *
> + * RMFB is supposed to free the framebuffers from any and all planes,
> + * so test this and make sure it works.
> + */
> +static bool
> +test_rmfb(struct rmfb_data *data, igt_output_t *output, enum pipe pipe, bool reopen)
> +{
> +	struct igt_fb fb, argb_fb;
> +	drmModeModeInfo *mode;
> +	igt_plane_t *plane;
> +	drmModeCrtc *crtc;
> +	uint64_t cursor_width, cursor_height;
> +
> +	igt_output_set_pipe(output, pipe);
> +	igt_display_commit(&data->display);
> +
> +	if (!output->valid) {
> +		igt_output_set_pipe(output, PIPE_ANY);
> +		return false;
> +	}
> +
> +	mode = igt_output_get_mode(output);
> +
> +	igt_create_fb(data->drm_fd, mode->hdisplay, mode->vdisplay,
> +		      DRM_FORMAT_XRGB8888, LOCAL_DRM_FORMAT_MOD_NONE, &fb);
> +
> +	igt_create_fb(data->drm_fd, mode->hdisplay, mode->vdisplay,
> +		      DRM_FORMAT_ARGB8888, LOCAL_DRM_FORMAT_MOD_NONE, &argb_fb);
> +
> +	do_or_die(drmGetCap(data->drm_fd, DRM_CAP_CURSOR_WIDTH, &cursor_width));
> +	if (cursor_width > mode->hdisplay)
> +		cursor_width = mode->hdisplay;
> +
> +	do_or_die(drmGetCap(data->drm_fd, DRM_CAP_CURSOR_HEIGHT, &cursor_height));
> +	if (cursor_height > mode->vdisplay)
> +		cursor_height = mode->vdisplay;
> +
> +	/*
> +	 * Make sure these buffers are suited for display use
> +	 * because most of the modeset operations must be fast
> +	 * later on.
> +	 */
> +	for_each_plane_on_pipe(&data->display, pipe, plane) {
> +		if (plane->is_cursor) {
> +			igt_plane_set_fb(plane, &argb_fb);
> +			igt_fb_set_size(&argb_fb, plane, cursor_width, cursor_height);
> +			igt_plane_set_size(plane, cursor_width, cursor_height);
> +		} else {
> +			igt_plane_set_fb(plane, &fb);
> +		}
> +	}
> +
> +	igt_display_commit2(&data->display, data->display.is_atomic ? COMMIT_ATOMIC : COMMIT_UNIVERSAL);
> +
> +	crtc = drmModeGetCrtc(data->drm_fd, output->config.crtc->crtc_id);
> +
> +	igt_assert_eq(crtc->buffer_id, fb.fb_id);
> +
> +	drmModeFreeCrtc(crtc);
> +
> +	if (reopen) {
> +		close(data->drm_fd);
> +
> +		data->drm_fd = drm_open_driver_master(DRIVER_ANY);
> +		drmSetClientCap(data->drm_fd, DRM_CLIENT_CAP_UNIVERSAL_PLANES, 1);
> +		drmSetClientCap(data->drm_fd, DRM_CLIENT_CAP_ATOMIC, 1);
> +	} else {
> +		igt_remove_fb(data->drm_fd, &fb);
> +		igt_remove_fb(data->drm_fd, &argb_fb);
> +	}
> +
> +	crtc = drmModeGetCrtc(data->drm_fd, output->config.crtc->crtc_id);
> +
> +	igt_assert_eq(crtc->buffer_id, 0);
> +
> +	drmModeFreeCrtc(crtc);
> +
> +	for_each_plane_on_pipe(&data->display, pipe, plane) {
> +		drmModePlanePtr planeres = drmModeGetPlane(data->drm_fd, plane->drm_plane->plane_id);
> +
> +		igt_assert_eq(planeres->fb_id, 0);
> +
> +		drmModeFreePlane(planeres);
> +	}
> +
> +	igt_output_set_pipe(output, PIPE_ANY);
> +	igt_display_commit2(&data->display, data->display.is_atomic ? COMMIT_ATOMIC : COMMIT_UNIVERSAL);
> +
> +	return true;
> +}
> +
> +static void
> +run_rmfb_test(struct rmfb_data *data, bool reopen)
> +{
> +	igt_output_t *output;
> +	int valid_tests = 0;
> +	enum pipe pipe;
> +
> +	for_each_connected_output(&data->display, output) {
> +		for_each_pipe(&data->display, pipe) {
> +			if (test_rmfb(data, output, pipe, reopen))
> +				valid_tests++;

This test seems like a good candidate to do only one pipe per crtc, 
since it would be BAT.

Alternatively, have basic-rmfb-ioctl and rmfb-ioctl subtests (and close) 
where the former does one (first valid?), and the other do all combos. 
This is something I proposed for other modesetting tests recently as well.

Regards,

Tvrtko

> +		}
> +	}
> +
> +	igt_require_f(valid_tests, "no valid crtc/connector combinations found\n");
> +}
> +
> +igt_main
> +{
> +	struct rmfb_data data = {};
> +
> +	igt_skip_on_simulation();
> +
> +	igt_fixture {
> +		data.drm_fd = drm_open_driver_master(DRIVER_ANY);
> +
> +		kmstest_set_vt_graphics_mode();
> +
> +		igt_display_init(&data.display, data.drm_fd);
> +	}
> +
> +	igt_subtest_f("rmfb-ioctl")
> +		run_rmfb_test(&data, false);
> +
> +	igt_subtest_f("close-fd")
> +		run_rmfb_test(&data, true);
> +
> +	igt_fixture {
> +		igt_display_fini(&data.display);
> +	}
> +}
>
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [PATCH i-g-t] tests/kms: Add test for testing rmfb framebuffer removal handling.

[Daniel Vetter]

On Thu, May 05, 2016 at 10:11:27AM +0100, Tvrtko Ursulin wrote:
> 
> Hi,
> 
> On 04/05/16 13:10, Maarten Lankhorst wrote:
> >Add some tests to BAT to ensure rmfb/lastclose handling doesn't break again.
> >
> >The test will set framebuffers on each crtc, and then try rmfb or close.
> >Afterwards it rechecks to make sure the framebuffers are removed.
> >
> >Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
> >---
> >diff --git a/tests/Makefile.sources b/tests/Makefile.sources
> >index b73f48d95568..92c84d697ded 100644
> >--- a/tests/Makefile.sources
> >+++ b/tests/Makefile.sources
> >@@ -97,6 +97,7 @@ TESTS_progs_M = \
> >  	kms_plane \
> >  	kms_psr_sink_crc \
> >  	kms_render \
> >+	kms_rmfb_basic \
> >  	kms_rotation_crc \
> >  	kms_setmode \
> >  	kms_universal_plane \
> >diff --git a/tests/kms_rmfb_basic.c b/tests/kms_rmfb_basic.c
> >new file mode 100644
> >index 000000000000..a3fde9f43788
> >--- /dev/null
> >+++ b/tests/kms_rmfb_basic.c
> >@@ -0,0 +1,180 @@
> >+/*
> >+ * Copyright © 2016 Intel Corporation
> >+ *
> >+ * Permission is hereby granted, free of charge, to any person obtaining a
> >+ * copy of this software and associated documentation files (the "Software"),
> >+ * to deal in the Software without restriction, including without limitation
> >+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
> >+ * and/or sell copies of the Software, and to permit persons to whom the
> >+ * Software is furnished to do so, subject to the following conditions:
> >+ *
> >+ * The above copyright notice and this permission notice (including the next
> >+ * paragraph) shall be included in all copies or substantial portions of the
> >+ * Software.
> >+ *
> >+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> >+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> >+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
> >+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
> >+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> >+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
> >+ * IN THE SOFTWARE.
> >+ */
> >+
> >+#include "igt.h"
> >+#include "drmtest.h"
> >+#include <errno.h>
> >+#include <stdbool.h>
> >+#include <stdio.h>
> >+#include <string.h>
> >+#include <time.h>
> >+
> >+#ifndef DRM_CAP_CURSOR_WIDTH
> >+#define DRM_CAP_CURSOR_WIDTH 0x8
> >+#endif
> >+#ifndef DRM_CAP_CURSOR_HEIGHT
> >+#define DRM_CAP_CURSOR_HEIGHT 0x9
> >+#endif
> >+
> >+struct rmfb_data {
> >+	int drm_fd;
> >+	igt_display_t display;
> >+};
> >+
> >+/*
> >+ * 1. Set primary plane to a known fb.
> >+ * 2. Make sure getcrtc returns the correct fb id.
> >+ * 3. Call rmfb on the fb.
> >+ * 4. Make sure getcrtc returns 0 fb id.
> >+ *
> >+ * RMFB is supposed to free the framebuffers from any and all planes,
> >+ * so test this and make sure it works.
> >+ */
> >+static bool
> >+test_rmfb(struct rmfb_data *data, igt_output_t *output, enum pipe pipe, bool reopen)
> >+{
> >+	struct igt_fb fb, argb_fb;
> >+	drmModeModeInfo *mode;
> >+	igt_plane_t *plane;
> >+	drmModeCrtc *crtc;
> >+	uint64_t cursor_width, cursor_height;
> >+
> >+	igt_output_set_pipe(output, pipe);
> >+	igt_display_commit(&data->display);
> >+
> >+	if (!output->valid) {
> >+		igt_output_set_pipe(output, PIPE_ANY);
> >+		return false;
> >+	}
> >+
> >+	mode = igt_output_get_mode(output);
> >+
> >+	igt_create_fb(data->drm_fd, mode->hdisplay, mode->vdisplay,
> >+		      DRM_FORMAT_XRGB8888, LOCAL_DRM_FORMAT_MOD_NONE, &fb);
> >+
> >+	igt_create_fb(data->drm_fd, mode->hdisplay, mode->vdisplay,
> >+		      DRM_FORMAT_ARGB8888, LOCAL_DRM_FORMAT_MOD_NONE, &argb_fb);
> >+
> >+	do_or_die(drmGetCap(data->drm_fd, DRM_CAP_CURSOR_WIDTH, &cursor_width));
> >+	if (cursor_width > mode->hdisplay)
> >+		cursor_width = mode->hdisplay;
> >+
> >+	do_or_die(drmGetCap(data->drm_fd, DRM_CAP_CURSOR_HEIGHT, &cursor_height));
> >+	if (cursor_height > mode->vdisplay)
> >+		cursor_height = mode->vdisplay;
> >+
> >+	/*
> >+	 * Make sure these buffers are suited for display use
> >+	 * because most of the modeset operations must be fast
> >+	 * later on.
> >+	 */
> >+	for_each_plane_on_pipe(&data->display, pipe, plane) {
> >+		if (plane->is_cursor) {
> >+			igt_plane_set_fb(plane, &argb_fb);
> >+			igt_fb_set_size(&argb_fb, plane, cursor_width, cursor_height);
> >+			igt_plane_set_size(plane, cursor_width, cursor_height);
> >+		} else {
> >+			igt_plane_set_fb(plane, &fb);
> >+		}
> >+	}
> >+
> >+	igt_display_commit2(&data->display, data->display.is_atomic ? COMMIT_ATOMIC : COMMIT_UNIVERSAL);
> >+
> >+	crtc = drmModeGetCrtc(data->drm_fd, output->config.crtc->crtc_id);
> >+
> >+	igt_assert_eq(crtc->buffer_id, fb.fb_id);
> >+
> >+	drmModeFreeCrtc(crtc);
> >+
> >+	if (reopen) {
> >+		close(data->drm_fd);
> >+
> >+		data->drm_fd = drm_open_driver_master(DRIVER_ANY);
> >+		drmSetClientCap(data->drm_fd, DRM_CLIENT_CAP_UNIVERSAL_PLANES, 1);
> >+		drmSetClientCap(data->drm_fd, DRM_CLIENT_CAP_ATOMIC, 1);
> >+	} else {
> >+		igt_remove_fb(data->drm_fd, &fb);
> >+		igt_remove_fb(data->drm_fd, &argb_fb);
> >+	}
> >+
> >+	crtc = drmModeGetCrtc(data->drm_fd, output->config.crtc->crtc_id);
> >+
> >+	igt_assert_eq(crtc->buffer_id, 0);
> >+
> >+	drmModeFreeCrtc(crtc);
> >+
> >+	for_each_plane_on_pipe(&data->display, pipe, plane) {
> >+		drmModePlanePtr planeres = drmModeGetPlane(data->drm_fd, plane->drm_plane->plane_id);
> >+
> >+		igt_assert_eq(planeres->fb_id, 0);
> >+
> >+		drmModeFreePlane(planeres);
> >+	}
> >+
> >+	igt_output_set_pipe(output, PIPE_ANY);
> >+	igt_display_commit2(&data->display, data->display.is_atomic ? COMMIT_ATOMIC : COMMIT_UNIVERSAL);
> >+
> >+	return true;
> >+}
> >+
> >+static void
> >+run_rmfb_test(struct rmfb_data *data, bool reopen)
> >+{
> >+	igt_output_t *output;
> >+	int valid_tests = 0;
> >+	enum pipe pipe;
> >+
> >+	for_each_connected_output(&data->display, output) {
> >+		for_each_pipe(&data->display, pipe) {
> >+			if (test_rmfb(data, output, pipe, reopen))
> >+				valid_tests++;
> 
> This test seems like a good candidate to do only one pipe per crtc, since it
> would be BAT.
> 
> Alternatively, have basic-rmfb-ioctl and rmfb-ioctl subtests (and close)
> where the former does one (first valid?), and the other do all combos. This
> is something I proposed for other modesetting tests recently as well.

Tbh not sure this should even be BAT. It's a corner-case in handling leaks
(or not), that doesn't feel like BAT material. Especially given that it
needs at least 1 modeset or two, so won't be fast.

We need to stop cramming everything into BAT simply because we don't have
any other CI. Because last time we've tried to run everything it also
didn't work ...

Also, BAT is over time, that pretty much means an embargo on new BAT
tests.

Thanks, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [PATCH] drm/core: Do not preserve framebuffer on rmfb, v4.

[Daniel Vetter]

On Thu, May 05, 2016 at 10:07:57AM +0100, Tvrtko Ursulin wrote:
> 
> On 04/05/16 13:38, Maarten Lankhorst wrote:
> >It turns out that preserving framebuffers after the rmfb call breaks
> >vmwgfx userspace. This was originally introduced because it was thought
> >nobody relied on the behavior, but unfortunately it seems there are
> >exceptions.
> >
> >drm_framebuffer_remove may fail with -EINTR now, so a straight revert
> >is impossible. There is no way to remove the framebuffer from the lists
> >and active planes without introducing a race because of the different
> >locking requirements. Instead call drm_framebuffer_remove from a
> >workqueue, which is unaffected by signals.
> >
> >Changes since v1:
> >- Add comment.
> >Changes since v2:
> >- Add fastpath for refcount = 1. (danvet)
> >Changes since v3:
> >- Rebased.
> >- Restore lastclose framebuffer removal too.
> >
> >Cc: stable@vger.kernel.org #v4.4+
> >Fixes: 13803132818c ("drm/core: Preserve the framebuffer after removing it.")
> >Testcase: kms_rmfb_basic
> >References: https://lists.freedesktop.org/archives/dri-devel/2016-March/102876.html
> >Cc: Thomas Hellstrom <thellstrom@vmware.com>
> >Cc: David Herrmann <dh.herrmann@gmail.com>
> >Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
> >Tested-by: Thomas Hellstrom <thellstrom@vmware.com> #v3
> 
> Can't be 100% since apparently eDP regressed a lot recently for me, but
> seems to be effective in getting rid of stale planes in my test cases.
> 
> Tested-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>

Applied to drm-misc, thanks.
-Daniel

> 
> Regards,
> 
> Tvrtko
> 
> >---
> >  drivers/gpu/drm/drm_crtc.c | 63 ++++++++++++++++++++++++++++++++++++++++------
> >  1 file changed, 56 insertions(+), 7 deletions(-)
> >
> >diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> >index 9626a0cc050a..9a3d17b70091 100644
> >--- a/drivers/gpu/drm/drm_crtc.c
> >+++ b/drivers/gpu/drm/drm_crtc.c
> >@@ -3440,6 +3440,24 @@ int drm_mode_addfb2(struct drm_device *dev,
> >  	return 0;
> >  }
> >
> >+struct drm_mode_rmfb_work {
> >+	struct work_struct work;
> >+	struct list_head fbs;
> >+};
> >+
> >+static void drm_mode_rmfb_work_fn(struct work_struct *w)
> >+{
> >+	struct drm_mode_rmfb_work *arg = container_of(w, typeof(*arg), work);
> >+
> >+	while (!list_empty(&arg->fbs)) {
> >+		struct drm_framebuffer *fb =
> >+			list_first_entry(&arg->fbs, typeof(*fb), filp_head);
> >+
> >+		list_del_init(&fb->filp_head);
> >+		drm_framebuffer_remove(fb);
> >+	}
> >+}
> >+
> >  /**
> >   * drm_mode_rmfb - remove an FB from the configuration
> >   * @dev: drm device for the ioctl
> >@@ -3480,12 +3498,29 @@ int drm_mode_rmfb(struct drm_device *dev,
> >  	list_del_init(&fb->filp_head);
> >  	mutex_unlock(&file_priv->fbs_lock);
> >
> >-	/* we now own the reference that was stored in the fbs list */
> >-	drm_framebuffer_unreference(fb);
> >-
> >  	/* drop the reference we picked up in framebuffer lookup */
> >  	drm_framebuffer_unreference(fb);
> >
> >+	/*
> >+	 * we now own the reference that was stored in the fbs list
> >+	 *
> >+	 * drm_framebuffer_remove may fail with -EINTR on pending signals,
> >+	 * so run this in a separate stack as there's no way to correctly
> >+	 * handle this after the fb is already removed from the lookup table.
> >+	 */
> >+	if (drm_framebuffer_read_refcount(fb) > 1) {
> >+		struct drm_mode_rmfb_work arg;
> >+
> >+		INIT_WORK_ONSTACK(&arg.work, drm_mode_rmfb_work_fn);
> >+		INIT_LIST_HEAD(&arg.fbs);
> >+		list_add_tail(&fb->filp_head, &arg.fbs);
> >+
> >+		schedule_work(&arg.work);
> >+		flush_work(&arg.work);
> >+		destroy_work_on_stack(&arg.work);
> >+	} else
> >+		drm_framebuffer_unreference(fb);
> >+
> >  	return 0;
> >
> >  fail_unref:
> >@@ -3635,7 +3670,6 @@ out_err1:
> >  	return ret;
> >  }
> >
> >-
> >  /**
> >   * drm_fb_release - remove and free the FBs on this file
> >   * @priv: drm file for the ioctl
> >@@ -3650,6 +3684,9 @@ out_err1:
> >  void drm_fb_release(struct drm_file *priv)
> >  {
> >  	struct drm_framebuffer *fb, *tfb;
> >+	struct drm_mode_rmfb_work arg;
> >+
> >+	INIT_LIST_HEAD(&arg.fbs);
> >
> >  	/*
> >  	 * When the file gets released that means no one else can access the fb
> >@@ -3662,10 +3699,22 @@ void drm_fb_release(struct drm_file *priv)
> >  	 * at it any more.
> >  	 */
> >  	list_for_each_entry_safe(fb, tfb, &priv->fbs, filp_head) {
> >-		list_del_init(&fb->filp_head);
> >+		if (drm_framebuffer_read_refcount(fb) > 1) {
> >+			list_move_tail(&fb->filp_head, &arg.fbs);
> >+		} else {
> >+			list_del_init(&fb->filp_head);
> >
> >-		/* This drops the fpriv->fbs reference. */
> >-		drm_framebuffer_unreference(fb);
> >+			/* This drops the fpriv->fbs reference. */
> >+			drm_framebuffer_unreference(fb);
> >+		}
> >+	}
> >+
> >+	if (!list_empty(&arg.fbs)) {
> >+		INIT_WORK_ONSTACK(&arg.work, drm_mode_rmfb_work_fn);
> >+
> >+		schedule_work(&arg.work);
> >+		flush_work(&arg.work);
> >+		destroy_work_on_stack(&arg.work);
> >  	}
> >  }
> >
> >
> _______________________________________________
> 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
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel