From patchwork Thu Nov 17 07:21:00 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Nanyong Sun X-Patchwork-Id: 21462 Return-Path: Delivered-To: ouuuleilei@gmail.com Received: by 2002:adf:f944:0:0:0:0:0 with SMTP id q4csp247765wrr; Wed, 16 Nov 2022 22:52:36 -0800 (PST) X-Google-Smtp-Source: AA0mqf7Gdil7OiqjDaKUcfldg0RbJDayA7uy9IzrITGEiMfIyVw00UtxxtNL06VVzLGOlqJNyz6T X-Received: by 2002:a17:906:35d5:b0:7ad:aeda:f814 with SMTP id p21-20020a17090635d500b007adaedaf814mr1066230ejb.441.1668667956537; Wed, 16 Nov 2022 22:52:36 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1668667956; cv=none; d=google.com; s=arc-20160816; b=By++ce6u9N3CiRt0FTjlze9PQjThpeJMVCM8Gjz/0yGkK+2Kr0AFpaYBoeAIgKLrEw 6Eyh7Gv9T6e+kntmUaYvMRVncx0jhyedBv3OGCpQGAo888c3HTaYpDmoZnCgeSFy7KBd mt++IgDjfqobdXQxfjJxOKJidN1EE7bs6f2ywurGKTBUS7vaUwV/TliknWDGiPqEpcEW nrPO2ez3au6YxycFu7yDlQmKiiclCiAl3lJac2ki/aE0vHtEf6sHSM1Wl6b/TQeP9Ath 2Ip5/zKE8sSVVWNJIa1LoJC04i4z0oY5G87iLR1i6F2L6KMUPtKcp3Pd4raErGoEbSMb quaA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from; bh=Z6o87QduuCHTHSaVorvjk+QHBS7din4YS7cy7frb5HY=; b=QH5KmUZy8nxdhSGqKRv0OCIRYcMhM6FwdoPX3MKpIYYILrP7qIqVYthH6AI33SMOIj prk4pVLyKlSCPLiXiB1vzTC2+qJdJDYwefHM50jQNY8Z8mWGnPKcMTQIj8ylWW45xoxb 6cSOOC8QdXyvWAt8uV5+rzWoe13cUiTZ93Lp5EOUaNZU5UyKLJg7OEpAttiKKNUFN5FL gVWv+CknCvBkDU0sn+Pkx5dRF48rMmOlpT4YCmAsghjlAm+SDn8knY11H2JnxyWTC7Pm 7cEn6NnjEjeSzHoE/kiyZ1rYptaCkNpDAc0K0iSaVlxIzjnt8hgPGzj5fCo5CIeNrW44 nk/w== 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=QUARANTINE sp=QUARANTINE dis=NONE) header.from=huawei.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id xj10-20020a170906db0a00b0070fc7c9d71dsi16239340ejb.989.2022.11.16.22.52.13; Wed, 16 Nov 2022 22:52:36 -0800 (PST) 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=QUARANTINE sp=QUARANTINE dis=NONE) header.from=huawei.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234074AbiKQGd2 (ORCPT + 99 others); Thu, 17 Nov 2022 01:33:28 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37748 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231871AbiKQGd0 (ORCPT ); Thu, 17 Nov 2022 01:33:26 -0500 Received: from szxga02-in.huawei.com (szxga02-in.huawei.com [45.249.212.188]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E6AD1118 for ; Wed, 16 Nov 2022 22:33:23 -0800 (PST) Received: from dggemv703-chm.china.huawei.com (unknown [172.30.72.53]) by szxga02-in.huawei.com (SkyGuard) with ESMTP id 4NCVTZ59KNzHvyx; Thu, 17 Nov 2022 14:32:50 +0800 (CST) Received: from kwepemm600003.china.huawei.com (7.193.23.202) by dggemv703-chm.china.huawei.com (10.3.19.46) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.31; Thu, 17 Nov 2022 14:33:22 +0800 Received: from huawei.com (10.175.113.32) by kwepemm600003.china.huawei.com (7.193.23.202) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.31; Thu, 17 Nov 2022 14:33:21 +0800 From: Nanyong Sun To: , , , , , , CC: , , , Subject: [RFC PATCH] arm64: mm: Add invalidate back in arch_sync_dma_for_device when FROM_DEVICE Date: Thu, 17 Nov 2022 15:21:00 +0800 Message-ID: <20221117072100.2720512-1-sunnanyong@huawei.com> X-Mailer: git-send-email 2.25.1 MIME-Version: 1.0 X-Originating-IP: [10.175.113.32] X-ClientProxiedBy: dggems705-chm.china.huawei.com (10.3.19.182) To kwepemm600003.china.huawei.com (7.193.23.202) X-CFilter-Loop: Reflected X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED, SPF_HELO_NONE,SPF_PASS autolearn=ham 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 X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1749725171175226438?= X-GMAIL-MSGID: =?utf-8?q?1749725171175226438?= The commit c50f11c6196f ("arm64: mm: Don't invalidate FROM_DEVICE buffers at start of DMA transfer") replaces invalidate with clean when DMA_FROM_DEVICE, this changes the behavior of functions like dma_map_single() and dma_sync_single_for_device(*, *, *, DMA_FROM_DEVICE), then it may make some drivers works unwell because the implementation of these DMA APIs lose the original cache invalidation. Situation 1: We can see that a lot of drivers in mainline have called the dma_sync_single_for_device(*, *, *, DMA_FROM_DEVICE) for sync, they would get cache invalidated before implementation changed, but now they got cache clean, which may violate the original expectation of the drivers and result in errors. Situation 2: After backporting the above commit, we find a network card driver go wrong with cache inconsistency when doing DMA transfer: CPU got the stale data in cache when reading DMA data received from device. A similar phenomenon happens on sata disk drivers, it involves mainline modules like libata, scsi, ahci etc, and is hard to find out which line of code results in the error. It seems that some dirvers may go wrong and have to match the implementation changes of the DMA APIs, and it would be confused because the behavior of these DMA APIs on arm64 are different from other archs. Add invalidate back in arch_sync_dma_for_device() to keep drivers compatible by replace dcache_clean_poc with dcache_clean_inval_poc when DMA_FROM_DEVICE. Fixes: c50f11c6196f ("arm64: mm: Don't invalidate FROM_DEVICE buffers at start of DMA transfer") Signed-off-by: Nanyong Sun --- arch/arm64/mm/dma-mapping.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/arch/arm64/mm/dma-mapping.c b/arch/arm64/mm/dma-mapping.c index 3cb101e8cb29..07f6a3089c64 100644 --- a/arch/arm64/mm/dma-mapping.c +++ b/arch/arm64/mm/dma-mapping.c @@ -18,7 +18,10 @@ void arch_sync_dma_for_device(phys_addr_t paddr, size_t size, { unsigned long start = (unsigned long)phys_to_virt(paddr); - dcache_clean_poc(start, start + size); + if (dir == DMA_FROM_DEVICE) + dcache_clean_inval_poc(start, start + size); + else + dcache_clean_poc(start, start + size); } void arch_sync_dma_for_cpu(phys_addr_t paddr, size_t size,