This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
RE: Questions about kprobes implementation on SMP and preemptible kernels
- From: rsmadhvesh at vsnl dot net
- To: qbarnes at urbana dot css dot mot dot com, systemtap at sources dot redhat dot com
- Cc: madhvesh dot s at ap dot sony dot com
- Date: Tue, 16 Jan 2007 13:00:01 +0500
- Subject: RE: Questions about kprobes implementation on SMP and preemptible kernels
> There's a few dangling issues in my mind that have come up in trying
> to wrap up the remaining kprobes implementation for ARM. Maybe
> these are more general Linux kernel programming exception handling
> questions on SMP and preemptible configurations, but since they're
> related to existing kprobes implementations, I'll ask them here.
.....
......
>
>
> Q #3:
> The ARM kprobes model uses an undefined instruction for its
> kprobe. This is necessary since ARM's breakpoint instruction (BKPT)
> triggers entry into the same CPU service mode as the kernel runs
> in. On ARM, this is bad to do. No problem though since undefined
> instructions have their own mode. Due to this, kprobe_handler() is
> called from ARM's undefined instruction handler, do_undefinstr().
> Currently interrupts remain disabled all the way through the
> kprobe's undef instruction exception handling into kprobe_handler()
> and up through returning. I would like to eventually change the
> code so that interrupts can be re-enabled at some point to reduce
> interrupt latency. When handling an undefined instruction the
> kernel is running in an exception context. Looking around at the
> kernel code, just running in Linux exception handler context is no
> guarantee of disabling preemption. Is this true? If so, I'd have
> to call preempt_disable() to prevent preemption before re-enabling
> interrupts.
I think that, while handling undefined instruction exception, only normal
interrupts are disabled and fast interrupts are still in enabled state. I think
in my ARM kprobes code we disabled both the interrupts while preparing
for single step and restored previous state while doing resume . So
without disabling fast interrupts, kprobes work, but requires full testing
with nested interrupts etc
If processor is explicitly disabling normal interrupts when undef exception occurs,
is it ok to (en/dis)able while processing in exception handler?
-Madhvesh