[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <7b7d353f-f38b-3205-8fd4-1072dbf69cb6@gentwo.org>
Date: Wed, 2 Jul 2025 08:55:13 -0700 (PDT)
From: "Christoph Lameter (Ampere)" <cl@...two.org>
To: Jeongjun Park <aha310510@...il.com>
cc: dennis@...nel.org, tj@...nel.org, akpm@...ux-foundation.org,
vbabka@...e.cz, rientjes@...gle.com, linux-mm@...ck.org,
linux-kernel@...r.kernel.org,
syzbot+e5bd32b79413e86f389e@...kaller.appspotmail.com
Subject: Re: [PATCH] mm/percpu: prevent concurrency problem for pcpu_nr_populated
read with spin lock
On Wed, 2 Jul 2025, Jeongjun Park wrote:
> diff --git a/mm/percpu.c b/mm/percpu.c
> index b35494c8ede2..0f98b857fb36 100644
> --- a/mm/percpu.c
> +++ b/mm/percpu.c
> @@ -3355,7 +3355,13 @@ void __init setup_per_cpu_areas(void)
> */
> unsigned long pcpu_nr_pages(void)
> {
> - return pcpu_nr_populated * pcpu_nr_units;
> + unsigned long flags, ret;
> +
> + spin_lock_irqsave(&pcpu_lock, flags);
> + ret = pcpu_nr_populated * pcpu_nr_units;
> + spin_unlock_irqrestore(&pcpu_lock, flags);
Ummm.. What? You are protecting a single read with a spinlock? There needs
to be some updating of data somewhere for this to make sense.
Unless a different critical section protected by the lock sets the value
intermittendly to something you are not allowed to see before a final
store of a valid value. But that would be unusual.
This is an academic exercise or did you really see a problem?
What is racing?
Powered by blists - more mailing lists