linux-kernel - Re: [PATCH v3 08/10] selftests/mm: Skip gup

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: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <86f91949-9972-4b0f-903e-cfa36bcd9926@redhat.com>
Date: Fri, 14 Mar 2025 22:19:36 +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 14.03.25 16:56, Brendan Jackman wrote:
>>> Even if it's a bug in QEMU, I think it is worth working around this
>>> one way or another. QEMU by far the most practical way to run these
>>> tests, and virtme-ng is probably the most popular/practical way to do
>>> that.
>>
>> I'm afraid yes. Although allocating temp files form 9pfs is rather ...
>> weird. :) One would assume that /tmp is usually backed by tmpfs. But well, a
>> disto can do what it wants.
> 
> Ah yeah but these tests also use mkstemp() in the CWD i.e. the
> location of run_vmtests.sh, it isn't /tmp that is causing this at the
> moment. (At some point I thought I was hitting the issue there too,
> but I think I was mistaken, like just not reading the test logs
> properly or something).

Ah, yes run_with_local_tmpfile() ... jep, I wrote that test, now my 
memory comes back; we wanted to test with actual filesystems (e.g., 
ext4, xfs) easily.

> 
>>> I think even if we are confident it's just a bunch of broken
>>> code that isn't even in Linux, it's pragmatic to spend a certain
>>> amount of energy on having green tests there.
>>>
>>
>> Yeah, we're trying ...
>>
>>> (Also, this f_type thing might be totally intentional specified
>>> filesystem behaviour, I don't know).
>>
>> I assume it's broken in various ways to mimic that you are a file system
>> which you are not.
>>
>> Your approach is likely the easiest approach to deal with this 9pfs crap.
>>
>> Can you document in the code+description better what we learned, and why we
>> cannot even trust f_type with crappy 9pfs?
> 
> Sure, I will be more verbose about it.
> 
> I've already sent v4 here:
> 
> https://lore.kernel.org/all/20250311-mm-selftests-v4-7-dec210a658f5@google.com/
> 
> So I will wait and see if there are any comments on the v4, if there
> are I'll spin the extra commentary into v5 otherwise send it as a
> followup, does that sound OK?


You can just ask Andrew to fixup the comment or description in a reply 
to the v4 patch. Andrew will let you know if he prefers a resend.

Thanks!


-- 
Cheers,

David / dhildenb