linux-kernel - Re: [PATCH v4 4/4] mm/vmalloc: don't assume vmap_area w/o VM_VM_AREA flag is vm_map

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>] [day] [month] [year] [list]

Message-ID: <20130903085959.GB30920@lge.com>
Date:	Tue, 3 Sep 2013 17:59:59 +0900
From:	Joonsoo Kim <iamjoonsoo.kim@....com>
To:	Wanpeng Li <liwanp@...ux.vnet.ibm.com>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	David Rientjes <rientjes@...gle.com>,
	KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>,
	Zhang Yanfei <zhangyanfei@...fujitsu.com>, linux-mm@...ck.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH v4 4/4] mm/vmalloc: don't assume vmap_area w/o VM_VM_AREA
 flag is vm_map_ram allocation

On Tue, Sep 03, 2013 at 03:51:39PM +0800, Wanpeng Li wrote:
> On Tue, Sep 03, 2013 at 04:42:21PM +0900, Joonsoo Kim wrote:
> >On Tue, Sep 03, 2013 at 03:01:46PM +0800, Wanpeng Li wrote:
> >> There is a race window between vmap_area free and show vmap_area information.
> >> 
> >> 	A                                                B
> >> 
> >> remove_vm_area
> >> spin_lock(&vmap_area_lock);
> >> 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 is introduced by commit: d4033afd(mm, vmalloc: iterate vmap_area_list, 
> >> instead of vmlist, in vmallocinfo()). This patch fix it by drop the assumption and 
> >> keep not dump vm_map_ram allocation information as the logic before that commit.
> >> 
> >> Signed-off-by: Wanpeng Li <liwanp@...ux.vnet.ibm.com>
> >> ---
> >>  mm/vmalloc.c | 7 -------
> >>  1 file changed, 7 deletions(-)
> >> 
> >> diff --git a/mm/vmalloc.c b/mm/vmalloc.c
> >> index 5368b17..62b7932 100644
> >> --- a/mm/vmalloc.c
> >> +++ b/mm/vmalloc.c
> >> @@ -2586,13 +2586,6 @@ static int s_show(struct seq_file *m, void *p)
> >>  	if (va->flags & (VM_LAZY_FREE | VM_LAZY_FREEING))
> >>  		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;
> >> -	}
> >> -
> >>  	v = va->vm;
> >>  
> >>  	seq_printf(m, "0x%pK-0x%pK %7ld",
> >
> >Hello, Wanpeng.
> >
> 
> Hi Joonsoo and Yanfei,
> 
> >Did you test this patch?
> >
> >I guess that, With this patch, if there are some vm_map areas,
> >null pointer deference would occurs, since va->vm may be null for it.
> >
> >And with this patch, if this race really occur, null pointer deference
> >would occurs too, since va->vm is set to null in remove_vm_area().
> >
> >I think that this is not a right fix for this possible race.
> >
> 
> How about append below to this patch?
> 
> if (va->vm)
> 	v = va->vm;
> else 
> 	return 0;

Hello,

I think that appending below code is better to represent it's purpose.
Maybe some comment is needed.

	/* blablabla */
	if (!(va->flags & VM_VM_AREA))
		return 0;

And maybe we can remove below code snippet, since
either VM_LAZY_FREE or VM_LAZY_FREEING is not possible for !VM_VM_AREA case.

	if (va->flags & (VM_LAZY_FREE | VM_LAZY_FREEING))
		return 0;

Thanks.
--
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/