public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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


  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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox