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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
