lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <41923b80-55f4-44b6-bc59-60327e5308f4@redhat.com>
Date: Tue, 11 Mar 2025 20:53:02 +0100
From: David Hildenbrand <david@...hat.com>
To: Brendan Jackman <jackmanb@...gle.com>
Cc: Lorenzo Stoakes <lorenzo.stoakes@...cle.com>,
 Andrew Morton <akpm@...ux-foundation.org>, Shuah Khan <shuah@...nel.org>,
 Dev Jain <dev.jain@....com>, linux-mm@...ck.org,
 linux-kselftest@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3 08/10] selftests/mm: Skip gup_longerm tests on weird
 filesystems

On 11.03.25 14:00, Brendan Jackman wrote:
> On Thu, 6 Mar 2025 at 15:40, David Hildenbrand <david@...hat.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


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ