linux-kernel - Re: [PATCH] tools: fix annoying "mkdir -p ..." logs when building tools in parallel

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

Message-ID: <CAD=FV=V19pgzU8NSyWwHSEs85kU_Fbofcn8uJVj-TE2DNKfUHQ@mail.gmail.com>
Date: Tue, 18 Mar 2025 09:41:20 -0700
From: Doug Anderson <dianders@...omium.org>
To: Masahiro Yamada <masahiroy@...nel.org>
Cc: Frank Binns <frank.binns@...tec.com>, Matt Coster <matt.coster@...tec.com>, 
	linux-kernel@...r.kernel.org, Arnaldo Carvalho de Melo <acme@...hat.com>, 
	Borislav Petkov <bp@...e.de>, Nathan Chancellor <nathan@...nel.org>, Nicolas Schier <nicolas@...sle.eu>, 
	bpf@...r.kernel.org, linux-kbuild@...r.kernel.org, 
	Stephen Boyd <swboyd@...omium.org>
Subject: Re: [PATCH] tools: fix annoying "mkdir -p ..." logs when building
 tools in parallel

Hi,

On Mon, Feb 10, 2025 at 4:30 PM Masahiro Yamada <masahiroy@...nel.org> wrote:
>
> When CONFIG_OBJTOOL=y or CONFIG_DEBUG_INFO_BTF=y, parallel builds
> show awkward "mkdir -p ..." logs.
>
>   $ make -j16
>     [ snip ]
>   mkdir -p /home/masahiro/ref/linux/tools/objtool && make O=/home/masahiro/ref/linux subdir=tools/objtool --no-print-directory -C objtool
>   mkdir -p /home/masahiro/ref/linux/tools/bpf/resolve_btfids && make O=/home/masahiro/ref/linux subdir=tools/bpf/resolve_btfids --no-print-directory -C bpf/resolve_btfids
>
> Defining MAKEFLAGS=<value> on the command line wipes out command line
> switches from the resultant MAKEFLAGS definition, even though the command
> line switches are active. [1]
>
> The first word of $(MAKEFLAGS) is a possibly empty group of characters
> representing single-letter options that take no argument. However, this
> breaks if MAKEFLAGS=<value> is given on the command line.
>
> The tools/ and tools/% targets set MAKEFLAGS=<value> on the command
> line, which breaks the following code in tools/scripts/Makefile.include:
>
>     short-opts := $(firstword -$(MAKEFLAGS))
>
> If MAKEFLAGS really needs modification, it should be done through the
> environment variable, as follows:
>
>     MAKEFLAGS=<value> $(MAKE) ...
>
> That said, I question whether modifying MAKEFLAGS is necessary here.
> The only flag we might want to exclude is --no-print-directory, as the
> tools build system changes the working directory. However, people might
> find the "Entering/Leaving directory" logs annoying.
>
> I simply removed the offending MAKEFLAGS=.
>
> [1]: https://savannah.gnu.org/bugs/?62469
>
> Fixes: a50e43332756 ("perf tools: Honor parallel jobs")
> Signed-off-by: Masahiro Yamada <masahiroy@...nel.org>
> ---
>
>  Makefile | 9 ++-------
>  1 file changed, 2 insertions(+), 7 deletions(-)

I happened to sync up to mainline today and noticed that my build was
broken. I bisected it to this change and reverting this change fixes
my build on mainline.

In my case I'm building in a ChromeOS environment and using clang as
my compiler. I'm also cross-compiling an arm64 kernel on x86 host.
...but the pure mainline kernel should work there. Presumably the
environment is a bit different compared to the typical one, though?

The error comes up when doing a clean build and the first error messages are:

In file included from libbpf.c:36:
.../tools/include/uapi/linux/bpf_perf_event.h:14:21: error: field has
incomplete type
      'bpf_user_pt_regs_t' (aka 'struct user_pt_regs')
   14 |         bpf_user_pt_regs_t regs;
      |                            ^
.../tools/include/../../arch/arm64/include/uapi/asm/bpf_perf_event.h:7:16:
note: forward
      declaration of 'struct user_pt_regs'
    7 | typedef struct user_pt_regs bpf_user_pt_regs_t;
      |                ^

btf_dump.c:1860:10: error: cast to smaller integer type 'uintptr_t'
(aka 'unsigned int') from 'const void *'
      [-Werror,-Wvoid-pointer-to-int-cast]
 1860 |         return ((uintptr_t)data) % alignment == 0;
      |                 ^~~~~~~~~~~~~~~
btf_dump.c:2045:4: error: format specifies type 'ssize_t' (aka 'long')
but the argument has type 'ssize_t' (aka 'int')
      [-Werror,-Wformat]
 2044 |                 pr_warn("unexpected elem size %zd for array
type [%u]\n",
      |                                               ~~~
      |                                               %d
 2045 |                         (ssize_t)elem_size, id);
      |                         ^~~~~~~~~~~~~~~~~~
./libbpf_internal.h:171:52: note: expanded from macro 'pr_warn'
  171 | #define pr_warn(fmt, ...)       __pr(LIBBPF_WARN, fmt, ##__VA_ARGS__)
      |                                                   ~~~    ^~~~~~~~~~~


I don't have time to dig right now, but I figured I'd at least post in
case the problem is obvious to someone else.


-Doug