public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: James Bottomley <James.Bottomley@HansenPartnership.com>
Cc: Linux Kernel list <linux-kernel@vger.kernel.org>,
	linux-scsi <linux-scsi@vger.kernel.org>,
	Russell King <rmk@arm.linux.org.uk>
Subject: SCSI breakage on non-cache coherent architectures
Date: Mon, 19 Nov 2007 16:35:23 +1100	[thread overview]
Message-ID: <1195450523.7022.37.camel@pasglop> (raw)

Hi James !

(Please CC me on replies as I'm not subscribed to linux-scsi)

I've been debugging various issues on the PowerPC 44x embedded
architecture which happens to have non-coherent PCI DMA.

One of the problem I'm hitting is that one really need to enforce
kmalloc alignement to cache lines or bad things will happen (among
others with USB), for some reasons, powerpc failed to do so, I fixed it.

The other one I'm hitting now is that the SCSI layer nowadays embeds the
sense_buffer inside the scsi_cmnd structure without any kind of
alignment whatsoever. I've been hitting irregulary is a crash on SCSI command
completion that seems to be related to corruption of the "request"
pointer in struct scsi_cmnd and I think it might be the cause.
I'm now trying to setup a proper repro-case.

The sense buffer is something that is written to by the device, thus it
gets cache invalidated when the DMA happens, potentially losing whatever
was sharing the cache line, which includes, among other things, that
"request" pointer field.

There are other issues as well if any of the fields sharing the cache
line happens to be read while the DMA is in progress, it would
populate the cache with memory content prior to the DMA being completed.

It's fairly important on such architectures not to share cache lines
between objects being DMA'd to/from and the rest of the system. If the
DMA is strictly outgoing, it's generally ok, but not if the DMA is
bidirectional or the device is writing to memory.

I'm not sure what is the best way to fix that. Internally, I've done
some test whacking some ____cacheline_aligned in the scsi_cmnd data
structure to verify I no longer get random SLAB corruption when using my
USB but that significantly bloats the size of the structure on archs
such as ppc64 that don't need it and have a large cache line size.

Unfortunately, I don't think there's any existing Kconfig symbol or arch
provided #define to tell us that we are on a non-coherent arch afaik
that could be used to make that conditional.

Another option would be to kmalloc the buffer (wasn't it the case before
btw ?) but I suppose some people will scream at the idea due to how the
command pools are done...

What do you suggest ?

Cheers,
Ben.



             reply	other threads:[~2007-11-19  5:36 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-11-19  5:35 Benjamin Herrenschmidt [this message]
2007-11-19  8:38 ` SCSI breakage on non-cache coherent architectures David Miller
2007-11-19 19:51   ` Benjamin Herrenschmidt
2007-11-19 22:31     ` David Miller
2007-11-20  0:34       ` Benjamin Herrenschmidt
2007-11-20  0:46         ` David Miller
2007-11-20  0:55           ` Benjamin Herrenschmidt
2007-11-20  0:57             ` David Miller
2007-11-20  2:10           ` Roland Dreier
2007-11-20  2:35             ` Benjamin Herrenschmidt
2007-11-20  3:14             ` Benjamin Herrenschmidt
2007-11-20 19:35               ` James Bottomley
2007-11-20  8:29     ` Thomas Bogendoerfer
2007-11-20 14:36       ` James Bottomley
2007-11-20 20:05         ` Roland Dreier
2007-11-20 21:10           ` James Bottomley
2007-11-20 22:39             ` Benjamin Herrenschmidt
2007-11-20 23:09               ` James Bottomley
2007-11-19 12:32 ` Matthew Wilcox
2007-11-19 15:09   ` James Bottomley
2007-11-19 19:54     ` Benjamin Herrenschmidt
2007-11-19 19:55     ` Benjamin Herrenschmidt
2007-11-19 19:53   ` Benjamin Herrenschmidt
2007-11-19 21:43 ` Roland Dreier
2007-11-19 21:55   ` Benjamin Herrenschmidt

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=1195450523.7022.37.camel@pasglop \
    --to=benh@kernel.crashing.org \
    --cc=James.Bottomley@HansenPartnership.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=rmk@arm.linux.org.uk \
    /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