linux-kernel - Re: [PATCH] cma: allow concurrent cma pages allocation for multi-cma areas

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:	Fri, 05 Jun 2015 10:42:52 -0700
From:	Laura Abbott <labbott@...hat.com>
To:	Michał Nazarewicz <mina86@...a86.com>
CC:	Weijie Yang <weijie.yang@...sung.com>, iamjoonsoo.kim@....com,
	Marek Szyprowski <m.szyprowski@...sung.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Weijie Yang <weijie.yang.kh@...il.com>,
	"linux-mm@...ck.org" <linux-mm@...ck.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] cma: allow concurrent cma pages allocation for multi-cma
 areas

On 06/05/2015 10:19 AM, Michał Nazarewicz wrote:
> On Fri, Jun 05 2015, Laura Abbott wrote:
>> On 06/05/2015 01:01 AM, Weijie Yang wrote:
>>> Currently we have to hold the single cma_mutex when alloc cma pages,
>>> it is ok when there is only one cma area in system.
>>> However, when there are several cma areas, such as in our Android smart
>>> phone, the single cma_mutex prevents concurrent cma page allocation.
>>>
>>> This patch removes the single cma_mutex and uses per-cma area alloc_lock,
>>> this allows concurrent cma pages allocation for different cma areas while
>>> protects access to the same pageblocks.
>>>
>>> Signed-off-by: Weijie Yang <weijie.yang@...sung.com>
>
>> Last I knew alloc_contig_range needed to be serialized which is why we
>> still had the global CMA mutex. https://lkml.org/lkml/2014/2/18/462
>>
>> So NAK unless something has changed to allow this.
>
> This patch should be fine.
>
> Change you’ve pointed to would get rid of any serialisation around
> alloc_contig_range which is dangerous, but since CMA regions are
> pageblock-aligned:
>
>      /*
>       * Sanitise input arguments.
>       * Pages both ends in CMA area could be merged into adjacent unmovable
>       * migratetype page by page allocator's buddy algorithm. In the case,
>       * you couldn't get a contiguous memory, which is not what we want.
>       */
>      alignment = max(alignment,
>          (phys_addr_t)PAGE_SIZE << max(MAX_ORDER - 1, pageblock_order));
>      base = ALIGN(base, alignment);
>      size = ALIGN(size, alignment);
>      limit &= ~(alignment - 1);
>
> synchronising allocation in each area should work fine.
>

Okay yes, you are correct. I was somehow thinking that different CMA regions
could end up in the same pageblock. This is documented in alloc_contig_range
but can we put a comment explaining this here too? It seems to come up
every time locking here is discussed.

Thanks,
Laura

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