[PATCH v4 1/5] drm: Move some options to separate new Kconfig
Tvrtko Ursulin
tvrtko.ursulin at igalia.com
Fri Mar 7 16:59:13 UTC 2025
On 07/03/2025 13:41, Philipp Stanner wrote:
> Hi,
>
> You forgot to put folks in CC as recipents for the cover letter :(
>
>
> On Thu, 2025-03-06 at 17:05 +0000, Tvrtko Ursulin wrote:
>> Move some options out into a new debug specific kconfig file in order
>> to
>> make things a bit cleaner.
>>
>> Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin at igalia.com>
>> Cc: Christian König <christian.koenig at amd.com>
>> Cc: Danilo Krummrich <dakr at kernel.org>
>> Cc: Matthew Brost <matthew.brost at intel.com>
>> Cc: Philipp Stanner <phasta at kernel.org>
>
> We all have our individual work flows, so don't take this as lecturing
> or anything – I just suspect that I was forgotten in the cover letter
> because you Cc people by hand in the individual patches.
>
> What I do is that I run get_maintainer and then put the individuals
> listed there into the --to= field. That sends the entire series to all
> of them.
>
> Only sometimes, when there's a huge list of recipents or when the
> patches of a series are very independent, I deviate from that rule.
>
> JFYI
Notice it was there in v3, I just omitted to paste it this time.
> Anyways, we have a bigger problem about the entire series. I now tested
> again with the same setup as yesterday and the faults are indeed gone,
> so that's good.
>
> But to be sure I then did run kmemleak and got a list of leaks that is
> more than 2000 lines long.
There is this comment for drm_sched_fini which ends with:
"""
...
* This stops submission of new jobs to the hardware through
* drm_sched_backend_ops.run_job(). Consequently,
drm_sched_backend_ops.free_job()
* will not be called for all jobs still in drm_gpu_scheduler.pending_list.
* There is no solution for this currently. Thus, it is up to the
driver to make
* sure that:
*
* a) drm_sched_fini() is only called after for all submitted jobs
* drm_sched_backend_ops.free_job() has been called or that
* b) the jobs for which drm_sched_backend_ops.free_job() has not been
called
* after drm_sched_fini() ran are freed manually.
*
* FIXME: Take care of the above problem and prevent this function from
leaking
* the jobs in drm_gpu_scheduler.pending_list under any circumstances.
"""
I got bitten by that. Keep forgetting how fragile the thing is.. :(
Regards,
Tvrtko
More information about the dri-devel
mailing list