From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nick Piggin Subject: Re: Announce: new-aops-1 for 2.6.21-rc3 Date: Mon, 2 Apr 2007 04:14:54 +0200 Message-ID: <20070402021454.GA5444@wotan.suse.de> References: <20070315161704.GH8321@wotan.suse.de> <20070315234713.GH21942@ca-server1.us.oracle.com> <20070401054218.GA6896@wotan.suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Linux Filesystems , Steven Whitehouse To: Mark Fasheh Return-path: Received: from mail.suse.de ([195.135.220.2]:50336 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752022AbXDBCO7 (ORCPT ); Sun, 1 Apr 2007 22:14:59 -0400 Content-Disposition: inline In-Reply-To: <20070401054218.GA6896@wotan.suse.de> Sender: linux-fsdevel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org Hmm, spotted another bug in here too, which also affects mainline AFAIKS. If the page is already uptodate, then a new buffer will get marked uptodate but will remain "new"... thus if the read portion of the RMW operation fails, then the error handler will zero this guy out "to prevent stale data exposure". Of course, the data is not stale because it is uptodate, so zeroing out will cause data loss. I fixed it thusly, because I think buffer_new should always be cleared before marking a buffer uptodate. I don't know whether I'll bother submitting this seperately from the new-aops lineup, but if anyone would like to, feel free to add my SOB. -- Index: linux-2.6/fs/buffer.c =================================================================== --- linux-2.6.orig/fs/buffer.c +++ linux-2.6/fs/buffer.c @@ -1813,7 +1813,9 @@ static int __block_prepare_write(struct unmap_underlying_metadata(bh->b_bdev, bh->b_blocknr); if (PageUptodate(page)) { + clear_buffer_new(bh); set_buffer_uptodate(bh); + mark_buffer_dirty(bh); continue; } if (block_end > to || block_start < from) {