From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754975Ab0D1Pjt (ORCPT ); Wed, 28 Apr 2010 11:39:49 -0400 Received: from mx1.redhat.com ([209.132.183.28]:12869 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752259Ab0D1Pjr (ORCPT ); Wed, 28 Apr 2010 11:39:47 -0400 Date: Wed, 28 Apr 2010 17:39:12 +0200 From: Andrea Arcangeli To: Mel Gorman Cc: Linux-MM , LKML , Minchan Kim , KAMEZAWA Hiroyuki , Christoph Lameter , Rik van Riel , Andrew Morton Subject: Re: [PATCH 2/3] mm,migration: Prevent rmap_walk_[anon|ksm] seeing the wrong VMA information Message-ID: <20100428153912.GS510@random.random> References: <1272403852-10479-1-git-send-email-mel@csn.ul.ie> <1272403852-10479-3-git-send-email-mel@csn.ul.ie> <20100427231007.GA510@random.random> <20100428091555.GB15815@csn.ul.ie> <20100428153525.GR510@random.random> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100428153525.GR510@random.random> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Another way (not sure if it's good or bad, but it'd clearly avoid the restarting locks in rmap_walk) would be to allocate a shared lock, and still share the lock like the anon_vma was shared before. So we have shorter chains to walk, but still a larger lock, so we've to take just one and be safe. spin_lock(&vma->anon_vma->shared_anon_vma_lock->lock) something like that...