All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Michel Dänzer" <michel-otUistvHUpPR7s880joybQ@public.gmane.org>
To: christian.koenig-5C7GfCeVMHo@public.gmane.org
Cc: amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org
Subject: Re: KASAN use-after-free report during piglit run
Date: Wed, 1 Nov 2017 17:16:25 +0100	[thread overview]
Message-ID: <276aa31a-9c04-087d-6f35-8a985c8bf92c@daenzer.net> (raw)
In-Reply-To: <6d95903b-3458-73c3-7ab4-2b7025e8c7e9-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>

On 01/11/17 09:47 AM, Christian König wrote:
> Am 31.10.2017 um 18:58 schrieb Michel Dänzer:
>> On 25/10/17 05:43 PM, Michel Dänzer wrote:
>>> KASAN caught another use-after-free on my development machine today, see
>>> the attached dmesg excerpt. There haven't been any related changes in
>>> amd-staging-drm-next since yesterday, so maybe userspace is just
>>> tickling the kernel differently (e.g. piglit runs some more tests in
>>> parallel now). It's not reproducible every time, but it just happened a
>>> second time (with an amd-staging-drm-next commit from about a week ago).
>> I took a closer look, and I think I see what's happening. The
>> use-after-free happens at:
>>
>>    reservation_object_wait_timeout_rcu+0xe02/0xe90
>>    ttm_bo_cleanup_refs_and_unlock+0x271/0x990 [ttm] (ttm_bo.c:530)
>>    ttm_mem_evict_first+0x263/0x4a0 [ttm]
>>
>> The memory was freed at:
>>
>>    [reservation_object_fini]
>>    ttm_bo_cleanup_refs_and_unlock+0x517/0x990 [ttm] (ttm_bo.c:564)
>>    ttm_mem_evict_first+0x263/0x4a0 [ttm]
>>
>> So it's two processes handling the same BO in ttm_mem_evict_first ->
>> ttm_bo_cleanup_refs_and_unlock. The first one unreserved the BO before
>> calling reservation_object_wait_timeout_rcu. Meanwhile, the other one
>> manages to reserve the BO and get all the way to the end of
>> ttm_bo_cleanup_refs_and_unlock, destroying bo->ttm_resv. Then
>> reservation_object_wait_timeout_rcu in the first process still accesses
>> memory which bo->ttm_resv pointed to => boom.
> 
> Good catch. But this means that just grabbing another reference before
> calling reservation_object_wait_timeout_rcu() and we should be on the
> safe side, shouldn't we ?

Grabbing a reference doesn't prevent ttm_bo_cleanup_refs_and_unlock in
another task from destroying bo->ttm_resv, does it?

I sent a patch for review which should fix it.


> Going to take a closer look tomorrow, today is a holiday here and I'm
> actually ill again once more :(

Take rest and get well soon!


-- 
Earthling Michel Dänzer               |               http://www.amd.com
Libre software enthusiast             |             Mesa and X developer
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

      parent reply	other threads:[~2017-11-01 16:16 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-10-25 15:43 KASAN use-after-free report during piglit run Michel Dänzer
     [not found] ` <e9df6a9b-19bc-4b2f-eeb2-a06ebb2f22c2-otUistvHUpPR7s880joybQ@public.gmane.org>
2017-10-25 15:51   ` Christian König
     [not found]     ` <bb31e238-502c-eda7-5bcb-302ef6c04c15-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2017-10-25 15:54       ` Michel Dänzer
     [not found]         ` <9d301254-6ce8-f8e0-ea3f-dc73f0440d08-otUistvHUpPR7s880joybQ@public.gmane.org>
2017-10-30 14:51           ` Christian König
     [not found]             ` <77e5ed00-bc39-4faa-c189-c27191ed4d72-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2017-10-30 14:54               ` Michel Dänzer
2017-10-31 17:58   ` Michel Dänzer
     [not found]     ` <237aa88a-0484-1b7e-d4c7-7f7311c7a1fb-otUistvHUpPR7s880joybQ@public.gmane.org>
2017-11-01  8:47       ` Christian König
     [not found]         ` <6d95903b-3458-73c3-7ab4-2b7025e8c7e9-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2017-11-01 16:16           ` Michel Dänzer [this message]

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=276aa31a-9c04-087d-6f35-8a985c8bf92c@daenzer.net \
    --to=michel-otuistvhuppr7s880joybq@public.gmane.org \
    --cc=amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org \
    --cc=christian.koenig-5C7GfCeVMHo@public.gmane.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.