From: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
To: "H. Peter Anvin" <hpa@zytor.com>
Cc: Ananth N Mavinakayanahalli <ananth@in.ibm.com>,
Peter Zijlstra <peterz@infradead.org>,
Srikar Dronamraju <srikar@linux.vnet.ibm.com>,
Ingo Molnar <mingo@elte.hu>,
Masami Hiramatsu <mhiramat@redhat.com>,
Mel Gorman <mel@csn.ul.ie>, Randy Dunlap <rdunlap@xenotime.net>,
Linus Torvalds <torvalds@linux-foundation.org>,
Roland McGrath <roland@redhat.com>,
Oleg Nesterov <oleg@redhat.com>, Mark Wielaard <mjw@redhat.com>,
LKML <linux-kernel@vger.kernel.org>,
Jim Keniston <jkenisto@linux.vnet.ibm.com>,
Frederic Weisbecker <fweisbec@gmail.com>,
"Frank Ch. Eigler" <fche@redhat.com>,
Andrew Morton <akpm@linux-foundation.org>,
Andrea Arcangeli <aarcange@redhat.com>,
Hugh Dickins <hugh.dickins@tiscali.co.uk>,
Rik van Riel <riel@redhat.com>,
"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
Subject: Re: [PATCH v3 0/10] Uprobes v3
Date: Wed, 12 May 2010 13:59:24 -0400 [thread overview]
Message-ID: <20100512175924.GB15953@Krystal> (raw)
In-Reply-To: <4BEADD94.6080501@zytor.com>
* H. Peter Anvin (hpa@zytor.com) wrote:
> On 05/12/2010 07:46 AM, Mathieu Desnoyers wrote:
> >
> > Now the tricky case is the sequence: instruction A -> int3 -> instruction B,
> > because a core can only see "instruction A -> instruction B" without any
> > core synchronization whatsoever, and may not see the int3. That's where the
> > djprobes logic (with IPIs to all cores) comes into play. But as long as we stick
> > to "insn A -> int3 -> insn A", things can be done very simply.
> >
> > By the way, kprobes rely on the assumption that it is OK to put a breakpoint
> > atomically and to put back the original instruction afterward.
> >
>
> Keep in mind the following corner case, though:
>
> insnA -> int3@A -> insnA
> insnB -> int3@B -> insnB
>
> It is now possible for the core to hit int3@A, without the int3@B being
> there. The int3 handler *has* to be able to handle any of the int3's
> put in place, quite possibly out of order, until a core serialization is
> performed.
Indeed. I would add that this out-of-order observation of breakpoint
modification is already expected, because other cores may be executing arbitrary
code when we add the two breakpoints (either insnA, B, or somewhere in between,
or somewhere else entirely).
Basically, we can make no assumption about the order in which the two stores
will be seen by other CPUs. But I can't imagine a debugger expecting these two
stores to be observed in order.
If we ever want to provide a _guarantee_ that starting from a certain point all
CPUs will see a set of breakpoint, then we need to issue a core serializing
instruction on all CPUs. This would determine the "quiescent state" of the CPUs,
starting from which all of them see the breakpoints.
Thanks,
Mathieu
>
> -hpa
>
> --
> H. Peter Anvin, Intel Open Source Technology Center
> I work for Intel. I don't speak on their behalf.
>
--
Mathieu Desnoyers
Operating System Efficiency R&D Consultant
EfficiOS Inc.
http://www.efficios.com
next prev parent reply other threads:[~2010-05-12 17:59 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-05-06 18:01 [PATCH v3 0/10] Uprobes v3 Srikar Dronamraju
2010-05-06 18:01 ` [PATCH v3 1/10] X86 instruction analysis: Move Macro W to insn.h Srikar Dronamraju
2010-05-06 18:02 ` [PATCH v3 2/10] User Space Breakpoint Assistance Layer Srikar Dronamraju
2010-05-06 18:02 ` [PATCH v3 3/10] x86 support for User space breakpoint assistance Srikar Dronamraju
2010-05-06 18:02 ` [PATCH v3 4/10] Slot allocation for execution out of line (XOL) Srikar Dronamraju
2010-05-06 18:02 ` [PATCH v3 5/10] Uprobes Implementation Srikar Dronamraju
2010-05-06 18:02 ` [PATCH v3 6/10] x86 support for Uprobes Srikar Dronamraju
2010-05-06 18:03 ` [PATCH v3 7/10] samples: Uprobes samples Srikar Dronamraju
2010-05-06 18:03 ` [PATCH v3 8/10] Uprobes documentation Srikar Dronamraju
2010-05-06 18:03 ` [PATCH v3 9/10] trace: uprobes trace_event interface Srikar Dronamraju
2010-05-06 18:03 ` [PATCH v3 10/10] perf: perf interface for uprobes Srikar Dronamraju
2010-05-06 23:13 ` Masami Hiramatsu
2010-05-07 2:24 ` Srikar Dronamraju
2010-05-07 17:53 ` Masami Hiramatsu
2010-05-09 11:18 ` Srikar Dronamraju
2010-05-11 20:59 ` [PATCH v3 0/10] Uprobes v3 Peter Zijlstra
2010-05-12 10:25 ` Srikar Dronamraju
2010-05-12 12:13 ` Peter Zijlstra
2010-05-12 13:27 ` Ananth N Mavinakayanahalli
2010-05-12 13:39 ` Peter Zijlstra
2010-05-12 14:04 ` Ananth N Mavinakayanahalli
2010-05-12 14:46 ` Mathieu Desnoyers
2010-05-12 16:55 ` H. Peter Anvin
2010-05-12 17:59 ` Mathieu Desnoyers [this message]
2010-05-13 12:07 ` Srikar Dronamraju
2010-05-12 10:38 ` Frederic Weisbecker
2010-05-12 13:39 ` Srikar Dronamraju
2010-05-12 14:53 ` Frederic Weisbecker
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=20100512175924.GB15953@Krystal \
--to=mathieu.desnoyers@efficios.com \
--cc=aarcange@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=ananth@in.ibm.com \
--cc=fche@redhat.com \
--cc=fweisbec@gmail.com \
--cc=hpa@zytor.com \
--cc=hugh.dickins@tiscali.co.uk \
--cc=jkenisto@linux.vnet.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mel@csn.ul.ie \
--cc=mhiramat@redhat.com \
--cc=mingo@elte.hu \
--cc=mjw@redhat.com \
--cc=oleg@redhat.com \
--cc=paulmck@linux.vnet.ibm.com \
--cc=peterz@infradead.org \
--cc=rdunlap@xenotime.net \
--cc=riel@redhat.com \
--cc=roland@redhat.com \
--cc=srikar@linux.vnet.ibm.com \
--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