* [PATCH] drm/i915: Do not leak VMAs (and PPGTT VMs) of imported flinked objects
@ 2015-04-20 12:14 Tvrtko Ursulin
2015-04-20 12:36 ` Chris Wilson
2015-04-20 16:57 ` shuang.he
0 siblings, 2 replies; 7+ messages in thread
From: Tvrtko Ursulin @ 2015-04-20 12:14 UTC (permalink / raw)
To: Intel-gfx
From: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
If a client instantiates a VMA against an imported object (flink) this VMA
will not get unbound when the object is closed.
This happens because the exporter holds a reference count on the object and
will also keep a reference to the PPGTT VM.
In real life this happens with xorg-driver-intel and fbcon takeover. Latter
is copied from via the flink name and when Xorg process exists one VMA
remains dangling with a now unreachable VM.
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Testcase: igt/gem_ppgtt/flink-vs-ctx-vm-leak
---
drivers/gpu/drm/i915/i915_drv.c | 1 +
drivers/gpu/drm/i915/i915_drv.h | 2 ++
drivers/gpu/drm/i915/i915_gem.c | 63 ++++++++++++++++++++++++++++++++---------
3 files changed, 53 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index f9754c3..16a0b34 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1630,6 +1630,7 @@ static struct drm_driver driver = {
.debugfs_init = i915_debugfs_init,
.debugfs_cleanup = i915_debugfs_cleanup,
#endif
+ .gem_close_object = i915_gem_close_object,
.gem_free_object = i915_gem_free_object,
.gem_vm_ops = &i915_gem_vm_ops,
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 6a2528c..e82790b 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2635,6 +2635,8 @@ struct drm_i915_gem_object *i915_gem_alloc_object(struct drm_device *dev,
size_t size);
void i915_init_vm(struct drm_i915_private *dev_priv,
struct i915_address_space *vm);
+void i915_gem_close_object(struct drm_gem_object *gem_obj,
+ struct drm_file *file);
void i915_gem_free_object(struct drm_gem_object *obj);
void i915_gem_vma_destroy(struct i915_vma *vma);
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index f7b8766..a720154 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -4523,6 +4523,55 @@ static bool discard_backing_storage(struct drm_i915_gem_object *obj)
return atomic_long_read(&obj->base.filp->f_count) == 1;
}
+static void i915_gem_unbind_vma(struct drm_i915_private *dev_priv,
+ struct i915_vma *vma)
+{
+ if (WARN_ON(i915_vma_unbind(vma) == -ERESTARTSYS)) {
+ bool was_interruptible;
+
+ was_interruptible = dev_priv->mm.interruptible;
+ dev_priv->mm.interruptible = false;
+
+ WARN_ON(i915_vma_unbind(vma));
+
+ dev_priv->mm.interruptible = was_interruptible;
+ }
+}
+
+void i915_gem_close_object(struct drm_gem_object *gem_obj,
+ struct drm_file *file)
+{
+ struct drm_i915_gem_object *obj = to_intel_bo(gem_obj);
+ struct drm_device *dev = obj->base.dev;
+ struct drm_i915_file_private *file_priv = file->driver_priv;
+ struct i915_vma *vma, *next;
+ struct i915_hw_ppgtt *ppgtt;
+
+ mutex_lock(&dev->struct_mutex);
+
+ /*
+ * Release all VMAs associated with this client's PPGTT.
+ *
+ * This is to avoid potentially unreachable VMAs since contexts can have
+ * shorter lifetime than objects. Meaning if a client has a reference to
+ * an object (flink) and an instantiated VMA, when it exists neither VMA
+ * will be unbound (since object free won't run), nor the PPGTT VM
+ * freed (since VMA holds a reference to it).
+ */
+ list_for_each_entry_safe(vma, next, &obj->vma_list, vma_link) {
+ if (i915_is_ggtt(vma->vm))
+ continue;
+
+ ppgtt = (struct i915_hw_ppgtt *)vma->vm;
+ if (ppgtt->file_priv != file_priv)
+ continue;
+
+ i915_gem_unbind_vma(dev->dev_private, vma);
+ }
+
+ mutex_unlock(&dev->struct_mutex);
+}
+
void i915_gem_free_object(struct drm_gem_object *gem_obj)
{
struct drm_i915_gem_object *obj = to_intel_bo(gem_obj);
@@ -4535,20 +4584,8 @@ void i915_gem_free_object(struct drm_gem_object *gem_obj)
trace_i915_gem_object_destroy(obj);
list_for_each_entry_safe(vma, next, &obj->vma_list, vma_link) {
- int ret;
-
vma->pin_count = 0;
- ret = i915_vma_unbind(vma);
- if (WARN_ON(ret == -ERESTARTSYS)) {
- bool was_interruptible;
-
- was_interruptible = dev_priv->mm.interruptible;
- dev_priv->mm.interruptible = false;
-
- WARN_ON(i915_vma_unbind(vma));
-
- dev_priv->mm.interruptible = was_interruptible;
- }
+ i915_gem_unbind_vma(dev_priv, vma);
}
/* Stolen objects don't hold a ref, but do hold pin count. Fix that up
--
2.3.5
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply related [flat|nested] 7+ messages in thread
* Re: [PATCH] drm/i915: Do not leak VMAs (and PPGTT VMs) of imported flinked objects
2015-04-20 12:14 [PATCH] drm/i915: Do not leak VMAs (and PPGTT VMs) of imported flinked objects Tvrtko Ursulin
@ 2015-04-20 12:36 ` Chris Wilson
2015-04-20 12:53 ` Tvrtko Ursulin
2015-04-20 16:57 ` shuang.he
1 sibling, 1 reply; 7+ messages in thread
From: Chris Wilson @ 2015-04-20 12:36 UTC (permalink / raw)
To: Tvrtko Ursulin; +Cc: Intel-gfx
On Mon, Apr 20, 2015 at 01:14:34PM +0100, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
>
> If a client instantiates a VMA against an imported object (flink) this VMA
> will not get unbound when the object is closed.
>
> This happens because the exporter holds a reference count on the object and
> will also keep a reference to the PPGTT VM.
>
> In real life this happens with xorg-driver-intel and fbcon takeover. Latter
> is copied from via the flink name and when Xorg process exists one VMA
> remains dangling with a now unreachable VM.
>
> Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
> Cc: Chris Wilson <chris@chris-wilson.co.uk>
> Testcase: igt/gem_ppgtt/flink-vs-ctx-vm-leak
> ---
> drivers/gpu/drm/i915/i915_drv.c | 1 +
> drivers/gpu/drm/i915/i915_drv.h | 2 ++
> drivers/gpu/drm/i915/i915_gem.c | 63 ++++++++++++++++++++++++++++++++---------
> 3 files changed, 53 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index f9754c3..16a0b34 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -1630,6 +1630,7 @@ static struct drm_driver driver = {
> .debugfs_init = i915_debugfs_init,
> .debugfs_cleanup = i915_debugfs_cleanup,
> #endif
> + .gem_close_object = i915_gem_close_object,
> .gem_free_object = i915_gem_free_object,
> .gem_vm_ops = &i915_gem_vm_ops,
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 6a2528c..e82790b 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -2635,6 +2635,8 @@ struct drm_i915_gem_object *i915_gem_alloc_object(struct drm_device *dev,
> size_t size);
> void i915_init_vm(struct drm_i915_private *dev_priv,
> struct i915_address_space *vm);
> +void i915_gem_close_object(struct drm_gem_object *gem_obj,
> + struct drm_file *file);
> void i915_gem_free_object(struct drm_gem_object *obj);
> void i915_gem_vma_destroy(struct i915_vma *vma);
>
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index f7b8766..a720154 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -4523,6 +4523,55 @@ static bool discard_backing_storage(struct drm_i915_gem_object *obj)
> return atomic_long_read(&obj->base.filp->f_count) == 1;
> }
>
> +static void i915_gem_unbind_vma(struct drm_i915_private *dev_priv,
> + struct i915_vma *vma)
> +{
> + if (WARN_ON(i915_vma_unbind(vma) == -ERESTARTSYS)) {
> + bool was_interruptible;
> +
> + was_interruptible = dev_priv->mm.interruptible;
> + dev_priv->mm.interruptible = false;
> +
> + WARN_ON(i915_vma_unbind(vma));
> +
> + dev_priv->mm.interruptible = was_interruptible;
> + }
> +}
> +
> +void i915_gem_close_object(struct drm_gem_object *gem_obj,
> + struct drm_file *file)
> +{
> + struct drm_i915_gem_object *obj = to_intel_bo(gem_obj);
> + struct drm_device *dev = obj->base.dev;
> + struct drm_i915_file_private *file_priv = file->driver_priv;
> + struct i915_vma *vma, *next;
> + struct i915_hw_ppgtt *ppgtt;
> +
> + mutex_lock(&dev->struct_mutex);
> +
> + /*
> + * Release all VMAs associated with this client's PPGTT.
> + *
> + * This is to avoid potentially unreachable VMAs since contexts can have
> + * shorter lifetime than objects. Meaning if a client has a reference to
> + * an object (flink) and an instantiated VMA, when it exists neither VMA
> + * will be unbound (since object free won't run), nor the PPGTT VM
> + * freed (since VMA holds a reference to it).
> + */
> + list_for_each_entry_safe(vma, next, &obj->vma_list, vma_link) {
> + if (i915_is_ggtt(vma->vm))
> + continue;
> +
> + ppgtt = (struct i915_hw_ppgtt *)vma->vm;
> + if (ppgtt->file_priv != file_priv)
> + continue;
> +
> + i915_gem_unbind_vma(dev->dev_private, vma);
No we can't do this, as it makes close sync and so can have disasterous
effects on performance (though mitigated chiefly by userspace
agressively caching bo) and also the unbind is very likely to fail,
though admittedly the fbcon copy should be before X starts (ab)using
signals - hence nasty WARN_ON.
Plus also walking this linear list is quite painful in certain abusive
tests. My preference for fixing this bug would be via vma active
references and auto-unbinding on retirement after a close.
Expect some fun patches in your inbox Tvrtko :-p
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] drm/i915: Do not leak VMAs (and PPGTT VMs) of imported flinked objects
2015-04-20 12:36 ` Chris Wilson
@ 2015-04-20 12:53 ` Tvrtko Ursulin
2015-04-20 12:58 ` Chris Wilson
0 siblings, 1 reply; 7+ messages in thread
From: Tvrtko Ursulin @ 2015-04-20 12:53 UTC (permalink / raw)
To: Chris Wilson, Intel-gfx, Tvrtko Ursulin
On 04/20/2015 01:36 PM, Chris Wilson wrote:
> On Mon, Apr 20, 2015 at 01:14:34PM +0100, Tvrtko Ursulin wrote:
>> From: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
>>
>> If a client instantiates a VMA against an imported object (flink) this VMA
>> will not get unbound when the object is closed.
>>
>> This happens because the exporter holds a reference count on the object and
>> will also keep a reference to the PPGTT VM.
>>
>> In real life this happens with xorg-driver-intel and fbcon takeover. Latter
>> is copied from via the flink name and when Xorg process exists one VMA
>> remains dangling with a now unreachable VM.
>>
>> Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
>> Cc: Chris Wilson <chris@chris-wilson.co.uk>
>> Testcase: igt/gem_ppgtt/flink-vs-ctx-vm-leak
>> ---
>> drivers/gpu/drm/i915/i915_drv.c | 1 +
>> drivers/gpu/drm/i915/i915_drv.h | 2 ++
>> drivers/gpu/drm/i915/i915_gem.c | 63 ++++++++++++++++++++++++++++++++---------
>> 3 files changed, 53 insertions(+), 13 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
>> index f9754c3..16a0b34 100644
>> --- a/drivers/gpu/drm/i915/i915_drv.c
>> +++ b/drivers/gpu/drm/i915/i915_drv.c
>> @@ -1630,6 +1630,7 @@ static struct drm_driver driver = {
>> .debugfs_init = i915_debugfs_init,
>> .debugfs_cleanup = i915_debugfs_cleanup,
>> #endif
>> + .gem_close_object = i915_gem_close_object,
>> .gem_free_object = i915_gem_free_object,
>> .gem_vm_ops = &i915_gem_vm_ops,
>>
>> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
>> index 6a2528c..e82790b 100644
>> --- a/drivers/gpu/drm/i915/i915_drv.h
>> +++ b/drivers/gpu/drm/i915/i915_drv.h
>> @@ -2635,6 +2635,8 @@ struct drm_i915_gem_object *i915_gem_alloc_object(struct drm_device *dev,
>> size_t size);
>> void i915_init_vm(struct drm_i915_private *dev_priv,
>> struct i915_address_space *vm);
>> +void i915_gem_close_object(struct drm_gem_object *gem_obj,
>> + struct drm_file *file);
>> void i915_gem_free_object(struct drm_gem_object *obj);
>> void i915_gem_vma_destroy(struct i915_vma *vma);
>>
>> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
>> index f7b8766..a720154 100644
>> --- a/drivers/gpu/drm/i915/i915_gem.c
>> +++ b/drivers/gpu/drm/i915/i915_gem.c
>> @@ -4523,6 +4523,55 @@ static bool discard_backing_storage(struct drm_i915_gem_object *obj)
>> return atomic_long_read(&obj->base.filp->f_count) == 1;
>> }
>>
>> +static void i915_gem_unbind_vma(struct drm_i915_private *dev_priv,
>> + struct i915_vma *vma)
>> +{
>> + if (WARN_ON(i915_vma_unbind(vma) == -ERESTARTSYS)) {
>> + bool was_interruptible;
>> +
>> + was_interruptible = dev_priv->mm.interruptible;
>> + dev_priv->mm.interruptible = false;
>> +
>> + WARN_ON(i915_vma_unbind(vma));
>> +
>> + dev_priv->mm.interruptible = was_interruptible;
>> + }
>> +}
>> +
>> +void i915_gem_close_object(struct drm_gem_object *gem_obj,
>> + struct drm_file *file)
>> +{
>> + struct drm_i915_gem_object *obj = to_intel_bo(gem_obj);
>> + struct drm_device *dev = obj->base.dev;
>> + struct drm_i915_file_private *file_priv = file->driver_priv;
>> + struct i915_vma *vma, *next;
>> + struct i915_hw_ppgtt *ppgtt;
>> +
>> + mutex_lock(&dev->struct_mutex);
>> +
>> + /*
>> + * Release all VMAs associated with this client's PPGTT.
>> + *
>> + * This is to avoid potentially unreachable VMAs since contexts can have
>> + * shorter lifetime than objects. Meaning if a client has a reference to
>> + * an object (flink) and an instantiated VMA, when it exists neither VMA
>> + * will be unbound (since object free won't run), nor the PPGTT VM
>> + * freed (since VMA holds a reference to it).
>> + */
>> + list_for_each_entry_safe(vma, next, &obj->vma_list, vma_link) {
>> + if (i915_is_ggtt(vma->vm))
>> + continue;
>> +
>> + ppgtt = (struct i915_hw_ppgtt *)vma->vm;
>> + if (ppgtt->file_priv != file_priv)
>> + continue;
>> +
>> + i915_gem_unbind_vma(dev->dev_private, vma);
>
> No we can't do this, as it makes close sync and so can have disasterous
> effects on performance (though mitigated chiefly by userspace
> agressively caching bo) and also the unbind is very likely to fail,
> though admittedly the fbcon copy should be before X starts (ab)using
> signals - hence nasty WARN_ON.
>
> Plus also walking this linear list is quite painful in certain abusive
> tests. My preference for fixing this bug would be via vma active
> references and auto-unbinding on retirement after a close.
Why this is any different today with GEM_CLOSE having pretty similar VMA
unbind loop? Is the typical (and interesting) case not that GEM_CLOSE
will trigger gem_object_close and gem_object_free at the same invocation?
> Expect some fun patches in your inbox Tvrtko :-p
Ok, just don't make them depend on everything. :)
Regards,
Tvrtko
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] drm/i915: Do not leak VMAs (and PPGTT VMs) of imported flinked objects
2015-04-20 12:53 ` Tvrtko Ursulin
@ 2015-04-20 12:58 ` Chris Wilson
2015-04-20 13:11 ` Tvrtko Ursulin
0 siblings, 1 reply; 7+ messages in thread
From: Chris Wilson @ 2015-04-20 12:58 UTC (permalink / raw)
To: Tvrtko Ursulin; +Cc: Intel-gfx
On Mon, Apr 20, 2015 at 01:53:03PM +0100, Tvrtko Ursulin wrote:
> >No we can't do this, as it makes close sync and so can have disasterous
> >effects on performance (though mitigated chiefly by userspace
> >agressively caching bo) and also the unbind is very likely to fail,
> >though admittedly the fbcon copy should be before X starts (ab)using
> >signals - hence nasty WARN_ON.
> >
> >Plus also walking this linear list is quite painful in certain abusive
> >tests. My preference for fixing this bug would be via vma active
> >references and auto-unbinding on retirement after a close.
>
> Why this is any different today with GEM_CLOSE having pretty similar
> VMA unbind loop? Is the typical (and interesting) case not that
> GEM_CLOSE will trigger gem_object_close and gem_object_free at the
> same invocation?
We have such a cleanup loop in free_object, but we have an active
reference to ensure that we only do so once the object is idle (and
unbinding won't cause to wait).
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] drm/i915: Do not leak VMAs (and PPGTT VMs) of imported flinked objects
2015-04-20 12:58 ` Chris Wilson
@ 2015-04-20 13:11 ` Tvrtko Ursulin
2015-04-20 13:33 ` Chris Wilson
0 siblings, 1 reply; 7+ messages in thread
From: Tvrtko Ursulin @ 2015-04-20 13:11 UTC (permalink / raw)
To: Chris Wilson, Intel-gfx, Tvrtko Ursulin
On 04/20/2015 01:58 PM, Chris Wilson wrote:
> On Mon, Apr 20, 2015 at 01:53:03PM +0100, Tvrtko Ursulin wrote:
>>> No we can't do this, as it makes close sync and so can have disasterous
>>> effects on performance (though mitigated chiefly by userspace
>>> agressively caching bo) and also the unbind is very likely to fail,
>>> though admittedly the fbcon copy should be before X starts (ab)using
>>> signals - hence nasty WARN_ON.
>>>
>>> Plus also walking this linear list is quite painful in certain abusive
>>> tests. My preference for fixing this bug would be via vma active
>>> references and auto-unbinding on retirement after a close.
>>
>> Why this is any different today with GEM_CLOSE having pretty similar
>> VMA unbind loop? Is the typical (and interesting) case not that
>> GEM_CLOSE will trigger gem_object_close and gem_object_free at the
>> same invocation?
>
> We have such a cleanup loop in free_object, but we have an active
> reference to ensure that we only do so once the object is idle (and
> unbinding won't cause to wait).
Is that a predominant situation - closing of active objects vs inactive?
It would be surprising (to me).
Regards,
Tvrtko
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] drm/i915: Do not leak VMAs (and PPGTT VMs) of imported flinked objects
2015-04-20 13:11 ` Tvrtko Ursulin
@ 2015-04-20 13:33 ` Chris Wilson
0 siblings, 0 replies; 7+ messages in thread
From: Chris Wilson @ 2015-04-20 13:33 UTC (permalink / raw)
To: Tvrtko Ursulin; +Cc: Intel-gfx
On Mon, Apr 20, 2015 at 02:11:39PM +0100, Tvrtko Ursulin wrote:
>
> On 04/20/2015 01:58 PM, Chris Wilson wrote:
> >On Mon, Apr 20, 2015 at 01:53:03PM +0100, Tvrtko Ursulin wrote:
> >>>No we can't do this, as it makes close sync and so can have disasterous
> >>>effects on performance (though mitigated chiefly by userspace
> >>>agressively caching bo) and also the unbind is very likely to fail,
> >>>though admittedly the fbcon copy should be before X starts (ab)using
> >>>signals - hence nasty WARN_ON.
> >>>
> >>>Plus also walking this linear list is quite painful in certain abusive
> >>>tests. My preference for fixing this bug would be via vma active
> >>>references and auto-unbinding on retirement after a close.
> >>
> >>Why this is any different today with GEM_CLOSE having pretty similar
> >>VMA unbind loop? Is the typical (and interesting) case not that
> >>GEM_CLOSE will trigger gem_object_close and gem_object_free at the
> >>same invocation?
> >
> >We have such a cleanup loop in free_object, but we have an active
> >reference to ensure that we only do so once the object is idle (and
> >unbinding won't cause to wait).
>
> Is that a predominant situation - closing of active objects vs
> inactive? It would be surprising (to me).
Relatively rare due to our aggressive userspace caching. (You can look
at a couple of other drivers which don't use either such an aggressive
cache or employ active references to see how much it hurts *cough*
nouveau *cough*). However, we do hit it often enough through flinked
buffers which can't be safely reused and so get closed as soon as we
finish referencing them in commands.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] drm/i915: Do not leak VMAs (and PPGTT VMs) of imported flinked objects
2015-04-20 12:14 [PATCH] drm/i915: Do not leak VMAs (and PPGTT VMs) of imported flinked objects Tvrtko Ursulin
2015-04-20 12:36 ` Chris Wilson
@ 2015-04-20 16:57 ` shuang.he
1 sibling, 0 replies; 7+ messages in thread
From: shuang.he @ 2015-04-20 16:57 UTC (permalink / raw)
To: shuang.he, ethan.gao, intel-gfx, tvrtko.ursulin
Tested-By: Intel Graphics QA PRTS (Patch Regression Test System Contact: shuang.he@intel.com)
Task id: 6235
-------------------------------------Summary-------------------------------------
Platform Delta drm-intel-nightly Series Applied
PNV 276/276 276/276
ILK 302/302 302/302
SNB 318/318 318/318
IVB 341/341 341/341
BYT 287/287 287/287
BDW -35 318/318 283/318
-------------------------------------Detailed-------------------------------------
Platform Test drm-intel-nightly Series Applied
*BDW igt@gem_fenced_exec_thrash@no-spare-fences-busy-interruptible PASS(2) DMESG_WARN(2)
(dmesg patch applied)WARNING:at_drivers/gpu/drm/i915/i915_gem.c:#i915_gem_unbind_vma[i915]()@WARNING:.* at .* i915_gem_unbind_vma
*BDW igt@gem_persistent_relocs@forked-interruptible PASS(2) DMESG_WARN(2)
(dmesg patch applied)WARNING:at_drivers/gpu/drm/i915/i915_gem.c:#i915_gem_unbind_vma[i915]()@WARNING:.* at .* i915_gem_unbind_vma
*BDW igt@gem_persistent_relocs@forked-interruptible-faulting-reloc PASS(2) DMESG_WARN(2)
(dmesg patch applied)WARNING:at_drivers/gpu/drm/i915/i915_gem.c:#i915_gem_unbind_vma[i915]()@WARNING:.* at .* i915_gem_unbind_vma
*BDW igt@gem_persistent_relocs@forked-interruptible-faulting-reloc-thrash-inactive PASS(2) DMESG_WARN(2)
(dmesg patch applied)WARNING:at_drivers/gpu/drm/i915/i915_gem.c:#i915_gem_unbind_vma[i915]()@WARNING:.* at .* i915_gem_unbind_vma
*BDW igt@gem_persistent_relocs@forked-interruptible-faulting-reloc-thrashing PASS(2) DMESG_WARN(2)
(dmesg patch applied)WARNING:at_drivers/gpu/drm/i915/i915_gem.c:#i915_gem_unbind_vma[i915]()@WARNING:.* at .* i915_gem_unbind_vma
*BDW igt@gem_persistent_relocs@forked-interruptible-thrash-inactive PASS(2) DMESG_WARN(2)
(dmesg patch applied)WARNING:at_drivers/gpu/drm/i915/i915_gem.c:#i915_gem_unbind_vma[i915]()@WARNING:.* at .* i915_gem_unbind_vma
*BDW igt@gem_persistent_relocs@forked-interruptible-thrashing PASS(2) DMESG_WARN(2)
(dmesg patch applied)WARNING:at_drivers/gpu/drm/i915/i915_gem.c:#i915_gem_unbind_vma[i915]()@WARNING:.* at .* i915_gem_unbind_vma
*BDW igt@gem_persistent_relocs@interruptible PASS(2) DMESG_WARN(2)
(dmesg patch applied)WARNING:at_drivers/gpu/drm/i915/i915_gem.c:#i915_gem_unbind_vma[i915]()@WARNING:.* at .* i915_gem_unbind_vma
*BDW igt@gem_reloc_vs_gpu@faulting-reloc-interruptible PASS(2) DMESG_WARN(2)
(dmesg patch applied)WARNING:at_drivers/gpu/drm/i915/i915_gem.c:#i915_gem_unbind_vma[i915]()@WARNING:.* at .* i915_gem_unbind_vma
*BDW igt@gem_reloc_vs_gpu@forked-interruptible PASS(2) DMESG_WARN(2)
(dmesg patch applied)WARNING:at_drivers/gpu/drm/i915/i915_gem.c:#i915_gem_unbind_vma[i915]()@WARNING:.* at .* i915_gem_unbind_vma
*BDW igt@gem_reloc_vs_gpu@forked-interruptible-faulting-reloc PASS(2) DMESG_WARN(2)
(dmesg patch applied)WARNING:at_drivers/gpu/drm/i915/i915_gem.c:#i915_gem_unbind_vma[i915]()@WARNING:.* at .* i915_gem_unbind_vma
*BDW igt@gem_reloc_vs_gpu@forked-interruptible-faulting-reloc-thrash-inactive PASS(2) DMESG_WARN(2)
(dmesg patch applied)WARNING:at_drivers/gpu/drm/i915/i915_gem.c:#i915_gem_unbind_vma[i915]()@WARNING:.* at .* i915_gem_unbind_vma
*BDW igt@gem_reloc_vs_gpu@forked-interruptible-faulting-reloc-thrashing PASS(2) DMESG_WARN(2)
(dmesg patch applied)WARNING:at_drivers/gpu/drm/i915/i915_gem.c:#i915_gem_unbind_vma[i915]()@WARNING:.* at .* i915_gem_unbind_vma
*BDW igt@gem_reloc_vs_gpu@forked-interruptible-thrash-inactive PASS(2) DMESG_WARN(2)
(dmesg patch applied)WARNING:at_drivers/gpu/drm/i915/i915_gem.c:#i915_gem_unbind_vma[i915]()@WARNING:.* at .* i915_gem_unbind_vma
*BDW igt@gem_reloc_vs_gpu@forked-interruptible-thrashing PASS(2) DMESG_WARN(2)
(dmesg patch applied)WARNING:at_drivers/gpu/drm/i915/i915_gem.c:#i915_gem_unbind_vma[i915]()@WARNING:.* at .* i915_gem_unbind_vma
*BDW igt@gem_reloc_vs_gpu@interruptible PASS(2) DMESG_WARN(2)
(dmesg patch applied)WARNING:at_drivers/gpu/drm/i915/i915_gem.c:#i915_gem_unbind_vma[i915]()@WARNING:.* at .* i915_gem_unbind_vma
*BDW igt@gem_render_copy_redux@flink-interruptible PASS(2) DMESG_WARN(2)
(dmesg patch applied)WARNING:at_drivers/gpu/drm/i915/i915_gem.c:#i915_gem_unbind_vma[i915]()@WARNING:.* at .* i915_gem_unbind_vma
*BDW igt@gem_render_copy_redux@interruptible PASS(2) DMESG_WARN(2)
(dmesg patch applied)WARNING:at_drivers/gpu/drm/i915/i915_gem.c:#i915_gem_unbind_vma[i915]()@WARNING:.* at .* i915_gem_unbind_vma
*BDW igt@gem_userptr_blits@forked-sync-interruptible PASS(2) DMESG_WARN(2)
(dmesg patch applied)WARNING:at_drivers/gpu/drm/i915/i915_gem.c:#i915_gem_unbind_vma[i915]()@WARNING:.* at .* i915_gem_unbind_vma
*BDW igt@gem_userptr_blits@forked-sync-mempressure-interruptible PASS(2) DMESG_WARN(2)
(dmesg patch applied)WARNING:at_drivers/gpu/drm/i915/i915_gem.c:#i915_gem_unbind_vma[i915]()@WARNING:.* at .* i915_gem_unbind_vma
*BDW igt@gem_userptr_blits@forked-sync-multifd-interruptible PASS(2) DMESG_WARN(2)
(dmesg patch applied)WARNING:at_drivers/gpu/drm/i915/i915_gem.c:#i915_gem_unbind_vma[i915]()@WARNING:.* at .* i915_gem_unbind_vma
*BDW igt@gem_userptr_blits@forked-sync-multifd-mempressure-interruptible PASS(2) DMESG_WARN(2)
(dmesg patch applied)WARNING:at_drivers/gpu/drm/i915/i915_gem.c:#i915_gem_unbind_vma[i915]()@WARNING:.* at .* i915_gem_unbind_vma
*BDW igt@gem_userptr_blits@forked-sync-swapping-interruptible PASS(2) DMESG_WARN(2)
(dmesg patch applied)WARNING:at_drivers/gpu/drm/i915/i915_gem.c:#i915_gem_unbind_vma[i915]()@WARNING:.* at .* i915_gem_unbind_vma
*BDW igt@gem_userptr_blits@forked-sync-swapping-mempressure-interruptible PASS(2) DMESG_WARN(2)
(dmesg patch applied)WARNING:at_drivers/gpu/drm/i915/i915_gem.c:#i915_gem_unbind_vma[i915]()@WARNING:.* at .* i915_gem_unbind_vma
*BDW igt@gem_userptr_blits@forked-sync-swapping-multifd-interruptible PASS(2) DMESG_WARN(2)
(dmesg patch applied)WARNING:at_drivers/gpu/drm/i915/i915_gem.c:#i915_gem_unbind_vma[i915]()@WARNING:.* at .* i915_gem_unbind_vma
*BDW igt@gem_userptr_blits@forked-sync-swapping-multifd-mempressure-interruptible PASS(2) DMESG_WARN(1)
(dmesg patch applied)WARNING:at_drivers/gpu/drm/i915/i915_gem.c:#i915_gem_unbind_vma[i915]()@WARNING:.* at .* i915_gem_unbind_vma
*BDW igt@gem_userptr_blits@forked-unsync-interruptible PASS(2) DMESG_WARN(1)
(dmesg patch applied)WARNING:at_drivers/gpu/drm/i915/i915_gem.c:#i915_gem_unbind_vma[i915]()@WARNING:.* at .* i915_gem_unbind_vma
*BDW igt@gem_userptr_blits@forked-unsync-mempressure-interruptible PASS(2) DMESG_WARN(1)
(dmesg patch applied)WARNING:at_drivers/gpu/drm/i915/i915_gem.c:#i915_gem_unbind_vma[i915]()@WARNING:.* at .* i915_gem_unbind_vma
*BDW igt@gem_userptr_blits@forked-unsync-multifd-interruptible PASS(2) DMESG_WARN(1)
(dmesg patch applied)WARNING:at_drivers/gpu/drm/i915/i915_gem.c:#i915_gem_unbind_vma[i915]()@WARNING:.* at .* i915_gem_unbind_vma
*BDW igt@gem_userptr_blits@forked-unsync-multifd-mempressure-interruptible PASS(2) DMESG_WARN(1)
(dmesg patch applied)WARNING:at_drivers/gpu/drm/i915/i915_gem.c:#i915_gem_unbind_vma[i915]()@WARNING:.* at .* i915_gem_unbind_vma
*BDW igt@gem_userptr_blits@forked-unsync-swapping-interruptible PASS(2) DMESG_WARN(1)
(dmesg patch applied)WARNING:at_drivers/gpu/drm/i915/i915_gem.c:#i915_gem_unbind_vma[i915]()@WARNING:.* at .* i915_gem_unbind_vma
*BDW igt@gem_userptr_blits@forked-unsync-swapping-mempressure-interruptible PASS(2) DMESG_WARN(1)
(dmesg patch applied)WARNING:at_drivers/gpu/drm/i915/i915_gem.c:#i915_gem_unbind_vma[i915]()@WARNING:.* at .* i915_gem_unbind_vma
*BDW igt@gem_write_read_ring_switch@blt2bsd-interruptible PASS(2) DMESG_WARN(1)
(dmesg patch applied)WARNING:at_drivers/gpu/drm/i915/i915_gem.c:#i915_gem_unbind_vma[i915]()@WARNING:.* at .* i915_gem_unbind_vma
*BDW igt@gem_write_read_ring_switch@blt2render-interruptible PASS(2) DMESG_WARN(1)
(dmesg patch applied)WARNING:at_drivers/gpu/drm/i915/i915_gem.c:#i915_gem_unbind_vma[i915]()@WARNING:.* at .* i915_gem_unbind_vma
*BDW igt@gem_write_read_ring_switch@blt2vebox-interruptible PASS(2) DMESG_WARN(1)
(dmesg patch applied)WARNING:at_drivers/gpu/drm/i915/i915_gem.c:#i915_gem_unbind_vma[i915]()@WARNING:.* at .* i915_gem_unbind_vma
Note: You need to pay more attention to line start with '*'
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2015-04-20 16:58 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-04-20 12:14 [PATCH] drm/i915: Do not leak VMAs (and PPGTT VMs) of imported flinked objects Tvrtko Ursulin
2015-04-20 12:36 ` Chris Wilson
2015-04-20 12:53 ` Tvrtko Ursulin
2015-04-20 12:58 ` Chris Wilson
2015-04-20 13:11 ` Tvrtko Ursulin
2015-04-20 13:33 ` Chris Wilson
2015-04-20 16:57 ` shuang.he
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.