git.openwrt.org Git - openwrt/staging/aparcar.git/blob

   1 From patchwork Thu Apr 26 23:28:34 2018
   2 Content-Type: text/plain; charset="utf-8"
   3 MIME-Version: 1.0
   4 Content-Transfer-Encoding: 7bit
   5 Subject: [v2] MIPS: c-r4k: fix data corruption related to cache coherence.
   6 X-Patchwork-Submitter: NeilBrown <neil@brown.name>
   7 X-Patchwork-Id: 19259
   8 Message-Id: <87vacdlf8d.fsf@notabene.neil.brown.name>
   9 To: James Hogan <jhogan@kernel.org>
  10 Cc: Ralf Baechle <ralf@linux-mips.org>,
  11  Paul Burton <paul.burton@mips.com>, linux-mips@linux-mips.org,
  12  linux-kernel@vger.kernel.org
  13 Date: Fri, 27 Apr 2018 09:28:34 +1000
  14 From: NeilBrown <neil@brown.name>
  15 List-Id: linux-mips <linux-mips.eddie.linux-mips.org>
  16
  17 When DMA will be performed to a MIPS32 1004K CPS, the
  18 L1-cache for the range needs to be flushed and invalidated
  19 first.
  20 The code currently takes one of two approaches.
  21 1/ If the range is less than the size of the dcache, then
  22    HIT type requests flush/invalidate cache lines for the
  23    particular addresses.  HIT-type requests a globalised
  24    by the CPS so this is safe on SMP.
  25
  26 2/ If the range is larger than the size of dcache, then
  27    INDEX type requests flush/invalidate the whole cache.
  28    INDEX type requests affect the local cache only. CPS
  29    does not propagate them in any way.  So this invalidation
  30    is not safe on SMP CPS systems.
  31
  32 Data corruption due to '2' can quite easily be demonstrated by
  33 repeatedly "echo 3 > /proc/sys/vm/drop_caches" and then sha1sum
  34 a file that is several times the size of available memory.
  35 Dropping caches means that large contiguous extents (large than
  36 dcache) are more likely.
  37
  38 This was not a problem before Linux-4.8 because option 2 was
  39 never used if CONFIG_MIPS_CPS was defined.  The commit
  40 which removed that apparently didn't appreciate the full
  41 consequence of the change.
  42
  43 We could, in theory, globalize the INDEX based flush by sending an IPI
  44 to other cores.  These cache invalidation routines can be called with
  45 interrupts disabled and synchronous IPI require interrupts to be
  46 enabled.  Asynchronous IPI may not trigger writeback soon enough.
  47 So we cannot use IPI in practice.
  48
  49 We can already test is IPI would be needed for an INDEX operation
  50 with r4k_op_needs_ipi(R4K_INDEX).  If this is True then we mustn't try
  51 the INDEX approach as we cannot use IPI.  If this is False (e.g. when
  52 there is only one core and hence one L1 cache) then it is safe to
  53 use the INDEX approach without IPI.
  54
  55 This patch avoids options 2 if r4k_op_needs_ipi(R4K_INDEX), and so
  56 eliminates the corruption.
  57
  58 Fixes: c00ab4896ed5 ("MIPS: Remove cpu_has_safe_index_cacheops")
  59 Cc: stable@vger.kernel.org # v4.8+
  60 Signed-off-by: NeilBrown <neil@brown.name>
  61 ---
  62  arch/mips/mm/c-r4k.c | 9 ++++++---
  63  1 file changed, 6 insertions(+), 3 deletions(-)
  64
  65 --- a/arch/mips/mm/c-r4k.c
  66 +++ b/arch/mips/mm/c-r4k.c
  67 @@ -851,9 +851,12 @@ static void r4k_dma_cache_wback_inv(unsi
  68         /*
  69          * Either no secondary cache or the available caches don't have the
  70          * subset property so we have to flush the primary caches
  71 -        * explicitly
  72 +        * explicitly.
  73 +        * If we would need IPI to perform an INDEX-type operation, then
  74 +        * we have to use the HIT-type alternative as IPI cannot be used
  75 +        * here due to interrupts possibly being disabled.
  76          */
  77 -       if (size >= dcache_size) {
  78 +       if (!r4k_op_needs_ipi(R4K_INDEX) && size >= dcache_size) {
  79                 r4k_blast_dcache();
  80         } else {
  81                 R4600_HIT_CACHEOP_WAR_IMPL;
  82 @@ -890,7 +893,7 @@ static void r4k_dma_cache_inv(unsigned l
  83                 return;
  84         }
  85
  86 -       if (size >= dcache_size) {
  87 +       if (!r4k_op_needs_ipi(R4K_INDEX) && size >= dcache_size) {
  88                 r4k_blast_dcache();
  89         } else {
  90                 R4600_HIT_CACHEOP_WAR_IMPL;