On Fri, Dec 14, 2012 at 1:41 AM, Johannes Berg
<johannes@xxxxxxxxxxxxxxxx> wrote:
> On Fri, 2012-12-14 at 01:32 +0200, Eliad Peller wrote:
>> On Fri, Dec 14, 2012 at 12:59 AM, Johannes Berg
>> <johannes@xxxxxxxxxxxxxxxx> wrote:
>> > From: Johannes Berg <johannes.berg@xxxxxxxxx>
>> >
>> > The last fixes re-added the RCU synchronize penalty
>> > on roaming to fix the races. Split up sta_info_flush()
>> > now to get rid of that again, and let managed mode
>> > (and only it) delay the actual destruction.
>> >
>> > Signed-off-by: Johannes Berg <johannes.berg@xxxxxxxxx>
>> > ---
>> > +static inline int sta_info_flush(struct ieee80211_sub_if_data *sdata)
>> > +{
>> > + int ret = sta_info_flush_defer(sdata);
>> > +
>> > + if (ret)
>> > + sta_info_flush_cleanup(sdata);
>> > +
>> > + return ret;
>> > +}
>> > +
>>
>> but i think this is wrong - there might already be stations in the cleanup list.
>> you should always call sta_info_flush_cleanup.
>
> I don't think so? I thought about this for a while, but I see only the
> case where there are stations being added to the list in the
> sta_info_flush_defer() call -- then the return value is bigger than zero
> and when we return, nothing is on the cleanup list.
>
> The other case is that there's something on the cleanup list for managed
> mode, but that only needs to be guaranteed to be cleaned up when the
> interface goes down (nothing in the destroy calls back to the driver) so
> there the explicit call to sta_info_flush_cleanup() should be enough?
>
well, i didn't delve into the exact use cases, but semantically, after
calling sta_info_flush(), i'd expect all the vif's stations to get
flushed.
this might be redundant right now (as there are no
sta_info_flush_defer calls followed by sta_info_flush), but it sounds
more correct to me.
Eliad.
--
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
