linux-dev - Linux kernel development work

Age	Commit message (Collapse)	Author	Files	Lines
2008-09-01	[ARM] 5221/1: fix ldm/stm emulation for kprobes	Nicolas Pitre	1	-2/+2
	Logic for the p bit was reversed. Signed-off-by: Nicolas Pitre <nico@marvell.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2008-04-28	kprobes/arm: fix decoding of arithmetic immediate instructions	Lennert Buytenhek	1	-1/+1
	The ARM kprobes arithmetic immediate instruction decoder (space_cccc_001x()) was accidentally zero'ing out not only the Rn and Rd arguments, but the lower nibble of the immediate argument as well -- this patch fixes this. Signed-off-by: Lennert Buytenhek <buytenh@marvell.com> Acked-by: Nicolas Pitre <nico@marvell.com>
2008-01-26	ARM kprobes: instruction single-stepping support	Quentin Barnes	1	-0/+1529
	This is the code implementing instruction single-stepping for kprobes on ARM. To get around the limitation of no Next-PC and no hardware single- stepping, all kprobe'd instructions are split into three camps: simulation, emulation, and rejected. "Simulated" instructions are those instructions which behavior is reproduced by straight C code. "Emulated" instructions are ones that are copied, slightly altered and executed directly in the instruction slot to reproduce their behavior. "Rejected" instructions are ones that could be simulated, but work hasn't been put into simulating them. These instructions should be very rare, if not unencountered, in the kernel. If ever needed, code could be added to simulate them. One might wonder why this and the ptrace singlestep facility are not sharing some code. Both approaches are fundamentally different because the ptrace code regains control after the stepped instruction by installing a breakpoint after the instruction itself, and possibly at the location where the instruction might be branching to, instead of simulating or emulating the target instruction. The ptrace approach isn't suitable for kprobes because the breakpoints would have to be moved back, and the icache flushed, everytime the probe is hit to let normal code execution resume, which would have a significant performance impact. It is also racy on SMP since another CPU could, with the right timing, sail through the probe point without being caught. Because ptrace single-stepping always result in a different process to be scheduled, the concern for performance is much less significant. On the other hand, the kprobes approach isn't (currently) suitable for ptrace because it has no provision for proper user space memory protection and translation, and even if that was implemented, the gain wouldn't be worth the added complexity in the ptrace path compared to the current approach. So, until kprobes does support user space, both kprobes and ptrace are best kept independent and separate. Signed-off-by: Quentin Barnes <qbarnes@gmail.com> Signed-off-by: Abhishek Sagar <sagar.abhishek@gmail.com> Signed-off-by: Nicolas Pitre <nico@marvell.com>