Messages in this thread | | | Date | Mon, 17 Jun 2013 15:45:38 -0700 | From | Ben Greear <> | Subject | Re: kmemleak reports in kernel 3.9.5+ |
| |
On 06/13/2013 08:50 AM, Catalin Marinas wrote: > On Wed, Jun 12, 2013 at 01:28:13AM +0100, Ben Greear wrote: >> On 06/11/2013 12:52 PM, Ben Greear wrote: >>> On 06/10/2013 03:32 PM, Catalin Marinas wrote: >>>> On 10 June 2013 19:22, Ben Greear <greearb@candelatech.com> wrote: >>>>> We had a system go OOM while doing lots of wireless >>>>> stations. (System had 8GB of RAM, so I suspect a leak). >>>>> >>>>> I enabled kmemleak in a 3.9.5 (plus some local patches) and >>>>> I see the entries below. Any idea if these are real or not? >> >> Most of this went away when I disabled SLUB debugging and other >> kernel hacking options. The wifi cfg80211_inform_bss_frame >> remains, however. I'll go dig some more on that tomorrow...didn't >> see anything obvious at first glance. >> >> But, perhaps there could be some improvements to >> kmemleak to make it deal better with the various kernel >> debugging features? > > That's unrelated to the debugging features. Kmemleak cannot find > pointers to the allocated objects. They could be real leaks or it simply > doesn't scan the right memory where such pointers are stored. The debug > objects are stored in a list with the head as static memory, so it > should be scanned.
I re-ran a similar test just now, but I had added an explicit reference for each of the items that I know this test causes to leak (I add them to a global list.)
This means that memleak would no longer show them as leaked, and that also cleaned up all of the strange leaks reported before.
So, I think kmemleak is at least mostly working properly, even with lots of debugging options.
Thanks, Ben
-- Ben Greear <greearb@candelatech.com> Candela Technologies Inc http://www.candelatech.com
| |