netdev - Re: [PATCH bpf-next] tools build: propagate build failures from tools/build/Makefile.build

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]

Date:   Sun, 2 Aug 2020 18:11:06 +0200
From:   Jiri Olsa <jolsa@...hat.com>
To:     Andrii Nakryiko <andriin@...com>
Cc:     bpf@...r.kernel.org, netdev@...r.kernel.org, ast@...com,
        daniel@...earbox.net, andrii.nakryiko@...il.com,
        kernel-team@...com, Jiri Olsa <jolsa@...nel.org>,
        Arnaldo Carvalho de Melo <acme@...hat.com>
Subject: Re: [PATCH bpf-next] tools build: propagate build failures from
 tools/build/Makefile.build

On Thu, Jul 30, 2020 at 07:42:44PM -0700, Andrii Nakryiko wrote:
> The '&&' command seems to have a bad effect when $(cmd_$(1)) exits with
> non-zero effect: the command failure is masked (despite `set -e`) and all but
> the first command of $(dep-cmd) is executed (successfully, as they are mostly
> printfs), thus overall returning 0 in the end.

nice, thanks for digging into this,
any idea why is the failure masked?

Acked-by: Jiri Olsa <jolsa@...hat.com>

jirka

> 
> This means in practice that despite compilation errors, tools's build Makefile
> will return success. We see this very reliably with libbpf's Makefile, which
> doesn't get compilation error propagated properly. This in turns causes issues
> with selftests build, as well as bpftool and other projects that rely on
> building libbpf.
> 
> The fix is simple: don't use &&. Given `set -e`, we don't need to chain
> commands with &&. The shell will exit on first failure, giving desired
> behavior and propagating error properly.
> 
> Cc: Jiri Olsa <jolsa@...nel.org>
> Cc: Arnaldo Carvalho de Melo <acme@...hat.com>
> Fixes: 275e2d95591e ("tools build: Move dependency copy into function")
> Signed-off-by: Andrii Nakryiko <andriin@...com>
> ---
> 
> I'm sending this against bpf-next tree, given libbpf is affected enough for me
> to debug this fun problem that no one seemed to notice (or care, at least) in
> almost 5 years. If there is a better kernel tree, please let me know.
> 
>  tools/build/Build.include | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/tools/build/Build.include b/tools/build/Build.include
> index 9ec01f4454f9..585486e40995 100644
> --- a/tools/build/Build.include
> +++ b/tools/build/Build.include
> @@ -74,7 +74,8 @@ dep-cmd = $(if $(wildcard $(fixdep)),
>  #                   dependencies in the cmd file
>  if_changed_dep = $(if $(strip $(any-prereq) $(arg-check)),         \
>                    @set -e;                                         \
> -                  $(echo-cmd) $(cmd_$(1)) && $(dep-cmd))
> +                  $(echo-cmd) $(cmd_$(1));                         \
> +                  $(dep-cmd))
>  
>  # if_changed      - execute command if any prerequisite is newer than
>  #                   target, or command line has changed
> -- 
> 2.24.1
>