Fix for crash on eject after module removal
linux at brodo.de
Sun Apr 27 09:22:30 BST 2003
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
Url : http://lists.infradead.org/pipermail/linux-pcmcia/attachments/20030427/d5b4319d/attachment.bin
More information about the linux-pcmcia