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:
.
next 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.