Received-SPF: pass (google.com: domain of linux-kernel+bounces-210045-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) client-ip=2604:1380:45d1:ec00::1;
Precedence: bulk
MIME-Version: 1.0
References: <20240608021023.176027-1-jhubbard@nvidia.com> <CABi2SkVoNyXLrfU71gnv1qVUAADpUmFXiDoKKPc54MLb5JpB+Q@mail.gmail.com>
 <a8f9d4e2-8a12-4e5d-bd22-9c92955135f4@nvidia.com> <CABi2SkU8=tjWhD-e=OdiVr+YeU+BZZLB_vMfkNb-VWpbP2xcng@mail.gmail.com>
 <95005e7c-3705-48c5-8ee2-3d9b0688fcbc@nvidia.com>
In-Reply-To: <95005e7c-3705-48c5-8ee2-3d9b0688fcbc@nvidia.com>
From: Jeff Xu <jeffxu@chromium.org>
Date: Tue, 11 Jun 2024 07:13:44 -0700
Message-ID: <CABi2SkXN1jsnrawCwADxWB0Whj+e-m7+9c=5Lo3gY5CYVrnpkQ@mail.gmail.com>
Subject: Re: [PATCH 0/5] cleanups, fixes, and progress towards avoiding "make headers"
To: John Hubbard <jhubbard@nvidia.com>
Cc: Andrew Morton <akpm@linux-foundation.org>, Shuah Khan <shuah@kernel.org>, 
	Andrei Vagin <avagin@google.com>, Axel Rasmussen <axelrasmussen@google.com>, 
	Christian Brauner <brauner@kernel.org>, David Hildenbrand <david@redhat.com>, Kees Cook <kees@kernel.org>, 
	Kent Overstreet <kent.overstreet@linux.dev>, "Liam R . Howlett" <Liam.Howlett@oracle.com>, 
	Muhammad Usama Anjum <usama.anjum@collabora.com>, Peter Xu <peterx@redhat.com>, 
	Rich Felker <dalias@libc.org>, linux-mm@kvack.org, linux-kselftest@vger.kernel.org, 
	LKML <linux-kernel@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Mon, Jun 10, 2024 at 11:26=E2=80=AFPM John Hubbard <jhubbard@nvidia.com>=
 wrote:
>
> On 6/10/24 9:45 PM, Jeff Xu wrote:
> > On Mon, Jun 10, 2024 at 9:34=E2=80=AFPM John Hubbard <jhubbard@nvidia.c=
om> wrote:
> >> On 6/10/24 9:21 PM, Jeff Xu wrote:
> >>> Hi
> >>>
> >>>
> >>> On Fri, Jun 7, 2024 at 7:10=E2=80=AFPM John Hubbard <jhubbard@nvidia.=
com> wrote:
> >>>>
> >>>> Eventually, once the build succeeds on a sufficiently old distro, th=
e
> >>>> idea is to delete $(KHDR_INCLUDES) from the selftests/mm build, and =
then
> >>>> after that, from selftests/lib.mk and all of the other selftest buil=
ds.
> >>>>
> >>>> For now, this series merely achieves a clean build of selftests/mm o=
n a
> >>>> not-so-old distro: Ubuntu 23.04:
> >>>>
> >>>> 1. Add __NR_mseal.
> >>>>
> >>>> 2. Add fs.h, taken as usual from a snapshot of ./usr/include/linux/f=
s.h
> >>>> after running "make headers". This is how we have agreed to do this =
sort
> >>>> of thing, see [1].
> >>>>
> >>> What is the "official" way to build selftests/mm ?
> >>
> >>   From Documentation/dev-tools/kselftest.rst, it is:
> >>
> >>     $ make headers
> >>     $ make -C tools/testing/selftests
> >>
> >>> I tried a few ways, but it never worked, i.e. due to head missing.
> >>
> >> You are correct. Today's rules require "make headers" first. But
> >> I'm working on getting rid of that requirement, because it causes
> >> problems for some people and situations.
> >>
> >> (Even worse is the follow-up rule, in today's documentation,
> >> that tells us to *run* the selftests from within Make! This
> >> is just madness.
> >
> > That is hilarious! :)
>
> :)
>
> >
> >>   Because the tests need to run as root in
> >> many cases. And Make will try to rebuild if necessary...thus
> >> filling your tree full of root-owned files...but that's for
> >> another time.)
> >>
> >>>
> >>> 1>
> >>> cd tools/testing/selftests/mm
> >>> make
> >>>
> >>> migration.c:10:10: fatal error: numa.h: No such file or directory
> >>>      10 | #include <numa.h>
> >>>         |          ^~~~~~~~
> >>> compilation terminated.
> >>>
> >>> 2>
> >>> make headers
> >>> make -C tools/testing/selftests
> >>>
> >>> make[1]: Entering directory
> >>> '/usr/local/google/home/jeffxu/mm/tools/testing/selftests/mm'
> >>>     CC       migration
> >>> migration.c:10:10: fatal error: numa.h: No such file or directory
> >>>      10 | #include <numa.h>
> >>>
> >>
> >> Well, actually, for these, one should install libnuma-dev and
> >> numactl (those are Ubuntu package names. Arch Linux would be:
> >> numactl).
> >>
> >> I think. The idea is: use system headers if they are there, and
> >> local kernel tree header files if the items are so new that they
> >> haven't made it to $OLDEST_DISTO_REASONABLE.
> >>
> >> Something like that.
> >>
> > But I don't want to install random packages if possible.
>
> Well...keep in mind that it's not really random. If a test program
> requires numa.h, it's typically because it also links against libnuma,
> which *must* be supplied by the distro if you want to build. Because
> it doesn't come with the kernel, of course.
>
Agreed.

> So what you're really saying is that you'd like to build and run
> whatever you can at the moment--the build should soldier on past
> failures as much as possible.
>
Yes. That is what I meant. It would be a convenient feature.

> >
> > Can makefile rule continue to the next target in case of failure though=
 ?
>
> That could be done, in general. The question is if that's really what
> we want, or should want. Maybe...
>
> > right now it stopped  at migration.c , if it continues to the next targ=
et, then
> > I don't  need to use gcc to manually build mseal_test.
>
> Let me take a peek at it in the morning.
>
>
>
> thanks,
> --
> John Hubbard
> NVIDIA
>