From: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
To: Ingo Molnar <mingo@elte.hu>
Cc: Peter Zijlstra <peterz@infradead.org>,
Linus Torvalds <torvalds@linux-foundation.org>,
Oleg Nesterov <oleg@redhat.com>,
LKML <linux-kernel@vger.kernel.org>,
Christoph Hellwig <hch@infradead.org>,
Steven Rostedt <rostedt@goodmis.org>,
Thomas Gleixner <tglx@linutronix.de>,
Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>,
Anton Arapov <anton@redhat.com>,
Ananth N Mavinakayanahalli <ananth@in.ibm.com>,
Jim Keniston <jkenisto@linux.vnet.ibm.com>,
Jiri Olsa <jolsa@redhat.com>, Josh Stone <jistone@redhat.com>
Subject: Re: [PATCH 1/3] uprobes/core: Make instruction tables volatile.
Date: Wed, 22 Feb 2012 15:34:31 +0530 [thread overview]
Message-ID: <20120222100431.GA15963@linux.vnet.ibm.com> (raw)
In-Reply-To: <20120222094710.GA31848@elte.hu>
> * Srikar Dronamraju <srikar@linux.vnet.ibm.com> wrote:
>
> > From: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
> >
> > Some versions of gcc spits a warning about the asm operand for test_bit and
> > also causes the first long of the instruction table to be output.
> >
> > Fix is similar to 7115e3fc on arch/x86/kernel/kprobes.c
> >
> > Signed-off-by: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
> > ---
> > arch/x86/kernel/uprobes.c | 61 ++++++++++++++++++++++++---------------------
> > 1 files changed, 32 insertions(+), 29 deletions(-)
> >
> > diff --git a/arch/x86/kernel/uprobes.c b/arch/x86/kernel/uprobes.c
> > index cf2a184..13d616d 100644
> > --- a/arch/x86/kernel/uprobes.c
> > +++ b/arch/x86/kernel/uprobes.c
> > @@ -53,34 +53,12 @@
> > (bc##UL << 0xc)|(bd##UL << 0xd)|(be##UL << 0xe)|(bf##UL << 0xf)) \
> > << (row % 32))
> >
> > -#ifdef CONFIG_X86_64
> > -static u32 good_insns_64[256 / 32] = {
> > - /* 0 1 2 3 4 5 6 7 8 9 a b c d e f */
> > - /* ---------------------------------------------- */
> > - W(0x00, 1, 1, 1, 1, 1, 1, 0, 0, 1, 1, 1, 1, 1, 1, 0, 0) | /* 00 */
> > - W(0x10, 1, 1, 1, 1, 1, 1, 0, 0, 1, 1, 1, 1, 1, 1, 0, 0) , /* 10 */
> > - W(0x20, 1, 1, 1, 1, 1, 1, 0, 0, 1, 1, 1, 1, 1, 1, 0, 0) | /* 20 */
> > - W(0x30, 1, 1, 1, 1, 1, 1, 0, 0, 1, 1, 1, 1, 1, 1, 0, 0) , /* 30 */
> > - W(0x40, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0) | /* 40 */
> > - W(0x50, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1) , /* 50 */
> > - W(0x60, 0, 0, 0, 1, 1, 1, 0, 0, 1, 1, 1, 1, 0, 0, 0, 0) | /* 60 */
> > - W(0x70, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1) , /* 70 */
> > - W(0x80, 1, 1, 0, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1) | /* 80 */
> > - W(0x90, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1) , /* 90 */
> > - W(0xa0, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1) | /* a0 */
> > - W(0xb0, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1) , /* b0 */
> > - W(0xc0, 1, 1, 1, 1, 0, 0, 1, 1, 1, 1, 1, 1, 0, 0, 0, 0) | /* c0 */
> > - W(0xd0, 1, 1, 1, 1, 0, 0, 0, 1, 1, 1, 1, 1, 1, 1, 1, 1) , /* d0 */
> > - W(0xe0, 1, 1, 1, 1, 0, 0, 0, 0, 1, 1, 1, 1, 0, 0, 0, 0) | /* e0 */
> > - W(0xf0, 0, 0, 1, 1, 0, 1, 1, 1, 1, 1, 0, 0, 1, 1, 1, 1) /* f0 */
> > - /* ---------------------------------------------- */
> > - /* 0 1 2 3 4 5 6 7 8 9 a b c d e f */
> > -};
> > -#endif
> > -
> > -/* Good-instruction tables for 32-bit apps */
> > -
> > -static u32 good_insns_32[256 / 32] = {
> > +/*
> > + * Good-instruction tables for 32-bit apps. This is non-const and volatile
> > + * to keep gcc from statically optimizing it out, as variable_test_bit makes
> > + * some versions of gcc to think only *(unsigned long*) is used.
> > + */
> > +static volatile u32 good_insns_32[256 / 32] = {
> > /* 0 1 2 3 4 5 6 7 8 9 a b c d e f */
> > /* ---------------------------------------------- */
> > W(0x00, 1, 1, 1, 1, 1, 1, 1, 0, 1, 1, 1, 1, 1, 1, 1, 0) | /* 00 */
> > @@ -104,7 +82,7 @@ static u32 good_insns_32[256 / 32] = {
> > };
> >
> > /* Using this for both 64-bit and 32-bit apps */
> > -static u32 good_2byte_insns[256 / 32] = {
> > +static volatile u32 good_2byte_insns[256 / 32] = {
> > /* 0 1 2 3 4 5 6 7 8 9 a b c d e f */
> > /* ---------------------------------------------- */
> > W(0x00, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 1) | /* 00 */
> > @@ -127,6 +105,31 @@ static u32 good_2byte_insns[256 / 32] = {
> > /* 0 1 2 3 4 5 6 7 8 9 a b c d e f */
> > };
> >
> > +#ifdef CONFIG_X86_64
> > +/* Good-instruction tables for 64-bit apps */
> > +static volatile u32 good_insns_64[256 / 32] = {
> > + /* 0 1 2 3 4 5 6 7 8 9 a b c d e f */
> > + /* ---------------------------------------------- */
> > + W(0x00, 1, 1, 1, 1, 1, 1, 0, 0, 1, 1, 1, 1, 1, 1, 0, 0) | /* 00 */
> > + W(0x10, 1, 1, 1, 1, 1, 1, 0, 0, 1, 1, 1, 1, 1, 1, 0, 0) , /* 10 */
> > + W(0x20, 1, 1, 1, 1, 1, 1, 0, 0, 1, 1, 1, 1, 1, 1, 0, 0) | /* 20 */
> > + W(0x30, 1, 1, 1, 1, 1, 1, 0, 0, 1, 1, 1, 1, 1, 1, 0, 0) , /* 30 */
> > + W(0x40, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0) | /* 40 */
> > + W(0x50, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1) , /* 50 */
> > + W(0x60, 0, 0, 0, 1, 1, 1, 0, 0, 1, 1, 1, 1, 0, 0, 0, 0) | /* 60 */
> > + W(0x70, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1) , /* 70 */
> > + W(0x80, 1, 1, 0, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1) | /* 80 */
> > + W(0x90, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1) , /* 90 */
> > + W(0xa0, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1) | /* a0 */
> > + W(0xb0, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1) , /* b0 */
> > + W(0xc0, 1, 1, 1, 1, 0, 0, 1, 1, 1, 1, 1, 1, 0, 0, 0, 0) | /* c0 */
> > + W(0xd0, 1, 1, 1, 1, 0, 0, 0, 1, 1, 1, 1, 1, 1, 1, 1, 1) , /* d0 */
> > + W(0xe0, 1, 1, 1, 1, 0, 0, 0, 0, 1, 1, 1, 1, 0, 0, 0, 0) | /* e0 */
> > + W(0xf0, 0, 0, 1, 1, 0, 1, 1, 1, 1, 1, 0, 0, 1, 1, 1, 1) /* f0 */
> > + /* ---------------------------------------------- */
> > + /* 0 1 2 3 4 5 6 7 8 9 a b c d e f */
> > +};
> > +#endif
>
> Hm, why was the table moved around? This makes it hard to see
> whether it's just a single volatile that is added, or something
> more.
>
Without the table moving, the volatile was first used under #ifdef
CONFIG_X86_64. I was wondering if I add a comment in #ifdef people
looking at it might assume that its a problem only on x86_64 only.
So I moved the CONFIG_X86_64 specific table down and added the comment
for volatile at the first instance its used.
--
Thanks and Regards
Srikar
next prev parent reply other threads:[~2012-02-22 10:04 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-02-22 9:15 [PATCH 1/3] uprobes/core: Make instruction tables volatile Srikar Dronamraju
2012-02-22 9:15 ` [PATCH 2/3] uprobes/core: remove uprobe_opcode_sz Srikar Dronamraju
2012-02-22 16:05 ` [tip:perf/uprobes] uprobes/core: Remove uprobe_opcode_sz tip-bot for Srikar Dronamraju
2012-02-22 9:16 ` [PATCH 3/3] uprobes/core: move insn to arch specific structure Srikar Dronamraju
2012-02-22 16:06 ` [tip:perf/uprobes] uprobes/core: Move " tip-bot for Srikar Dronamraju
2012-02-22 9:47 ` [PATCH 1/3] uprobes/core: Make instruction tables volatile Ingo Molnar
2012-02-22 10:04 ` Srikar Dronamraju [this message]
2012-02-22 16:04 ` [tip:perf/uprobes] " tip-bot for Srikar Dronamraju
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=20120222100431.GA15963@linux.vnet.ibm.com \
--to=srikar@linux.vnet.ibm.com \
--cc=ananth@in.ibm.com \
--cc=anton@redhat.com \
--cc=hch@infradead.org \
--cc=jistone@redhat.com \
--cc=jkenisto@linux.vnet.ibm.com \
--cc=jolsa@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=masami.hiramatsu.pt@hitachi.com \
--cc=mingo@elte.hu \
--cc=oleg@redhat.com \
--cc=peterz@infradead.org \
--cc=rostedt@goodmis.org \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.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