From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from psmtp.com (na3sys010amx141.postini.com [74.125.245.141]) by kanga.kvack.org (Postfix) with SMTP id 611716B0032 for ; Mon, 15 Jul 2013 21:51:34 -0400 (EDT) Message-ID: <51E4A719.4020703@redhat.com> Date: Mon, 15 Jul 2013 21:51:21 -0400 From: Rik van Riel MIME-Version: 1.0 Subject: Re: [PATCH] mm/hugetlb: per-vma instantiation mutexes References: <1373671681.2448.10.camel@buesod1.americas.hpqcorp.net> <1373858204.13826.9.camel@buesod1.americas.hpqcorp.net> <20130715072432.GA28053@voom.fritz.box> In-Reply-To: <20130715072432.GA28053@voom.fritz.box> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: David Gibson Cc: Davidlohr Bueso , Hugh Dickins , Andrew Morton , Michel Lespinasse , Mel Gorman , Konstantin Khlebnikov , Michal Hocko , "AneeshKumarK.V" , KAMEZAWA Hiroyuki , Hillf Danton , linux-mm@kvack.org, LKML On 07/15/2013 03:24 AM, David Gibson wrote: > On Sun, Jul 14, 2013 at 08:16:44PM -0700, Davidlohr Bueso wrote: >>> Reading the existing comment, this change looks very suspicious to me. >>> A per-vma mutex is just not going to provide the necessary exclusion, is >>> it? (But I recall next to nothing about these regions and >>> reservations.) > > A per-VMA lock is definitely wrong. I think it handles one form of > the race, between threads sharing a VM on a MAP_PRIVATE mapping. > However another form of the race can and does occur between different > MAP_SHARED VMAs in the same or different processes. I think there may > be edge cases involving mremap() and MAP_PRIVATE that will also be > missed by a per-VMA lock. > > Note that the libhugetlbfs testsuite contains tests for both PRIVATE > and SHARED variants of the race. Can we get away with simply using a mutex in the file? Say vma->vm_file->mapping->i_mmap_mutex? That might help with multiple processes initializing multiple shared memory segments at the same time, and should not hurt the case of a process mapping its own hugetlbfs area. It might have the potential to hurt when getting private copies on a MAP_PRIVATE area, though. I have no idea how common it is for multiple processes to MAP_PRIVATE the same hugetlbfs file, though... -- All rights reversed -- 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