Re: [PATCH v6 5/5] selftests/mm: add UFFDIO_MOVE ioctl test

From: David Hildenbrand
Date: Mon Dec 11 2023 - 11:32:26 EST


On 11.12.23 17:15, Suren Baghdasaryan wrote:
On Mon, Dec 11, 2023 at 4:24 AM Mark Brown <broonie@xxxxxxxxxx> 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@xxxxxxxxxx

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