objtool warnings on 4.14-stable/gcc-7.3.0

objtool warnings on 4.14-stable/gcc-7.3.0

[Arnd Bergmann]

Hi Josh,

I recently did some randconfig testing with a plain 4.14-stable kernel
and gcc-7.3.0, and came across three distinct objtool warnings:

drivers/misc/lkdtm_bugs.o: warning: objtool:
lkdtm_CORRUPT_LIST_ADD()+0x15: return with modified stack frame

crypto/asymmetric_keys/x509_cert_parser.o: warning: objtool:
x509_note_pkey_algo()+0xa4: sibling call from callable instruction
with modified stack frame

drivers/infiniband/hw/bnxt_re/qplib_fp.o: warning: objtool:
bnxt_qplib_poll_cq()+0x106: sibling call from callable instruction
with modified stack frame

It's likely that this is the complete set at the moment, I saw each
one multiple times,
but did not see any others. I'll reply with the respective object
files for your reference,
in case these are so far unknown to you. There are only a handful of randconfig
warnings we see overall in the kernel these days (at least on x86 and arm64), so
even if they are false-positive, it would be great to get rid of the
output so we can
do randconfig testing on 4.14.y and treat any output from 'make -s' as
a regression.
I did not check

With gcc-8, things are looking very differently, and we still get an
endless supply of
similar warnings.

        Arnd

Re: objtool warnings on 4.14-stable/gcc-7.3.0

[Josh Poimboeuf]

On Wed, Feb 14, 2018 at 04:11:15PM +0100, Arnd Bergmann wrote:
> Hi Josh,
> 
> I recently did some randconfig testing with a plain 4.14-stable kernel
> and gcc-7.3.0, and came across three distinct objtool warnings:
> 
> drivers/misc/lkdtm_bugs.o: warning: objtool:
> lkdtm_CORRUPT_LIST_ADD()+0x15: return with modified stack frame
> 
> crypto/asymmetric_keys/x509_cert_parser.o: warning: objtool:
> x509_note_pkey_algo()+0xa4: sibling call from callable instruction
> with modified stack frame
> 
> drivers/infiniband/hw/bnxt_re/qplib_fp.o: warning: objtool:
> bnxt_qplib_poll_cq()+0x106: sibling call from callable instruction
> with modified stack frame
> 
> It's likely that this is the complete set at the moment, I saw each
> one multiple times,
> but did not see any others. I'll reply with the respective object
> files for your reference,
> in case these are so far unknown to you. There are only a handful of randconfig
> warnings we see overall in the kernel these days (at least on x86 and arm64), so
> even if they are false-positive, it would be great to get rid of the
> output so we can
> do randconfig testing on 4.14.y and treat any output from 'make -s' as
> a regression.
> I did not check

The third one has been fixed upstream with

  99ce7962d52d ("objtool: Fix switch-table detection")

... so we should put that one into stable.

I don't recall seeing the other two, I'll look into them.

> With gcc-8, things are looking very differently, and we still get an
> endless supply of
> similar warnings.

Yeah, I haven't forgotten about GCC 8, it just fell off my plate thanks
to spectre/meltdown.  It's still on my TODO list...

-- 
Josh

Re: objtool warnings on 4.14-stable/gcc-7.3.0

[Josh Poimboeuf]

On Wed, Feb 14, 2018 at 04:24:12PM -0600, Josh Poimboeuf wrote:
> On Wed, Feb 14, 2018 at 04:11:15PM +0100, Arnd Bergmann wrote:
> > Hi Josh,
> > 
> > I recently did some randconfig testing with a plain 4.14-stable kernel
> > and gcc-7.3.0, and came across three distinct objtool warnings:
> > 
> > drivers/misc/lkdtm_bugs.o: warning: objtool:
> > lkdtm_CORRUPT_LIST_ADD()+0x15: return with modified stack frame

While this is probably an objtool bug, the code is very odd:

00000000000001a8 <lkdtm_CORRUPT_LIST_ADD>:
 1a8:   e8 00 00 00 00          callq  1ad <lkdtm_CORRUPT_LIST_ADD+0x5>
                        1a9: R_X86_64_PC32      __fentry__-0x4
 1ad:   55                      push   %rbp
 1ae:   48 89 e5                mov    %rsp,%rbp
 1b1:   48 83 e4 f0             and    $0xfffffffffffffff0,%rsp
 1b5:   48 83 ec 20             sub    $0x20,%rsp
 1b9:   48 89 ec                mov    %rbp,%rsp
 1bc:   5d                      pop    %rbp
 1bd:   c3                      retq

The function just allocates/aligns its stack space and then returns.  It
seems like GCC was too smart for its own good here, as the function
doesn't test what it's supposed to.  Can you share the config for this
one?

> > crypto/asymmetric_keys/x509_cert_parser.o: warning: objtool:
> > x509_note_pkey_algo()+0xa4: sibling call from callable instruction
> > with modified stack frame

>From a quick glance, this looks like yet another switch statement
detection issue.  I'll need to dig into it more (unless PeterZ, my shiny
new co-maintainer, wants to take a look!)

-- 
Josh

Re: objtool warnings on 4.14-stable/gcc-7.3.0

[Greg KH]

+Kees

On Wed, Feb 14, 2018 at 04:45:25PM -0600, Josh Poimboeuf wrote:
> On Wed, Feb 14, 2018 at 04:24:12PM -0600, Josh Poimboeuf wrote:
> > On Wed, Feb 14, 2018 at 04:11:15PM +0100, Arnd Bergmann wrote:
> > > Hi Josh,
> > > 
> > > I recently did some randconfig testing with a plain 4.14-stable kernel
> > > and gcc-7.3.0, and came across three distinct objtool warnings:
> > > 
> > > drivers/misc/lkdtm_bugs.o: warning: objtool:
> > > lkdtm_CORRUPT_LIST_ADD()+0x15: return with modified stack frame
> 
> While this is probably an objtool bug, the code is very odd:
> 
> 00000000000001a8 <lkdtm_CORRUPT_LIST_ADD>:
>  1a8:   e8 00 00 00 00          callq  1ad <lkdtm_CORRUPT_LIST_ADD+0x5>
>                         1a9: R_X86_64_PC32      __fentry__-0x4
>  1ad:   55                      push   %rbp
>  1ae:   48 89 e5                mov    %rsp,%rbp
>  1b1:   48 83 e4 f0             and    $0xfffffffffffffff0,%rsp
>  1b5:   48 83 ec 20             sub    $0x20,%rsp
>  1b9:   48 89 ec                mov    %rbp,%rsp
>  1bc:   5d                      pop    %rbp
>  1bd:   c3                      retq
> 
> The function just allocates/aligns its stack space and then returns.  It
> seems like GCC was too smart for its own good here, as the function
> doesn't test what it's supposed to.  Can you share the config for this
> one?

lkdtm is a "interesting" module in that it tries to do bad things to
test for various stuff.  Kees, does the above look like it is doing the
correct thing?

thanks,

greg k-h

Re: objtool warnings on 4.14-stable/gcc-7.3.0

[Arnd Bergmann]

On Wed, Feb 14, 2018 at 11:45 PM, Josh Poimboeuf <jpoimboe@redhat.com> wrote:
> On Wed, Feb 14, 2018 at 04:24:12PM -0600, Josh Poimboeuf wrote:
>> On Wed, Feb 14, 2018 at 04:11:15PM +0100, Arnd Bergmann wrote:
>> > Hi Josh,
>> >
>> > I recently did some randconfig testing with a plain 4.14-stable kernel
>> > and gcc-7.3.0, and came across three distinct objtool warnings:
>> >
>> > drivers/misc/lkdtm_bugs.o: warning: objtool:
>> > lkdtm_CORRUPT_LIST_ADD()+0x15: return with modified stack frame
>
> While this is probably an objtool bug, the code is very odd:
>
> 00000000000001a8 <lkdtm_CORRUPT_LIST_ADD>:
>  1a8:   e8 00 00 00 00          callq  1ad <lkdtm_CORRUPT_LIST_ADD+0x5>
>                         1a9: R_X86_64_PC32      __fentry__-0x4
>  1ad:   55                      push   %rbp
>  1ae:   48 89 e5                mov    %rsp,%rbp
>  1b1:   48 83 e4 f0             and    $0xfffffffffffffff0,%rsp
>  1b5:   48 83 ec 20             sub    $0x20,%rsp
>  1b9:   48 89 ec                mov    %rbp,%rsp
>  1bc:   5d                      pop    %rbp
>  1bd:   c3                      retq
>
> The function just allocates/aligns its stack space and then returns.  It
> seems like GCC was too smart for its own good here, as the function
> doesn't test what it's supposed to.

AFAIU, there is an optimization step in gcc that eliminates basic blocks
that contain an unconditional NULL pointer dereference, based on the
assumption that it's undefined behavior, and if we ever get here, it is
free to drop not only code after but also before it as long as it doesn't
have any side-effects.

I would have expected an actual NULL pointer dereference to remain
in the function though, or at least another trapping instruction.

>  Can you share the config for this one?

https://pastebin.com/qFV6SPWP

        Arnd

Re: objtool warnings on 4.14-stable/gcc-7.3.0

[Josh Poimboeuf]

On Thu, Feb 15, 2018 at 04:01:57PM +0100, Arnd Bergmann wrote:
> On Wed, Feb 14, 2018 at 11:45 PM, Josh Poimboeuf <jpoimboe@redhat.com> wrote:
> > On Wed, Feb 14, 2018 at 04:24:12PM -0600, Josh Poimboeuf wrote:
> >> On Wed, Feb 14, 2018 at 04:11:15PM +0100, Arnd Bergmann wrote:
> >> > Hi Josh,
> >> >
> >> > I recently did some randconfig testing with a plain 4.14-stable kernel
> >> > and gcc-7.3.0, and came across three distinct objtool warnings:
> >> >
> >> > drivers/misc/lkdtm_bugs.o: warning: objtool:
> >> > lkdtm_CORRUPT_LIST_ADD()+0x15: return with modified stack frame
> >
> > While this is probably an objtool bug, the code is very odd:
> >
> > 00000000000001a8 <lkdtm_CORRUPT_LIST_ADD>:
> >  1a8:   e8 00 00 00 00          callq  1ad <lkdtm_CORRUPT_LIST_ADD+0x5>
> >                         1a9: R_X86_64_PC32      __fentry__-0x4
> >  1ad:   55                      push   %rbp
> >  1ae:   48 89 e5                mov    %rsp,%rbp
> >  1b1:   48 83 e4 f0             and    $0xfffffffffffffff0,%rsp
> >  1b5:   48 83 ec 20             sub    $0x20,%rsp
> >  1b9:   48 89 ec                mov    %rbp,%rsp
> >  1bc:   5d                      pop    %rbp
> >  1bd:   c3                      retq
> >
> > The function just allocates/aligns its stack space and then returns.  It
> > seems like GCC was too smart for its own good here, as the function
> > doesn't test what it's supposed to.
> 
> AFAIU, there is an optimization step in gcc that eliminates basic blocks
> that contain an unconditional NULL pointer dereference, based on the
> assumption that it's undefined behavior, and if we ever get here, it is
> free to drop not only code after but also before it as long as it doesn't
> have any side-effects.

Ok, I expected something like that.  GCC "undefined behavior" strikes
again.

Kees, I suppose you'll need to obfuscate the code to stay one step ahead
of GCC.

While this may be an objtool bug, I might not fix it because it served a
useful purpose here in finding GCC crap.

> I would have expected an actual NULL pointer dereference to remain
> in the function though, or at least another trapping instruction.
> 
> >  Can you share the config for this one?
> 
> https://pastebin.com/qFV6SPWP

Would be interesting to analyze that config to understand what options
are causing GCC to do that.  I don't see this "optimization" with my
config.

-- 
Josh

Re: objtool warnings on 4.14-stable/gcc-7.3.0

[Arnd Bergmann]

On Thu, Feb 15, 2018 at 4:25 PM, Josh Poimboeuf <jpoimboe@redhat.com> wrote:
> On Thu, Feb 15, 2018 at 04:01:57PM +0100, Arnd Bergmann wrote:
>> On Wed, Feb 14, 2018 at 11:45 PM, Josh Poimboeuf <jpoimboe@redhat.com> wrote:
>> > On Wed, Feb 14, 2018 at 04:24:12PM -0600, Josh Poimboeuf wrote:
>> >> On Wed, Feb 14, 2018 at 04:11:15PM +0100, Arnd Bergmann wrote:

> Ok, I expected something like that.  GCC "undefined behavior" strikes
> again.
>
> Kees, I suppose you'll need to obfuscate the code to stay one step ahead
> of GCC.
>
> While this may be an objtool bug, I might not fix it because it served a
> useful purpose here in finding GCC crap.
>
>> I would have expected an actual NULL pointer dereference to remain
>> in the function though, or at least another trapping instruction.
>>
>> >  Can you share the config for this one?
>>
>> https://pastebin.com/qFV6SPWP
>
> Would be interesting to analyze that config to understand what options
> are causing GCC to do that.  I don't see this "optimization" with my
> config.

This seems like a very rare combination, the flags I need to reproduce are
"gcc -O2 -mno-red-zone  -mpreferred-stack-boundary=3 -march=nocona",
however I do see the same behavior with every gcc version since 4.8!

Aside from -march=nocona, also bonnell, atom, silvermont, slm, and knl
show this, but none of the modern microarchitectures do.

        Arnd

Re: objtool warnings on 4.14-stable/gcc-7.3.0

[Kees Cook]

On Thu, Feb 15, 2018 at 7:59 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Thu, Feb 15, 2018 at 4:25 PM, Josh Poimboeuf <jpoimboe@redhat.com> wrote:
>> On Thu, Feb 15, 2018 at 04:01:57PM +0100, Arnd Bergmann wrote:
>>> On Wed, Feb 14, 2018 at 11:45 PM, Josh Poimboeuf <jpoimboe@redhat.com> wrote:
>>> > On Wed, Feb 14, 2018 at 04:24:12PM -0600, Josh Poimboeuf wrote:
>>> >> On Wed, Feb 14, 2018 at 04:11:15PM +0100, Arnd Bergmann wrote:
>
>> Ok, I expected something like that.  GCC "undefined behavior" strikes
>> again.
>>
>> Kees, I suppose you'll need to obfuscate the code to stay one step ahead
>> of GCC.
>>
>> While this may be an objtool bug, I might not fix it because it served a
>> useful purpose here in finding GCC crap.
>>
>>> I would have expected an actual NULL pointer dereference to remain
>>> in the function though, or at least another trapping instruction.

Uuhhh... I don't see the NULL deref, and even if it was eliminating
later stuff, I'd still expect a pr_info() ...

void lkdtm_CORRUPT_LIST_ADD(void)
{
        /*
         * Initially, an empty list via LIST_HEAD:
         *      test_head.next = &test_head
         *      test_head.prev = &test_head
         */
        LIST_HEAD(test_head);
        struct lkdtm_list good, bad;
        void *target[2] = { };
        void *redirection = &target;

        pr_info("attempting good list addition\n");
...

>>> >  Can you share the config for this one?
>>>
>>> https://pastebin.com/qFV6SPWP
>>
>> Would be interesting to analyze that config to understand what options
>> are causing GCC to do that.  I don't see this "optimization" with my
>> config.
>
> This seems like a very rare combination, the flags I need to reproduce are
> "gcc -O2 -mno-red-zone  -mpreferred-stack-boundary=3 -march=nocona",
> however I do see the same behavior with every gcc version since 4.8!
>
> Aside from -march=nocona, also bonnell, atom, silvermont, slm, and knl
> show this, but none of the modern microarchitectures do.

I'll see if I can reproduce this...

-Kees

-- 
Kees Cook
Pixel Security

Re: objtool warnings on 4.14-stable/gcc-7.3.0

[Kees Cook]

On Thu, Feb 15, 2018 at 10:06 AM, Kees Cook <keescook@chromium.org> wrote:
> On Thu, Feb 15, 2018 at 7:59 AM, Arnd Bergmann <arnd@arndb.de> wrote:
>> On Thu, Feb 15, 2018 at 4:25 PM, Josh Poimboeuf <jpoimboe@redhat.com> wrote:
>>> On Thu, Feb 15, 2018 at 04:01:57PM +0100, Arnd Bergmann wrote:
>>>> On Wed, Feb 14, 2018 at 11:45 PM, Josh Poimboeuf <jpoimboe@redhat.com> wrote:
>>>> > On Wed, Feb 14, 2018 at 04:24:12PM -0600, Josh Poimboeuf wrote:
>>>> >> On Wed, Feb 14, 2018 at 04:11:15PM +0100, Arnd Bergmann wrote:
>>
>>> Ok, I expected something like that.  GCC "undefined behavior" strikes
>>> again.
>>>
>>> Kees, I suppose you'll need to obfuscate the code to stay one step ahead
>>> of GCC.
>>>
>>> While this may be an objtool bug, I might not fix it because it served a
>>> useful purpose here in finding GCC crap.
>>>
>>>> I would have expected an actual NULL pointer dereference to remain
>>>> in the function though, or at least another trapping instruction.
>
> Uuhhh... I don't see the NULL deref, and even if it was eliminating
> later stuff, I'd still expect a pr_info() ...
>
> void lkdtm_CORRUPT_LIST_ADD(void)
> {
>         /*
>          * Initially, an empty list via LIST_HEAD:
>          *      test_head.next = &test_head
>          *      test_head.prev = &test_head
>          */
>         LIST_HEAD(test_head);
>         struct lkdtm_list good, bad;
>         void *target[2] = { };
>         void *redirection = &target;
>
>         pr_info("attempting good list addition\n");
> ...
>
>>>> >  Can you share the config for this one?
>>>>
>>>> https://pastebin.com/qFV6SPWP
>>>
>>> Would be interesting to analyze that config to understand what options
>>> are causing GCC to do that.  I don't see this "optimization" with my
>>> config.
>>
>> This seems like a very rare combination, the flags I need to reproduce are
>> "gcc -O2 -mno-red-zone  -mpreferred-stack-boundary=3 -march=nocona",
>> however I do see the same behavior with every gcc version since 4.8!
>>
>> Aside from -march=nocona, also bonnell, atom, silvermont, slm, and knl
>> show this, but none of the modern microarchitectures do.
>
> I'll see if I can reproduce this...

To clarify, this is _only_ on 4.14, gcc 7.3.0, and any of
march=nocona, bonnell, atom, silvermont, slm, or knl ?

Is it present in latest Linus and/or with gcc 8?

-Kees

-- 
Kees Cook
Pixel Security

Re: objtool warnings on 4.14-stable/gcc-7.3.0

[Arnd Bergmann]

On Fri, Feb 16, 2018 at 4:41 AM, Kees Cook <keescook@chromium.org> wrote:
> On Thu, Feb 15, 2018 at 10:06 AM, Kees Cook <keescook@chromium.org> wrote:
>> On Thu, Feb 15, 2018 at 7:59 AM, Arnd Bergmann <arnd@arndb.de> wrote:
>>> On Thu, Feb 15, 2018 at 4:25 PM, Josh Poimboeuf <jpoimboe@redhat.com> wrote:
>>>> On Thu, Feb 15, 2018 at 04:01:57PM +0100, Arnd Bergmann wrote:
>>>>> On Wed, Feb 14, 2018 at 11:45 PM, Josh Poimboeuf <jpoimboe@redhat.com> wrote:
>>>>> > On Wed, Feb 14, 2018 at 04:24:12PM -0600, Josh Poimboeuf wrote:
>>>>> >> On Wed, Feb 14, 2018 at 04:11:15PM +0100, Arnd Bergmann wrote:
>>>
>>>> Ok, I expected something like that.  GCC "undefined behavior" strikes
>>>> again.
>>>>
>>>> Kees, I suppose you'll need to obfuscate the code to stay one step ahead
>>>> of GCC.
>>>>
>>>> While this may be an objtool bug, I might not fix it because it served a
>>>> useful purpose here in finding GCC crap.
>>>>
>>>>> I would have expected an actual NULL pointer dereference to remain
>>>>> in the function though, or at least another trapping instruction.
>>
>> Uuhhh... I don't see the NULL deref, and even if it was eliminating
>> later stuff, I'd still expect a pr_info() ...
>>
>> void lkdtm_CORRUPT_LIST_ADD(void)
>> {
>>         /*
>>          * Initially, an empty list via LIST_HEAD:
>>          *      test_head.next = &test_head
>>          *      test_head.prev = &test_head
>>          */
>>         LIST_HEAD(test_head);
>>         struct lkdtm_list good, bad;
>>         void *target[2] = { };
>>         void *redirection = &target;
>>
>>         pr_info("attempting good list addition\n");
>> ...
>>
>>>>> >  Can you share the config for this one?
>>>>>
>>>>> https://pastebin.com/qFV6SPWP
>>>>
>>>> Would be interesting to analyze that config to understand what options
>>>> are causing GCC to do that.  I don't see this "optimization" with my
>>>> config.
>>>
>>> This seems like a very rare combination, the flags I need to reproduce are
>>> "gcc -O2 -mno-red-zone  -mpreferred-stack-boundary=3 -march=nocona",
>>> however I do see the same behavior with every gcc version since 4.8!
>>>
>>> Aside from -march=nocona, also bonnell, atom, silvermont, slm, and knl
>>> show this, but none of the modern microarchitectures do.
>>
>> I'll see if I can reproduce this...
>
> To clarify, this is _only_ on 4.14, gcc 7.3.0, and any of
> march=nocona, bonnell, atom, silvermont, slm, or knl ?
>
> Is it present in latest Linus and/or with gcc 8?

It is with all modern gcc versions: 4.8 though 8.0.1 on those -march
values, and it still appears on latest Linus and next/master.

           Arnd

Re: objtool warnings on 4.14-stable/gcc-7.3.0

[Josh Poimboeuf]

On Wed, Feb 14, 2018 at 04:45:25PM -0600, Josh Poimboeuf wrote:
> On Wed, Feb 14, 2018 at 04:24:12PM -0600, Josh Poimboeuf wrote:
> > On Wed, Feb 14, 2018 at 04:11:15PM +0100, Arnd Bergmann wrote:
> > > crypto/asymmetric_keys/x509_cert_parser.o: warning: objtool:
> > > x509_note_pkey_algo()+0xa4: sibling call from callable instruction
> > > with modified stack frame
> 
> From a quick glance, this looks like yet another switch statement
> detection issue.  I'll need to dig into it more (unless PeterZ, my shiny
> new co-maintainer, wants to take a look!)

Arnd, can you test this fix?

----

From: Josh Poimboeuf <jpoimboe@redhat.com>
Subject: [PATCH] objtool: Another switch table detection fix

Continue the switch table detection whack-a-mole.  Add a check to
distinguish KASAN-related .rodata reads from switch-related .rodata
reads in GCC 7.

This fixes the following warning:

  crypto/asymmetric_keys/x509_cert_parser.o: warning: objtool: x509_note_pkey_algo()+0xa4: sibling call from callable instruction with modified stack frame

Reported-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
---
 tools/objtool/check.c | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/tools/objtool/check.c b/tools/objtool/check.c
index 472e64e95891..46c1d239cc1b 100644
--- a/tools/objtool/check.c
+++ b/tools/objtool/check.c
@@ -925,7 +925,11 @@ static struct rela *find_switch_table(struct objtool_file *file,
 		if (find_symbol_containing(file->rodata, text_rela->addend))
 			continue;
 
-		return find_rela_by_dest(file->rodata, text_rela->addend);
+		rodata_rela = find_rela_by_dest(file->rodata, text_rela->addend);
+		if (!rodata_rela)
+			continue;
+
+		return rodata_rela;
 	}
 
 	return NULL;
-- 
2.14.3

Re: objtool warnings on 4.14-stable/gcc-7.3.0

[Arnd Bergmann]

On Wed, Feb 28, 2018 at 3:20 AM, Josh Poimboeuf <jpoimboe@redhat.com> wrote:
> On Wed, Feb 14, 2018 at 04:45:25PM -0600, Josh Poimboeuf wrote:
>> On Wed, Feb 14, 2018 at 04:24:12PM -0600, Josh Poimboeuf wrote:
>> > On Wed, Feb 14, 2018 at 04:11:15PM +0100, Arnd Bergmann wrote:
>> > > crypto/asymmetric_keys/x509_cert_parser.o: warning: objtool:
>> > > x509_note_pkey_algo()+0xa4: sibling call from callable instruction
>> > > with modified stack frame
>>
>> From a quick glance, this looks like yet another switch statement
>> detection issue.  I'll need to dig into it more (unless PeterZ, my shiny
>> new co-maintainer, wants to take a look!)
>
> Arnd, can you test this fix?

It took me a while, as I had lost the earlier reproducer and am
currently testing
linux-next/gcc-8 whereas the report was for v4.14/gcc-7.

I have finally found a new reproducer on linux-next/gcc-7 and confirmed that
the warning is fixed now, both for gcc-7 and gcc-8.

Thanks for the fix!

        Arnd

Re: objtool warnings on 4.14-stable/gcc-7.3.0

[Greg KH]

On Wed, Feb 14, 2018 at 04:24:12PM -0600, Josh Poimboeuf wrote:
> On Wed, Feb 14, 2018 at 04:11:15PM +0100, Arnd Bergmann wrote:
> > Hi Josh,
> > 
> > I recently did some randconfig testing with a plain 4.14-stable kernel
> > and gcc-7.3.0, and came across three distinct objtool warnings:
> > 
> > drivers/misc/lkdtm_bugs.o: warning: objtool:
> > lkdtm_CORRUPT_LIST_ADD()+0x15: return with modified stack frame
> > 
> > crypto/asymmetric_keys/x509_cert_parser.o: warning: objtool:
> > x509_note_pkey_algo()+0xa4: sibling call from callable instruction
> > with modified stack frame
> > 
> > drivers/infiniband/hw/bnxt_re/qplib_fp.o: warning: objtool:
> > bnxt_qplib_poll_cq()+0x106: sibling call from callable instruction
> > with modified stack frame
> > 
> > It's likely that this is the complete set at the moment, I saw each
> > one multiple times,
> > but did not see any others. I'll reply with the respective object
> > files for your reference,
> > in case these are so far unknown to you. There are only a handful of randconfig
> > warnings we see overall in the kernel these days (at least on x86 and arm64), so
> > even if they are false-positive, it would be great to get rid of the
> > output so we can
> > do randconfig testing on 4.14.y and treat any output from 'make -s' as
> > a regression.
> > I did not check
> 
> The third one has been fixed upstream with
> 
>   99ce7962d52d ("objtool: Fix switch-table detection")
> 
> ... so we should put that one into stable.

Now queued up, thanks.

greg k-h