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: <e7cb18c4-fed3-4fa5-bb51-228f2b018ce9@sirena.org.uk>
Date: Wed, 21 May 2025 19:48:35 +0100
From: Mark Brown <broonie@...nel.org>
To: David Hildenbrand <david@...hat.com>
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 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.  

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.  I'm not seeing a super tasteful way to deal with that
mismatch of assumptions, the most obvious thing is to switch to having a
static list of possible huge page sizes and skipping if that size isn't
there but there's an awful lot of potential huge page sizes most of
which won't appear on any given system.  That'd be both ugly code and
bad ergonomics for anyone actively working with the test.

Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)