From: Ben Greear <greearb@candelatech.com>
To: "linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>
Subject: kmemleak report in 3.9.5+, related to cfg80211_inform_bss_frame
Date: Tue, 11 Jun 2013 12:00:07 -0700 [thread overview]
Message-ID: <51B773B7.5090301@candelatech.com> (raw)
I see several reports similar to the one below while doing some
kmemleak testing on my 3.9.5+ tree (with local patches applied):
http://dmz2.candelatech.com/git/gitweb.cgi?p=linux-3.9.dev.y/.git;a=summary
While looking through the code, I found this in scan.c:cfg80211_bss_update
} else {
/*
* Ok so we found a beacon, and don't have an entry. If
* it's a beacon with hidden SSID, we might be in for an
* expensive search for any probe responses that should
* be grouped with this beacon for updates ...
*/
if (!cfg80211_combine_bsses(dev, new)) {
kfree(new);
goto drop;
}
}
I don't know if this is the culprit that I am seeing, but I believe
we should be freeing the tmp.pub.beacon_ies (if it is not NULL)
before doing the 'goto drop'?
The kmemleak report is below:
unreferenced object 0xffff8801c8e41e78 (size 192):
comm "kworker/u:2", pid 157, jiffies 4295509873 (age 86582.869s)
hex dump (first 32 bytes):
41 0d 00 30 02 00 00 00 6b 6b 6b 6b 6b 6b 6b 6b A..0....kkkkkkkk
6b 6b 6b 6b 6b 6b 6b 6b 69 00 00 00 00 0c 2e 32 kkkkkkkki......2
backtrace:
[<ffffffff815de7bf>] kmemleak_alloc+0x73/0x98
[<ffffffff8118b4d4>] slab_post_alloc_hook+0x28/0x2a
[<ffffffff8118d605>] __kmalloc+0xf9/0x122
[<ffffffffa027cb27>] cfg80211_inform_bss_frame+0x114/0x1f8 [cfg80211]
[<ffffffffa03d6865>] ieee80211_bss_info_update+0x66/0x21f [mac80211]
[<ffffffffa040aec6>] ieee80211_rx_bss_info+0x12f/0x1ca [mac80211]
[<ffffffffa040b017>] ieee80211_rx_mgmt_probe_resp+0xb6/0x197 [mac80211]
[<ffffffffa040e8a3>] ieee80211_sta_rx_queued_mgmt+0xdd/0x60e [mac80211]
[<ffffffffa03df0ee>] ieee80211_iface_work+0x238/0x2cc [mac80211]
[<ffffffff810b0cd3>] process_one_work+0x292/0x42e
[<ffffffff810b36af>] worker_thread+0x14f/0x264
[<ffffffff810b7bea>] kthread+0xc7/0xcf
[<ffffffff815f64ec>] ret_from_fork+0x7c/0xb0
[<ffffffffffffffff>] 0xffffffffffffffff
(gdb) l *(cfg80211_inform_bss_frame+0x114)
0x8b27 is in cfg80211_inform_bss_frame (/home/greearb/git/linux-3.9.dev.y/net/wireless/scan.c:960).
955 ielen, channel);
956 if (!channel)
957 return NULL;
958
959 ies = kmalloc(sizeof(*ies) + ielen, gfp);
960 if (!ies)
961 return NULL;
962 ies->len = ielen;
963 ies->tsf = le64_to_cpu(mgmt->u.probe_resp.timestamp);
964 memcpy(ies->data, mgmt->u.probe_resp.variable, ielen);
(gdb)
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
next reply other threads:[~2013-06-11 19:00 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-06-11 19:00 Ben Greear [this message]
2013-06-11 19:08 ` kmemleak report in 3.9.5+, related to cfg80211_inform_bss_frame Ben Greear
2013-06-12 0:36 ` Ben Greear
2013-06-14 22:48 ` Ben Greear
2013-06-15 17:11 ` Johannes Berg
2013-06-15 19:18 ` 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=51B773B7.5090301@candelatech.com \
--to=greearb@candelatech.com \
--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).