[Jaunty SRU] LP#345710 [v2: description modified] iwl3945: cancel rfkill_poll with sync when?the module is exiting

[Stefan Bader]

Huaxu Wan wrote:
> Hi Stefan,
> 
> The patch 71d449b55abf5018d7c711b2b62abc0c083723c4 doesn't work in my test
> with 2.6.28 kernel. Please double check before it's pulled in.
> 
> Thanks
> Huaxu
> 
> On 15:53 Wed 10 Jun, Stefan Bader wrote:
>> Hi Huaxu,
>>
>> thanks for the work and sorry for being so late in response. It seems, by 
>> now the patch made it upstream as
>>
>> commit 71d449b55abf5018d7c711b2b62abc0c083723c4
>> Author: Reinette Chatre <reinette.chatre at intel.com>
>> Date:   Mon Apr 20 14:37:01 2009 -0700
>>
>>     iwl3945: use cancel_delayed_work_sync to cancel rfkill_poll
>>
>>     Users reported lockup with work still trying to run
>>     after module has been unloaded.
>>
>>     http://thread.gmane.org/gmane.linux.kernel.wireless.general/30594/focus=3060
>>
>>     Signed-off-by: Reinette Chatre <reinette.chatre at intel.com>
>>     Reported-by: TJ <ubuntu at tjworld.net>
>>     Reported-by: Huaxu Wan <huaxu.wan at linux.intel.com>
>>     Signed-off-by: John W. Linville <linville at tuxdriver.com>
>>
>>
>> This looks even simpler by just syncing the cancellation. I will go on 
>> and try to get this version into SRU. Thanks again.
>>
>> Stefan
>>
>> Huaxu Wan wrote:
>>> From f3628f0ac6c9713afadaa9654815c37a294ce7e2 Mon Sep 17 00:00:00 2001
>>> From: Huaxu Wan <huaxu.wan at linux.intel.com>
>>> Date: Fri, 8 May 2009 07:36:58 -0400
>>> Subject: [PATCH] cancel rfkill_poll with sync when module is exiting
>>>
>>> Re-write the patch due to there is no response from TJ.
>>>
>>> When the the interface is down, a delayed work rfkill_poll is queued.
>>> This work must be canceled before the module is unloaded, or the OS would
>>> suffer a hard lock-up.
>>>  This patch fix the bug LP: #345710 by make sure the queued work is 
>>> canceled.
>>>
>>>
>>> Original info:
>>> http://marc.info/?l=linux-wireless&m=123791044313158&w=2
>>> Bug: #345710
>>>
>>> When the wireless interface is active and the iwl3945 module is unloaded the
>>> call to ieee80211_unregister_hw() would call iwl3945_mac_stop() which would
>>> restart the delayed workqueue for rfkill_poll. That workqueue had already been
>>> cancelled so when the next work item was run (2 seconds later) the system would
>>> suffer a hard lock-up because the module had been unloaded by then.
>>>
>>> This patch implements STATUS_EXIT_PENDING checks in places where the rfkill_poll
>>> work is scheduled, and moves the final workqueue cancellation to occur after the
>>> call to ieee80211_unregister_hw().
>>>
>>> Bug discovered, experienced and fix tested on my PC.
>>>
>>> Signed-off-by: TJ <ubuntu at tjworld.net>
>>> Signed-off-by: Huaxu Wan <huaxu.wan at linux.intel.com>
>>> ---
>>>  drivers/net/wireless/iwlwifi/iwl3945-base.c |    2 +-
>>>  1 files changed, 1 insertions(+), 1 deletions(-)
>>>
>>> diff --git a/drivers/net/wireless/iwlwifi/iwl3945-base.c b/drivers/net/wireless/iwlwifi/iwl3945-base.c
>>> index bb92db2..08c2a9d 100644
>>> --- a/drivers/net/wireless/iwlwifi/iwl3945-base.c
>>> +++ b/drivers/net/wireless/iwlwifi/iwl3945-base.c
>>> @@ -8166,7 +8166,6 @@ static void __devexit iwl3945_pci_remove(struct pci_dev *pdev)
>>>  	sysfs_remove_group(&pdev->dev.kobj, &iwl3945_attribute_group);
>>>   	iwl3945_rfkill_unregister(priv);
>>> -	cancel_delayed_work(&priv->rfkill_poll);
>>>  	iwl3945_dealloc_ucode_pci(priv);
>>>   	if (priv->rxq.bd)
>>> @@ -8181,6 +8180,7 @@ static void __devexit iwl3945_pci_remove(struct pci_dev *pdev)
>>>   	/*netif_stop_queue(dev); */
>>>  	flush_workqueue(priv->workqueue);
>>> +	cancel_delayed_work_sync(&priv->rfkill_poll);
>>>   	/* ieee80211_unregister_hw calls iwl3945_mac_stop, which flushes
>>>  	 * priv->workqueue... so we can't take down the workqueue
>>
>> -- 
>>
>> When all other means of communication fail, try words!
>>
>>
> 
Hi Huaxu,

we got now confirmed in the bug, that the upstream part alone does not fix the 
problem.  prepared the following update to it. I added your signed-off for now, 
is that ok? Should I send it upstream or do you want to do that?

Thanks,
Stefan


-- 

When all other means of communication fail, try words!


-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-UBUNTU-Move-cancel_delayed_work_sync-to-avoid-locku.patch
Type: text/x-diff
Size: 1716 bytes
Desc: not available
URL: <https://lists.ubuntu.com/archives/kernel-team/attachments/20090630/c5e04fb8/attachment.patch>