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.hi...@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@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
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
