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)

From: "Christian König" <christian.koenig@amd.com>
To: Maxime Ripard <mripard@kernel.org>
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>
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)
Date: Tue, 20 Feb 2024 16:03:57 +0100	[thread overview]
Message-ID: <535f9089-b988-45ac-b3f3-a7d593861723@amd.com> (raw)
In-Reply-To: <4xggxtkk44m3xcfucbougtuhr66s2pc7tilpnju7xnyw45facb@odsrpqp57kiz>

[-- Attachment #1: Type: text/plain, Size: 1103 bytes --]

Am 20.02.24 um 15:56 schrieb Maxime Ripard:
> On Tue, Feb 20, 2024 at 02:28:53PM +0100, Christian König wrote:
>> [SNIP]
>> This kunit test is not meant to be run on real hardware, but rather just as
>> stand a long kunit tests within user mode linux. I was assuming that it
>> doesn't even compiles on bare metal.
>>
>> 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 as 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.

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 
global pools work correctly.

If you run on real hardware and have a real device additionally to the 
dummy device the reference count of the global pool never goes down to 
zero and so it is never torn down.

So running this test just doesn't make any sense in that environment. 
Any idea how to work around that?

Thanks,
Christian.

>
> Maxime

[-- Attachment #2: Type: text/html, Size: 1852 bytes --]