public inbox for intel-gfx@lists.freedesktop.org
 help / color / mirror / Atom feed
From: "Das, Nirmoy" <nirmoy.das@intel.com>
To: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>,
	"Das, Nirmoy" <nirmoy.das@linux.intel.com>,
	<intel-gfx@lists.freedesktop.org>
Cc: matthew.auld@intel.com, Chris Wilson <chris.p.wilson@intel.com>
Subject: Re: [Intel-gfx] [PATCH 1/2] drm/i915: Fix a potential UAF at device unload
Date: Thu, 22 Sep 2022 14:32:27 +0200	[thread overview]
Message-ID: <c310d75b-38c4-698f-56bb-d7ae27ecc6ed@intel.com> (raw)
In-Reply-To: <90befd6f-da2c-702d-e92a-e6ace9d3e9f2@linux.intel.com>


On 9/22/2022 2:28 PM, Tvrtko Ursulin wrote:
>
> On 22/09/2022 13:11, Das, Nirmoy wrote:
>>
>> On 9/22/2022 11:37 AM, Tvrtko Ursulin wrote:
>>>
>>> On 21/09/2022 16:53, Das, Nirmoy wrote:
>>>>
>>>> On 9/9/2022 10:55 AM, Tvrtko Ursulin wrote:
>>>>>
>>>>> On 08/09/2022 21:07, Nirmoy Das wrote:
>>>>>> i915_gem_drain_freed_objects() might not be enough to
>>>>>> free all the objects and RCU delayed work might get
>>>>>> scheduled after the i915 device struct gets freed.
>>>>>>
>>>>>> Call i915_gem_drain_workqueue() to catch all RCU delayed work.
>>>>>>
>>>>>> Suggested-by: Chris Wilson <chris.p.wilson@intel.com>
>>>>>> Signed-off-by: Nirmoy Das <nirmoy.das@intel.com>
>>>>>> ---
>>>>>>   drivers/gpu/drm/i915/i915_gem.c | 2 +-
>>>>>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>>>>>
>>>>>> diff --git a/drivers/gpu/drm/i915/i915_gem.c 
>>>>>> b/drivers/gpu/drm/i915/i915_gem.c
>>>>>> index 0f49ec9d494a..e8a053eaaa89 100644
>>>>>> --- a/drivers/gpu/drm/i915/i915_gem.c
>>>>>> +++ b/drivers/gpu/drm/i915/i915_gem.c
>>>>>> @@ -1254,7 +1254,7 @@ void i915_gem_init_early(struct 
>>>>>> drm_i915_private *dev_priv)
>>>>>>     void i915_gem_cleanup_early(struct drm_i915_private *dev_priv)
>>>>>>   {
>>>>>> -    i915_gem_drain_freed_objects(dev_priv);
>>>>>> +    i915_gem_drain_workqueue(dev_priv);
>>>>>> GEM_BUG_ON(!llist_empty(&dev_priv->mm.free_list));
>>>>>> GEM_BUG_ON(atomic_read(&dev_priv->mm.free_count));
>>>>>>       drm_WARN_ON(&dev_priv->drm, dev_priv->mm.shrink_count);
>>>>>
>>>>>
>>>>> Help me spot the place where RCU free worker schedules itself back 
>>>>> to free more objects - if I got the rationale here right?
>>>> (Sorry for late reply, was on leave last week.)
>>>>
>>>> I had to clarify this with Chris. So when driver frees a obj, it 
>>>> does dma_resv_fini() which will drop reference
>>>>
>>>> for all the fences in it and a fence might  reference to an object 
>>>> and upon release of that fence can trigger a  release reference to 
>>>> an object.
>>>
>>> Hmm I couldn't find that in code but never mind. It's just a 
>>> stronger version of the same flushing and it's not on a path where 
>>> speed matters so feel free to go with it.
>>
>>
>> Can I get a Ack from you for this, Tvrtko ?
>
> Sorry yes, forgot to be explicit.
>
> Acked-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>


Thanks a lot. I will rebase and send again.


Nirmoy

>
> Regards,
>
> Tvrtko

  reply	other threads:[~2022-09-22 12:32 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-09-08 20:07 [Intel-gfx] [PATCH 1/2] drm/i915: Fix a potential UAF at device unload Nirmoy Das
2022-09-08 20:07 ` [Intel-gfx] [PATCH 2/2] drm/i915: remove excessive i915_gem_drain_freed_objects Nirmoy Das
2022-09-09  8:55   ` Tvrtko Ursulin
2022-09-08 20:47 ` [Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/2] drm/i915: Fix a potential UAF at device unload Patchwork
2022-09-09  8:55 ` [Intel-gfx] [PATCH 1/2] " Tvrtko Ursulin
2022-09-21 15:53   ` Das, Nirmoy
2022-09-22  9:37     ` Tvrtko Ursulin
2022-09-22 12:11       ` Das, Nirmoy
2022-09-22 12:28         ` Tvrtko Ursulin
2022-09-22 12:32           ` Das, Nirmoy [this message]
  -- strict thread matches above, loose matches on Subject: below --
2022-09-23  7:35 Nirmoy Das
2022-09-27  7:43 ` Andrzej Hajda
2022-09-29 11:32 ` Andi Shyti
2022-09-29 11:36   ` Das, Nirmoy
2022-10-21 16:34 ` Ville Syrjälä
2022-10-24  8:08   ` Das, Nirmoy
2022-11-02 17:55     ` Ville Syrjälä
2022-11-02 18:37       ` Das, Nirmoy

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=c310d75b-38c4-698f-56bb-d7ae27ecc6ed@intel.com \
    --to=nirmoy.das@intel.com \
    --cc=chris.p.wilson@intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=matthew.auld@intel.com \
    --cc=nirmoy.das@linux.intel.com \
    --cc=tvrtko.ursulin@linux.intel.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