From patchwork Fri Apr 27 00:11:42 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Rosen Penev X-Patchwork-Id: 905442 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=none (mailfrom) smtp.mailfrom=lists.infradead.org (client-ip=2607:7c80:54:e::133; helo=bombadil.infradead.org; envelope-from=lede-dev-bounces+incoming=patchwork.ozlabs.org@lists.infradead.org; receiver=) Authentication-Results: ozlabs.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: ozlabs.org; dkim=pass (2048-bit key; unprotected) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="EUNzJkVV"; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.b="ayWH94TQ"; dkim-atps=neutral Received: from bombadil.infradead.org (bombadil.infradead.org [IPv6:2607:7c80:54:e::133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 40XDrn23YVz9s02 for ; Fri, 27 Apr 2018 10:12:07 +1000 (AEST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:MIME-Version:Cc:List-Subscribe: List-Help:List-Post:List-Archive:List-Unsubscribe:List-Id:Subject:Message-Id: Date:To:From:Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References: List-Owner; bh=y2VaCpfc3M8jOEcuwnWdjnrlWiR9eu7XcjOZks2xlXc=; b=EUNzJkVVB9x4Bv Dp+za55bAaugCll4lr3DDgS4+hUX/x4BmTXjjNuV+Be0VF+2UybfKfUYCNZG70iLvAvaZui1R8yIT DTG7/95hiWZRRUMU8KU1tWGeaJxI5C6zuvQKELDHDqQG5KSHtFedCURaQdFtEOzfIraVW03tfUd48 /zAZFdDGJLMLsVGhmAfYqKQijsIbSuMgltgd/FrANxDHh8K+aXE8+wR6xRtCgLLUik5Iivbj1R5si uXDnYUgicEB3z37umuKB01/bEtpojDY6Eq2QFw4lYkUZx3mUxdemS/PCLZq1zaC1nQjE+Cvrd9KBZ XTHRwK6XqqzzlFnOgicA==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.90_1 #2 (Red Hat Linux)) id 1fBqzX-0007pO-Ha; Fri, 27 Apr 2018 00:11:59 +0000 Received: from mail-pg0-x22f.google.com ([2607:f8b0:400e:c05::22f]) by bombadil.infradead.org with esmtps (Exim 4.90_1 #2 (Red Hat Linux)) id 1fBqzR-0007oA-I3 for lede-dev@lists.infradead.org; Fri, 27 Apr 2018 00:11:55 +0000 Received: by mail-pg0-x22f.google.com with SMTP id n9-v6so125429pgq.5 for ; Thu, 26 Apr 2018 17:11:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id; bh=36PoMH6SNaFDtmHViwuhMhPxnTyZkg657bxn/8jPZQo=; b=ayWH94TQx7IMmT289/J+Oi6MvzsKXPKK2a+k+vpspSry0kJNsDiDvUUt4MQnf5wAmB qI0KnuinjN2oaieGIg9Ck7MnwIzw6WRRdor9NPugzAHRMz2uYwtXyzmNY+/ZTXzTQcfD 2yB68yieBpSa7mP/1zZtttz8D0uZXTtkeEVgO04IxcrC51XG055T/FLm5ErCpkenyW0b yLAbjiNGvy4LkusKYNEmjo5M1Oxka82I+9NZpbx402fLyZGtsKqOWPbzcki2N5XQUuCx KMzmL7qsKLOCk4RO/VO68i/cgk4kxzldB0qJZ9OE41s6dzNEmLvrn74rMLVdXf4j6JnG UKPA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id; bh=36PoMH6SNaFDtmHViwuhMhPxnTyZkg657bxn/8jPZQo=; b=Zb+fDtprFMXhJ3ESE0WPoBBgQEgZienBQFo8R9p0qU3WdAZDi9c9paysSliTpoaYAm KvIOdIkeazsqgGRTqHpvvIaKwecMLeDs/ltdLJEkkzQc0J+u/vSu8vtiAnbxBU/6OCcX xlkr/PGFxXmPQ7Vp1wN31fKieW3LaDEP0fWFCmY/xS41mqqO47cb1dRTXvmmwwv69QX8 epli4YlZYvcdaTVDMln9QFBA5vBYQamJw3/NAn6JUS2inmrfhewqxSdAhYyyUaf9GQtO 8c4iOoAroLb20HXvevZdeuh1NH5iuj2Mw8WfIKHROyhf29HgQUokhX+iO1ciF3g7RNb0 IbRQ== X-Gm-Message-State: ALQs6tAcjDp3LGjGHLMg/oY4ceFOWi8mwHlq5+GKu7nipABbJ2nHWp6f zlv367ErYU5rdZ+cIXJvRBorITkU X-Google-Smtp-Source: AB8JxZoJOPzAUM7O7/xem8ud4XOZJkAf5uHia3ZIDDHftGCiCbIK+I7seWs3dL64Mo2B6TD8k3jTpw== X-Received: by 2002:a17:902:3281:: with SMTP id z1-v6mr153840plb.226.1524787899408; Thu, 26 Apr 2018 17:11:39 -0700 (PDT) Received: from DESKTOP-CEH0M93.lan (astound-69-42-5-101.ca.astound.net. [69.42.5.101]) by smtp.gmail.com with ESMTPSA id y3-v6sm47220pgc.81.2018.04.26.17.11.37 (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 26 Apr 2018 17:11:38 -0700 (PDT) From: Rosen Penev To: lede-dev@lists.infradead.org Date: Thu, 26 Apr 2018 17:11:42 -0700 Message-Id: <1524787902-14536-1-git-send-email-rosenp@gmail.com> X-Mailer: git-send-email 2.7.4 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20180426_171153_624984_029C4F28 X-CRM114-Status: GOOD ( 19.70 ) X-Spam-Score: -0.1 (/) X-Spam-Report: SpamAssassin version 3.4.1 on bombadil.infradead.org summary: Content analysis details: (-0.1 points) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [2607:f8b0:400e:c05:0:0:0:22f listed in] [list.dnswl.org] 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (rosenp[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid Subject: [LEDE-DEV] [PATCH] kernel: Fix data corruption on some mips devices. X-BeenThere: lede-dev@lists.infradead.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Rosen Penev MIME-Version: 1.0 Sender: "Lede-dev" Errors-To: lede-dev-bounces+incoming=patchwork.ozlabs.org@lists.infradead.org This is mainly a bug fix for multi-core MIPS systems where L1 caches besides the primary do not get flushed. The most obvious problem is data corruption on SATA and USB devices where read requests are typically larger than the cacheline size. This may also fix ar71xx systems that suffer from similar data corruption but I have not tested if it does. Signed-off-by: Rosen Penev --- ...ata-corruption-related-to-cache-coherence.patch | 92 ++++++++++++++++++++++ 1 file changed, 92 insertions(+) create mode 100755 target/linux/generic/pending-4.14/103-MIPS-c-r4k-fix-data-corruption-related-to-cache-coherence.patch diff --git a/target/linux/generic/pending-4.14/103-MIPS-c-r4k-fix-data-corruption-related-to-cache-coherence.patch b/target/linux/generic/pending-4.14/103-MIPS-c-r4k-fix-data-corruption-related-to-cache-coherence.patch new file mode 100755 index 0000000..3cfbd2c --- /dev/null +++ b/target/linux/generic/pending-4.14/103-MIPS-c-r4k-fix-data-corruption-related-to-cache-coherence.patch @@ -0,0 +1,92 @@ +From patchwork Thu Apr 26 23:28:34 2018 +Content-Type: text/plain; charset="utf-8" +MIME-Version: 1.0 +Content-Transfer-Encoding: 7bit +Subject: [v2] MIPS: c-r4k: fix data corruption related to cache coherence. +X-Patchwork-Submitter: NeilBrown +X-Patchwork-Id: 19259 +Message-Id: <87vacdlf8d.fsf@notabene.neil.brown.name> +To: James Hogan +Cc: Ralf Baechle , + Paul Burton , linux-mips@linux-mips.org, + linux-kernel@vger.kernel.org +Date: Fri, 27 Apr 2018 09:28:34 +1000 +From: NeilBrown +List-Id: linux-mips + +When DMA will be performed to a MIPS32 1004K CPS, the +L1-cache for the range needs to be flushed and invalidated +first. +The code currently takes one of two approaches. +1/ If the range is less than the size of the dcache, then + HIT type requests flush/invalidate cache lines for the + particular addresses. HIT-type requests a globalised + by the CPS so this is safe on SMP. + +2/ If the range is larger than the size of dcache, then + INDEX type requests flush/invalidate the whole cache. + INDEX type requests affect the local cache only. CPS + does not propagate them in any way. So this invalidation + is not safe on SMP CPS systems. + +Data corruption due to '2' can quite easily be demonstrated by +repeatedly "echo 3 > /proc/sys/vm/drop_caches" and then sha1sum +a file that is several times the size of available memory. +Dropping caches means that large contiguous extents (large than +dcache) are more likely. + +This was not a problem before Linux-4.8 because option 2 was +never used if CONFIG_MIPS_CPS was defined. The commit +which removed that apparently didn't appreciate the full +consequence of the change. + +We could, in theory, globalize the INDEX based flush by sending an IPI +to other cores. These cache invalidation routines can be called with +interrupts disabled and synchronous IPI require interrupts to be +enabled. Asynchronous IPI may not trigger writeback soon enough. +So we cannot use IPI in practice. + +We can already test is IPI would be needed for an INDEX operation +with r4k_op_needs_ipi(R4K_INDEX). If this is True then we mustn't try +the INDEX approach as we cannot use IPI. If this is False (e.g. when +there is only one core and hence one L1 cache) then it is safe to +use the INDEX approach without IPI. + +This patch avoids options 2 if r4k_op_needs_ipi(R4K_INDEX), and so +eliminates the corruption. + +Fixes: c00ab4896ed5 ("MIPS: Remove cpu_has_safe_index_cacheops") +Cc: stable@vger.kernel.org # v4.8+ +Signed-off-by: NeilBrown +--- + arch/mips/mm/c-r4k.c | 9 ++++++--- + 1 file changed, 6 insertions(+), 3 deletions(-) + +diff --git a/arch/mips/mm/c-r4k.c b/arch/mips/mm/c-r4k.c +index 6f534b209971..e12dfa48b478 100644 +--- a/arch/mips/mm/c-r4k.c ++++ b/arch/mips/mm/c-r4k.c +@@ -851,9 +851,12 @@ static void r4k_dma_cache_wback_inv(unsigned long addr, unsigned long size) + /* + * Either no secondary cache or the available caches don't have the + * subset property so we have to flush the primary caches +- * explicitly ++ * explicitly. ++ * If we would need IPI to perform an INDEX-type operation, then ++ * we have to use the HIT-type alternative as IPI cannot be used ++ * here due to interrupts possibly being disabled. + */ +- if (size >= dcache_size) { ++ if (!r4k_op_needs_ipi(R4K_INDEX) && size >= dcache_size) { + r4k_blast_dcache(); + } else { + R4600_HIT_CACHEOP_WAR_IMPL; +@@ -890,7 +893,7 @@ static void r4k_dma_cache_inv(unsigned long addr, unsigned long size) + return; + } + +- if (size >= dcache_size) { ++ if (!r4k_op_needs_ipi(R4K_INDEX) && size >= dcache_size) { + r4k_blast_dcache(); + } else { + R4600_HIT_CACHEOP_WAR_IMPL;