Alan Cox wrote:
>
> > Here it is (it compiles both for UP and SMP, I can't test it on SMP though).
> >
> > --- linux/kernel/module.c Fri Jun 23 20:17:18 2000
> > +++ linux-prumpf/kernel/module.c Sat Jun 24 11:53:05 2000
>
> CPU1 CPU2
> spinlock(&card->lock)
> rmmod
> -FREEZE->
> spin on freeze
> cleanup_module
> spinlock(&card->lock)
>
> And the box is dead.
Except CPU2 shouldn't be diddling with device-specific locks when the
module refcount is zero.
Al, the problem we've hit with the netdevice drivers is that they are
registered and appear in the namespace _when their refcount is zero_.
That is, register_netdevice() is called from within the context of the
module constructor. (Well, that's just one of the problems..)
So netdevice methods such as open(), do_ioctl(), set_multicast_list(),
etc can be and are called when the module refcount is zero.
The act of inserting the module and the act of making the module's
facilities available to the kernel shouldn't be coupled in this way
because it _forces_ us to have an "open" driver whose module refcount is
zero. I don't see a fix for this without a change to the way we handle
netdevices. 'ifconfig tulip register' and 'ifconfig tulip unregister'.
Fun.
I think the 'grab all other CPUs' trick solves a lot of the problems.
It seems to be a sensible thing to do when you're unloading kernel text
anyway. But there remains the possibility that someone has done a
shedule() from within the context of a zero-refcount module :(
Phil, you were right - the kernel threads are run-to-completion. I had
a long fsck to prove it.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Mon Jun 26 2000 - 21:00:07 EST