From: Jens Axboe <jens.axboe@oracle.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>,
Giacomo Catenazzi <cate@cateee.net>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
akpm@linux-foundation.org
Subject: Re: regression: disk error loop (panic?) ide_do_rw_disk-bad:
Date: Thu, 19 Jul 2007 08:13:01 +0200 [thread overview]
Message-ID: <20070719061300.GP11657@kernel.dk> (raw)
In-Reply-To: <alpine.LFD.0.999.0707181618340.27353@woody.linux-foundation.org>
On Wed, Jul 18 2007, Linus Torvalds wrote:
>
>
> On Thu, 19 Jul 2007, Bartlomiej Zolnierkiewicz wrote:
> >
> > Thanks for finding and fixing this.
> >
> > The latest patch (with additional cleanups) also looks good and should be
> > safe enough (unchanged behavior for all non-pc requests) to merge it now.
> >
> > Acked-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
>
> Ok, Jens - mind signing off on the patch you sent out, and writing an
> explanatory message? Feel free to just crib from my explanation of my
> original patch, or whatever.
Sure thing, it's below.
> And it would be beautiful if people who saw the bad behaviour before
> reverting the ide.c changes were to go back to that broken state, and
> try the patch, and just verify that it acts like it should (ie you
> should see just a few error messages, and it shouldn't cause the IDE
> layer to go ballistic any more).
---
[PATCH] IDE: fix termination of non-fs requests
ide-disk calls
ide_end_request(drive, 0, 0);
to finish an unknown request, but this doesn't work so well for non-fs
requests, since ide_end_request() internally looks at ->hard_cur_sectors
to see how much data to end. Only file system requests store a transfer
value in there, pc requests fill out ->data_len as a byte based transfer
value instead.
Since we ask to end 0 bytes of that request, it will never be terminated
and ide-disk gets stuck in a loop "handling" that same request over and
over.
Switch __ide_end_request() to take a byte based transfer count, and
adjust ide_end_request() to look at the right field to determine how
much IO to end when it's being passed in 0.
Acked-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Signed-off-by: Jens Axboe <jens.axboe@oracle.com>
diff --git a/drivers/ide/ide-io.c b/drivers/ide/ide-io.c
index c5b5011..f9de798 100644
--- a/drivers/ide/ide-io.c
+++ b/drivers/ide/ide-io.c
@@ -55,7 +55,7 @@
#include <asm/bitops.h>
static int __ide_end_request(ide_drive_t *drive, struct request *rq,
- int uptodate, int nr_sectors)
+ int uptodate, unsigned int nr_bytes)
{
int ret = 1;
@@ -64,7 +64,7 @@ static int __ide_end_request(ide_drive_t *drive, struct request *rq,
* complete the whole request right now
*/
if (blk_noretry_request(rq) && end_io_error(uptodate))
- nr_sectors = rq->hard_nr_sectors;
+ nr_bytes = rq->hard_nr_sectors << 9;
if (!blk_fs_request(rq) && end_io_error(uptodate) && !rq->errors)
rq->errors = -EIO;
@@ -78,7 +78,7 @@ static int __ide_end_request(ide_drive_t *drive, struct request *rq,
HWGROUP(drive)->hwif->ide_dma_on(drive);
}
- if (!end_that_request_first(rq, uptodate, nr_sectors)) {
+ if (!end_that_request_chunk(rq, uptodate, nr_bytes)) {
add_disk_randomness(rq->rq_disk);
if (!list_empty(&rq->queuelist))
blkdev_dequeue_request(rq);
@@ -103,6 +103,7 @@ static int __ide_end_request(ide_drive_t *drive, struct request *rq,
int ide_end_request (ide_drive_t *drive, int uptodate, int nr_sectors)
{
+ unsigned int nr_bytes = nr_sectors << 9;
struct request *rq;
unsigned long flags;
int ret = 1;
@@ -114,10 +115,14 @@ int ide_end_request (ide_drive_t *drive, int uptodate, int nr_sectors)
spin_lock_irqsave(&ide_lock, flags);
rq = HWGROUP(drive)->rq;
- if (!nr_sectors)
- nr_sectors = rq->hard_cur_sectors;
+ if (!nr_bytes) {
+ if (blk_pc_request(rq))
+ nr_bytes = rq->data_len;
+ else
+ nr_bytes = rq->hard_cur_sectors << 9;
+ }
- ret = __ide_end_request(drive, rq, uptodate, nr_sectors);
+ ret = __ide_end_request(drive, rq, uptodate, nr_bytes);
spin_unlock_irqrestore(&ide_lock, flags);
return ret;
--
Jens Axboe
next prev parent reply other threads:[~2007-07-19 6:13 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-07-17 19:49 regression: disk error loop (panic?) ide_do_rw_disk-bad: Giacomo Catenazzi
2007-07-17 20:47 ` Michal Piotrowski
2007-07-17 21:20 ` Bartlomiej Zolnierkiewicz
2007-07-17 21:24 ` Linus Torvalds
2007-07-17 22:45 ` Bartlomiej Zolnierkiewicz
2007-07-17 22:38 ` Linus Torvalds
2007-07-17 23:14 ` Bartlomiej Zolnierkiewicz
2007-07-17 23:18 ` Jeff Garzik
2007-07-18 8:09 ` Jens Axboe
2007-07-17 22:57 ` Linus Torvalds
2007-07-18 6:31 ` Giacomo Catenazzi
2007-07-18 19:57 ` Linus Torvalds
2007-07-18 20:08 ` Jens Axboe
2007-07-18 20:11 ` Jens Axboe
2007-07-18 20:14 ` Linus Torvalds
2007-07-18 20:27 ` Jens Axboe
2007-07-18 22:53 ` Bartlomiej Zolnierkiewicz
2007-07-18 23:20 ` Linus Torvalds
2007-07-19 6:13 ` Jens Axboe [this message]
2007-07-19 6:40 ` Giacomo Catenazzi
2007-07-19 6:47 ` Jens Axboe
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=20070719061300.GP11657@kernel.dk \
--to=jens.axboe@oracle.com \
--cc=akpm@linux-foundation.org \
--cc=bzolnier@gmail.com \
--cc=cate@cateee.net \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@linux-foundation.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 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.