From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+w=401wt.eu-S1753430AbWLRHRQ@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1753430AbWLRHRQ (ORCPT <rfc822;w@1wt.eu>);
	Mon, 18 Dec 2006 02:17:16 -0500
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1753428AbWLRHRQ
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Mon, 18 Dec 2006 02:17:16 -0500
Received: from smtp.osdl.org ([65.172.181.25]:39246 "EHLO smtp.osdl.org"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S1753430AbWLRHRP (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Mon, 18 Dec 2006 02:17:15 -0500
Date: Sun, 17 Dec 2006 23:17:03 -0800
From: Andrew Morton <akpm@osdl.org>
To: Linus Torvalds <torvalds@osdl.org>, Nick Piggin <nickpiggin@yahoo.com.au>,
       andrei.popa@i-neo.ro,
       Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
       Peter Zijlstra <a.p.zijlstra@chello.nl>,
       Hugh Dickins <hugh@veritas.com>, Florian Weimer <fw@deneb.enyo.de>,
       Marc Haber <mh+linux-kernel@zugschlus.de>,
       Martin Michlmayr <tbm@cyrius.com>
Subject: Re: 2.6.19 file content corruption on ext3
Message-Id: <20061217231703.8e3e26ec.akpm@osdl.org>
In-Reply-To: <20061217231617.0726b97f.akpm@osdl.org>
References: <1166314399.7018.6.camel@localhost>
	<20061217040620.91dac272.akpm@osdl.org>
	<1166362772.8593.2.camel@localhost>
	<20061217154026.219b294f.akpm@osdl.org>
	<Pine.LNX.4.64.0612171716510.3479@woody.osdl.org>
	<Pine.LNX.4.64.0612171725110.3479@woody.osdl.org>
	<Pine.LNX.4.64.0612171744360.3479@woody.osdl.org>
	<45861E68.3060403@yahoo.com.au>
	<Pine.LNX.4.64.0612172145250.3479@woody.osdl.org>
	<20061217231617.0726b97f.akpm@osdl.org>
X-Mailer: Sylpheed version 2.2.7 (GTK+ 2.8.17; x86_64-unknown-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

On Sun, 17 Dec 2006 23:16:17 -0800
Andrew Morton <akpm@osdl.org> wrote:

> >  out:
> >  	if (buffers_to_free) {
> >  		struct buffer_head *bh = buffers_to_free;
> 
> This will (at least) cause truncate to do peculiar things. 
> do_invalidatepage() runs discard_buffer() against the dirty page and will
> then expect try_to_free_buffers() to remove those buffers and then clean
> the page.  truncate_complete_page() will clean the page, but it still has
> those invalidated buffers.  We'll end up with a large number of clean,
> unused pages on the LRU, with attached buffers.  These should eventually
> get reaped, but it'll change the page aging dynamics.

That being said, it's be great to get this tested by someone who can
trigger this bug, please.