All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@zip.com.au>
To: Marcelo Tosatti <marcelo@conectiva.com.br>
Cc: lkml <linux-kernel@vger.kernel.org>, Andrea Arcangeli <andrea@suse.de>
Subject: [patch] disable READA
Date: Tue, 30 Jul 2002 14:25:18 -0700	[thread overview]
Message-ID: <3D47043E.413E9803@zip.com.au> (raw)


There's a bug in bread() which can cause it to misinterpret a
failed READA request as an IO error on SMP.

If a filesytem block is subject to READA and __make_request()
decides that the request would block then __make_request()
will (via end_buffer_io_sync) mark the buffer as not uptodate
and will unlock it.

But if another CPU attempts to bread() the same buffer at the same
time, the following happens:

1: ll_rw_block() sees the buffer is locked and does nothing at all

2: bread() does a wait_on_buffer()

3: the other CPU (the one doing READA) unlocks the non uptodate buffer

4: bread() sees the buffer come unlocked.  It's not uptodate, so
   bread() bogusly reports an IO error.

I haven't seen it in the wild, because it is rare to get that 
much read I/O in flight.  reiserfs and ext3 (at least) use READA.

An appropriate fix for 2.4 is to disable READA.


 ll_rw_blk.c |    2 ++
 1 files changed, 2 insertions

--- 2.4.19-rc3/drivers/block/ll_rw_blk.c~no-readahead	Tue Jul 30 14:18:17 2002
+++ 2.4.19-rc3-akpm/drivers/block/ll_rw_blk.c	Tue Jul 30 14:19:52 2002
@@ -841,7 +841,9 @@ static int __make_request(request_queue_
 	rw_ahead = 0;	/* normal case; gets changed below for READA */
 	switch (rw) {
 		case READA:
+#if 0	/* bread() misinterprets failed READA attempts as IO errors on SMP */
 			rw_ahead = 1;
+#endif
 			rw = READ;	/* drop into READ */
 		case READ:
 		case WRITE:

.

             reply	other threads:[~2002-07-30 21:24 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-07-30 21:25 Andrew Morton [this message]
2002-07-30 20:40 ` [patch] disable READA Marcelo Tosatti
2002-07-30 20:44   ` Marcelo Tosatti
2002-07-30 21:43 ` Jeff Garzik

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=3D47043E.413E9803@zip.com.au \
    --to=akpm@zip.com.au \
    --cc=andrea@suse.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=marcelo@conectiva.com.br \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.