fault-injection-developer Mailing List for Fault Injection Test Harness (Page 12)

Status: Alpha

Brought to you by: rustyl

fault-injection-developer — Developer discussions about creating a fault injection test harness.

You can subscribe to this list here.

2002	Jan	Feb	Mar	Apr	May	Jun (1)	Jul	Aug (13)	Sep (2)	Oct (49)	Nov (69)	Dec (70)
2003	Jan (64)	Feb (41)	Mar (25)	Apr (18)	May (5)	Jun	Jul	Aug	Sep	Oct	Nov	Dec
2004	Jan	Feb	Mar	Apr	May	Jun (1)	Jul	Aug	Sep	Oct	Nov	Dec
2006	Jan	Feb	Mar	Apr	May	Jun	Jul (3)	Aug	Sep	Oct	Nov	Dec
2007	Jan	Feb	Mar	Apr	May (1)	Jun (1)	Jul	Aug	Sep	Oct	Nov	Dec
2008	Jan	Feb	Mar	Apr	May	Jun	Jul	Aug	Sep (1)	Oct (1)	Nov	Dec
2009	Jan (1)	Feb (2)	Mar	Apr	May	Jun	Jul	Aug	Sep	Oct	Nov	Dec
2011	Jan	Feb	Mar	Apr	May	Jun	Jul	Aug	Sep	Oct (1)	Nov	Dec
2014	Jan	Feb	Mar	Apr	May	Jun	Jul	Aug	Sep	Oct (1)	Nov (1)	Dec
2015	Jan	Feb	Mar	Apr	May	Jun	Jul	Aug	Sep	Oct	Nov	Dec (2)
2016	Jan (2)	Feb (5)	Mar (2)	Apr (1)	May (1)	Jun (1)	Jul (2)	Aug (1)	Sep	Oct	Nov	Dec
2017	Jan	Feb	Mar	Apr	May	Jun	Jul	Aug	Sep	Oct (4)	Nov	Dec

Flat | Threaded

<< < 1 .. 10 11 12 13 14 15 > >> (Page 12 of 15)

[Fault-injection-developer] RE: FITH test proposal

From: Gao, K. <kev...@in...> - 2002-11-14 01:38:46

For testing we split the new function of FITH into 3 testing aspect:=20
Codesegment support, Old opcode transform to codesegment fault =
injection,=20
and some shortcut for writing fsml.
=20
We will writes some special faultset to test the codesegment support.
That includes, DMA send/receive fault injection, band rates of serier
driver fault injection, etc.
=20
For old opcode transform, mostly we will use the old test case,
We thought if new version of FITH can pass these test, the compability
between old and new version is OK.
=20
To test the functionality of shortcut, Our test case should contain
all the shortcut format which FITH provide.
=20
Besides all the above test proposal, we still need test all the =
function
proveded by FITH, e.g. fith_print.
=20
=20
 Kevin Gao, SW Engineer, Intel Corporation.
Opinions expressed are those of the author and do not represent Intel
Corporation
=20
Intel China Software Lab.=20
Tel: 021-52574545 ext. 1271
iNet: 8-752-1271=20
=20
 -----Original Message-----
From: Zhuang, Louis=20
Sent: 2002=C4=EA11=D4=C213=C8=D5 16:17
To: Gao, Kevin; Wang, Frank; Wang, Stanley
Cc: 'fau...@li...'
Subject: RE: FITH test proposal


Could you give us some light about test environment/methods/processes?
=20
Louis Zhuang, SW Engineer, Intel Corporation.
My opinions are my own and NEVER the opinions of Intel Corporation.
=20
-----Original Message-----
From: Gao, Kevin=20
Sent: Wednesday, November 13, 2002 4:14 PM
To: Zhuang, Louis; Wang, Frank; Wang, Stanley
Cc: 'fau...@li...'
Subject: FITH test proposal
=20
FITH test plan:
=20
        Inject fault into IO read operation
        Inject fault into IO write operation
        Inject fault into MMIO read operation
        Inject fault into MMIO write operation
        Inject fault to lost a IRQ operation=20
        Inject fault to delay a IRQ operation
        Inject fault to overload IRQ operation
        Other attribute testing
        Inject fault into Sequence IO read operation
        Inject fault into Sequence IO write operation
        Inject fault into PCI configuration
        Inject fault into DMA send operation
        Inject fault into DMA receive operation
=20
Besides using our dummy driver, we will also use seriel driver to test =
the
functionality of FITH.
Our target is to test the compatiblity , and the new functionality of =
FITH.
=20
=20
Kevin Gao, SW Engineer, Intel Corporation.
Opinions expressed are those of the author and do not represent Intel
Corporation
=20
Intel China Software Lab.=20
Tel: 021-52574545 ext. 1271
iNet: 8-752-1271=20
=20
=20
=20

[Fault-injection-developer] RE: FITH test proposal

From: Zhuang, L. <lou...@in...> - 2002-11-13 08:19:15

Could you give us some light about test environment/methods/processes?

Louis Zhuang, SW Engineer, Intel Corporation.
My opinions are my own and NEVER the opinions of Intel Corporation.

-----Original Message-----
From: Gao, Kevin 
Sent: Wednesday, November 13, 2002 4:14 PM
To: Zhuang, Louis; Wang, Frank; Wang, Stanley
Cc: 'fau...@li...'
Subject: FITH test proposal

FITH test plan:

        Inject fault into IO read operation
        Inject fault into IO write operation
        Inject fault into MMIO read operation
        Inject fault into MMIO write operation
        Inject fault to lost a IRQ operation 
        Inject fault to delay a IRQ operation
        Inject fault to overload IRQ operation
        Other attribute testing
        Inject fault into Sequence IO read operation
        Inject fault into Sequence IO write operation
        Inject fault into PCI configuration
        Inject fault into DMA send operation
        Inject fault into DMA receive operation

Besides using our dummy driver, we will also use seriel driver to test the
functionality of FITH.
Our target is to test the compatiblity , and the new functionality of FITH.

Kevin Gao, SW Engineer, Intel Corporation.
Opinions expressed are those of the author and do not represent Intel
Corporation

Intel China Software Lab. 
Tel: 021-52574545 ext. 1271
iNet: 8-752-1271

[Fault-injection-developer] FITH test proposal

From: Gao, K. <kev...@in...> - 2002-11-13 08:16:10

FITH test plan:
 
        Inject fault into IO read operation
        Inject fault into IO write operation
        Inject fault into MMIO read operation
        Inject fault into MMIO write operation
        Inject fault to lost a IRQ operation 
        Inject fault to delay a IRQ operation
        Inject fault to overload IRQ operation
        Other attribute testing
        Inject fault into Sequence IO read operation
        Inject fault into Sequence IO write operation
        Inject fault into PCI configuration
        Inject fault into DMA send operation
        Inject fault into DMA receive operation
 
Besides using our dummy driver, we will also use seriel driver to test the
functionality of FITH.
Our target is to test the compatiblity , and the new functionality of FITH.
 
 
Kevin Gao, SW Engineer, Intel Corporation.
Opinions expressed are those of the author and do not represent Intel
Corporation
 
Intel China Software Lab. 
Tel: 021-52574545 ext. 1271
iNet: 8-752-1271

RE: [Fault-injection-developer] (no subject)

From: Gao, K. <kev...@in...> - 2002-11-13 01:12:29

I 've updated the test suite. Now it can run properly.
Please check the update test suite.
Thanks.

Kevin Gao, SW Engineer, Intel Corporation.
Opinions expressed are those of the author and do not represent Intel
Corporation
=20
Intel China Software Lab.=20
Tel: 021-52574545 ext. 1271
iNet: 8-752-1271=20
=20
=20


-----Original Message-----
From: Wang, Stanley [mailto:sta...@in...]=20
Sent: 2002=C4=EA11=D4=C212=C8=D5 14:11
To: Zhuang, Louis
Cc: SourceforgeFI mail list (E-mail)
Subject: [Fault-injection-developer] (no subject)


I've splitted the FITH into two parts: fith_core and fith_utility.
Please check the updated code.
Thanks.

Your Sincerely,
Stanley Wang=20

SW Engineer, Intel Corporation.
Intel China Software Lab.=20
Tel: 021-52574545 ext. 1171=20
iNet: 8-752-1171=20
=20
Opinions expressed are those of the author and do not represent Intel
Corporation


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Fault-injection-developer mailing list
Fau...@li...
https://lists.sourceforge.net/lists/listinfo/fault-injection-developer

[Fault-injection-developer] (no subject)

From: Wang, S. <sta...@in...> - 2002-11-12 06:12:57

I've splitted the FITH into two parts: fith_core and fith_utility.
Please check the updated code.
Thanks.

Your Sincerely,
Stanley Wang 

SW Engineer, Intel Corporation.
Intel China Software Lab. 
Tel: 021-52574545 ext. 1171 
iNet: 8-752-1171 
 
Opinions expressed are those of the author and do not represent Intel
Corporation

[Fault-injection-developer] RE: Fault-injection-developer digest, Vol 1 #26 - 2 msgs

From: Gao, K. <kev...@in...> - 2002-11-11 06:50:10

I think the proposal 1 is reasonable. So I support proposal 1.

RE: [Fault-injection-developer] Proposals for 2.5.x porting

From: Zhuang, L. <lou...@in...> - 2002-11-11 06:33:47

As we know now, do_pagefault has already been =A1=AEinterrupt =
gate=A1=AF. We needn=A1=AF
t change anymore.
=20
Louis Zhuang, SW Engineer, Intel Corporation.
My opinions are my own and NEVER the opinions of Intel Corporation.
=20
We=A1=AFd like to propose such candidates in our coming 2.5.x porting. =
Any
comments?
=20
Proposal 1:
          Changing =A1=AEdo_pagefault=A1=AF as =A1=AEinterrupt =
gate=A1=AF and putting a call
statement in =A1=AEdo_pagefault=A1=AF and =A1=AEdo_debug=A1=AF =
function, such as
              do_pagefault() {
                     if(fi_do_pagefault()) return;
                     =A1=AD.
              }
Advantage: Clean & Clear patch. Purpose in patch is explicit.
Disadvantage: do_pagefault is a *very* busy kernel path. Any changing =
in
that is hard to be accepted without important reason.
=20
=20
Proposal 2:
          Changing =A1=AEdo_pagefault=A1=AF as =A1=AEinterrupt =
gate=A1=AF and placing a
kprobe in =A1=AEdo_pagefault' function.
=20
Advantage: Do not change do_pagefault directly. We can remove the =
influence
in do_pagefault dynamically.=20
=20
Disadvantage: The code is very hard to understand and hard to maintain.
Kernel patch will experience two exceptions before got into =
fi_do_pagefault
(pagefault exception and debug [int3] exception). In such patch, kernel =
is
under a mixture metaphor. More, kprobes does not design to place hook =
in
exception handler.
=20
=20
Proposal 3:
          Using kwatch to monitor data access. Do not change kernel at =
all.
=20
Advantage: Needn=A1=AFt to change kernel.
=20
Disadvantage: Debugger register can only intercept data access *after*
accessing is completed. There are only 4 debugger registers in IA32
         =20
=20
Louis Zhuang, SW Engineer, Intel Corporation.
My opinions are my own and NEVER the opinions of Intel Corporation.
=20

[Fault-injection-developer] Proposals for 2.5.x porting

From: Zhuang, L. <lou...@in...> - 2002-11-11 05:45:34

We=A1=AFd like to propose such candidates in our coming 2.5.x porting. =
Any
comments?
=20
Proposal 1:
          Changing =A1=AEdo_pagefault=A1=AF as =A1=AEinterrupt =
gate=A1=AF and putting a call
statement in =A1=AEdo_pagefault=A1=AF and =A1=AEdo_debug=A1=AF =
function, such as
              do_pagefault() {
                     if(fi_do_pagefault()) return;
                     =A1=AD.
              }
Advantage: Clean & Clear patch. Purpose in patch is explicit.
Disadvantage: do_pagefault is a *very* busy kernel path. Any changing =
in
that is hard to be accepted without important reason.
=20
=20
Proposal 2:
          Changing =A1=AEdo_pagefault=A1=AF as =A1=AEinterrupt =
gate=A1=AF and placing a
kprobe in =A1=AEdo_pagefault' function.
=20
Advantage: Do not change do_pagefault directly. We can remove the =
influence
in do_pagefault dynamically.=20
=20
Disadvantage: The code is very hard to understand and hard to maintain.
Kernel patch will experience two exceptions before got into =
fi_do_pagefault
(pagefault exception and debug [int3] exception). In such patch, kernel =
is
under a mixture metaphor. More, kprobes does not design to place hook =
in
exception handler.
=20
=20
Proposal 3:
          Using kwatch to monitor data access. Do not change kernel at =
all.
=20
Advantage: Needn=A1=AFt to change kernel.
=20
Disadvantage: Debugger register can only intercept data access *after*
accessing is completed. There are only 4 debugger registers in IA32
         =20
=20
Louis Zhuang, SW Engineer, Intel Corporation.
My opinions are my own and NEVER the opinions of Intel Corporation.
=20

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

From: Wang, F. <fra...@in...> - 2002-11-08 05:15:14

also limited numbers of debug registers...

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


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

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

From: Wang, S. <sta...@in...> - 2002-11-08 03:47:02

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=C4=EA11=D4=C28=C8=D5 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=C4=EA11=D4=C28=C8=D5 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.=20
-----Original Message-----
From: Lynch, Rusty=20
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?
=20
    -rusty
-----Original Message-----
From: Zhuang, Louis=20
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=20
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.
=20
    -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

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

From: Wang, S. <sta...@in...> - 2002-11-08 03:47:02

There are only four debug register :)
We need more watch point in some complex test case.

> -----Original Message-----
> From: Lynch, Rusty=20
> Sent: 2002=E5=B9=B411=E6=9C=888=E6=97=A5 11:14
> To: Wang, Stanley; Wang, Frank; Zhuang, Louis; Lynch, Rusty;=20
> 'fau...@so...'
> Subject: RE: [Fault-injection-developer] LKML threads about kprobes
>=20
>=20
> What about using the debug registers via the kwatch=20
> functions?  Does that solve our MMIO needs?
>=20
> 	-rusty
>=20
> -----Original Message-----
> From: Wang, Stanley=20
> Sent: Thursday, November 07, 2002 7:08 PM
> To: Wang, Frank; Zhuang, Louis; Lynch, Rusty;=20
> 'fau...@so...'
> Subject: RE: [Fault-injection-developer] LKML threads about kprobes
>=20
>=20
> Kprobes can only capture a specific instruction (by specified=20
> 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;=20
> 'fau...@so...'
> Subject: RE: [Fault-injection-developer] LKML threads about kprobes
>=20
>=20
> "With kprobes you can register to have a handler called=20
> before a specific address is executed", is this correct?
> The idea of capturing pagefault exception is to capture an=20
> MMIO address access. If the above sentence is correct, why we=20
> continue to capture pagefault exception?
> Or kprobes enables you capture a specific address access but=20
> it must be with interrupt-enabled? Why is it? Can we change=20
> 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
>=20
>=20
> Yes, It is not enough. FITH needs capture pagefault exception=20
> in interrept-disabled condition, just as kprobes for=20
> do_int3/do_debug.=20
> -----Original Message-----
> From: Lynch, Rusty=20
> Sent: Friday, November 08, 2002 9:02 AM
> To: Zhuang, Louis; Lynch, Rusty;=20
> 'fau...@so...'
> Subject: RE: [Fault-injection-developer] LKML threads about kprobes
>=20
>=20
> Ok, now I'm confused.  With kprobes you can register to have=20
> a handler called before a specific address is executed.  Why=20
> is that not enough?
>=20
>     -rusty
> -----Original Message-----
> From: Zhuang, Louis=20
> Sent: Thursday, November 07, 2002 4:48 PM
> To: Lynch, Rusty; 'fau...@so...'
> Subject: RE: [Fault-injection-developer] LKML threads about kprobes
>=20
>=20
> Hi, Rusty
>     We did work based on kprobes. After we investigated=20
> kprobes, we found kprobes had removed GKHI support. So we=20
> need to find another way to get additional control in=20
> exception handling... This is a problem we need to solve in 2.5.x
> -----Original Message-----
> From: Lynch, Rusty=20
> Sent: Friday, November 08, 2002 1:30 AM
> To: Zhuang, Louis; 'fau...@so...'
> Subject: RE: [Fault-injection-developer] LKML threads about kprobes
>=20
>=20
> It looks to me like kprobes will make it in the kernel.  Why=20
> don't we work under that assumption for now.
>=20
>     -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
>=20
>=20
> Humm... kprobes in 2.5.x removed GKHI(General Kernel Hook=20
> Interface) mechanism, which FITH needed. But all kprobes=20
> patch in 2.5.x is useful for FITH, such as do_int3/do_debug=20
> interrupt gate. We need a mederate patch to hook these=20
> exception for FITH. But I wonder if this can be accepted by=20
> LKML. Any comments
>     -Louis
>=20

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

From: Rusty L. <ru...@li...> - 2002-11-08 03:45:52

So is the only reason for worrying about catching page faults so that we can
insert a fault when a specific memory mapped address is touched (or looked
at)?  If so then we should ask kprobes for that capability.  (It might
already be in the works.)

    -rusty

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


maybe a little more explanation.
In FITH, the PTE of watched memory address will be marked as 'absent'. When
driver accesses the memory, a page fault exception will be triggered. Our
FITH will catch the exception to do our stuffs. This needs a metaphor, the
interrupt vector table (IDT) entry of page fault exception should be an
'interrupt gate', not a 'trap gate', because driver may access watched
memory in interrupt handler which cause exception re-entry.

The problem is:
        1. normal 2.4.x kernel do not have this metaphor, kernel sets page
fault execption as 'trap gate'
    2. 2.4.x+dprobes do have this metaphor, dprobes changes
do_int3/do_debug/do_pagefault exception as 'interrupt gate'
    3. 2.5.x+kprobes do not have this metaphor. kprobes only changes
do_int3/do_debug exception as 'interrupt gate'. let do_pagefault be :-(

IMHO, we must patch kernel based on 2.5.x+kprobes to following the metaphor.
-----Original Message-----
From: Zhuang, Louis [mailto:lou...@in...]
Sent: Friday, November 08, 2002 9:31 AM
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

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

From: Lynch, R. <rus...@in...> - 2002-11-08 03:45:43

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

	-rusty

-----Original Message-----
From: Wang, Stanley=20
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=C4=EA11=D4=C28=C8=D5 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=C4=EA11=D4=C28=C8=D5 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.=20
-----Original Message-----
From: Lynch, Rusty=20
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=20
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=20
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

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

From: Zhuang, L. <lou...@in...> - 2002-11-08 03:43:01

Right or not. kprobes can have a handler in *almost* any address, =
except
exception handler address. And more, the 'specific address' means =
executable
code address... not the address you access as data. kprobes just place =
an
int3 in the watched address, when somebody run here, a int3 exception =
is
triggered. kprobes can not place a handler for data address access, =
this is
FITH want to do. :-)
-----Original Message-----
From: Wang, Frank=20
Sent: Friday, November 08, 2002 10:58 AM
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=C4=EA11=D4=C28=C8=D5 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.=20
-----Original Message-----
From: Lynch, Rusty=20
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?
=20
    -rusty
-----Original Message-----
From: Zhuang, Louis=20
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=20
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.
=20
    -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

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

From: Zhuang, L. <lou...@in...> - 2002-11-08 03:26:33

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

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

From: Wang, F. <fra...@in...> - 2002-11-08 03:00:24

"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=C4=EA11=D4=C28=C8=D5 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.=20
-----Original Message-----
From: Lynch, Rusty=20
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?
=20
    -rusty
-----Original Message-----
From: Zhuang, Louis=20
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=20
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.
=20
    -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

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

From: Zhuang, L. <lou...@in...> - 2002-11-08 02:27:15

maybe a little more explanation. 
In FITH, the PTE of watched memory address will be marked as 'absent'. When
driver accesses the memory, a page fault exception will be triggered. Our
FITH will catch the exception to do our stuffs. This needs a metaphor, the
interrupt vector table (IDT) entry of page fault exception should be an
'interrupt gate', not a 'trap gate', because driver may access watched
memory in interrupt handler which cause exception re-entry.
 
The problem is:
        1. normal 2.4.x kernel do not have this metaphor, kernel sets page
fault execption as 'trap gate'
    2. 2.4.x+dprobes do have this metaphor, dprobes changes
do_int3/do_debug/do_pagefault exception as 'interrupt gate'
    3. 2.5.x+kprobes do not have this metaphor. kprobes only changes
do_int3/do_debug exception as 'interrupt gate'. let do_pagefault be :-(
 
IMHO, we must patch kernel based on 2.5.x+kprobes to following the metaphor.
-----Original Message-----
From: Zhuang, Louis [mailto:lou...@in...]
Sent: Friday, November 08, 2002 9:31 AM
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

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

From: Zhuang, L. <lou...@in...> - 2002-11-08 01:32:42

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

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

From: Lynch, R. <rus...@in...> - 2002-11-08 01:02:18

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

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

From: Zhuang, L. <lou...@in...> - 2002-11-08 00:50:18

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

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

From: Rusty L. <ru...@li...> - 2002-11-07 19:36:31

Attachments: patch-kprobes-2.5.46.diff

Here is the patch with the first hunk adjusted.

    -rusty

----- Original Message -----
From: "Rusty Lynch" <ru...@li...>
To: "Zhuang, Louis" <lou...@in...>;
<fau...@so...>
Sent: Thursday, November 07, 2002 11:16 AM
Subject: Re: [Fault-injection-developer] LKML threads about kprobes


> The kprobes patch for 2.5.45 applies almost just fine to 2.5.46.
> (The first hunk is off by a line, but patch is able to figure
> it out.)
>
>     -rusty
>
> ----- Original Message -----
> From: Zhuang, Louis
> To: 'fau...@so...'
> Sent: Wednesday, November 06, 2002 1:43 AM
> Subject: [Fault-injection-developer] LKML threads about kprobes
>
>
> [PATCH] kprobes for 2.5.30
> http://www.uwsg.iu.edu/hypermail/linux/kernel/0208.0/0282.html
> [PATCH] (Re-xmit) kprobes for i386
> http://www.uwsg.iu.edu/hypermail/linux/kernel/0208.1/0870.html
> [PATCH] (re-xmit): kprobes for i386
> http://www.uwsg.iu.edu/hypermail/linux/kernel/0208.2/0718.html
> [PATCH] (re-xmit) Kprobes
> http://www.uwsg.iu.edu/hypermail/linux/kernel/0208.3/0216.html
> [PATCH] kprobes for 2.5.33
> http://www.uwsg.iu.edu/hypermail/linux/kernel/0209.0/0177.html
> [PATCH] re-xmit: kprobes vs bk tree
> http://www.uwsg.iu.edu/hypermail/linux/kernel/0209.0/0628.html
> [PATCH] kprobes for 2.5.35
> http://www.uwsg.iu.edu/hypermail/linux/kernel/0209.2/0278.html
> [PATCH] Re-xmit: kprobes for i386
> http://www.uwsg.iu.edu/hypermail/linux/kernel/0209.2/1145.html
> [PATCH] kprobes for 2.5.40
> http://www.uwsg.iu.edu/hypermail/linux/kernel/0210.0/1250.html
> [PATCH] kprobes re-xmit
> http://www.uwsg.iu.edu/hypermail/linux/kernel/0210.2/0790.html
> [patch 0/4] kprobes patches for 2.5.44
> http://www.uwsg.iu.edu/hypermail/linux/kernel/0210.2/2082.html
> [patch 1/4] kprobes - base for 2.5.44
> http://www.uwsg.iu.edu/hypermail/linux/kernel/0210.2/2084.html
> [patch 2/4] kprobes - debug register management for 2.5.44
> http://www.uwsg.iu.edu/hypermail/linux/kernel/0210.2/2085.html
> [patch 3/4] kprobes - kwatch points for 2.5.44
> http://www.uwsg.iu.edu/hypermail/linux/kernel/0210.2/2086.html
> [patch 4/4] kprobes - user space probes for 2.5.44
> http://www.uwsg.iu.edu/hypermail/linux/kernel/0210.2/2089.html
> dynamic probes vs kprobes
> http://www.uwsg.iu.edu/hypermail/linux/kernel/0210.2/2113.html
> [PATCH] kprobes for 2.5.45
http://www.uwsg.iu.edu/hypermail/linux/kernel/021
> 0.3/1852.html
>
>
>
>
> Louis Zhuang, SW Engineer, Intel Corporation.
> My opinions are my own and NEVER the opinions of Intel Corporation.
>
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by: See the NEW Palm
> Tungsten T handheld. Power & Color in a compact size!
> http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en
> _______________________________________________
> Fault-injection-developer mailing list
> Fau...@li...
> https://lists.sourceforge.net/lists/listinfo/fault-injection-developer

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

From: Rusty L. <ru...@li...> - 2002-11-07 19:20:59

Also, there now documentation on kprobes at
http://oss.software.ibm.com/linux/projects/kprobes/

    -rusty

----- Original Message -----
From: "Rusty Lynch" <ru...@li...>
To: "Zhuang, Louis" <lou...@in...>;
<fau...@so...>
Sent: Thursday, November 07, 2002 11:16 AM
Subject: Re: [Fault-injection-developer] LKML threads about kprobes


> The kprobes patch for 2.5.45 applies almost just fine to 2.5.46.
> (The first hunk is off by a line, but patch is able to figure
> it out.)
>
>     -rusty
>
> ----- Original Message -----
> From: Zhuang, Louis
> To: 'fau...@so...'
> Sent: Wednesday, November 06, 2002 1:43 AM
> Subject: [Fault-injection-developer] LKML threads about kprobes
>
>
> [PATCH] kprobes for 2.5.30
> http://www.uwsg.iu.edu/hypermail/linux/kernel/0208.0/0282.html
> [PATCH] (Re-xmit) kprobes for i386
> http://www.uwsg.iu.edu/hypermail/linux/kernel/0208.1/0870.html
> [PATCH] (re-xmit): kprobes for i386
> http://www.uwsg.iu.edu/hypermail/linux/kernel/0208.2/0718.html
> [PATCH] (re-xmit) Kprobes
> http://www.uwsg.iu.edu/hypermail/linux/kernel/0208.3/0216.html
> [PATCH] kprobes for 2.5.33
> http://www.uwsg.iu.edu/hypermail/linux/kernel/0209.0/0177.html
> [PATCH] re-xmit: kprobes vs bk tree
> http://www.uwsg.iu.edu/hypermail/linux/kernel/0209.0/0628.html
> [PATCH] kprobes for 2.5.35
> http://www.uwsg.iu.edu/hypermail/linux/kernel/0209.2/0278.html
> [PATCH] Re-xmit: kprobes for i386
> http://www.uwsg.iu.edu/hypermail/linux/kernel/0209.2/1145.html
> [PATCH] kprobes for 2.5.40
> http://www.uwsg.iu.edu/hypermail/linux/kernel/0210.0/1250.html
> [PATCH] kprobes re-xmit
> http://www.uwsg.iu.edu/hypermail/linux/kernel/0210.2/0790.html
> [patch 0/4] kprobes patches for 2.5.44
> http://www.uwsg.iu.edu/hypermail/linux/kernel/0210.2/2082.html
> [patch 1/4] kprobes - base for 2.5.44
> http://www.uwsg.iu.edu/hypermail/linux/kernel/0210.2/2084.html
> [patch 2/4] kprobes - debug register management for 2.5.44
> http://www.uwsg.iu.edu/hypermail/linux/kernel/0210.2/2085.html
> [patch 3/4] kprobes - kwatch points for 2.5.44
> http://www.uwsg.iu.edu/hypermail/linux/kernel/0210.2/2086.html
> [patch 4/4] kprobes - user space probes for 2.5.44
> http://www.uwsg.iu.edu/hypermail/linux/kernel/0210.2/2089.html
> dynamic probes vs kprobes
> http://www.uwsg.iu.edu/hypermail/linux/kernel/0210.2/2113.html
> [PATCH] kprobes for 2.5.45
http://www.uwsg.iu.edu/hypermail/linux/kernel/021
> 0.3/1852.html
>
>
>
>
> Louis Zhuang, SW Engineer, Intel Corporation.
> My opinions are my own and NEVER the opinions of Intel Corporation.
>
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by: See the NEW Palm
> Tungsten T handheld. Power & Color in a compact size!
> http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en
> _______________________________________________
> Fault-injection-developer mailing list
> Fau...@li...
> https://lists.sourceforge.net/lists/listinfo/fault-injection-developer

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

From: Rusty L. <ru...@li...> - 2002-11-07 19:16:22

The kprobes patch for 2.5.45 applies almost just fine to 2.5.46.
(The first hunk is off by a line, but patch is able to figure
it out.)

    -rusty

----- Original Message -----
From: Zhuang, Louis
To: 'fau...@so...'
Sent: Wednesday, November 06, 2002 1:43 AM
Subject: [Fault-injection-developer] LKML threads about kprobes


[PATCH] kprobes for 2.5.30
http://www.uwsg.iu.edu/hypermail/linux/kernel/0208.0/0282.html
[PATCH] (Re-xmit) kprobes for i386
http://www.uwsg.iu.edu/hypermail/linux/kernel/0208.1/0870.html
[PATCH] (re-xmit): kprobes for i386
http://www.uwsg.iu.edu/hypermail/linux/kernel/0208.2/0718.html
[PATCH] (re-xmit) Kprobes
http://www.uwsg.iu.edu/hypermail/linux/kernel/0208.3/0216.html
[PATCH] kprobes for 2.5.33
http://www.uwsg.iu.edu/hypermail/linux/kernel/0209.0/0177.html
[PATCH] re-xmit: kprobes vs bk tree
http://www.uwsg.iu.edu/hypermail/linux/kernel/0209.0/0628.html
[PATCH] kprobes for 2.5.35
http://www.uwsg.iu.edu/hypermail/linux/kernel/0209.2/0278.html
[PATCH] Re-xmit: kprobes for i386
http://www.uwsg.iu.edu/hypermail/linux/kernel/0209.2/1145.html
[PATCH] kprobes for 2.5.40
http://www.uwsg.iu.edu/hypermail/linux/kernel/0210.0/1250.html
[PATCH] kprobes re-xmit
http://www.uwsg.iu.edu/hypermail/linux/kernel/0210.2/0790.html
[patch 0/4] kprobes patches for 2.5.44
http://www.uwsg.iu.edu/hypermail/linux/kernel/0210.2/2082.html
[patch 1/4] kprobes - base for 2.5.44
http://www.uwsg.iu.edu/hypermail/linux/kernel/0210.2/2084.html
[patch 2/4] kprobes - debug register management for 2.5.44
http://www.uwsg.iu.edu/hypermail/linux/kernel/0210.2/2085.html
[patch 3/4] kprobes - kwatch points for 2.5.44
http://www.uwsg.iu.edu/hypermail/linux/kernel/0210.2/2086.html
[patch 4/4] kprobes - user space probes for 2.5.44
http://www.uwsg.iu.edu/hypermail/linux/kernel/0210.2/2089.html
dynamic probes vs kprobes
http://www.uwsg.iu.edu/hypermail/linux/kernel/0210.2/2113.html
[PATCH] kprobes for 2.5.45 http://www.uwsg.iu.edu/hypermail/linux/kernel/021
0.3/1852.html




Louis Zhuang, SW Engineer, Intel Corporation.
My opinions are my own and NEVER the opinions of Intel Corporation.

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

From: Lynch, R. <rus...@in...> - 2002-11-07 17:30:07

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

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

From: Zhuang, L. <lou...@in...> - 2002-11-07 08:29:19

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

25 messages has been excluded from this view by a project administrator.

Flat | Threaded

<< < 1 .. 10 11 12 13 14 15 > >> (Page 12 of 15)