Re: [PATCH V2 1/2] ath6kl: Fix race in aggregation reorder logic

[Vasanthakumar Thiagarajan <vthiagar@qca.qualcomm.com>]

On Tuesday 29 May 2012 04:43 PM, Kalle Valo wrote:
> On 05/25/2012 01:19 PM, Vasanthakumar Thiagarajan wrote:
>> There are many places where tid data are accessed without
>> the lock (rxtid->lock), this can lead to a race condition
>> when the timeout handler for aggregatin reorder and the
>> receive function are getting executed at the same time.
>> Fix this race, but still there are races which can not
>> be fixed without rewriting the whole aggregation reorder
>> logic, for now fix the obvious ones.
>>
>> Signed-off-by: Vasanthakumar Thiagarajan<vthiagar@qca.qualcomm.com>
>
> [...]
>
>> @@ -1188,6 +1189,7 @@ static bool aggr_process_recv_frm(struct aggr_info_conn *agg_conn, u8 tid,
>>   		rxtid->progress = true;
>>   	else
>>   		for (idx = 0 ; idx<  rxtid->hold_q_sz; idx++) {
>> +			spin_lock_bh(&rxtid->lock);
>>   			if (rxtid->hold_q[idx].skb) {
>>   				/*
>>   				 * There is a frame in the queue and no
>> @@ -1201,8 +1203,10 @@ static bool aggr_process_recv_frm(struct aggr_info_conn *agg_conn, u8 tid,
>>   					   HZ * (AGGR_RX_TIMEOUT) / 1000));
>>   				rxtid->progress = false;
>>   				rxtid->timer_mon = true;
>> +				spin_unlock_bh(&rxtid->lock);
>>   				break;
>>   			}
>> +			spin_unlock_bh(&rxtid->lock);
>>   		}
>
> Here you take and release the lock multiple times inside the loop. Why
> not take the lock before the loop?

Sounds better to acquire the lock before loop and releasing it after
the loop. I was kind of thinking about protecting the data only
in critical section, but in this case we can bring the loop
in the lock, it is not going to make much difference. I'll change
this, thanks.

Vasanth