Mike Christie wrote:
> Mike Christie wrote:
>> Mike Christie wrote:
>>> any missing functionality. I am still testing the patch. I have not
>>> tested some of the older sg interfaces
>> I am pretty sure (100% :)), that I messed up the old interface handling.
>>
>>> -
>>> -static int
>>> -sg_write_xfer(Sg_request * srp)
>>> -{
>>> - sg_io_hdr_t *hp = &srp->header;
>>> - Sg_scatter_hold *schp = &srp->data;
>>> - struct scatterlist *sg = schp->buffer;
>>> - int num_xfer = 0;
>>> - int j, k, onum, usglen, ksglen, res;
>>> - int iovec_count = (int) hp->iovec_count;
>>> - int dxfer_dir = hp->dxfer_direction;
>>> - unsigned char *p;
>>> - unsigned char __user *up;
>>> - int new_interface = ('\0' == hp->interface_id) ? 0 : 1;
>>> -
>>> - if ((SG_DXFER_UNKNOWN == dxfer_dir) || (SG_DXFER_TO_DEV == dxfer_dir) ||
>>> - (SG_DXFER_TO_FROM_DEV == dxfer_dir)) {
>>> - num_xfer = (int) (new_interface ? hp->dxfer_len : hp->flags);
>>> - if (schp->bufflen < num_xfer)
>>> - num_xfer = schp->bufflen;
>> In sg_write_xfer here, for the old interface is it valid to have
>> hp->dxfer_len greater than hp->flags, then have sg_read_oxfer get
>> num_read_xfer that is not equal to hp->dxfer_len?
>
> Could num_read_xfer would also not be equal to hp->flags, so three
> different values?
Three different values might be a bug, but the code should not oops. I
updated the code so that could support three different sizes if it ever
comes up. It does the same checks for schp->bufflen < num_xfer to handle
some of the problems and blk_rq_copy_user takes a write_len and len
value so if hp->dxfer_len are different hp->flags we copy the right
amount of data. I already changed the uncopy equivalent to copy on what
is passed in sg_read for the old interface.
I put the updated patches here
http://people.redhat.com/mchristi/sg/v3/
they were made against Jens bsg branch.
I will resend them, once I get comments or do more major cleanups and
fixes. But they are there if you want to look at them.
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
