Re: [dm-devel] 2.6.3-udm3

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Am Mi, den 18.02.2004 schrieb Joe Thornber um 17:34:

> This is a refactor of udm2 by way of preparation for submission.  I'm
> proposing to submit patches 2-7 this week, unless somebody yells.

I'm just looking at patch 2:

> +	/* Save the bio info so we can restore it during endio. */
> +	tio->bi_sector = clone->bi_sector;
> +	tio->bi_bdev = clone->bi_bdev;
> +	tio->bi_size = clone->bi_size;
> +	tio->bi_idx = clone->bi_idx;

[...]

> +	/* Restore bio fields. */
> +	bio->bi_sector = tio->bi_sector;
> +	bio->bi_bdev = tio->bi_bdev;
> +	bio->bi_size = tio->bi_size;
> +	bio->bi_idx = tio->bi_idx;

Are you aware that the bvec array (bv_offset and bv_len) can also
be modified by the device driver if it decides to partially complete
a bvec?

If you don't believe me, look at drivers/block/ll_rw_blk.c
__end_that_request_first, the last if:

>   /*
>    * if the request wasn't completed, update state
>    */
>   if (bio_nbytes) {
>      bio_endio(bio, bio_nbytes, error);
>      bio->bi_idx += next_idx;
>      bio_iovec(bio)->bv_offset += nr_bytes;
>      bio_iovec(bio)->bv_len -= nr_bytes;
>   }

I don't think IDE or SCSI drivers are doing this but some
exotic ones might.

Perhaps the bvec array should be restored using informations
found in the original bio...




[Index of Archives]     [DM Crypt]     [Fedora Desktop]     [ATA RAID]     [Fedora Marketing]     [Fedora Packaging]     [Fedora SELinux]     [Yosemite Discussion]     [KDE Users]     [Fedora Docs]

  Powered by Linux