From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail143.messagelabs.com (mail143.messagelabs.com [216.82.254.35]) by kanga.kvack.org (Postfix) with SMTP id 417B962009A for ; Thu, 6 May 2010 11:59:58 -0400 (EDT) Received: by gxk10 with SMTP id 10so74491gxk.10 for ; Thu, 06 May 2010 08:59:55 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: References: <1273065281-13334-1-git-send-email-mel@csn.ul.ie> <1273065281-13334-2-git-send-email-mel@csn.ul.ie> <20100505145620.GP20979@csn.ul.ie> <20100505175311.GU20979@csn.ul.ie> <20100506002255.GY20979@csn.ul.ie> Date: Fri, 7 May 2010 00:59:55 +0900 Message-ID: Subject: Re: [PATCH 1/2] mm,migration: Prevent rmap_walk_[anon|ksm] seeing the wrong VMA information From: Minchan Kim Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Sender: owner-linux-mm@kvack.org To: Linus Torvalds Cc: Mel Gorman , Andrew Morton , Linux-MM , LKML , KAMEZAWA Hiroyuki , Christoph Lameter , Andrea Arcangeli , Rik van Riel List-ID: On Thu, May 6, 2010 at 11:06 PM, Linus Torvalds wrote: > > > On Thu, 6 May 2010, Minchan Kim wrote: >> > + =C2=A0 =C2=A0 =C2=A0 =C2=A0*/ >> > + =C2=A0 =C2=A0 =C2=A0 avc =3D list_first_entry(&anon_vma->head, struc= t anon_vma_chain, same_anon_vma); >> >> Dumb question. >> >> I can't understand why we should use list_first_entry. > > It's not that we "should" use list_entry_first. It's that we want to find > _any_ entry on the list, and the most natural one is the first one. > > So we could take absolutely any 'avc' entry that is reachable from the > anon_vma, and use that to look up _any_ 'vma' that is associated with tha= t > anon_vma. And then, from _any_ of those vma's, we know how to get to the > "root anon_vma" - the one that they are all associated with. > > So no, there's absolutely nothing special about the first entry. It's > just a random easily found one. > > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Linus > Thanks, Linus and Mel. You understood my question correctly. :) My concern was following case. Child process does mmap new VMA but anon_vma is reused nearer child's VMA which is linked parent's VMA by fork. In that case, anon_vma_prepare calls list_add not list_add_tail. ex) list_add(&avc->same_anon_vma, &anon_vma->head); It means list_first_entry is the new VMA not old VMA and new VMA's root_avc isn't linked at parent's one. It means we are locking each other locks. That's why I have a question. But I carefully looked at the reusable_anon_vma and found list_is_singular. I remember Linus changed it to make problem simple. So in my scenario, new VMA can't share old VMA's anon_vma. So my story is broken. If I miss something, please, correct me. :) --=20 Kind regards, Minchan Kim -- 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: email@kvack.org