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-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
