Re: Re: Kprobes: pre-handler with interrupts enabled - is it possible?

[Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>]

(2015/02/24 15:04), Eugene Shatokhin wrote:
> 24.02.2015 06:47, Masami Hiramatsu пишет:
>> No, that is not allowed. I mean, you can do anything you want to do
>> on your handler (enabling preemption/irq etc.) but the result may be
>> not safe (it can crash your kernel, but it's not a kprobes' bug).
> 
> Yes, that is why I am asking.
> 
>> Actually, enable interrupts on kprobe handlers can cause reentering
>> kprobes (by kprobes on interrupt handlers), and currently kprobe skips
>> all those reentered kprobes.
>> Is it acceptable that some of your kprobe handlers are not fired when
>> hitting?
> 
> I think, yes. When a software breakpoint hits, my system decodes the 
> instruction, finds the address that is about to be accessed and tries to 
> place a hardware breakpoint on that memory area.
> 
> There are only 4 hardware breakpoints a CPU can use on x86, so if the 
> software breakpoint hits too often, the system will not be able to 
> process all hits anyway because all HW breakpoints may be already in use.
> 
>> Would you mean sleep on your handler??
> 
> No, I use mdelay(). It is, in essence, a busy-wait loop as far as I 
> know. The delay intervals may vary, the default is 5 jiffies.

Hmm, here I couldn't understand. If mdelay() does busy-wait loop, why
would you like to enable irq??
Other code doesn't work on the core while waiting.

Thank you,


-- 
Masami HIRAMATSU
Software Platform Research Dept. Linux Technology Research Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: masami.hiramatsu.pt@hitachi.com