Re: [PATCH bluetooth-next] Fixes kernel oops when unloading the radio module

[Koen Zandberg <koen@bergzand.net>]

Hello,

On 4-2-2016 15:55, Stefan Schmidt wrote:
> Hello.
>
> Please add a mac802154 as prefix to your subject line to make clear 
> where the patch belongs to.
>
>
> On 02/02/16 22:26, Koen Zandberg wrote:
>> Destroying the workqueue before unregistering the net device caused a
>> kernel oops
>>
>> Signed-off-by: Koen Zandberg <koen@bergzand.net>
>> ---
>>   net/mac802154/main.c | 2 +-
>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/net/mac802154/main.c b/net/mac802154/main.c
>> index e8cab5b..87da85a 100644
>> --- a/net/mac802154/main.c
>> +++ b/net/mac802154/main.c
>> @@ -218,7 +218,6 @@ void ieee802154_unregister_hw(struct 
>> ieee802154_hw *hw)
>>         tasklet_kill(&local->tasklet);
>>       flush_workqueue(local->workqueue);
>> -    destroy_workqueue(local->workqueue);
>>         rtnl_lock();
>>   @@ -226,6 +225,7 @@ void ieee802154_unregister_hw(struct 
>> ieee802154_hw *hw)
>>         rtnl_unlock();
>>   +    destroy_workqueue(local->workqueue);
>>       wpan_phy_unregister(local->phy);
>
> When I look at the cleanup part of ieee802154_register_hw() we call 
> these two in a different order. Should we do the same here or can we 
> be sure that these two are orthogonal and the order do not matter here.
I'm not completly sure whether the order matters in the ieee802154. It 
seems that mac80211 does it reversed, first registering the wiphy and 
then creating the work queue with the failure handling destroying the 
workqueue first and the wiphy unregistering second. I'm not 
knowledgeable enough about these things to make a good call about 
whether to switch them in the ieee802154_hw_register too.

regards
Koen Zandberg