Re: [PATCH v3 08/10] selftests/mm: Skip gup_longerm tests on weird filesystems

[David Hildenbrand <david@redhat.com>]

On 11.03.25 14:00, Brendan Jackman wrote:
> On Thu, 6 Mar 2025 at 15:40, David Hildenbrand <david@redhat.com> wrote:
>> Yes, just skip 9pfs early, and mention in the commit message that 9pfs
>> has a history of being probematic with "use-after-unlink", maybe
>> mentioning the discussion I linked above.
>>
>> Maybe something like this would work?
>>
>> diff --git a/tools/testing/selftests/mm/gup_longterm.c b/tools/testing/selftests/mm/gup_longterm.c
>> index 9423ad439a614..349e40d3979f2 100644
>> --- a/tools/testing/selftests/mm/gup_longterm.c
>> +++ b/tools/testing/selftests/mm/gup_longterm.c
>> @@ -47,6 +47,16 @@ static __fsword_t get_fs_type(int fd)
>>           return ret ? 0 : fs.f_type;q
>>    }
>>
>> +static bool fs_is_problematic(__fsword_t fs_type)
>> +{
>> +       switch (fs_type) {
>> +       case V9FS_MAGIC:
>> +               return false;
>> +       default:
>> +               return true;
>> +       }
>> +}
> 
> Ugh, some fun discoveries.
> 
> 1. fstatfs() seems to have the same bug as ftruncate() i.e. it doesn't
> work on unlinked files on 9pfs. This can be worked around by calling
> it on the parent directory, but...

oO what a piece of bad software :(

> 
> 2. 9pfs seems to pass the f_type through from the host. So you can't
> detect it this way anyway.
> 
> [3. I guess overlayfs & friends would also be an issue here although
> that doesn't affect my usecase.]
> 
> Anyway, I think we would have to scrape /proc/mounts to do this :(
> 

The question I am asking myself: is this a 9pfs design bug or is it a 
9pfs hypervisor bug. Because we shouldn't try too hard to work around 
hypervisor bugs.

Which 9pfs implementation are you using in the hypervisor?

> I think the proper way to deal with this is something like what I've
> described here[0]. I.e. have a central facility as part of kselftest
> to detect relevant characteristics of the platform. This logic could
> be written in a proper programming language or in Bash, then the
> relevant info could be passed in via the environment or whatever (e.g.
> export KSFT_SYSENV_cwd_ftruncate_unlinked_works=1).
> 
> [0] https://lore.kernel.org/all/Z8WJEsEAwUPeMkqy@google.com/
> 
> But, to find an immediate way to get these tests working, I think we
> are stuck with just peeking at errno and guessing for the time being.



-- 
Cheers,

David / dhildenb