Hi Jeremy, Recall that through DTrace, a privileged user can trace the contents of arbitrary memory addresses, and it performs all these actions with interrupts disabled. Your idea is clever, it just would be extremely complex to implement safely if, indeed, it could be done at all.
Adam On Sat, Sep 30, 2006 at 11:40:12PM +0100, Jeremy Harris wrote: > Bryan Cantrill wrote: > >On Sat, Sep 30, 2006 at 11:09:54PM +0100, Jeremy Harris wrote: > >>Bryan Cantrill wrote: > >>>We will never be doing this: it violates the safety constraint, in > >>>several dimensions. (One of which you outline below.) > >>I'm interested - which other dimensions do you have in mind? > > > >What if someone puts bad ECC on the text or data required to execute > >the bad ECC handler? How does DTrace know what this text and data are > >to prohibit it? > > Sorry - I wasn't clear. "Someone" here is Dtrace; I'm suggesting > that Dtrace should both place the bad-ECC and log the placed regions. > > > More generally, what if someone puts bad ECC on text > >or data that needs to be accessed at TL>1? How is this handled? > > Yes, that is an issue. Can we constrain it in any way? What memory > is accessed at TL>1, and can we restrict it from this type of > tracing? Are there similar issues on non-SPARC architectures? > > >And what about memory that DTrace itself uses to (for example) store the > >lookup table to know how to correct the bogus bad ECC? > > What about it? You're not very clear here; please expand. > > It's just memory; given the assumption above > that it is Dtrace placing the bad ECC, it would seem possible to > not permit it as a traceable region. > > > Most generally, > >how can one prevent bad ECC from being placed on any word of memory that > >is accessed in a context in which a correctable ECC trap cannot be > >handled? > > By having Dtrace responsible for placing the bad ECC. > > - Jeremy Harris > _______________________________________________ > dtrace-discuss mailing list > [EMAIL PROTECTED] -- Adam Leventhal, Solaris Kernel Development http://blogs.sun.com/ahl _______________________________________________ networking-discuss mailing list [email protected]
