From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758892Ab0EFP76 (ORCPT ); Thu, 6 May 2010 11:59:58 -0400 Received: from mail-yx0-f191.google.com ([209.85.210.191]:50135 "EHLO mail-yx0-f191.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753227Ab0EFP74 convert rfc822-to-8bit (ORCPT ); Thu, 6 May 2010 11:59:56 -0400 DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=GgRzSPZTRUm007jPw1GKTzabr6YBkICx9Sz7vWGyKhnOFAguLVlAW7ScGZIRaaoTfT tKp942AzMveP3fD2a8FxsqqEHDNBQQArAFJFbcHqpJeyRsx1YgkaEnpMbdt4XMYdOMj/ clrUPPGra4g1QYs8fVnhgzOt5BaDeRv6J9HbM= 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 To: Linus Torvalds Cc: Mel Gorman , Andrew Morton , Linux-MM , LKML , KAMEZAWA Hiroyuki , Christoph Lameter , Andrea Arcangeli , Rik van Riel Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, May 6, 2010 at 11:06 PM, Linus Torvalds wrote: > > > On Thu, 6 May 2010, Minchan Kim wrote: >> > +        */ >> > +       avc = list_first_entry(&anon_vma->head, struct 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 that > 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. > >                Linus > 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. :) -- Kind regards, Minchan Kim