Fix for crash on eject after module removal

[Pavel Roskin]

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.

-- 
Regards,
Pavel Roskin