On Wed, 2013-06-12 at 13:58 -0700, Ben Greear wrote:
> > When did this report get printed?
>
> I have a system with 100 or so stations constantly trying to
> associate with a set of APs that can handle < 100. This
> effectively causes constant churn of re-associations and
> associated logic...
Right ... I figured it was this.
> Good for shaking out bugs it seems :)
>
> These and other leaks show up after a few minutes of
> running this test scenario. It's not a huge number of
> leaks, however...so usually stations go away w/out leaking.
That's not all too surprising really, the work should run quickly I
guess.
Anyway I guess kmemleak doesn't actually let you pinpoint when the leak
occurred because it just scans periodically and not on every kfree, so
n/m my question.
> > for (i = 0; i < IEEE80211_NUM_TIDS; i++) {
> > + kfree(sta->ampdu_mlme.tid_start_tx[i]);
> > tid_tx = rcu_dereference_raw(sta->ampdu_mlme.tid_tx[i]);
> > if (!tid_tx)
> > continue;
>
> Looks reasonable to me. I was about to start testing similar logic
> in sta_info_free(), but likely your patch is more proper.
>
> I'll give it a try now.
Thanks.
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
