Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Tue, 28 Apr 2020 23:55:54 +0200
From:   Peter Zijlstra <peterz@infradead.org>
To:     Josh Poimboeuf <jpoimboe@redhat.com>
Cc:     Arnd Bergmann <arnd@arndb.de>,
        the arch/x86 maintainers <x86@kernel.org>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        Kees Cook <keescook@chromium.org>
Subject: Re: Remaining randconfig objtool warnings, linux-next-20200428
Message-ID: <20200428215554.GA16027@hirez.programming.kicks-ass.net>
References: <CAK8P3a2qLJkokMGt48JRky=WUeAbJRuNmoD1oqfWdrGSC6y1LA@mail.gmail.com>
 <20200428161044.caamvx67t2z4t6vd@treble>
 <CAK8P3a0X4kMW1BQU6x9A2oo6i3-CMxi1h=0PhQgEbBtYWbJa9A@mail.gmail.com>
 <20200428203855.zapf6jhcp6mbft7i@treble>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20200428203855.zapf6jhcp6mbft7i@treble>
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Tue, Apr 28, 2020 at 03:38:55PM -0500, Josh Poimboeuf wrote:
> This one makes no sense to me.  It looks like the assembler is inserting
> a jump as part of the alignment padding???  WTH.
> 
> 0000000000000980 <common_spurious>:
>      980:	48 83 04 24 80       	addq   $0xffffffffffffff80,(%rsp)
>      985:	e8 00 00 00 00       	callq  98a <common_spurious+0xa>
> 			986: R_X86_64_PLT32	interrupt_entry-0x4
>      98a:	e8 00 00 00 00       	callq  98f <common_spurious+0xf>
> 			98b: R_X86_64_PLT32	smp_spurious_interrupt-0x4
>      98f:	eb 7e                	jmp    a0f <ret_from_intr>
>      991:	eb 6d                	jmp    a00 <common_interrupt>
>      993:	66 66 2e 0f 1f 84 00 	data16 nopw %cs:0x0(%rax,%rax,1)
>      99a:	00 00 00 00 
>      99e:	66 66 2e 0f 1f 84 00 	data16 nopw %cs:0x0(%rax,%rax,1)
>      9a5:	00 00 00 00 
>      9a9:	66 66 2e 0f 1f 84 00 	data16 nopw %cs:0x0(%rax,%rax,1)
>      9b0:	00 00 00 00 
>      9b4:	66 66 2e 0f 1f 84 00 	data16 nopw %cs:0x0(%rax,%rax,1)
>      9bb:	00 00 00 00 
>      9bf:	66 66 2e 0f 1f 84 00 	data16 nopw %cs:0x0(%rax,%rax,1)
>      9c6:	00 00 00 00 
>      9ca:	66 66 2e 0f 1f 84 00 	data16 nopw %cs:0x0(%rax,%rax,1)
>      9d1:	00 00 00 00 
>      9d5:	66 66 2e 0f 1f 84 00 	data16 nopw %cs:0x0(%rax,%rax,1)
>      9dc:	00 00 00 00 
>      9e0:	66 66 2e 0f 1f 84 00 	data16 nopw %cs:0x0(%rax,%rax,1)
>      9e7:	00 00 00 00 
>      9eb:	66 66 2e 0f 1f 84 00 	data16 nopw %cs:0x0(%rax,%rax,1)
>      9f2:	00 00 00 00 
>      9f6:	66 2e 0f 1f 84 00 00 	nopw   %cs:0x0(%rax,%rax,1)
>      9fd:	00 00 00 

binutils.git/gas/configure/tc-i386.c:i386_generate_nops

When there's too many NOPs (as here) it generates a JMP across the NOPS.
It makes some sort of sense, at some point executing NOPs is going to be
more expensive than a branch.. But shees..