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

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

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