Re: [PATCH 2/3] mm: cma: allocation trigger

[Joonsoo Kim]

On Tue, Jan 20, 2015 at 12:38:32PM -0500, Sasha Levin wrote:
> Provides a userspace interface to trigger a CMA allocation.
> 
> Usage:
> 
> 	echo [pages] > alloc
> 
> This would provide testing/fuzzing access to the CMA allocation paths.
> 
> Signed-off-by: Sasha Levin <sasha.levin@xxxxxxxxxx>
> ---
>  mm/cma_debug.c |   58 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 58 insertions(+)
> 
> diff --git a/mm/cma_debug.c b/mm/cma_debug.c
> index 3a25413..eda0a41 100644
> --- a/mm/cma_debug.c
> +++ b/mm/cma_debug.c
> @@ -7,9 +7,22 @@
>  
>  #include <linux/debugfs.h>
>  #include <linux/cma.h>
> +#include <linux/list.h>
> +#include <linux/kernel.h>
> +#include <linux/dma-contiguous.h>
> +#include <linux/slab.h>
>  
>  #include "cma.h"
>  
> +struct cma_mem {
> +	struct hlist_node node;
> +	struct page *p;
> +	unsigned long n;
> +};
> +
> +static HLIST_HEAD(cma_mem_head);
> +static DEFINE_SPINLOCK(cma_mem_head_lock);
> +
>  static struct dentry *cma_debugfs_root;
>  
>  static int cma_debugfs_get(void *data, u64 *val)
> @@ -44,6 +57,48 @@ static void cma_debugfs_add_one(struct cma *cma, int idx)
>  	debugfs_create_u32_array("bitmap", S_IRUGO, tmp, (u32*)cma->bitmap, u32s);
>  }
>  
> +static void cma_add_to_cma_mem_list(struct cma_mem *mem)
> +{
> +	spin_lock(&cma_mem_head_lock);
> +	hlist_add_head(&mem->node, &cma_mem_head);
> +	spin_unlock(&cma_mem_head_lock);
> +}
> +
> +static int cma_alloc_mem(int count)
> +{
> +	struct cma_mem *mem;
> +	struct page *p;
> +
> +	mem = kzalloc(sizeof(*mem), GFP_KERNEL);
> +	if (!mem) 
> +		return -ENOMEM;
> +
> +	p = cma_alloc(dma_contiguous_default_area, count, CONFIG_CMA_ALIGNMENT);
> +	if (!p) {
> +		pr_info("CMA: Allocation failed.\n");
> +		kfree(mem);
> +		return -ENOMEM;
> +	}

Hello,

I'm glad to see this patchset. I had similar one privately. :)
Without this kind of facility, testing CMA is really hard.

Anyway, dma_contiguous_default_area is defined only in CONFIG_DMA_CMA.
So, it would cause build break.

And, I think that it is better for this tester to have an ability to
allocate pages on specific CMA reserved region. It could be easily
achieved by moving 'alloc' registration to cma_debugfs_add_one(). Is
there any reason not to do that?

> +
> +	pr_info("CMA: Allocated %d pages at %p\n", count, p);

I don't think this output is needed. If CONFIG_CMA_DEBUG is enabled,
cma_alloc() print similar output.

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