mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Nick Piggin <nickpiggin@yahoo.com.au>
To: Anton Altaparmakov <aia21@cam.ac.uk>
Cc: Andrew Morton <akpm@osdl.org>,
	lkml <linux-kernel@vger.kernel.org>,
	Andrea Arcangeli <andrea@suse.de>
Subject: Re: [patch] fix race in __block_prepare_write (again)
Date: Thu, 21 Apr 2005 17:20:57 +1000	[thread overview]
Message-ID: <1114068058.5182.22.camel@npiggin-nld.site> (raw)
In-Reply-To: <1114067401.11293.3.camel@imp.csi.cam.ac.uk>

[-- Attachment #1: Type: text/plain, Size: 1414 bytes --]

On Thu, 2005-04-21 at 08:10 +0100, Anton Altaparmakov wrote:
> And one more thing...
> 
> On Thu, 2005-04-21 at 08:01 +0100, Anton Altaparmakov wrote:
> > On Thu, 21 Apr 2005, Nick Piggin wrote:
> > > ... I somehow didn't send it to Andrew last time.
> > > 
> > > Fix a race where __block_prepare_write can leak out an in-flight
> > > read against a bh if get_block returns an error. This can lead to
> > > the page becoming unlocked while the buffer is locked and the read
> > > still in flight. __mpage_writepage BUGs on this condition.
> > [snip]
> > > --- linux-2.6.orig/fs/buffer.c	2005-04-21 11:55:17.549614278 
> > +1000
> > > +++ linux-2.6/fs/buffer.c	2005-04-21 15:55:41.483826075 +1000
> > > @@ -1988,6 +1988,7 @@
> > >  			*wait_bh++=bh;
> > >  		}
> > >  	}
> > > +out:
> > >  	/*
> > >  	 * If we issued read requests - let them complete.
> > >  	 */
> > > @@ -1996,8 +1997,9 @@
> > >  		if (!buffer_uptodate(*wait_bh))
> > >  			return -EIO;
> 
> This return is now wrong after your patch.  It should be "err = -EIO;"
> otherwise you do not zero newly allocated blocks and thus risk exposing
> stale data on buffer i/o errors. 
> 

Hmm yeah I should have been more careful. But isn't that another bug? I
mean, wasn't that wrong *before* my patch as well?

It was, right? Because not only might it return without having waited
for all in-flight buffers, but it also didn't zero the blocks on errors?


[-- Attachment #2: __block_prepare_write-bug.patch --]
[-- Type: text/x-patch, Size: 1355 bytes --]

Fix a race where __block_prepare_write can leak out an in-flight
read against a bh if get_block returns an error. This can lead to
the page becoming unlocked while the buffer is locked and the read
still in flight. __mpage_writepage BUGs on this condition.

BUG sighted on a 2-way Itanium2 system with 16K PAGE_SIZE running

	fsstress -v -d $DIR/tmp -n 1000 -p 1000 -l 2
	
where $DIR is a new ext2 filesystem with 4K blocks that is quite
small (causing get_block to fail often with -ENOSPC).

Signed-off-by: Nick Piggin <nickpiggin@yahoo.com.au>

Index: linux-2.6/fs/buffer.c
===================================================================
--- linux-2.6.orig/fs/buffer.c	2005-04-21 11:55:17.549614278 +1000
+++ linux-2.6/fs/buffer.c	2005-04-21 17:20:06.149176996 +1000
@@ -1952,7 +1952,7 @@
 		if (!buffer_mapped(bh)) {
 			err = get_block(inode, block, bh, 1);
 			if (err)
-				goto out;
+				break;
 			if (buffer_new(bh)) {
 				clear_buffer_new(bh);
 				unmap_underlying_metadata(bh->b_bdev,
@@ -1994,10 +1994,12 @@
 	while(wait_bh > wait) {
 		wait_on_buffer(*--wait_bh);
 		if (!buffer_uptodate(*wait_bh))
-			return -EIO;
+			err = -EIO;
 	}
-	return 0;
-out:
+	if (!err)
+		return err;
+
+	/* Error case: */
 	/*
 	 * Zero out any newly allocated blocks to avoid exposing stale
 	 * data.  If BH_New is set, we know that the block was newly

  reply	other threads:[~2005-04-21  7:21 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-04-21  6:14 Nick Piggin
2005-04-21  7:01 ` Anton Altaparmakov
2005-04-21  7:10   ` Anton Altaparmakov
2005-04-21  7:20     ` Nick Piggin [this message]
2005-04-21  7:31       ` Anton Altaparmakov
2005-04-22 15:10         ` Nikita Danilov
2005-04-22 15:50           ` Anton Altaparmakov
2005-04-24 21:24         ` Andrew Morton
2005-04-25  7:44           ` Anton Altaparmakov
2005-04-21  7:13   ` Nick Piggin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1114068058.5182.22.camel@npiggin-nld.site \
    --to=nickpiggin@yahoo.com.au \
    --cc=aia21@cam.ac.uk \
    --cc=akpm@osdl.org \
    --cc=andrea@suse.de \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®