[PATCH 4/5] ath10k: protect wep tx key setup

Michal Kazior michal.kazior at tieto.com
Wed May 14 23:04:29 PDT 2014


On 14 May 2014 21:50, Kalle Valo <kvalo at qca.qualcomm.com> wrote:
> Michal Kazior <michal.kazior at tieto.com> writes:
>
>> All configuration sequences should be protected
>> with conf_mutex to avoid concurrent/conflicting
>> requests.
>>
>> This should make sure that wep tx key setup is not
>> performed while hw is restarted (at least).
>
> Locks and mutexes should protect data, not thread of execution. What are
> we exactly protecting here, arvif->def_wep_key_idx?

Actually conf_mutex idea is to protect and serialize configuration
sequences (WMI) too, not just data. Perhaps we should revise this?


> The patch makes sense, I'm just trying to understand the idea behind the
> implementation.
>
>> --- a/drivers/net/wireless/ath/ath10k/mac.c
>> +++ b/drivers/net/wireless/ath/ath10k/mac.c
>> @@ -1888,8 +1888,10 @@ static void ath10k_tx_wep_key_work(struct work_struct *work)
>>                                               wep_key_work);
>>       int ret, keyidx = arvif->def_wep_key_newidx;
>>
>> +     mutex_lock(&arvif->ar->conf_mutex);
>> +
>>       if (arvif->def_wep_key_idx == keyidx)
>> -             return;
>> +             goto unlock;
>
> BTW, shouldn't we also check the state and bail out if the state is not
> ON (and possibly RESTARTED)? How can this work otherwise?

Very good point!

But actually.. this should be cancelled during recovery in the first
place. I need to take a look at it.


Michał



More information about the ath10k mailing list