On 2018-09-17 1:55 p.m., Christian König wrote:
> Am 17.09.2018 um 19:50 schrieb Tom St Denis:
>> On 2018-09-17 1:45 p.m., Christian König wrote:
>>> Mhm, not the slightest idea.
>>>
>>> That nearly looks like adev->stolen_vga_memory already contains
>>> something.
>>
>> Nope,
>>
>> [Â Â 51.564605] >>>adev->stolen_vga_memory == (null)
>> [Â Â 51.564619] kasan: CONFIG_KASAN_INLINE enabled
>> [Â Â 51.564877] kasan: GPF could be caused by NULL-ptr deref or user
>> memory access
>> [Â Â 51.565071] general protection fault: 0000 [#1] SMP DEBUG_PAGEALLOC
>> KASAN NOPTI
>> [Â Â 51.565254] CPU: 6 PID: 3863 Comm: modprobe Not tainted 4.19.0-rc1+
>> #30
>> [Â Â 51.565425] Hardware name: System manufacturer System Product
>> Name/TUF B350M-PLUS GAMING, BIOS 4011 04/19/2018
>> [Â Â 51.565714] RIP: 0010:amdgpu_bo_create_kernel+0x59/0x1a0 [amdgpu]
>>
>> That's me printing out the value of the value for stolen_vga_memory
>> before the call to allocate it.
>
> What does amdgpu_bo_create_kernel+0x59 points to?
I've never really got line numbers to work with the kernel but if I had
to guess I'd say right here
int amdgpu_bo_create_kernel(struct amdgpu_device *adev,
unsigned long size, int align,
u32 domain, struct amdgpu_bo **bo_ptr,
u64 *gpu_addr, void **cpu_addr)
{
int r;
r = amdgpu_bo_create_reserved(adev, size, align, domain, bo_ptr,
gpu_addr, cpu_addr);
if (r)
return r;
*bo_ptr is NULL ===> amdgpu_bo_unreserve(*bo_ptr);
return 0;
}
Which then results in
static inline void amdgpu_bo_unreserve(struct amdgpu_bo *bo)
{
ttm_bo_unreserve(&bo->tbo);
}
Which then passes the address NULL + offsetof(tbo) to ttm_bo_unreserve:
static inline void ttm_bo_unreserve(struct ttm_buffer_object *bo)
{
if (!(bo->mem.placement & TTM_PL_FLAG_NO_EVICT)) {
spin_lock(&bo->bdev->glob->lru_lock);
ttm_bo_add_to_lru(bo);
spin_unlock(&bo->bdev->glob->lru_lock);
}
reservation_object_unlock(bo->resv);
}
Which likely faults on reading bo->mem.placement since the address is bogus.
The report is from amdgpu_bo_create_kernel because everything is a macro
or inlined... :-)
Tom
>
> Christian.
>
>>
>> Tom
>>
>>
>>>
>>> Christian.
>>>
>>> Am 17.09.2018 um 18:47 schrieb Tom St Denis:
>>>> On 2018-09-17 12:21 p.m., Tom St Denis wrote:
>>>>> (attached). I'll try to bisect in a second. Is anyone aware of this?
>>>>>
>>>>> Tom
>>>>
>>>> Bisection led to:
>>>>
>>>> a327772a5655ff4fb104c8aae6515faa461df466 is the first bad commit
>>>> commit a327772a5655ff4fb104c8aae6515faa461df466
>>>> Author: Christian König <christian.koenig at amd.com>
>>>> Date:Â Â Fri Sep 14 21:06:50 2018 +0200
>>>>
>>>> Â Â Â drm/amdgpu: drop size check
>>>>
>>>> Â Â Â We no don't allocate zero sized kernel BOs any longer.
>>>>
>>>>    Signed-off-by: Christian König <christian.koenig at amd.com>
>>>> Â Â Â Reviewed-by: Alex Deucher <alexander.deucher at amd.com>
>>>>
>>>> :040000 040000 265e4fa231d367d354e4c66600b8f98a4d2f04c4
>>>> 3702baaeb2423361dcd7eac8c533edace760ae3e MÂ Â Â Â Â drivers
>>>>
>>>>
>>>> As the culprit.
>>>>
>>>> Cheers,
>>>> Tom
>>>
>>
>> _______________________________________________
>> amd-gfx mailing list
>> amd-gfx at lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
>
