On Mon, Sep 16, 2013 at 05:27:52PM -0400, KOSAKI Motohiro wrote:
>On 9/14/2013 7:45 PM, Wanpeng Li wrote:
>> Changelog:
>> *v4 -> v5: return directly for !VM_VM_AREA case and remove (VM_LAZY_FREE | VM_LAZY_FREEING) check
>>
>> There is a race window between vmap_area tear down and show vmap_area information.
>>
>> A B
>>
>> remove_vm_area
>> spin_lock(&vmap_area_lock);
>> va->vm = NULL;
>> va->flags &= ~VM_VM_AREA;
>> spin_unlock(&vmap_area_lock);
>> spin_lock(&vmap_area_lock);
>> if (va->flags & (VM_LAZY_FREE | VM_LAZY_FREEZING))
>> return 0;
>> if (!(va->flags & VM_VM_AREA)) {
>> seq_printf(m, "0x%pK-0x%pK %7ld vm_map_ram\n",
>> (void *)va->va_start, (void *)va->va_end,
>> va->va_end - va->va_start);
>> return 0;
>> }
>> free_unmap_vmap_area(va);
>> flush_cache_vunmap
>> free_unmap_vmap_area_noflush
>> unmap_vmap_area
>> free_vmap_area_noflush
>> va->flags |= VM_LAZY_FREE
>>
>> The assumption !VM_VM_AREA represents vm_map_ram allocation is introduced by
>> commit: d4033afd(mm, vmalloc: iterate vmap_area_list, instead of vmlist, in
>> vmallocinfo()). However, !VM_VM_AREA also represents vmap_area is being tear
>> down in race window mentioned above. This patch fix it by don't dump any
>> information for !VM_VM_AREA case and also remove (VM_LAZY_FREE | VM_LAZY_FREEING)
>> check since they are not possible for !VM_VM_AREA case.
>>
>> Suggested-by: Joonsoo Kim <iamjoonsoo.kim@xxxxxxx>
>> Signed-off-by: Wanpeng Li <liwanp@xxxxxxxxxxxxxxxxxx>
>
>Acked-by: KOSAKI Motohiro <kosaki.motohiro@xxxxxxxxxxxxxx>
>
Thanks for your review. ;-)
Regards,
Wanpeng Li
>--
>To unsubscribe, send a message with 'unsubscribe linux-mm' in
>the body to majordomo@xxxxxxxxx. For more info on Linux MM,
>see: http://www.linux-mm.org/ .
>Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxx. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>