From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id E1DB5386C30; Thu, 19 Mar 2026 13:59:29 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=185.176.79.56 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773928773; cv=none; b=hdX3OTjWWJIe1qvbAuPTXmb12FJ0yO0oSVY/GTQW989cswKJY1ZTAM43x5EZJ0KYxnqmef9gll0rzwx0CCotdMriJmilUEtJXVP8D8PJMkLFIL1oHd8FMzVX1leTLMTudN7yLx41nhZS8NZMb8XLuHwloQGSHiB9tkroZCAIC/k= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773928773; c=relaxed/simple; bh=TTNzvb3312bF4OJODOgMQqa+yyQSoFloxeONu4CmNao=; h=Date:From:To:CC:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=eiY2nNaK2dsyN4qm0gfqIXc16YClZkAdw2qxC8yapjkbPrnfsl1o+8Nargu99l/P/PqrzOQhiQLyDL86pT31iQC/dE/O84N6XTznZATUX7V5S0jAmjpOcA/aCBseVEBxd9XQIN8nZKctO4gc5jqKCwVXZjd3v0mIk5V0Hc3hMyM= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com; spf=pass smtp.mailfrom=huawei.com; arc=none smtp.client-ip=185.176.79.56 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=huawei.com Received: from mail.maildlp.com (unknown [172.18.224.83]) by frasgout.his.huawei.com (SkyGuard) with ESMTPS id 4fc6jb34hCzJ46BP; Thu, 19 Mar 2026 21:58:27 +0800 (CST) Received: from dubpeml500005.china.huawei.com (unknown [7.214.145.207]) by mail.maildlp.com (Postfix) with ESMTPS id DD35440572; Thu, 19 Mar 2026 21:59:26 +0800 (CST) Received: from localhost (10.203.177.15) by dubpeml500005.china.huawei.com (7.214.145.207) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.11; Thu, 19 Mar 2026 13:59:25 +0000 Date: Thu, 19 Mar 2026 13:59:24 +0000 From: Jonathan Cameron To: Smita Koralahalli CC: , , , , , Ard Biesheuvel , "Alison Schofield" , Vishal Verma , Ira Weiny , Dan Williams , Yazen Ghannam , "Dave Jiang" , Davidlohr Bueso , "Matthew Wilcox" , Jan Kara , "Rafael J . Wysocki" , Len Brown , Pavel Machek , Li Ming , Jeff Johnson , Ying Huang , Yao Xingtao , "Peter Zijlstra" , Greg Kroah-Hartman , Nathan Fontenot , Terry Bowman , Robert Richter , Benjamin Cheatham , Zhijian Li , Borislav Petkov , Tomasz Wolski Subject: Re: [PATCH v7 4/7] dax: Track all dax_region allocations under a global resource tree Message-ID: <20260319135924.000060c2@huawei.com> In-Reply-To: <20260319011500.241426-5-Smita.KoralahalliChannabasappa@amd.com> References: <20260319011500.241426-1-Smita.KoralahalliChannabasappa@amd.com> <20260319011500.241426-5-Smita.KoralahalliChannabasappa@amd.com> X-Mailer: Claws Mail 4.3.0 (GTK 3.24.42; x86_64-w64-mingw32) Precedence: bulk X-Mailing-List: linux-fsdevel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable X-ClientProxiedBy: lhrpeml500009.china.huawei.com (7.191.174.84) To dubpeml500005.china.huawei.com (7.214.145.207) On Thu, 19 Mar 2026 01:14:57 +0000 Smita Koralahalli wrote: > Introduce a global "DAX Regions" resource root and register each > dax_region->res under it via request_resource(). Release the resource on > dax_region teardown. >=20 > By enforcing a single global namespace for dax_region allocations, this > ensures only one of dax_hmem or dax_cxl can successfully register a > dax_region for a given range. >=20 > Suggested-by: Dan Williams > Signed-off-by: Smita Koralahalli The comment below is about the existing code. If we decide not to tidy that up for now and you swap the ordering of release_resource() and sysfs_remove= _groups() in unregister. Reviewed-by: Jonathan Cameron > --- > drivers/dax/bus.c | 20 +++++++++++++++++--- > 1 file changed, 17 insertions(+), 3 deletions(-) >=20 > diff --git a/drivers/dax/bus.c b/drivers/dax/bus.c > index c94c09622516..448e2bc285c3 100644 > --- a/drivers/dax/bus.c > +++ b/drivers/dax/bus.c > @@ -10,6 +10,7 @@ > #include "dax-private.h" > #include "bus.h" > =20 > +static struct resource dax_regions =3D DEFINE_RES_MEM_NAMED(0, -1, "DAX = Regions"); > static DEFINE_MUTEX(dax_bus_lock); > =20 > /* > @@ -625,6 +626,7 @@ static void dax_region_unregister(void *region) > { > struct dax_region *dax_region =3D region; > =20 > + release_resource(&dax_region->res); Should reverse the line above and the line below so we unwind in reverse of setup. I doubt it matters in practice today but keeping ordering like that makes it much easier to see if a future patch messes things up. > sysfs_remove_groups(&dax_region->dev->kobj, > dax_region_attribute_groups); > dax_region_put(dax_region); > @@ -635,6 +637,7 @@ struct dax_region *alloc_dax_region(struct device *pa= rent, int region_id, > unsigned long flags) > { > struct dax_region *dax_region; > + int rc; > =20 > /* > * The DAX core assumes that it can store its private data in > @@ -667,14 +670,25 @@ struct dax_region *alloc_dax_region(struct device *= parent, int region_id, > .flags =3D IORESOURCE_MEM | flags, > }; > =20 > - if (sysfs_create_groups(&parent->kobj, dax_region_attribute_groups)) { > - kfree(dax_region); > - return NULL; > + rc =3D request_resource(&dax_regions, &dax_region->res); > + if (rc) { > + dev_dbg(parent, "dax_region resource conflict for %pR\n", > + &dax_region->res); > + goto err_res; > } > =20 > + if (sysfs_create_groups(&parent->kobj, dax_region_attribute_groups)) > + goto err_sysfs; > + > if (devm_add_action_or_reset(parent, dax_region_unregister, dax_region)) This is curious. The code flips over to a kref_put() based release but we d= idn't do anything with the kref in the previous call. So whilst not 'buggy' as su= ch it's definitely inconsistent and we should clean it up. This should really have been doing the release via dax_region_put() from the kref_init(). In practice that means never calling kfree(dax_regions) error= paths because the kref_init() is just after the allocation. Instead call dax_regi= on_put() in all those error paths. =20 > return NULL; > return dax_region; > + > +err_sysfs: > + release_resource(&dax_region->res); > +err_res: > + kfree(dax_region); =46rom above I think this should be dax_region_put(dax_region); > + return NULL; > } > EXPORT_SYMBOL_GPL(alloc_dax_region); > =20