linux-kernel - Re: Memory leak in iwlwifi or false positive?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <1246573533.17896.867.camel@rc-desk>
Date:	Thu, 02 Jul 2009 15:25:33 -0700
From:	reinette chatre <reinette.chatre@...el.com>
To:	Catalin Marinas <catalin.marinas@....com>
Cc:	"linux-wireless@...r.kernel.org" <linux-wireless@...r.kernel.org>,
	linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: Memory leak in iwlwifi or false positive?

Hi Catalin,

On Thu, 2009-07-02 at 14:32 -0700, Catalin Marinas wrote:
> Hi,
> 
> I'm trying to get kmemleak more robust and with the latest patches (not

I just compiled my 2.6.31 kernel with kmemleak but did not yet look into
how it works ... I do see a lot of messages though. 

> pushed yet) it seems to no longer show so many random leaks. However, I
> get a lot of leaks reported in the iwlwifi code, about 4800 and they do
> not disappear from any subsequent memory scanning (as is usually the
> case with false positives). There are a lot of kmalloc's of < 512 bytes
> and /proc/slabinfo seems to be in line with this:
> 
> kmalloc-512         5440   5481
> 
> This happens shortly after booting. Note that if an object is freed,
> kmemleak no longer tracks it and therefore no reporting. But in this
> case it looks like the iwlwifi code really allocated ~4800 blocks. Is it
> normal for this code to keep so many blocks allocated? If yes, it is
> probably kmemleak missing some root object in the references tree.

Yes - this sounds about right. You tested with 5100 hardware which by
default initializes 20 TX queues. For each of these queues it maintains
a 256 buffer array of commands with 356 bytes used for each command.

The 20 * 256 gives me 5120 ... would that explain the ~4800?

Reinette


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/