Re: Maximum_transfer_size and SCSI request buffer size parameters

Jens Axboe
2003-07-24T15:27:10Z

On Thu, Jul 24 2003, Alan Stern wrote:
> I'm trying to solve the problem of a user whose USB disk drive crashes
> when it is asked to write 512K bytes in a single command. A good way to
> solve this problem would be to have a maximum_transfer_size field as part
> of the scsi_device structure. Is it worthwhile adding such a feature?

First of all, you don't mention what kernel version you are talking
about...

Anyways, the feature is already there. It's called max_sectors, and it's
even in the host template for you to set. That handles block layer
requests, at least.

> In sd.c and sr.c, scmd->request_bufflen is the number of bytes to
> transfer. Both files use the variable this_count to compute the number
> of sectors, stored in the command's CDB. this_count is based on
> request_bufflen, but the values can disagree. For example, if READ(6)
> is used and request_bufflen corresponds to more than 255 sectors,
> this_count will be reduced to 255.

That is in purpose, for cases like that you have to only do a part of
the entire request.

> Furthermore, sr.c goes to the trouble of adding up the lengths of all the
> scatter-gather blocks, and if the total disagrees with request_bufflen it
> sets request_bufflen equal to the total -- but it does this after storing
> this_count in the CDB.

It's a bug if they differ, that's why there's a printk there. Might be a
good idea to make that a harder error, though.

> A related issue is that in both sd.c and sr.c, the rw_intr() routine
> identifies the number of sectors correctly transferred as scmd->bufflen
> (if no error occurred). Normally bufflen is initialized equal to
> request_bufflen. But if this_count has been altered, the number of
> sectors will be different from bufflen.

The device will not transfer more data than what it is told from the
cdb. Aren't you getting a completed byte count from your hardware? Or
are you blindly assuming the device transferred what you initially told
you?

> If nobody objects, I will work on a patch to fix these problems.

Well..

--
Jens Axboe