[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <YtGaP+e35DZYSQf0@slm.duckdns.org>
Date: Fri, 15 Jul 2022 06:47:59 -1000
From: Tejun Heo <tj@...nel.org>
To: Michal Koutný <mkoutny@...e.com>
Cc: Jing-Ting Wu <jing-ting.wu@...iatek.com>,
Johannes Weiner <hannes@...xchg.org>,
Zefan Li <lizefan.x@...edance.com>,
Matthias Brugger <matthias.bgg@...il.com>,
cgroups@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-arm-kernel@...ts.infradead.org,
linux-mediatek@...ts.infradead.org,
Shakeel Butt <shakeelb@...gle.com>, wsd_upstream@...iatek.com,
lixiong.liu@...iatek.com, wenju.xu@...iatek.com,
jonathan.jmchen@...iatek.com
Subject: Re: [Bug] race condition at rebind_subsystems()
(resending, I messed up the message header, sorry)
Hello,
On Fri, Jul 15, 2022 at 01:59:38PM +0200, Michal Koutný wrote:
> The css->rstat_css_node should not be modified if there are possible RCU
> readers elsewhere.
> One way to fix this would be to insert synchronize_rcu() after
> list_del_rcu() and before list_add_rcu().
> (A further alternative (I've heard about) would be to utilize 'nulls'
> RCU lists [1] to make the move between lists detectable.)
>
> But as I'm looking at it from distance, it may be simpler and sufficient
> to just take cgroup_rstat_lock around the list migration (the nesting
> under cgroup_mutex that's held with rebind_subsystems() is fine).
synchronize_rcu() prolly is the better fit here given how that list_node's
usage, but yeah, great find.
Thanks.
--
tejun
Powered by blists - more mailing lists