From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail137.messagelabs.com (mail137.messagelabs.com [216.82.249.19]) by kanga.kvack.org (Postfix) with SMTP id AC0396B01E3 for ; Mon, 26 Apr 2010 05:32:42 -0400 (EDT) Received: from m6.gw.fujitsu.co.jp ([10.0.50.76]) by fgwmail6.fujitsu.co.jp (Fujitsu Gateway) with ESMTP id o3Q9WeF9019765 for (envelope-from kamezawa.hiroyu@jp.fujitsu.com); Mon, 26 Apr 2010 18:32:40 +0900 Received: from smail (m6 [127.0.0.1]) by outgoing.m6.gw.fujitsu.co.jp (Postfix) with ESMTP id D8EB545DE58 for ; Mon, 26 Apr 2010 18:32:39 +0900 (JST) Received: from s6.gw.fujitsu.co.jp (s6.gw.fujitsu.co.jp [10.0.50.96]) by m6.gw.fujitsu.co.jp (Postfix) with ESMTP id B3DD145DE53 for ; Mon, 26 Apr 2010 18:32:39 +0900 (JST) Received: from s6.gw.fujitsu.co.jp (localhost.localdomain [127.0.0.1]) by s6.gw.fujitsu.co.jp (Postfix) with ESMTP id 993031DB8019 for ; Mon, 26 Apr 2010 18:32:39 +0900 (JST) Received: from ml13.s.css.fujitsu.com (ml13.s.css.fujitsu.com [10.249.87.103]) by s6.gw.fujitsu.co.jp (Postfix) with ESMTP id 10E7B1DB8014 for ; Mon, 26 Apr 2010 18:32:39 +0900 (JST) Date: Mon, 26 Apr 2010 18:28:38 +0900 From: KAMEZAWA Hiroyuki Subject: Re: [BUGFIX][mm][PATCH] fix migration race in rmap_walk Message-Id: <20100426182838.2cab9844.kamezawa.hiroyu@jp.fujitsu.com> In-Reply-To: <20100426084901.15c09a29.kamezawa.hiroyu@jp.fujitsu.com> References: <20100423120148.9ffa5881.kamezawa.hiroyu@jp.fujitsu.com> <20100423095922.GJ30306@csn.ul.ie> <20100423155801.GA14351@csn.ul.ie> <20100424110200.b491ec5f.kamezawa.hiroyu@jp.fujitsu.com> <20100424104324.GD14351@csn.ul.ie> <20100426084901.15c09a29.kamezawa.hiroyu@jp.fujitsu.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org To: KAMEZAWA Hiroyuki Cc: Mel Gorman , "linux-mm@kvack.org" , "minchan.kim@gmail.com" , Christoph Lameter , "akpm@linux-foundation.org" , "linux-kernel@vger.kernel.org" List-ID: On Mon, 26 Apr 2010 08:49:01 +0900 KAMEZAWA Hiroyuki wrote: > On Sat, 24 Apr 2010 11:43:24 +0100 > Mel Gorman wrote: > > It looks nice but it still broke after 28 hours of running. The > > seq-counter is still insufficient to catch all changes that are made to > > the list. I'm beginning to wonder if a) this really can be fully safely > > locked with the anon_vma changes and b) if it has to be a spinlock to > > catch the majority of cases but still a lazy cleanup if there happens to > > be a race. It's unsatisfactory and I'm expecting I'll either have some > > insight to the new anon_vma changes that allow it to be locked or Rik > > knows how to restore the original behaviour which as Andrea pointed out > > was safe. > > > Ouch. Ok, reproduced. Here is status in my test + printk(). * A race doesn't seem to happen if swap=off. I need to swapon to cause the bug. * Before unmap, mapcount=1, SwapCache for anonymous memory. old page's flag was SWAPCACHE, Active, Uptodate, Referenced, Locked. * After remap, mapcount=0, return code=0. new page's flag after remap was SwapCache, Active, Dirty, Uptodate, Referenced. (Hmm, dirty bit can be added by try_to_unamp().) -Kame -- 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