linux-kernel - Re: [PATCH] selftests/nolibc: always rebuild the sysroot when running a test

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: <20221026164825.GN5600@paulmck-ThinkPad-P17-Gen-1>
Date:   Wed, 26 Oct 2022 09:48:25 -0700
From:   "Paul E. McKenney" <paulmck@...nel.org>
To:     Willy Tarreau <w@....eu>
Cc:     linux-kselftest@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] selftests/nolibc: always rebuild the sysroot when
 running a test

On Wed, Oct 26, 2022 at 07:45:08AM +0200, Willy Tarreau wrote:
> Paul and myself got trapped a few times by not seeing the effects of
> applying a patch to the nolibc source code until a "make clean" was
> issued in the nolibc directory. It's particularly annoying when trying
> to confirm that a proposed patch really solves a problem (or that
> reverting it reintroduces the problem).
> 
> The reason for the sysroot not being rebuilt was that it can be quite
> slow. But in fact it's only slow after a "make clean" issued at the
> kernel's topdir, because it's the main "make headers" that can take a
> tens of seconds; as long as "usr/include" still contains headers, the
> "headers_install" phase is only a quick "rsync", and rebuilding the
> whole nolibc sysroot takes a bit less than one second, which is perfectly
> acceptable for a test, even more once the time lost caused by misleading
> results if factored in.
> 
> This patch marks the sysroot target as phony and starts by clearing
> the previous sysroot for the current architecture before reinstalling
> it. Thanks to this, applying a patch to nolibc makes the effect
> immediately visible to "make nolibc-test":
> 
>   $ time make -j -C tools/testing/selftests/nolibc nolibc-test
>   make: Entering directory '/k/tools/testing/selftests/nolibc'
>     MKDIR   sysroot/x86/include
>   make[1]: Entering directory '/k/tools/include/nolibc'
>   make[2]: Entering directory '/k'
>   make[2]: Leaving directory '/k'
>   make[2]: Entering directory '/k'
>     INSTALL /k/tools/testing/selftests/nolibc/sysroot/sysroot/include
>   make[2]: Leaving directory '/k'
>   make[1]: Leaving directory '/k/tools/include/nolibc'
>     CC      nolibc-test
>   make: Leaving directory '/k/tools/testing/selftests/nolibc'
> 
>   real    0m0.869s
>   user    0m0.716s
>   sys     0m0.149s
> 
> Cc: "Paul E. McKenney" <paulmck@...nel.org>
> Link: https://lore.kernel.org/all/20221021155645.GK5600@paulmck-ThinkPad-P17-Gen-1/
> Signed-off-by: Willy Tarreau <w@....eu>

Works like a champ with reverting and unreverting c9388e0c1c6c
("tools/nolibc/string: Fix memcmp() implementation"), thank you!!!

I have queued this.  I expect to push this into the next merge window,
thus avoiding the need to document the need for "make clean" in my
pull request.  ;-)

							Thanx, Paul

> ---
>  tools/testing/selftests/nolibc/Makefile | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/tools/testing/selftests/nolibc/Makefile b/tools/testing/selftests/nolibc/Makefile
> index 69ea659caca9..22f1e1d73fa8 100644
> --- a/tools/testing/selftests/nolibc/Makefile
> +++ b/tools/testing/selftests/nolibc/Makefile
> @@ -95,6 +95,7 @@ all: run
>  sysroot: sysroot/$(ARCH)/include
>  
>  sysroot/$(ARCH)/include:
> +	$(Q)rm -rf sysroot/$(ARCH) sysroot/sysroot
>  	$(QUIET_MKDIR)mkdir -p sysroot
>  	$(Q)$(MAKE) -C ../../../include/nolibc ARCH=$(ARCH) OUTPUT=$(CURDIR)/sysroot/ headers_standalone
>  	$(Q)mv sysroot/sysroot sysroot/$(ARCH)
> @@ -133,3 +134,5 @@ clean:
>  	$(Q)rm -rf initramfs
>  	$(call QUIET_CLEAN, run.out)
>  	$(Q)rm -rf run.out
> +
> +.PHONY: sysroot/$(ARCH)/include
> -- 
> 2.35.3
>