From: Roland Dreier <roland@topspin.com>
To: James Bottomley <James.Bottomley@steeleye.com>
Cc: linux-kernel@vger.kernel.org, linux-scsi@vger.kernel.org
Subject: Re: [PATCH] 2.4 use __dma_buffer in scsi.h
Date: 13 Jun 2002 10:42:16 -0700 [thread overview]
Message-ID: <52fzzr2hzb.fsf@topspin.com> (raw)
In-Reply-To: <200206130218.g5D2Hx302994@localhost.localdomain>
>>>>> "James" == James Bottomley <James.Bottomley@steeleye.com> writes:
James> This is actually unnecessary. We've already had this
James> discussion on the parisc mailing lists (over a year ago, I
James> think).
Fair enough, the only reason I came up with this patch is that I
looked at all unaligned DMA done by USB, and
drivers/usb/storage/transport.c does DMA into sense_buffer.
James> The SCSI subsystem is designed with this type of cache
James> incoherency problem in mind. The Scsi_Cmnd structure has
James> an ownership model to forestall cache line bouncing. The
James> idea is that when you want to dma to/from components of a
James> Scsi_Cmnd, you can only do it when the ownership is
James> SCSI_OWNER_LOW_LEVEL, which guarantees that nothing in the
James> mid layer will touch the command and trigger an incoherency
James> (at least until it times out). The low level driver is
James> supposed to know about the cache incoherency problem, and
James> so avoids touching the structure between cache line
James> invalidation/writeback and DMA completion, thus, with a
James> correctly implemented driver, there should be no
James> possibility of DMA corruption.
Out of curiousity, how do you deal with someone writing to Scsi_Cmnd
_before_ the DMA and having that data lost when pci_map_single() with
PCI_DMA_FROMDEVICE invalidates the cache before writeback?
Best,
Roland
next prev parent reply other threads:[~2002-06-13 17:42 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-06-13 2:17 [PATCH] 2.4 use __dma_buffer in scsi.h James Bottomley
2002-06-13 17:42 ` Roland Dreier [this message]
2002-06-13 17:52 ` James Bottomley
-- strict thread matches above, loose matches on Subject: below --
2002-06-13 0:24 Roland Dreier
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=52fzzr2hzb.fsf@topspin.com \
--to=roland@topspin.com \
--cc=James.Bottomley@steeleye.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.