From: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
To: Arjan van de Ven <arjan@infradead.org>
Cc: Ingo Molnar <mingo@elte.hu>,
Peter Zijlstra <a.p.zijlstra@chello.nl>,
prasad@linux.vnet.ibm.com, linux-kernel@vger.kernel.org,
tglx@linutronix.de, Christoph Hellwig <hch@infradead.org>,
"Frank Ch. Eigler" <fche@redhat.com>
Subject: Re: [RFC PATCH 1/2] Marker probes in futex.c
Date: Wed, 16 Apr 2008 10:48:14 -0400 [thread overview]
Message-ID: <20080416144814.GA15554@Krystal> (raw)
In-Reply-To: <20080416072416.7b9ff3d2@laptopd505.fenrus.org>
* Arjan van de Ven (arjan@infradead.org) wrote:
> On Wed, 16 Apr 2008 10:00:09 -0400
> Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca> wrote:
>
>
> > > > > If we want to support NMI context and have the ability to
> > > > > instrument preemptable code without too much headache, we must
> > > > > insure that every modification will leave the code in a
> > > > > "correct" state and that we do not grow the size of any
> > > > > reachable instruction. Also, we must insure gcc did not put
> > > > > code between these instructions. Modifying non-relocatable
> > > > > instructions would also be a pain, since we would have to deal
> > > > > with instruction pointer relocation in the breakpoint code when
> > > > > the code modification is being done.
> > >
> > > you also need to make sure no cpu is executing that code ever..
> > > but you already deal with that right?
> > >
> >
> > By "insure that every modification will leave the code in a "correct"
> > state", I mean that at any given time before, during or after the code
> > modification, if an NMI comes on any CPU and try to run the modified
> > code, it should have a valid version of the code to execute. Does it
> > make more sense ?
>
> I understand your words. My concern is that I don't quite understand how you
> guarantee that you'll not be executing the code you're modifying.
> Just saying "it's consistent before and after" sounds nice but probably isn't
> enough to be safe.
>
Ah, I see. I insert a breakpoint and execute a bypass rather than the
code being modified. I only put back the 1st instruction byte after the
rest of the instruction has been modified.
>
>
> > Not only does the compare and jmp need to be consecutive, but the movb
> > $0x0,%al also does. I *could* try to detect specific code inserted in
> > between, but I really have to make sure I don't get burned by the
> > compiler inserting a jmp there.
>
> I wonder if just sticking in 2 barriers around your code make gcc stop moving stuff too much
>
I'm not sure people would like the side-effect for the rest of
optimizations, but it should be tried.
Mathieu
--
Mathieu Desnoyers
Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68
next prev parent reply other threads:[~2008-04-16 14:48 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-04-15 11:50 [RFC PATCH 0/2] Debugging infrastructure for Futexes using Markers K. Prasad
2008-04-15 11:53 ` [RFC PATCH 1/2] Marker probes in futex.c K. Prasad
2008-04-15 11:55 ` [RFC PATCH 2/2] Marker handler for the probes in futex file K. Prasad
2008-04-15 12:02 ` [RFC PATCH 1/2] Marker probes in futex.c Peter Zijlstra
2008-04-15 12:32 ` Mathieu Desnoyers
2008-04-15 12:50 ` Alexey Dobriyan
2008-04-15 16:13 ` K. Prasad
2008-04-15 12:56 ` Peter Zijlstra
2008-04-15 13:17 ` Ingo Molnar
2008-04-15 13:47 ` Mathieu Desnoyers
2008-04-15 14:04 ` Ingo Molnar
2008-04-15 14:21 ` Frank Ch. Eigler
2008-04-15 14:39 ` Mathieu Desnoyers
2008-04-15 16:48 ` Ingo Molnar
2008-04-15 21:38 ` Mathieu Desnoyers
2008-04-16 13:17 ` Ingo Molnar
2008-04-16 13:46 ` Arjan van de Ven
2008-04-16 14:00 ` Mathieu Desnoyers
2008-04-16 14:24 ` Arjan van de Ven
2008-04-16 14:29 ` Ingo Molnar
2008-04-16 14:48 ` Mathieu Desnoyers [this message]
2008-04-16 15:32 ` Arjan van de Ven
2008-04-16 15:39 ` Mathieu Desnoyers
2008-04-16 20:10 ` text_poke, vmap and vmalloc on x86_64 Mathieu Desnoyers
2008-04-16 21:22 ` Mathieu Desnoyers
2008-04-15 13:25 ` [RFC PATCH 1/2] Marker probes in futex.c Mathieu Desnoyers
2008-04-16 15:51 ` Peter Zijlstra
2008-04-17 19:19 ` Frank Ch. Eigler
2008-04-17 20:16 ` Mathieu Desnoyers
2008-04-19 12:13 ` K. Prasad
2008-04-19 21:33 ` Mathieu Desnoyers
2008-04-18 6:56 ` Peter Zijlstra
2008-04-15 15:52 ` K. Prasad
2008-04-16 15:51 ` Peter Zijlstra
2008-04-17 22:02 ` Frank Ch. Eigler
2008-04-18 6:46 ` Peter Zijlstra
2008-04-18 14:29 ` Frank Ch. Eigler
2008-04-19 12:28 ` K. Prasad
2008-04-19 14:52 ` Peter Zijlstra
2008-04-19 18:03 ` Frank Ch. Eigler
2008-04-19 18:29 ` Peter Zijlstra
2008-04-19 18:48 ` Frank Ch. Eigler
2008-04-22 17:50 ` Nicholas Miell
2008-04-19 14:13 ` Mathieu Desnoyers
2008-04-19 14:56 ` Peter Zijlstra
2008-04-18 10:44 ` Andrew Morton
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=20080416144814.GA15554@Krystal \
--to=mathieu.desnoyers@polymtl.ca \
--cc=a.p.zijlstra@chello.nl \
--cc=arjan@infradead.org \
--cc=fche@redhat.com \
--cc=hch@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=prasad@linux.vnet.ibm.com \
--cc=tglx@linutronix.de \
/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.