linux-kernel - Re: [PATCH] mm: cma: print allocation failure reason and bitmap status

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]

Date:   Thu, 29 Dec 2016 10:43:36 +0100
From:   Michal Hocko <mhocko@...nel.org>
To:     Jaewon Kim <jaewon31.kim@...sung.com>
Cc:     gregkh@...uxfoundation.org, akpm@...ux-foundation.org,
        labbott@...hat.com, mina86@...a86.com, m.szyprowski@...sung.com,
        linux-mm@...ck.org, linux-kernel@...r.kernel.org,
        jaewon31.kim@...il.com
Subject: Re: [PATCH] mm: cma: print allocation failure reason and bitmap
 status

On Thu 29-12-16 18:26:38, Jaewon Kim wrote:
> 
> 
> On 2016년 12월 29일 18:14, Michal Hocko wrote:
> > On Thu 29-12-16 11:28:02, Jaewon Kim wrote:
> >> There are many reasons of CMA allocation failure such as EBUSY, ENOMEM, EINTR.
> >> This patch prints the error value and bitmap status to know available pages
> >> regarding fragmentation.
> >>
> >> This is an ENOMEM example with this patch.
> >> [   11.616321]  [2:   Binder:711_1:  740] cma: cma_alloc: alloc failed, req-size: 256 pages, ret: -12
> >> [   11.616365]  [2:   Binder:711_1:  740] number of available pages: 4+7+7+8+38+166+127=>357 pages, total: 2048 pages
> > Could you be more specific why this part is useful?
> Hi
> Without this patch we do not know why CMA allocation failed.

Yes, I understand the first part

> Additionally in case of ENOMEM, with bitmap status we can figure out that

The code doesn't seem to check for ENOMEM though

> if it is too small CMA region issue or if it is fragmentation issue.

then please describe that in the changelog. If I got it right the above
would tell us that the fragmentation is the problem, right?

> >  
> >> Signed-off-by: Jaewon Kim <jaewon31.kim@...sung.com>
> >> ---
> >>  mm/cma.c | 29 ++++++++++++++++++++++++++++-
> >>  1 file changed, 28 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/mm/cma.c b/mm/cma.c
> >> index c960459..535aa39 100644
> >> --- a/mm/cma.c
> >> +++ b/mm/cma.c
> >> @@ -369,7 +369,7 @@ struct page *cma_alloc(struct cma *cma, size_t count, unsigned int align)
> >>  	unsigned long start = 0;
> >>  	unsigned long bitmap_maxno, bitmap_no, bitmap_count;
> >>  	struct page *page = NULL;
> >> -	int ret;
> >> +	int ret = -ENOMEM;
> >>  
> >>  	if (!cma || !cma->count)
> >>  		return NULL;
> >> @@ -427,6 +427,33 @@ struct page *cma_alloc(struct cma *cma, size_t count, unsigned int align)
> >>  	trace_cma_alloc(pfn, page, count, align);
> >>  
> >>  	pr_debug("%s(): returned %p\n", __func__, page);
> >> +
> >> +	if (ret != 0) {
> >> +		unsigned int nr, nr_total = 0;
> >> +		unsigned long next_set_bit;
> >> +
> >> +		pr_info("%s: alloc failed, req-size: %zu pages, ret: %d\n",
> >> +			__func__, count, ret);
> >> +		mutex_lock(&cma->lock);
> >> +		printk("number of available pages: ");

I guess you want pr_info (or maybe pr_debug) here

> >> +		start = 0;
> >> +		for (;;) {
> >> +			bitmap_no = find_next_zero_bit(cma->bitmap, cma->count, start);
> >> +			next_set_bit = find_next_bit(cma->bitmap, cma->count, bitmap_no);
> >> +			nr = next_set_bit - bitmap_no;
> >> +			if (bitmap_no >= cma->count)
> >> +				break;
> >> +			if (nr_total == 0)
> >> +				printk("%u", nr);
> >> +			else
> >> +				printk("+%u", nr);

pr_cont

> >> +			nr_total += nr;
> >> +			start = bitmap_no + nr;
> >> +		}
> >> +		printk("=>%u pages, total: %lu pages\n", nr_total, cma->count);

pr_cont

> >> +		mutex_unlock(&cma->lock);
> >> +	}
> >> +
> >>  	return page;
> >>  }
> >>  
> >> -- 
> >> 1.9.1
> >>
> >> --
> >> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> >> the body to majordomo@...ck.org.  For more info on Linux MM,
> >> see: http://www.linux-mm.org/ .
> >> Don't email: <a href=mailto:"dont@...ck.org"> email@...ck.org </a>
> 
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majordomo@...ck.org.  For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: <a href=mailto:"dont@...ck.org"> email@...ck.org </a>

-- 
Michal Hocko
SUSE Labs