Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754626AbZFXJRp (ORCPT ); Wed, 24 Jun 2009 05:17:45 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1752320AbZFXJRg (ORCPT ); Wed, 24 Jun 2009 05:17:36 -0400 Received: from mail7.hitachi.co.jp ([133.145.228.42]:59883 "EHLO mail7.hitachi.co.jp" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751818AbZFXJRd (ORCPT ); Wed, 24 Jun 2009 05:17:33 -0400 X-AuditID: b753bd60-aaefdba00000617e-00-4a41ef2c63eb Message-ID: <4A41EF15.2060507@hitachi.com> Date: Wed, 24 Jun 2009 18:17:09 +0900 From: Hidehiro Kawai User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja-JP; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja MIME-Version: 1.0 To: Andi Kleen Cc: Wu Fengguang , Andrew Morton , LKML , hugh.dickins@tiscali.co.uk, npiggin@suse.de, chris.mason@oracle.com, Rik van Riel , Andi Kleen , Ingo Molnar , Minchan Kim , Mel Gorman , Thomas Gleixner , "H. Peter Anvin" , Peter Zijlstra , "linux-mm@kvack.org" , Satoshi OSHIMA Subject: Re: [PATCH 11/15] HWPOISON: The high level memory error handler in the VM v8 References: <20090620031608.624240019@intel.com> <20090620031626.106150781@intel.com> <20090621085721.GD8218@one.firstfloor.org> In-Reply-To: <20090621085721.GD8218@one.firstfloor.org> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== X-FMFTCR: RANGEA Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1353 Lines: 35 Andi Kleen wrote: >>introduce invalidate_inode_page() and don't remove dirty/writeback pages >>from page cache (Nick, Fengguang) > > I'm still dubious this is a good idea, it means potentially a lot > of pages not covered. I think this is not bad idea for now. Certainly we become unable to recover from uncorrected memory error on dirty page cache pages, it will be safer than the old patch. As for ext3 filesystem, unlike usual I/O error, the I/O error generated by HWPOISON feature doesn't cause journal abort and read-only remount even if the fs has been mounted with data=ordered and data_err=abort options. So we can re-read the old data and update the fs after failing to write out dirty data, this may cause an integrity problem. And improper data can be exposed by the re-read if it's a newly allocated data block. The amount of dirty pages are not so many because it is limited by dirty_ratio or dirty_bytes. HWPOISON feature is still useful even if it doesn't cover dirty page cache pages. :-) Regards, -- Hidehiro Kawai Hitachi, Systems Development Laboratory Linux Technology Center -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/