Received: by 2002:a05:6358:bb9e:b0:b9:5105:a5b4 with SMTP id df30csp4580529rwb; Tue, 6 Sep 2022 09:24:50 -0700 (PDT) X-Google-Smtp-Source: AA6agR7CPzh9IFv8KsENj9oBwplY+GB3EYwFgzwYmlUf4ZAvvqn9b62HJ3XioHNhwzYeDwzLm+Sg X-Received: by 2002:a17:90a:bf18:b0:200:8a12:d7ad with SMTP id c24-20020a17090abf1800b002008a12d7admr7293315pjs.243.1662481490282; Tue, 06 Sep 2022 09:24:50 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1662481490; cv=none; d=google.com; s=arc-20160816; b=sQP0U1r7Cbq6aPlTAVypxty8LKGZDXTsGCOFD/YPMbONMNG81otfy8MCwPgMhU8/RI d4TXn1aPbo309Y1GFu+Sd5J44zn9egSVl0J6xxnk+6Z/7H1ehKxnhF6RG5fGc19RqWie wZ+UcWKoIcjq8ljwhPbtJKw7OvAbRIrTHGraeazQcuJb8Q12Y9qzX4ZdYVD5oKQojCHV fM+luLw4YtfSfIVvzuG1rqnDDXQ+gjCWelpbT43aSRV1Ig+MN+EBjgBRCbCpDolhdTsu 2EqyhOIYGUF2V8TioDA2GzQTjW7zZWAmPJfYom9ApDJgmWjrxguSeux0MLnJjrkOhKi3 gp0w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to:from :references:cc:to:content-language:subject:user-agent:mime-version :date:message-id; bh=BxtJRUtW0fMpkuj8t/JGZRPNVqpjR/ahMM0nN8/N2Dw=; b=tuN5iZ2TijwEpH/mpJpUceTvIiIFQGoWis2WN5fDVqzKOYC5u5qQHC8lf3/PnEGcjs vtw7jUn7uO9KT1c1QtStKhUa65kCWPteny4pppEXrgHUWgPdztU5Z3kxzM8cMHSqfB/e lBto66BgaWHkZYTaSUEEIE73XgFmyPZmGHB1SygRtX1O3AFAMROnSndKYaTMAny3UmUd TwjHuq2OxN1MezMDQxCktPz0eeVxKmlgOE6UvaqMb2+/1B9HP37J4rWj12GIZgdk9Wkn W58qi7vUckMkC1QqqB42wzYhfxwiXhbTHJINJ0xnzHwa2FHY1TprG/zhYGN9SfRyMjFu ivmg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id f10-20020a63de0a000000b0042a3636816fsi15597351pgg.168.2022.09.06.09.24.37; Tue, 06 Sep 2022 09:24:50 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233972AbiIFQJO (ORCPT + 99 others); Tue, 6 Sep 2022 12:09:14 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47134 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S239348AbiIFQIx (ORCPT ); Tue, 6 Sep 2022 12:08:53 -0400 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 4A543101DF for ; Tue, 6 Sep 2022 08:33:53 -0700 (PDT) Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id C88F3139F; Tue, 6 Sep 2022 06:37:30 -0700 (PDT) Received: from [10.57.15.197] (unknown [10.57.15.197]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 437753F7B4; Tue, 6 Sep 2022 06:37:23 -0700 (PDT) Message-ID: <555fa5aa-a575-d783-dc97-79f63dcf2f57@arm.com> Date: Tue, 6 Sep 2022 14:37:18 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; rv:102.0) Gecko/20100101 Thunderbird/102.2.1 Subject: Re: [PATCH v2 1/2] iova: Remove some magazine pointer NULL checks Content-Language: en-GB To: John Garry , Ethan Zhao , joro@8bytes.org, will@kernel.org Cc: iommu@lists.linux.dev, linux-kernel@vger.kernel.org, linuxarm@huawei.com References: <1662369083-238529-1-git-send-email-john.garry@huawei.com> <1662369083-238529-2-git-send-email-john.garry@huawei.com> <1d80f56c-bef7-6e5f-0bca-dad35f5e5a8e@linux.intel.com> <3fa23318-6fa7-eba0-30b8-1fb71e6c327e@huawei.com> From: Robin Murphy In-Reply-To: <3fa23318-6fa7-eba0-30b8-1fb71e6c327e@huawei.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-8.7 required=5.0 tests=BAYES_00,NICE_REPLY_A, RCVD_IN_DNSWL_HI,SPF_HELO_NONE,SPF_NONE,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2022-09-06 11:50, John Garry wrote: > On 06/09/2022 10:28, Ethan Zhao wrote: > > Hi Ethan, > >>> Signed-off-by: John Garry >>> Reviewed-by: Robin Murphy >>> --- >>>   drivers/iommu/iova.c | 7 ++----- >>>   1 file changed, 2 insertions(+), 5 deletions(-) >>> >>> diff --git a/drivers/iommu/iova.c b/drivers/iommu/iova.c >>> index 47d1983dfa2a..580fdf669922 100644 >>> --- a/drivers/iommu/iova.c >>> +++ b/drivers/iommu/iova.c >>> @@ -661,9 +661,6 @@ iova_magazine_free_pfns(struct iova_magazine >>> *mag, struct iova_domain *iovad) >>>       unsigned long flags; >>>       int i; >>> -    if (!mag) >>> -        return; >>> - >> >> iommu_probe_device >>    ops->probe_finalize(dev); >>      intel_iommu_probe_finalize >>         iommu_setup_dma_ops >>           iommu_dma_init_domain(domain, dma_base, dma_limit, dev) >>             iova_domain_init_rcaches >>               { >>               ... >>               cpu_rcache->loaded = iova_magazine_alloc(GFP_KERNEL); >>               cpu_rcache->prev = iova_magazine_alloc(GFP_KERNEL); >>             if (!cpu_rcache->loaded || !cpu_rcache->prev) { >>                  ret = -ENOMEM; >>                        goto out_err; >> >> Do you mean iova_magazine_alloc() is impossible to fail ? > > No, iova_magazine_alloc() may fail and return NULL. But if it does then > we set iovad rcache pointer = NULL in the error path and don't use the > rcache. > > However we have a !iovad->rcache check on the "fast" alloc but not > "insert". I need to check why that is again. Right, if you find a good reason to respin the patch then perhaps also tweaking the commit message to clarify that it's impossible to have a NULL rcache *at any point where those checks are made* might avoid all possible doubt, however I'd hope that it's clear enough that the transient case while iova_domain_init_rcaches() is in the process of failing really doesn't need consideration in its own right. I guess the check in iova_rcache_get() was maybe with the intent of allowing alloc_iova_fast() to seamlessly fall back to standard allocation, so an API user can treat iova_domain_init_rcaches() failure as non-fatal? That makes a fair amount of sense, but does mean that we're missing the equivalent in iova_rcache_insert() for it to actually work. Or we just remove it and tighten up the documentation to say that's not valid - I would like a way to make rcaches optional in iommu-dma for systems where they're a pointless waste of memory, but we can always revisit this when we get there. Cheers, Robin.