On Tue, 2011-03-29 at 12:38 +0100, Maxin John wrote: > Hi, > > > You may want to disable the kmemleak testing to reduce the amount of > > leaks reported. > > The kmemleak results in MIPS that I have included in the previous mail > were obtained during the booting of the malta kernel. > Later, I have checked the "real" usage by using the default > "kmemleak_test" module. > > Following output shows the kmemleak results when I used the "kmemleak_test.ko" Yes, that's fine to test kmemleak and show that it reports issues on MIPS. But it shouldn't report other leaks if the test module isn't loaded at all (removing it wouldn't remove the leaks reported as they are permanent). > debian-mips:~# cat /sys/kernel/debug/kmemleak > ........ These were caused by the kmemleak test. > > > These are probably false positives. > The previous results could be false positives. However, the current > results are not false positives as we have intentionally created the > memory leaks using the test module. I was only referring to those leaks coming from udp.c and ignored the kmemleak tests (that's why I said that you should run it again without the kmemleak_test.ko). > > Since the pointer referring this > > block (udp_table) is __read_mostly, is it possible that the > > corresponding section gets placed outside the _sdata.._edata range? > > I am not sure about this. Please let know how can I check this. Boot the kernel with kmemleak enabled but don't load kmemleak_test.ko. Than you can either wait 10-15 minutes or force a scan with: echo scan > /sys/kernel/debug/kmemleak echo scan > /sys/kernel/debug/kmemleak cat /sys/kernel/debug/kmemleak. -- Catalin
