linux-kernel - Re: [PATCH] mm/cma: add an API to enable/disable concurrent memory allocation for the CMA

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: <20250127150412.875e666a728c3d7bde0726b0@linux-foundation.org>
Date: Mon, 27 Jan 2025 15:04:12 -0800
From: Andrew Morton <akpm@...ux-foundation.org>
To: yangge1116@....com
Cc: linux-mm@...ck.org, linux-kernel@...r.kernel.org,
 stable@...r.kernel.org, 21cnbao@...il.com, david@...hat.com,
 baolin.wang@...ux.alibaba.com, aisheng.dong@....com, liuzixing@...on.cn
Subject: Re: [PATCH] mm/cma: add an API to enable/disable concurrent memory
 allocation for the CMA

On Fri, 24 Jan 2025 19:21:27 +0800 yangge1116@....com wrote:

> From: yangge <yangge1116@....com>
> 
> Commit 60a60e32cf91 ("Revert "mm/cma.c: remove redundant cma_mutex lock"")
> simply reverts to the original method of using the cma_mutex to ensure
> that alloc_contig_range() runs sequentially. This change was made to avoid
> concurrency allocation failures. However, it can negatively impact
> performance when concurrent allocation of CMA memory is required.
> 
> To address this issue, we could introduce an API for concurrency settings,
> allowing users to decide whether their CMA can perform concurrent memory
> allocations or not.

The term "users" tends to refer to userspace code.  Here I'm thinking
you mean in-kernel code, so a better term to use is "callers".

This new interface has no callers.  We prefer not to merge unused code!
Please send along the patch which calls cma_set_concurrency() so we
can better understand this proposal and so that the new code is
testable.  In fact the patch has cc:stable, which makes things
stranger.  Why should the -stable maintainers merge a patch which
doesn't do anything?

And please quantify the benefit.  "negatively impact" is too vague. 
How much benefit can we expect our users to see from this?  Some
runtime testing results would be good.

And please describe in more detail why this particular caller doesn't
require concurrency protection.  And help other developers understand
when it is safe for them to use concurr_alloc==false.