Received: by 2002:a05:7412:2a8c:b0:e2:908c:2ebd with SMTP id u12csp3198650rdh; Thu, 28 Sep 2023 05:42:59 -0700 (PDT) X-Google-Smtp-Source: AGHT+IG2iMj6+WljbAvAYqhvbdyh9ytEB3mVzmCpCnvJ8gx0Wx1yJQPhfJTS9AtLwHQA++UCOZIP X-Received: by 2002:a1f:cc41:0:b0:486:e696:c69a with SMTP id c62-20020a1fcc41000000b00486e696c69amr940687vkg.16.1695904979484; Thu, 28 Sep 2023 05:42:59 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1695904979; cv=none; d=google.com; s=arc-20160816; b=q5O5trLsOnbf9HuokwDrlyB1HOLagoEE0ia5q15rR7MzJqNaib1CNil4HNCr/gg6Xw f+i0+nlsYaVEwchSwSO6smENyGkAsVSFPVfRBCCKNTvV/2aGGT81lkiEozB6VBAyDwJB f8gbkc4AbN5L/PQyE2exZEsZo5r6MnYp9giKzQz7OxI6SuBV/4rjC2O1STtwyZv5nl+R r+bnyRlqPRgEmW92HjSbxoRkaTPPOnZeWb62WneIkCdYjwJNMF5yNUvUBU78/yrP3YNF eELnnEZLP9vXKjzTFkvQFTnaaLkKQsJsrVbI6DzmbGQ4QyHkaWMo1j/Bi5CdflKuJruh Nc4A== 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:to:content-language:subject:cc:user-agent:mime-version :date:message-id:dkim-signature; bh=kvV1gscpkLoseff93SE/GIpaEMsivUtezhwWCAO3DjA=; fh=YoHMEKao3yo8G1uRvgR6iqn+WyfPu7Afz28jLs6JlNY=; b=b34VQWe+4hd5104PnPifmpoN9o7TeXmk+B01cpHZWf0lF9gjzT5iAqPQ+l/r9Y+zJQ CWAA43mTPKdc0y2gYhNtAO3LWdgsZhgEIT1yqyjAuIfXb032m7fWXSD1AKxvrFjhb4h+ mWFwarelnMQIL8bFsCeNgmPyd4DOg5GC0Idtc8GwacDpIAAHW23WkvwLebjvsk4Ysg1k Dx5Z8+bY2sJA4e3IsKBMM+TkTT2MgE4NYf2QC56Kn8W4e7LTJcz7RI2Cjlmo98Uol0ua VuL65+/pz9Dw4klW/OKDwPwZFGeACwn5hyUSzsDPFEp1dMHy0b8THmdvoyK+DrQ2Ns0E kOzw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=cMa9fL5f; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:5 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from groat.vger.email (groat.vger.email. [2620:137:e000::3:5]) by mx.google.com with ESMTPS id x42-20020a056a0018aa00b0068e2b1d5651si19891004pfh.281.2023.09.28.05.42.59 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 28 Sep 2023 05:42:59 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:5 as permitted sender) client-ip=2620:137:e000::3:5; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=cMa9fL5f; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:5 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by groat.vger.email (Postfix) with ESMTP id 706D1807C7D5; Thu, 28 Sep 2023 02:25:49 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at groat.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231717AbjI1JZ0 (ORCPT + 99 others); Thu, 28 Sep 2023 05:25:26 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46510 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231697AbjI1JZK (ORCPT ); Thu, 28 Sep 2023 05:25:10 -0400 Received: from mgamail.intel.com (mgamail.intel.com [134.134.136.24]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 0FCC81AB for ; Thu, 28 Sep 2023 02:25:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1695893107; x=1727429107; h=message-id:date:mime-version:cc:subject:to:references: from:in-reply-to:content-transfer-encoding; bh=R2aE8j4JYfqblhnvS1c2OlVELJZE0JvEb7YhQhBXfYs=; b=cMa9fL5fVQnIn6ZdHB3maWHjAXm0mv7+5R1W6w4SGDfv10W1uToB8RH+ GxLGOOgpvVGjfNZv70tq4cqqkJ/ALTQ0iSDjK6p8ugaSINu3H+xf9BOvT yZHta4BjTdlg4OjIE4bxgXuxDLYYSqyGXnqN/+9PM94UcP31A3M0G2b3h oMUyT8FylfGsb2vw1eKtNZsBhvBwbVq4xkEt68ceSSydxY+Q2RqvETcb4 a4VMfs396CM+HspyQx7Eme/Bms5mJ0eBbCNet1eSv5Bu7pNt8TDJF+mt9 w8CEFaU795hl26H88rC+lKlzC35ouyiHoGz18+6+YCbdvdh3dSRO7Ol2H g==; X-IronPort-AV: E=McAfee;i="6600,9927,10846"; a="384818207" X-IronPort-AV: E=Sophos;i="6.03,183,1694761200"; d="scan'208";a="384818207" Received: from orsmga006.jf.intel.com ([10.7.209.51]) by orsmga102.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 28 Sep 2023 02:25:06 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10846"; a="726169101" X-IronPort-AV: E=Sophos;i="6.03,183,1694761200"; d="scan'208";a="726169101" Received: from blu2-mobl.ccr.corp.intel.com (HELO [10.254.215.143]) ([10.254.215.143]) by orsmga006-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 28 Sep 2023 02:25:04 -0700 Message-ID: Date: Thu, 28 Sep 2023 17:25:02 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.15.1 Cc: baolu.lu@linux.intel.com, joro@8bytes.org, will@kernel.org, robin.murphy@arm.com, jgg@nvidia.com, iommu@lists.linux.dev, linux-kernel@vger.kernel.org Subject: Re: [PATCH] iommu: Sanity check on param list for iommu_get_resv_regions Content-Language: en-US To: Dawei Li References: <7c7b8981-022c-2fa8-7ee5-9c97d8e17862@linux.intel.com> From: Baolu Lu In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.2 required=5.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on groat.vger.email Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (groat.vger.email [0.0.0.0]); Thu, 28 Sep 2023 02:25:49 -0700 (PDT) On 2023/9/28 16:57, Dawei Li wrote: > On Thu, Sep 28, 2023 at 09:33:29AM +0800, Baolu Lu wrote: >> On 9/27/23 10:25 PM, Dawei Li wrote: >>> In iommu_get_resv_regions(), param list is an argument supplied by caller, >>> into which callee is supposed to insert resv regions. >>> >>> In other words, this 'list' argument is expected to be an empty list, >>> so make an explicit annotation on it. >>> >>> Signed-off-by: Dawei Li >>> --- >>> drivers/iommu/iommu.c | 9 +++++---- >>> 1 file changed, 5 insertions(+), 4 deletions(-) >>> >>> diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c >>> index 1ecac2b5c54f..a01c4a7a9d19 100644 >>> --- a/drivers/iommu/iommu.c >>> +++ b/drivers/iommu/iommu.c >>> @@ -813,7 +813,7 @@ int iommu_get_group_resv_regions(struct iommu_group *group, >>> mutex_lock(&group->mutex); >>> for_each_group_device(group, device) { >>> - struct list_head dev_resv_regions; >>> + LIST_HEAD(dev_resv_regions); >>> /* >>> * Non-API groups still expose reserved_regions in sysfs, >>> @@ -822,7 +822,6 @@ int iommu_get_group_resv_regions(struct iommu_group *group, >>> if (!device->dev->iommu) >>> break; >>> - INIT_LIST_HEAD(&dev_resv_regions); >>> iommu_get_resv_regions(device->dev, &dev_resv_regions); >>> ret = iommu_insert_device_resv_regions(&dev_resv_regions, head); >>> iommu_put_resv_regions(device->dev, &dev_resv_regions); >>> @@ -1061,12 +1060,11 @@ static int iommu_create_device_direct_mappings(struct iommu_domain *domain, >>> struct device *dev) >>> { >>> struct iommu_resv_region *entry; >>> - struct list_head mappings; >>> unsigned long pg_size; >>> + LIST_HEAD(mappings); >>> int ret = 0; >>> pg_size = domain->pgsize_bitmap ? 1UL << __ffs(domain->pgsize_bitmap) : 0; >>> - INIT_LIST_HEAD(&mappings); >>> if (WARN_ON_ONCE(iommu_is_dma_domain(domain) && !pg_size)) >>> return -EINVAL; >>> @@ -2813,6 +2811,9 @@ void iommu_get_resv_regions(struct device *dev, struct list_head *list) >>> { >>> const struct iommu_ops *ops = dev_iommu_ops(dev); >>> + if (WARN_ON(!list_empty(list))) >>> + return; >> I don't understand why the input list*must* be empty. This interface > Because @list is an output-only argument, which is supposed to be filled > by caller(inserting elements into it). If it's not empty, it's an inputing > argument, in which case caller will take existing node (in @list) into account, > and insert new nodes before/after them. > Please lemme put it another way, if list argment is not empty: > > Before calling: > list: head->A > > After calling > list: head->A->B->C > > It will confuse caller cuz it can't tell whether A is a valid returned > by callee. I see. Thank you for the explanation. Best regards, baolu