Re: [ANNOUNCE] d80211 based driver for Intel PRO/Wireless 3945ABG

["Hesse, Christian" <mail@earthworm.de>]

[-- Attachment #1: Type: text/plain, Size: 2094 bytes --]

On Tuesday 13 February 2007 07:47, Pavel Roskin wrote:
> Hello!
>
> On Sun, 2007-02-11 at 14:17 +0100, Hesse, Christian wrote:
> > lsmod shows a use count of 4294967295 (2^32 - 1), no oopses or the like.
> > This is reproducable all the time.
>
> Although I cannot reproduce the problem (I'm on current wireless-dev),
> here's my interpretation.
>
> The iwlwifi driver includes both a driver and a rate control algorithm.
> It passes THIS_MODULE (i.e. a handle to itself) to the generic rate
> control code, which locks the caller i.e. iwlwifi.  Therefore, iwlwifi
> has locked itself in memory.
>
> To counteract that, the driver "puts" the module, i.e. decreases its use
> count after the rate control is registered.  Conversely, the module
> "gets" itself when the rate control is unregistered.
>
> One thing that is clearly wrong is that try_module_get() comes after
> ieee80211_rate_control_unregister(), not before.  This means that the
> use count would go negative between those calls.  If the kernel starts
> checking for this, the driver is in trouble.
>
> Further, why do we need this self-locking/unlocking trick?  The driver
> can just set priv->rate_control.module to NULL and prevent self-locking.
>
> It would only make sense to put THIS_MODULE there is the rate control
> were implemented as a separate module, which it probably a good idea in
> the long term.
>
> But a simple fix would be just to get rid of all references to
> THIS_MODULE and let the kernel do the right thing.
>
> Most likely, your kernel doesn't use the priv->rate_control.module field
> to lock the module, so it would help in your case.
>
> Please try this patch:
>
> [ patch snipped ]

This patch solves the problem. The module's use count is zero and I can unload 
and load the module.
However I have processes in status D when restarting the device. Is it 
possible that some functions (i.e. escape_essid()) from old and new ieee80211 
stack conflict? I will recompile my kernel without the old stack and see if 
anything changes.
-- 
Regards,
Chris

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]