lkml.org 
[lkml]   [2015]   [Feb]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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




\
 
 \ /
  Last update: 2015-02-24 11:41    [W:0.121 / U:0.132 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site