[dm-devel] clone_endio question (kernel 2.5/2.6)
Kevin Corry
kevincorry at sbcglobal.net
Fri Jul 25 09:56:01 UTC 2003
On Thursday 24 July 2003 18:49, Christophe Saout wrote:
> Am Fr, 2003-07-25 um 01.40 schrieb Christophe Saout:
> > Is it possible that someone calls bio_endio with done < bi_size and an
> > error set? If it is so, the error is ignored by clone_endio.
> >
> > "if (bio->bi_size) return 1;" gets executed before the error parameter
> > gets checked.
> >
> > When clone_endio is executed, say, two times and the first time it get's
> > called with an error and the second time without, device-mapper calls
> > bio_endio on the original bio without noticing the error.
>
> I just checked: The raid1 code checks the BIO_UPTODATE flag in the bio
> and returns an error if it got cleared. It can get cleared by bio_endio
> when an error is passed.
The "if (bio->bi_size) return 1;" is the accepted convention for drivers that
don't care about partial bio completions (MD and DM certainly don't care).
IIRC, the original assumption is that if a driver sets an error when it
completes one part of a bio, it will set an error on completions of the
remaining parts. Now, if that assumption is no longer valid, then there could
be a problem. But...if you look at raid1.c and multipath.c, they have this
same check and return, so DM won't be the only thing that's broken.
As for the error that DM will return to the original submitter, if the above
assumption is correct, the code in dec_pending() should handle returning the
correct error code.
About the only thing that *could* be done differently would be: instead of
calling
dec_pending(io, error)
call
dec_pending(io, test_bit(BIO_UPTODATE, &bio->bi_flags) ? 0 : -EIO)
If the above assumption is incorrect, it looks like this change should fix it.
-Kevin Corry
More information about the dm-devel
mailing list