linux-kernel - Re: [PATCH v2 4/4] 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: <961a62b0-d0d3-40db-8008-61c634172ca6@sirena.org.uk>
Date: Thu, 5 Jun 2025 18:38:36 +0100
From: Mark Brown <broonie@...nel.org>
To: Lorenzo Stoakes <lorenzo.stoakes@...cle.com>
Cc: Andrew Morton <akpm@...ux-foundation.org>,
	Shuah Khan <shuah@...nel.org>, David Hildenbrand <david@...hat.com>,
	linux-mm@...ck.org, linux-kselftest@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 4/4] selftests/mm: Fix test result reporting in
 gup_longterm

On Thu, Jun 05, 2025 at 06:09:09PM +0100, Lorenzo Stoakes wrote:
> On Thu, Jun 05, 2025 at 05:42:55PM +0100, Mark Brown wrote:

> > > Better to do all of these formating fixes and maintain the _same behaviour_ then
> > > separately tackle whether or not we should skip.

> > I'm confused, that's generally the opposite of the standard advice for
> > the kernel - usually it's fixes first, then deal with anything cosmetic
> > or new?

> I mean the crux is that the 'cosmetic' changes also included a 'this might
> break things' change.

No, the cosmetic changes are separate.  I'm just saying I have a small
bunch of stuff based on David's feedback to send out after the merge
window.

> I'm saying do the cosmetic things in _isolation_, or fix the brokenness
> before doing the whole lot.

Some subsystems will complain if you send anything that isn't urgent
during the merge window, this looked more like an "I suppose you could
configure the kernel that way" problem than a "people will routinely run
into this" one, I was expecting it (or something) to go in as a fix but
that it was safer to wait for -rc1 to send.

> > > Obviously the better option would be to somehow determine if hugetlb is
> > > available in advance (of course, theoretically somebody could come in and
> > > reserve pages but that's not veyr likely).

> > The tests do enumerate the set of available hugepage sizes at runtime
> > (see the loop in run_test_case()) but detect_hugetlb_page_sizes() just
> > looks in /sys/kernel/mm/hugepages/ for subdirectories and doesn't look
> > inside those directories to see if there are actually any huge pages
> > available for the huge page sizes advertised.  There's probably utility
> > in at least a version of that function that checks.

> Right yes, I mean obviously this whole thing is a mess already that's not
> your fault, and ideally we'd have some general way of looking this up
> across _all_ tests and just switch things on/off accordingly.

That is at least library code so it'd get the three tests that use it,
though possibly one of them actually wants the current behaviour for
some reason?

> There's a whole Pandora's box about what the tests should assume/not and
> yeah. Anyway. Maybe leave it closed for now :)

It's separate, yeah.  It'd also be good to document what you need to
enable all the tests somewhere as well - there's the config fragment
already which is good, but you also at least need a bunch of command
line options to set up huge pages and enable secretmem.

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