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.