Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1498288 > unrolled thread

[PATCH] [RFC] x86: avoid -mtune=atom for objtool warnings

Started byArnd Bergmann <arnd@arndb.de>
First post2016-10-10 15:10 +0200
Last post2016-10-11 04:00 +0200
Articles 9 — 2 participants

Back to article view | Back to linux.kernel

Contents

  [PATCH] [RFC] x86: avoid -mtune=atom for objtool warnings Arnd Bergmann <arnd@arndb.de> - 2016-10-10 15:10 +0200
    Re: [PATCH] [RFC] x86: avoid -mtune=atom for objtool warnings Josh Poimboeuf <jpoimboe@redhat.com> - 2016-10-10 22:40 +0200
      Re: [PATCH] [RFC] x86: avoid -mtune=atom for objtool warnings Arnd Bergmann <arnd@arndb.de> - 2016-10-11 10:20 +0200
        Re: [PATCH] [RFC] x86: avoid -mtune=atom for objtool warnings Josh Poimboeuf <jpoimboe@redhat.com> - 2016-10-11 14:30 +0200
          Re: [PATCH] [RFC] x86: avoid -mtune=atom for objtool warnings Josh Poimboeuf <jpoimboe@redhat.com> - 2016-10-11 17:10 +0200
            Re: [PATCH] [RFC] x86: avoid -mtune=atom for objtool warnings Josh Poimboeuf <jpoimboe@redhat.com> - 2016-10-11 18:10 +0200
              Re: [PATCH] [RFC] x86: avoid -mtune=atom for objtool warnings Arnd Bergmann <arnd@arndb.de> - 2016-10-11 22:50 +0200
                Re: [PATCH] [RFC] x86: avoid -mtune=atom for objtool warnings Josh Poimboeuf <jpoimboe@redhat.com> - 2016-10-12 15:10 +0200
    [PATCH] objtool: support '-mtune=atom' stack frame setup instruction Josh Poimboeuf <jpoimboe@redhat.com> - 2016-10-11 04:00 +0200

#1498288 — [PATCH] [RFC] x86: avoid -mtune=atom for objtool warnings

FromArnd Bergmann <arnd@arndb.de>
Date2016-10-10 15:10 +0200
Subject[PATCH] [RFC] x86: avoid -mtune=atom for objtool warnings
Message-ID<sqIv8-1FC-19@gated-at.bofh.it>
I have no idea what is actually going on here, but building an x86 kernel
with CONFIG_MATOM results in countless warnings from objtool, such as

arch/x86/events/intel/ds.o: warning: objtool: intel_pmu_pebs_del()+0x43: call without frame pointer save/setup
security/keys/keyring.o: warning: objtool: keyring_read()+0x59: call without frame pointer save/setup
kernel/signal.o: warning: objtool: __dequeue_signal()+0xd8: call without frame pointer save/setup
kernel/signal.o: warning: objtool: kill_pid()+0x15: call without frame pointer save/setup
kernel/signal.o: warning: objtool: SyS_signal()+0x27: call without frame pointer save/setup
mm/page_alloc.o: warning: objtool: zone_watermark_ok_safe()+0x27: call without frame pointer save/setup
fs/exec.o: warning: objtool: read_code()+0x18: call without frame pointer save/setup
mm/swap.o: warning: objtool: get_kernel_page()+0x24: call without frame pointer save/setup
mm/swap.o: warning: objtool: pagevec_move_tail.constprop.25()+0x26: call without frame pointer save/setup
block/bio.o: warning: objtool: bio_map_kern()+0x47: call without frame pointer save/setup
arch/x86/crypto/poly1305_glue.o: warning: objtool: poly1305_simd_mult()+0x2d: call without frame pointer save/setup
crypto/skcipher.o: warning: objtool: skcipher_encrypt_ablkcipher()+0x58: call without frame pointer save/setup
crypto/skcipher.o: warning: objtool: skcipher_decrypt_ablkcipher()+0x58: call without frame pointer save/setup
fs/inode.o: warning: objtool: ilookup()+0x5d: call without frame pointer save/setup
fs/inode.o: warning: objtool: proc_nr_inodes()+0x3e: call without frame pointer save/setup
fs/namei.o: warning: objtool: lookup_one_len_unlocked()+0x21: call without frame pointer save/setup
block/elevator.o: warning: objtool: elv_rb_add()+0x5b: call without frame pointer save/setup
crypto/shash.o: warning: objtool: shash_async_init()+0x1e: call without frame pointer save/setup
crypto/shash.o: warning: objtool: shash_async_import()+0x1e: call without frame pointer save/setup
mm/vmscan.o: warning: objtool: pfmemalloc_watermark_ok()+0xb9: call without frame pointer save/setup

I have not looked at whether this is a bug in gcc or in objtool, however
I found that not using -mtune=atom reliably avoids the problem. I could
reproduce the problem with gcc versions 4.7 through 6.1.

Cc: Josh Poimboeuf <jpoimboe@redhat.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 arch/x86/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/Makefile b/arch/x86/Makefile
index 2d449337a360..e1dfb37d66ad 100644
--- a/arch/x86/Makefile
+++ b/arch/x86/Makefile
@@ -110,7 +110,7 @@ else
         cflags-$(CONFIG_MCORE2) += \
                 $(call cc-option,-march=core2,$(call cc-option,-mtune=generic))
 	cflags-$(CONFIG_MATOM) += $(call cc-option,-march=atom) \
-		$(call cc-option,-mtune=atom,$(call cc-option,-mtune=generic))
+		$(call cc-option,-mtune=generic)
         cflags-$(CONFIG_GENERIC_CPU) += $(call cc-option,-mtune=generic)
         KBUILD_CFLAGS += $(cflags-y)
 
-- 
2.9.0

[toc] | [next] | [standalone]

#1498523

FromJosh Poimboeuf <jpoimboe@redhat.com>
Date2016-10-10 22:40 +0200
Message-ID<sqPwB-5N5-7@gated-at.bofh.it>
In reply to#1498288
On Mon, Oct 10, 2016 at 02:56:56PM +0200, Arnd Bergmann wrote:
> I have no idea what is actually going on here, but building an x86 kernel
> with CONFIG_MATOM results in countless warnings from objtool, such as
> 
> arch/x86/events/intel/ds.o: warning: objtool: intel_pmu_pebs_del()+0x43: call without frame pointer save/setup
> security/keys/keyring.o: warning: objtool: keyring_read()+0x59: call without frame pointer save/setup
> kernel/signal.o: warning: objtool: __dequeue_signal()+0xd8: call without frame pointer save/setup
> kernel/signal.o: warning: objtool: kill_pid()+0x15: call without frame pointer save/setup
> kernel/signal.o: warning: objtool: SyS_signal()+0x27: call without frame pointer save/setup
> mm/page_alloc.o: warning: objtool: zone_watermark_ok_safe()+0x27: call without frame pointer save/setup
> fs/exec.o: warning: objtool: read_code()+0x18: call without frame pointer save/setup
> mm/swap.o: warning: objtool: get_kernel_page()+0x24: call without frame pointer save/setup
> mm/swap.o: warning: objtool: pagevec_move_tail.constprop.25()+0x26: call without frame pointer save/setup
> block/bio.o: warning: objtool: bio_map_kern()+0x47: call without frame pointer save/setup
> arch/x86/crypto/poly1305_glue.o: warning: objtool: poly1305_simd_mult()+0x2d: call without frame pointer save/setup
> crypto/skcipher.o: warning: objtool: skcipher_encrypt_ablkcipher()+0x58: call without frame pointer save/setup
> crypto/skcipher.o: warning: objtool: skcipher_decrypt_ablkcipher()+0x58: call without frame pointer save/setup
> fs/inode.o: warning: objtool: ilookup()+0x5d: call without frame pointer save/setup
> fs/inode.o: warning: objtool: proc_nr_inodes()+0x3e: call without frame pointer save/setup
> fs/namei.o: warning: objtool: lookup_one_len_unlocked()+0x21: call without frame pointer save/setup
> block/elevator.o: warning: objtool: elv_rb_add()+0x5b: call without frame pointer save/setup
> crypto/shash.o: warning: objtool: shash_async_init()+0x1e: call without frame pointer save/setup
> crypto/shash.o: warning: objtool: shash_async_import()+0x1e: call without frame pointer save/setup
> mm/vmscan.o: warning: objtool: pfmemalloc_watermark_ok()+0xb9: call without frame pointer save/setup
> 
> I have not looked at whether this is a bug in gcc or in objtool, however
> I found that not using -mtune=atom reliably avoids the problem. I could
> reproduce the problem with gcc versions 4.7 through 6.1.

Thanks for reporting it.  It looks like 'mtune=atom' sometimes makes a
slight change to one of the stack frame setup instructions.  Instead of:

  move rsp, rbp

It sometimes does:

  lea (%rsp),%rbp

They're two different instructions, but they have the same result.  It's
an easy fix for objtool.  I'll post a patch soon.

-- 
Josh

[toc] | [prev] | [next] | [standalone]

#1498659

FromArnd Bergmann <arnd@arndb.de>
Date2016-10-11 10:20 +0200
Message-ID<sr0s2-4d1-25@gated-at.bofh.it>
In reply to#1498523
On Monday, October 10, 2016 3:23:22 PM CEST Josh Poimboeuf wrote:
> 
> Thanks for reporting it.  It looks like 'mtune=atom' sometimes makes a
> slight change to one of the stack frame setup instructions.  Instead of:
> 
>   move rsp, rbp
> 
> It sometimes does:
> 
>   lea (%rsp),%rbp
> 
> They're two different instructions, but they have the same result.  It's
> an easy fix for objtool.  I'll post a patch soon.
> 
> 

Ah, good to hear. I've replaced my patch with yours in my randconfig
tests now and will let you know if there are any other warnings on
atom. I've done a few thousand x86 randconfig builds now and done private
patches for all warnings I got (I previously had fixes only for the arm
warnings). I found objtool warnings for a few files in some configurations
that do not involve -mtune=atom, maybe you can also look at what
is going on there as I have no idea for how to address them:

drivers/scsi/fnic/fnic_main.o: warning: objtool: fnic_log_q_error() falls through to next function fnic_handle_link_event()
drivers/scsi/snic/snic_res.o: warning: objtool: .text: unexpected end of section
drivers/infiniband/sw/rxe/rxe_comp.o: warning: objtool: rxe_completer()+0x2f3: sibling call from callable instruction with changed frame pointer
drivers/infiniband/sw/rxe/rxe_resp.o: warning: objtool: rxe_responder()+0x10f: sibling call from callable instruction with changed frame pointer
kernel/locking/rwsem.o: warning: objtool: down_write_killable()+0x16: call without frame pointer save/setup

I can provide additional information for reproducing them if it's
not immediately obvious what the problems are.

Thanks,

	Arnd

[toc] | [prev] | [next] | [standalone]

#1498835

FromJosh Poimboeuf <jpoimboe@redhat.com>
Date2016-10-11 14:30 +0200
Message-ID<sr4lY-6Fi-35@gated-at.bofh.it>
In reply to#1498659
On Tue, Oct 11, 2016 at 10:08:12AM +0200, Arnd Bergmann wrote:
> On Monday, October 10, 2016 3:23:22 PM CEST Josh Poimboeuf wrote:
> > 
> > Thanks for reporting it.  It looks like 'mtune=atom' sometimes makes a
> > slight change to one of the stack frame setup instructions.  Instead of:
> > 
> >   move rsp, rbp
> > 
> > It sometimes does:
> > 
> >   lea (%rsp),%rbp
> > 
> > They're two different instructions, but they have the same result.  It's
> > an easy fix for objtool.  I'll post a patch soon.
> > 
> > 
> 
> Ah, good to hear. I've replaced my patch with yours in my randconfig
> tests now and will let you know if there are any other warnings on
> atom. I've done a few thousand x86 randconfig builds now and done private
> patches for all warnings I got (I previously had fixes only for the arm
> warnings). I found objtool warnings for a few files in some configurations
> that do not involve -mtune=atom, maybe you can also look at what
> is going on there as I have no idea for how to address them:
> 
> drivers/scsi/fnic/fnic_main.o: warning: objtool: fnic_log_q_error() falls through to next function fnic_handle_link_event()
> drivers/scsi/snic/snic_res.o: warning: objtool: .text: unexpected end of section
> drivers/infiniband/sw/rxe/rxe_comp.o: warning: objtool: rxe_completer()+0x2f3: sibling call from callable instruction with changed frame pointer
> drivers/infiniband/sw/rxe/rxe_resp.o: warning: objtool: rxe_responder()+0x10f: sibling call from callable instruction with changed frame pointer
> kernel/locking/rwsem.o: warning: objtool: down_write_killable()+0x16: call without frame pointer save/setup
> 
> I can provide additional information for reproducing them if it's
> not immediately obvious what the problems are.

I'm really surprised the 0-day bot didn't find these.  I was under the
impression that it continuously did a bunch of randconfigs.

Anyway, if you could send the configs for the warnings, that would be
very helpful.

I also happen to be working on a significant rewrite of objtool and
these configs will come in handy for making a regression suite.

-- 
Josh

[toc] | [prev] | [next] | [standalone]

#1498963

FromJosh Poimboeuf <jpoimboe@redhat.com>
Date2016-10-11 17:10 +0200
Message-ID<sr6QO-8jN-19@gated-at.bofh.it>
In reply to#1498835
On Tue, Oct 11, 2016 at 03:30:20PM +0200, Arnd Bergmann wrote:
> I've attached the three .config files here, but due to the size I
> don't know if they make it to the list or your inbox. Let me
> know if you get them, and if you are able to reproduce the problem.
> 
> The compiler version I used is gcc-6 (Ubuntu 6.2.0-3ubuntu11~16.04)
> 6.2.0 20160901, and this is on top of linux-next plus a few other
> patches.

Thanks, I got the configs, and I do see the warnings.  Will
investigate...

-- 
Josh

[toc] | [prev] | [next] | [standalone]

#1498996

FromJosh Poimboeuf <jpoimboe@redhat.com>
Date2016-10-11 18:10 +0200
Message-ID<sr7MR-qu-3@gated-at.bofh.it>
In reply to#1498963
(spoiler alert: another bad gcc bug which is truncating functions...)

On Tue, Oct 11, 2016 at 10:05:41AM -0500, Josh Poimboeuf wrote:
> On Tue, Oct 11, 2016 at 03:30:20PM +0200, Arnd Bergmann wrote:
> > I've attached the three .config files here, but due to the size I
> > don't know if they make it to the list or your inbox. Let me
> > know if you get them, and if you are able to reproduce the problem.
> > 
> > The compiler version I used is gcc-6 (Ubuntu 6.2.0-3ubuntu11~16.04)
> > 6.2.0 20160901, and this is on top of linux-next plus a few other
> > patches.
> 
> Thanks, I got the configs, and I do see the warnings.  Will
> investigate...

1) 0x364C8CDB-config:
kernel/locking/rwsem.o: warning: objtool: down_write_killable()+0x16: call without frame pointer save/setup

This is a bug in kernel code in the ____down_write() macro.  It doesn't
ensure there's a stack frame before the call instruction.  Easy fix.


2) 0x3A1DA440-config:
drivers/infiniband/sw/rxe/rxe_comp.o: warning: objtool: rxe_completer()+0x2f4: sibling call from callable instruction with changed frame pointer
drivers/infiniband/sw/rxe/rxe_resp.o: warning: objtool: rxe_responder()+0x10f: sibling call from callable instruction with changed frame pointer

These are false positive warnings, caused by the bane of objtool's
existence, gcc switch statement jump tables.  objtool needs to be made a
little smarter.


3) 0xFC244C03-config:
drivers/scsi/fnic/fnic_main.o: warning: objtool: fnic_log_q_error() falls through to next function fnic_handle_link_event()
drivers/scsi/snic/snic_res.o: warning: objtool: .text: unexpected end of section

These look like another bad gcc bug which is truncating functions:

  0000000000000940 <snic_log_q_error>:
   940:   55                      push   %rbp
   941:   48 89 e5                mov    %rsp,%rbp
   944:   53                      push   %rbx
   945:   48 89 fb                mov    %rdi,%rbx
   948:   e8 00 00 00 00          callq  94d <snic_log_q_error+0xd>
                          949: R_X86_64_PC32      __sanitizer_cov_trace_pc-0x4
   94d:   8b 83 58 02 00 00       mov    0x258(%rbx),%eax
   953:   85 c0                   test   %eax,%eax
   955:   75 08                   jne    95f <snic_log_q_error+0x1f>
   957:   e8 00 00 00 00          callq  95c <snic_log_q_error+0x1c>
                          958: R_X86_64_PC32      __sanitizer_cov_trace_pc-0x4
   95c:   5b                      pop    %rbx
   95d:   5d                      pop    %rbp
   95e:   c3                      retq   
   95f:   e8 00 00 00 00          callq  964 <snic_log_q_error+0x24>
                          960: R_X86_64_PC32      __sanitizer_cov_trace_pc-0x4
   964:   48 8b 83 10 1c 00 00    mov    0x1c10(%rbx),%rax
   96b:   48 8d 78 50             lea    0x50(%rax),%rdi
   96f:   e8 00 00 00 00          callq  974 <snic_log_q_error+0x34>
                          970: R_X86_64_PC32      ioread32-0x4
   974:   83 bb 58 02 00 00 01    cmpl   $0x1,0x258(%rbx)
   97b:   76 da                   jbe    957 <snic_log_q_error+0x17>
   97d:   e8 00 00 00 00          callq  982 <snic_log_q_error+0x42>
                          97e: R_X86_64_PC32      __sanitizer_cov_trace_pc-0x4

[end of file]

Notice how it just falls off the end of the function.  We had a similar
bug before:

  https://lkml.kernel.org/r/20160413033649.7r3msnmo3trtq47z@treble
  https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70646

I'm not sure yet if this is the same gcc bug or a different one.  Maybe
it's related to the new GCC_PLUGIN_SANCOV?

-- 
Josh

[toc] | [prev] | [next] | [standalone]

#1499199

FromArnd Bergmann <arnd@arndb.de>
Date2016-10-11 22:50 +0200
Message-ID<src9Q-2XG-3@gated-at.bofh.it>
In reply to#1498996
On Tuesday, October 11, 2016 10:51:46 AM CEST Josh Poimboeuf wrote:
> 
> 3) 0xFC244C03-config:
> drivers/scsi/fnic/fnic_main.o: warning: objtool: fnic_log_q_error() falls through to next function fnic_handle_link_event()
> drivers/scsi/snic/snic_res.o: warning: objtool: .text: unexpected end of section
> 
> These look like another bad gcc bug which is truncating functions:

Same bug for both of them?

> 
>   0000000000000940 <snic_log_q_error>:
>    940:   55                      push   %rbp
>    941:   48 89 e5                mov    %rsp,%rbp
>    944:   53                      push   %rbx
>    945:   48 89 fb                mov    %rdi,%rbx
>    948:   e8 00 00 00 00          callq  94d <snic_log_q_error+0xd>
>                           949: R_X86_64_PC32      __sanitizer_cov_trace_pc-0x4
>    94d:   8b 83 58 02 00 00       mov    0x258(%rbx),%eax
>    953:   85 c0                   test   %eax,%eax
>    955:   75 08                   jne    95f <snic_log_q_error+0x1f>
>    957:   e8 00 00 00 00          callq  95c <snic_log_q_error+0x1c>
>                           958: R_X86_64_PC32      __sanitizer_cov_trace_pc-0x4
>    95c:   5b                      pop    %rbx
>    95d:   5d                      pop    %rbp
>    95e:   c3                      retq   
>    95f:   e8 00 00 00 00          callq  964 <snic_log_q_error+0x24>
>                           960: R_X86_64_PC32      __sanitizer_cov_trace_pc-0x4
>    964:   48 8b 83 10 1c 00 00    mov    0x1c10(%rbx),%rax
>    96b:   48 8d 78 50             lea    0x50(%rax),%rdi
>    96f:   e8 00 00 00 00          callq  974 <snic_log_q_error+0x34>
>                           970: R_X86_64_PC32      ioread32-0x4
>    974:   83 bb 58 02 00 00 01    cmpl   $0x1,0x258(%rbx)
>    97b:   76 da                   jbe    957 <snic_log_q_error+0x17>
>    97d:   e8 00 00 00 00          callq  982 <snic_log_q_error+0x42>
>                           97e: R_X86_64_PC32      __sanitizer_cov_trace_pc-0x4
> 
> [end of file]
> 
> Notice how it just falls off the end of the function.  We had a similar
> bug before:
> 
>   https://lkml.kernel.org/r/20160413033649.7r3msnmo3trtq47z@treble

I remember that nightmare :(

>   https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70646
> 
> I'm not sure yet if this is the same gcc bug or a different one.  Maybe
> it's related to the new GCC_PLUGIN_SANCOV?

I've reduced one of the test cases to this now:

/* gcc-6  -O2 -fno-strict-aliasing -fno-reorder-blocks -fno-omit-frame-pointer  -Wno-pointer-sign -fsanitize-coverage=trace-pc -Wall -Werror -c snic_res.c -o snic_res.o */
typedef int spinlock_t;
extern unsigned int ioread32(void *);
struct vnic_wq_ctrl {
	unsigned int error_status;
};
struct vnic_wq {
	struct vnic_wq_ctrl *ctrl;
} mempool_t;
struct snic {
	unsigned int wq_count;
	__attribute__ ((__aligned__)) struct vnic_wq wq[1];
	spinlock_t wq_lock[1];
};
unsigned int snic_log_q_error_err_status;
void snic_log_q_error(struct snic *snic)
{
	unsigned int i;
	for (i = 0; i < snic->wq_count; i++)
		snic_log_q_error_err_status =
		    ioread32(&snic->wq[i].ctrl->error_status);
}

which gets compiled into

0000000000000000 <snic_log_q_error>:
   0:	55                   	push   %rbp
   1:	48 89 e5             	mov    %rsp,%rbp
   4:	53                   	push   %rbx
   5:	48 89 fb             	mov    %rdi,%rbx
   8:	48 83 ec 08          	sub    $0x8,%rsp
   c:	e8 00 00 00 00       	callq  11 <snic_log_q_error+0x11>
			d: R_X86_64_PC32	__sanitizer_cov_trace_pc-0x4
  11:	8b 03                	mov    (%rbx),%eax
  13:	85 c0                	test   %eax,%eax
  15:	75 11                	jne    28 <snic_log_q_error+0x28>
  17:	48 83 c4 08          	add    $0x8,%rsp
  1b:	5b                   	pop    %rbx
  1c:	5d                   	pop    %rbp
  1d:	e9 00 00 00 00       	jmpq   22 <snic_log_q_error+0x22>
			1e: R_X86_64_PC32	__sanitizer_cov_trace_pc-0x4
  22:	66 0f 1f 44 00 00    	nopw   0x0(%rax,%rax,1)
  28:	e8 00 00 00 00       	callq  2d <snic_log_q_error+0x2d>
			29: R_X86_64_PC32	__sanitizer_cov_trace_pc-0x4
  2d:	48 8b 7b 10          	mov    0x10(%rbx),%rdi
  31:	e8 00 00 00 00       	callq  36 <snic_log_q_error+0x36>
			32: R_X86_64_PC32	ioread32-0x4
  36:	89 05 00 00 00 00    	mov    %eax,0x0(%rip)        # 3c <snic_log_q_error+0x3c>
			38: R_X86_64_PC32	snic_log_q_error_err_status-0x4
  3c:	83 3b 01             	cmpl   $0x1,(%rbx)
  3f:	76 d6                	jbe    17 <snic_log_q_error+0x17>
  41:	e8 00 00 00 00       	callq  46 <snic_log_q_error+0x46>
			42: R_X86_64_PC32	__sanitizer_cov_trace_pc-0x4

	Arnd

[toc] | [prev] | [next] | [standalone]

#1499649

FromJosh Poimboeuf <jpoimboe@redhat.com>
Date2016-10-12 15:10 +0200
Message-ID<srrse-4OM-69@gated-at.bofh.it>
In reply to#1499199
On Tue, Oct 11, 2016 at 10:38:42PM +0200, Arnd Bergmann wrote:
> I've reduced one of the test cases to this now:
> 
> /* gcc-6  -O2 -fno-strict-aliasing -fno-reorder-blocks -fno-omit-frame-pointer  -Wno-pointer-sign -fsanitize-coverage=trace-pc -Wall -Werror -c snic_res.c -o snic_res.o */
> typedef int spinlock_t;
> extern unsigned int ioread32(void *);
> struct vnic_wq_ctrl {
> 	unsigned int error_status;
> };
> struct vnic_wq {
> 	struct vnic_wq_ctrl *ctrl;
> } mempool_t;
> struct snic {
> 	unsigned int wq_count;
> 	__attribute__ ((__aligned__)) struct vnic_wq wq[1];
> 	spinlock_t wq_lock[1];
> };
> unsigned int snic_log_q_error_err_status;
> void snic_log_q_error(struct snic *snic)
> {
> 	unsigned int i;
> 	for (i = 0; i < snic->wq_count; i++)
> 		snic_log_q_error_err_status =
> 		    ioread32(&snic->wq[i].ctrl->error_status);
> }
> 
> which gets compiled into
> 
> 0000000000000000 <snic_log_q_error>:
>    0:	55                   	push   %rbp
>    1:	48 89 e5             	mov    %rsp,%rbp
>    4:	53                   	push   %rbx
>    5:	48 89 fb             	mov    %rdi,%rbx
>    8:	48 83 ec 08          	sub    $0x8,%rsp
>    c:	e8 00 00 00 00       	callq  11 <snic_log_q_error+0x11>
> 			d: R_X86_64_PC32	__sanitizer_cov_trace_pc-0x4
>   11:	8b 03                	mov    (%rbx),%eax
>   13:	85 c0                	test   %eax,%eax
>   15:	75 11                	jne    28 <snic_log_q_error+0x28>
>   17:	48 83 c4 08          	add    $0x8,%rsp
>   1b:	5b                   	pop    %rbx
>   1c:	5d                   	pop    %rbp
>   1d:	e9 00 00 00 00       	jmpq   22 <snic_log_q_error+0x22>
> 			1e: R_X86_64_PC32	__sanitizer_cov_trace_pc-0x4
>   22:	66 0f 1f 44 00 00    	nopw   0x0(%rax,%rax,1)
>   28:	e8 00 00 00 00       	callq  2d <snic_log_q_error+0x2d>
> 			29: R_X86_64_PC32	__sanitizer_cov_trace_pc-0x4
>   2d:	48 8b 7b 10          	mov    0x10(%rbx),%rdi
>   31:	e8 00 00 00 00       	callq  36 <snic_log_q_error+0x36>
> 			32: R_X86_64_PC32	ioread32-0x4
>   36:	89 05 00 00 00 00    	mov    %eax,0x0(%rip)        # 3c <snic_log_q_error+0x3c>
> 			38: R_X86_64_PC32	snic_log_q_error_err_status-0x4
>   3c:	83 3b 01             	cmpl   $0x1,(%rbx)
>   3f:	76 d6                	jbe    17 <snic_log_q_error+0x17>
>   41:	e8 00 00 00 00       	callq  46 <snic_log_q_error+0x46>
> 			42: R_X86_64_PC32	__sanitizer_cov_trace_pc-0x4
> 

Thanks!  I'll open a gcc bug.

-- 
Josh

[toc] | [prev] | [next] | [standalone]

#1498581 — [PATCH] objtool: support '-mtune=atom' stack frame setup instruction

FromJosh Poimboeuf <jpoimboe@redhat.com>
Date2016-10-11 04:00 +0200
Subject[PATCH] objtool: support '-mtune=atom' stack frame setup instruction
Message-ID<sqUwh-gU-3@gated-at.bofh.it>
In reply to#1498288
From 60c982d4d04014adb3bde1ebee6ca95320ffb213 Mon Sep 17 00:00:00 2001
Message-Id: <60c982d4d04014adb3bde1ebee6ca95320ffb213.1476150736.git.jpoimboe@redhat.com>
From: Josh Poimboeuf <jpoimboe@redhat.com>
Date: Mon, 10 Oct 2016 15:24:01 -0500
Subject: [PATCH] objtool: support '-mtune=atom' stack frame setup instruction

Arnd reported that enabling CONFIG_MATOM results in a bunch of objtool
false positive frame pointer warnings:

  arch/x86/events/intel/ds.o: warning: objtool: intel_pmu_pebs_del()+0x43: call without frame pointer save/setup
  security/keys/keyring.o: warning: objtool: keyring_read()+0x59: call without frame pointer save/setup
  kernel/signal.o: warning: objtool: __dequeue_signal()+0xd8: call without frame pointer save/setup
  ...

objtool gets confused by the fact that the '-mtune=atom' gcc option
sometimes uses 'lea (%rsp),%rbp' instead of 'mov %rsp,%rbp'.  The
instructions are effectively the same, but objtool doesn't know about
the 'lea' variant.

Fix the false warnings by adding support for 'lea (%rsp),%rbp' in the
objtool decoder.

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

diff --git a/tools/objtool/arch/x86/decode.c b/tools/objtool/arch/x86/decode.c
index c0c0b26..b63a31b 100644
--- a/tools/objtool/arch/x86/decode.c
+++ b/tools/objtool/arch/x86/decode.c
@@ -98,6 +98,15 @@ int arch_decode_instruction(struct elf *elf, struct section *sec,
 			*type = INSN_FP_SETUP;
 		break;
 
+	case 0x8d:
+		if (insn.rex_prefix.bytes &&
+		    insn.rex_prefix.bytes[0] == 0x48 &&
+		    insn.modrm.nbytes && insn.modrm.bytes[0] == 0x2c &&
+		    insn.sib.nbytes && insn.sib.bytes[0] == 0x24)
+			/* lea %(rsp), %rbp */
+			*type = INSN_FP_SETUP;
+		break;
+
 	case 0x90:
 		*type = INSN_NOP;
 		break;
-- 
2.7.4

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web