Received: by 10.223.185.116 with SMTP id b49csp4972534wrg; Wed, 7 Mar 2018 04:22:18 -0800 (PST) X-Google-Smtp-Source: AG47ELtvYo1VyMqG/u7WN4/oGynuNybK4wKceSlCWwY8z89SKa1f46zu35nZJw5FVHuZcwPPzm04 X-Received: by 2002:a17:902:ab93:: with SMTP id f19-v6mr12914047plr.180.1520425338560; Wed, 07 Mar 2018 04:22:18 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1520425338; cv=none; d=google.com; s=arc-20160816; b=Ug5ipsi9tQ1YJNyxFq8iYo/RtzahcKwWnfQN7KVAhJ1IJ3InuB78WJoFxME5X/kcsQ E3PYxPMzy1r7K1kalUeYOnYaJ2gcwCrUz/piwZHJSvzzP97c+zpP+Q2iQ+LYoPVgljOr Z0j+cVpYzxg672ui/Ktw3PLeh3ZHHbUO7geiudLsWHOI6dO0Kty2cWjH9p9WHxLr623L LACrHaYMIW5EsIoQrb9cdUW/un/QpbajUCtasno1L3VxsoOQtT8JSOz/KCtWDSCZjZLo Wdz72+9Z2/OmOInDzi4p94WZWN9HI/D/WMwEEHoIQBVrpIUFXNBa3vQNfxJPwaFHV5mD SiyQ== 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 :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:arc-authentication-results; bh=ADhYNEeOuZzQVYaFNHJrNxhOLDBm2y2uCnagvohsfts=; b=iz/aHbIzyfFgjD8GrDhMrtLT7QPkja8iWYsE+azNKCI0BvzzueLrVdSeRda0UQplNF b/Q0QN7uyuhyDaiQIYpOy1//NR7wsB40GL3k9P9mIf/E3S95Tzu2Qpomyi+Z3XXUp3Ln enTCrssl3mhTFfNZyODNqraBvs/GtOiydsJJoTMwF75mA0S5B37CgU2SKdXLeSY4KQuN n1XkLFMYqGGPLzB6KYM4x8dOpCagRQ7ZQytzj2i//xFgs4WLkH7qYMsPB469b8YlZyno Mk4kJ6ALf/TqxUi4qUg1tW4KgCVzT047j1pEPI5Z6Y80gNNB1LqnRL6rdet0PW/PMhLU 1pqg== 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 i33-v6si12706650pld.212.2018.03.07.04.22.04; Wed, 07 Mar 2018 04:22:18 -0800 (PST) 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 S1754392AbeCGMUx (ORCPT + 99 others); Wed, 7 Mar 2018 07:20:53 -0500 Received: from usa-sjc-mx-foss1.foss.arm.com ([217.140.101.70]:49608 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754345AbeCGMUu (ORCPT ); Wed, 7 Mar 2018 07:20:50 -0500 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 62DD314; Wed, 7 Mar 2018 04:20:50 -0800 (PST) Received: from [10.1.210.88] (e110467-lin.cambridge.arm.com [10.1.210.88]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 9EA453F487; Wed, 7 Mar 2018 04:20:47 -0800 (PST) Subject: Re: [PATCH v8 1/5] iommu/arm-smmu: Destroy domain context in failure path To: Vivek Gautam , joro@8bytes.org, robh+dt@kernel.org, mark.rutland@arm.com, rjw@rjwysocki.net, will.deacon@arm.com, robdclark@gmail.com, iommu@lists.linux-foundation.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org Cc: tfiga@chromium.org, jcrouse@codeaurora.org, sboyd@codeaurora.org, sricharan@codeaurora.org, m.szyprowski@samsung.com, architt@codeaurora.org, linux-arm-msm@vger.kernel.org References: <20180302101050.6191-1-vivek.gautam@codeaurora.org> <20180302101050.6191-2-vivek.gautam@codeaurora.org> From: Robin Murphy Message-ID: Date: Wed, 7 Mar 2018 12:20:45 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <20180302101050.6191-2-vivek.gautam@codeaurora.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 02/03/18 10:10, Vivek Gautam wrote: > If we fail after initializing domain_context, we should destroy > the context to free up resources. Have another think about why the "problem" this patch caters for cannot ever happen (hint: consider how domain->smmu is used in arm_smmu_init_domain_context()). And then also about the really catastrophically bad problem it actually introduces (hint: "iommu_attach(domain, good_dev); iommu_attach(domain, bad_dev);") Robin. > Signed-off-by: Vivek Gautam > --- > > * New patch added in this series. > > drivers/iommu/arm-smmu.c | 7 ++++++- > 1 file changed, 6 insertions(+), 1 deletion(-) > > diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c > index 69e7c60792a8..ffc152c36002 100644 > --- a/drivers/iommu/arm-smmu.c > +++ b/drivers/iommu/arm-smmu.c > @@ -1223,11 +1223,16 @@ static int arm_smmu_attach_dev(struct iommu_domain *domain, struct device *dev) > dev_err(dev, > "cannot attach to SMMU %s whilst already attached to domain on SMMU %s\n", > dev_name(smmu_domain->smmu->dev), dev_name(smmu->dev)); > - return -EINVAL; > + ret = -EINVAL; > + goto destroy_domain; > } > > /* Looks ok, so add the device to the domain */ > return arm_smmu_domain_add_master(smmu_domain, fwspec); > + > +destroy_domain: > + arm_smmu_destroy_domain_context(domain); > + return ret; > } > > static int arm_smmu_map(struct iommu_domain *domain, unsigned long iova, >