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 :) 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... Cheers, Lorenzo > > Thanks, > Ryan > [snip]
