From: Mika Kuoppala <mika.kuoppala@linux.intel.com>
To: Chris Wilson <chris@chris-wilson.co.uk>, intel-gfx@lists.freedesktop.org
Cc: stable@vger.kernel.org, Guenter Roeck <linux@roeck-us.net>,
Chris Wilson <chris@chris-wilson.co.uk>
Subject: Re: [Intel-gfx] [PATCH] drm/i915: Skip stale object handle for debugfs per-file-stats
Date: Tue, 30 Jun 2020 19:16:43 +0300 [thread overview]
Message-ID: <87imf84jh0.fsf@gaia.fi.intel.com> (raw)
In-Reply-To: <20200630152724.3734-1-chris@chris-wilson.co.uk>
Chris Wilson <chris@chris-wilson.co.uk> writes:
> As we close a handle GEM object, we update the drm_file's idr with an
> error pointer to indicate the in-progress closure, and finally set it to
The error pointer part stage seems to be missing.
But the finding is valid.
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
> NULL. If we read the idr directly, we may then see an invalid object
> pointer, and in our debugfs per_file_stats() we therefore need to
> protect against the entry being invalid.
>
> [ 1016.651637] RIP: 0010:per_file_stats+0xe/0x16e
> [ 1016.651646] Code: d2 41 0f b6 8e 69 8c 00 00 48 89 df 48 c7 c6 7b 74 8c be 31 c0 e8 0c 89 cf ff eb d2 0f 1f 44 00 00 55 48 89 e5 41
> 57 41 56 53 <8b> 06 85 c0 0f 84 4d 01 00 00 49 89 d6 48 89 f3 3d ff ff ff 7f 73
> [ 1016.651651] RSP: 0018:ffffad3a01337ba0 EFLAGS: 00010293
> [ 1016.651656] RAX: 0000000000000018 RBX: ffff96fe040d65e0 RCX: 0000000000000002
> [ 1016.651660] RDX: ffffad3a01337c50 RSI: 0000000000000000 RDI: 00000000000001e8
> [ 1016.651663] RBP: ffffad3a01337bb8 R08: 0000000000000000 R09: 00000000000001c0
> [ 1016.651667] R10: 0000000000000000 R11: ffffffffbdbe5fce R12: 0000000000000000
> [ 1016.651671] R13: ffffffffbdbe5fce R14: ffffad3a01337c50 R15: 0000000000000001
> [ 1016.651676] FS: 00007a597e2d7480(0000) GS:ffff96ff3bb00000(0000) knlGS:0000000000000000
> [ 1016.651680] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [ 1016.651683] CR2: 0000000000000000 CR3: 0000000171fc2001 CR4: 00000000003606e0
> [ 1016.651687] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> [ 1016.651690] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
> [ 1016.651693] Call Trace:
> [ 1016.651693] Call Trace:
> [ 1016.651703] idr_for_each+0x8a/0xe8
> [ 1016.651711] i915_gem_object_info+0x2a3/0x3eb
> [ 1016.651720] seq_read+0x162/0x3ca
> [ 1016.651727] full_proxy_read+0x5b/0x8d
> [ 1016.651733] __vfs_read+0x45/0x1bb
> [ 1016.651741] vfs_read+0xc9/0x15e
> [ 1016.651746] ksys_read+0x7e/0xde
> [ 1016.651752] do_syscall_64+0x54/0x68
> [ 1016.651758] entry_SYSCALL_64_after_hwframe+0x44/0xa9
>
> Reported-by: Guenter Roeck <linux@roeck-us.net>
> Fixes: a8c15954d64a ("drm/i915: Protect debugfs per_file_stats with RCU lock")
> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
> Cc: Guenter Roeck <linux@roeck-us.net>
> Cc: stable@vger.kernel.org
> ---
> drivers/gpu/drm/i915/i915_debugfs.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c b/drivers/gpu/drm/i915/i915_debugfs.c
> index 8594a8ef08ce..9ca94a435b75 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -230,7 +230,7 @@ static int per_file_stats(int id, void *ptr, void *data)
> struct file_stats *stats = data;
> struct i915_vma *vma;
>
> - if (!kref_get_unless_zero(&obj->base.refcount))
> + if (IS_ERR_OR_NULL(obj) || !kref_get_unless_zero(&obj->base.refcount))
> return 0;
>
> stats->count++;
> --
> 2.20.1
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
WARNING: multiple messages have this Message-ID (diff)
From: Mika Kuoppala <mika.kuoppala@linux.intel.com>
To: Chris Wilson <chris@chris-wilson.co.uk>, intel-gfx@lists.freedesktop.org
Cc: Chris Wilson <chris@chris-wilson.co.uk>,
Guenter Roeck <linux@roeck-us.net>,
stable@vger.kernel.org
Subject: Re: [PATCH] drm/i915: Skip stale object handle for debugfs per-file-stats
Date: Tue, 30 Jun 2020 19:16:43 +0300 [thread overview]
Message-ID: <87imf84jh0.fsf@gaia.fi.intel.com> (raw)
In-Reply-To: <20200630152724.3734-1-chris@chris-wilson.co.uk>
Chris Wilson <chris@chris-wilson.co.uk> writes:
> As we close a handle GEM object, we update the drm_file's idr with an
> error pointer to indicate the in-progress closure, and finally set it to
The error pointer part stage seems to be missing.
But the finding is valid.
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
> NULL. If we read the idr directly, we may then see an invalid object
> pointer, and in our debugfs per_file_stats() we therefore need to
> protect against the entry being invalid.
>
> [ 1016.651637] RIP: 0010:per_file_stats+0xe/0x16e
> [ 1016.651646] Code: d2 41 0f b6 8e 69 8c 00 00 48 89 df 48 c7 c6 7b 74 8c be 31 c0 e8 0c 89 cf ff eb d2 0f 1f 44 00 00 55 48 89 e5 41
> 57 41 56 53 <8b> 06 85 c0 0f 84 4d 01 00 00 49 89 d6 48 89 f3 3d ff ff ff 7f 73
> [ 1016.651651] RSP: 0018:ffffad3a01337ba0 EFLAGS: 00010293
> [ 1016.651656] RAX: 0000000000000018 RBX: ffff96fe040d65e0 RCX: 0000000000000002
> [ 1016.651660] RDX: ffffad3a01337c50 RSI: 0000000000000000 RDI: 00000000000001e8
> [ 1016.651663] RBP: ffffad3a01337bb8 R08: 0000000000000000 R09: 00000000000001c0
> [ 1016.651667] R10: 0000000000000000 R11: ffffffffbdbe5fce R12: 0000000000000000
> [ 1016.651671] R13: ffffffffbdbe5fce R14: ffffad3a01337c50 R15: 0000000000000001
> [ 1016.651676] FS: 00007a597e2d7480(0000) GS:ffff96ff3bb00000(0000) knlGS:0000000000000000
> [ 1016.651680] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [ 1016.651683] CR2: 0000000000000000 CR3: 0000000171fc2001 CR4: 00000000003606e0
> [ 1016.651687] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> [ 1016.651690] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
> [ 1016.651693] Call Trace:
> [ 1016.651693] Call Trace:
> [ 1016.651703] idr_for_each+0x8a/0xe8
> [ 1016.651711] i915_gem_object_info+0x2a3/0x3eb
> [ 1016.651720] seq_read+0x162/0x3ca
> [ 1016.651727] full_proxy_read+0x5b/0x8d
> [ 1016.651733] __vfs_read+0x45/0x1bb
> [ 1016.651741] vfs_read+0xc9/0x15e
> [ 1016.651746] ksys_read+0x7e/0xde
> [ 1016.651752] do_syscall_64+0x54/0x68
> [ 1016.651758] entry_SYSCALL_64_after_hwframe+0x44/0xa9
>
> Reported-by: Guenter Roeck <linux@roeck-us.net>
> Fixes: a8c15954d64a ("drm/i915: Protect debugfs per_file_stats with RCU lock")
> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
> Cc: Guenter Roeck <linux@roeck-us.net>
> Cc: stable@vger.kernel.org
> ---
> drivers/gpu/drm/i915/i915_debugfs.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c b/drivers/gpu/drm/i915/i915_debugfs.c
> index 8594a8ef08ce..9ca94a435b75 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -230,7 +230,7 @@ static int per_file_stats(int id, void *ptr, void *data)
> struct file_stats *stats = data;
> struct i915_vma *vma;
>
> - if (!kref_get_unless_zero(&obj->base.refcount))
> + if (IS_ERR_OR_NULL(obj) || !kref_get_unless_zero(&obj->base.refcount))
> return 0;
>
> stats->count++;
> --
> 2.20.1
next prev parent reply other threads:[~2020-06-30 16:16 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-06-30 15:27 [Intel-gfx] [PATCH] drm/i915: Skip stale object handle for debugfs per-file-stats Chris Wilson
2020-06-30 15:27 ` Chris Wilson
2020-06-30 16:16 ` Mika Kuoppala [this message]
2020-06-30 16:16 ` Mika Kuoppala
2020-06-30 17:29 ` [Intel-gfx] " Chris Wilson
2020-06-30 17:29 ` Chris Wilson
2020-06-30 17:31 ` [Intel-gfx] ✓ Fi.CI.BAT: success for " Patchwork
2020-06-30 23:18 ` [Intel-gfx] ✓ Fi.CI.IGT: " 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=87imf84jh0.fsf@gaia.fi.intel.com \
--to=mika.kuoppala@linux.intel.com \
--cc=chris@chris-wilson.co.uk \
--cc=intel-gfx@lists.freedesktop.org \
--cc=linux@roeck-us.net \
--cc=stable@vger.kernel.org \
/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 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.