Thanks Harry,
P.S Just spotted following memory leak in DAL when loading/unloading
Xorg - maybe something you also wanna take a look .
unreferenced object 0xffff880059fc0000 (size 24640):
 comm "Xorg", pid 1395, jiffies 4295164722 (age 6699.912s)
 hex dump (first 32 bytes):
   01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
 backtrace:
   [<000000000e9d80ff>] dc_create_transfer_func+0x1a/0x40 [amdgpu]
   [<000000005a24894c>]
fill_stream_properties_from_drm_display_mode+0x25/0x410 [amdgpu]
   [<0000000098c1adc7>] create_stream_for_sink+0x19a/0x790 [amdgpu]
   [<000000000ab720fc>] amdgpu_dm_connector_mode_valid+0xe3/0x4d0 [amdgpu]
   [<000000004a8a0d75>]
drm_helper_probe_single_connector_modes+0x811/0xb20 [drm_kms_helper]
   [<00000000d551192f>] drm_mode_getconnector+0x536/0x580 [drm]
   [<00000000d9a8e32d>] drm_ioctl_kernel+0xa7/0xf0 [drm]
   [<00000000f08bfd00>] drm_ioctl+0x3ef/0x490 [drm]
   [<00000000583ca5f6>] amdgpu_drm_ioctl+0x72/0xd0 [amdgpu]
   [<000000003d352ad0>] do_vfs_ioctl+0x11a/0x830
   [<000000008290460f>] SyS_ioctl+0x74/0x80
   [<000000003e42a381>] do_syscall_64+0xe1/0x270
   [<00000000ea5f5530>] return_from_SYSCALL_64+0x0/0x65
   [<00000000941b2638>] 0xffffffffffffffff
unreferenced object 0xffff880059fc8000 (size 24640):
 comm "Xorg", pid 1395, jiffies 4295164722 (age 6699.916s)
On 01/15/2018 09:58 AM, Harry Wentland wrote:
> Hey Andrey,
>
> been sick for the last few days which is why I wasn't able to follow up on that other email thread. I'm still working from home today so won't be able to give this a spin. Leo, if you got a chance it'd be useful to see if we can repro it. If not I'll try it tomorrow.
>
> Harry
>
> On 2018-01-14 06:22 PM, Grodzovsky, Andrey wrote:
>> Thanks, you did it right. I will try to think more how this happened, Harry, Leo, if you have banwidth to try and reproduce it it would help, from Kasan prints it seems the way to make it more probable to happen is to move the mouse repeatedly during flipping like video playback, also maybe trying async flip mode makes it more probable.
>>
>> Thanks,
>> Andrey
>>
>> ________________________________________
>> From: Johannes Hirte <johannes.hirte at datenkhaos.de>
>> Sent: 14 January 2018 15:34:16
>> To: Grodzovsky, Andrey
>> Cc: LuÃs Mendes; Deucher, Alexander; Li, Sun peng (Leo); Wentland, Harry; Koenig, Christian; amd-gfx at lists.freedesktop.org
>> Subject: Re: BUG: KASAN: use-after-free in amdgpu_job_free_cb
>>
>> On 2018 Jan 14, Grodzovsky, Andrey wrote:
>>> To be sure it was inserted at the correct place please send me output of git diff on your modified branch.
>>>
>>> Thanks,
>>> Andrey
>>>
>> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
>> index bb5fa895fb64..bc2050a5a5c6 100644
>> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
>> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
>> @@ -4802,7 +4802,7 @@ static int amdgpu_dm_atomic_check(struct drm_device *dev,
>> * synchronization events.
>> */
>>
>> - if (lock_and_validation_needed) {
>> + if (lock_and_validation_needed || state->legacy_cursor_update == true) {
>>
>> ret = do_aquire_global_lock(dev, state);
>> if (ret)
>>
>> If this matters, I've applied the patch on top of 4.15-rc7 with your
>> "Fix: Save job's priority on it's creation instead of accessing it from s_entity later on."
>> patch. This one is still not upstream, but without I see the other
>> use-after-free
>>
>> --
>> Regards,
>> Johannes
>>
