From: Roman Gushchin <roman.gushchin@linux.dev>
To: Breno Leitao <leitao@debian.org>
Cc: Johannes Weiner <hannes@cmpxchg.org>,
Michal Hocko <mhocko@kernel.org>,
Shakeel Butt <shakeel.butt@linux.dev>,
Muchun Song <muchun.song@linux.dev>,
Andrew Morton <akpm@linux-foundation.org>,
paulmck@kernel.org,
"open list:CONTROL GROUP - MEMORY RESOURCE CONTROLLER (MEMCG)"
<cgroups@vger.kernel.org>,
"open list:CONTROL GROUP - MEMORY RESOURCE CONTROLLER (MEMCG)"
<linux-mm@kvack.org>, open list <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] mm: memcg: use READ_ONCE()/WRITE_ONCE() to access stock->nr_pages
Date: Wed, 1 May 2024 16:18:57 -0700 [thread overview]
Message-ID: <ZjLN4eWVwr9W-pk8@P9FQF9L96D> (raw)
In-Reply-To: <20240501095420.679208-1-leitao@debian.org>
On Wed, May 01, 2024 at 02:54:20AM -0700, Breno Leitao wrote:
> A memcg pointer in the per-cpu stock can be accessed by drain_all_stock()
> and consume_stock() in parallel, causing a potential race.
>
> KCSAN shows this data-race clearly in the splat below:
>
> BUG: KCSAN: data-race in drain_all_stock.part.0 / try_charge_memcg
>
> write to 0xffff88903f8b0788 of 4 bytes by task 35901 on cpu 2:
> try_charge_memcg (mm/memcontrol.c:2323 mm/memcontrol.c:2746)
> __mem_cgroup_charge (mm/memcontrol.c:7287 mm/memcontrol.c:7301)
> do_anonymous_page (mm/memory.c:1054 mm/memory.c:4375 mm/memory.c:4433)
> __handle_mm_fault (mm/memory.c:3878 mm/memory.c:5300 mm/memory.c:5441)
> handle_mm_fault (mm/memory.c:5606)
> do_user_addr_fault (arch/x86/mm/fault.c:1363)
> exc_page_fault (./arch/x86/include/asm/irqflags.h:37
> ./arch/x86/include/asm/irqflags.h:72
> arch/x86/mm/fault.c:1513
> arch/x86/mm/fault.c:1563)
> asm_exc_page_fault (./arch/x86/include/asm/idtentry.h:623)
>
> read to 0xffff88903f8b0788 of 4 bytes by task 287 on cpu 27:
> drain_all_stock.part.0 (mm/memcontrol.c:2433)
> mem_cgroup_css_offline (mm/memcontrol.c:5398 mm/memcontrol.c:5687)
> css_killed_work_fn (kernel/cgroup/cgroup.c:5521 kernel/cgroup/cgroup.c:5794)
> process_one_work (kernel/workqueue.c:3254)
> worker_thread (kernel/workqueue.c:3329 kernel/workqueue.c:3416)
> kthread (kernel/kthread.c:388)
> ret_from_fork (arch/x86/kernel/process.c:147)
> ret_from_fork_asm (arch/x86/entry/entry_64.S:257)
>
> value changed: 0x00000014 -> 0x00000013
>
> This happens because drain_all_stock() is reading stock->nr_pages, while
> consume_stock() might be updating the same address, causing a potential
> data-race.
Btw there is an actual data race, which is periodically causing a needless
draining of a per-cpu stock.
>
> Make the shared addresses bulletproof regarding to reads and writes,
> similarly to what stock->cached_objcg and stock->cached.
> Annotate all accesses to stock->nr_pages with READ_ONCE()/WRITE_ONCE().
>
> Signed-off-by: Breno Leitao <leitao@debian.org>
Reviewed-by: Roman Gushchin <roman.gushchin@linux.dev>
next prev parent reply other threads:[~2024-05-01 23:19 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-01 9:54 [PATCH] mm: memcg: use READ_ONCE()/WRITE_ONCE() to access stock->nr_pages Breno Leitao
2024-05-01 20:47 ` Shakeel Butt
2024-05-01 23:18 ` Roman Gushchin [this message]
2024-05-03 11:28 ` Michal Hocko
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZjLN4eWVwr9W-pk8@P9FQF9L96D \
--to=roman.gushchin@linux.dev \
--cc=akpm@linux-foundation.org \
--cc=cgroups@vger.kernel.org \
--cc=hannes@cmpxchg.org \
--cc=leitao@debian.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@kernel.org \
--cc=muchun.song@linux.dev \
--cc=paulmck@kernel.org \
--cc=shakeel.butt@linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.