On 22/04/2025 12:07, Lorenzo Stoakes wrote:
On Tue, Apr 22, 2025 at 12:03:08PM +0100, Ryan Roberts wrote:
On 22/04/2025 11:47, Lorenzo Stoakes wrote:
On Tue, Apr 22, 2025 at 11:37:57AM +0100, Ryan Roberts wrote:
[snip]
Hi Lorenzo,
I'm getting a test failure in v6.15-rc3 on arm64:
----8<---- # RUN guard_regions.shmem.uffd ... # guard-regions.c:1467:uffd:Expected ioctl(uffd, UFFDIO_REGISTER, ®) (-1) == 0 (0) # uffd: Test terminated by assertion # FAIL guard_regions.shmem.uffd not ok 45 guard_regions.shmem.uffd ----8<----
The ioctl is returning EINVAL.
Hm strange, that works fine <resists urge to say 'on my machine'> on x86-64. Is userfaultfd enabled in your config, to ask a silly question?
Yep, and the anon version of the test is passing, as are all the uffd tests.
It'd be odd for this to vary depending upon arch.
So a factor here is a _stupidity_ in the testing - does your system mount /tmp as tmpfs or an actual file system? As the test code unconditionally assumes /tmp is indeed going to get you a shmem file.
Ahh that's probably it. I'm on Ubuntu and it looks like /tmp is just a dir on the rootfs (XFS in my case).
Forcing a tmpfs to /tmp solved it.
Looks like uffd-unit-tests (see shmem_allocate_area()) is just using memfd. Would it be reasonable to take that approach? Or just use anon+shared via mmap?
Yeah could be either memfd or MAP_ANON | MAP_SHARED. I think I did it this way to make the code a little easier given all the variant stuff.
Unless you felt especially keen, I can add fixing this to my todos :)
I'm not keen, but if it lingers I might have a crack. Otherwise it's just more noise to ignore when I'm running tests...
Sorry about this! Entirely my fault, knew it wasn't ideal when I wrote it, but with test code sometimes you (perhaps incorrectly) tolerate things you wouldn't elsewhere...
No problem; I would have done the same thing. Given we know the root cause is a test issue, this is not a high priority issue from my perspective.
Cheers, Lorenzo
Thanks, Ryan
[snip]