From: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
To: Matthew Auld <matthew.william.auld@gmail.com>
Cc: Intel Graphics Development <intel-gfx@lists.freedesktop.org>,
ML dri-devel <dri-devel@lists.freedesktop.org>
Subject: Re: [Intel-gfx] [PATCH v2 06/16] drm/i915: Ensure gem_contexts selftests work with unbind changes.
Date: Wed, 8 Dec 2021 14:20:20 +0100 [thread overview]
Message-ID: <6cbad03a-4a6c-af9e-82cb-4759a2e61c70@linux.intel.com> (raw)
In-Reply-To: <CAM0jSHPbcU9wJyKasz_c9uXHuSe=B7rx5bHfhBoV4joFGi-YNg@mail.gmail.com>
On 07-12-2021 11:44, Matthew Auld wrote:
> On Mon, 29 Nov 2021 at 13:57, Maarten Lankhorst
> <maarten.lankhorst@linux.intel.com> wrote:
>> In the next commit, we don't evict when refcount = 0.
>>
>> igt_vm_isolation() continuously tries to pin/unpin at same address,
>> but also calls put() on the object, which means the object may not
>> be unpinned in time.
>>
>> Instead of this, re-use the same object over and over, so they can
>> be unbound as required.
>>
>> Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
> Is this something to be worried about in the real world, outside of
> the selftests?
I don't think userspace could hit it because the race is small, it would need to free an object, then immediately try to softpin a new object in the same place.
It could be fixed, but it would require a massive rework of eviction. It could eventually be done, but requires fixing the entire vm locking. I don't think userspace
will hit it, except if it tried deliberately. If it does turn out to be a problem, a workaround would be only calling i915_gem_evict_vm() without locks, so it can call drain_freed_objects as needed. This requires some surgery
to make execbuf handle the case where we may drop all locks when evicting.
>> ---
>> .../drm/i915/gem/selftests/i915_gem_context.c | 54 +++++++++++--------
>> 1 file changed, 32 insertions(+), 22 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c b/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c
>> index b32f7fed2d9c..3fc595b57cf4 100644
>> --- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c
>> +++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c
>> @@ -1481,10 +1481,10 @@ static int check_scratch(struct i915_address_space *vm, u64 offset)
>>
>> static int write_to_scratch(struct i915_gem_context *ctx,
>> struct intel_engine_cs *engine,
>> + struct drm_i915_gem_object *obj,
>> u64 offset, u32 value)
>> {
>> struct drm_i915_private *i915 = ctx->i915;
>> - struct drm_i915_gem_object *obj;
>> struct i915_address_space *vm;
>> struct i915_request *rq;
>> struct i915_vma *vma;
>> @@ -1497,15 +1497,9 @@ static int write_to_scratch(struct i915_gem_context *ctx,
>> if (err)
>> return err;
>>
>> - obj = i915_gem_object_create_internal(i915, PAGE_SIZE);
>> - if (IS_ERR(obj))
>> - return PTR_ERR(obj);
>> -
>> cmd = i915_gem_object_pin_map_unlocked(obj, I915_MAP_WB);
>> - if (IS_ERR(cmd)) {
>> - err = PTR_ERR(cmd);
>> - goto out;
>> - }
>> + if (IS_ERR(cmd))
>> + return PTR_ERR(cmd);
>>
>> *cmd++ = MI_STORE_DWORD_IMM_GEN4;
>> if (GRAPHICS_VER(i915) >= 8) {
>> @@ -1569,17 +1563,19 @@ static int write_to_scratch(struct i915_gem_context *ctx,
>> i915_vma_unpin(vma);
>> out_vm:
>> i915_vm_put(vm);
>> -out:
>> - i915_gem_object_put(obj);
>> +
>> + if (!err)
>> + err = i915_gem_object_wait(obj, 0, MAX_SCHEDULE_TIMEOUT);
>> +
>> return err;
>> }
>>
>> static int read_from_scratch(struct i915_gem_context *ctx,
>> struct intel_engine_cs *engine,
>> + struct drm_i915_gem_object *obj,
>> u64 offset, u32 *value)
>> {
>> struct drm_i915_private *i915 = ctx->i915;
>> - struct drm_i915_gem_object *obj;
>> struct i915_address_space *vm;
>> const u32 result = 0x100;
>> struct i915_request *rq;
>> @@ -1594,10 +1590,6 @@ static int read_from_scratch(struct i915_gem_context *ctx,
>> if (err)
>> return err;
>>
>> - obj = i915_gem_object_create_internal(i915, PAGE_SIZE);
>> - if (IS_ERR(obj))
>> - return PTR_ERR(obj);
>> -
>> if (GRAPHICS_VER(i915) >= 8) {
>> const u32 GPR0 = engine->mmio_base + 0x600;
>>
>> @@ -1615,7 +1607,7 @@ static int read_from_scratch(struct i915_gem_context *ctx,
>> cmd = i915_gem_object_pin_map_unlocked(obj, I915_MAP_WB);
>> if (IS_ERR(cmd)) {
>> err = PTR_ERR(cmd);
>> - goto out;
>> + goto err_unpin;
>> }
>>
>> memset(cmd, POISON_INUSE, PAGE_SIZE);
>> @@ -1651,7 +1643,7 @@ static int read_from_scratch(struct i915_gem_context *ctx,
>> cmd = i915_gem_object_pin_map_unlocked(obj, I915_MAP_WB);
>> if (IS_ERR(cmd)) {
>> err = PTR_ERR(cmd);
>> - goto out;
>> + goto err_unpin;
>> }
>>
>> memset(cmd, POISON_INUSE, PAGE_SIZE);
>> @@ -1722,8 +1714,10 @@ static int read_from_scratch(struct i915_gem_context *ctx,
>> i915_vma_unpin(vma);
>> out_vm:
>> i915_vm_put(vm);
>> -out:
>> - i915_gem_object_put(obj);
>> +
>> + if (!err)
>> + err = i915_gem_object_wait(obj, 0, MAX_SCHEDULE_TIMEOUT);
>> +
>> return err;
>> }
>>
>> @@ -1765,6 +1759,7 @@ static int igt_vm_isolation(void *arg)
>> u64 vm_total;
>> u32 expected;
>> int err;
>> + struct drm_i915_gem_object *obj_a, *obj_b;
> Nit: Christmas tree-ish
>
>> if (GRAPHICS_VER(i915) < 7)
>> return 0;
>> @@ -1810,6 +1805,18 @@ static int igt_vm_isolation(void *arg)
>> vm_total = ctx_a->vm->total;
>> GEM_BUG_ON(ctx_b->vm->total != vm_total);
>>
>> + obj_a = i915_gem_object_create_internal(i915, PAGE_SIZE);
>> + if (IS_ERR(obj_a)) {
>> + err = PTR_ERR(obj_a);
>> + goto out_file;
>> + }
>> +
>> + obj_b = i915_gem_object_create_internal(i915, PAGE_SIZE);
>> + if (IS_ERR(obj_b)) {
>> + err = PTR_ERR(obj_b);
>> + goto put_a;
>> + }
>> +
>> count = 0;
>> num_engines = 0;
>> for_each_uabi_engine(engine, i915) {
>> @@ -1832,10 +1839,10 @@ static int igt_vm_isolation(void *arg)
>> I915_GTT_PAGE_SIZE, vm_total,
>> sizeof(u32), alignof_dword);
>>
>> - err = write_to_scratch(ctx_a, engine,
>> + err = write_to_scratch(ctx_a, engine, obj_a,
>> offset, 0xdeadbeef);
>> if (err == 0)
>> - err = read_from_scratch(ctx_b, engine,
>> + err = read_from_scratch(ctx_b, engine, obj_b,
>> offset, &value);
>> if (err)
>> goto out_file;
> goto put_b; below also?
>
> Otherwise,
> Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Thanks, will fixup both!
~Maarten
next prev parent reply other threads:[~2021-12-08 13:20 UTC|newest]
Thread overview: 59+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-11-29 13:47 [Intel-gfx] [PATCH v2 00/16] drm/i915: Remove short term pins from execbuf Maarten Lankhorst
2021-11-29 13:47 ` [Intel-gfx] [PATCH v2 01/16] drm/i915: Remove unused bits of i915_vma/active api Maarten Lankhorst
2021-11-29 13:47 ` [Intel-gfx] [PATCH v2 02/16] drm/i915: Change shrink ordering to use locking around unbinding Maarten Lankhorst
2021-11-29 13:47 ` [Intel-gfx] [PATCH v2 03/16] drm/i915: Remove pages_mutex and intel_gtt->vma_ops.set/clear_pages members, v2 Maarten Lankhorst
2021-12-06 13:13 ` Matthew Auld
2021-12-06 15:18 ` Maarten Lankhorst
2021-12-06 17:00 ` Matthew Auld
2021-12-07 18:15 ` Daniel Vetter
2021-12-06 17:10 ` Matthew Auld
2021-12-07 10:06 ` Maarten Lankhorst
2021-12-07 10:45 ` Matthew Auld
2021-11-29 13:47 ` [Intel-gfx] [PATCH v2 04/16] drm/i915: Take object lock in i915_ggtt_pin if ww is not set Maarten Lankhorst
2021-12-06 13:18 ` Matthew Auld
2021-11-29 13:47 ` [Intel-gfx] [PATCH v2 05/16] drm/i915: Force ww lock for i915_gem_object_ggtt_pin_ww Maarten Lankhorst
2021-11-30 9:20 ` [Intel-gfx] [PATCH] drm/i915: Force ww lock for i915_gem_object_ggtt_pin_ww, v2 Maarten Lankhorst
2021-12-01 15:07 ` Matthew Auld
2021-11-29 13:47 ` [Intel-gfx] [PATCH v2 06/16] drm/i915: Ensure gem_contexts selftests work with unbind changes Maarten Lankhorst
2021-12-07 10:44 ` Matthew Auld
2021-12-08 13:20 ` Maarten Lankhorst [this message]
2021-11-29 13:47 ` [Intel-gfx] [PATCH v2 07/16] drm/i915: Take trylock during eviction, v2 Maarten Lankhorst
2021-12-07 11:01 ` Matthew Auld
2021-12-08 13:28 ` Maarten Lankhorst
2021-11-29 13:47 ` [Intel-gfx] [PATCH v2 08/16] drm/i915: Pass trylock context to callers Maarten Lankhorst
2021-12-07 14:26 ` Matthew Auld
2021-11-29 13:47 ` [Intel-gfx] [PATCH v2 09/16] drm/i915: Ensure i915_vma tests do not get -ENOSPC with the locking changes Maarten Lankhorst
2021-12-08 11:49 ` Matthew Auld
2021-12-08 12:01 ` Matthew Auld
2021-11-29 13:47 ` [Intel-gfx] [PATCH v2 10/16] drm/i915: Make i915_gem_evict_vm work correctly for already locked objects Maarten Lankhorst
2021-12-08 12:07 ` Matthew Auld
2021-12-08 13:34 ` Maarten Lankhorst
2021-11-29 13:47 ` [Intel-gfx] [PATCH v2 11/16] drm/i915: Call i915_gem_evict_vm in vm_fault_gtt to prevent new ENOSPC errors Maarten Lankhorst
2021-12-09 12:17 ` Matthew Auld
2021-12-09 12:59 ` Maarten Lankhorst
2021-11-29 13:47 ` [Intel-gfx] [PATCH v2 12/16] drm/i915: Add i915_vma_unbind_unlocked, and take obj lock for i915_vma_unbind Maarten Lankhorst
2021-12-09 13:05 ` Matthew Auld
2021-12-09 13:25 ` Maarten Lankhorst
2021-12-09 13:40 ` Matthew Auld
2021-12-09 13:45 ` Maarten Lankhorst
2021-12-09 14:27 ` Matthew Auld
2021-11-29 13:47 ` [Intel-gfx] [PATCH v2 13/16] drm/i915: Require object lock when freeing pages during destruction Maarten Lankhorst
2021-11-29 13:47 ` [Intel-gfx] [PATCH v2 14/16] drm/i915: Remove assert_object_held_shared Maarten Lankhorst
2021-12-09 13:07 ` Matthew Auld
2021-11-29 13:47 ` [Intel-gfx] [PATCH v2 15/16] drm/i915: Remove support for unlocked i915_vma unbind Maarten Lankhorst
2021-11-29 13:47 ` [Intel-gfx] [PATCH v2 16/16] drm/i915: Remove short-term pins from execbuf, v5 Maarten Lankhorst
2021-12-09 16:22 ` Matthew Auld
2021-11-29 15:32 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Remove short term pins from execbuf Patchwork
2021-11-29 15:33 ` [Intel-gfx] ✗ Fi.CI.SPARSE: " Patchwork
2021-11-29 15:37 ` [Intel-gfx] ✗ Fi.CI.DOCS: " Patchwork
2021-11-29 16:11 ` [Intel-gfx] ✗ Fi.CI.BAT: failure " Patchwork
2021-11-30 8:54 ` [Intel-gfx] [PATCH v2 00/16] " Tvrtko Ursulin
2021-11-30 11:17 ` Maarten Lankhorst
2021-11-30 18:38 ` Tvrtko Ursulin
2021-12-01 11:15 ` Maarten Lankhorst
2021-12-01 13:11 ` Tvrtko Ursulin
2021-11-30 11:18 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Remove short term pins from execbuf. (rev2) Patchwork
2021-11-30 11:19 ` [Intel-gfx] ✗ Fi.CI.SPARSE: " Patchwork
2021-11-30 11:23 ` [Intel-gfx] ✗ Fi.CI.DOCS: " Patchwork
2021-11-30 11:49 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2021-11-30 14:51 ` [Intel-gfx] ✗ Fi.CI.IGT: failure " Patchwork
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=6cbad03a-4a6c-af9e-82cb-4759a2e61c70@linux.intel.com \
--to=maarten.lankhorst@linux.intel.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=intel-gfx@lists.freedesktop.org \
--cc=matthew.william.auld@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox