On 03/06/2025 5:12 am, Andrew Morton wrote:
> On Tue,  3 Jun 2025 02:22:32 +0300 Khaled Elnaggar 
> <khaledelnaggarli...@gmail.com> wrote:
> 
>> The hugevm tests 'charge_reserved_hugetlb.sh' and 
>> 'hugetlb_reparenting_test.sh'
>> depend on the 'write_to_hugetlbfs' binary to simulate writes to hugetlbfs
>> while checking reservations asynchronously in the background.
>>
>> When this binary is missing (e.g., excluded from the build), these tests hang
>> for up to 180 seconds. During this time, run_vmtests.sh is eventually killed
>> due to timeout, aborting all subsequent tests.
>>
>> This patch skips these tests if the binary is not found, preventing delays
>> and ensuring that the test suite runs to completion.
> 
> OK, but why is write_to_hugetlbfs missing?  If we're in a situation
> where we _could_ run it then we _should_ run it!  The user wants to
> test stuff so we should test as much as we can.
> So I'm thinking that it would be preferable to make sure the dang thing
> is there?
> 

Totally agree, let me try to explain how I understand the issue.

The write_to_hugetlbfs binary is built from selftests/mm/Makefile,
lines 136–142. It is only compiled if ARCH matches one of the explicitly
listed 64-bit architectures:


```
   ifneq (,$(filter $(ARCH),arm64 mips64 parisc64 powerpc riscv64 s390x sparc64 
x86_64 s390))
   TEST_GEN_FILES += va_high_addr_switch
   ifneq ($(ARCH),riscv64)
   TEST_GEN_FILES += virtual_address_range
   endif
   TEST_GEN_FILES += write_to_hugetlbfs
   endif
```

However, when the MM selftests are run from the kernel’s top-level Makefile,
(root directory for example:

  make defconfig
  sudo make kselftest TARGETS=mm


ARCH is resolved as x86, even on an x86_64 machine (Debian in my case),
ARCH=x86 is the reason why the binary gets excluded from the build system.

As far as I understand, the top-level Makefile normalizes both
i.86 and x86_64 to x86 for ARCH variable:

Makfile: lines: 383,403
        383:include $(srctree)/scripts/subarch.include
        403:ARCH                ?= $(SUBARCH)

scripts/subarch.include: line: 7
        7:SUBARCH := $(shell uname -m | sed -e s/i.86/x86/ -e s/x86_64/x86/ \

This mapping probably makes sense for selecting the correct arch/ directory
(since we have arch/x86, not arch/x86_64) for top-level Makefile.

But the mm selftests Makefile expects ARCH to differentiate between x86 and 
x86_64
to decide whether to build certain binaries.
As a result, the 64-bit-only binaries like write_to_hugetlbfs are skipped
during build, yet still expected at runtime (by run_vmtests.sh).

That's why this whole issue of the missing executable does not happen when
ran from selftests/mm using something like:

  sudo make -C tools/testing/selftests/mm

Because then selftests/mm/Makefile arch detection rus as intended.

You're right — the proper fix is to improve how we propagate architecture
information from the top-level Makefile to selftests.
But since that's a larger change (and possibly beyond what I can safely
attempt at this point), this patch is just a targeted workaround to
avoid test stalls when the binary is missing.

I hope I haven't gone completely wrong with this analysis, happy to improve
or revise it further if needed.


Reply via email to