From patchwork Tue Feb 9 06:09:25 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Sumit Garg X-Patchwork-Id: 379290 Delivered-To: patch@linaro.org Received: by 2002:a02:b18a:0:0:0:0:0 with SMTP id t10csp5311276jah; Mon, 8 Feb 2021 22:11:04 -0800 (PST) X-Google-Smtp-Source: ABdhPJwBFDvFOI+Vj/VLg25rssqw5ZUiy15sAOY0UhOC2Q7rETx3zEidAsEb24slMP55Q4+0LmmC X-Received: by 2002:a50:b5c5:: with SMTP id a63mr20926840ede.227.1612851063872; Mon, 08 Feb 2021 22:11:03 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1612851063; cv=none; d=google.com; s=arc-20160816; b=PTwGYP+7umKGfLI9ImmlZGeCz7tbxsTm6EfETKzo5eM8AatnQWSoipy0YG7k+QaCXg hu0oJI/74xO0JMtMfVyz9R4LwzVjBOpbMnvKBlmtfcMd6XRZBOOAg+0STdGTnov1m07E HYbirInMrl+NHAAR99axd26Iw6mxX/H5xkNEq3m16niCj5reS6ep2v69Vo84UBrmyBmj d2FKu1E5a937MZyZpc7EwImECe8y+pmitsZpHKv3/mxFJQoV9cAF6vVi9RaRYCGaWBjl 7O0obOT9wUqmllWnmCaV5eMj68hHyxUG1/qb3vvTLG/L+O4BPf5JaO4Zhp2fxioedtA5 cpyg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:mime-version :dkim-signature; bh=EN0Mzb6s8Tl+sO9KcM8dEOwC7FeQgGNzUGgSeuHZRDo=; b=x12kNUTSuTc/vSJNG/Unj1My9oUdVC/ZQ66bk/kbWBGsqktehrusGipo9fn+mpN4rr pGaZHsv2YGvVgH+RZy1+Ru+DBnoy76ya7/DlqW+TZIkpSICRzVP9ykaNI/S/fO2uueOn DjirMwAX0fMP08wBpZ4gXEYno2gCF0PFVhnBKFqmcCm1gR0JCSm0KV89yJN1CVG+J9OD yqKpfcAdzFHYTdq4SEK9bHUF+DGMt53FtMXrgM3Z1C4azuj4vuJYMoI1sVEndkLl4Ksb ytdG5XKKJ5wy6c8iAjDoJkty65aXvPbwII3a3raeMKOMAKi5Bq24q92zBbVuQ1VrUqxw 36jA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=QiOwygcd; spf=pass (google.com: domain of stable-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=stable-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id p11si3641500ejo.704.2021.02.08.22.11.03; Mon, 08 Feb 2021 22:11:03 -0800 (PST) Received-SPF: pass (google.com: domain of stable-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=QiOwygcd; spf=pass (google.com: domain of stable-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=stable-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229665AbhBIGK2 (ORCPT + 13 others); Tue, 9 Feb 2021 01:10:28 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46984 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229521AbhBIGKT (ORCPT ); Tue, 9 Feb 2021 01:10:19 -0500 Received: from mail-lj1-x230.google.com (mail-lj1-x230.google.com [IPv6:2a00:1450:4864:20::230]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 2F5BBC06178A for ; Mon, 8 Feb 2021 22:09:38 -0800 (PST) Received: by mail-lj1-x230.google.com with SMTP id b16so5122360lji.13 for ; Mon, 08 Feb 2021 22:09:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:from:date:message-id:subject:to:cc; bh=EN0Mzb6s8Tl+sO9KcM8dEOwC7FeQgGNzUGgSeuHZRDo=; b=QiOwygcdrjYgf/3lDY8pI7Ji34qvamUJReMpjfXTUuvpzEcBEFrIOOiUI8xr04NjZU tpwH6Mnld5gW5qUqlcT9yclH/H8vFgE74ftvEsxScW/+eNUafP6SF28PnC/FqJsK0wXw UALR75hzAWTlMJczQAzJgq1zobcY00uLi654VtOoTCD5qOkMlYDcrFKxsW8nOAxEPNxw WOL5S79DTZlWQCi0Re6jfrDqg034CDDoVLCPh75gl2R1gKqxXAIoqFdBXAS+juaAqs/D U1bhIwdWGgY5hgvpirFgjr7we1NAuDFcJnrmXzAdj0ahBNHgu2U4sqd3h7/I3c4UQTYx DnGQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=EN0Mzb6s8Tl+sO9KcM8dEOwC7FeQgGNzUGgSeuHZRDo=; b=ATnVVV7mIltqtGyEJI1WKqqb2xKKja2W8zMtb36O3PqBugM4gVr7DJUvMkMMiD+cFl z8ATqzmuk5W43aE40nwW8fwEQUpDVnmxh7kQDdf/gBWkm1GYU3Ew7fWp/QBPvcd+X+uG LZfwlukFRhcZC4/LjYYGa/W7jw73qyRAk7zx70Qw16+fcQG/Ytcvv2ESgWDUOqzNE3AJ EgXXTN6ewCFrtxReL52+PG2tYTD8laBirHm7U6usM0DlKfTCwm9EN18gwGphyeLaosSz Km7jlyylGOp5AqR8lALw5LGkubvI7jKDgfcbZt+X8UQsTLGr4FDd3udhXhLzdgsPwOar Dk+A== X-Gm-Message-State: AOAM533+j0yfvw4lvVjVoI2hwXuYCWVJ6vFFxpZHrdCleeFB8ogZswwN OpeYF4pRV51eCxQgb9JnDX5FDygSWNocgDucQ5GGfQ== X-Received: by 2002:a05:651c:c5:: with SMTP id 5mr2207729ljr.480.1612850976581; Mon, 08 Feb 2021 22:09:36 -0800 (PST) MIME-Version: 1.0 From: Sumit Garg Date: Tue, 9 Feb 2021 11:39:25 +0530 Message-ID: Subject: DMA direct mapping fix for 5.4 and earlier stable branches To: hch@lst.de, Greg Kroah-Hartman Cc: m.szyprowski@samsung.com, robin.murphy@arm.com, iommu@lists.linux-foundation.org, Linux Kernel Mailing List , stable , Daniel Thompson , obayashi.yoshimasa@socionext.com Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org Hi Christoph, Greg, Currently we are observing an incorrect address translation corresponding to DMA direct mapping methods on 5.4 stable kernel while sharing dmabuf from one device to another where both devices have their own coherent DMA memory pools. I am able to root cause this issue which is caused by incorrect virt to phys translation for addresses belonging to vmalloc space using virt_to_page(). But while looking at the mainline kernel, this patch [1] changes address translation from virt->to->phys to dma->to->phys which fixes the issue observed on 5.4 stable kernel as well (minimal fix [2]). So I would like to seek your suggestion for backport to stable kernels (5.4 or earlier) as to whether we should backport the complete mainline commit [1] or we should just apply the minimal fix [2]? [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=34dc0ea6bc960f1f57b2148f01a3f4da23f87013 [2] minimal fix required for 5.4 stable kernel: commit bb0b3ff6e54d78370b6b0c04426f0d9192f31795 Author: Sumit Garg Date: Wed Feb 3 13:08:37 2021 +0530 dma-mapping: Fix common get_sgtable and mmap methods Currently common get_sgtable and mmap methods can only handle normal kernel addresses leading to incorrect handling of vmalloc addresses which is common means for DMA coherent memory mapping. So instead of cpu_addr, directly decode the physical address from dma_addr and hence decode corresponding page and pfn values. In this way we can handle normal kernel addresses as well as vmalloc addresses. This fix is inspired from following mainline commit: 34dc0ea6bc96 ("dma-direct: provide mmap and get_sgtable method overrides") This fixes an issue observed during dmabuf sharing from one device to another where both devices have their own coherent DMA memory pools. Signed-off-by: Sumit Garg ret = sg_alloc_table(sgt, 1, GFP_KERNEL); @@ -214,7 +214,7 @@ int dma_common_mmap(struct device *dev, struct vm_area_struct *vma, if (!pfn_valid(pfn)) return -ENXIO; } else { - pfn = page_to_pfn(virt_to_page(cpu_addr)); + pfn = PHYS_PFN(dma_to_phys(dev, dma_addr)); } return remap_pfn_range(vma, vma->vm_start, pfn + vma->vm_pgoff, diff --git a/kernel/dma/mapping.c b/kernel/dma/mapping.c index 8682a53..034bbae 100644 --- a/kernel/dma/mapping.c +++ b/kernel/dma/mapping.c @@ -127,7 +127,7 @@ int dma_common_get_sgtable(struct device *dev, struct sg_table *sgt, return -ENXIO; page = pfn_to_page(pfn); } else { - page = virt_to_page(cpu_addr); + page = pfn_to_page(PHYS_PFN(dma_to_phys(dev, dma_addr))); }