Hi Christian & Emily I think the v4 fix for "fix force app kill hang" is still not good enough: First: See that in "sched_entity_fini", we only call dma_fence_put(entity->last_scheduled" under the condition of "If (entity->fini_status)", so This way there is memory leak for the case of "entity->fini_stats ==0" Second: If we move dma_fence_put(entity->last_scheduled) out of the condition of "if (entity->fini_status)", the memory leak issue can be fixed But there will be kernel NULL pointer access, I think the time you call dma_fence_put(entity->last_scheduled") may actually executed *not* On the last scheduled fence of this entity, because it is run without "thread_park/unpark" pair which to make sure scheduler not dealing this entity So with certain race issue, here is the scenario: 1. scheduler is doing the dma_fence_put() on the 1st fence, 2. scheduler set entity->last_scheduled to 1st fence 3. now sched_entity_fini() run, and it call dma_fence_put() on entity->last_scheduled 4. now this 1st fence is actually put double time and the real last fence won't get put by expected any idea? /Monk -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/amd-gfx/attachments/20180418/3bc111b2/attachment-0001.html>
