linux-kernel - Re: [PATCH] xarray: port tests to kunit

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <zlcagbwyskb4nkl4usbq4foc4vjcau3exp42zpfsl5b4tabr7u@o42mpfcsfygr>
Date: Thu, 30 Jan 2025 09:05:29 -0500
From: "Liam R. Howlett" <Liam.Howlett@...cle.com>
To: Geert Uytterhoeven <geert@...ux-m68k.org>
Cc: Sidhartha Kumar <sidhartha.kumar@...cle.com>, akpm@...ux-foundation.org,
        christophe.leroy@...roup.eu, justinstitt@...gle.com,
        linux-kernel@...r.kernel.org, linux-m68k@...ts.linux-m68k.org,
        linuxppc-dev@...ts.ozlabs.org, llvm@...ts.linux.dev,
        maddy@...ux.ibm.com, morbo@...gle.com, mpe@...erman.id.au,
        nathan@...nel.org, naveen@...nel.org, ndesaulniers@...gle.com,
        npiggin@...il.com, Matthew Wilcox <willy@...radead.org>,
        linux-mm@...ck.org
Subject: Re: [PATCH] xarray: port tests to kunit

* Geert Uytterhoeven <geert@...ux-m68k.org> [250130 08:26]:
> Hi Liam,
> 
> On Thu, 30 Jan 2025 at 13:52, Liam R. Howlett <Liam.Howlett@...cle.com> wrote:
> > * Geert Uytterhoeven <geert@...ux-m68k.org> [250130 03:21]:
> > > On Wed, 29 Jan 2025 at 23:26, Liam R. Howlett <Liam.Howlett@...cle.com> wrote:
> > > > I've never used the kunit testing of xarray and have used the userspace
> > > > testing instead, so I can't speak to the obscure invocation as both
> > > > commands seem insanely long and obscure to me.
> > >
> > > The long and obscure command line is a red herring: a simple
> > > "modprobe test_xarray" is all it takes...
> >
> > That command worked before too...
> 
> Exactly, great!
> 
> > > > You should look at the userspace testing (that this broke) as it has
> > > > been really useful in certain scenarios.
> > >
> > > BTW, how do I even build tools/testing/radix-tree?
> > > "make tools/help" doesn't show the radix-tree test.
> > > "make tools/all" doesn't seem to try to build it.
> > > Same for "make kselftest-all".
> >
> > make
> 
> Where?
> > > BTW, how do I even build tools/testing/radix-tree?
                                ^^^^^^^^^^^^^^^^^^^^^^^
> 
> > Or look at the make file and stop guessing.  Considering how difficult
> 
> There is no Makefile referencing tools/testing/radix-tree or the
> radix-tree subdir. That's why I asked...
> 
> Oh, I am supposed to run make in tools/testing/radix-tree/?
> What a surprise!
> 
> Which is a pain when building in a separate output directory, as you
> cannot just do "make -C tools/testing/radix-tree" there, but have to
> type the full "make -C tools/testing/radix-tree O=..." (and optionally
> ARCH=... and CROSS_COMPILE=...; oh wait, these are ignored :-( in the
> source directory instead...

I'll await your patch to link all this together.  Please Cc the authors.


> 
> If these tests are not integrated into the normal build system (see
> also [1]), I am not so surprised the auto-builders don't build them,
> and breakages are introduced...
> 
> > it is to get m68k to build, you should probably know how to read a
> > makefile.
> 
> Like all other kernel cross-compilation? Usually you don't even have
> to know where your cross-compiler is living:
> 
>     make ARCH=m68k

Ignoring that I had to make a config - which asked challenging
questions...

And ignoring the steps to get m68k compiler...

> > > When trying the above, and ignoring failures due to missing packages
> > > on my host:
> > >   - there are several weird build errors,
> > >   - this doesn't play well with O=,
> > >   - lots of scary warnings when building for 32-bit,
> > >   - ...
> > >

In file included from ./include/linux/sched.h:12,
                 from arch/m68k/kernel/asm-offsets.c:15:
./arch/m68k/include/asm/current.h:7:30: error: invalid register name for ‘current’
    7 | register struct task_struct *current __asm__("%a2");


> 
> > > At least the kunit tests build (and run[1] ;-) most of the time...
> >
> > Do they?  How about you break something in xarray and then try to boot
> > the kunit, or try to boot to load that module.
> 
> If you break the kernel beyond the point of booting, you can indeed
> not run any test modules...

Which is extremely easy when you are changing code that runs so early in
the boot.

My code found a compiler issue because it's the first function that
returns a boolean.  This is stupid.

> 
> Which does _not_ mean the userspace tests are not useful, and that I
> approve breaking the userspace tests...

Perfect, let's revert the patch then.

This is such a waste of time.