From: Eugene Shatokhin <eugene.shatokhin@rosalab.ru>
To: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: Kprobes: pre-handler with interrupts enabled - is it possible?
Date: Tue, 24 Feb 2015 09:04:55 +0300 [thread overview]
Message-ID: <54EC1487.4020902@rosalab.ru> (raw)
In-Reply-To: <54EBF464.7020704@hitachi.com>
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.
Regards,
Eugene
--
Eugene Shatokhin, ROSA
www.rosalab.com
next prev parent reply other threads:[~2015-02-24 6:04 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-02-23 15:04 Kprobes: pre-handler with interrupts enabled - is it possible? Eugene Shatokhin
2015-02-24 3:47 ` Masami Hiramatsu
2015-02-24 6:04 ` Eugene Shatokhin [this message]
2015-02-24 10:24 ` Masami Hiramatsu
2015-03-09 11:04 ` Eugene Shatokhin
2015-03-22 17:26 ` Eugene Shatokhin
[not found] <54ED88BC.8080705@rosalab.ru>
2015-02-25 11:20 ` Eugene Shatokhin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=54EC1487.4020902@rosalab.ru \
--to=eugene.shatokhin@rosalab.ru \
--cc=linux-kernel@vger.kernel.org \
--cc=masami.hiramatsu.pt@hitachi.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox