Re: [PATCH v2 4/4] selftests/mm: Fix test result reporting in gup_longterm

[Mark Brown <broonie@kernel.org>]

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

On Thu, Jun 05, 2025 at 05:26:05PM +0100, Lorenzo Stoakes wrote:
> On Thu, Jun 05, 2025 at 05:15:51PM +0100, Mark Brown wrote:

> > That's the thing with memfd being special and skipping on setup failure
> > that David mentioned, I've got a patch as part of the formatting series
> > I was going to send after the merge window.

> where did he mention this?

I can't remember off hand, sorry.

> I mean I'd argue that making a test that previously worked now fail due to how
> somebody's set up their system is a reason not to merge that patch.

Well, it's a bit late now given that this is in Linus' tree and actually
it turns out this was the only update for gup_longterm so I just rebased
it onto Linus' tree and kicked off my tests.

> 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?

> 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.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]