On 15/07/2026 17:02, Marco Pagani wrote:
8<>
I first want to understand exactly what the issue is. The current design
exactly cannot free the memory under the scheduler nose unless there is
a test bug where test exited and has left the scheduler with unprocessed
jobs. I am not saying we cannot have reference counted jobs but, again,
at the moment I don't understand the problem.
I think that the current design of the mock scheduler can indeed free
test objects' memory under the scheduler backend's nose. Consider the
example discussed above: the mock scheduler is instantiated and released
in the .init and .exit functions respectively, while jobs are allocated
in the test body using drm_mock_sched_job_new(). In this rather basic
use case, jobs' memory is freed before the entities and the scheduler
are released in the .exit function.
So at first I thought that as long as entity is freed at each test exit,
which includes idling, and is done by all current test cases (apart from
the parallel one where you did it via actions) it is all fine. The
entity->last_scheduled you mention is not a concern then since it is
cleared etc.
However, now I think that even if entity is idled and freed before test
exit that does nothing for the jobs not yet processed by the
drm_sched_free_job_work()-er.
Even though I was testing with KASAN I possibly did not manage to hit
that race. Strange but I guess possible.
Unless I am missing something with the above analysis, one options is
along the lines of what you propose - forgo using kunit managed
allocations for anything mock scheduler owned. Second would be to stop
using test suite init/exit for the scheduler management and just make
each test create own scheduler and free it as it exits.
Regardless of the option, as long as it is safe against UAFs we are I
think good. Memory leaks on test failures are not that interesting that
it would warrant coming up with anything more complicated.
Does that make sense? If so, question is which option is simpler?
Probably just making tests create and destroy schedulers since then
there is no need to deal with any memory freeing. It would be just two
lines added to a subset of tests, the ones which rely on .init/.exit.
Regards,
Tvrtko
