* [bug] infinite loop in generic_make_request()
@ 2000-11-30 7:02 V Ganesh
2000-11-30 9:24 ` [PATCH] " Neil Brown
0 siblings, 1 reply; 6+ messages in thread
From: V Ganesh @ 2000-11-30 7:02 UTC (permalink / raw)
To: linux-kernel; +Cc: linux-LVM, mingo
[cc'ed to maintainers of md and lvm]
hi,
in generic_make_request(), the following code handles stacking:
do {
q = blk_get_queue(bh->b_rdev);
if (!q) {
printk(...)
buffer_IO_error(bh);
break;
}
} while (q->make_request_fn(q, rw, bh));
however, make_request_fn may return -1 in case of errors. one such fn is
raid0_make_request(). this causes generic_make_request() to loop endlessly.
lvm returns 1 unconditionally, so it would also loop if an error occured in
lvm_map(). other bdevs might have the same problem.
I think a better mechanism would be to mandate that make_request_fn ought
to call bh->b_end_io() in case of errors and return 0.
ganesh
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [flat|nested] 6+ messages in thread* [PATCH] Re: [bug] infinite loop in generic_make_request() 2000-11-30 7:02 [bug] infinite loop in generic_make_request() V Ganesh @ 2000-11-30 9:24 ` Neil Brown 2000-11-30 20:05 ` Andreas Dilger 0 siblings, 1 reply; 6+ messages in thread From: Neil Brown @ 2000-11-30 9:24 UTC (permalink / raw) To: Linus Torvalds, V Ganesh; +Cc: linux-kernel, linux-LVM, mingo On Thursday November 30, ganesh@veritas.com wrote: > [cc'ed to maintainers of md and lvm] > > hi, > in generic_make_request(), the following code handles stacking: > > do { > q = blk_get_queue(bh->b_rdev); > if (!q) { > printk(...) > buffer_IO_error(bh); > break; > } > } while (q->make_request_fn(q, rw, bh)); > > however, make_request_fn may return -1 in case of errors. one such fn is > raid0_make_request(). this causes generic_make_request() to loop endlessly. > lvm returns 1 unconditionally, so it would also loop if an error occured in > lvm_map(). other bdevs might have the same problem. > I think a better mechanism would be to mandate that make_request_fn ought > to call bh->b_end_io() in case of errors and return 0. > > ganesh Good catch, thanks. Below is a patch to fix md drivers (md.c, linear.c and raid0.c). NeilBrown --- ./drivers/md/md.c 2000/11/30 08:23:51 1.2 +++ ./drivers/md/md.c 2000/11/30 09:20:05 1.3 @@ -179,7 +179,7 @@ return mddev->pers->make_request(mddev, rw, bh); else { buffer_IO_error(bh); - return -1; + return 0; } } --- ./drivers/md/linear.c 2000/11/30 08:23:51 1.2 +++ ./drivers/md/linear.c 2000/11/30 09:20:05 1.3 @@ -136,7 +136,8 @@ if (!hash->dev1) { printk ("linear_make_request : hash->dev1==NULL for block %ld\n", block); - return -1; + buffer_IO_error(bh); + return 0; } tmp_dev = hash->dev1; } else @@ -145,7 +146,8 @@ if (block >= (tmp_dev->size + tmp_dev->offset) || block < tmp_dev->offset) { printk ("linear_make_request: Block %ld out of bounds on dev %s size %ld offset %ld\n", block, kdevname(tmp_dev->dev), tmp_dev->size, tmp_dev->offset); - return -1; + buffer_IO_error(bh); + return 0; } bh->b_rdev = tmp_dev->dev; bh->b_rsector = bh->b_rsector - (tmp_dev->offset << 1); --- ./drivers/md/raid0.c 2000/11/30 08:23:51 1.2 +++ ./drivers/md/raid0.c 2000/11/30 09:20:05 1.3 @@ -275,16 +275,18 @@ bad_map: printk ("raid0_make_request bug: can't convert block across chunks or bigger than %dk %ld %d\n", chunk_size, bh->b_rsector, bh->b_size >> 10); - return -1; + goto outerr; bad_hash: printk("raid0_make_request bug: hash==NULL for block %ld\n", block); - return -1; + goto outerr; bad_zone0: printk ("raid0_make_request bug: hash->zone0==NULL for block %ld\n", block); - return -1; + goto outerr; bad_zone1: printk ("raid0_make_request bug: hash->zone1==NULL for block %ld\n", block); - return -1; + outerr: + buffer_IO_error(bh); + return 0; } static int raid0_status (char *page, mddev_t *mddev) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/ ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] Re: [bug] infinite loop in generic_make_request() 2000-11-30 9:24 ` [PATCH] " Neil Brown @ 2000-11-30 20:05 ` Andreas Dilger 2000-11-30 20:41 ` Andrea Arcangeli 0 siblings, 1 reply; 6+ messages in thread From: Andreas Dilger @ 2000-11-30 20:05 UTC (permalink / raw) To: Neil Brown; +Cc: Linus Torvalds, V Ganesh, linux-kernel, linux-LVM, mingo Neil Brown write: > On Thursday November 30, ganesh@veritas.com wrote: > > in generic_make_request(), the following code handles stacking: > > > > do { > > q = blk_get_queue(bh->b_rdev); > > if (!q) { > > printk(...) > > buffer_IO_error(bh); > > break; > > } > > } while (q->make_request_fn(q, rw, bh)); > > > > however, make_request_fn may return -1 in case of errors. one such fn is > > raid0_make_request(). this causes generic_make_request() to loop endlessly. > > lvm returns 1 unconditionally, so it would also loop if an error occured in > > lvm_map(). other bdevs might have the same problem. > > I think a better mechanism would be to mandate that make_request_fn ought > > to call bh->b_end_io() in case of errors and return 0. > > Good catch, thanks. Below is a patch to fix md drivers (md.c, > linear.c and raid0.c). > > NeilBrown You need to also patch the lvm.c driver at the same time... However, this change now makes it very counter-intuitive compared to other kernel functions. Normally, we return 0 on success, and -ve on error. Maybe the RAID and LVM make_request functions should be changed to do that instead (i.e. 0 on success, -ve on error, and maybe "1" if they do their own recursion to break the loop)? Cheers, Andreas PS - I fixed the LVM mailing list address... -- Andreas Dilger \ "If a man ate a pound of pasta and a pound of antipasto, \ would they cancel out, leaving him still hungry?" http://www-mddsp.enel.ucalgary.ca/People/adilger/ -- Dogbert - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/ ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] Re: [bug] infinite loop in generic_make_request() 2000-11-30 20:05 ` Andreas Dilger @ 2000-11-30 20:41 ` Andrea Arcangeli 2000-11-30 21:54 ` Andreas Dilger 0 siblings, 1 reply; 6+ messages in thread From: Andrea Arcangeli @ 2000-11-30 20:41 UTC (permalink / raw) To: Andreas Dilger Cc: Neil Brown, Linus Torvalds, V Ganesh, linux-kernel, linux-LVM, mingo On Thu, Nov 30, 2000 at 01:05:53PM -0700, Andreas Dilger wrote: > the RAID and LVM make_request functions should be changed to do that > instead (i.e. 0 on success, -ve on error, and maybe "1" if they do their > own recursion to break the loop)? We preferred to let the lowlevel drivers to handle error themselfs to simplify the interface. The lowlevel driver needs to call buffer_IO_error before returning in case of error. Andrea - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/ ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] Re: [bug] infinite loop in generic_make_request() 2000-11-30 20:41 ` Andrea Arcangeli @ 2000-11-30 21:54 ` Andreas Dilger 2000-11-30 22:17 ` Andrea Arcangeli 0 siblings, 1 reply; 6+ messages in thread From: Andreas Dilger @ 2000-11-30 21:54 UTC (permalink / raw) To: Andrea Arcangeli Cc: Andreas Dilger, Neil Brown, Linus Torvalds, V Ganesh, linux-kernel, linux-LVM, mingo Andrea writes: > On Thu, Nov 30, 2000 at 01:05:53PM -0700, Andreas Dilger wrote: > > the RAID and LVM make_request functions should be changed to do that > > instead (i.e. 0 on success, -ve on error, and maybe "1" if they do their > > own recursion to break the loop)? > > We preferred to let the lowlevel drivers to handle error themselfs to > simplify the interface. The lowlevel driver needs to call buffer_IO_error > before returning in case of error. Even if the lowlevel driver handles the error case, it would still make more sense to stick with the normal kernel practise of -ERROR, and 0 for success. Then, if in the future we can do something with the error codes, at least we don't have to change the interface yet again. Also, it is a bit confusing, because the lvm (and md, I suppose) driver returned "0" for success in 2.2, so now you need to special-case the return value depending on kernel version, if you want to keep the same code for 2.2 and 2.4. Cheers, Andreas -- Andreas Dilger \ "If a man ate a pound of pasta and a pound of antipasto, \ would they cancel out, leaving him still hungry?" http://www-mddsp.enel.ucalgary.ca/People/adilger/ -- Dogbert - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/ ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] Re: [bug] infinite loop in generic_make_request() 2000-11-30 21:54 ` Andreas Dilger @ 2000-11-30 22:17 ` Andrea Arcangeli 0 siblings, 0 replies; 6+ messages in thread From: Andrea Arcangeli @ 2000-11-30 22:17 UTC (permalink / raw) To: Andreas Dilger Cc: Neil Brown, Linus Torvalds, V Ganesh, linux-kernel, linux-LVM, mingo On Thu, Nov 30, 2000 at 02:54:19PM -0700, Andreas Dilger wrote: > Andrea writes: > > On Thu, Nov 30, 2000 at 01:05:53PM -0700, Andreas Dilger wrote: > > > the RAID and LVM make_request functions should be changed to do that > > > instead (i.e. 0 on success, -ve on error, and maybe "1" if they do their > > > own recursion to break the loop)? > > > > We preferred to let the lowlevel drivers to handle error themselfs to > > simplify the interface. The lowlevel driver needs to call buffer_IO_error > > before returning in case of error. > > Even if the lowlevel driver handles the error case, it would still > make more sense to stick with the normal kernel practise of -ERROR, > and 0 for success. Then, if in the future we can do something with the > error codes, at least we don't have to change the interface yet again. You shouldn't see the fact that a storage management driver returns 0 as an error. It has a different semantic, it only means: "the make_request callback completed the request, it wasn't a remap". That's all. As said the highlevel layer doesn't know anything about errors anymore, it only need to know when the request is completed. Of course if there's an error during a remap you can't continue so you have to say "this request is completed" and to tell this you currently have to return 0. But 0 from the point of view of the highlevel layer doesn't mean "error". I'd suggest to take a third way that is to define only two retvals: BLKDEV_IO_REQ_COMPLETED BLKDEV_IO_REQ_REMAPPED Then it doesn't matter anymore what number they're defined to. generic_make_request simply keeps looping as far as it gets BLKDEV_IO_REQ_REMAPPED as retval. Andrea - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/ ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2000-11-30 22:48 UTC | newest] Thread overview: 6+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2000-11-30 7:02 [bug] infinite loop in generic_make_request() V Ganesh 2000-11-30 9:24 ` [PATCH] " Neil Brown 2000-11-30 20:05 ` Andreas Dilger 2000-11-30 20:41 ` Andrea Arcangeli 2000-11-30 21:54 ` Andreas Dilger 2000-11-30 22:17 ` Andrea Arcangeli
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox