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: <3240f4b5-081b-4075-851a-7d1cd86f4333@redhat.com>
Date:   Mon, 11 Dec 2023 17:32:16 +0100
From:   David Hildenbrand <david@...hat.com>
To:     Suren Baghdasaryan <surenb@...gle.com>,
        Mark Brown <broonie@...nel.org>
Cc:     akpm@...ux-foundation.org, viro@...iv.linux.org.uk,
        brauner@...nel.org, shuah@...nel.org, aarcange@...hat.com,
        lokeshgidra@...gle.com, peterx@...hat.com, ryan.roberts@....com,
        hughd@...gle.com, mhocko@...e.com, axelrasmussen@...gle.com,
        rppt@...nel.org, willy@...radead.org, Liam.Howlett@...cle.com,
        jannh@...gle.com, zhangpeng362@...wei.com, bgeffon@...gle.com,
        kaleshsingh@...gle.com, ngeoffray@...gle.com, jdduke@...gle.com,
        linux-mm@...ck.org, linux-fsdevel@...r.kernel.org,
        linux-kernel@...r.kernel.org, linux-kselftest@...r.kernel.org,
        kernel-team@...roid.com, John Hubbard <jhubbard@...dia.com>,
        Peter Zijlstra <peterz@...radead.org>
Subject: Re: [PATCH v6 5/5] selftests/mm: add UFFDIO_MOVE ioctl test

On 11.12.23 17:15, Suren Baghdasaryan wrote:
> On Mon, Dec 11, 2023 at 4:24 AM Mark Brown <broonie@...nel.org> wrote:
>>
>> On Mon, Dec 11, 2023 at 01:03:27PM +0100, David Hildenbrand wrote:
>>> On 11.12.23 12:15, Mark Brown wrote:
>>
>>>> This is linux-next.  I pasted the commands used to build and sent links
>>>> to a full build log in the original report.
>>
>>> Probably also related to "make headers-install":
>>
>>> https://lkml.kernel.org/r/20231209020144.244759-1-jhubbard@nvidia.com
>>
>>> The general problem is that some mm selftests are currently not written in
>>> way that allows them to compile with old linux headers. That's why the build
>>> fails if "make headers-install" was not executed, but it does not fail if
>>> "make headers-install" was once upon a time executed, but the headers are
>>> outdated.
>>
>> Oh, it's obviously the new headers not being installed.  The builds
>> where I'm seeing the problem (my own and KernelCI's) are all fresh
>> containers so there shouldn't be any stale headers lying around.
> 
> Ok, I was updating my headers and that's why I could not reproduce it.
> David, should the test be modified to handle old linux headers
> (disable the new tests #ifndef _UFFDIO_MOVE or some other way)?

That's an open question: do we want to be able to build selftests 
against any host headers, and not the in-tree headers that have to be 
manually installed and dirty the git tree?

One obvious drawbacks is that we'll have to deal with all that using a 
bunch of #ifdef, and the tests that will be built+run will depend on the 
host headers.

Especially the letter is relevant I think: Our upstream testing won't be 
able to build+run tests that rely on new upstream features. But that's 
what some key benefit of these selftests, and being able to run them 
automatically on a bunch of different combinations upstream.

Further, the tests are closely related to the given kernel version, they 
are not some completely separate tests.


Moving the the (MM?) selftests to a separate repository would make the 
decision easier: just like in QEMU etc, we'd simply pull in a headers 
update and only build against these archived headers.

So I see the options:

(1) Rely on installing the proper in-tree headers. Build will fail if
     that is not happening.

(2) Make the tests build with any host headers.

(3) Regularly archive the required headers in the selftest directory
     like external projects like QEMU do.


(3) avoids dirtying the tree as a "make headers_install" would, but it 
also means that each test that makes use of new uapi has to update the 
relevant headers (what people working on QEMU are used to).


-- 
Cheers,

David / dhildenb

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ