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

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

[Koen Koning]

Move buddy to the start of the link order, so its __init runs before any
other built-in drivers that may depend on it. Otherwise, a built-in
driver that tries to use the buddy allocator will run into a kernel NULL
pointer dereference because slab_blocks is uninitialized.

Specifically, this fixes drm/xe (as built-in) running into a kernel
panic during boot, because it uses buddy during device probe.

Fixes: ba110db8e1bc ("gpu: Move DRM buddy allocator one level up (part two)")
Cc: Joel Fernandes <joelagnelf@nvidia.com>
Cc: Dave Airlie <airlied@redhat.com>
Cc: intel-xe@lists.freedesktop.org
Tested-by: Peter Senna Tschudin <peter.senna@linux.intel.com>
Signed-off-by: Koen Koning <koen.koning@linux.intel.com>
---
 drivers/gpu/Makefile | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/Makefile b/drivers/gpu/Makefile
index 5cd54d06e262..b4e5e338efa2 100644
--- a/drivers/gpu/Makefile
+++ b/drivers/gpu/Makefile
@@ -2,8 +2,9 @@
 # drm/tegra depends on host1x, so if both drivers are built-in care must be
 # taken to initialize them in the correct order. Link order is the only way
 # to ensure this currently.
+# Similarly, buddy must come first since it is used by other drivers.
+obj-$(CONFIG_GPU_BUDDY)	+= buddy.o
 obj-y			+= host1x/ drm/ vga/ tests/
 obj-$(CONFIG_IMX_IPUV3_CORE)	+= ipu-v3/
 obj-$(CONFIG_TRACE_GPU_MEM)		+= trace/
 obj-$(CONFIG_NOVA_CORE)		+= nova-core/
-obj-$(CONFIG_GPU_BUDDY)		+= buddy.o
-- 
2.48.1

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

[Joel Fernandes]

On 2/13/2026 10:20 AM, Koen Koning wrote:
> Move buddy to the start of the link order, so its __init runs before any
> other built-in drivers that may depend on it. Otherwise, a built-in
> driver that tries to use the buddy allocator will run into a kernel NULL
> pointer dereference because slab_blocks is uninitialized.
> 
> Specifically, this fixes drm/xe (as built-in) running into a kernel
> panic during boot, because it uses buddy during device probe.
> 
> Fixes: ba110db8e1bc ("gpu: Move DRM buddy allocator one level up (part two)")
> Cc: Joel Fernandes <joelagnelf@nvidia.com>
> Cc: Dave Airlie <airlied@redhat.com>
> Cc: intel-xe@lists.freedesktop.org
> Tested-by: Peter Senna Tschudin <peter.senna@linux.intel.com>
> Signed-off-by: Koen Koning <koen.koning@linux.intel.com>
> ---
>  drivers/gpu/Makefile | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/Makefile b/drivers/gpu/Makefile
> index 5cd54d06e262..b4e5e338efa2 100644
> --- a/drivers/gpu/Makefile
> +++ b/drivers/gpu/Makefile
> @@ -2,8 +2,9 @@
>  # drm/tegra depends on host1x, so if both drivers are built-in care must be
>  # taken to initialize them in the correct order. Link order is the only way
>  # to ensure this currently.
> +# Similarly, buddy must come first since it is used by other drivers.
> +obj-$(CONFIG_GPU_BUDDY)	+= buddy.o

Rather than relying on fragile link ordering, would it be better to use an
earlier initcall level for the buddy allocator?

Thanks,

-- 
Joel Fernandes

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

[Matthew Auld]

On 13/02/2026 17:27, Joel Fernandes wrote:
> On 2/13/2026 10:20 AM, Koen Koning wrote:
>> Move buddy to the start of the link order, so its __init runs before any
>> other built-in drivers that may depend on it. Otherwise, a built-in
>> driver that tries to use the buddy allocator will run into a kernel NULL
>> pointer dereference because slab_blocks is uninitialized.
>>
>> Specifically, this fixes drm/xe (as built-in) running into a kernel
>> panic during boot, because it uses buddy during device probe.
>>
>> Fixes: ba110db8e1bc ("gpu: Move DRM buddy allocator one level up (part two)")
>> Cc: Joel Fernandes <joelagnelf@nvidia.com>
>> Cc: Dave Airlie <airlied@redhat.com>
>> Cc: intel-xe@lists.freedesktop.org
>> Tested-by: Peter Senna Tschudin <peter.senna@linux.intel.com>
>> Signed-off-by: Koen Koning <koen.koning@linux.intel.com>
>> ---
>>   drivers/gpu/Makefile | 3 ++-
>>   1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/Makefile b/drivers/gpu/Makefile
>> index 5cd54d06e262..b4e5e338efa2 100644
>> --- a/drivers/gpu/Makefile
>> +++ b/drivers/gpu/Makefile
>> @@ -2,8 +2,9 @@
>>   # drm/tegra depends on host1x, so if both drivers are built-in care must be
>>   # taken to initialize them in the correct order. Link order is the only way
>>   # to ensure this currently.
>> +# Similarly, buddy must come first since it is used by other drivers.
>> +obj-$(CONFIG_GPU_BUDDY)	+= buddy.o
> 
> Rather than relying on fragile link ordering, would it be better to use an
> earlier initcall level for the buddy allocator?

Ok, makes sense. Should we go with something like 
subsys_initcall(gpu_buddy_module_init) here?

> 
> Thanks,
> 

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

[Koen Koning]

Use subsys_initcall instead of module_init for the GPU buddy allocator,
so its initialization code runs before any gpu drivers.
Otherwise, a built-in driver that tries to use the buddy allocator will
run into a kernel NULL pointer dereference because slab_blocks is
uninitialized.

Specifically, this fixes drm/xe (as built-in) running into a kernel
panic during boot, because it uses buddy during device probe.

Fixes: ba110db8e1bc ("gpu: Move DRM buddy allocator one level up (part two)")
Cc: Joel Fernandes <joelagnelf@nvidia.com>
Cc: Dave Airlie <airlied@redhat.com>
Cc: intel-xe@lists.freedesktop.org
Cc: Peter Senna Tschudin <peter.senna@linux.intel.com>
Cc: Matthew Auld <matthew.auld@intel.com>
Signed-off-by: Koen Koning <koen.koning@linux.intel.com>
---
v2: use subsys_initcall instead of relying on (fragile) Makefile ordering
    (suggested by Joel Fernandes <joelagnelf@nvidia.com>)
---
 drivers/gpu/buddy.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/buddy.c b/drivers/gpu/buddy.c
index 603c59a2013a..81f57fdf913b 100644
--- a/drivers/gpu/buddy.c
+++ b/drivers/gpu/buddy.c
@@ -1315,7 +1315,7 @@ static int __init gpu_buddy_module_init(void)
 	return 0;
 }

-module_init(gpu_buddy_module_init);
+subsys_initcall(gpu_buddy_module_init);
 module_exit(gpu_buddy_module_exit);

 MODULE_DESCRIPTION("GPU Buddy Allocator");
--
2.48.1

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

[Joel Fernandes]

On Mon, 16 Feb 2026 12:19:01 +0100, Koen Koning wrote:
> Use subsys_initcall instead of module_init for the GPU buddy allocator,
> so its initialization code runs before any gpu drivers.
> Otherwise, a built-in driver that tries to use the buddy allocator will
> run into a kernel NULL pointer dereference because slab_blocks is
> uninitialized.
> 
> Specifically, this fixes drm/xe (as built-in) running into a kernel
> panic during boot, because it uses buddy during device probe.
> 
> Fixes: ba110db8e1bc ("gpu: Move DRM buddy allocator one level up (part two)")
> Cc: Joel Fernandes <joelagnelf@nvidia.com>
> Cc: Dave Airlie <airlied@redhat.com>
> Cc: intel-xe@lists.freedesktop.org
> Cc: Peter Senna Tschudin <peter.senna@linux.intel.com>
> Cc: Matthew Auld <matthew.auld@intel.com>
> Signed-off-by: Koen Koning <koen.koning@linux.intel.com>
>

Reviewed-by: Joel Fernandes <joelagnelf@nvidia.com>

-- 
Joel Fernandes

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

[Danilo Krummrich]

On Mon Feb 16, 2026 at 12:19 PM CET, Koen Koning wrote:
> Use subsys_initcall instead of module_init for the GPU buddy allocator,
> so its initialization code runs before any gpu drivers.
> Otherwise, a built-in driver that tries to use the buddy allocator will
> run into a kernel NULL pointer dereference because slab_blocks is
> uninitialized.
>
> Specifically, this fixes drm/xe (as built-in) running into a kernel
> panic during boot, because it uses buddy during device probe.

I just noticed that this patch was sent twice, and I posted my feedback on [1]
-- pasting it here as well.

> Fixes: ba110db8e1bc ("gpu: Move DRM buddy allocator one level up (part two)")

This Fixes: tag seems wrong. How is this code move related to this problem?

This should rather be:

Fixes: 6387a3c4b0c4 ("drm: move the buddy allocator from i915 into common drm")

Also, please add:

Cc: stable@vger.kernel.org

> Cc: Joel Fernandes <joelagnelf@nvidia.com>
> Cc: Dave Airlie <airlied@redhat.com>
> Cc: intel-xe@lists.freedesktop.org
> Cc: Peter Senna Tschudin <peter.senna@linux.intel.com>
> Cc: Matthew Auld <matthew.auld@intel.com>
> Signed-off-by: Koen Koning <koen.koning@linux.intel.com>

[1] https://lore.kernel.org/all/DGIUUFLC31D5.2OZBF5FWQJWMZ@kernel.org/

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

[Matthew Auld]

On 19/02/2026 10:16, Danilo Krummrich wrote:
> On Mon Feb 16, 2026 at 12:19 PM CET, Koen Koning wrote:
>> Use subsys_initcall instead of module_init for the GPU buddy allocator,
>> so its initialization code runs before any gpu drivers.
>> Otherwise, a built-in driver that tries to use the buddy allocator will
>> run into a kernel NULL pointer dereference because slab_blocks is
>> uninitialized.
>>
>> Specifically, this fixes drm/xe (as built-in) running into a kernel
>> panic during boot, because it uses buddy during device probe.
> 
> I just noticed that this patch was sent twice, and I posted my feedback on [1]
> -- pasting it here as well.
> 
>> Fixes: ba110db8e1bc ("gpu: Move DRM buddy allocator one level up (part two)")
> 
> This Fixes: tag seems wrong. How is this code move related to this problem?

This popped up as a very recent regression for us internally. It looks 
like it worked before since link order ensured drm_buddy came before all 
the driver code. With above commit the link order changed and became 
drm/ and then buddy. See [1] also, which is maybe clearer to see this.

[1] 
https://lore.kernel.org/intel-xe/20260213152047.179628-1-koen.koning@linux.intel.com/

> 
> This should rather be:
> 
> Fixes: 6387a3c4b0c4 ("drm: move the buddy allocator from i915 into common drm")
> 
> Also, please add:
> 
> Cc: stable@vger.kernel.org
> 
>> Cc: Joel Fernandes <joelagnelf@nvidia.com>
>> Cc: Dave Airlie <airlied@redhat.com>
>> Cc: intel-xe@lists.freedesktop.org
>> Cc: Peter Senna Tschudin <peter.senna@linux.intel.com>
>> Cc: Matthew Auld <matthew.auld@intel.com>
>> Signed-off-by: Koen Koning <koen.koning@linux.intel.com>
> 
> [1] https://lore.kernel.org/all/DGIUUFLC31D5.2OZBF5FWQJWMZ@kernel.org/

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

[Danilo Krummrich]

On Thu Feb 19, 2026 at 11:38 AM CET, Matthew Auld wrote:
> On 19/02/2026 10:16, Danilo Krummrich wrote:
>> On Mon Feb 16, 2026 at 12:19 PM CET, Koen Koning wrote:
>>> Use subsys_initcall instead of module_init for the GPU buddy allocator,
>>> so its initialization code runs before any gpu drivers.
>>> Otherwise, a built-in driver that tries to use the buddy allocator will
>>> run into a kernel NULL pointer dereference because slab_blocks is
>>> uninitialized.
>>>
>>> Specifically, this fixes drm/xe (as built-in) running into a kernel
>>> panic during boot, because it uses buddy during device probe.
>> 
>> I just noticed that this patch was sent twice, and I posted my feedback on [1]
>> -- pasting it here as well.
>> 
>>> Fixes: ba110db8e1bc ("gpu: Move DRM buddy allocator one level up (part two)")
>> 
>> This Fixes: tag seems wrong. How is this code move related to this problem?
>
> This popped up as a very recent regression for us internally. It looks 
> like it worked before since link order ensured drm_buddy came before all 
> the driver code. With above commit the link order changed and became 
> drm/ and then buddy. See [1] also, which is maybe clearer to see this.

I see, I think this would be a good hint for the commit message. :)

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.

Whether it should be backported is a different question though, as it seems to
work by accident in previous versions, i.e. it is only a "potential bug".

My personal opinion is that it should be backported either way, however that's
ultimately up to the stable team.

- Danilo

>
> [1] 
> https://lore.kernel.org/intel-xe/20260213152047.179628-1-koen.koning@linux.intel.com/
>
>> 
>> This should rather be:
>> 
>> Fixes: 6387a3c4b0c4 ("drm: move the buddy allocator from i915 into common drm")
>> 
>> Also, please add:
>> 
>> Cc: stable@vger.kernel.org
>> 
>>> Cc: Joel Fernandes <joelagnelf@nvidia.com>
>>> Cc: Dave Airlie <airlied@redhat.com>
>>> Cc: intel-xe@lists.freedesktop.org
>>> Cc: Peter Senna Tschudin <peter.senna@linux.intel.com>
>>> Cc: Matthew Auld <matthew.auld@intel.com>
>>> Signed-off-by: Koen Koning <koen.koning@linux.intel.com>
>> 
>> [1] https://lore.kernel.org/all/DGIUUFLC31D5.2OZBF5FWQJWMZ@kernel.org/

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

[Matthew Auld]

On 19/02/2026 11:14, Danilo Krummrich wrote:
> On Thu Feb 19, 2026 at 11:38 AM CET, Matthew Auld wrote:
>> On 19/02/2026 10:16, Danilo Krummrich wrote:
>>> On Mon Feb 16, 2026 at 12:19 PM CET, Koen Koning wrote:
>>>> Use subsys_initcall instead of module_init for the GPU buddy allocator,
>>>> so its initialization code runs before any gpu drivers.
>>>> Otherwise, a built-in driver that tries to use the buddy allocator will
>>>> run into a kernel NULL pointer dereference because slab_blocks is
>>>> uninitialized.
>>>>
>>>> Specifically, this fixes drm/xe (as built-in) running into a kernel
>>>> panic during boot, because it uses buddy during device probe.
>>>
>>> I just noticed that this patch was sent twice, and I posted my feedback on [1]
>>> -- pasting it here as well.
>>>
>>>> Fixes: ba110db8e1bc ("gpu: Move DRM buddy allocator one level up (part two)")
>>>
>>> This Fixes: tag seems wrong. How is this code move related to this problem?
>>
>> This popped up as a very recent regression for us internally. It looks
>> like it worked before since link order ensured drm_buddy came before all
>> the driver code. With above commit the link order changed and became
>> drm/ and then buddy. See [1] also, which is maybe clearer to see this.
> 
> I see, I think this would be a good hint for the commit message. :)
> 
> 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_init);

The sched one looks identical with the slab thing. Do these need to be 
fixed also?

> 
> Whether it should be backported is a different question though, as it seems to
> work by accident in previous versions, i.e. it is only a "potential bug".
> 
> My personal opinion is that it should be backported either way, however that's
> ultimately up to the stable team.
> 
> - Danilo
> 
>>
>> [1]
>> https://lore.kernel.org/intel-xe/20260213152047.179628-1-koen.koning@linux.intel.com/
>>
>>>
>>> This should rather be:
>>>
>>> Fixes: 6387a3c4b0c4 ("drm: move the buddy allocator from i915 into common drm")
>>>
>>> Also, please add:
>>>
>>> Cc: stable@vger.kernel.org
>>>
>>>> Cc: Joel Fernandes <joelagnelf@nvidia.com>
>>>> Cc: Dave Airlie <airlied@redhat.com>
>>>> Cc: intel-xe@lists.freedesktop.org
>>>> Cc: Peter Senna Tschudin <peter.senna@linux.intel.com>
>>>> Cc: Matthew Auld <matthew.auld@intel.com>
>>>> Signed-off-by: Koen Koning <koen.koning@linux.intel.com>
>>>
>>> [1] https://lore.kernel.org/all/DGIUUFLC31D5.2OZBF5FWQJWMZ@kernel.org/
> 

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

[Danilo Krummrich]

On Thu Feb 19, 2026 at 1:44 PM CET, Matthew Auld wrote:
> On 19/02/2026 11:14, Danilo Krummrich wrote:
>> On Thu Feb 19, 2026 at 11:38 AM CET, Matthew Auld wrote:
>>> On 19/02/2026 10:16, Danilo Krummrich wrote:
>>>> On Mon Feb 16, 2026 at 12:19 PM CET, Koen Koning wrote:
>>>>> Use subsys_initcall instead of module_init for the GPU buddy allocator,
>>>>> so its initialization code runs before any gpu drivers.
>>>>> Otherwise, a built-in driver that tries to use the buddy allocator will
>>>>> run into a kernel NULL pointer dereference because slab_blocks is
>>>>> uninitialized.
>>>>>
>>>>> Specifically, this fixes drm/xe (as built-in) running into a kernel
>>>>> panic during boot, because it uses buddy during device probe.
>>>>
>>>> I just noticed that this patch was sent twice, and I posted my feedback on [1]
>>>> -- pasting it here as well.
>>>>
>>>>> Fixes: ba110db8e1bc ("gpu: Move DRM buddy allocator one level up (part two)")
>>>>
>>>> This Fixes: tag seems wrong. How is this code move related to this problem?
>>>
>>> This popped up as a very recent regression for us internally. It looks
>>> like it worked before since link order ensured drm_buddy came before all
>>> the driver code. With above commit the link order changed and became
>>> drm/ and then buddy. See [1] also, which is maybe clearer to see this.
>> 
>> I see, I think this would be a good hint for the commit message. :)
>> 
>> 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_init);
>
> 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?

>> 
>> Whether it should be backported is a different question though, as it seems to
>> work by accident in previous versions, i.e. it is only a "potential bug".
>> 
>> My personal opinion is that it should be backported either way, however that's
>> ultimately up to the stable team.
>> 
>> - Danilo
>> 
>>>
>>> [1]
>>> https://lore.kernel.org/intel-xe/20260213152047.179628-1-koen.koning@linux.intel.com/
>>>
>>>>
>>>> This should rather be:
>>>>
>>>> Fixes: 6387a3c4b0c4 ("drm: move the buddy allocator from i915 into common drm")
>>>>
>>>> Also, please add:
>>>>
>>>> Cc: stable@vger.kernel.org
>>>>
>>>>> Cc: Joel Fernandes <joelagnelf@nvidia.com>
>>>>> Cc: Dave Airlie <airlied@redhat.com>
>>>>> Cc: intel-xe@lists.freedesktop.org
>>>>> Cc: Peter Senna Tschudin <peter.senna@linux.intel.com>
>>>>> Cc: Matthew Auld <matthew.auld@intel.com>
>>>>> Signed-off-by: Koen Koning <koen.koning@linux.intel.com>
>>>>
>>>> [1] https://lore.kernel.org/all/DGIUUFLC31D5.2OZBF5FWQJWMZ@kernel.org/
>> 

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

[Matthew Auld]

On 19/02/2026 12:56, 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:
>>> On Thu Feb 19, 2026 at 11:38 AM CET, Matthew Auld wrote:
>>>> On 19/02/2026 10:16, Danilo Krummrich wrote:
>>>>> On Mon Feb 16, 2026 at 12:19 PM CET, Koen Koning wrote:
>>>>>> Use subsys_initcall instead of module_init for the GPU buddy allocator,
>>>>>> so its initialization code runs before any gpu drivers.
>>>>>> Otherwise, a built-in driver that tries to use the buddy allocator will
>>>>>> run into a kernel NULL pointer dereference because slab_blocks is
>>>>>> uninitialized.
>>>>>>
>>>>>> Specifically, this fixes drm/xe (as built-in) running into a kernel
>>>>>> panic during boot, because it uses buddy during device probe.
>>>>>
>>>>> I just noticed that this patch was sent twice, and I posted my feedback on [1]
>>>>> -- pasting it here as well.
>>>>>
>>>>>> Fixes: ba110db8e1bc ("gpu: Move DRM buddy allocator one level up (part two)")
>>>>>
>>>>> This Fixes: tag seems wrong. How is this code move related to this problem?
>>>>
>>>> This popped up as a very recent regression for us internally. It looks
>>>> like it worked before since link order ensured drm_buddy came before all
>>>> the driver code. With above commit the link order changed and became
>>>> drm/ and then buddy. See [1] also, which is maybe clearer to see this.
>>>
>>> I see, I think this would be a good hint for the commit message. :)
>>>
>>> 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_init);
>>
>> 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?

Koen will send something.

> 
>>>
>>> Whether it should be backported is a different question though, as it seems to
>>> work by accident in previous versions, i.e. it is only a "potential bug".
>>>
>>> My personal opinion is that it should be backported either way, however that's
>>> ultimately up to the stable team.
>>>
>>> - Danilo
>>>
>>>>
>>>> [1]
>>>> https://lore.kernel.org/intel-xe/20260213152047.179628-1-koen.koning@linux.intel.com/
>>>>
>>>>>
>>>>> This should rather be:
>>>>>
>>>>> Fixes: 6387a3c4b0c4 ("drm: move the buddy allocator from i915 into common drm")
>>>>>
>>>>> Also, please add:
>>>>>
>>>>> Cc: stable@vger.kernel.org
>>>>>
>>>>>> Cc: Joel Fernandes <joelagnelf@nvidia.com>
>>>>>> Cc: Dave Airlie <airlied@redhat.com>
>>>>>> Cc: intel-xe@lists.freedesktop.org
>>>>>> Cc: Peter Senna Tschudin <peter.senna@linux.intel.com>
>>>>>> Cc: Matthew Auld <matthew.auld@intel.com>
>>>>>> Signed-off-by: Koen Koning <koen.koning@linux.intel.com>
>>>>>
>>>>> [1] https://lore.kernel.org/all/DGIUUFLC31D5.2OZBF5FWQJWMZ@kernel.org/
>>>
> 

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

[Danilo Krummrich]

On Thu Feb 19, 2026 at 4:32 PM CET, Matthew Auld wrote:
> Koen will send something.

Sounds good -- thanks!

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

[Koen Koning]

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).

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

[Danilo Krummrich]

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.

[PATCH v3 0/3] gpu: fix module_init() usage

[Koen Koning]

This series fixes several uses of module_init() for subsystem-level code
that can be used by other drivers, and thus must be initialized first.

While this is not a problem for modules, for built-in drivers
module_init() compiles down to a device_initcall(). Between these, the
initialization order depends on the linking order in the Makefiles, but
this behavior should not be depended on.

This series is the result of recent regressions, where moving buddy from
drm to gpu accidentally changed the Makefile linking order, causing NULL
pointer dereferences in drm drivers.

Replacing module_init() with subsys_initcall() resolves these potential
issues for built-ins, while keeping the behavior the same for modules.

While the fixes can be backported, there have never been reports of
issues besides regressions due to refactoring of code. In particular,
the drm_drv module_init() usage predates the git history.

v2->v3: https://lore.kernel.org/dri-devel/20260216111902.110286-1-koen.koning@linux.intel.com/
 - add patches for other uses of module_init() (drm_dev and drm/sched)
 - reword gpu/buddy commit message

v1->v2:
 - use subsys_initcall instead of relying on (fragile) Makefile ordering

Koen Koning (3):
  gpu/buddy: fix module_init() usage
  drm/sched: fix module_init() usage
  drm/drv: fix module_init() usage

 drivers/gpu/buddy.c                     | 2 +-
 drivers/gpu/drm/drm_drv.c               | 2 +-
 drivers/gpu/drm/scheduler/sched_fence.c | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

--
2.48.1

[PATCH v3 1/3] gpu/buddy: fix module_init() usage

[Koen Koning]

Use subsys_initcall() instead of module_init() (which compiles to
device_initcall() for built-ins) for buddy, so its initialization code
always runs before any (built-in) drivers.
This happened to work correctly so far due to the order of linking in
the Makefiles, but this should not be relied upon.

An incorrect initialization order could lead to built-in drivers that
use the buddy allocator to run into NULL pointer dereferences due to
slab_blocks being uninitialized.

Fixes: 6387a3c4b0c4 ("drm: move the buddy allocator from i915 into common drm")
Fixes: ba110db8e1bc ("gpu: Move DRM buddy allocator one level up (part two)")
Cc: Joel Fernandes <joelagnelf@nvidia.com>
Cc: Dave Airlie <airlied@redhat.com>
Cc: Matthew Auld <matthew.auld@intel.com>
Cc: Peter Senna Tschudin <peter.senna@linux.intel.com>
Cc: intel-xe@lists.freedesktop.org
Cc: stable@vger.kernel.org
Reviewed-by: Joel Fernandes <joelagnelf@nvidia.com>
Signed-off-by: Koen Koning <koen.koning@linux.intel.com>
---
 drivers/gpu/buddy.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/buddy.c b/drivers/gpu/buddy.c
index 603c59a2013a..81f57fdf913b 100644
--- a/drivers/gpu/buddy.c
+++ b/drivers/gpu/buddy.c
@@ -1315,7 +1315,7 @@ static int __init gpu_buddy_module_init(void)
 	return 0;
 }

-module_init(gpu_buddy_module_init);
+subsys_initcall(gpu_buddy_module_init);
 module_exit(gpu_buddy_module_exit);

 MODULE_DESCRIPTION("GPU Buddy Allocator");
--
2.48.1

[PATCH v3 2/3] drm/sched: fix module_init() usage

[Koen Koning]

Use subsys_initcall() instead of module_init() (which compiles to
device_initcall() for built-ins) for sched_fence, so its initialization
code always runs before any (built-in) drivers.
This happened to work correctly so far due to the order of linking in
the Makefiles, but this should not be relied upon.

Fixes: 4983e48c85392 ("drm/sched: move fence slab handling to module init/exit")
Cc: Chunming Zhou <david1.zhou@amd.com>
Cc: Alex Deucher <alexander.deucher@amd.com>
Cc: Lucas Stach <l.stach@pengutronix.de>
Cc: Matthew Brost <matthew.brost@intel.com>
Cc: Danilo Krummrich <dakr@kernel.org>
Cc: Philipp Stanner <phasta@kernel.org>
Cc: "Christian König" <ckoenig.leichtzumerken@gmail.com>
Cc: Matthew Auld <matthew.auld@intel.com>
Cc: stable@vger.kernel.org
Signed-off-by: Koen Koning <koen.koning@linux.intel.com>
---
 drivers/gpu/drm/scheduler/sched_fence.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/scheduler/sched_fence.c b/drivers/gpu/drm/scheduler/sched_fence.c
index 9391d6f0dc01..d10c1163719f 100644
--- a/drivers/gpu/drm/scheduler/sched_fence.c
+++ b/drivers/gpu/drm/scheduler/sched_fence.c
@@ -235,7 +235,7 @@ void drm_sched_fence_init(struct drm_sched_fence *fence,
 		       &fence->lock, entity->fence_context + 1, seq);
 }

-module_init(drm_sched_fence_slab_init);
+subsys_initcall(drm_sched_fence_slab_init);
 module_exit(drm_sched_fence_slab_fini);

 MODULE_DESCRIPTION("DRM GPU scheduler");
--
2.48.1

[PATCH v3 3/3] drm/drv: fix module_init() usage

[Koen Koning]

Use subsys_initcall() instead of module_init() (which compiles to
device_initcall() for built-ins) for drm_drv, so its initialization code
always runs before any (built-in) drivers.
This happened to work correctly so far due to the order of linking in
the Makefiles, but this should not be relied upon.

Cc: Matthew Auld <matthew.auld@intel.com>
Cc: Danilo Krummrich <dakr@kernel.org>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Maxime Ripard <mripard@kernel.org>
Cc: Thomas Zimmermann <tzimmermann@suse.de>
Cc: David Airlie <airlied@gmail.com>
Cc: Simona Vetter <simona@ffwll.ch>
Signed-off-by: Koen Koning <koen.koning@linux.intel.com>
---
 drivers/gpu/drm/drm_drv.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index 2915118436ce..db974f769692 100644
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -1271,5 +1271,5 @@ static int __init drm_core_init(void)
 	return ret;
 }

-module_init(drm_core_init);
+subsys_initcall(drm_core_init);
 module_exit(drm_core_exit);
--
2.48.1

Re: [PATCH v3 2/3] drm/sched: fix module_init() usage

[Greg KH]

On Thu, Feb 19, 2026 at 10:38:57PM +0100, Koen Koning wrote:
> Use subsys_initcall() instead of module_init() (which compiles to
> device_initcall() for built-ins) for sched_fence, so its initialization
> code always runs before any (built-in) drivers.
> This happened to work correctly so far due to the order of linking in
> the Makefiles, but this should not be relied upon.

The linking order of Makefiles should ALWAYS be relied on.  If that were
to somehow change, so many things will blow up.

But be careful, none of this fixes the issue if you use modules, so you
still have to have symbols resolving properly.


> 
> Fixes: 4983e48c85392 ("drm/sched: move fence slab handling to module init/exit")
> Cc: Chunming Zhou <david1.zhou@amd.com>
> Cc: Alex Deucher <alexander.deucher@amd.com>
> Cc: Lucas Stach <l.stach@pengutronix.de>
> Cc: Matthew Brost <matthew.brost@intel.com>
> Cc: Danilo Krummrich <dakr@kernel.org>
> Cc: Philipp Stanner <phasta@kernel.org>
> Cc: "Christian König" <ckoenig.leichtzumerken@gmail.com>
> Cc: Matthew Auld <matthew.auld@intel.com>
> Cc: stable@vger.kernel.org

Why is this for stable if it doesn't actually fix a real issue?

thanks,

greg k-h

Re: [PATCH v3 1/3] gpu/buddy: fix module_init() usage

[Greg KH]

On Thu, Feb 19, 2026 at 10:38:56PM +0100, Koen Koning wrote:
> Use subsys_initcall() instead of module_init() (which compiles to
> device_initcall() for built-ins) for buddy, so its initialization code
> always runs before any (built-in) drivers.
> This happened to work correctly so far due to the order of linking in
> the Makefiles, but this should not be relied upon.

Same here, Makefile order can always be relied on.

thanks,

greg k-h

Re: [PATCH v3 1/3] gpu/buddy: fix module_init() usage

[Danilo Krummrich]

On Fri Feb 20, 2026 at 7:06 AM CET, Greg KH wrote:
> On Thu, Feb 19, 2026 at 10:38:56PM +0100, Koen Koning wrote:
>> Use subsys_initcall() instead of module_init() (which compiles to
>> device_initcall() for built-ins) for buddy, so its initialization code
>> always runs before any (built-in) drivers.
>> This happened to work correctly so far due to the order of linking in
>> the Makefiles, but this should not be relied upon.
>
> Same here, Makefile order can always be relied on.

I want to point out that Koen's original patch fixed the Makefile order:

diff --git a/drivers/gpu/Makefile b/drivers/gpu/Makefile
index 5cd54d06e262..b4e5e338efa2 100644
--- a/drivers/gpu/Makefile
+++ b/drivers/gpu/Makefile
@@ -2,8 +2,9 @@
 # drm/tegra depends on host1x, so if both drivers are built-in care must be
 # taken to initialize them in the correct order. Link order is the only way
 # to ensure this currently.
+# Similarly, buddy must come first since it is used by other drivers.
+obj-$(CONFIG_GPU_BUDDY)	+= buddy.o
 obj-y			+= host1x/ drm/ vga/ tests/
 obj-$(CONFIG_IMX_IPUV3_CORE)	+= ipu-v3/
 obj-$(CONFIG_TRACE_GPU_MEM)		+= trace/
 obj-$(CONFIG_NOVA_CORE)		+= nova-core/
-obj-$(CONFIG_GPU_BUDDY)		+= buddy.o

He was then suggested to not rely on this and rather use subsys_initcall().

When I then came across the new patch using subsys_initcall() I made it worse; I
badly confused this with something else and gave a wrong advise -- sorry Koen!

(Of course, since this is all within the same subsystem, without any external
ordering contraints, Makefile order is sufficient.)

Re: [PATCH v3 1/3] gpu/buddy: fix module_init() usage

[Joel Fernandes]

> On Feb 20, 2026, at 5:17 AM, Danilo Krummrich <dakr@kernel.org> wrote:
> 
> On Fri Feb 20, 2026 at 7:06 AM CET, Greg KH wrote:
>>> On Thu, Feb 19, 2026 at 10:38:56PM +0100, Koen Koning wrote:
>>> Use subsys_initcall() instead of module_init() (which compiles to
>>> device_initcall() for built-ins) for buddy, so its initialization code
>>> always runs before any (built-in) drivers.
>>> This happened to work correctly so far due to the order of linking in
>>> the Makefiles, but this should not be relied upon.
>> 
>> Same here, Makefile order can always be relied on.
> 
> I want to point out that Koen's original patch fixed the Makefile order:
> 
> diff --git a/drivers/gpu/Makefile b/drivers/gpu/Makefile
> index 5cd54d06e262..b4e5e338efa2 100644
> --- a/drivers/gpu/Makefile
> +++ b/drivers/gpu/Makefile
> @@ -2,8 +2,9 @@
> # drm/tegra depends on host1x, so if both drivers are built-in care must be
> # taken to initialize them in the correct order. Link order is the only way
> # to ensure this currently.
> +# Similarly, buddy must come first since it is used by other drivers.
> +obj-$(CONFIG_GPU_BUDDY)    += buddy.o
> obj-y            += host1x/ drm/ vga/ tests/
> obj-$(CONFIG_IMX_IPUV3_CORE)    += ipu-v3/
> obj-$(CONFIG_TRACE_GPU_MEM)        += trace/
> obj-$(CONFIG_NOVA_CORE)        += nova-core/
> -obj-$(CONFIG_GPU_BUDDY)        += buddy.o
> 
> He was then suggested to not rely on this and rather use subsys_initcall().

I take the blame for the suggestion; however, I am not yet convinced it is a bad
idea. 
> 
> When I then came across the new patch using subsys_initcall() I made it worse; I
> badly confused this with something else and gave a wrong advise -- sorry Koen!
> 
> (Of course, since this is all within the same subsystem, without any external
> ordering contraints, Makefile order is sufficient.)

If we are still going to do the link ordering by reordering in the Makefile,
may I ask what is the drawback of doing the alternative - that is, not
relying on that (and its associated potential for breakage)?

Even if Makefile ordering can be relied on, why do we want to rely on it if
there is an alternative? Also module_init() compiles to device_initcall() for
built-ins and this is shared infra.

We use this technique in other code paths too, no? See
drivers/i2c/i2c-core-base.c:

  /* We must initialize early, because some subsystems register i2c drivers
   * in subsys_initcall() code, but are linked (and initialized) before i2c.
   */
  postcore_initcall(i2c_init);

If there is a drawback I am all ears but otherwise I would prefer the new
patch tbh. 

--
Joel Fernandes

Re: [PATCH v3 1/3] gpu/buddy: fix module_init() usage

[Greg KH]

On Fri, Feb 20, 2026 at 08:55:52AM -0500, Joel Fernandes wrote:
> > On Feb 20, 2026, at 5:17 AM, Danilo Krummrich <dakr@kernel.org> wrote:
> > 
> > On Fri Feb 20, 2026 at 7:06 AM CET, Greg KH wrote:
> >>> On Thu, Feb 19, 2026 at 10:38:56PM +0100, Koen Koning wrote:
> >>> Use subsys_initcall() instead of module_init() (which compiles to
> >>> device_initcall() for built-ins) for buddy, so its initialization code
> >>> always runs before any (built-in) drivers.
> >>> This happened to work correctly so far due to the order of linking in
> >>> the Makefiles, but this should not be relied upon.
> >> 
> >> Same here, Makefile order can always be relied on.
> > 
> > I want to point out that Koen's original patch fixed the Makefile order:
> > 
> > diff --git a/drivers/gpu/Makefile b/drivers/gpu/Makefile
> > index 5cd54d06e262..b4e5e338efa2 100644
> > --- a/drivers/gpu/Makefile
> > +++ b/drivers/gpu/Makefile
> > @@ -2,8 +2,9 @@
> > # drm/tegra depends on host1x, so if both drivers are built-in care must be
> > # taken to initialize them in the correct order. Link order is the only way
> > # to ensure this currently.
> > +# Similarly, buddy must come first since it is used by other drivers.
> > +obj-$(CONFIG_GPU_BUDDY)    += buddy.o
> > obj-y            += host1x/ drm/ vga/ tests/
> > obj-$(CONFIG_IMX_IPUV3_CORE)    += ipu-v3/
> > obj-$(CONFIG_TRACE_GPU_MEM)        += trace/
> > obj-$(CONFIG_NOVA_CORE)        += nova-core/
> > -obj-$(CONFIG_GPU_BUDDY)        += buddy.o
> > 
> > He was then suggested to not rely on this and rather use subsys_initcall().
> 
> I take the blame for the suggestion; however, I am not yet convinced it is a bad
> idea. 
> > 
> > When I then came across the new patch using subsys_initcall() I made it worse; I
> > badly confused this with something else and gave a wrong advise -- sorry Koen!
> > 
> > (Of course, since this is all within the same subsystem, without any external
> > ordering contraints, Makefile order is sufficient.)
> 
> If we are still going to do the link ordering by reordering in the Makefile,
> may I ask what is the drawback of doing the alternative - that is, not
> relying on that (and its associated potential for breakage)?
> 
> Even if Makefile ordering can be relied on, why do we want to rely on it if
> there is an alternative? Also module_init() compiles to device_initcall() for
> built-ins and this is shared infra.
> 
> We use this technique in other code paths too, no? See
> drivers/i2c/i2c-core-base.c:
> 
>   /* We must initialize early, because some subsystems register i2c drivers
>    * in subsys_initcall() code, but are linked (and initialized) before i2c.
>    */
>   postcore_initcall(i2c_init);
> 
> If there is a drawback I am all ears but otherwise I would prefer the new
> patch tbh. 

The "problem" is that the init levels are very "coarse", and the link
order is very specific.  You can play with init levels a lot, but what
happens if another driver also sets to the same init level, or an
earlier one to try to solve something that way?

So it can be a loosing battle for many things, choose the best and
simplest solution, but always remember, Makefile order matters, which is
what I was wanting to correct here.

thanks,

greg k-h

Claude review: gpu: fix module_init() usage

[Claude Code Review Bot]

Overall Series Review

Subject: gpu: fix module_init() usage
Author: Koen Koning <koen.koning@linux.intel.com>
Patches: 23
Reviewed: 2026-02-23T06:25:10.056015

---

This is a 3-patch series (v3) from Koen Koning that changes `module_init()` to `subsys_initcall()` in three places: the GPU buddy allocator, the DRM scheduler fence slab, and the DRM core driver init. The motivation is that `module_init()` compiles to `device_initcall()` for built-in code, and the initialization order within the same initcall level depends on Makefile link order. A recent refactoring that moved the buddy allocator from `drivers/gpu/drm/` to `drivers/gpu/` changed the link order, causing a NULL pointer dereference when xe was built-in.

The series itself is straightforward -- each patch is a one-line change from `module_init()` to `subsys_initcall()`. The patches are technically correct in that they will resolve the initialization ordering issue. However, the approach is controversial, as seen in the mailing list discussion. Greg KH pushed back, noting that Makefile link order is reliable and intentional, and that initcall levels are coarse -- if other subsystem infrastructure starts using `subsys_initcall()`, ordering conflicts between them would arise. Danilo Krummrich (who originally suggested the approach) later acknowledged he gave wrong advice and that Makefile ordering is sufficient within the same subsystem.

The core tension is between the v1 approach (fix Makefile ordering for buddy) and the v3 approach (promote three modules to `subsys_initcall`). The v1 approach fixes the actual regression with minimal blast radius. The v3 approach is more defensive but promotes infrastructure code to a different initcall level, which has its own ordering risks and creates an inconsistency with how other in-tree subsystem infrastructure handles this.

---
Generated by Claude Code Patch Reviewer

Claude review: gpu: Fix uninitialized buddy for built-in drivers

[Claude Code Review Bot]

Patch Review

> -module_init(gpu_buddy_module_init);
> +subsys_initcall(gpu_buddy_module_init);

This is the patch that fixes the actual regression. The buddy allocator must initialize before drivers that use it, and after the recent move from `drm/` to `gpu/`, the link order placed it after the DRM drivers. Using `subsys_initcall()` guarantees it runs before any `device_initcall()` (i.e., `module_init()` built-in) code.

Functionally correct. The `module_exit()` left as-is on the next line is fine -- `module_exit()` for built-in code is typically a no-op or runs at the corresponding exit stage.

The commit message now includes both Fixes tags as Danilo requested. The Fixes tag pointing to `ba110db8e1bc` ("gpu: Move DRM buddy allocator one level up (part two)") is debatable -- that commit exposed the latent bug by changing link order, but the underlying issue (using `module_init()` for infrastructure code) existed since the buddy allocator was moved out of i915. Including both tags is reasonable since `ba110db8e1bc` is what caused the actual regression.

Given Greg KH's feedback, the simpler v1 Makefile ordering fix may be the preferred approach for this patch. The Makefile ordering fix is a smaller change, more targeted, and follows the existing pattern used by `host1x`/`tegra` in the same Makefile.

---
Generated by Claude Code Patch Reviewer

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

[Claude Code Review Bot]

Patch Review

> -module_init(drm_sched_fence_slab_init);
> +subsys_initcall(drm_sched_fence_slab_init);

This fixes a latent issue. The scheduler fence slab init allocates a `kmem_cache` that must exist before any driver creates scheduler fences. Currently this works because `sched_fence.c` is linked within `drivers/gpu/drm/scheduler/` which is linked before the driver subdirectories. No actual regression has been reported.

The `Fixes:` tag points to `4983e48c85392` ("drm/sched: move fence slab handling to module init/exit") which is the commit that introduced the `module_init()` for the slab. The `Cc: stable` tag is questionable here since this has never caused an actual failure -- Greg KH explicitly asked why this is tagged for stable if it doesn't fix a real issue. The commit message says "This happened to work correctly so far due to the order of linking" which is accurate but doesn't justify stable backporting.

No code correctness issues in the change itself.

---
Generated by Claude Code Patch Reviewer

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

[Claude Code Review Bot]

Patch Review

> -module_init(drm_core_init);
> +subsys_initcall(drm_core_init);

This changes the DRM core initialization from `module_init()` (= `device_initcall()` when built-in) to `subsys_initcall()`. The DRM core init has existed with `module_init()` since before the git history, and has never caused an issue because `drm_drv.c` is linked early within `drivers/gpu/drm/`.

No `Fixes:` tag or `Cc: stable` is included, which is appropriate given the discussion and that this has never caused an issue.

However, `drm_core_init()` does quite a bit of work -- it registers device classes, creates debugfs entries, registers sysctl tables, initializes the panic handler, and more. Promoting this to `subsys_initcall()` means all of this runs earlier in boot. While unlikely to cause problems, it changes the ordering relative to other `subsys_initcall()` users that may have their own ordering assumptions. This is exactly the concern Greg KH raised about initcall levels being coarse.

There is also an ordering question between this patch and patch 1: if both buddy and drm_core use `subsys_initcall()`, their relative ordering within that level falls back to... Makefile link order. So for these two patches to work correctly relative to each other, the Makefile ordering still matters. This somewhat undermines the stated goal of not relying on Makefile ordering.

---
Generated by Claude Code Patch Reviewer