Received-SPF: pass (google.com: domain of linux-kernel+bounces-35452-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) client-ip=147.75.80.249;
Date: Tue, 23 Jan 2024 09:35:19 -0500
From: Steven Rostedt <rostedt@goodmis.org>
To: Christian =?UTF-8?B?S8O2bmln?= <christian.koenig@amd.com>
Cc: Dave Airlie <airlied@gmail.com>, "Bhardwaj, Rajneesh"
 <rajneesh.bhardwaj@amd.com>, Linus Torvalds
 <torvalds@linux-foundation.org>, LKML <linux-kernel@vger.kernel.org>, Felix
 Kuehling <Felix.Kuehling@amd.com>, dri-devel@lists.freedesktop.org, Fedor
 Pchelkin <pchelkin@ispras.ru>
Subject: Re: [BUG] BUG: kernel NULL pointer dereference at
 ttm_device_init+0xb4
Message-ID: <20240123093519.3ed37601@gandalf.local.home>
In-Reply-To: <c45df2c7-695b-42be-b893-a4f520d9e723@amd.com>
References: <20240122180605.28daf23a@gandalf.local.home>
	<20240122181547.16b029d6@gandalf.local.home>
	<20240122181901.05a3b9ab@gandalf.local.home>
	<CAHk-=whry+-JUDiiCkDkDn2TDg7SA5OvZpPbcQ_jkM_J5=ySdA@mail.gmail.com>
	<27c3d1e9-5933-47a9-9c33-ff8ec13f40d3@amd.com>
	<20240122203552.529eeb20@gandalf.local.home>
	<CAPM=9tyQ22nw4_u366EX=PnROYcWPD7ONRFpPEKxRvTZo0B4zQ@mail.gmail.com>
	<CAPM=9tyCN1ZhvCTjoKn-Yg5BhnrMae4E5Ci4_u7BZ2vv5gDnKw@mail.gmail.com>
	<20240122215200.1ec02a4a@gandalf.local.home>
	<c45df2c7-695b-42be-b893-a4f520d9e723@amd.com>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Tue, 23 Jan 2024 10:43:04 +0100
Christian K=C3=B6nig <christian.koenig@amd.com> wrote:

> While applying the fix a week ago I was under the impression that QXL=20
> doesn't use a device structure because it doesn't have one and so can't=20
> give anything meaningful for this parameter.
>=20
> If QXL does have a device structure and can provide it I would rather=20
> like to go down this route and make the device and with it the numa node=
=20
> mandatory for drivers to specify.

Then at a minimum my original fix should be applied. Perhaps with a warning
too. That is, I added at the beginning of that function:

	if (!dev)
		return -EINVAL;

Could have that be:

	if (WARN_ON_ONCE(!dev))
		return -EINVAL;

In any case, it should not cause the system to crash.

-- Steve