linux-kernel - Re: [PATCH] [BUGFIX] update mm->owner even if no next owner.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

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/