All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eugene Surovegin <ebs@ebshome.net>
To: linuxppc-embedded@lists.linuxppc.org
Subject: [RFC] consistent_sync and non L1 cache line aligned buffers
Date: Mon, 14 Jul 2003 21:32:07 -0700	[thread overview]
Message-ID: <5.1.0.14.2.20030714210220.0308a070@mail.zultys.com> (raw)


Hi!

I think this is a known problem.

There are drivers or even subsystems which use stack allocated DMA buffers.
To make things worse, those buffers usually non L1 cache line aligned
(start and/or end).

When they use pci_map_* with PCI_DMA_FROMDEVICE, consistent_sync calls
invalidate_dcache_range for the buffer.

invalidate_dcache_range works in L1_CACHE_LINE chunks, so if start and/or
end of the buffer are not aligned we may corrupt data located in the same
cache line (usually stack variable(s) declared before or after buffer
declaration).

According to MV kernel, there are USB devices that use such buffers.

After spending last weekend with RISCWatch :) I can say that SCSI subsystem
is also guilty of this behavior (drivers/scsi/scsi_scan.c::scan_scsis,
scsi_result0).

Unfortunately, I don't know how many similar places of code are still
waiting to be found :(.
To be safe I think it's better to modify consistent_sync to handle such
"bad" buffers.

If start and/or end of the buffer are not properly aligned I use "dcbf" to
flush corresponding cache line(s) and then call invalidate_dcache_range.

This change doesn't affect performance of consistent_sync noticeably (like
in the variant I found in MV kernel, where invalidate_dcache_range was
changed to flush_dcache_range if USB was enabled)

I don't know whether we should "ifdef" this for CONFIG_4xx and I know this
fix is ugly :)
I'm not even sure that such hacks should be included in the kernel :)))
(but I will definitely use it in my tree)

Comments/suggestions are welcome!

Thanks,

Eugene


===== arch/ppc/mm/cachemap.c 1.13 vs edited =====
--- 1.13/arch/ppc/mm/cachemap.c	Thu Feb 27 11:40:16 2003
+++ edited/arch/ppc/mm/cachemap.c	Mon Jul 14 20:49:28 2003
@@ -150,6 +150,21 @@
  	case PCI_DMA_NONE:
  		BUG();
  	case PCI_DMA_FROMDEVICE:	/* invalidate only */
+
+		/* Handle cases when the buffer start and/or end
+		   are not L1 cache line aligned.
+		   Some drivers/subsystems (e.g. USB, SCSI) do DMA
+		   from the stack allocated buffers, to prevent
+		   corruption of the other stack variables located
+		   near the buffer, we flush (instead of invalidate)
+		   these "dangerous" areas                     --ebs
+		*/
+		if (unlikely(start & (L1_CACHE_LINE_SIZE - 1)))
+			__asm__ __volatile__("dcbf 0,%0" : : "r" (start));
+
+		if (unlikely(end & (L1_CACHE_LINE_SIZE - 1)))
+			__asm__ __volatile__("dcbf 0,%0" : : "r" (end));
+
  		invalidate_dcache_range(start, end);
  		break;
  	case PCI_DMA_TODEVICE:		/* writeback only */


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

             reply	other threads:[~2003-07-15  4:32 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-07-15  4:32 Eugene Surovegin [this message]
2003-07-15 15:46 ` [RFC] consistent_sync and non L1 cache line aligned buffers Tom Rini
2003-07-15 16:20   ` Eugene Surovegin
2003-07-15 16:25     ` Tom Rini
2003-07-15 16:17 ` Matt Porter
2003-07-15 16:27   ` Eugene Surovegin
2003-07-15 18:11     ` PPCBoot on Ebony board Brian Padalino
2003-07-15 21:32       ` Chris Zimman
2003-07-16 11:59         ` Brian Padalino
2003-07-16 14:29           ` Chris Zimman
2003-07-16 15:39             ` Brian Padalino
2003-07-16 14:45           ` Roland Dreier
2003-07-15 23:51     ` [RFC] consistent_sync and non L1 cache line aligned buffers Matt Porter
2003-07-15 20:18 Darin.Johnson
     [not found] <F0B628F30F48064289D8CCC1EE21B7A80C48A5@mvebe001.americas.n okia.com>
2003-07-15 20:39 ` Eugene Surovegin
2003-07-15 21:26   ` David Blythe
2003-07-15 22:15     ` Dan Malek
2003-07-15 20:47 Darin.Johnson
2003-07-15 23:04 Darin.Johnson
2003-07-15 23:34 ` Paul Mackerras
2003-07-15 23:50   ` Eugene Surovegin
2003-07-15 23:45 ` Matt Porter
2003-07-16 14:01 ` Dan Malek
2003-07-16  0:12 Darin.Johnson

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=5.1.0.14.2.20030714210220.0308a070@mail.zultys.com \
    --to=ebs@ebshome.net \
    --cc=linuxppc-embedded@lists.linuxppc.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.