Message ID | TYTP286MB35645FDEF45FDFC91D35CE1ECAC2A@TYTP286MB3564.JPNP286.PROD.OUTLOOK.COM |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:cae8:0:b0:403:3b70:6f57 with SMTP id r8csp2696463vqu; Wed, 27 Sep 2023 08:10:01 -0700 (PDT) X-Google-Smtp-Source: AGHT+IH/+mOwDA2wUdzbWL2K0sMtTc0u20Pr02lYFIUMnFaqoS7iW5HaDlmVpaAaiWxfGWedUdnX X-Received: by 2002:a05:6a20:8f1a:b0:13d:5b8e:db83 with SMTP id b26-20020a056a208f1a00b0013d5b8edb83mr2583979pzk.9.1695827400946; Wed, 27 Sep 2023 08:10:00 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1695827400; cv=pass; d=google.com; s=arc-20160816; b=difPz+QiCtFqgomBj/ROjNTD95e0Odss0SZwYjPBlbuSdwQQ2jXJyk4V5njz1R7gUl PqJ1uaaIPs9/njgRv0DfjZ1Q06OkN8VcMNqwxgyE3y2WElWr10kIcB/vvsi5tndeS3O+ S7Nrj5wyMBtwlP+gowWjZ3TnMplbDuN6vxFMDIApY7drRLf0+UhtVkw+DOL0WOJAuZGl 5E0pn3KpYXgzL+ixLuipPNinTuOr8x3JNs92GUOP7lWCMHjKlHCbbvcIsXz8IuFQylgm Zg3ahsZepFfunhh6lv31dyZdyAmo4ipqnYtEb0ySAleyCwkIX4hU4lkytr6/Hg2S3fu7 f4RQ== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:content-transfer-encoding :message-id:date:subject:cc:to:from:dkim-signature; bh=xLubrLAF8F8iFpdG1xw+fKj7eghrW9TtzkA2ictIvrg=; fh=GJegKu6W1TFiBMV+/VdaK0qooo/5U7likG8jaZcO2a0=; b=d+IndxgLcum3Jz3K70Fst3u1c5iWZ/VaKqfxgI+/vfdMS0Pl1s7/0tqVmw+RxADI5V ZnvEqCurESQ/RZDPfFI16u6fd4u7l0aLk+VYFFDNNTY/GXXqcIwQmtMbBs8gisWEJust pHU9Wg7E35udMWWSyvfi9oBxDHRvMIH+NIEMQk7z2TI0p4eywcLBMvDq/HMJHb86W31e laIi/nQcd3BYQK8UK75K7DlRR4Abu9BxrI/XTLeEf6fMJ7DPYnqPZ7XEUHa+1djfXOMR vPyxteJTpiDVRkAi6ojWVRfWxL67tAHS58YnWZK9qB49D9UjKCVWWsFHtzuJ30N0yTEJ J0JA== ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@outlook.com header.s=selector1 header.b=L2RoHXfs; arc=pass (i=1); 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=QUARANTINE dis=NONE) header.from=outlook.com Received: from groat.vger.email (groat.vger.email. [2620:137:e000::3:5]) by mx.google.com with ESMTPS id 126-20020a630284000000b00565f611a1f8si15306745pgc.263.2023.09.27.08.10.00 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 27 Sep 2023 08:10:00 -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=@outlook.com header.s=selector1 header.b=L2RoHXfs; arc=pass (i=1); 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=QUARANTINE dis=NONE) header.from=outlook.com Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by groat.vger.email (Postfix) with ESMTP id C1B7F80A4154; Wed, 27 Sep 2023 07:26:00 -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 S232045AbjI0OZn (ORCPT <rfc822;ruipengqi7@gmail.com> + 21 others); Wed, 27 Sep 2023 10:25:43 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46886 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232011AbjI0OZl (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Wed, 27 Sep 2023 10:25:41 -0400 Received: from JPN01-TYC-obe.outbound.protection.outlook.com (mail-tycjpn01olkn2091.outbound.protection.outlook.com [40.92.99.91]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 2580D19E for <linux-kernel@vger.kernel.org>; Wed, 27 Sep 2023 07:25:38 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=VZrwJ+NH1z3OwszniPybXUFD1f7zlpg53NeAwxq5WeA6nVcXRi9yn9Rp5HDHvTKpbK4hrj0oP+vWOnDGj8yDh/3pJLyXm5OmeV1nbcTqYKulLGOimBOlMYZeusIqa+zE8/A9zZosDnXqH7ZKadwC6NwqX9j9r9VCyJyZ1hCwFu5/bIRpd4UJ89BzANCIsX9dWVsenoTpferVwNIlQqZUkEuZBb5euJbX4+AS8xMmkWv6QXlKnNdTqv81S5Qapb15yHUni4qzDg5pRcWuomKDgeRGJzCpQbweg3TUO5m+f8I57vYbDV7F0bdP7+9eG9DlAEDAsTaoCOkQmEAj011/9A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=xLubrLAF8F8iFpdG1xw+fKj7eghrW9TtzkA2ictIvrg=; b=k9DnqpmO5P0R7z9WQaso7PRLMdR+O4RmgRV+Nxyt88Etbxz/TvNYAG9PP5HBai2m4eDWwA4+Vek3BVY+JtflY8DFqn5TQeGSkQy4uCrMDAlDu71cFybNyyGxH50ADIPQlW7m7BhmYC741E0FmcsTFOai4A9a/ZXJXM5/m/b6de1Bbov1ksiA+OuObFaHg8YycTyezoyJws4TqcnreRmyq6mu65yWg4nUkaaOqT6ZntrCG+HRO9Vh1Gkfhy6vG0i3qv/tUuCZ0M+avBnwxEM/cmmB9Nz4eExs849/YAHvndjzNLgJW8d8+LZbfu8cy/zBCGYXrK31EyPCZYnuBzvSmw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outlook.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=xLubrLAF8F8iFpdG1xw+fKj7eghrW9TtzkA2ictIvrg=; b=L2RoHXfsus5CGgxIbQHSVd7jB6PHdPj6DWmNA+MCjnaPGgvKaIQAxQvyR83l9nRXitl6sgcjjcI4nGIHyXqrFfS2A8nObgshu5wuc2/z+8Ufy53p/44eGKlNcy4pXzyZI31cughGsLaUsL4uvVnq50zbYrALjuz2lSZ2at36Hf7k2u5qzn1BIwhrKp77RWqMqIrOMDZ1KcoSPfWw1GSZ1+15F7LRnHVegYF3tf0DLNloeFW9F/ZfAjjnQPMEDlOXnrqJtn4jNgiiz+3jAA+ob01bYC136Sr8fKjQPwnDSadszTmlMVv9BaPtZ5bcteM8xeEiMhnTAUQvuVXk90x2fQ== Received: from TYTP286MB3564.JPNP286.PROD.OUTLOOK.COM (2603:1096:400:39d::8) by TY3P286MB2771.JPNP286.PROD.OUTLOOK.COM (2603:1096:400:257::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6838.19; Wed, 27 Sep 2023 14:25:35 +0000 Received: from TYTP286MB3564.JPNP286.PROD.OUTLOOK.COM ([fe80::ee22:5eba:da74:7c25]) by TYTP286MB3564.JPNP286.PROD.OUTLOOK.COM ([fe80::ee22:5eba:da74:7c25%7]) with mapi id 15.20.6838.016; Wed, 27 Sep 2023 14:25:35 +0000 From: Dawei Li <set_pte_at@outlook.com> To: joro@8bytes.org, will@kernel.org Cc: robin.murphy@arm.com, jgg@nvidia.com, iommu@lists.linux.dev, linux-kernel@vger.kernel.org, Dawei Li <set_pte_at@outlook.com> Subject: [PATCH] iommu: Sanity check on param list for iommu_get_resv_regions Date: Wed, 27 Sep 2023 22:25:01 +0800 Message-ID: <TYTP286MB35645FDEF45FDFC91D35CE1ECAC2A@TYTP286MB3564.JPNP286.PROD.OUTLOOK.COM> X-Mailer: git-send-email 2.25.1 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-TMN: [f9PMvWYya170/TBFzH72aac6/QRDkiGe] X-ClientProxiedBy: SG3P274CA0019.SGPP274.PROD.OUTLOOK.COM (2603:1096:4:be::31) To TYTP286MB3564.JPNP286.PROD.OUTLOOK.COM (2603:1096:400:39d::8) X-Microsoft-Original-Message-ID: <20230927142501.33287-1-set_pte_at@outlook.com> MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: TYTP286MB3564:EE_|TY3P286MB2771:EE_ X-MS-Office365-Filtering-Correlation-Id: a0293fee-7527-4a02-d881-08dbbf659d21 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: jRutR2T7uaR1RJNSp5v2Uyf0BTb2vRD5zWv8giUdnBJto6Iy95C0pdByy5pilxsJTguWclfjWp/EAeVGqwZWMdxBKjpyFtF4Z4eAcrXnvEEzYg7Dc/JzeYcMKKJyhgwFYFMssDC8onWw9ZIV+xZ8Ge1nDj0fjww0sGMO8jmr0cTvlrDszikAy+5YDw2RrHAPqKQ5cFrgsXPlvzRnFmUdSMnYJb+MU0rdfionnkZ0BrNKgoFc18teqRvoKFTKXy5G5963rpUgDZOVy6zzYeEs4NjMwMtctNRVgrW3vgXGMo2Ivm7Uv5FiiiXN9dBBV9vC8Iu1Jq0Wfnn43Pt+Xx1YRBqwPMWxSymJ3J4RKkcnc3AQShebPjwP5eZccQ+bN/yg2yGXhVyOZTXZQI20CI7m3pv7urrhJ98UqWI1fzgbMLXsiPfxPWoN+j+/ioLjPyVqnjXq0jzO7pMnDM4BXtuIPWJzOIE9BKBwxqmPjoO6zzXzd5oxDSm9HQpHrlp+6CEW3gK2FwtwexEwyPVBaAyTjhZ5bdWdh27wbaJcBbxytLo2S3fTh3ZmT5I9ayGGX2+Th4wG370ZlzYWMl/SpWuGJbuSLKSibhPECjoI1HR008xuYTA2LPdDUgDRVlDg+JX9 X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: bikK3bzAU4uyAcI0J4DotFwbUdio2GWKen5TwPYrtU/nmrGTTUqtmoLAVdMTqc2BqgSfzelkcZvEI1NNbt4FOPvaxGPTxQBnXNQKhnFLaXa81+VQynVqRRO9vjqb+LpZTW/JjKQFH982C1AjlB57ajZ7MEqmc1gFZaMwF8L/kX/541ZfM2VY67czWSksKlak/TnVRHjNU9XFvrWfzGCdeVN1TC1/NdjhCPyvI8LOgYwNjRBDogwqSBajeHFhernItTsQLM58O5hseQf4haaOZQ9c6qewuy2oIISzQCWRwQU2h4TFkJBSDhseQQ++RLHrUZIml59ar5lwYK5/UKlz0CKGJlPZAr1YGVJdv245yG0QZw0vX6hUFTWcpf85kdalxxVlWDIBXz5B5zfg//uUEpPPcZZy8L/1xxCaIz52SEd8jr6fc3MYxNQtSS7QUp+vdDaUaxC1wW1Vh0p2IMDkYPkohhZFW82aREB9heM7M0HkkC1wquUA8B8rOQErysIb2rbQoNivk5RcUjTeEuyTmzJ+uj4gvgqtj+DjyXSnzj50+gjkBBI6llTyhHdTGf15bAE5Jlop8Y8dTE3mJIHR/grIJXsvG5c5BPml8yo4D5TylHMB5avFjNjMDqpkzN2Ywhz8Spn6xpPAXYmYvvDe4kyaUIvCf902a3nYg1N5wNgMEqwN3sYZDuTNfyA9cr+yHUO9/rh4N8IIhJaF/zNj8Z6tqxX/4gcul4uuLiJ68qWQZ5dEWOHy1JjNb0PzGaA0Gvgm6qsJkbf4Bb2dSGQW4QGS1IKSDEAeSQSgxnUwOW8m7+gy4pCdNQmyhhDlit96T0BNWVvDO2HbxGWdw9oo4zYyO6ELMHd1y3Gh/d2Tm8H3SSVxjv9JjCDeCQNDB38b4KDq1FzZ4x3CyELb1uDmgvw6wDuHLNNIh55YOuUI/8muJlEs//h4y77DJ6PNUF8OwlfeJGBBP/MHBhzun0SIkQXq3njNgFvBBLAUbmhHKitjYpq64mMpM0mHx4g9zTbxN3Ymynmbxr8oqpOxtScLVjicS61q9Nvj9upl7e4MWe96aO6LixjuMxkiE0Hb/PMsvHTCHovXPOyfkg/Cx54JPAzt2b/CCyHECDFYU3MtCrNhGUmZuTQ1us+O+7A2zK9GCKlRydZ3iJm6zFPRGP9B3B/ZfEzMdOBygIRSHbwQQ9xtql4hKLMvLBLC8yocumDTChkJe/Ztg+8siippkMkuiA== X-OriginatorOrg: outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: a0293fee-7527-4a02-d881-08dbbf659d21 X-MS-Exchange-CrossTenant-AuthSource: TYTP286MB3564.JPNP286.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Sep 2023 14:25:35.5952 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-Transport-CrossTenantHeadersStamped: TY3P286MB2771 X-Spam-Status: No, score=-0.6 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,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: <linux-kernel.vger.kernel.org> 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]); Wed, 27 Sep 2023 07:26:00 -0700 (PDT) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1778203912542194180 X-GMAIL-MSGID: 1778203912542194180 |
Series |
iommu: Sanity check on param list for iommu_get_resv_regions
|
|
Commit Message
Dawei Li
Sept. 27, 2023, 2:25 p.m. UTC
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 <set_pte_at@outlook.com>
---
drivers/iommu/iommu.c | 9 +++++----
1 file changed, 5 insertions(+), 4 deletions(-)
Comments
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 <set_pte_at@outlook.com> > --- > 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 has already been exported, so please update the comment to explain this new requirement. > + > if (ops->get_resv_regions) > ops->get_resv_regions(dev, list); > } Best regards, baolu
Hi, Thanks for reviewing, 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 <set_pte_at@outlook.com> > > --- > > 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. > has already been exported, so please update the comment to explain this > new requirement. > > > + > > if (ops->get_resv_regions) > > ops->get_resv_regions(dev, list); > > } > > Best regards, > baolu
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<set_pte_at@outlook.com> >>> --- >>> 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
On 2023-09-28 09:57, Dawei Li wrote: > Hi, > Thanks for reviewing, > > 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 <set_pte_at@outlook.com> >>> --- >>> 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 Yeah, the commit message really doesn't make much sense :( > 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. If a caller would be confused by appending to a non-empty list then that caller should avoid passing a non-empty list. But that's not the API's problem; in general, appending to non-empty lists is absolutely a valid thing to do, it's kind of the point of using a list rather than, say, returning an array. It seems entirely reasonable that a caller might want to collect the reserved regions for multiple groups into a single list for its own convenience, and we have absolutely no reason to disallow that. Note also that your arbitrary input vs. output argument rule fundamentally couldn't work for this API, since actual implementations of ops->get_resv_regions already *do* build up the list by passing it around multiple different helper APIs internally (look at the call path through arm_smmu_get_resv_regions(), for instance). Thanks, Robin. >> has already been exported, so please update the comment to explain this >> new requirement. >> >>> + >>> if (ops->get_resv_regions) >>> ops->get_resv_regions(dev, list); >>> } >> >> Best regards, >> baolu
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; + if (ops->get_resv_regions) ops->get_resv_regions(dev, list); }