Re: [PATCH 3/4] tools/selftests: expand all guard region tests to file-backed

[Ryan Roberts <ryan.roberts@arm.com>]

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, &reg) (-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]