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

[Minchan Kim]

On Fri, Jan 29, 2010 at 2:24 AM, Rik van Riel <riel@xxxxxxxxxx> 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 from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/