[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

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

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

[Joel Fernandes]

On 2/21/2026 12:44 AM, Greg KH wrote:
> 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.
Fair enough, the solution you are suggesting also sounds good to me.

thanks,

--
Joel Fernandes

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

[Koen Koning]

On Mon Feb 23, 2026 at 01:49 +0100, Joel Fernandes wrote:
> On 2/21/2026 12:44 AM, Greg KH wrote:
>> 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.
> Fair enough, the solution you are suggesting also sounds good to me.

Thanks that makes sense, then let's just stick to addressing the current 
regression with gpu/buddy in the drm-tip tree.

Joel, could you grab the v1 of this patchset (or the v2 with with 
subsys_initcall, either works) and try to get it applied to drm-tip? 
Since this is my first time submitting patches, I'm not really sure how 
to proceed from here, and it will probably be faster if you have a look.

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

[Danilo Krummrich]

On Mon Feb 23, 2026 at 12:17 PM CET, Koen Koning wrote:
> Thanks that makes sense, then let's just stick to addressing the current 
> regression with gpu/buddy in the drm-tip tree.

The patch should go into drm-misc-next.

> Joel, could you grab the v1 of this patchset (or the v2 with with 
> subsys_initcall, either works) and try to get it applied to drm-tip? 
> Since this is my first time submitting patches, I'm not really sure how 
> to proceed from here, and it will probably be faster if you have a look.

I think we should land your original v1; I don't know if Joel can push to
drm-misc-next, if not please let me know, I can pick it up then.

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

[Joel Fernandes]

> On Feb 23, 2026, at 6:20 AM, Danilo Krummrich <dakr@kernel.org> wrote:
> 
> On Mon Feb 23, 2026 at 12:17 PM CET, Koen Koning wrote:
>> Thanks that makes sense, then let's just stick to addressing the current
>> regression with gpu/buddy in the drm-tip tree.
> 
> The patch should go into drm-misc-next.
> 
>> Joel, could you grab the v1 of this patchset (or the v2 with with
>> subsys_initcall, either works) and try to get it applied to drm-tip?
>> Since this is my first time submitting patches, I'm not really sure how

Welcome to the dark side! ;-)

>> to proceed from here, and it will probably be faster if you have a look.
> 
> I think we should land your original v1; I don't know if Joel can push to
> drm-misc-next, if not please let me know, I can pick it up then.

Yes I do not have access to this tree, so over to Danilo ;-)

Thanks,
Joel

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

[Danilo Krummrich]

(Cc: Arun)

On Mon Feb 23, 2026 at 12:20 PM CET, Danilo Krummrich wrote:
> On Mon Feb 23, 2026 at 12:17 PM CET, Koen Koning wrote:
>> Thanks that makes sense, then let's just stick to addressing the current 
>> regression with gpu/buddy in the drm-tip tree.
>
> The patch should go into drm-misc-next.
>
>> Joel, could you grab the v1 of this patchset (or the v2 with with 
>> subsys_initcall, either works) and try to get it applied to drm-tip? 
>> Since this is my first time submitting patches, I'm not really sure how 
>> to proceed from here, and it will probably be faster if you have a look.
>
> I think we should land your original v1; I don't know if Joel can push to
> drm-misc-next, if not please let me know, I can pick it up then.

Actually, since GPU buddy has a separate maintainers entry, I will leave it to
Matthew and Arun.

(Cc'd you both on v1.)

Thanks,
Danilo

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

[David Airlie]

On Tue, Feb 24, 2026 at 8:31 AM Danilo Krummrich <dakr@kernel.org> wrote:
>
> (Cc: Arun)
>
> On Mon Feb 23, 2026 at 12:20 PM CET, Danilo Krummrich wrote:
> > On Mon Feb 23, 2026 at 12:17 PM CET, Koen Koning wrote:
> >> Thanks that makes sense, then let's just stick to addressing the current
> >> regression with gpu/buddy in the drm-tip tree.
> >
> > The patch should go into drm-misc-next.
> >
> >> Joel, could you grab the v1 of this patchset (or the v2 with with
> >> subsys_initcall, either works) and try to get it applied to drm-tip?
> >> Since this is my first time submitting patches, I'm not really sure how
> >> to proceed from here, and it will probably be faster if you have a look.
> >
> > I think we should land your original v1; I don't know if Joel can push to
> > drm-misc-next, if not please let me know, I can pick it up then.
>
> Actually, since GPU buddy has a separate maintainers entry, I will leave it to
> Matthew and Arun.
>
> (Cc'd you both on v1.)

Since I pushed the original damage, I've pushed this fix.

Dave.

[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

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

[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] gpu: Fix uninitialized buddy for built-in drivers

[Danilo Krummrich]

(Cc: Matthew, Arun)

On Fri Feb 13, 2026 at 4:20 PM CET, 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
>  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