From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Sun, 6 Nov 2005 05:56:42 +0000 (GMT) From: Hugh Dickins Subject: Re: Does shmem_getpage==>shmem_alloc_page==>alloc_page_vma hold mmap_sem? In-Reply-To: <20051105212133.714da0d2.pj@sgi.com> Message-ID: References: <20051105212133.714da0d2.pj@sgi.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mm@kvack.org Return-Path: To: Paul Jackson Cc: Andi Kleen , akpm@osdl.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org List-ID: On Sat, 5 Nov 2005, Paul Jackson wrote: > > The comment in mm/mempolicy.c for alloc_page_vma() states: > > Should be called with the mm_sem of the vma hold. > > However it seems that the call chain (#ifdef CONFIG_NUMA): > > shmem_getpage ==> shmem_alloc_page ==> alloc_page_vma > > where shmem_getpage() is called from many of the mm/shmem.c file > operations, is called without holding mmap_sem. There is no > mention of mmap_sem in the entire mm/shmem.c file. It's safe but horrid. Look closer and you'll find there isn't even an mm to hold the mmap_sem of. The struct vm_area_struct is on the stack of shmem_alloc_page, and exists solely to apply mempolicy to a shmem file via an interface designed for mempolicy on vmas. So far as I know, it works fine; but that interface really ought to be redesigned some time - it looks like a quick hack that stuck. Hugh -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org