On Tue, 21 Oct 2014 14:14:56 +0200 Thierry Reding <thierry.reding@xxxxxxxxx> wrote:
> From: Thierry Reding <treding@xxxxxxxxxx>
>
> kmemleak will add allocations as objects to a pool. The memory allocated
> for each object in this pool is periodically searched for pointers to
> other allocated objects. This only works for memory that is mapped into
> the kernel's virtual address space, which happens not to be the case for
> most CMA regions.
>
> Furthermore, CMA regions are typically used to store data transferred to
> or from a device and therefore don't contain pointers to other objects.
>
> Signed-off-by: Thierry Reding <treding@xxxxxxxxxx>
> ---
> Note: I'm not sure this is really the right fix. But without this, the
> kernel crashes on the first execution of the scan_gray_list() because
> it tries to access highmem. Perhaps a more appropriate fix would be to
> reject any object that can't map to a kernel virtual address?
Let's cc Catalin.
> --- a/mm/cma.c
> +++ b/mm/cma.c
> @@ -280,6 +280,7 @@ int __init cma_declare_contiguous(phys_addr_t base,
> ret = -ENOMEM;
> goto err;
> } else {
> + kmemleak_ignore(phys_to_virt(addr));
> base = addr;
> }
> }
And let's tell our poor readers why we did stuff. Something like this.
--- a/mm/cma.c~mm-cma-make-kmemleak-ignore-cma-regions-fix
+++ a/mm/cma.c
@@ -280,6 +280,10 @@ int __init cma_declare_contiguous(phys_a
ret = -ENOMEM;
goto err;
} else {
+ /*
+ * kmemleak writes metadata to the tracked objects, but
+ * this address isn't mapped and accessible.
+ */
kmemleak_ignore(phys_to_virt(addr));
base = addr;
}
_
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxx. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>