Received-SPF: pass (google.com: domain of linux-kernel+bounces-74925-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:40f1:3f00::1 as permitted sender) client-ip=2604:1380:40f1:3f00::1;
Date: Wed, 21 Feb 2024 15:41:49 +0100
From: Maxime Ripard <mripard@kernel.org>
To: Christian =?utf-8?B?S8O2bmln?= <christian.koenig@amd.com>
Cc: Bagas Sanjaya <bagasdotme@gmail.com>, 
	Erhard Furtner <erhard_f@mailbox.org>, Linux DRI Development <dri-devel@lists.freedesktop.org>, 
	Huang Rui <ray.huang@amd.com>, Maarten Lankhorst <maarten.lankhorst@linux.intel.com>, 
	Thomas Zimmermann <tzimmermann@suse.de>, David Airlie <airlied@gmail.com>, 
	Daniel Vetter <daniel@ffwll.ch>, Karolina Stolarek <karolina.stolarek@intel.com>, 
	"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>, Andrew Morton <akpm@linux-foundation.org>, 
	Zi Yan <ziy@nvidia.com>, Linux Kernel Mailing List <linux-kernel@vger.kernel.org>, 
	Linux Memory Management List <linux-mm@kvack.org>, Brendan Higgins <brendan.higgins@linux.dev>, 
	David Gow <davidgow@google.com>, Rae Moar <rmoar@google.com>, linux-kselftest@vger.kernel.org, 
	kunit-dev@googlegroups.com
Subject: Re: Running ttm_device_test leads to list_add corruption. prev->next
 should be next (ffffffffc05cd428), but was 6b6b6b6b6b6b6b6b.
 (prev=ffffa0b1a5c034f0) (kernel 6.7.5)
Message-ID: <uddqboamqcnxwvnud5gmkkm4igvxj67xc2zw52iex5ahljtlb4@2e7ydoplg6rt>
References: <20240219230116.77b8ad68@yea>
 <ZdRtDOhQGQUm5X4d@archie.me>
 <9cdf0baa-f544-4fa8-bee3-568b790527cc@amd.com>
 <4xggxtkk44m3xcfucbougtuhr66s2pc7tilpnju7xnyw45facb@odsrpqp57kiz>
 <535f9089-b988-45ac-b3f3-a7d593861723@amd.com>
Precedence: bulk
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="54nvwbweshimitzn"
Content-Disposition: inline
In-Reply-To: <535f9089-b988-45ac-b3f3-a7d593861723@amd.com>


--54nvwbweshimitzn
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hi Christian,

On Tue, Feb 20, 2024 at 04:03:57PM +0100, Christian K=F6nig wrote:
> Am 20.02.24 um 15:56 schrieb Maxime Ripard:
> > On Tue, Feb 20, 2024 at 02:28:53PM +0100, Christian K=F6nig wrote:
> > > [SNIP]
> > > This kunit test is not meant to be run on real hardware, but rather j=
ust as
> > > stand a long kunit tests within user mode linux. I was assuming that =
it
> > > doesn't even compiles on bare metal.
> > >=20
> > > We should probably either double check the kconfig options to prevent
> > > compiling it or modify the test so that it can run on real hardware a=
s well.
> > I think any cross-compiled kunit run will be impossible to differentiate
> > from running on real hardware. We should just make it work there.
>=20
> The problem is what the unit test basically does is registering and
> destroying a dummy device to see if initializing and tear down of the glo=
bal
> pools work correctly.
>=20
> If you run on real hardware and have a real device

I assume you mean a real DRM device backed by TTM here, right?

> additionally to the dummy device the reference count of the global
> pool never goes down to zero and so it is never torn down.
>=20
> So running this test just doesn't make any sense in that environment.
> Any idea how to work around that?

I've added David, Brendan and Rae in Cc.

To sum up the problem, your tests are relying on the mock device created
to run a kunit test to be the sole DRM device in the system. But if you
compile a kernel with the kunit tests enabled and boot that on a real
hardware, then that assumption might not be true anymore and things
break apart. Is that a fair description?

If so, maybe we could detect if it's running under qemu or UML (if
that's something we can do in the first place), and then extend
kunit_attributes to only run that test if it's in a simulated
environment.

Maxime

--54nvwbweshimitzn
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iHUEABYKAB0WIQRcEzekXsqa64kGDp7j7w1vZxhRxQUCZdYLrAAKCRDj7w1vZxhR
xdN5AP0a2qM2svXKCp42Du8M5ceOwqA0Ro4VNIqTjfP71wm84wEAqBc0BtfBVIUp
WX9cTT9QW23f/XVrxJCgQkZF0UJvlg8=
=cUKm
-----END PGP SIGNATURE-----

--54nvwbweshimitzn--