linux-kernel - Re: [PATCH] selftests/mm: Fix test result reporting in gup

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <f6cf8a99-48b0-46f7-b11b-574d1544fa24@redhat.com>
Date: Thu, 22 May 2025 10:42:50 +0200
From: David Hildenbrand <david@...hat.com>
To: Mark Brown <broonie@...nel.org>
Cc: Andrew Morton <akpm@...ux-foundation.org>, Shuah Khan <shuah@...nel.org>,
 linux-mm@...ck.org, linux-kselftest@...r.kernel.org,
 linux-kernel@...r.kernel.org
Subject: Re: [PATCH] selftests/mm: Fix test result reporting in gup_longterm

On 21.05.25 20:48, Mark Brown wrote:
> On Mon, May 19, 2025 at 03:28:47PM +0200, David Hildenbrand wrote:
>> On 16.05.25 20:07, Mark Brown wrote:
>>> On Fri, May 16, 2025 at 04:12:08PM +0200, David Hildenbrand wrote:
> 
>>> [Converting to kselftet_harness]
>>>>> That'd certainly work, though doing that is more surgery on the test
>>>>> than I personally have the time/enthusiasm for right now.
> 
>>>> Same over here.
> 
>>>> But probably if we touch it, we should just clean it up right away. Well,
>>>> if we decide that that is the right cleanup. (you mention something like that
>>>> in your patch description :)
> 
>>> OTOH there's something to be said for just making incremental
>>> improvements in the tests where we can, they tend not to get huge
>>> amounts of love in general which means perfect can very much be the
> 
>> I would agree if it would be a handful of small changes.
> 
>> But here we are already at
> 
>>   1 file changed, 107 insertions(+), 56 deletions(-)
> 
> So, I did have a brief poke at this which confirmed my instinct that
> blocking a fix for this (and the other similarly structured tests like
> cow) seems disproportionate.

Thanks for giving it a try.

> 
> The biggest issue is the configuration of fixtures, the harness really
> wants the set of test variants to be fixed at compile time (see the
> FIXTURE_ macros) but we're covering the dynamically discovered list of
> huge page sizes.

Yes.

Probably, one might be able to revert the logic: instead of running each 
test for each size, run each size for each test: then, the tests are 
fixed and would be covering all available sizes in a single logical test.

I agree that that really is a bigger rework. Let me take a look at your 
original patch later (fairly busy today, please poke me if I forget).

-- 
Cheers,

David / dhildenb