RE: [Fault-injection-developer] RE: [DISCUSSION] make decisions a bout ficl

[Lynch, R. <rus...@in...>]

> From: Zhuang, Louis [mailto:lou...@in...]
> > But the problem is that, user always forgets to remove 
> > trigger before remove
> > interceptor, and make system oops.
> Oh, I'm resolving this problem now. Maybe in two or three hours.
> 
> The *real* hard problem is, when user put a trigger on a 
> device driver's
> MMIO space (the driver got it by calling "ioremap"), the PF 
> interceptor will
> set the page of MMIO as 'UNPRESENT'. After a while, user 
> remove the device
> driver without remove trigger firstly. In the case, the 
> iounmap called by
> driver's cleanup method will find one of MMIO page is 
> UNPRESENT. It really
> confuses iounmap and oops. So we should prevent user from 
> removing device
> driver before removing trigger. But as Stan said, it much 
> mess up our code.
> 
> 
> Yours truly,
> Louis Zhuang

Hmm... this really an implementation issue with one specific
interceptor.  I am inclined to resolve this via documentation
and user space tools for a specific test case.

(For example, a test case could be executed by a shell script
that loads the driver, loads the fault set, does it's thing,
unloads the fault set, and finally unloads the driver.)

I would guess there are a lot of ways somebody could misuse
the fault injection interfaces to do a LOT of bad stuff to 
a test machine.  By definition fault injection is dangerous.
If we try to make the basic interfaces fool proof then we will
end up with an overly complex solution.

    -rusty