Re: [PATCH] mm/cma: Make kmemleak ignore CMA regions

[Andrew Morton <akpm@linux-foundation.org>]

On Tue, 21 Oct 2014 14:14:56 +0200 Thierry Reding <thierry.reding@gmail.com> wrote:

> From: Thierry Reding <treding@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 <treding@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, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>