On Fri, 2012-12-14 at 01:57 +0200, Eliad Peller wrote:
> >> > +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.
Actually you're right, if a station is deleted explicitly (just before
the AP interface goes down) it still goes on the cleanup list, and if
it's the only one then this patch brings back the bug.
I'll put it back unconditionally.
johannes
--
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
