Re: Lots of confusion on bss refcounting.

[Ben Greear <greearb@candelatech.com>]

On 06/17/2013 02:31 PM, Ben Greear wrote:
> On 06/17/2013 12:09 PM, Ben Greear wrote:
>> On 06/17/2013 12:02 PM, Johannes Berg wrote:
>
>> The bss reference is passed back, and through luck or careful programming,
>> it *seems* that all paths related to calling ieee80211_rx_mgmt_assoc_resp
>> managed to consume the bss.
>>
>> I haven't figured out yet why this is not an erroneous put since I didn't
>> find the reference taken in the first place.
>>
>> I'm going to work on making some changes to the ref counting scheme
>> a bit.  I'd rather have the code perhaps take and put a few refs
>> it might otherwise skip to keep the ownership cleaner and make
>> the code easier to debug and understand...
>>
>> I'll post some for RFC when I make some progress.
>
> I think I found at least some of the leaks.
>
> In places like ieee80211_mgd_stop, we were calling ieee80211_destroy_assoc_data,
> but it was not putting the bss reference.
>
> I'll post some RFC patches in a minute or two...first is debugging
> logic, second attempts to fix bss ref counting.  This needs more
> testing before it is applied...we will continue testing it....

It seems that the wdev objects (struct wireless_dev) can also
hold a reference to the bss.

Do you happen to know what code is responsible for destructing
those objects?  I want to check to make sure it properly puts
its reference.

Even after the patches posted I still see a few leaked bss objects...

Thanks,
Ben

-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com