Received: by 2002:ac8:156:0:b0:3e0:cd10:60c8 with SMTP id f22csp562240qtg; Fri, 31 Mar 2023 10:19:55 -0700 (PDT) X-Google-Smtp-Source: AKy350aumx5dnVjU6c9U6AeCIKXR0j15Wrz6qQtfxMZjf6OYjbGU/n6BGCWhlIdFkduOCZz3/6g7 X-Received: by 2002:a17:90b:e01:b0:237:40a5:77cb with SMTP id ge1-20020a17090b0e0100b0023740a577cbmr6440194pjb.1.1680283194915; Fri, 31 Mar 2023 10:19:54 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1680283194; cv=none; d=google.com; s=arc-20160816; b=tzgaSlRkn/qIBe1ZAB086H4WmZUKOiwDNEj0RIpYxuyGGKmAaXZNsGAY11IZ4Pm+V3 1THZzCKYB5cMcAhD8rDCQA2L6ZSLmB/GUh5bqR5iMl33qoKOz1f60IKQzyC7NllwtsJ7 LC9cn6s+J1M4OvtsGjd5wsVlhuxsj0hYcOTHRF+wFCbLcPxKY2E+FK14+w+qWkx1KelY 0ixSFDoNolg+84a7jOslMsiXl0+dkRhwwOUqREb4IYYlDkQSjQFD6tLQdnz2MJBAgvVJ +a9Rj9JLORAElc2gDGkeK34kHly3HUdindcHv98XEnEG6Ds+1dkTrLWbOwkwDt6R4LZv kT2g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date; bh=J2F4J8CYNsJz4d+ZiBkNKf+1v3E44k0xTHMwW3KMXNA=; b=RlKiwpjBnGrWlLN2RzoL9FxgSArwOP1Ievfv90rHp1Dn1RbuNOgj4jM3fnkOd468aj 4qXoijZqnMSCDRF1y2+gLNGycTDj4RO8uThsUIednKDlUr5YX3uEHw7wMe+3D8P+wf49 6u8mYKlrhVW3N3jUrCCV/GYxBdbUde6Y3Oo0+EoFFoTm2k8IsKx7QFsVDtBqotLsWykB uPof6myfCaMQkNt8pnxWwYO/c802ZUQfs8Q70NAuUmBQcOG5bJSfQ4zlvz19pjUkV6IT 1LhwfUVZaobz3v3vdX6e86CoDDgRuxTglBrsfc5NlrIyp8mUHBf8H6qav9TjYc6EXain yyaw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id mg17-20020a17090b371100b0023def94be71si2772412pjb.162.2023.03.31.10.19.43; Fri, 31 Mar 2023 10:19:54 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232327AbjCaRJc (ORCPT + 99 others); Fri, 31 Mar 2023 13:09:32 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42452 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230142AbjCaRJ3 (ORCPT ); Fri, 31 Mar 2023 13:09:29 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E451012CF5; Fri, 31 Mar 2023 10:09:27 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 8314762AB0; Fri, 31 Mar 2023 17:09:27 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 65E1FC433D2; Fri, 31 Mar 2023 17:09:19 +0000 (UTC) Date: Fri, 31 Mar 2023 18:09:16 +0100 From: Catalin Marinas To: Arnd Bergmann Cc: linux-kernel@vger.kernel.org, Arnd Bergmann , Vineet Gupta , Russell King , Neil Armstrong , Linus Walleij , Will Deacon , Guo Ren , Brian Cain , Geert Uytterhoeven , Michal Simek , Thomas Bogendoerfer , Dinh Nguyen , Stafford Horne , Helge Deller , Michael Ellerman , Christophe Leroy , Paul Walmsley , Palmer Dabbelt , Rich Felker , John Paul Adrian Glaubitz , "David S. Miller" , Max Filippov , Christoph Hellwig , Robin Murphy , Lad Prabhakar , Conor Dooley , linux-snps-arc@lists.infradead.org, linux-arm-kernel@lists.infradead.org, linux-oxnas@groups.io, linux-csky@vger.kernel.org, linux-hexagon@vger.kernel.org, linux-m68k@lists.linux-m68k.org, linux-mips@vger.kernel.org, linux-openrisc@vger.kernel.org, linux-parisc@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, linux-riscv@lists.infradead.org, linux-sh@vger.kernel.org, sparclinux@vger.kernel.org, linux-xtensa@linux-xtensa.org, Daniel Golle Subject: Re: [PATCH 18/21] ARM: drop SMP support for ARM11MPCore Message-ID: References: <20230327121317.4081816-1-arnd@kernel.org> <20230327121317.4081816-19-arnd@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230327121317.4081816-19-arnd@kernel.org> X-Spam-Status: No, score=-4.8 required=5.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, RCVD_IN_DNSWL_HI,SPF_HELO_NONE,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Mar 27, 2023 at 02:13:14PM +0200, Arnd Bergmann wrote: > From: Arnd Bergmann > > The cache management operations for noncoherent DMA on ARMv6 work > in two different ways: > > * When CONFIG_DMA_CACHE_RWFO is set, speculative prefetches on in-flight > DMA buffers lead to data corruption when the prefetched data is written > back on top of data from the device. > > * When CONFIG_DMA_CACHE_RWFO is disabled, a cache flush on one CPU > is not seen by the other core(s), leading to inconsistent contents > accross the system. > > As a consequence, neither configuration is actually safe to use in a > general-purpose kernel that is used on both MPCore systems and ARM1176 > with prefetching enabled. As the author of this terrible hack (created under duress ;)) Acked-by: Catalin Marinas IIRC, RWFO is working in combination with the cache operations. Because the cache maintenance broadcast did not happen, we forced the cache lines to migrate to a CPU via a write (for ownership) and doing the cache maintenance on that CPU (that was the FROM_DEVICE case). For the TO_DEVICE case, reading on a CPU would cause dirty lines on another CPU to be evicted (or migrated as dirty to the current CPU IIRC) then the cache maintenance to clean them to PoC on the local CPU. But there's always a small window between read/write for ownership and the actual cache maintenance which can cause a cache line to migrate to other CPUs if they do speculative prefetches. At the time ARM11MPCore was deemed safe-ish but I haven't followed what later implementations actually did (luckily we fixed the architecture in ARMv7). -- Catalin