On 10 April 2014 08:50, Kalle Valo <kvalo@xxxxxxxxxxxxxxxx> wrote: > Michal Kazior <michal.kazior@xxxxxxxxx> writes: > >> It was troublesome to iterate over peers and >> perform sleepable calls. This will be necessary >> for some upcomming changes to tx flushing. >> >> Make peer allocation and initial setup >> protected by both ar->conf_mutex and >> ar->data_lock. This way it's possible to iterate >> over peers with conf_mutex and call sleepable >> functions. >> >> Signed-off-by: Michal Kazior <michal.kazior@xxxxxxxxx> > > Sorry, but I'm not really getting your idea here of using both > conf_mutex and data_lock to protect ar->peers. Can you elaborate more, > please? Why can't we just use conf_mutex then? What am I missing? Originally ar->peers was protected by data_lock. The reason for that the list is accessed from a tasklet context for htt peer map/unmap events. Originally those events allocated/freed peers. This however is cumbersome to work with when you want to iterate over peers and issue blocking/sleepable calls (e.g. flush tx via wmi). Having conf_mutex-only protected conf_mutex would require htt peer map/unmap event processing to be moved into sleepable context (e.g. into a worker). That's why I've made ar->peers being write-protected by both so that it can be read while holding any of these locks. I'll try to make the commit message clearer. Michał -- 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
