[lkml]   [2000]   [Nov]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [ANNOUNCE] Generalised Kernel Hooks Interface (GKHI)

Please respond to Andrea Arcangeli <>

To: Richard J Moore/UK/IBM@IBMGB
Subject: Re: [ANNOUNCE] Generalised Kernel Hooks Interface (GKHI)

On Wed, Nov 15, 2000 at 05:14:57AM +0000, wrote:
> Andrea,
> I am very greatful for your detailed analysis. I have yet to digest
> everything you commented but will get back to you on all points you raise
> very soon. Here are my thoughts so far:

I'm glad you appreciated my comments. I think dprobes gives an higher
level of flexibility for debugging purposes and I'd really like to
include it in the aa kernels until it will be included into the mainstream.

> When I announced GKHI I did state that SMP support was to follow. The

I probably overlooked that part of your announcement, sorry.

> updates are trivial but I didn't wan't to release the code until I had
> a chance to test it.

Very promising.

Note that SMP could introduce non trivial issues: the self modifying
should be atomic with respect of the other CPUs executing the self
code and specs are often not very explicit about side effects of self
code in SMP, it's not only a matter of implementing the GKHI locks with SMP

> Are you claiming that flush_icache_range has an error and should
> the IA32 instruction flush as I did using CPUID? If this is the case has


> this error been officially reported?

I hope I did that in my email :). Actually when I fixed the alpha port
some month ago (alpha needs an explicit imb() to flush the speculative
icache and it was really crashing in modules because of the missing
smp_imb) I
also noticed IA32 was buggy, since also IA32 execute out of order and specs
says we must do a cpuid as only way to serialize the istream. But I didn't
fixed IA32 because nobody ever got bitten by that race because of
timing/implementation reasons, but to be correcet we should do cpuid also

Once flush_icache_range is fixed in IA32 you can use it inside GKHI too
(and then you'll get it right on all architectures).

> Thanks for this information. Reserving a syscall will become irrelvant
> we release Dprobes as a module using gkhi since we will use ioctl() as
> application interface.

Ok (still you need to reserve a blockdevice major minor number with Linus

> Well, not necessarily so while lkcd is not get accepted into the standard
> kernel source. [..]

It won't until it uses a separate driver that doesn't depend on scsi or
ide layer.

Even ignoring the safety problem of scsi layer potentially corrupted by
memory corruption at crash time, the scsi layer doesn't work without being
interrupt driven. It will recurse on the stack badly if somebody ever tries
use it polled. Probably similar thing happens with IDE (but none IDE polled
hardware exists so we don't know). I documented all this in the `Linux
Debugging' document on my ftp area in

> [.] But also, even when lkcd becomes accepted, using gkhi with
> lkcd will allow a crash dump capability to be actived dynamically. [..]

We can control everything dynamically without self modifying code.

The _only_ point of self modifying code is performance. None other reason
to use it. lkcd is definitely called in an extremely slow path (infact
if all goes right it should never be recalled), so it doesn't give
any advantage to use self modifying code there.

> [..] That
> gives the user more fexibility. Even enterprise customers can sometimes
> hedge their bets when it comes to RAS-like features.

I agree that being able to enable/disable lkcd dynamically is fine


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 12:45    [W:0.025 / U:0.020 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site