Fix for crash on eject after module removal

[Dominik Brodowski]

On Sun, Apr 27, 2003 at 06:49:06AM +0100, Christoph Hellwig wrote:
> On Sat, Apr 26, 2003 at 10:38:05PM -0400, Pavel Roskin wrote:
> > What I don't quite like is that setting the module owner is voluntary and
> > cannot be enforced except by obsoleting register_pccard_driver().  
> 
> register_pccard_driver() has been obsoleted.  I finally got jgarzik to
> take my patch to converted all net drivers and hopefully it will be
> gone by the end of next week.

That's great! Many thanks!

On Sat, Apr 26, 2003 at 10:38:05PM -0400, Pavel Roskin wrote:
> 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.

That's exactly what I hoped the updated version of the patch would do.

> 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.

Actually, I'd prefer it to be the long-term solution. In my opinion it's the
most logical locking. 

> What I don't quite like is that setting the module owner is voluntary and
> cannot be enforced except by obsoleting register_pccard_driver().  

register_pccard_driver() is only missing __deprecated for one reason: I had
wanted the pcmcia_register_driver() to evolve a bit over time (e.g. device
ID table)... but that was a bad idea, I agree. 

One important question is whether we will continue exporting
register_pccard_driver() once all in-kernel users are converted. 

> 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.

No, that'd be way too ugly.

	Dominik
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.infradead.org/pipermail/linux-pcmcia/attachments/20030427/d5b4319d/attachment.bin