[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20110613105410.e06720f1.kamezawa.hiroyu@jp.fujitsu.com>
Date: Mon, 13 Jun 2011 10:54:10 +0900
From: KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>
To: Hugh Dickins <hughd@...gle.com>
Cc: Johannes Weiner <hannes@...xchg.org>,
Andrea Arcangeli <aarcange@...hat.com>,
Ying Han <yinghan@...gle.com>, Dave Jones <davej@...hat.com>,
Linux Kernel <linux-kernel@...r.kernel.org>,
"linux-mm@...ck.org" <linux-mm@...ck.org>,
Oleg Nesterov <oleg@...hat.com>,
Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [PATCH] [BUGFIX] update mm->owner even if no next owner.
On Sun, 12 Jun 2011 18:41:58 -0700 (PDT)
Hugh Dickins <hughd@...gle.com> wrote:
> On Sat, 11 Jun 2011, Johannes Weiner wrote:
> > On Sat, Jun 11, 2011 at 01:54:42AM +0200, Johannes Weiner wrote:
> > > On Fri, Jun 10, 2011 at 02:49:35PM -0700, Hugh Dickins wrote:
> > > > On Fri, 10 Jun 2011, KAMEZAWA Hiroyuki wrote:
> > > > >
> > > > > I think this can be a fix.
> > > >
> > > > Sorry, I think not: I've not digested your rationale,
> > > > but three things stand out:
> > > >
> > > > 1. Why has this only just started happening? I may not have run that
> > > > test on 3.0-rc1, but surely I ran it for hours with 2.6.39;
> > > > maybe not with khugepaged, but certainly with ksmd.
> > > >
> > > > 2. Your hunk below:
> > > > > - if (!mm_need_new_owner(mm, p))
> > > > > + if (!mm_need_new_owner(mm, p)) {
> > > > > + rcu_assign_pointer(mm->owner, NULL);
> > > > is now setting mm->owner to NULL at times when we were sure it did not
> > > > need updating before (task is not the owner): you're damaging mm->owner.
> >
> > This is a problem with the patch, but I think Kame's analysis and
> > approach to fix it are still correct.
>
> Yes, I was looking at his patch, when I should have spent more time
> reading his comments: you're right, the analysis is fine, and I too
> dislike stale pointers.
>
> >
> > mm_update_next_owner() does not set mm->owner to NULL when the last
> > possible owner goes away, but leaves it pointing to a possibly stale
> > task struct.
> >
> > Noone cared before khugepaged, and up to Andrea's patch khugepaged
> > prevented the last possible owner from exiting until the call into the
> > memory controller had finished.
> >
> > Here is a revised version of Kame's fix.
>
> It seems to be strangely difficult to get right!
> I have no idea what your
> if (atomic_read(&mm->mm_users <= 1)) {
> actually ends up doing, I'm surprised it only gives compiler warnings
> rather than an error.
>
> The version I've signed off and am actually testing is below;
> but I've not had enough time to spare on the machine which reproduced
> it before, and another I thought I'd delegate it to last night,
> failed to reproduce without the patch. Try again tonight.
>
> Thought I'd better respond despite inadequate testing, given the flaw
> in the posted patch. Hope the one below is flawless.
>
Thank you, I'll do test, too.
-Kame
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists