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....@lge.com>
> Signed-off-by: Wanpeng Li <liw...@linux.vnet.ibm.com>
Acked-by: KOSAKI Motohiro <kosaki.motoh...@jp.fujitsu.com>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
