Received: by 2002:ad5:4acb:0:0:0:0:0 with SMTP id n11csp3918369imw; Thu, 7 Jul 2022 09:34:37 -0700 (PDT) X-Google-Smtp-Source: AGRyM1sNzcLjEOtUQavgzleUnIYB6EYVEcIcV8oXN15U2llCIRBVLP5PT7XD4oANVcdz3fPAbD7k X-Received: by 2002:a17:906:3f49:b0:722:e1d2:f857 with SMTP id f9-20020a1709063f4900b00722e1d2f857mr46320981ejj.15.1657211677284; Thu, 07 Jul 2022 09:34:37 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1657211677; cv=none; d=google.com; s=arc-20160816; b=w5WXnr1QSj8rsT2dLr1KPedaX5Qj3yx7J4LHNEMSxzKowHUeo0JEXN8MR/t4thMKDm fK1T4jm1T5p8bXOQ+t+X4EGJB+n9msLpGi76V/kDab393O0BxCWRorgspHjl9h4WUxdS McXm4lWzCQAy6rO1N6GfXfNKqVXHqA9UzYoITOtBybrH1MDmxpWPcoRVPzdHt3rd3ZZG rIkckXUV3ke46tLvJGuV3BVC0hWBwdXAg/P1JIS6mevdIpvrdOht+v/mSorKgeGupFpP uJMGqQiKwm8l+OmKUb2DXQkF0vJn78oGagO1bEwTovDW9l26pvUqrA9gWTsLQOF3kjAC cJHQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :message-id:subject:cc:to:from:date:dkim-signature; bh=7PUowsZ6B3mpLhhIpW8FlAP+zQ3WgtmULxZkHw5XzJ4=; b=1JXUBfI2RNhuKTTVT7SslKd4hthVyBY1DiUAKSdAU13ul/6a4yavkYnkkn6bMCI9lv kWgOYNyEErfgA1Sc1iCV/FFig+FB+UDeaVpmdfToXg7AoPpPetBUE9eNC5Tx9yPd/85U g8RNhgOsVWy+kFS4JTP5U3O+KXorp6lDCS1dVcLGh7hzwq9xkkCoIErUwhX7hOXy4juu ITGOwiTgqJg/Ds0+q49MyRdShCiFBHvL1FpHV7u34k03ZmhgeQ8MKJodbPMyuXMRRGcP JjoSn19a5OcJQzMjXGt5llTzHGXe25zuE9u38y4pTKxYt1ZiL6PstEDUMPmBIfd/1XHy ThEw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=jmK0c+vy; 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=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id k11-20020a170906054b00b0072affa39083si495813eja.23.2022.07.07.09.34.11; Thu, 07 Jul 2022 09:34:37 -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; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=jmK0c+vy; 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=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236115AbiGGQME (ORCPT + 99 others); Thu, 7 Jul 2022 12:12:04 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46848 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235953AbiGGQLj (ORCPT ); Thu, 7 Jul 2022 12:11:39 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 97FE433350; Thu, 7 Jul 2022 09:10:50 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 347E0623E2; Thu, 7 Jul 2022 16:10:50 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5D6AAC3411E; Thu, 7 Jul 2022 16:10:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1657210249; bh=9Rh396CKXH0FuHlZMYkM5a1yPWoX1HChEl9dRmBJAm0=; h=Date:From:To:Cc:Subject:In-Reply-To:From; b=jmK0c+vyGAqHN6jPfTbrSNu9EnDBttNpGRdQSMwCFbEfc7KdToJwScXAWeTYRvbie kHRCTjiKCsuuC2ihifrSa2lHfXRe053aS5BgvUgySDICUtvvDItDggQ8nqgnC9DYqe oaBSvLRzQ7MzgQKEtLLyu+x6vmqpqKnVt92AhZ5jIo2UYbnSVbOidhyYEAl6V9huZQ YfhBlFr3Y2B+WVwhgHTXQMzqh4kbYqOh4yZ6RFL8nPKnv/VPEUc4QEnLngxEKyd8QU HkGvJCBESZA5E7NDpwdCpKawMTaj1TKeIuv7Z4aKB0RrsYDifUOv0fcdJj+Iub6Ji5 xCIzxtgKH1k+A== Date: Thu, 7 Jul 2022 11:10:47 -0500 From: Bjorn Helgaas To: ira.weiny@intel.com Cc: Dan Williams , Matthew Wilcox , Greg Kroah-Hartman , "Rafael J. Wysocki" , Alison Schofield , Vishal Verma , linux-kernel@vger.kernel.org, linux-cxl@vger.kernel.org, linux-pci@vger.kernel.org, linux-fsdevel@vger.kernel.org Subject: Re: [RFC PATCH 1/3] xarray: Introduce devm_xa_init() Message-ID: <20220707161047.GA307158@bhelgaas> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220705232159.2218958-2-ira.weiny@intel.com> X-Spam-Status: No, score=-7.8 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_HI, SPF_HELO_NONE,SPF_PASS,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 Tue, Jul 05, 2022 at 04:21:57PM -0700, ira.weiny@intel.com wrote: > From: Ira Weiny > > Many devices may have arrays of resources which are allocated with > device managed functions. The objects referenced by the XArray are > therefore automatically destroyed without the need for the XArray. "... without the need for the XArray" seems like it's missing something. Should this say something like "... without the need for destroying them in the XArray destroy action"? > Introduce devm_xa_init() which takes care of the destruction of the > XArray meta data automatically as well. > > Cc: Dan Williams > Cc: Matthew Wilcox > Signed-off-by: Ira Weiny > > --- > The main issue I see with this is defining devm_xa_init() in device.h. > This makes sense because a device is required to use the call. However, > I'm worried about if users will find the call there vs including it in > xarray.h? > --- > drivers/base/core.c | 20 ++++++++++++++++++++ > include/linux/device.h | 3 +++ > 2 files changed, 23 insertions(+) > > diff --git a/drivers/base/core.c b/drivers/base/core.c > index 2eede2ec3d64..8c5c20a62744 100644 > --- a/drivers/base/core.c > +++ b/drivers/base/core.c > @@ -2609,6 +2609,26 @@ void devm_device_remove_groups(struct device *dev, > } > EXPORT_SYMBOL_GPL(devm_device_remove_groups); > > +static void xa_destroy_cb(void *xa) > +{ > + xa_destroy(xa); > +} > + > +/** > + * devm_xa_init() - Device managed initialization of an empty XArray > + * @dev: The device this xarray is associated with > + * @xa: XArray > + * > + * Context: Any context > + * Returns: 0 on success, -errno if the action fails to be set > + */ > +int devm_xa_init(struct device *dev, struct xarray *xa) > +{ > + xa_init(xa); > + return devm_add_action(dev, xa_destroy_cb, xa); > +} > +EXPORT_SYMBOL(devm_xa_init); > + > static int device_add_attrs(struct device *dev) > { > struct class *class = dev->class; > diff --git a/include/linux/device.h b/include/linux/device.h > index 073f1b0126ac..e06dc63e375b 100644 > --- a/include/linux/device.h > +++ b/include/linux/device.h > @@ -27,6 +27,7 @@ > #include > #include > #include > +#include > #include > #include > #include > @@ -978,6 +979,8 @@ int __must_check devm_device_add_group(struct device *dev, > void devm_device_remove_group(struct device *dev, > const struct attribute_group *grp); > > +int devm_xa_init(struct device *dev, struct xarray *xa); > + > /* > * Platform "fixup" functions - allow the platform to have their say > * about devices and actions that the general device layer doesn't > -- > 2.35.3 >