AMD-GFX Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Felix Kuehling <felix.kuehling@amd.com>
To: amd-gfx@lists.freedesktop.org
Subject: Re: [PATCH] drm/amdgpu: Fix vm free pts race when process exiting
Date: Wed, 4 Aug 2021 11:47:06 -0400	[thread overview]
Message-ID: <351c02cc-4b76-85d8-a64f-e87182cac19d@amd.com> (raw)
In-Reply-To: <920b7b04-8f8d-a57a-724e-811a4c7e581c@gmail.com>

Am 2021-08-04 um 5:01 a.m. schrieb Christian König:
> Am 03.08.21 um 00:33 schrieb Philip Yang:
>> Take vm->invalidated_lock spinlock to remove vm pd and pt bos, to avoid
>> link list corruption with crash backtrace:
>>
>> [ 2290.505111] list_del corruption. next->prev should be
>>   ffff9b2514ec0018, but was 4e03280211010f04
>> [ 2290.505154] kernel BUG at lib/list_debug.c:56!
>> [ 2290.505176] invalid opcode: 0000 [#1] SMP NOPTI
>> [ 2290.505254] Workqueue: events delayed_fput
>> [ 2290.505271] RIP: 0010:__list_del_entry_valid.cold.1+0x20/0x4c
>> [ 2290.505513] Call Trace:
>> [ 2290.505623]  amdgpu_vm_free_table+0x26/0x80 [amdgpu]
>> [ 2290.505705]  amdgpu_vm_free_pts+0x7a/0xf0 [amdgpu]
>> [ 2290.505786]  amdgpu_vm_fini+0x1f0/0x440 [amdgpu]
>> [ 2290.505864]  amdgpu_driver_postclose_kms+0x172/0x290 [amdgpu]
>> [ 2290.505893]  drm_file_free.part.10+0x1d4/0x270 [drm]
>> [ 2290.505916]  drm_release+0xa9/0xe0 [drm]
>> [ 2290.505930]  __fput+0xb7/0x230
>> [ 2290.505942]  delayed_fput+0x1c/0x30
>> [ 2290.505957]  process_one_work+0x1a7/0x360
>> [ 2290.505971]  worker_thread+0x30/0x390
>> [ 2290.505985]  ? create_worker+0x1a0/0x1a0
>> [ 2290.505999]  kthread+0x112/0x130
>> [ 2290.506011]  ? kthread_flush_work_fn+0x10/0x10
>> [ 2290.506027]  ret_from_fork+0x22/0x40
>
> Wow, well this is a big NAK.
>
> The page tables should never ever be on the invalidation list or
> otherwise we would try to point PTEs to them which is a huge security
> issue.

entry->vm_status is used on other lists as well, and I think page tables
can be added to those when they are evicted:

    static void amdgpu_vm_bo_evicted(struct amdgpu_vm_bo_base *vm_bo)
    {
            struct amdgpu_vm *vm = vm_bo->vm;
            struct amdgpu_bo *bo = vm_bo->bo;

            vm_bo->moved = true;
            if (bo->tbo.type == ttm_bo_type_kernel)
                    list_move(&vm_bo->vm_status, &vm->evicted);
            else
                    list_move_tail(&vm_bo->vm_status, &vm->evicted);
    }

But that never seems to involve the invalidated_lock. Maybe there is
some other lock we should be holding somewhere (not necessarily in
amdgpu_vm_free_table) to avoid this list corruption.

Regards,
  Felix


>
> Taking the lock just workaround that. Can you investigate how it
> happens that a page table ends up on that list?
>
> Thanks in advance,
> Christian.
>
>>
>> Signed-off-by: Philip Yang <Philip.Yang@amd.com>
>> ---
>>   drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 2 ++
>>   1 file changed, 2 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
>> index 2a88ed5d983b..5c4c355e7d6b 100644
>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
>> @@ -1045,7 +1045,9 @@ static void amdgpu_vm_free_table(struct
>> amdgpu_vm_bo_base *entry)
>>           return;
>>       shadow = amdgpu_bo_shadowed(entry->bo);
>>       entry->bo->vm_bo = NULL;
>> +    spin_lock(&entry->vm->invalidated_lock);
>>       list_del(&entry->vm_status);
>> +    spin_unlock(&entry->vm->invalidated_lock);
>>       amdgpu_bo_unref(&shadow);
>>       amdgpu_bo_unref(&entry->bo);
>>   }
>

      parent reply	other threads:[~2021-08-04 15:47 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-02 22:33 [PATCH] drm/amdgpu: Fix vm free pts race when process exiting Philip Yang
2021-08-03 16:13 ` Felix Kuehling
2021-08-04  9:01 ` Christian König
2021-08-04 15:11   ` philip yang
2021-08-04 15:32     ` Christian König
2021-08-04 15:47   ` Felix Kuehling [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=351c02cc-4b76-85d8-a64f-e87182cac19d@amd.com \
    --to=felix.kuehling@amd.com \
    --cc=amd-gfx@lists.freedesktop.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox