From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail172.messagelabs.com (mail172.messagelabs.com [216.82.254.3]) by kanga.kvack.org (Postfix) with SMTP id 951736B0047 for ; Mon, 1 Feb 2010 12:04:18 -0500 (EST) Message-ID: <4B670968.7090801@redhat.com> Date: Mon, 01 Feb 2010 12:03:36 -0500 From: Rik van Riel MIME-Version: 1.0 Subject: Re: [PATCH 32 of 32] khugepaged References: <51b543fab38b1290f176.1264969663@v2.random> In-Reply-To: <51b543fab38b1290f176.1264969663@v2.random> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org To: Andrea Arcangeli Cc: linux-mm@kvack.org, Marcelo Tosatti , Adam Litke , Avi Kivity , Izik Eidus , Hugh Dickins , Nick Piggin , Mel Gorman , Dave Hansen , Benjamin Herrenschmidt , Ingo Molnar , Mike Travis , KAMEZAWA Hiroyuki , Christoph Lameter , Chris Wright , Andrew Morton , bpicco@redhat.com, KOSAKI Motohiro , Balbir Singh , Arnd Bergmann List-ID: On 01/31/2010 03:27 PM, Andrea Arcangeli wrote: > + /* stop anon_vma rmap pagetable access */ > + spin_lock(&vma->anon_vma->lock); This is no longer enough. The anon_vma changes that went into -mm recently mean that a VMA can be associated with multiple anon_vmas. Of course, forcefully COW copying/writing every page in the VMA will ensure that they are all in the anon_vma you lock with the code above. I suspect the easiest fix would be to lock all the anon_vmas attached to a VMA. That should not lead to any deadlocks, since multiple siblings of the same parent process would be encountering their anon_vma structs in the same order, due to the way that anon_vma_clone and anon_vma_fork work. This may be too subtle for lockdep, 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