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.
signature.asc
Description: PGP signature
