[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20191121152847.GA14375@blackbody.suse.cz>
Date: Thu, 21 Nov 2019 16:28:47 +0100
From: Michal Koutný <mkoutny@...e.com>
To: Roman Gushchin <guro@...com>
Cc: "linux-mm@...ck.org" <linux-mm@...ck.org>,
Andrew Morton <akpm@...ux-foundation.org>,
Michal Hocko <mhocko@...nel.org>,
Johannes Weiner <hannes@...xchg.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Kernel Team <Kernel-team@...com>,
"stable@...r.kernel.org" <stable@...r.kernel.org>,
Tejun Heo <tj@...nel.org>
Subject: Re: [PATCH 1/2] mm: memcg: switch to css_tryget() in
get_mem_cgroup_from_mm()
On Wed, Nov 13, 2019 at 05:08:29PM +0000, Roman Gushchin <guro@...com> wrote:
> The thing here is that css_tryget_online() cannot pin the online state,
> so even if returned true, the cgroup can be offline at the return from
> the function.
Adding this for the record.
The actual offlining happens only from css_killed_ref_fn, which is
percpu_ref_kill_and_confirm confirmation callback. That is only called
after RCU grace period. So, css_tryget_online will pin the online state
_inside_ rcu_read_{,un}lock section.
The fact is that many call sites pass the css reference over
rcu_read_unlock boundary allowing potential offlining.
> So if we rely somewhere on it, it's already broken.
Charges into offlined memcg should fine (wrt the original patch). I
didn't check other callers though...
> Generally speaking, it's better to reduce it's usage to the bare minimum.
...I agree as it's confusing and potentially redundant.
Michal
Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)
Powered by blists - more mailing lists