lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Mon, 16 Sep 2013 17:27:52 -0400
From:	KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>
To:	liwanp@...ux.vnet.ibm.com
CC:	akpm@...ux-foundation.org, iamjoonsoo.kim@....com,
	rientjes@...gle.com, kosaki.motohiro@...fujitsu.com,
	zhangyanfei@...fujitsu.com, linux-mm@...ck.org,
	linux-kernel@...r.kernel.org
Subject: Re: [RESEND PATCH v5 4/4] mm/vmalloc: fix show vmap_area information
 race with vmap_area tear down

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@....com>
> Signed-off-by: Wanpeng Li <liwanp@...ux.vnet.ibm.com>

Acked-by: KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ