Howdy,
as many of you know, we have potential memory leaks in drm_sched_fini()
which have been tried to be solved by various parties with various
methods in the past.
In our past discussions, we came to the conclusion, that the simplest
solution, blocking in drm_sched_fini(), is not possible beca
The waitqueue that ensures that drm_sched_fini() blocks until the
pending_list has become empty could theoretically cause that function to
block for a very long time. That, ultimately, could block userspace
procesess and prevent them from being killable through SIGKILL.
When a driver calls drm_sch
From: Philipp Stanner
The GPU scheduler currently does not ensure that its pending_list is
empty before performing various other teardown tasks in
drm_sched_fini().
If there are still jobs in the pending_list, this is problematic because
after scheduler teardown, no one will call backend_ops.fre
On Sat Mar 22, 2025 at 1:20 AM JST, Daniel Brooks wrote:
> "Alexandre Courbot" writes:
>
>> Hi Boqun,
>>
>> On Fri Mar 21, 2025 at 3:17 AM JST, Boqun Feng wrote:
>>> Also an Instant type has been proposed and reviewed for a while:
>>>
>>>
>>> https://lore.kernel.org/rust-for-linux/20250220070
There is a new callback for always tearing the scheduler down in a
leak-free, deadlock-free manner.
Port Nouveau as its first user by providing the scheduler with a
callback that ensures the fence context gets killed in drm_sched_fini().
Signed-off-by: Philipp Stanner
---
drivers/gpu/drm/nouvea
drm_sched_fini() can leak jobs under certain circumstances.
Warn if that happens.
Signed-off-by: Philipp Stanner
---
drivers/gpu/drm/scheduler/sched_main.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/scheduler/sched_main.c
b/drivers/gpu/drm/scheduler/sched_main.c
in
