Received: by 2002:a25:86ce:0:0:0:0:0 with SMTP id y14csp144669ybm; Wed, 22 May 2019 00:21:59 -0700 (PDT) X-Google-Smtp-Source: APXvYqwftD48s5ZHQ/Mt3N/ll1I/c23eg7aQ/td+O+Z6DRabN0ebmox2obvKLByqzFDEwQd3x+zI X-Received: by 2002:a63:10d:: with SMTP id 13mr61660042pgb.176.1558509719464; Wed, 22 May 2019 00:21:59 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1558509719; cv=none; d=google.com; s=arc-20160816; b=KffeudKv3wanbjqViq8j0Q/Qet5QsHQ0nalYECipwVLaQcmrdjoGBUIUiW6H8xlD7J 48nJgt3PzigybX55iHmst/vejC0/k4b/gBKIKiB82+6bbWcZUAJAXH7RKrAdlFcvw0Gw McJnXuszJQ0jYfbGzbxFeSmBeriI12aMdnriPWCn7Rt2Ai/9lpVbTAZ7hAuk3wTF4zBi WE3detmjm31rNqJAr61HIgd7f6NA0YPp9UziNMH2ZcntxXeRR4YhA3uyybiwiJcZgoYf Fyz/6uF+BtpJFDYbqYKdq+gRmF7Yqk8+8zvSx81WVXCUshtyy2DbF/YvCN8sj6kR2Vm7 1KGw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from; bh=LTAEGp5U3J8SdHnlC6WmP6nClfw/f6gkgWE6hK7vTmI=; b=iwidDWUN2RKrmABEaN3cKGP2iZQllawJJP0ARziMOSoJzSrLph2hJrTT20vnYKvDOt PyL27mtuG3xWR7BuG8tPs43tVg54rAGo6MLtEm3UMXUyrXoAAS5JYQq8IEbD9V6XkGrO DlXgaCJN1feo+TgY6eEBOh5OIjzmRGkC0coStp0i/BFAHawPyMX6VblzTmsfzpOXk9mP uAZnBZxMav1kC/lSmhgnRPqiZY5+qYXnFcDwspGyU4PlcJFD+5YXGepgk7Pbl16sfI5/ Sgc8zI4IjGrctzzTBQh9E2T+WCf+oO7aPZ6VGBpOJgOsAUZjjGmKq+PCL2s7aQH5M8IA lhPw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=nxp.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id s20si26024160pgj.63.2019.05.22.00.21.42; Wed, 22 May 2019 00:21:59 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=nxp.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728406AbfEVHUd (ORCPT + 99 others); Wed, 22 May 2019 03:20:33 -0400 Received: from inva021.nxp.com ([92.121.34.21]:40532 "EHLO inva021.nxp.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726358AbfEVHUd (ORCPT ); Wed, 22 May 2019 03:20:33 -0400 Received: from inva021.nxp.com (localhost [127.0.0.1]) by inva021.eu-rdc02.nxp.com (Postfix) with ESMTP id 1073820008A; Wed, 22 May 2019 09:20:31 +0200 (CEST) Received: from inva024.eu-rdc02.nxp.com (inva024.eu-rdc02.nxp.com [134.27.226.22]) by inva021.eu-rdc02.nxp.com (Postfix) with ESMTP id 0057B200079; Wed, 22 May 2019 09:20:31 +0200 (CEST) Received: from fsr-ub1864-014.ea.freescale.net (fsr-ub1864-014.ea.freescale.net [10.171.95.219]) by inva024.eu-rdc02.nxp.com (Postfix) with ESMTP id 97A152061A; Wed, 22 May 2019 09:20:30 +0200 (CEST) From: =?UTF-8?q?Horia=20Geant=C4=83?= To: Konrad Rzeszutek Wilk , Christoph Hellwig , Marek Szyprowski , Robin Murphy Cc: iommu@lists.linux-foundation.org, linux-kernel@vger.kernel.org, linux-imx@nxp.com, =?UTF-8?q?Horia=20Geant=C4=83?= Subject: [PATCH] swiotlb: sync buffer when mapping FROM_DEVICE Date: Wed, 22 May 2019 10:20:18 +0300 Message-Id: <20190522072018.10660-1-horia.geanta@nxp.com> X-Mailer: git-send-email 2.17.1 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV using ClamSMTP Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From the very beginning, the swiotlb implementation (and even before that, pci implementation if we look in full git history) did not sync the bounced buffer in case of DMA mapping using DMA_FROM_DEVICE direction. However, this is incorrect since the device might not write to that area at all (or might partially write to it), which leads to data corruption in the sense that data in original buffer is lost (overwritten with uninitialized data in the bounced buffer at DMA unmap time). In general, DMA mapping using DMA_FROM_DEVICE does not mean existing data should be thrown away. Fix this by sync-ing the bounced buffer at DMA mapping time irrespective of DMA direction. Link: https://lore.kernel.org/lkml/584b54f6-bd12-d036-35e6-23eb2dabe811@arm.com Signed-off-by: Horia Geantă --- I haven't provided a Fixes tag since this approach goes way back in time. If you agree with the fix, we'll have to decide if it should go into -stable and what's the earliest LTS branch to get the backport. Patch is based on konrad/swiotlb.git, devel/for-linus-5.2 branch. kernel/dma/swiotlb.c | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/kernel/dma/swiotlb.c b/kernel/dma/swiotlb.c index 38d57218809c..f330222f0eb5 100644 --- a/kernel/dma/swiotlb.c +++ b/kernel/dma/swiotlb.c @@ -545,13 +545,14 @@ phys_addr_t swiotlb_tbl_map_single(struct device *hwdev, /* * Save away the mapping from the original address to the DMA address. - * This is needed when we sync the memory. Then we sync the buffer if - * needed. + * This is needed when we sync the memory. Then we sync the buffer + * irrespective of mapping direction - since for FROM_DEVICE we want to + * make sure original data is not lost in the case of device not fully + * overwriting the area mapped. */ for (i = 0; i < nslots; i++) io_tlb_orig_addr[index+i] = orig_addr + (i << IO_TLB_SHIFT); - if (!(attrs & DMA_ATTR_SKIP_CPU_SYNC) && - (dir == DMA_TO_DEVICE || dir == DMA_BIDIRECTIONAL)) + if (!(attrs & DMA_ATTR_SKIP_CPU_SYNC)) swiotlb_bounce(orig_addr, tlb_addr, size, DMA_TO_DEVICE); return tlb_addr; -- 2.17.1