Received: by 2002:ac0:a5b6:0:0:0:0:0 with SMTP id m51-v6csp3496755imm; Mon, 4 Jun 2018 04:42:52 -0700 (PDT) X-Google-Smtp-Source: ADUXVKLbmWfQUxSDnxM1PWT56QEJr9oj+EdK0Pwnws4i33KlncoznThp09E17VxW96de62DCB/q5 X-Received: by 2002:a62:ab0e:: with SMTP id p14-v6mr15259736pff.211.1528112571956; Mon, 04 Jun 2018 04:42:51 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1528112571; cv=none; d=google.com; s=arc-20160816; b=nGSSNr3r7oHeMR4W8hB0heLnRSMR6QTK/XCE0DG3GX1y4YX+bSp5op6BOIEpvV4jk8 iI0mD7oM+uhdWz5SHWKN8Uf+o46J0Or0WDRHrL/F7Urvn0kWIG7uDMDXyLN8+kf5TNUh 7vXwc8v1aCZPPQIampSLlbcdSDVhlUXEr1U/cKhHvGYydkPHRUnjVOKC38UHpEo3w1YA 3bhTY20DN4xDB0uYv2PqHLJFec7PvWu5E3BImuyE43S9JxW5H/fk6yeXyCfzDUxMlZZf Ra9VhYMl3N+YolzxES4p1c8TFJqmgRp1AMXm5v2kqjN0Pc8VtlHEOii3QRm+G8I5ypc2 ARrQ== 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:in-reply-to :mime-version:user-agent:date:message-id:from:cc:references:to :subject:arc-authentication-results; bh=WwT7YtYboVyfI0PmixvQN3hyrqdsAA6x4wWq1Wmm3ac=; b=Sbr+2DGsYb1DyDuKxxKeuisyb+P8FJWUVu636J6EroScndrx3QkUrfqUYAZxJ8rLOi 2AEOsCnHGwghl/55b0gc2/ufu45nyHoE41xh1GHwx2EHw2mjJS8XFz5/MZBoPgQL7C2s A4U5HPMfRSDOrxhmYw3lNvh42C0QXXRvR3iStXRqZwCfg8nkVnZs6QPM3G3Su0LqzSe9 pEPOvf3mNmXsFbfz5520vqRCP5+QKiE8iccYdNHFcOGtFNDesg3N3+Fx4QJaJg/d9IQ1 lEBboV+q12scVKN0ek5OgNcqnIfg2BA2xjXWk9RJmruFX3reZy6JPJ1QEphiwQqLUuL4 7jkQ== 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id o1-v6si36731313pgp.273.2018.06.04.04.42.37; Mon, 04 Jun 2018 04:42:51 -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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752478AbeFDLmQ (ORCPT + 99 others); Mon, 4 Jun 2018 07:42:16 -0400 Received: from szxga07-in.huawei.com ([45.249.212.35]:35392 "EHLO huawei.com" rhost-flags-OK-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S1751482AbeFDLmO (ORCPT ); Mon, 4 Jun 2018 07:42:14 -0400 Received: from DGGEMS403-HUB.china.huawei.com (unknown [172.30.72.58]) by Forcepoint Email with ESMTP id 8FBE511915D90; Mon, 4 Jun 2018 19:42:11 +0800 (CST) Received: from [127.0.0.1] (10.177.23.164) by DGGEMS403-HUB.china.huawei.com (10.3.19.203) with Microsoft SMTP Server id 14.3.382.0; Mon, 4 Jun 2018 19:42:03 +0800 Subject: Re: [PATCH 4/7] iommu/amd: make sure TLB to be flushed before IOVA freed To: Robin Murphy , Will Deacon , Matthias Brugger , Rob Clark , Joerg Roedel , linux-mediatek , linux-arm-msm , linux-arm-kernel , iommu , linux-kernel References: <1527752569-18020-1-git-send-email-thunder.leizhen@huawei.com> <1527752569-18020-5-git-send-email-thunder.leizhen@huawei.com> CC: Hanjun Guo , Libin , "Guozhu Li" , Xinwei Hu From: "Leizhen (ThunderTown)" Message-ID: <5B152573.2080905@huawei.com> Date: Mon, 4 Jun 2018 19:41:39 +0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.177.23.164] X-CFilter-Loop: Reflected Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2018/5/31 21:04, Robin Murphy wrote: > On 31/05/18 08:42, Zhen Lei wrote: >> Although the mapping has already been removed in the page table, it maybe >> still exist in TLB. Suppose the freed IOVAs is reused by others before the >> flush operation completed, the new user can not correctly access to its >> meomory. > > This change seems reasonable in isolation, but why is it right in the middle of a series which has nothing to do with x86? Because I described more in the previous patch, which may help this patch to be understood well. You're right, I will repost this patch separately. > > Robin. > >> Signed-off-by: Zhen Lei >> --- >> drivers/iommu/amd_iommu.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/drivers/iommu/amd_iommu.c b/drivers/iommu/amd_iommu.c >> index 8fb8c73..93aa389 100644 >> --- a/drivers/iommu/amd_iommu.c >> +++ b/drivers/iommu/amd_iommu.c >> @@ -2402,9 +2402,9 @@ static void __unmap_single(struct dma_ops_domain *dma_dom, >> } >> if (amd_iommu_unmap_flush) { >> - dma_ops_free_iova(dma_dom, dma_addr, pages); >> domain_flush_tlb(&dma_dom->domain); >> domain_flush_complete(&dma_dom->domain); >> + dma_ops_free_iova(dma_dom, dma_addr, pages); >> } else { >> pages = __roundup_pow_of_two(pages); >> queue_iova(&dma_dom->iovad, dma_addr >> PAGE_SHIFT, pages, 0); >> > > . > -- Thanks! BestRegards