Re: simple handling of module removals Re: [OKS] Module removal

Pavel Machek
2002-07-06T19:44:35Z

Hi!

> I'm assuming for the sake of argument that we're requiring the use count to
> be incremented for any call outside the module, a rule we might want anyway,
> since it is less fragile than the no-sleeping rule.
>
> > the module has taken an interrupt into an unrelated driver;
>
> With Ben's new separate interrupt stacks the current IP would be available at
> a known place at the base of the interrupt stack.
>
> > we have computed a call into the module but haven't actually executed
> > the call yet;
>
> This one is problematic, and yes, I now agree the problem is hard. This is
> where Keith's handwaving comes in: we are supposed to have deregistered the
> module's services and ensured all processes are out of the module at this
> point. I don't know how that helps, really. I just want to note that this
> seems to be the only really hard problem. It's not insoluable though: going
> to extremes we could record each region of code from which module calls
> originate and check for execution addresses in that region, along with
> execution addresses in the module. Picking up the call address would have to
> be an atomic read. You don't have to tell me this is ugly and slow, but it
> would work.

freeze_processes(), and now you know that rmmod is only runnable job
on the system [approximately; you'd have to audit all threads marked
as non-stoppable]. So... if rmmod() does not do any computed calls to
module being removed, noone is doing that and all is safe.
Pavel
--
Casualities in World Trade Center: ~3k dead inside the building,
cryptography in U.S.A. and free speech in Czech Republic.