linux-kernel - Re: [PATCH v2 3/3] mm: cma: release trigger

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20150127081012.GD11358@js1304-P5Q-DELUXE>
Date:	Tue, 27 Jan 2015 17:10:12 +0900
From:	Joonsoo Kim <iamjoonsoo.kim@....com>
To:	Sasha Levin <sasha.levin@...cle.com>
Cc:	linux-kernel@...r.kernel.org, m.szyprowski@...sung.com,
	akpm@...ux-foundation.org, lauraa@...eaurora.org
Subject: Re: [PATCH v2 3/3] mm: cma: release trigger

On Mon, Jan 26, 2015 at 09:26:05AM -0500, Sasha Levin wrote:
> Provides a userspace interface to trigger a CMA release.
> 
> Usage:
> 
> 	echo [pages] > free
> 
> This would provide testing/fuzzing access to the CMA release paths.
> 
> Signed-off-by: Sasha Levin <sasha.levin@...cle.com>
> ---
>  mm/cma_debug.c |   54 ++++++++++++++++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 54 insertions(+)
> 
> diff --git a/mm/cma_debug.c b/mm/cma_debug.c
> index 39c7116..0a63945 100644
> --- a/mm/cma_debug.c
> +++ b/mm/cma_debug.c
> @@ -11,6 +11,7 @@
>  #include <linux/kernel.h>
>  #include <linux/dma-contiguous.h>
>  #include <linux/slab.h>
> +#include <linux/mm_types.h>

Is mm_types.h needed?

>  
>  #include "cma.h"
>  
> @@ -43,6 +44,56 @@ static void cma_add_to_cma_mem_list(struct cma_mem *mem)
>  	spin_unlock(&cma_mem_head_lock);
>  }
>  
> +static struct cma_mem *cma_get_entry_from_list(void)
> +{
> +	struct cma_mem *mem = NULL;
> +
> +	spin_lock(&cma_mem_head_lock);
> +	if (!hlist_empty(&cma_mem_head)) {
> +		mem = hlist_entry(cma_mem_head.first, struct cma_mem, node);
> +		hlist_del_init(&mem->node);
> +	}
> +	spin_unlock(&cma_mem_head_lock);
> +
> +	return mem;
> +}
> +
> +static int cma_free_mem(struct cma *cma, int count)
> +{
> +	struct cma_mem *mem = NULL;
> +
> +	while (count) {
> +		mem = cma_get_entry_from_list();
> +		if (mem == NULL)
> +			return 0;
> +
> +		if (mem->n <= count) {
> +			cma_release(cma, mem->p, mem->n);
> +			count -= mem->n;
> +			kfree(mem);
> +		} else {
> +			cma_release(cma, mem->p, count);
> +			mem->p += count;
> +			mem->n -= count;
> +			count = 0;
> +			cma_add_to_cma_mem_list(mem);
> +		}
> +	}

If order_per_bit is not 0 and count used in cma_release() is
different with the count used in cma_alloc(), problem could
occur since bitmap management code can't handle that situation.

Could we just disable this case in this testing module?

Thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/