From: "Michal Koutný" <mkoutny-IBi9RG/b67k@public.gmane.org>
To: Andrew Morton <akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>
Cc: Chris Down <chris-6Bi1550iOqEnzZ6mRAm98g@public.gmane.org>,
Johannes Weiner <hannes-druUgvl0LCNAfugRpC6u6w@public.gmane.org>,
Tejun Heo <tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
Roman Gushchin <guro-b10kYP2dOMg@public.gmane.org>,
linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org,
cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
kernel-team-b10kYP2dOMg@public.gmane.org
Subject: Re: [PATCH 3/6] mm, memcg: Prevent memory.low load/store tearing
Date: Fri, 12 Jun 2020 19:03:52 +0200 [thread overview]
Message-ID: <20200612170352.GA40768@blackbook> (raw)
In-Reply-To: <448206f44b0fa7be9dad2ca2601d2bcb2c0b7844.1584034301.git.chris-6Bi1550iOqEnzZ6mRAm98g@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 2142 bytes --]
Hello.
I see suspicious asymmetry, in the current mainline:
> WRITE_ONCE(memcg->memory.emin, effective_protection(usage, parent_usage,
> READ_ONCE(memcg->memory.min),
> READ_ONCE(parent->memory.emin),
> atomic_long_read(&parent->memory.children_min_usage)));
>
> WRITE_ONCE(memcg->memory.elow, effective_protection(usage, parent_usage,
> memcg->memory.low, READ_ONCE(parent->memory.elow),
> atomic_long_read(&parent->memory.children_low_usage)));
On Thu, Mar 12, 2020 at 05:33:01PM +0000, Chris Down <chris-6Bi1550iOqEnzZ6mRAm98g@public.gmane.org> wrote:
> diff --git a/mm/memcontrol.c b/mm/memcontrol.c
> index aca2964ea494..c85a304fa4a1 100644
> --- a/mm/memcontrol.c
> +++ b/mm/memcontrol.c
> @@ -6262,7 +6262,7 @@ enum mem_cgroup_protection mem_cgroup_protected(struct mem_cgroup *root,
> return MEMCG_PROT_NONE;
>
> emin = memcg->memory.min;
> - elow = memcg->memory.low;
> + elow = READ_ONCE(memcg->memory.low);
>
> parent = parent_mem_cgroup(memcg);
> /* No parent means a non-hierarchical mode on v1 memcg */
> @@ -6291,7 +6291,7 @@ enum mem_cgroup_protection mem_cgroup_protected(struct mem_cgroup *root,
> if (elow && parent_elow) {
> unsigned long low_usage, siblings_low_usage;
>
> - low_usage = min(usage, memcg->memory.low);
> + low_usage = min(usage, READ_ONCE(memcg->memory.low));
> siblings_low_usage = atomic_long_read(
> &parent->memory.children_low_usage);
Is it possible that these hunks were lost during rebase/merge?
IMHO it should apply as:
-- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@ -6428,7 +6428,8 @@ enum mem_cgroup_protection mem_cgroup_protected(struct mem_cgroup *root,
atomic_long_read(&parent->memory.children_min_usage)));
WRITE_ONCE(memcg->memory.elow, effective_protection(usage, parent_usage,
- memcg->memory.low, READ_ONCE(parent->memory.elow),
+ READ_ONCE(memcg->memory.low),
+ READ_ONCE(parent->memory.elow),
atomic_long_read(&parent->memory.children_low_usage)));
out:
Michal
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
WARNING: multiple messages have this Message-ID (diff)
From: "Michal Koutný" <mkoutny@suse.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Chris Down <chris@chrisdown.name>,
Johannes Weiner <hannes@cmpxchg.org>, Tejun Heo <tj@kernel.org>,
Roman Gushchin <guro@fb.com>,
linux-mm@kvack.org, cgroups@vger.kernel.org,
linux-kernel@vger.kernel.org, kernel-team@fb.com
Subject: Re: [PATCH 3/6] mm, memcg: Prevent memory.low load/store tearing
Date: Fri, 12 Jun 2020 19:03:52 +0200 [thread overview]
Message-ID: <20200612170352.GA40768@blackbook> (raw)
In-Reply-To: <448206f44b0fa7be9dad2ca2601d2bcb2c0b7844.1584034301.git.chris@chrisdown.name>
[-- Attachment #1: Type: text/plain, Size: 2117 bytes --]
Hello.
I see suspicious asymmetry, in the current mainline:
> WRITE_ONCE(memcg->memory.emin, effective_protection(usage, parent_usage,
> READ_ONCE(memcg->memory.min),
> READ_ONCE(parent->memory.emin),
> atomic_long_read(&parent->memory.children_min_usage)));
>
> WRITE_ONCE(memcg->memory.elow, effective_protection(usage, parent_usage,
> memcg->memory.low, READ_ONCE(parent->memory.elow),
> atomic_long_read(&parent->memory.children_low_usage)));
On Thu, Mar 12, 2020 at 05:33:01PM +0000, Chris Down <chris@chrisdown.name> wrote:
> diff --git a/mm/memcontrol.c b/mm/memcontrol.c
> index aca2964ea494..c85a304fa4a1 100644
> --- a/mm/memcontrol.c
> +++ b/mm/memcontrol.c
> @@ -6262,7 +6262,7 @@ enum mem_cgroup_protection mem_cgroup_protected(struct mem_cgroup *root,
> return MEMCG_PROT_NONE;
>
> emin = memcg->memory.min;
> - elow = memcg->memory.low;
> + elow = READ_ONCE(memcg->memory.low);
>
> parent = parent_mem_cgroup(memcg);
> /* No parent means a non-hierarchical mode on v1 memcg */
> @@ -6291,7 +6291,7 @@ enum mem_cgroup_protection mem_cgroup_protected(struct mem_cgroup *root,
> if (elow && parent_elow) {
> unsigned long low_usage, siblings_low_usage;
>
> - low_usage = min(usage, memcg->memory.low);
> + low_usage = min(usage, READ_ONCE(memcg->memory.low));
> siblings_low_usage = atomic_long_read(
> &parent->memory.children_low_usage);
Is it possible that these hunks were lost during rebase/merge?
IMHO it should apply as:
-- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@ -6428,7 +6428,8 @@ enum mem_cgroup_protection mem_cgroup_protected(struct mem_cgroup *root,
atomic_long_read(&parent->memory.children_min_usage)));
WRITE_ONCE(memcg->memory.elow, effective_protection(usage, parent_usage,
- memcg->memory.low, READ_ONCE(parent->memory.elow),
+ READ_ONCE(memcg->memory.low),
+ READ_ONCE(parent->memory.elow),
atomic_long_read(&parent->memory.children_low_usage)));
out:
Michal
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2020-06-12 17:03 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-12 17:32 [PATCH 0/6] mm, memcg: cgroup v2 tunable load/store tearing fixes Chris Down
[not found] ` <cover.1584034301.git.chris-6Bi1550iOqEnzZ6mRAm98g@public.gmane.org>
2020-03-12 17:32 ` [PATCH 1/6] mm, memcg: Prevent memory.high load/store tearing Chris Down
2020-03-12 17:32 ` Chris Down
[not found] ` <2f66f7038ed1d4688e59de72b627ae0ea52efa83.1584034301.git.chris-6Bi1550iOqEnzZ6mRAm98g@public.gmane.org>
2020-03-16 14:54 ` Michal Hocko
2020-03-16 14:54 ` Michal Hocko
2020-03-12 17:32 ` [PATCH 2/6] mm, memcg: Prevent memory.max load tearing Chris Down
2020-03-12 17:32 ` Chris Down
[not found] ` <50a31e5f39f8ae6c8fb73966ba1455f0924e8f44.1584034301.git.chris-6Bi1550iOqEnzZ6mRAm98g@public.gmane.org>
2020-03-16 14:56 ` Michal Hocko
2020-03-16 14:56 ` Michal Hocko
2020-03-12 17:33 ` [PATCH 3/6] mm, memcg: Prevent memory.low load/store tearing Chris Down
2020-03-12 17:33 ` Chris Down
[not found] ` <448206f44b0fa7be9dad2ca2601d2bcb2c0b7844.1584034301.git.chris-6Bi1550iOqEnzZ6mRAm98g@public.gmane.org>
2020-03-16 14:57 ` Michal Hocko
2020-03-16 14:57 ` Michal Hocko
2020-06-12 17:03 ` Michal Koutný [this message]
2020-06-12 17:03 ` Michal Koutný
2020-06-12 17:13 ` Chris Down
2020-06-12 17:13 ` Chris Down
2020-03-12 17:33 ` [PATCH 6/6] mm, memcg: Prevent mem_cgroup_protected store tearing Chris Down
2020-03-12 17:33 ` Chris Down
2020-03-16 14:59 ` Michal Hocko
2020-03-12 17:33 ` [PATCH 4/6] mm, memcg: Prevent memory.min load/store tearing Chris Down
[not found] ` <e809b4e6b0c1626dac6945970de06409a180ee65.1584034301.git.chris-6Bi1550iOqEnzZ6mRAm98g@public.gmane.org>
2020-03-16 14:58 ` Michal Hocko
2020-03-16 14:58 ` Michal Hocko
2020-03-12 17:33 ` [PATCH 5/6] mm, memcg: Prevent memory.swap.max load tearing Chris Down
[not found] ` <bbec2c3d822217334855c8877a9d28b2a6d395fb.1584034301.git.chris-6Bi1550iOqEnzZ6mRAm98g@public.gmane.org>
2020-03-16 14:58 ` Michal Hocko
2020-03-16 14:58 ` 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=20200612170352.GA40768@blackbook \
--to=mkoutny-ibi9rg/b67k@public.gmane.org \
--cc=akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org \
--cc=cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=chris-6Bi1550iOqEnzZ6mRAm98g@public.gmane.org \
--cc=guro-b10kYP2dOMg@public.gmane.org \
--cc=hannes-druUgvl0LCNAfugRpC6u6w@public.gmane.org \
--cc=kernel-team-b10kYP2dOMg@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org \
--cc=tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \
/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.