Re: [Intel-gfx] [PATCH] drm/i915: Fix the race between the GEM close and debugfs

From: "Nikunj A. Dadhania" <nikunj.dadhania@linux.intel.com>
To: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>,
	intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org,
	chris@chris-wilson.co.uk,
	Jani Nikula <jani.nikula@linux.intel.com>,
	Joonas Lahtinen <joonas.lahtinen@linux.intel.com>,
	Rodrigo Vivi <rodrigo.vivi@intel.com>,
	David Airlie <airlied@linux.ie>, Daniel Vetter <daniel@ffwll.ch>
Subject: Re: [Intel-gfx] [PATCH] drm/i915: Fix the race between the GEM close and debugfs
Date: Mon, 14 Sep 2020 23:22:47 +0530	[thread overview]
Message-ID: <139d811d-929f-96c3-16c3-15177fa9bd3f@linux.intel.com> (raw)
In-Reply-To: <66c99a4d-ab35-55e8-44a2-18f5c39b8b1f@linux.intel.com>

On 9/14/2020 10:17 PM, Tvrtko Ursulin wrote:
> 
> On 14/09/2020 12:00, Nikunj A. Dadhania wrote:
>> As we close GEM object and set file_priv to -EBADF which is protected
>> by ctx->mutex, populating the GEM debugfs info is not protected
>> and results in the crash shown below.
>>
>> Make sure to protect the access to file_priv using ctx->mutex to avoid
>> race.
>>
>> BUG: unable to handle page fault for address: ffffffffffffffff
>> RIP: 0010:i915_gem_object_info+0x26b/0x3eb
>> Code: 89 44 24 48 48 89 44 24 40 48 89 44 24 38 48 89 44 24 30 48 89 
>> 44 24 28 48 89 44 24 20 49 8b 46 f0 48 89 44 24 20 49 8b 46 a0 <48> 8b 
>> 58 08 b9 0a 00 00 00 48 b8 aa aa aa aa aa aa aa aa 48 8d bc
>> RSP: 0018:ffffac81c14cfc30 EFLAGS: 00010246
>> RAX: fffffffffffffff7 RBX: ffff95094429c218 RCX: ffff95096756c740
>> RDX: 0000000000000000 RSI: ffffffff919b93ee RDI: ffff95094429c218
>> RBP: ffffac81c14cfd58 R08: ffff9509746fab80 R09: 0000000000000000
>> R10: 0000000000000001 R11: 0000000000000000 R12: ffff9509753f8e80
>> R13: ffffac81c14cfc98 R14: ffff95094429c268 R15: ffffac81c14cfc88
>> FS:  00007a1bdcd52900(0000) GS:ffff950977e00000(0000) 
>> knlGS:0000000000000000
>> CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
>> CR2: ffffffffffffffff CR3: 000000026b4e0000 CR4: 0000000000340ef0
>> Call Trace:
>>   seq_read+0x162/0x3ca
>>   full_proxy_read+0x5b/0x8d
>>   __vfs_read+0x45/0x1b9
>>   vfs_read+0xc9/0x15e
>>   ksys_read+0x7e/0xde
>>   do_syscall_64+0x54/0x7e
>>   entry_SYSCALL_64_after_hwframe+0x44/0xa9
>> RIP: 0033:0x7a1bdd34cf03
>>
>> Signed-off-by: Nikunj A. Dadhania <nikunj.dadhania@linux.intel.com>
>> ---
>>   drivers/gpu/drm/i915/i915_debugfs.c | 2 ++
>>   1 file changed, 2 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
>> b/drivers/gpu/drm/i915/i915_debugfs.c
>> index 784219962193..ea469168cd44 100644
>> --- a/drivers/gpu/drm/i915/i915_debugfs.c
>> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
>> @@ -326,6 +326,7 @@ static void print_context_stats(struct seq_file *m,
>>           }
>>           i915_gem_context_unlock_engines(ctx);
>> +        mutex_lock(&ctx->mutex);
>>           if (!IS_ERR_OR_NULL(ctx->file_priv)) {
>>               struct file_stats stats = {
>>                   .vm = rcu_access_pointer(ctx->vm),
>> @@ -346,6 +347,7 @@ static void print_context_stats(struct seq_file *m,
>>               print_file_stats(m, name, stats);
>>           }
>> +        mutex_unlock(&ctx->mutex);
>>           spin_lock(&i915->gem.contexts.lock);
>>           list_safe_reset_next(ctx, cn, link);
>>
> 
> Fix is correct, but it looked familiar and indeed I found a fix for the 
> same issues back from July. Copied you on that one which now has an r-b. 

Yes, saw your other email. Both are same, whichever gets applied is fine.

> This one can have it as well but please also copy stable.

Do I need to send the patch again with CC to stable?

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

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