From: Larry Finger <Larry.Finger@lwfinger.net>
To: Johannes Berg <johannes@sipsolutions.net>
Cc: linux-wireless <linux-wireless@vger.kernel.org>
Subject: Re: Memory leaks in cfg80211 and mac80211
Date: Wed, 06 Mar 2013 10:17:44 -0600 [thread overview]
Message-ID: <51376C28.5030208@lwfinger.net> (raw)
In-Reply-To: <1362562265.8457.7.camel@jlt4.sipsolutions.net>
On 03/06/2013 03:31 AM, Johannes Berg wrote:
> Larry,
>
> Hmm, not sure I understand. What part is kmemleak() having issues with?
> This seems like it would hide genuine issues? This is typically stored
> in a list and/or hash-table, so there should be references? Or does
> kmemleak have issues with pointers to the "middle" of blocks?
As I understand it, a kmemleak scan cannot find pointers to all objects. I don't
understand the details. My approach is to run a scan, note the possible leaks,
unload the drivers indicated, and rerun the scan. If that driver freed a block,
it will disappear from the second scan, thus it is a false positive. It can
safely be annotated with a kmemleak_no_leak() call. If the block still appears
in the scan, or new ones appear, those are real leaks.
> Hmm. I looked and found one possible leak, which this should fix:
>
> --- a/net/wireless/scan.c
> +++ b/net/wireless/scan.c
> @@ -723,6 +721,8 @@ cfg80211_bss_update(struct cfg80211_registered_device *dev,
>
> if (found->pub.hidden_beacon_bss &&
> !list_empty(&found->hidden_list)) {
> + const struct cfg80211_bss_ies *f;
> +
> /*
> * The found BSS struct is one of the probe
> * response members of a group, but we're
> @@ -732,6 +732,10 @@ cfg80211_bss_update(struct cfg80211_registered_device *dev,
> * SSID to showing it, which is confusing so
> * drop this information.
> */
> +
> + f = rcu_access_pointer(tmp->pub.beacon_ies);
> + kfree_rcu((struct cfg80211_bss_ies *)f,
> + rcu_head);
> goto drop;
> }
>
>
> However, that's a corner case, I don't think you ran into it. Since you
> also didn't note any warnings, we can also discount a few cases that
> would be code bugs and would leak.
>
> I wonder if this is related to the first warning? The "new" object in
> the first block would typically take ownership of the "ies" object.
I did not get any warnings.
I will fix the one false positive that I noted, add the patch for your corner
case above, and rerun.
Thanks,
Larry
next prev parent reply other threads:[~2013-03-06 16:17 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-03-05 21:08 Memory leaks in cfg80211 and mac80211 Larry Finger
2013-03-06 9:31 ` Johannes Berg
2013-03-06 16:17 ` Larry Finger [this message]
2013-03-06 23:53 ` Larry Finger
2013-03-07 11:50 ` Johannes Berg
2013-03-07 16:00 ` Larry Finger
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=51376C28.5030208@lwfinger.net \
--to=larry.finger@lwfinger.net \
--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).