Message-ID: <45140E33.9030509@opersys.com>
Date:	Fri, 22 Sep 2006 12:24:19 -0400
From:	Karim Yaghmour <karim@...rsys.com>
To:	Mathieu Desnoyers <compudj@...stal.dyndns.org>
CC:	Ingo Molnar <mingo@...e.hu>, Martin Bligh <mbligh@...gle.com>,
	"Frank Ch. Eigler" <fche@...hat.com>,
	Masami Hiramatsu <masami.hiramatsu.pt@...achi.com>,
	prasanna@...ibm.com, Andrew Morton <akpm@...l.org>,
	Paul Mundt <lethal@...ux-sh.org>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	Jes Sorensen <jes@....com>, Tom Zanussi <zanussi@...ibm.com>,
	Richard J Moore <richardj_moore@...ibm.com>,
	Michel Dagenais <michel.dagenais@...ymtl.ca>,
	Christoph Hellwig <hch@...radead.org>,
	Greg Kroah-Hartman <gregkh@...e.de>,
	Thomas Gleixner <tglx@...utronix.de>,
	William Cohen <wcohen@...hat.com>, ltt-dev@...fik.org,
	systemtap@...rces.redhat.com, Alan Cox <alan@...rguk.ukuu.org.uk>
Subject: Re: [PATCH] Linux Kernel Markers 0.5 for Linux 2.6.17 (with probe
 management)


Funny, I never thought I'd be defending djprobes ...

Mathieu Desnoyers wrote:
> 2 bytes jump + 3 bytes nops.. Yes, it should modify it without causing an
> illegal instruction, but how ? Are you aware that their approach has to :
> - put an int3
> - wait for _all_ the CPUs to execute this int3
> - then change the 5 bytes instruction
> 
> I can think of a lot of cases where the CPUs will never execute this int3.
> Probably that sending an IPI or launching a kernel thread on each CPU to make
> sure that this int3 is executed could give more guarantees there. But my point
> is not even there : I have seen very skillful teams work hard on those
> hardware-caused problems for years and the result is still not usable. It looks
> to me like a race between software developers and hardware manufacturers, where
> the software guy is always one step behind. This kind of scenario happens when
> you want to use an architecture in a way it was not designed and tested for.
> 
> As long as CPU manufacturers won't design for live instruction patching (and why
> should they do that ? the in3 breakpoint is all what is needed from their
> perspective), this will be a race where software developers will lose.

I'm with you all the way if we're talking about patching instructions
which are less than 5 bytes. And I must fault djprobes backers
for their insistence on trying to get it to work for all possible
instruction lengths. But in the specific case discussed between
Hiramatsu-san and myself (5 byte short jmp + nops) I have no reason
to believe it doesn't work. Continuing to try to get it to work on
any instruction length can be argued to be a waste of time, but not
what has been talked of of late.

With regards to all CPUs executing the int3, here's a rather savage,
but effective way of making this work:
- launch one thread per cpu (as you explained)
- have each thread make a direct jump to the location of the int3
- catch the int3 and kill active thread if this is a forced jump
This is deterministic.

So if your proposal is to amend the markup to use the short-jmp+nops
at every marker site instead of my earlier suggestion for the bprobes
thing, I'm all with you.

And I agree, 5 NOPs is *not* the right thing. 1 short jmp + 3 nops,
this works.

Karim
-- 
President  / Opersys Inc.
Embedded Linux Training and Expertise
www.opersys.com  /  1.866.677.4546
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists