Fix for crash on eject after module removal
proski at gnu.org
Sat Apr 26 23:38:05 BST 2003
On Sun, 27 Apr 2003, Dominik Brodowski wrote:
> > The recent 2.5.x kernels panic if I remove a PCMCIA client module by
> > rmmod and then do "cardctl eject":
> > modprobe yenta_socket
> > cardmgr
> > rmmod orinoco_cs
> > cardctl eject
> Yes, users might do this. But it's BAD BAD BAD. cardmgr does its own
> reference counting of module usage, and rmmod's it automatically if it isn't
> needed any longer. Instead, the pcmcia core should increase the reference
> count on "bind"==probe, and drop the reference in "unbind"==remove. So I'd
> prefer the patch attached (untested, notebook ~6km away). Pavel, could you
> please test it?
It works. The modules that use pcmcia_register_driver() e.g. pcnet_cs set
the module owner, so they become locked until "cardctl eject". Modules
that use register_pccard_driver() e.g. orinoco_cs are not locked and can
be unloaded. The kernel warns the user but doesn't crash.
I believe that's the expected behavior, so the patch can be applied.
I actually considered the idea to lock the modules, but decided that if we
are going to make PCMCIA more like other driver subsystems, maybe such
locking would not be a good idea. I mean, I can insert and remove
orinoco_plx as long as the interface is down. Why cannot I do the same
with orinoco_cs? OK, let it be a temporary solution.
What I don't quite like is that setting the module owner is voluntary and
cannot be enforced except by obsoleting register_pccard_driver().
Ideally, the module should be found by the address without any cooperation
from the client driver, but I guess __find_symbol() in kernel/module.c
begins with two underscores for a reason.
If this locking is a temporary measure then perhaps we shouldn't try to
lock the old-style modules using advanced module API. But if it's here to
stay, then yelling on the user doesn't cut it.
More information about the linux-pcmcia