lkml.org 
[lkml]   [2010]   [Sep]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: scsi_cmnd data_buffer checksum
On Thu, Sep 09, 2010 at 01:35:02AM -0700, Anil kumar wrote:
> Hi Christof,
>
> Thanks for the response.
>
> I am running mkfs.ext3 command.
>
> I am doing the following in the driver for write(10):
>
> Queuecommand:
>
> sg = scsi_sglist(cmd->scsi_cmd);
> cmd->write_buf = (u8 *)(kmap_atomic(sg->page, KM_IRQ0) + sg->offset);
> Calculate checksum for write_buf
>
> Write Done:
> Calculate checksum for cmd->write_buf
>
> and checksums don't match. I am wondering how come OS changed the cmd->write_buf when I have not even unmapped the buffer. Is filesystem changing this cmd->write_buf pages when driver/HW is working on it?

Yes, the driver has direct access to the data. Usually, the data is
not copied for I/O requests. The driver gets one sg list that points
to the data pages of file system (or whatever the data source is).
When the filesystem decides to change the data, this single data
buffer is changed.

> Is there anyway I can avoid this. How about if we allocate a local buffer(kmalloc/pci_alloc_consistent) and memcpy kmap_atomic to that local buffer and then calculate checksum on that local buffer. Will this help?

Sure, you can create copies of data buffers in the driver, calculate
the checksum of the copy and submit the data copy with the checksum to
the hardware controller. This is usually not done for performance
reasons, and you probably should keep a mempool to be able to issue
I/Os when memory is low.

Christof


\
 
 \ /
  Last update: 2010-09-09 10:55    [W:0.140 / U:0.140 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site