From: Ben Greear <greearb@candelatech.com>
To: "linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>
Subject: Re: kmemleak report in 3.9.5+, related to cfg80211_inform_bss_frame
Date: Fri, 14 Jun 2013 15:48:37 -0700 [thread overview]
Message-ID: <51BB9DC5.2020509@candelatech.com> (raw)
In-Reply-To: <51B7C29C.1060701@candelatech.com>
On 06/11/2013 05:36 PM, Ben Greear wrote:
> On 06/11/2013 12:08 PM, Ben Greear wrote:
>> On 06/11/2013 12:00 PM, Ben Greear wrote:
>>> 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
>
>>> 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
I am still working on trying to figure this one out.
I've instrumented all (as far as I can tell) allocation points
and destruction points for the ies, and I am keeping a separate
list of structures to record some info about each ies.
I loaded up lots of stations, let them bounce around for a while,
and then did an 'rmmod ath9k'.
I still see 14 ies entries in my debug list. Should
I expect to see zero ies data structures left after
I rmmod all wifi drivers, or is it normal for a few
to be left around?
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
next prev parent reply other threads:[~2013-06-14 22:48 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-06-11 19:00 kmemleak report in 3.9.5+, related to cfg80211_inform_bss_frame Ben Greear
2013-06-11 19:08 ` Ben Greear
2013-06-12 0:36 ` Ben Greear
2013-06-14 22:48 ` Ben Greear [this message]
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=51BB9DC5.2020509@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).