linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Kevin Brodsky <kevin.brodsky@arm.com>
To: Mark Brown <broonie@kernel.org>
Cc: linux-mm@kvack.org, linux-kselftest@vger.kernel.org,
	linux-kernel@vger.kernel.org,
	Andrew Morton <akpm@linux-foundation.org>,
	David Hildenbrand <david@kernel.org>,
	Lorenzo Stoakes <lorenzo.stoakes@oracle.com>,
	Ryan Roberts <ryan.roberts@arm.com>,
	Shuah Khan <shuah@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
	Yunsheng Lin <linyunsheng@huawei.com>
Subject: Re: [PATCH 1/4] selftests/mm: remove flaky header check
Date: Mon, 29 Dec 2025 16:40:26 +0100	[thread overview]
Message-ID: <9c97ac9c-b0df-42e7-84fc-7e0d986c7324@arm.com> (raw)
In-Reply-To: <682f64d0-353c-47bb-808b-eacc2d4d6c00@sirena.org.uk>

On 18/12/2025 15:25, Mark Brown wrote:
> On Thu, Dec 18, 2025 at 02:24:10PM +0100, Kevin Brodsky wrote:
>> On 17/12/2025 11:04, Mark Brown wrote:
>>> More generally building selftests with random older kernel versions
>>> isn't really something that's expected to be robust:
>> I suppose that Documentation/dev-tools/kselftest.rst talks about
>> *running* against older kernels, not *building* against them. That said,
> Yeah, running is fairly normal but huge swathes of the selftests won't
> build without current kernel headers and it's not an especially useful
> use of time to support that.
>
>> we are dealing with an out-of-tree kernel module here, so the two are
>> essentially the same... Yunsheng suggested an updated check that I think
>> is reasonable, maybe it is a reasonable compromise?
> Well, there's also the selection of KDIR which for some reason defaults
> to the installed kernel so we get:

Overall the kselftests tend to assume that we're building on the same
machine we'll run them, so at least that feels consistent. The same
default is used for most other out-of-tree kselftests modules
(livepatch, net/bench).

>   $ make -C tools/testing/selftests LLVM=1 ARCH=arm64 TARGETS=mm
>
>   Warning: missing page_frag_cache.h, please use a newer kernel. page_frag test will be skipped.

But yes if cross-compiling the default makes no sense and KDIR has to be
set explicitly.

> Your changelog says it'll work for an in tree build but I can't figure
> out how to do that (using the top level Makefile to recurse doesn't seem
> to DTRT either).  Having looked at this more I think the problem here is
> that the selection of KDIR is wrong, not the check.

I use KBUILD_OUTPUT=out and KDIR needs to be absolute, so:
KDIR=$PWD/out. I suppose for an in-tree build KDIR=$PWD would do the
right thing. But yes it's all very wonky.

Maybe the documentation should be updated to recommend setting KDIR
explicitly? Or maybe it could default to KDIR=$PWD or $(abspath
$(KBUILD_OUTPUT)) when cross-compiling?

- Kevin


  reply	other threads:[~2025-12-29 15:40 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-12-16 14:26 [PATCH 0/4] Various mm kselftests improvements/fixes Kevin Brodsky
2025-12-16 14:26 ` [PATCH 1/4] selftests/mm: remove flaky header check Kevin Brodsky
2025-12-17  3:18   ` Yunsheng Lin
2025-12-17  9:58     ` Kevin Brodsky
2025-12-18  7:21       ` Yunsheng Lin
2025-12-17 10:04   ` Mark Brown
2025-12-18 13:24     ` Kevin Brodsky
2025-12-18 14:25       ` Mark Brown
2025-12-29 15:40         ` Kevin Brodsky [this message]
2025-12-16 14:26 ` [PATCH 2/4] selftests/mm: pass down full CC and CFLAGS to check_config.sh Kevin Brodsky
2025-12-18  8:04   ` David Hildenbrand (Red Hat)
2025-12-16 14:26 ` [PATCH 3/4] selftests/mm: fix faulting-in code in pagemap_ioctl test Kevin Brodsky
2025-12-16 14:56   ` Ryan Roberts
2025-12-16 15:11     ` Kevin Brodsky
2025-12-18  8:05     ` David Hildenbrand (Red Hat)
2025-12-18 13:18       ` Kevin Brodsky
2025-12-19  8:29         ` David Hildenbrand (Red Hat)
2025-12-29 11:46           ` Kevin Brodsky
2025-12-16 14:26 ` [PATCH 4/4] selftests/mm: fix exit code in pagemap_ioctl Kevin Brodsky
2025-12-16 14:58   ` Ryan Roberts
2025-12-17 10:08   ` Mark Brown
2025-12-18 13:20     ` Kevin Brodsky
2025-12-18  8:07   ` David Hildenbrand (Red Hat)

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=9c97ac9c-b0df-42e7-84fc-7e0d986c7324@arm.com \
    --to=kevin.brodsky@arm.com \
    --cc=akpm@linux-foundation.org \
    --cc=broonie@kernel.org \
    --cc=david@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linyunsheng@huawei.com \
    --cc=lorenzo.stoakes@oracle.com \
    --cc=pabeni@redhat.com \
    --cc=ryan.roberts@arm.com \
    --cc=shuah@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox