Re: [PATCH -mm] change anon_vma linking to fix multi-process server scalability issue

[Minchan Kim <minchan.kim@gmail.com>]

On Fri, Jan 29, 2010 at 2:24 AM, Rik van Riel <riel@redhat.com> wrote:
>>> -void vma_adjust(struct vm_area_struct *vma, unsigned long start,
>>> +int vma_adjust(struct vm_area_struct *vma, unsigned long start,
>>>        unsigned long end, pgoff_t pgoff, struct vm_area_struct *insert)
>>>  {
>>>        struct mm_struct *mm = vma->vm_mm;
>>> @@ -542,6 +541,29 @@ again:                     remove_next = 1 + (end>
>>>  next->vm_end);
>>>                }
>>>        }
>>>
>>> +       /*
>>> +        * When changing only vma->vm_end, we don't really need
>>> +        * anon_vma lock.
>>> +        */
>>> +       if (vma->anon_vma&&  (insert || importer || start !=
>>> vma->vm_start))
>>> +               anon_vma = vma->anon_vma;
>>> +       if (anon_vma) {
>>> +               /*
>>> +                * Easily overlooked: when mprotect shifts the boundary,
>>> +                * make sure the expanding vma has anon_vma set if the
>>> +                * shrinking vma had, to cover any anon pages imported.
>>> +                */
>>> +               if (importer&&  !importer->anon_vma) {
>>> +                       /* Block reverse map lookups until things are set
>>> up. */
>>> +                       importer->vm_flags |= VM_LOCK_RMAP;
>>> +                       if (anon_vma_clone(importer, vma)) {
>>> +                               importer->vm_flags&= ~VM_LOCK_RMAP;
>>> +                               return -ENOMEM;
>>
>> If we fail in here during progressing on next vmas in case of mprotect
>> case 6,
>> the previous vmas would become inconsistent state.
>
> I've re-read the code, but I don't see what you are referring
> to.  If vma_adjust bails out early, no VMAs will be adjusted
> and all the VMAs will stay the way they were before mprotect
> was called.
>
> What am I overlooking?

I also look at the code more detail and found me wrong.
In mprotect case 6,  the importer is fixed as head of vmas while next
is marched
on forward. So anon_vma_clone is just called once at first time.
So as what you said, It's no problem.
Totally, my mistake. Sorry for that, Rik.

-- 
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: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>