On Sun, 12 Jun 2011 18:41:58 -0700 (PDT)
Hugh Dickins <hughd@xxxxxxxxxx> 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, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxxx For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>