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