public inbox for linux-scsi@vger.kernel.org
 help / color / mirror / Atom feed
From: Christof Schmitt <christof.schmitt@de.ibm.com>
To: Anil kumar <anils_r@yahoo.com>
Cc: linux-kernel@vger.kernel.org, linux-scsi@vger.kernel.org
Subject: Re: scsi_cmnd data_buffer checksum
Date: Thu, 9 Sep 2010 10:51:43 +0200	[thread overview]
Message-ID: <20100909085142.GA15327@schmichrtp.mainz.de.ibm.com> (raw)
In-Reply-To: <534531.52796.qm@web32407.mail.mud.yahoo.com>

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

  reply	other threads:[~2010-09-09  8:51 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-09-09  3:36 scsi_cmnd data_buffer checksum Anil kumar
2010-09-09  8:00 ` Christof Schmitt
2010-09-09  8:35   ` Anil kumar
2010-09-09  8:51     ` Christof Schmitt [this message]
2010-09-09  9:09       ` Anil kumar
2010-09-09  9:29         ` Christof Schmitt
2010-09-09 13:23         ` Martin K. Petersen
2010-09-09 19:34           ` Anil kumar
2010-09-10  3:33             ` Martin K. Petersen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20100909085142.GA15327@schmichrtp.mainz.de.ibm.com \
    --to=christof.schmitt@de.ibm.com \
    --cc=anils_r@yahoo.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox