Re: [PATCH v2] gpu: Fix uninitialized buddy for built-in drivers

["Danilo Krummrich" <dakr@kernel.org>]

On Thu Feb 19, 2026 at 7:28 PM CET, Koen Koning wrote:
> On Thu, 2026-02-19 at 13:56 +0100, Danilo Krummrich wrote:
>> On Thu Feb 19, 2026 at 1:44 PM CET, Matthew Auld wrote:
>> > On 19/02/2026 11:14, Danilo Krummrich wrote:
>> > > However, I think it was never meant to rely on a build system
>> > > implementation
>> > > detail, nor would this be correct. So, I think this should add
>> > > both Fixes: tags.
>> > 
>> > Yeah, I'm really not sure tbh. From a quick grep there do seem to
>> > be 
>> > other users relying on this:
>> > 
>> > drm/drm_drv.c:1274:module_init(drm_core_init);
>> > drm/scheduler/sched_fence.c:238:module_init(drm_sched_fence_slab_in
>> > it);
>> > 
>> > The sched one looks identical with the slab thing. Do these need to
>> > be 
>> > fixed also?
>> 
>> Yes, those should be fixed as well.
>> 
>> Also note that module_init() compiles down to device_initcall() when
>> built-in,
>> i.e. the initcall stage that is mainly for drivers, not for subsystem
>> code.
>> 
>> Do you want to send a fix for thise as well?
>
> Thanks for your input! The usage in drm_drv.c goes all the way back to
> before the git history, so I'm not sure there's a Fixes: tag that would
> make sense there. Do you have a recommendation for how to handle that
> patch?
>
> Overall, I don't think it makes sense to backport these fixes anyway -
> there's no actual issue unless there's some large refactoring (like
> what happened with drm/buddy).

It is always possible to Cc: stable without a Fixes: tag and a brief comment.
However, as you say, there was never a report about this actually causing any
issues. Obviously, it also can't be an issue for OOT modules. So, a "normal"
patch with a brief note that this dates back to the historic tree seems to be
sufficient.