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.
