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

[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