[Bug 207383] [Regression] 5.7 amdgpu/polaris11 gpf: amdgpu_atomic_commit_tail

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



https://bugzilla.kernel.org/show_bug.cgi?id=207383

--- Comment #84 from Nicholas Kazlauskas (nicholas.kazlauskas@xxxxxxx) ---
We don't manually free the dm_state from amdgpu, that should be handled by the
DRM core.

It should generally only be freed once it's no longer use by the DRM core as
well once the state has been swapped and we drop the reference on the old state
at the end of commit tail.

If DRM private objects work the same as regular DRM objects - which from my
impression they should - then they should be NULL until they've been acquired
for a new state as needed.

This turns out to be on almost every commit in our current code. I think most
commits that touch planes or CRTCs would end up doing this.

I kind of wonder if we're keeping the old dm_state pointer that was freed in
the case where it isn't duplicated and for whatever reason it isn't actually
NULL.

Based on the above discussion I guess we're probably not doing a use after free
on the dc_state itself.

There's been other bugs with private objects in the past with DRM that didn't
exist with the regular objects that I'd almost consider finding an alternative
solution here and not keeping an old vs new dc_state just to avoid using them
in the first place.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel



[Index of Archives]     [Linux DRI Users]     [Linux Intel Graphics]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux