(2013/11/11 19:58), Will Deacon wrote: > On Mon, Nov 11, 2013 at 10:51:52AM +0000, Masami Hiramatsu wrote: >> (2013/11/11 16:54), Masami Hiramatsu wrote: >>>>>> In fact, how do you avoid a race with hardware breakpoints? E.g., >>>>>> somebody >>>>>> places a hardware breakpoint on an instruction in the kernel for which >>>>>> kprobes has patched in a brk. We take the hardware breakpoint, disable >>>>>> the >>>>>> breakpoint and set up a single step before returning to the brk. The brk >>>>>> then traps, but we must take care not to disable single-step and/or >>>>>> unmask >>>>>> debug exceptions, because that will cause the hardware breakpoint code to >>>>>> re-arm its breakpoint before we've stepped off the brk instruction. >>>>> >>>>> Hmm, frankly to say, this kind of race issue is not seriously discussed >>>>> on x86 too, since kgdb is still a special tool (not used on the production >>>>> system). >>>>> I think under such situation kgdb operator must have full control of the >>>>> system, and he can (and has to) avoid such kind of race. >>>> Masami, >>>> >>>> Hmm I think in same lines, but not sure if we expect kprobes to be >>>> able to work fool-proof along with kgdb or hw breakpoints ? >>> >>> For hw breakpoint, yes, we finally get check each other to safely >>> use it even if one rejects the other one at some points(address). >>> Since the hw breakpoint is already open for normal user via perf, >>> we should do it. But the policy still needs to be discussed. >> >> OK, I've ensured that the hw_breakpoint (from perf) can work >> with kprobes (from ftrace) at the same address on x86. >> So if arm64 already support hw_breakpoint on perf, kprobes should >> work with it. > > Single-stepping on x86 is different to the step behaviour on arm64 afaik. On > ARM, we have to manually remove the breakpoint, perform a single-step, then > add the breakpoint again. If we re-enable debug exceptions in the kprobe > handler, the step will complete early and we'll never step off the > breakpoint.
I'm unsure about arm64's debug feature behavior, what does happen when it performs a single-step on sw-breakpoint? > Sandeepa: I think you need to retry Masami's test on the arm64 model, since > I'm fairly sure it won't work as expected without some additional code. OK, anyway, for testing same one, we need to port ftrace first. So the next plan is to make a kprobe module to put a probe (which just printk something) on a specific function (e.g. vfs_symlink), and run perf record with hw-breakpoint as below $ perf record -e "mem:0xXXXXXX:k" ln -s /dev/null /tmp/foo Note that 0xXXXXXX is the address of vfs_symlink. After that, you can see the message in dmesg and also check the perf result with "sudo perf script --dump" (you can find a PERF_RECORD_SAMPLE entry if it works) Thank you, -- Masami HIRAMATSU IT Management Research Dept. Linux Technology Center Hitachi, Ltd., Yokohama Research Laboratory E-mail: masami.hiramatsu...@hitachi.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
