From: Ben Greear <greearb@candelatech.com>
To: Johannes Berg <johannes@sipsolutions.net>
Cc: "linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>
Subject: Re: Lots of confusion on bss refcounting.
Date: Mon, 17 Jun 2013 12:09:08 -0700 [thread overview]
Message-ID: <51BF5ED4.9010704@candelatech.com> (raw)
In-Reply-To: <1371495758.8168.3.camel@jlt4.sipsolutions.net>
On 06/17/2013 12:02 PM, Johannes Berg wrote:
> On Mon, 2013-06-17 at 11:49 -0700, Ben Greear wrote:
>
>> We create an assoc_data, assign a bss pointer in ieee80211_mgd_assoc,
>> but do not claim a reference.
>
> Heh, yeah, I was actually looking at this code too but didn't have time
> today to finish my thoughts ...
>
>> Later, when deleting the assoc_data, the ref is not freed either,
>> except in one error path where it is explicitly freed:
>>
>> if (!ieee80211_assoc_success(sdata, *bss, mgmt, len)) {
>> /* oops -- internal error -- send timeout for now */
>> ieee80211_destroy_assoc_data(sdata, false);
>> cfg80211_put_bss(sdata->local->hw.wiphy, *bss);
>> return RX_MGMT_CFG80211_ASSOC_TIMEOUT;
>> }
>>
>> This seems ripe for bugs, if not already buggy.
>>
>> Maybe we should be more explicit about always grabbing a ref when
>> we take a reference to the pointer, and always put it when we
>> destroy the pointer?
>
> I think the reference is actually given to mac80211 by cfg80211 in
> cfg80211_mlme_assoc(), so we shouldn't need to grab a reference?
> Although I'm certainly willing to change this and make cfg80211 always
> put the reference after calling rdev_assoc() so that the driver/mac80211
> would be responsible for obtaining its own if it needs to hang on to the
> struct.
>
> This does seem broken though.
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.
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
next prev parent reply other threads:[~2013-06-17 19:09 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-06-17 18:49 Lots of confusion on bss refcounting Ben Greear
2013-06-17 19:02 ` Johannes Berg
2013-06-17 19:09 ` Ben Greear [this message]
2013-06-17 21:31 ` Ben Greear
2013-06-18 0:30 ` Ben Greear
2013-06-18 12:49 ` Johannes Berg
2013-06-18 15:47 ` Ben Greear
2013-06-18 15:52 ` Johannes Berg
2013-06-18 15:59 ` Ben Greear
2013-06-18 21:36 ` Ben Greear
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=51BF5ED4.9010704@candelatech.com \
--to=greearb@candelatech.com \
--cc=johannes@sipsolutions.net \
--cc=linux-wireless@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).