Re: [PATCH] mm/percpu: prevent concurrency problem for pcpu_nr_populated read with spin lock

[Jeongjun Park <aha310510@gmail.com>]

Shakeel Butt <shakeel.butt@linux.dev> wrote:
>
> On Wed, Jul 02, 2025 at 05:27:49PM +0900, Jeongjun Park wrote:
> > Read/Write to pcpu_nr_populated should be performed while protected
> > by pcpu_lock. However, pcpu_nr_pages() reads pcpu_nr_populated without any
> > protection, which causes a data race between read/write.
> >
> > Therefore, when reading pcpu_nr_populated in pcpu_nr_pages(), it should be
> > modified to be protected by pcpu_lock.
> >
> > Reported-by: syzbot+e5bd32b79413e86f389e@syzkaller.appspotmail.com
> > Fixes: 7e8a6304d541 ("/proc/meminfo: add percpu populated pages count")
> > Signed-off-by: Jeongjun Park <aha310510@gmail.com>
> > ---
> >  mm/percpu.c | 8 +++++++-
> >  1 file changed, 7 insertions(+), 1 deletion(-)
> >
> > 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;
>
> No need for the lock as I think race is fine here. Use something like
> the following and add a comment.
>
>         data_race(READ_ONCE(pcpu_nr_populated)) * pcpu_nr_units;
>

This race itself is not a critical security vuln, but it is a read/write
race that actually occurs. Writing to pcpu_nr_populated is already
systematically protected through pcpu_lock, so why do you think you can
ignore the data race only when reading?

--
Regards,

Jeongjun Park