From: Michal Hocko <mhocko@suse.cz> To: Hugh Dickins <hughd@google.com> Cc: Andrew Morton <akpm@linux-foundation.org>, Johannes Weiner <hannes@cmpxchg.org>, Greg Thelen <gthelen@google.com>, Tejun Heo <tj@kernel.org>, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 1/2] memcg: fix endless loop in __mem_cgroup_iter_next Date: Thu, 13 Feb 2014 15:23:55 +0100 [thread overview] Message-ID: <20140213142355.GB11986@dhcp22.suse.cz> (raw) In-Reply-To: <alpine.LSU.2.11.1402121717420.5917@eggly.anvils> On Wed 12-02-14 17:26:46, Hugh Dickins wrote: > Commit 0eef615665ed ("memcg: fix css reference leak and endless loop in > mem_cgroup_iter") got the interaction with the commit a few before it > d8ad30559715 ("mm/memcg: iteration skip memcgs not yet fully initialized") > slightly wrong, and we didn't notice at the time. > > It's elusive, and harder to get than the original, but for a couple of > days before rc1, I several times saw a endless loop similar to that > supposedly being fixed. > > This time it was a tighter loop in __mem_cgroup_iter_next(): because we > can get here when our root has already been offlined, and the ordering > of conditions was such that we then just cycled around forever. > > Fixes: 0eef615665ed ("memcg: fix css reference leak and endless loop in mem_cgroup_iter") > Signed-off-by: Hugh Dickins <hughd@google.com> > Cc: stable@vger.kernel.org # 3.12+ You are right of course. This is really embarrassing. I should have noticed this when porting my original patch on top of yours. Acked-by: Michal Hocko <mhocko@suse.cz> Thanks! > --- > Of course I'd have preferred to send this before that commit went through > to -stable, but priorities kept preempting; I did wonder whether to ask > GregKH to delay it, but decided it's not serious enough to trouble him, > just go with the flow of stable fixing stable. > > mm/memcontrol.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > --- 3.14-rc2/mm/memcontrol.c 2014-02-02 18:49:07.897302115 -0800 > +++ linux/mm/memcontrol.c 2014-02-12 11:55:02.836035004 -0800 > @@ -1127,8 +1127,8 @@ skip_node: > * skipping css reference should be safe. > */ > if (next_css) { > - if ((next_css->flags & CSS_ONLINE) && > - (next_css == &root->css || css_tryget(next_css))) > + if ((next_css == &root->css) || > + ((next_css->flags & CSS_ONLINE) && css_tryget(next_css))) > return mem_cgroup_from_css(next_css); > > prev_css = next_css; -- Michal Hocko SUSE Labs
WARNING: multiple messages have this Message-ID (diff)
From: Michal Hocko <mhocko@suse.cz> To: Hugh Dickins <hughd@google.com> Cc: Andrew Morton <akpm@linux-foundation.org>, Johannes Weiner <hannes@cmpxchg.org>, Greg Thelen <gthelen@google.com>, Tejun Heo <tj@kernel.org>, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 1/2] memcg: fix endless loop in __mem_cgroup_iter_next Date: Thu, 13 Feb 2014 15:23:55 +0100 [thread overview] Message-ID: <20140213142355.GB11986@dhcp22.suse.cz> (raw) In-Reply-To: <alpine.LSU.2.11.1402121717420.5917@eggly.anvils> On Wed 12-02-14 17:26:46, Hugh Dickins wrote: > Commit 0eef615665ed ("memcg: fix css reference leak and endless loop in > mem_cgroup_iter") got the interaction with the commit a few before it > d8ad30559715 ("mm/memcg: iteration skip memcgs not yet fully initialized") > slightly wrong, and we didn't notice at the time. > > It's elusive, and harder to get than the original, but for a couple of > days before rc1, I several times saw a endless loop similar to that > supposedly being fixed. > > This time it was a tighter loop in __mem_cgroup_iter_next(): because we > can get here when our root has already been offlined, and the ordering > of conditions was such that we then just cycled around forever. > > Fixes: 0eef615665ed ("memcg: fix css reference leak and endless loop in mem_cgroup_iter") > Signed-off-by: Hugh Dickins <hughd@google.com> > Cc: stable@vger.kernel.org # 3.12+ You are right of course. This is really embarrassing. I should have noticed this when porting my original patch on top of yours. Acked-by: Michal Hocko <mhocko@suse.cz> Thanks! > --- > Of course I'd have preferred to send this before that commit went through > to -stable, but priorities kept preempting; I did wonder whether to ask > GregKH to delay it, but decided it's not serious enough to trouble him, > just go with the flow of stable fixing stable. > > mm/memcontrol.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > --- 3.14-rc2/mm/memcontrol.c 2014-02-02 18:49:07.897302115 -0800 > +++ linux/mm/memcontrol.c 2014-02-12 11:55:02.836035004 -0800 > @@ -1127,8 +1127,8 @@ skip_node: > * skipping css reference should be safe. > */ > if (next_css) { > - if ((next_css->flags & CSS_ONLINE) && > - (next_css == &root->css || css_tryget(next_css))) > + if ((next_css == &root->css) || > + ((next_css->flags & CSS_ONLINE) && css_tryget(next_css))) > return mem_cgroup_from_css(next_css); > > prev_css = next_css; -- Michal Hocko SUSE Labs -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2014-02-13 14:23 UTC|newest] Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top 2014-02-13 1:26 [PATCH 1/2] memcg: fix endless loop in __mem_cgroup_iter_next Hugh Dickins 2014-02-13 1:26 ` Hugh Dickins 2014-02-13 1:29 ` [PATCH 2/2] memcg: barriers to see memcgs as fully initialized Hugh Dickins 2014-02-13 1:29 ` Hugh Dickins 2014-02-13 14:53 ` Michal Hocko 2014-02-13 14:53 ` Michal Hocko 2014-02-16 2:52 ` Hugh Dickins 2014-02-16 2:52 ` Hugh Dickins 2014-02-13 21:07 ` Tejun Heo 2014-02-13 21:07 ` Tejun Heo 2014-02-13 14:23 ` Michal Hocko [this message] 2014-02-13 14:23 ` [PATCH 1/2] memcg: fix endless loop in __mem_cgroup_iter_next 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=20140213142355.GB11986@dhcp22.suse.cz \ --to=mhocko@suse.cz \ --cc=akpm@linux-foundation.org \ --cc=gthelen@google.com \ --cc=hannes@cmpxchg.org \ --cc=hughd@google.com \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-mm@kvack.org \ --cc=tj@kernel.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: linkBe 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.