Messages in this thread | | | Date | Thu, 29 Sep 2011 18:17:13 +0100 | From | Catalin Marinas <> | Subject | Re: [PATCH 2/4] kmemleak: Handle percpu memory allocation |
| |
On Thu, Sep 29, 2011 at 12:56:13PM +0100, Eric Dumazet wrote: > Le jeudi 29 septembre 2011 à 12:02 +0100, Catalin Marinas a écrit : > > This patch adds kmemleak callbacks from the percpu allocator, reducing a > > number of false positives caused by kmemleak not scanning such memory > > blocks. The percpu chunks are never reported as leaks because of current > > kmemleak limitations with the __percpu pointer not pointing directly to > > the actual chunks. > > > > Reported-by: Huajun Li <huajun.li.lee@gmail.com> > > Cc: Tejun Heo <tj@kernel.org>, > > Cc: Christoph Lameter <cl@linux-foundation.org> > > Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> > > --- > > I wonder if you tried it on a 16 or 64 cpus machine ?
I only tried on a 4-CPU system and the early log allocations went form under 400 to nearly 800.
> I guess we should increase CONFIG_DEBUG_KMEMLEAK_EARLY_LOG_SIZE default > > Or you could add new kmemleak_percpu_alloc() / kmemleak_percpu_free() > primitives to not waste entries in early_log[]
If we don't track them in early_log[] before kmemleak is initialised, they aren't tracked at all so we end up pretty much in the same situations.
A better approach would be to tell kmemleak about the __percpu pointer via some additional API (or some other way to detect that it's a __percpu pointer) and kmemleak would do the for_each_possible_cpu() conversion when scanning.
The question - can we guarantee that the __percpu pointer returned by alloc_percpu() does not overlap with some memory block allocated elsewhere? At least for the first chunk it seems to overlap with the percpu data section, which is fine as that's not added in kmemleak as an allocated block.
Allowing overlapping blocks in kmemleak may be a solution but it's not implemented yet.
-- Catalin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |