linux-kernel - Re: objtool warning breaks build for fs/dlm/lock.o

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: <20200508094518.GW5298@hirez.programming.kicks-ass.net>
Date:   Fri, 8 May 2020 11:45:18 +0200
From:   Peter Zijlstra <peterz@...radead.org>
To:     Josh Poimboeuf <jpoimboe@...hat.com>
Cc:     Arnd Bergmann <arnd@...db.de>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: objtool warning breaks build for fs/dlm/lock.o

On Thu, May 07, 2020 at 06:29:41PM -0500, Josh Poimboeuf wrote:
> On Wed, May 06, 2020 at 04:07:25PM +0200, Arnd Bergmann wrote:
> > Hi,
> > 
> > During randconfig testing with clang-10 I came across a number
> > of additional objtool warnings, I'll send another mail about those
> > when I have collected more information and some object files.
> > 
> > This one sticks out however, as objtool returns an error code that
> > stops the build:
> 
> > fs/dlm/lock.o: warning: objtool: __receive_convert_reply()+0x1e5: can't find jump dest instruction at .text+0xcaa7
> 
> Thanks for sending the patch for this one.  Objtool always gets confused
> by new compiler versions, I really think we need to revert
>  
>   644592d32837 ("objtool: Fail the kernel build on fatal errors")
> 
> because objtool is never going to be reliable enough such that we can be
> confident that failing the build is the right thing to do.

So on the one hand I agree. We're forever playing catch up with the
compilers, and as I said earlier, objtool generating an error has the
very unfortunate effect of the actual .o file getting deleted by the
build system, which is all sorts of annoying when you then want to
figure out what objtool got upset about.

So, yes, we probably should revert that.

OTOH, if we don't break the build, people are going to continue to
ignore objtool warnings/errors when they writes new code.