Received: by 2002:a25:c593:0:0:0:0:0 with SMTP id v141csp579274ybe; Fri, 6 Sep 2019 04:11:49 -0700 (PDT) X-Google-Smtp-Source: APXvYqzyBMmDnY1wx67g57UpqvTuZH+jr6Ne7nmQOkHrg9GqoHqOIcP6c13Y9HGPm8LctPQZ0B78 X-Received: by 2002:a62:583:: with SMTP id 125mr10183610pff.69.1567768309293; Fri, 06 Sep 2019 04:11:49 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1567768309; cv=none; d=google.com; s=arc-20160816; b=i+Wkdrih66JeOpmbwqVfrDidBreUqjFj99mRSqy053bPQclCcr/bpVv71uEEsey0Dh UFGsucPW9AOPA9VG/cSXjc/L2yFcRT/Q7MTU8+042yIvYfJlOJ2UACDCsTdrkPfMdGyN +0RItjyOCPKMI65HtEzI8iGgyZi1W8lD2t2ZD/BVPQBWqv/gpnesmwcnleEC5wzH9k1E Zi7iUIL2r/RzFeCZ0NvuyyM5U6AkQ+n3rJO0dFnSLyBGvSVSTNOM+33xNrjTOx4jQOf9 OOtNfChVkPXDXTYFMCGlxiTe0zP8RhxfW2Yybiud+d88FUdEBh3ypG3Cr3mkNqp3gs// tpqQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=ykNWrYekMFyGCAXYkN/pSSACE9rbtE1t4zmKjBlqYqo=; b=vyCQpc3koqOtIgMhEFzngYnhK01T9CQ2f+szgF+Os2JCUXMh7Satof9G7uxRIy9IcU 38dn8Cr5tgW2p3mBGx48M3APXo4+DTGUffH8lzfSngPBP/BadKX0MO4Yr/R9RxF/frm/ sTJ6R+1taCZYSvsnzt6yAxbowCyMUzee7xQOs+z6B8kp85pZQxLa2LCYQ3Sm04wvDmWH 6qAZYQEa2oy2+OkkGr8F7J2n6LTiehLXguDWiyRu6V+9MF6AhA4RUMvL9Rmn6Gr4SQrE 9rjwf0k975MW9Xb0Srx6B24BI00+vR+neu4dR4C8YXNmppZzQhqa5ZR5RxYHu2X2KsVk oN2Q== 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 z142si4760590pfc.80.2019.09.06.04.11.33; Fri, 06 Sep 2019 04:11:49 -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 S2388859AbfIFI4v (ORCPT + 99 others); Fri, 6 Sep 2019 04:56:51 -0400 Received: from mx2.suse.de ([195.135.220.15]:36922 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726936AbfIFI4v (ORCPT ); Fri, 6 Sep 2019 04:56:51 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id AD755AECB; Fri, 6 Sep 2019 08:56:49 +0000 (UTC) Date: Fri, 6 Sep 2019 10:56:47 +0200 From: Joerg Roedel To: Qian Cai Cc: hch@lst.de, iommu@lists.linux-foundation.org, don.brace@microsemi.com, esc.storagedev@microsemi.com, linux-kernel@vger.kernel.org Subject: [PATCH] iommu/amd: Fix race in increase_address_space() Message-ID: <20190906085647.GE5457@suse.de> References: <1567632262-21284-1-git-send-email-cai@lca.pw> <20190905114339.GC5457@suse.de> <1567717041.5576.102.camel@lca.pw> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1567717041.5576.102.camel@lca.pw> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Sep 05, 2019 at 04:57:21PM -0400, Qian Cai wrote: > On Thu, 2019-09-05 at 13:43 +0200, Joerg Roedel wrote: > > But I think the right fix is to lock the operation in > > increase_address_space() directly, and not the calls around it, like in > > the diff below. It is untested, so can you please try it and report back > > if it fixes your issue? > > Yes, it works great so far. Thanks for testing! I queued the patch below to the IOMMU tree and will send it upstream for v5.3 today. Thanks, Joerg From 754265bcab78a9014f0f99cd35e0d610fcd7dfa7 Mon Sep 17 00:00:00 2001 From: Joerg Roedel Date: Fri, 6 Sep 2019 10:39:54 +0200 Subject: [PATCH] iommu/amd: Fix race in increase_address_space() After the conversion to lock-less dma-api call the increase_address_space() function can be called without any locking. Multiple CPUs could potentially race for increasing the address space, leading to invalid domain->mode settings and invalid page-tables. This has been happening in the wild under high IO load and memory pressure. Fix the race by locking this operation. The function is called infrequently so that this does not introduce a performance regression in the dma-api path again. Reported-by: Qian Cai Fixes: 256e4621c21a ('iommu/amd: Make use of the generic IOVA allocator') Signed-off-by: Joerg Roedel --- drivers/iommu/amd_iommu.c | 16 +++++++++++----- 1 file changed, 11 insertions(+), 5 deletions(-) diff --git a/drivers/iommu/amd_iommu.c b/drivers/iommu/amd_iommu.c index f853b96ee547..61de81965c44 100644 --- a/drivers/iommu/amd_iommu.c +++ b/drivers/iommu/amd_iommu.c @@ -1435,18 +1435,21 @@ static void free_pagetable(struct protection_domain *domain) * another level increases the size of the address space by 9 bits to a size up * to 64 bits. */ -static bool increase_address_space(struct protection_domain *domain, +static void increase_address_space(struct protection_domain *domain, gfp_t gfp) { + unsigned long flags; u64 *pte; - if (domain->mode == PAGE_MODE_6_LEVEL) + spin_lock_irqsave(&domain->lock, flags); + + if (WARN_ON_ONCE(domain->mode == PAGE_MODE_6_LEVEL)) /* address space already 64 bit large */ - return false; + goto out; pte = (void *)get_zeroed_page(gfp); if (!pte) - return false; + goto out; *pte = PM_LEVEL_PDE(domain->mode, iommu_virt_to_phys(domain->pt_root)); @@ -1454,7 +1457,10 @@ static bool increase_address_space(struct protection_domain *domain, domain->mode += 1; domain->updated = true; - return true; +out: + spin_unlock_irqrestore(&domain->lock, flags); + + return; } static u64 *alloc_pte(struct protection_domain *domain, -- 2.16.4