Re: [Fwd: pcmcia ether drivers can't be unloaded]

Re: [Fwd: pcmcia ether drivers can't be unloaded]

[Russell King]

On Tue, Jul 27, 2004 at 01:07:59PM -0400, Jeff Garzik wrote:
> It looks like pcmica modular ether (example orinoco) can never be manually
> unloaded because module refcount is always 1. This comes from the owner
> field in the pcmcia_driver.owner being set.

Intended behaviour.  As long as the driver is bound to a socket, there are
references to the driver, so we need to keep the refcount non-zero.

Once the driver is unbound (by ejecting cards) then the ref count will
drop to zero and the module can be unloaded.

> One fix is to not set owner field but then there is a hot plug/module
> remove race. But the right fix seems to fix up pcmcia to be a true bus
> in the driver model and have the same hotplug as other buses; usb and
> pci don't have the problem.

No, the right fix is not to try to fsck with PCMCIA refcounting - it
isn't up to having drivers randomly unloaded.  IOW, it remains 2.4
behaviour.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 PCMCIA      - http://pcmcia.arm.linux.org.uk/
                 2.6 Serial core

Re: [Fwd: pcmcia ether drivers can't be unloaded]

[David S. Miller]

On Tue, 27 Jul 2004 23:36:14 +0100
Russell King <rmk@arm.linux.org.uk> wrote:

> > One fix is to not set owner field but then there is a hot plug/module
> > remove race. But the right fix seems to fix up pcmcia to be a true bus
> > in the driver model and have the same hotplug as other buses; usb and
> > pci don't have the problem.
> 
> No, the right fix is not to try to fsck with PCMCIA refcounting - it
> isn't up to having drivers randomly unloaded.  IOW, it remains 2.4
> behaviour.

I totally disagree.  This is a bogus argument for two reasons:

1) If the PCMCIA layer can handle cards popping out at any time,
   physically, it is illogical to handicap it on the software
   side in terms of this.

2) There is no way I can stomache "some" networking cards not being
   able to have their modules yanked at any point in time.

   An enormous amount of effort has gone into making networking
   devices and drivers yankable regardless of how configured they
   are and what resources are attached to it.

You have to be kidding me to say that the one subsystem that should
handle hot plugging of stuff the best (PCMCIA) can't handle something
that all of our "normal" PCI and USB drivers can?

The fact is this, device unload of an arbitrary network driver should
work at any point in time, and succeed unloading within a second or
two.  Anything else is a bug.

Re: [Fwd: pcmcia ether drivers can't be unloaded]

[Russell King]

On Tue, Jul 27, 2004 at 05:19:29PM -0700, David S. Miller wrote:
> I totally disagree.  This is a bogus argument for two reasons:

You may disagree, that is your option.  However, facts are facts -
this is how the PCMCIA layer currently works, and short of rewriting
the whole damned thing it isn't going to change.  Sorry.

PS, I'm on holiday for the next week or so, so don't expect anything
to happen, even if you rant and rave about it.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 PCMCIA      - http://pcmcia.arm.linux.org.uk/
                 2.6 Serial core

Re: [Fwd: pcmcia ether drivers can't be unloaded]

[David S. Miller]

On Wed, 28 Jul 2004 16:50:24 +0100
Russell King <rmk@arm.linux.org.uk> wrote:

> On Tue, Jul 27, 2004 at 05:19:29PM -0700, David S. Miller wrote:
> > I totally disagree.  This is a bogus argument for two reasons:
> 
> You may disagree, that is your option.  However, facts are facts -
> this is how the PCMCIA layer currently works, and short of rewriting
> the whole damned thing it isn't going to change.  Sorry.

Stephen offered a solution, moving this stray refcount into a toplevel
pcmcia bus type object.  We are not constrained by how the PCMCIA layer
currently works, just as we were not constrained a year ago by how the
generic network device handling worked when it was totally broken in
this area.  We just fixed it instead of whining.

Re: [Fwd: pcmcia ether drivers can't be unloaded]

[Russell King]

On Wed, Jul 28, 2004 at 08:54:19AM -0700, David S. Miller wrote:
> On Wed, 28 Jul 2004 16:50:24 +0100
> Russell King <rmk@arm.linux.org.uk> wrote:
> 
> > On Tue, Jul 27, 2004 at 05:19:29PM -0700, David S. Miller wrote:
> > > I totally disagree.  This is a bogus argument for two reasons:
> > 
> > You may disagree, that is your option.  However, facts are facts -
> > this is how the PCMCIA layer currently works, and short of rewriting
> > the whole damned thing it isn't going to change.  Sorry.
> 
> Stephen offered a solution, moving this stray refcount into a toplevel
> pcmcia bus type object.  We are not constrained by how the PCMCIA layer
> currently works, just as we were not constrained a year ago by how the
> generic network device handling worked when it was totally broken in
> this area.  We just fixed it instead of whining.

Sorry, I'm not the one whining here.  I just have _ZERO_ time at the moment
because I'm still in Canada and only have sporadic access to stuff.

Sorry if this doesn't meet your requirements, but this is the best I can
offer you at the moment.

In short, my best and only answer is "tough, live with it until I can
investigate."

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 PCMCIA      - http://pcmcia.arm.linux.org.uk/
                 2.6 Serial core

Re: [Fwd: pcmcia ether drivers can't be unloaded]

[Russell King]

On Wed, Jul 28, 2004 at 08:54:19AM -0700, David S. Miller wrote:
> On Wed, 28 Jul 2004 16:50:24 +0100
> Russell King <rmk@arm.linux.org.uk> wrote:
> 
> > On Tue, Jul 27, 2004 at 05:19:29PM -0700, David S. Miller wrote:
> > > I totally disagree.  This is a bogus argument for two reasons:
> > 
> > You may disagree, that is your option.  However, facts are facts -
> > this is how the PCMCIA layer currently works, and short of rewriting
> > the whole damned thing it isn't going to change.  Sorry.
> 
> Stephen offered a solution, moving this stray refcount into a toplevel
> pcmcia bus type object.  We are not constrained by how the PCMCIA layer
> currently works, just as we were not constrained a year ago by how the
> generic network device handling worked when it was totally broken in
> this area.  We just fixed it instead of whining.

Right, I now have sufficient time to investigate and provide a proper
response.

The reason PCMCIA modules _as a whole_ (ie, not limited to just PCMCIA
network drivers) are not unloadable while in use is that:

(1) the PCMCIA subsystem keeps references to structures inside the
    PCMCIA card driver module while the driver is bound (by the
    userspace daemon) to the PCMCIA card.

(2) the userspace daemon, cardmgr, keeps track of which PCMCIA
    card driver modules are loaded, and loads and unloads them
    as necessary.

Short of rearchitecting the way the PCMCIA userspace daemon works, I
don't see an easy fix for this.  Therefore, as I've already said, the
current behaviour stands for 2.6.  PCMCIA is _far_ too fragile to
risk doing a rewrite to get the locking and structure refcounting
rules correct overnight.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 PCMCIA      - http://pcmcia.arm.linux.org.uk/
                 2.6 Serial core