linux-scsi.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* Length and alignment in scsi_execute_async and blk_rq_map_user
@ 2010-06-29 21:23 Brett Dennis
  2010-06-30 10:30 ` Boaz Harrosh
  0 siblings, 1 reply; 3+ messages in thread
From: Brett Dennis @ 2010-06-29 21:23 UTC (permalink / raw)
  To: linux-scsi

Hello,

Apologies for posting twice (messed up on the subject line of the first post...)

In kernel 2.6.26, the implementation of __blk_rq_map_user changed and
now includes a call to bio_copy_user:

uaddr = (unsigned long) ubuf;
alignment = queue_dma_alignment(q) | q->dma_pad_mask;
if (!(uaddr & alignment) && !(len & alignment))

     bio = bio_map_user(q, NULL, uaddr, len, reading);

else

     bio = bio_copy_user(q, uaddr, len, reading);


bio_copy_user uses the HBA's scatter-gather pages for the copy.  The
problem I face is that if the data is not aligned properly, or the len
parameter does not divide properly, and the transfer is greater than
the number of scatter-gather pages, the IO operation will fail.  I am
considering increasing the size of my data buffer to meet the
length-alignment requirement and changing the 'len' parameter passed
into blk_rq_map_user to include a larger size than my CDB transfer
length.  This way it will hit the bio_map_user branch instead of the
bio_copy_user branch and I won't have to worry about insufficient
sg-pages.  The tape device should still honor the CDB write length, so
unless there are other limitations imposed by the Linux kernel or SCSI
subsystem, I think this is a workable solution.  Does anyone in this
list know if there are requirements against sending a larger buffer
length than CDB transfer length?

Thanks in advance.

Brett Dennis
IBM tape device driver developer

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Length and alignment in scsi_execute_async and blk_rq_map_user
  2010-06-29 21:23 Length and alignment in scsi_execute_async and blk_rq_map_user Brett Dennis
@ 2010-06-30 10:30 ` Boaz Harrosh
  2010-06-30 10:39   ` Boaz Harrosh
  0 siblings, 1 reply; 3+ messages in thread
From: Boaz Harrosh @ 2010-06-30 10:30 UTC (permalink / raw)
  To: Brett Dennis; +Cc: linux-scsi

On 06/30/2010 12:23 AM, Brett Dennis wrote:
> Hello,
> 
> Apologies for posting twice (messed up on the subject line of the first post...)
> 
> In kernel 2.6.26, the implementation of __blk_rq_map_user changed and
> now includes a call to bio_copy_user:
> 
> uaddr = (unsigned long) ubuf;
> alignment = queue_dma_alignment(q) | q->dma_pad_mask;
> if (!(uaddr & alignment) && !(len & alignment))
> 
>      bio = bio_map_user(q, NULL, uaddr, len, reading);
> 
> else
> 
>      bio = bio_copy_user(q, uaddr, len, reading);
> 
> 
> bio_copy_user uses the HBA's scatter-gather pages for the copy.  The
> problem I face is that if the data is not aligned properly, or the len
> parameter does not divide properly, and the transfer is greater than
> the number of scatter-gather pages, the IO operation will fail.  I am
> considering increasing the size of my data buffer to meet the
> length-alignment requirement and changing the 'len' parameter passed
> into blk_rq_map_user to include a larger size than my CDB transfer
> length.  This way it will hit the bio_map_user branch instead of the
> bio_copy_user branch and I won't have to worry about insufficient
> sg-pages.  The tape device should still honor the CDB write length, so
> unless there are other limitations imposed by the Linux kernel or SCSI
> subsystem, I think this is a workable solution.  Does anyone in this
> list know if there are requirements against sending a larger buffer
> length than CDB transfer length?
> 

It depends. If you are issuing BLOCK_PC commands then you are in the clear.
If an FS_PC commands then your ULD must take proper care at completion.
What ULD are you using?

> Thanks in advance.
> 
> Brett Dennis
> IBM tape device driver developer

Boaz

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Length and alignment in scsi_execute_async and blk_rq_map_user
  2010-06-30 10:30 ` Boaz Harrosh
@ 2010-06-30 10:39   ` Boaz Harrosh
  0 siblings, 0 replies; 3+ messages in thread
From: Boaz Harrosh @ 2010-06-30 10:39 UTC (permalink / raw)
  To: Brett Dennis; +Cc: linux-scsi

On 06/30/2010 01:30 PM, Boaz Harrosh wrote:
> On 06/30/2010 12:23 AM, Brett Dennis wrote:
>> Hello,
>>
>> Apologies for posting twice (messed up on the subject line of the first post...)
>>
>> In kernel 2.6.26, the implementation of __blk_rq_map_user changed and
>> now includes a call to bio_copy_user:
>>
>> uaddr = (unsigned long) ubuf;
>> alignment = queue_dma_alignment(q) | q->dma_pad_mask;
>> if (!(uaddr & alignment) && !(len & alignment))
>>
>>      bio = bio_map_user(q, NULL, uaddr, len, reading);
>>
>> else
>>
>>      bio = bio_copy_user(q, uaddr, len, reading);
>>
>>
>> bio_copy_user uses the HBA's scatter-gather pages for the copy.  The
>> problem I face is that if the data is not aligned properly, or the len
>> parameter does not divide properly, and the transfer is greater than
>> the number of scatter-gather pages, the IO operation will fail.  I am
>> considering increasing the size of my data buffer to meet the
>> length-alignment requirement and changing the 'len' parameter passed
>> into blk_rq_map_user to include a larger size than my CDB transfer
>> length.  This way it will hit the bio_map_user branch instead of the
>> bio_copy_user branch and I won't have to worry about insufficient
>> sg-pages.  The tape device should still honor the CDB write length, so
>> unless there are other limitations imposed by the Linux kernel or SCSI
>> subsystem, I think this is a workable solution.  Does anyone in this
>> list know if there are requirements against sending a larger buffer
>> length than CDB transfer length?
>>
> 
> It depends. If you are issuing BLOCK_PC commands then you are in the clear.
> If an FS_PC commands then your ULD must take proper care at completion.
> What ULD are you using?
> 

Sorry I missed the scsi_execute_async() part in the title. So yes it is
BLOCK_PC. I think it should be fine, unless some LLD would break because
LLDs and HW do funny things. I'd try it out. If you have problems with
particular HW, perhaps keep a black-list flag. You might expect some
residual returns from some LLDs.

>> Thanks in advance.
>>
>> Brett Dennis
>> IBM tape device driver developer
> 
> Boaz

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2010-06-30 10:40 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-06-29 21:23 Length and alignment in scsi_execute_async and blk_rq_map_user Brett Dennis
2010-06-30 10:30 ` Boaz Harrosh
2010-06-30 10:39   ` Boaz Harrosh

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).