From: Dongdong Deng <libfetion@gmail.com>
To: linux-kernel@vger.kernel.org
Cc: ananth@in.ibm.com, anil.s.keshavamurthy@intel.com,
davem@davemloft.net, mhiramat@redhat.com, arjan@infradead.org,
jkenisto@us.ibm.com
Subject: Did we really need to clear the IF flag at prepare_singlestep() of x86 kprobes?
Date: Tue, 12 Jan 2010 19:09:35 +0800 [thread overview]
Message-ID: <ce2c83091001120309q19d58b45kc27610fc31ce01dc@mail.gmail.com> (raw)
Hi Kprobe experts,
I have a doubt about the handling "X86_EFLAGS_IF" at prepare_singlestep(),
Could you give me some suggestions?
arch/x86/kernel/kprobes.c:
406 static void __kprobes prepare_singlestep(struct kprobe *p, struct
pt_regs *regs)
407 {
408 clear_btf();
409 regs->flags |= X86_EFLAGS_TF;
410 regs->flags &= ~X86_EFLAGS_IF;
...
}
for 410 line: Kprobe is intend to disable interrupt during the single step.
I think it is enough that just setting X86_EFLAGS_TF as following reasons.
******************
Reason 1: "debug trap" was initalized as an interrupt gate
arch/x86/kernel/traps.c:892: set_intr_gate_ist(1, &debug, DEBUG_STACK);
The "debug trap" was initalized as an interrupt gate, thereby during the
hanld function of debug exceptions, the X86_EFLAGS_IF have been
cleared automatically.
******************
Reason 2: the priority among debug exceptions and interrupts
Intel® 64 and IA-32 Architectures Software Developer’s Manual Volume
3A, page 5-11:
If more than one exception or interrupt is pending at an instruction
boundary, the
processor services them in a predictable order. Table 5-2 shows the
priority among
classes of exception and interrupt sources.
Table 5-2. Priority Among Simultaneous Exceptions and Interrupts
Priority Description
1 (Highest) Hardware Reset and Machine Checks
- RESET
- Machine Check
2 Trap on Task Switch
- T flag in TSS is set
3 External Hardware Interventions
- FLUSH
- STOPCLK
- SMI
- INIT
4 Traps on the Previous Instruction
- Breakpoints
- Debug Trap Exceptions (TF flag set or data/I-O breakpoint)
5 Nonmaskable Interrupts (NMI)
6 Maskable Hardware Interrupts
>From the table we could see debug exceptions lies in priority 4 and
external interrupt lies
in priority 6.
Thereby the processor will handle Debug Trap Exceptions first, then
handle external interrupt.
******************
Combining those reasons: maybe we could remove "regs->flags &= ~X86_EFLAGS_IF;".
(It just a example about X86_EFLAGS_IF and kprobe here.)
diff --git a/arch/x86/kernel/kprobes.c b/arch/x86/kernel/kprobes.c
index 5b8c750..dfd719a 100644
--- a/arch/x86/kernel/kprobes.c
+++ b/arch/x86/kernel/kprobes.c
@@ -407,7 +407,6 @@ static void __kprobes prepare_singlestep(struct
kprobe *p, struct pt_regs *regs)
{
clear_btf();
regs->flags |= X86_EFLAGS_TF;
- regs->flags &= ~X86_EFLAGS_IF;
/* single step inline if the instruction is an int3 */
if (p->opcode == BREAKPOINT_INSTRUCTION)
regs->ip = (unsigned long)p->addr;
What do you think about it?
I know I must be make a mistake here, could you correct me?
Thanks,
Dongdong.
next reply other threads:[~2010-01-12 11:09 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-01-12 11:09 Dongdong Deng [this message]
2010-01-12 16:06 ` Arjan van de Ven
2010-01-13 5:25 ` Dongdong Deng
2010-01-13 6:18 ` Masami Hiramatsu
2010-01-14 6:45 ` Dongdong Deng
2010-01-14 20:06 ` Masami Hiramatsu
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=ce2c83091001120309q19d58b45kc27610fc31ce01dc@mail.gmail.com \
--to=libfetion@gmail.com \
--cc=ananth@in.ibm.com \
--cc=anil.s.keshavamurthy@intel.com \
--cc=arjan@infradead.org \
--cc=davem@davemloft.net \
--cc=jkenisto@us.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mhiramat@redhat.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
all inboxes | Powered by JetHome®