linux-kernel - Re: [PATCH] percpu: fix race on alloc failed warning limit

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: <aKqB9sGmgJwsTXGg@MiWiFi-R3L-srv>
Date: Sun, 24 Aug 2025 11:07:34 +0800
From: Baoquan He <bhe@...hat.com>
To: Vlad Dumitrescu <vdumitrescu@...dia.com>
Cc: Dennis Zhou <dennis@...nel.org>, Tejun Heo <tj@...nel.org>,
	Christoph Lameter <cl@...two.org>,
	Andrew Morton <akpm@...ux-foundation.org>, linux-mm@...ck.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] percpu: fix race on alloc failed warning limit

On 08/22/25 at 03:55pm, Vlad Dumitrescu wrote:
> The 'allocation failed, ...' warning messages can cause unlimited log
> spam, contrary to the implementation's intent.
> 
> The warn_limit variable is accessed without synchronization. If more
> than <warn_limit> threads enter the warning path at the same time, the
> variable will get decremented past 0. Once it becomes negative, the
> non-zero check will always return true leading to unlimited log spam.
> 
> Use atomic operations to access warn_limit and change the check to test
> for positive (> 0) as it can still become negative.
> 
> While the change cited in Fixes is only adjacent, the warning limit
> implementation was correct before it. Only non-atomic allocations were
> considered for warnings, and those happened to hold pcpu_alloc_mutex
> while accessing warn_limit.
> 
> Fixes: f7d77dfc91f7 ("mm/percpu.c: print error message too if atomic alloc failed")
> Signed-off-by: Vlad Dumitrescu <vdumitrescu@...dia.com>
> ---
>  mm/percpu.c | 20 ++++++++++++--------
>  1 file changed, 12 insertions(+), 8 deletions(-)
> 
> diff --git a/mm/percpu.c b/mm/percpu.c
> index a56f35dcc417..c1a4089eb4c3 100644
> --- a/mm/percpu.c
> +++ b/mm/percpu.c
> @@ -1734,7 +1734,7 @@ void __percpu *pcpu_alloc_noprof(size_t size, size_t align, bool reserved,
>  	bool is_atomic;
>  	bool do_warn;
>  	struct obj_cgroup *objcg = NULL;
> -	static int warn_limit = 10;
> +	static atomic_t warn_limit = ATOMIC_INIT(10);
>  	struct pcpu_chunk *chunk, *next;
>  	const char *err;
>  	int slot, off, cpu, ret;
> @@ -1904,13 +1904,17 @@ void __percpu *pcpu_alloc_noprof(size_t size, size_t align, bool reserved,
>  fail:
>  	trace_percpu_alloc_percpu_fail(reserved, is_atomic, size, align);
>  
> -	if (do_warn && warn_limit) {
> -		pr_warn("allocation failed, size=%zu align=%zu atomic=%d, %s\n",
> -			size, align, is_atomic, err);
> -		if (!is_atomic)
> -			dump_stack();
> -		if (!--warn_limit)
> -			pr_info("limit reached, disable warning\n");
> +	if (do_warn && atomic_read(&warn_limit) > 0) {
> +		int remaining = atomic_dec_return(&warn_limit);
> +
> +		if (remaining >= 0) {
> +			pr_warn("allocation failed, size=%zu align=%zu atomic=%d, %s\n",
> +				size, align, is_atomic, err);
> +			if (!is_atomic)
> +				dump_stack();
> +			if (remaining == 0)
> +				pr_info("limit reached, disable warning\n");
> +		}

A good catch, and the new code logic makes code more robust, thanks for
the fix.

Reviewed-by: Baoquan He <bhe@...hat.com>

>  	}
>  
>  	if (is_atomic) {
> -- 
> 2.49.0
>