On Thu, May 6, 2010 at 11:06 PM, Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> 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 -- 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/ . Don't email: <a href