Re: [PATCH 2/4] kmemleak: Handle percpu memory allocation

[Christoph Lameter]

On Thu, 29 Sep 2011, Catalin Marinas wrote:

> 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.

percpu data can be placed in physical areas as well as virtually mapped
areas. The size of the offset returned by alloc_percpu() depends on the
mechanism and therefore is treated like an arbitrary value.

> Allowing overlapping blocks in kmemleak may be a solution but it's not
> implemented yet.

You could use the address of the instance of the percpu variable in the
*first* cpu as the canonical item. As soon as you calculate an actual
address (using a processor number) you will have a physical address that
cannot overlap elsewhere.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/