[Date Prev][Date Next] [Thread Prev][Thread Next]
[Thread Index]
[Date Index]
[Author Index]
Re: [dm-devel] 2.6.3-udm3
- From: Christophe Saout <christophe saout de>
- To: dm-devel redhat com
- Subject: Re: [dm-devel] 2.6.3-udm3
- Date: Wed Feb 18 11:49:02 2004
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...
[Date Prev][Date Next] [Thread Prev][Thread Next]
[Thread Index]
[Date Index]
[Author Index]