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 <[email protected]>
Cc: Dave Airlie <[email protected]>
Cc: [email protected]
Tested-by: Peter Senna Tschudin <[email protected]>
Signed-off-by: Koen Koning <[email protected]>
---
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,
