linux-wireless.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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




  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).