[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <efa81d0d-5e26-a3e4-a8d5-ec0d3f6499ee@redhat.com>
Date: Tue, 11 Feb 2020 07:51:40 +0000
From: Julien Thierry <jthierry@...hat.com>
To: Josh Poimboeuf <jpoimboe@...hat.com>, x86@...nel.org
Cc: linux-kernel@...r.kernel.org, Borislav Petkov <bp@...e.de>,
Peter Zijlstra <peterz@...radead.org>
Subject: Re: [PATCH 1/3] objtool: Fail the kernel build on fatal errors
On 2/10/20 6:32 PM, Josh Poimboeuf wrote:
> When objtool encounters a fatal error, it usually means the binary is
> corrupt or otherwise broken in some way. Up until now, such errors were
> just treated as warnings which didn't fail the kernel build.
>
> However, objtool is now stable enough that if a fatal error is
> discovered, it most likely means something is seriously wrong and it
> should fail the kernel build.
>
> Note that this doesn't apply to "normal" objtool warnings; only fatal
> ones.
>
> Suggested-by: Borislav Petkov <bp@...e.de>
> Signed-off-by: Josh Poimboeuf <jpoimboe@...hat.com>
Reviewed-by: Julien Thierry <jthierry@...hat.com>
> ---
> tools/objtool/check.c | 12 +++++++++---
> 1 file changed, 9 insertions(+), 3 deletions(-)
>
> diff --git a/tools/objtool/check.c b/tools/objtool/check.c
> index b6da413bcbd6..61d2d1877fd2 100644
> --- a/tools/objtool/check.c
> +++ b/tools/objtool/check.c
> @@ -2509,8 +2509,14 @@ int check(const char *_objname, bool orc)
> out:
> cleanup(&file);
>
> - /* ignore warnings for now until we get all the code cleaned up */
> - if (ret || warnings)
> - return 0;
> + if (ret < 0) {
> + /*
> + * Fatal error. The binary is corrupt or otherwise broken in
> + * some way, or objtool itself is broken. Fail the kernel
> + * build.
> + */
> + return ret;
> + }
> +
> return 0;
> }
>
--
Julien Thierry
Powered by blists - more mailing lists