RE: [Fault-injection-developer] LKML threads about kprobes

[Zhuang, L. <lou...@in...>]

Still no. :-) 

Debug Register can only capture the data access *AFTER* access has
completed. It is a hardware restriction in IA32.

-----Original Message-----
From: Lynch, Rusty 
Sent: Friday, November 08, 2002 11:14 AM
To: Wang, Stanley; Wang, Frank; Zhuang, Louis; Lynch, Rusty;
'fau...@so...'
Subject: RE: [Fault-injection-developer] LKML threads about kprobes


What about using the debug registers via the kwatch functions?  Does that
solve our MMIO needs?

	-rusty

-----Original Message-----
From: Wang, Stanley 
Sent: Thursday, November 07, 2002 7:08 PM
To: Wang, Frank; Zhuang, Louis; Lynch, Rusty;
'fau...@so...'
Subject: RE: [Fault-injection-developer] LKML threads about kprobes


Kprobes can only capture a specific instruction (by specified instruction's
address).
It cannot capture all accesses to a specific MMIO address :)
-----Original Message-----
From: Wang, Frank [mailto:fra...@in...]
Sent: 2002?11?8? 10:58
To: Zhuang, Louis; Lynch, Rusty; 'fau...@so...'
Subject: RE: [Fault-injection-developer] LKML threads about kprobes


"With kprobes you can register to have a handler called before a specific
address is executed", is this correct?
The idea of capturing pagefault exception is to capture an MMIO address
access. If the above sentence is correct, why we continue to capture
pagefault exception?
Or kprobes enables you capture a specific address access but it must be with
interrupt-enabled? Why is it? Can we change the kprobe to enable this in
interrupt-disabled condition?
-----Original Message-----
From: Zhuang, Louis [mailto:lou...@in...]
Sent: 2002?11?8? 9:31
To: Lynch, Rusty; 'fau...@so...'
Subject: RE: [Fault-injection-developer] LKML threads about kprobes


Yes, It is not enough. FITH needs capture pagefault exception in
interrept-disabled condition, just as kprobes for do_int3/do_debug. 
-----Original Message-----
From: Lynch, Rusty 
Sent: Friday, November 08, 2002 9:02 AM
To: Zhuang, Louis; Lynch, Rusty; 'fau...@so...'
Subject: RE: [Fault-injection-developer] LKML threads about kprobes


Ok, now I'm confused.  With kprobes you can register to have a handler
called before a specific address is executed.  Why is that not enough?

    -rusty
-----Original Message-----
From: Zhuang, Louis 
Sent: Thursday, November 07, 2002 4:48 PM
To: Lynch, Rusty; 'fau...@so...'
Subject: RE: [Fault-injection-developer] LKML threads about kprobes


Hi, Rusty
    We did work based on kprobes. After we investigated kprobes, we found
kprobes had removed GKHI support. So we need to find another way to get
additional control in exception handling... This is a problem we need to
solve in 2.5.x
-----Original Message-----
From: Lynch, Rusty 
Sent: Friday, November 08, 2002 1:30 AM
To: Zhuang, Louis; 'fau...@so...'
Subject: RE: [Fault-injection-developer] LKML threads about kprobes


It looks to me like kprobes will make it in the kernel.  Why don't we work
under that assumption for now.

    -rusty
-----Original Message-----
From: Zhuang, Louis [mailto:lou...@in...]
Sent: Thursday, November 07, 2002 12:27 AM
To: 'fau...@so...'
Subject: RE: [Fault-injection-developer] LKML threads about kprobes


Humm... kprobes in 2.5.x removed GKHI(General Kernel Hook Interface)
mechanism, which FITH needed. But all kprobes patch in 2.5.x is useful for
FITH, such as do_int3/do_debug interrupt gate. We need a mederate patch to
hook these exception for FITH. But I wonder if this can be accepted by LKML.
Any comments
    -Louis