Search Linux Wireless

Re: [RFTv2 3/5] ath10k: rework peer accounting

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Michal Kazior <michal.kazior@xxxxxxxxx> writes:

>>> +/* hold conf_mutex for simple iteration, or conf_mutex+data_lock for
>>> + * modifications */
>>>  struct ath10k_peer *ath10k_peer_find(struct ath10k *ar, int vdev_id,
>>>                                    const u8 *addr)
>>>  {
>>>       struct ath10k_peer *peer;
>>>
>>> -     lockdep_assert_held(&ar->data_lock);
>>> -
>>>       list_for_each_entry(peer, &ar->peers, list) {
>>>               if (peer->vdev_id != vdev_id)
>>>                       continue;
>>
>> The comment here makes me suspicious. How can we safely iterate the list
>> if we don't take data_lock? Doesn't it mean that the list can change
>> while we have conf_mutex?
>
> The idea is you need BOTH locks to modify the list structure, but you
> need only one of them to iterate over the list safely and
> consistently. This means writer will not alter the list structure
> until there are no readers.

Still not understanding this. Why not then use conf_mutex always, why do
we need data_lock at all?

Or are you saying that one can iterate the list by either taking
conf_mutex or by taking data_lock, depending on context?

-- 
Kalle Valo
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Host AP]     [ATH6KL]     [Linux Wireless Personal Area Network]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [Linux Kernel]     [IDE]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite Hiking]     [MIPS Linux]     [ARM Linux]     [Linux RAID]

  Powered by Linux