RE: Questions about kprobes implementation on SMP and preemptible kernels

[rsmadhvesh at vsnl dot net]

> 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