Messages in this thread | | | Date | Tue, 24 Feb 2015 19:24:32 +0900 | From | Masami Hiramatsu <> | Subject | Re: Re: Kprobes: pre-handler with interrupts enabled - is it possible? |
| |
(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
| |