From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id DC920237707 for ; Fri, 20 Feb 2026 06:06:14 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771567575; cv=none; b=WPVGuK3WeV1KVqU+MJnLNVFDgxO+2BkWFnz+foT8J0CSWHfgrT7Ldce8fmfUBEnpfctF7NYy4dTYnGBux63yDu3mF8xw1Q0jruB+ZeSUWGc1ntAxqgMmaj4l9rJVwmp4hPKhmrHnv1wPI+ueA/uKu/s/D5Bn4n8Ae4BN64z100U= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771567575; c=relaxed/simple; bh=K4J5kwrWG6Klaz0TWaWDwYqm9sura75BmlC5zDrxEic=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=FdOkANVIv/657hJ1TEK26brvkdiyqR18OkeHXBFgpcCNsfU9vaT01oFg7vnn2eO4VvekhN8LzMyAxtQHTv7OBTrOUFrfuzzq8/s7PSaGoP6VSU15TbmCnMYen0CwUV7UutbDtJpoIIFz1GPZj5XqkHzKwLxx/4QeMw6R+YUjwtI= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b=ysOn/ZQp; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b="ysOn/ZQp" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 276E2C116D0; Fri, 20 Feb 2026 06:06:14 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1771567574; bh=K4J5kwrWG6Klaz0TWaWDwYqm9sura75BmlC5zDrxEic=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=ysOn/ZQp+kpa+h+su/QdYoLZ9kPZfUB18kZEl0AJHkHijbDfpt0RdrOevuMjaVu81 l1PvMbTSwjKI86Bd9q1r25ghHZKdw5pWXi95I7G6jOF1Qg4KM01QWvN+HICS2qXn1A 3Z1DD67/W89jg84AxoptP8KaqH7t077dKwYf5hlM= Date: Fri, 20 Feb 2026 07:06:11 +0100 From: Greg KH To: Koen Koning Cc: dri-devel@lists.freedesktop.org, intel-xe@lists.freedesktop.org, Joel Fernandes , Matthew Auld , Danilo Krummrich , Chunming Zhou , Alex Deucher , Lucas Stach , Matthew Brost , Philipp Stanner , Christian =?iso-8859-1?Q?K=F6nig?= , stable@vger.kernel.org Subject: Re: [PATCH v3 2/3] drm/sched: fix module_init() usage Message-ID: <2026022007-radiator-schnapps-e557@gregkh> References: <20260216111902.110286-1-koen.koning@linux.intel.com> <20260219213858.370675-1-koen.koning@linux.intel.com> <20260219213858.370675-3-koen.koning@linux.intel.com> Precedence: bulk X-Mailing-List: stable@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit 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 > Cc: Alex Deucher > Cc: Lucas Stach > Cc: Matthew Brost > Cc: Danilo Krummrich > Cc: Philipp Stanner > Cc: "Christian König" > Cc: Matthew Auld > Cc: stable@vger.kernel.org Why is this for stable if it doesn't actually fix a real issue? thanks, greg k-h