From: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
To: Oleg Nesterov <oleg@redhat.com>
Cc: Ananth N Mavinakayanahalli <ananth@in.ibm.com>,
Ingo Molnar <mingo@elte.hu>,
Peter Zijlstra <peterz@infradead.org>,
Anton Arapov <anton@redhat.com>,
Sebastian Andrzej Siewior <bigeasy@linutronix.de>,
linux-kernel@vger.kernel.org,
Jim Keniston <jkenisto@linux.vnet.ibm.com>
Subject: Re: [PATCH 3/5] uprobes: Fix UPROBE_SKIP_SSTEP checks in handle_swbp()
Date: Thu, 20 Sep 2012 20:13:11 +0530 [thread overview]
Message-ID: <20120920144311.GF27880@linux.vnet.ibm.com> (raw)
In-Reply-To: <20120918160738.GA22995@redhat.com>
* Oleg Nesterov <oleg@redhat.com> [2012-09-18 18:07:38]:
> >
> > > Probably this is fine, at least this is
> > > fine if it finds "nop" eventually. But I can't undestand what
> > > "0x66* { 0x90 | 0x0f 0x1f | 0x0f 0x19 | 0x87 0xc0 }" means.
> > > OK, 0x66 and 0x90 are clear. But, say, 0x0f 0x1f ?
> >
> > we skip is 0x66 ..0x66 0x0f 0x1f
> >
> > So we have a check
> > if (i == (MAX_UINSN_BYTES - 1))
> >
> > so this ensures that we are consider 0x0f 0x1f as nop if and only if
> > they are at the end and preceeded by 0x66.
>
> Hmm. How so? The code does
>
> if (i == (MAX_UINSN_BYTES - 1))
> break;
>
> if ((auprobe->insn[i] == 0x0f) && (auprobe->insn[i+1] == 0x1f))
> return true;
>
>
> So, afaics, if the intent was to skip 1f0f at the end only, it should do
Its 0f1f and not 1f0f
>
> if (i == (MAX_UINSN_BYTES - 1)) {
> if ((auprobe->insn[i] == 0x0f) && (auprobe->insn[i+1] == 0x1f))
> return true;
> ...
> }
>
> "and preceeded by 0x66" above doesn't look true too, perhaps you
> meant "may be preceeded by 0x66".
>
Yup, as always you are right. We expect 0x0f 0x1f preceeded by 0x66 to
be nop instructions.
> > So are you suggesting extending the list of nops or is it that we are
> > considering non nop instructions as nops?
>
> No, I am trying to understand which insns arch_skip tries to skip.
> In particular, what "0x0f 0x1f" means.
>
> > > I compiled this program
> > >
> > > int main(void)
> > > {
> > > asm volatile (".word 0x1f0f");
> > > return 0;
> > > }
> > >
> > > and objdump reports:
> > >
> > > 000000000040047c <main>:
> > > 40047c: 0f 1f 31 nopl (%rcx)
> >
> > Current uprobes code wouldnt skip the above insn because it has 31
> > following it.
>
> See above.
>
> And again, could you explain which insn has 1f0f (at the end or not) ?
> IOW, what we are trying to skip?
Again its 0f1f and not 1f0f
for example
0f 1f 40 00
0f 1f 44 00 00
66 0f 1f 44 00 00
I referred arch/x86/include/asm/nops.h, arch/x86/lib/x86-opcode-map.txt
and disassembly of libc. And ofcourse Jim Keniston helped me in most of
the x86 stuff.
--
thanks and regards
Srikar
next prev parent reply other threads:[~2012-09-20 14:49 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-09-14 17:15 [PATCH 0/5] uprobes: handle_swbp() fixes Oleg Nesterov
2012-09-14 17:15 ` [PATCH 1/5] uprobes: Do not leak UTASK_BP_HIT if find_active_uprobe() fails Oleg Nesterov
2012-09-14 17:35 ` Oleg Nesterov
2012-09-20 13:53 ` Srikar Dronamraju
2012-09-14 17:15 ` [PATCH 2/5] uprobes: Do not setup ->active_uprobe/state prematurely Oleg Nesterov
2012-09-20 13:55 ` Srikar Dronamraju
2012-09-14 17:15 ` [PATCH 3/5] uprobes: Fix UPROBE_SKIP_SSTEP checks in handle_swbp() Oleg Nesterov
2012-09-15 7:39 ` Ananth N Mavinakayanahalli
2012-09-15 15:01 ` Oleg Nesterov
2012-09-17 17:20 ` Srikar Dronamraju
2012-09-18 16:07 ` Oleg Nesterov
2012-09-20 14:43 ` Srikar Dronamraju [this message]
2012-09-24 20:08 ` Oleg Nesterov
2012-09-29 17:42 ` Oleg Nesterov
2012-09-20 14:05 ` Srikar Dronamraju
2012-09-14 17:16 ` [PATCH 4/5] uprobes: Kill UTASK_BP_HIT state Oleg Nesterov
2012-09-16 14:38 ` Oleg Nesterov
2012-09-20 14:06 ` Srikar Dronamraju
2012-09-14 17:16 ` [PATCH 5/5] uprobes: Move clear_thread_flag(TIF_UPROBE) to uprobe_notify_resume() Oleg Nesterov
2012-09-20 14:06 ` 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=20120920144311.GF27880@linux.vnet.ibm.com \
--to=srikar@linux.vnet.ibm.com \
--cc=ananth@in.ibm.com \
--cc=anton@redhat.com \
--cc=bigeasy@linutronix.de \
--cc=jkenisto@linux.vnet.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=oleg@redhat.com \
--cc=peterz@infradead.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.