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

[Lorenzo Stoakes <lorenzo.stoakes@oracle.com>]

On Thu, Jun 05, 2025 at 05:15:51PM +0100, Mark Brown wrote:
> On Thu, Jun 05, 2025 at 05:00:49PM +0100, Lorenzo Stoakes wrote:
>
> > This seems to be causing tests to fail rather than be skipped if hugetlb
> > isn't configured. I bisected the problem to this patch so it's definitely
> > changed how things are handled (though of course it might just be
> > _revealing_ some previously existing bug in this test...).
>
> > Using a couple of tests as an example:
>
> > Before this patch:
>
> > # [RUN] R/O longterm GUP-fast pin in MAP_PRIVATE file mapping ... with memfd hugetlb (2048 kB)
> > # memfd_create() failed (Cannot allocate memory)
> > not ok 39 R/O longterm GUP-fast pin in MAP_PRIVATE file mapping ... with memfd hugetlb (2048 kB)
> > # [RUN] R/O longterm GUP-fast pin in MAP_PRIVATE file mapping ... with memfd hugetlb (1048576 kB)
> > # memfd_create() failed (Cannot allocate memory)
> > not ok 40 R/O longterm GUP-fast pin in MAP_PRIVATE file mapping ... with memfd hugetlb (1048576 kB)
>
> 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 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.

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

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

Anyway, mm-new accepts patches during the merge window, one of the advantages of
having this separated out from mm-unstable, so there's no reason not to send
something now.