All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michal Hocko <mhocko@kernel.org>
To: Roman Gushchin <guro@fb.com>
Cc: Naresh Kamboju <naresh.kamboju@linaro.org>,
	Shakeel Butt <shakeelb@google.com>,
	Johannes Weiner <hannes@cmpxchg.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	linux-mm <linux-mm@kvack.org>,
	open list <linux-kernel@vger.kernel.org>,
	lkft-triage@lists.linaro.org, Chris Down <chris@chrisdown.name>
Subject: Re: BUG: Bad page state in process - page dumped because: page still charged to cgroup
Date: Thu, 2 Jul 2020 18:22:02 +0200	[thread overview]
Message-ID: <20200702162202.GI18446@dhcp22.suse.cz> (raw)
In-Reply-To: <20200701184552.GA61684@carbon.DHCP.thefacebook.com>

On Wed 01-07-20 11:45:52, Roman Gushchin wrote:
[...]
> >From c97afecd32c0db5e024be9ba72f43d22974f5bcd Mon Sep 17 00:00:00 2001
> From: Roman Gushchin <guro@fb.com>
> Date: Wed, 1 Jul 2020 11:05:32 -0700
> Subject: [PATCH] mm: kmem: make memcg_kmem_enabled() irreversible
> 
> Historically the kernel memory accounting was an opt-in feature, which
> could be enabled for individual cgroups. But now it's not true, and
> it's on by default both on cgroup v1 and cgroup v2.  And as long as a
> user has at least one non-root memory cgroup, the kernel memory
> accounting is on. So in most setups it's either always on (if memory
> cgroups are in use and kmem accounting is not disabled), either always
> off (otherwise).
> 
> memcg_kmem_enabled() is used in many places to guard the kernel memory
> accounting code. If memcg_kmem_enabled() can reverse from returning
> true to returning false (as now), we can't rely on it on release paths
> and have to check if it was on before.
> 
> If we'll make memcg_kmem_enabled() irreversible (always returning true
> after returning it for the first time), it'll make the general logic
> more simple and robust. It also will allow to guard some checks which
> otherwise would stay unguarded.
> 
> Signed-off-by: Roman Gushchin <guro@fb.com>
> ---
>  mm/memcontrol.c | 6 ++----
>  1 file changed, 2 insertions(+), 4 deletions(-)
> 
> diff --git a/mm/memcontrol.c b/mm/memcontrol.c
> index 50ae77f3985e..2d018a51c941 100644
> --- a/mm/memcontrol.c
> +++ b/mm/memcontrol.c
> @@ -3582,7 +3582,8 @@ static int memcg_online_kmem(struct mem_cgroup *memcg)
>  	objcg->memcg = memcg;
>  	rcu_assign_pointer(memcg->objcg, objcg);
>  
> -	static_branch_inc(&memcg_kmem_enabled_key);
> +	if (!memcg_kmem_enabled())
> +		static_branch_inc(&memcg_kmem_enabled_key);

Wouldn't be static_branch_enable() more readable?

>  	/*
>  	 * A memory cgroup is considered kmem-online as soon as it gets
>  	 * kmemcg_id. Setting the id after enabling static branching will
> @@ -3643,9 +3644,6 @@ static void memcg_free_kmem(struct mem_cgroup *memcg)
>  	/* css_alloc() failed, offlining didn't happen */
>  	if (unlikely(memcg->kmem_state == KMEM_ONLINE))
>  		memcg_offline_kmem(memcg);
> -
> -	if (memcg->kmem_state == KMEM_ALLOCATED)
> -		static_branch_dec(&memcg_kmem_enabled_key);
>  }
>  #else
>  static int memcg_online_kmem(struct mem_cgroup *memcg)
> -- 
> 2.26.2

-- 
Michal Hocko
SUSE Labs

  parent reply	other threads:[~2020-07-02 16:22 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-01  8:18 BUG: Bad page state in process - page dumped because: page still charged to cgroup Naresh Kamboju
2020-07-01  8:18 ` Naresh Kamboju
2020-07-01  8:29 ` Michal Hocko
2020-07-01 12:31   ` Naresh Kamboju
2020-07-01 12:31     ` Naresh Kamboju
2020-07-01 18:45   ` Roman Gushchin
2020-07-02  6:19     ` Michal Hocko
2020-07-02  6:52     ` Naresh Kamboju
2020-07-02  6:52       ` Naresh Kamboju
2020-07-02 15:49       ` Roman Gushchin
2020-07-02 15:55         ` Naresh Kamboju
2020-07-02 15:55           ` Naresh Kamboju
2020-07-02 15:59           ` Roman Gushchin
2020-07-02 16:02     ` Shakeel Butt
2020-07-02 16:02       ` Shakeel Butt
2020-07-02 16:22     ` Michal Hocko [this message]
2020-07-02 16:35       ` Vlastimil Babka
2020-07-02 17:07         ` Roman Gushchin
2020-07-02 17:10         ` Michal Hocko
2020-07-02 16:37       ` Roman Gushchin
2020-07-02 17:13         ` Michal Hocko
2020-07-02 17:19           ` Roman Gushchin

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=20200702162202.GI18446@dhcp22.suse.cz \
    --to=mhocko@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=chris@chrisdown.name \
    --cc=guro@fb.com \
    --cc=hannes@cmpxchg.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=lkft-triage@lists.linaro.org \
    --cc=naresh.kamboju@linaro.org \
    --cc=shakeelb@google.com \
    /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.