From: Greg KH <gregkh@linuxfoundation.org>
To: Koen Koning <koen.koning@linux.intel.com>
Cc: dri-devel@lists.freedesktop.org, intel-xe@lists.freedesktop.org,
"Joel Fernandes" <joelagnelf@nvidia.com>,
"Matthew Auld" <matthew.auld@intel.com>,
"Danilo Krummrich" <dakr@kernel.org>,
"Chunming Zhou" <david1.zhou@amd.com>,
"Alex Deucher" <alexander.deucher@amd.com>,
"Lucas Stach" <l.stach@pengutronix.de>,
"Matthew Brost" <matthew.brost@intel.com>,
"Philipp Stanner" <phasta@kernel.org>,
"Christian König" <ckoenig.leichtzumerken@gmail.com>,
stable@vger.kernel.org
Subject: Re: [PATCH v3 2/3] drm/sched: fix module_init() usage
Date: Fri, 20 Feb 2026 07:06:11 +0100 [thread overview]
Message-ID: <2026022007-radiator-schnapps-e557@gregkh> (raw)
In-Reply-To: <20260219213858.370675-3-koen.koning@linux.intel.com>
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
prev parent reply other threads:[~2026-02-20 6:06 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20260216111902.110286-1-koen.koning@linux.intel.com>
[not found] ` <20260219213858.370675-1-koen.koning@linux.intel.com>
2026-02-19 21:38 ` [PATCH v3 1/3] gpu/buddy: fix module_init() usage Koen Koning
2026-02-20 6:06 ` Greg KH
2026-02-20 10:17 ` Danilo Krummrich
2026-02-20 13:55 ` Joel Fernandes
2026-02-21 5:44 ` Greg KH
2026-02-23 0:49 ` Joel Fernandes
2026-02-23 11:17 ` Koen Koning
2026-02-23 11:20 ` Danilo Krummrich
2026-02-23 13:42 ` Joel Fernandes
2026-02-23 22:31 ` Danilo Krummrich
2026-02-24 3:41 ` David Airlie
2026-02-19 21:38 ` [PATCH v3 2/3] drm/sched: " Koen Koning
2026-02-20 6:06 ` Greg KH [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2026022007-radiator-schnapps-e557@gregkh \
--to=gregkh@linuxfoundation.org \
--cc=alexander.deucher@amd.com \
--cc=ckoenig.leichtzumerken@gmail.com \
--cc=dakr@kernel.org \
--cc=david1.zhou@amd.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=intel-xe@lists.freedesktop.org \
--cc=joelagnelf@nvidia.com \
--cc=koen.koning@linux.intel.com \
--cc=l.stach@pengutronix.de \
--cc=matthew.auld@intel.com \
--cc=matthew.brost@intel.com \
--cc=phasta@kernel.org \
--cc=stable@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox