Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754905AbZFOKgb (ORCPT ); Mon, 15 Jun 2009 06:36:31 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1753108AbZFOKgV (ORCPT ); Mon, 15 Jun 2009 06:36:21 -0400 Received: from cantor2.suse.de ([195.135.220.15]:33214 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750930AbZFOKgU (ORCPT ); Mon, 15 Jun 2009 06:36:20 -0400 Date: Mon, 15 Jun 2009 12:36:19 +0200 From: Nick Piggin To: Wu Fengguang Cc: Balbir Singh , Andrew Morton , LKML , Ingo Molnar , Mel Gorman , Thomas Gleixner , "H. Peter Anvin" , Peter Zijlstra , Hugh Dickins , Andi Kleen , "riel@redhat.com" , "chris.mason@oracle.com" , "linux-mm@kvack.org" , "linux-fsdevel@vger.kernel.org" Subject: Re: [PATCH 00/22] HWPOISON: Intro (v5) Message-ID: <20090615103619.GC20461@wotan.suse.de> References: <20090615024520.786814520@intel.com> <4A35BD7A.9070208@linux.vnet.ibm.com> <20090615042753.GA20788@localhost> <20090615064447.GA18390@wotan.suse.de> <20090615081453.GC8665@wotan.suse.de> <20090615100954.GA7099@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090615100954.GA7099@localhost> User-Agent: Mutt/1.5.9i Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2002 Lines: 48 On Mon, Jun 15, 2009 at 06:09:54PM +0800, Wu Fengguang wrote: > On Mon, Jun 15, 2009 at 04:14:53PM +0800, Nick Piggin wrote: > > On Mon, Jun 15, 2009 at 08:44:47AM +0200, Nick Piggin wrote: > > > Did we verify with filesystem maintainers (eg. btrfs) that the > > > !ISREG test will be enough to prevent oopses? > > > > BTW. this is quite a significant change I think and not > > really documented well enough. Previously a filesystem > > will know exactly when and why pagecache in a mapping > > under its control will be truncated (as opposed to > > invalidated). > > > > They even have opportunity to hold locks such as i_mutex. > > > > And depending on what they do, they could do interesting > > things even with ISREG files. > > > > So, I really think this needs review by filesystem > > maintainers and it would be far safer to use invalidate > > until it is known to be safe. > > Nick, we are doing invalidate_complete_page() for !S_ISREG inodes now. > Do you mean to do invalidate_complete_page() for all inodes for now? That would make me a lot happier. It is obviously correct because that is basically what page reclaim and inode reclaim and drop caches etc does. Note that I still don't like exporting invalidate_complete_page fro the same reasons I don't like exporting truncate_complete_page, so I will ask if you can do an invalidate_inode_page function along the same lines of the truncate_inode_page one please. > That's a good suggestion, it shall be able to do the job for most > pages indeed. Yes I think it will be far far safer while only introducing another small class of pages which cannot be recovered (probably a much smaller set most of the time than the size of the existing set of pages which cannot be recovered). -- 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/