On Tue, 21 Oct 2014 14:14:56 +0200 Thierry Reding <thierry.red...@gmail.com>
wrote:
> From: Thierry Reding <tred...@nvidia.com>
>
> 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 <tred...@nvidia.com>
> ---
> 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 from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
