On Thu, 6 Mar 2025 at 15:40, David Hildenbrand <david@xxxxxxxxxx> 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...
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 :(
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@xxxxxxxxxx/
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.
