[PATCH 1/4] drm/i915: don't call free_mmap_offset when purging

[Matthew Auld]

On 05/01/2022 15:46, Thomas Hellström wrote:
> On Wed, 2022-01-05 at 14:58 +0000, Matthew Auld wrote:
>> The TTM backend is in theory the only user here(also purge should
>> only
>> be called once we have dropped the pages), where it is setup at
>> object
>> creation and is only removed once the object is destroyed. Also
>> resetting the node here might be iffy since the ttm fault handler
>> uses the stored fake offset to determine the page offset within the
>> pages
>> array.
>>
>> This also blows up in the dontneed-before-mmap test, since the
>> expectation is that the vma_node will live on, until the object is
>> destroyed:
>>
>> <2> [749.062902] kernel BUG at
>> drivers/gpu/drm/i915/gem/i915_gem_ttm.c:943!
>> <4> [749.062923] invalid opcode: 0000 [#1] PREEMPT SMP NOPTI
>> <4> [749.062928] CPU: 0 PID: 1643 Comm: gem_madvise Tainted: G     U
>> W         5.16.0-rc8-CI-CI_DRM_11046+ #1
>> <4> [749.062933] Hardware name: Gigabyte Technology Co., Ltd. GB-Z390
>> Garuda/GB-Z390 Garuda-CF, BIOS IG1c 11/19/2019
>> <4> [749.062937] RIP: 0010:i915_ttm_mmap_offset.cold.35+0x5b/0x5d
>> [i915]
>> <4> [749.063044] Code: 00 48 c7 c2 a0 23 4e a0 48 c7 c7 26 df 4a a0
>> e8 95 1d d0 e0 bf 01 00 00 00 e8 8b ec cf e0 31 f6 bf 09 00 00 00 e8
>> 5f 30 c0 e0 <0f> 0b 48 c7 c1 24 4b 56 a0 ba 5b 03 00 00 48 c7 c6 c0
>> 23 4e a0 48
>> <4> [749.063052] RSP: 0018:ffffc90002ab7d38 EFLAGS: 00010246
>> <4> [749.063056] RAX: 0000000000000240 RBX: ffff88811f2e61c0 RCX:
>> 0000000000000006
>> <4> [749.063060] RDX: 0000000000000000 RSI: 0000000000000000 RDI:
>> 0000000000000009
>> <4> [749.063063] RBP: ffffc90002ab7e58 R08: 0000000000000001 R09:
>> 0000000000000001
>> <4> [749.063067] R10: 000000000123d0f8 R11: ffffc90002ab7b20 R12:
>> ffff888112a1a000
>> <4> [749.063071] R13: 0000000000000004 R14: ffff88811f2e61c0 R15:
>> ffff888112a1a000
>> <4> [749.063074] FS:  00007f6e5fcad500(0000)
>> GS:ffff8884ad600000(0000) knlGS:0000000000000000
>> <4> [749.063078] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
>> <4> [749.063081] CR2: 00007efd264e39f0 CR3: 0000000115fd6005 CR4:
>> 00000000003706f0
>> <4> [749.063085] Call Trace:
>> <4> [749.063087]  <TASK>
>> <4> [749.063089]  __assign_mmap_offset+0x41/0x300 [i915]
>> <4> [749.063171]  __assign_mmap_offset_handle+0x159/0x270 [i915]
>> <4> [749.063248]  ? i915_gem_dumb_mmap_offset+0x70/0x70 [i915]
>> <4> [749.063325]  drm_ioctl_kernel+0xae/0x140
>> <4> [749.063330]  drm_ioctl+0x201/0x3d0
>> <4> [749.063333]  ? i915_gem_dumb_mmap_offset+0x70/0x70 [i915]
>> <4> [749.063409]  ? do_user_addr_fault+0x200/0x670
>> <4> [749.063415]  __x64_sys_ioctl+0x6d/0xa0
>> <4> [749.063419]  do_syscall_64+0x3a/0xb0
>> <4> [749.063423]  entry_SYSCALL_64_after_hwframe+0x44/0xae
>> <4> [749.063428] RIP: 0033:0x7f6e5f100317
>>
>> Testcase: igt at gem_madvise@dontneed-before-mmap
>> Fixes: cf3e3e86d779 ("drm/i915: Use ttm mmap handling for ttm bo's.")
>> Signed-off-by: Matthew Auld <matthew.auld at intel.com>
>> Cc: Thomas Hellström <thomas.hellstrom at linux.intel.com>
>> ---
>>   drivers/gpu/drm/i915/gem/i915_gem_pages.c | 1 -
>>   1 file changed, 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_pages.c
>> b/drivers/gpu/drm/i915/gem/i915_gem_pages.c
>> index 89b70f5cde7a..9f429ed6e78a 100644
>> --- a/drivers/gpu/drm/i915/gem/i915_gem_pages.c
>> +++ b/drivers/gpu/drm/i915/gem/i915_gem_pages.c
>> @@ -161,7 +161,6 @@ int i915_gem_object_pin_pages_unlocked(struct
>> drm_i915_gem_object *obj)
>>   /* Immediately discard the backing storage */
>>   int i915_gem_object_truncate(struct drm_i915_gem_object *obj)
>>   {
>> -       drm_gem_free_mmap_offset(&obj->base);
> 
> What happens if a non-ttm shmem system object gets truncated from the
> shrinker and then tries to use the above mmap offset?

AFAIK nothing on integrated is really using this. The mmap_offset ioctl 
stuff is managing multiple vma nodes itself, per object(one for each 
cache type/mapping or something), and so doesn't use this. And the shmem 
mmap ioctl doesn't use the any fake offset stuff, AFAIK.

> 
> /Thomas
> 
> 
> 
>>          if (obj->ops->truncate)
>>                  return obj->ops->truncate(obj);
>>   
> 
>