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. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sun Jul 07 2002 - 22:00:17 EST