From: Josh Poimboeuf <jpoimboe@redhat.com>
To: Ingo Molnar <mingo@kernel.org>
Cc: Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
x86@kernel.org, linux-kernel@vger.kernel.org,
live-patching@vger.kernel.org, Michal Marek <mmarek@suse.cz>,
Peter Zijlstra <peterz@infradead.org>,
Andy Lutomirski <luto@kernel.org>, Borislav Petkov <bp@alien8.de>,
Linus Torvalds <torvalds@linux-foundation.org>,
Andi Kleen <andi@firstfloor.org>, Pedro Alves <palves@redhat.com>,
Namhyung Kim <namhyung@gmail.com>,
Bernd Petrovitsch <bernd@petrovitsch.priv.at>,
Chris J Arges <chris.j.arges@canonical.com>,
Andrew Morton <akpm@linux-foundation.org>,
Jiri Slaby <jslaby@suse.cz>,
Arnaldo Carvalho de Melo <acme@kernel.org>
Subject: Re: [PATCH v18 0/9] Compile-time stack metadata validation
Date: Sun, 28 Feb 2016 11:00:09 -0600 [thread overview]
Message-ID: <20160228170009.GA3079@treble.redhat.com> (raw)
In-Reply-To: <20160228065729.GB20796@gmail.com>
On Sun, Feb 28, 2016 at 07:57:29AM +0100, Ingo Molnar wrote:
>
> Another thing I've noticed are _thousands_ of these warnings:
>
> objtool: kernel/sched/core.o: preempt_schedule_irq()+0x20: function has unreachable instruction
> objtool: kernel/sched/core.o: preempt_schedule_irq()+0x27: function has unreachable instruction
> objtool: kernel/sched/core.o: preempt_schedule_irq()+0x2c: function has unreachable instruction
> objtool: kernel/sched/core.o: preempt_schedule_irq()+0x33: function has unreachable instruction
> objtool: net/ceph/pagevec.o: ceph_put_page_vector()+0x171: function has unreachable instruction
> objtool: net/ceph/pagevec.o: ceph_put_page_vector()+0x178: function has unreachable instruction
> objtool: net/ceph/pagevec.o: ceph_put_page_vector()+0x17d: function has unreachable instruction
> objtool: net/ceph/pagevec.o: ceph_put_page_vector()+0x184: function has unreachable instruction
> objtool: net/ceph/pagevec.o: ceph_get_direct_page_vector()+0xe2: function has unreachable instruction
> objtool: net/ceph/pagevec.o: ceph_get_direct_page_vector()+0xe9: function has unreachable instruction
> objtool: net/ceph/pagevec.o: ceph_get_direct_page_vector()+0xee: function has unreachable instruction
> objtool: net/ceph/pagevec.o: ceph_get_direct_page_vector()+0xf5: function has unreachable instruction
> objtool: net/ceph/pagevec.o: zero_user_segment()+0x120: function has unreachable instruction
> objtool: net/ceph/pagevec.o: zero_user_segment()+0x127: function has unreachable instruction
> objtool: net/ceph/pagevec.o: zero_user_segment()+0x12c: function has unreachable instruction
> objtool: net/ceph/pagevec.o: zero_user_segment()+0x133: function has unreachable instruction
>
> that's on an x86-64 allyesconfig kernel, with objtool merged to tip:master, using
> GCC 4.9.2:
>
> gcc version 4.9.2 20150212 (Red Hat 4.9.2-6) (GCC)
Those are caused by CONFIG_KASAN, CONFIG_UBSAN, and CONFIG_GCOV_KERNEL,
which can all add unreachable instructions. Technically, an unreachable
instruction isn't really a problem, but objtool warns about it because
it often means there's something going on in the control flow which it
doesn't understand.
I guess we could make CONFIG_STACK_VALIDATION conflict with those
options, but I think that would disable it on allyesconfig.
I'll see if I can make objtool smarter so that it detects these special
cases of unreachable instructions and ignores them.
> Also, please prefix such warnings with the standard compiler prefix, something
> like this:
>
> kernel/sched/core.c: warning: objtool: preempt_schedule_irq()+0x20: function has unreachable instruction
>
> so that scripts/tools monitoring new build warnings can pick them up
> automatically?
Yeah, good idea.
--
Josh
prev parent reply other threads:[~2016-02-28 17:00 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-25 22:57 [PATCH v18 0/9] Compile-time stack metadata validation Josh Poimboeuf
2016-02-25 22:57 ` [PATCH v18 1/9] objtool: Mark non-standard files and directories Josh Poimboeuf
2016-02-25 22:57 ` [PATCH v18 2/9] objtool: Add STACK_FRAME_NON_STANDARD macro Josh Poimboeuf
2016-02-25 22:57 ` [PATCH v18 3/9] x86/xen: Mark xen_cpuid() stack frame as non-standard Josh Poimboeuf
2016-02-25 22:57 ` [PATCH v18 4/9] bpf: Mark __bpf_prog_run() " Josh Poimboeuf
2016-02-25 22:57 ` [PATCH v18 5/9] sched: Mark __schedule() " Josh Poimboeuf
2016-02-25 22:57 ` [PATCH v18 6/9] x86/kprobes: Mark kretprobe_trampoline() " Josh Poimboeuf
2016-02-25 22:57 ` [PATCH v18 7/9] objtool: Compile-time stack metadata validation Josh Poimboeuf
2016-02-25 22:57 ` [PATCH v18 8/9] objtool: Add CONFIG_STACK_VALIDATION option Josh Poimboeuf
2016-02-25 22:57 ` [PATCH v18 9/9] objtool: Enable stack metadata validation on x86_64 Josh Poimboeuf
2016-02-28 6:52 ` [PATCH v18 0/9] Compile-time stack metadata validation Ingo Molnar
2016-02-28 6:57 ` Ingo Molnar
2016-02-28 17:00 ` Josh Poimboeuf [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160228170009.GA3079@treble.redhat.com \
--to=jpoimboe@redhat.com \
--cc=acme@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=andi@firstfloor.org \
--cc=bernd@petrovitsch.priv.at \
--cc=bp@alien8.de \
--cc=chris.j.arges@canonical.com \
--cc=hpa@zytor.com \
--cc=jslaby@suse.cz \
--cc=linux-kernel@vger.kernel.org \
--cc=live-patching@vger.kernel.org \
--cc=luto@kernel.org \
--cc=mingo@kernel.org \
--cc=mingo@redhat.com \
--cc=mmarek@suse.cz \
--cc=namhyung@gmail.com \
--cc=palves@redhat.com \
--cc=peterz@infradead.org \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.org \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox