linux-kernel - Re: [PATCH v3 20/25] dax/bus: Factor out dev dax resize logic

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <66d0e9e93aab4_f937b29446@iweiny-mobl.notmuch>
Date: Thu, 29 Aug 2024 16:36:41 -0500
From: Ira Weiny <ira.weiny@...el.com>
To: Jonathan Cameron <Jonathan.Cameron@...wei.com>, Ira Weiny
	<ira.weiny@...el.com>
CC: Dave Jiang <dave.jiang@...el.com>, Fan Ni <fan.ni@...sung.com>, "Navneet
 Singh" <navneet.singh@...el.com>, Chris Mason <clm@...com>, Josef Bacik
	<josef@...icpanda.com>, David Sterba <dsterba@...e.com>, Petr Mladek
	<pmladek@...e.com>, Steven Rostedt <rostedt@...dmis.org>, Andy Shevchenko
	<andriy.shevchenko@...ux.intel.com>, Rasmus Villemoes
	<linux@...musvillemoes.dk>, Sergey Senozhatsky <senozhatsky@...omium.org>,
	Jonathan Corbet <corbet@....net>, Andrew Morton <akpm@...ux-foundation.org>,
	Dan Williams <dan.j.williams@...el.com>, Davidlohr Bueso <dave@...olabs.net>,
	Alison Schofield <alison.schofield@...el.com>, Vishal Verma
	<vishal.l.verma@...el.com>, <linux-btrfs@...r.kernel.org>,
	<linux-cxl@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
	<linux-doc@...r.kernel.org>, <nvdimm@...ts.linux.dev>
Subject: Re: [PATCH v3 20/25] dax/bus: Factor out dev dax resize logic

Jonathan Cameron wrote:
> On Fri, 16 Aug 2024 09:44:28 -0500
> Ira Weiny <ira.weiny@...el.com> wrote:
> 
> > Dynamic Capacity regions must limit dev dax resources to those areas
> > which have extents backing real memory.  Such DAX regions are dubbed
> > 'sparse' regions.  In order to manage where memory is available four
> > alternatives were considered:
> > 
> > 1) Create a single region resource child on region creation which
> >    reserves the entire region.  Then as extents are added punch holes in
> >    this reservation.  This requires new resource manipulation to punch
> >    the holes and still requires an additional iteration over the extent
> >    areas which may already have existing dev dax resources used.
> > 
> > 2) Maintain an ordered xarray of extents which can be queried while
> >    processing the resize logic.  The issue is that existing region->res
> >    children may artificially limit the allocation size sent to
> >    alloc_dev_dax_range().  IE the resource children can't be directly
> >    used in the resize logic to find where space in the region is.  This
> >    also poses a problem of managing the available size in 2 places.
> > 
> > 3) Maintain a separate resource tree with extents.  This option is the
> >    same as 2) but with the different data structure.  Most ideally there
> >    should be a unified representation of the resource tree not two places
> >    to look for space.
> > 
> > 4) Create region resource children for each extent.  Manage the dax dev
> >    resize logic in the same way as before but use a region child
> >    (extent) resource as the parents to find space within each extent.
> > 
> > Option 4 can leverage the existing resize algorithm to find space within
> > the extents.  It manages the available space in a singular resource tree
> > which is less complicated for finding space.
> > 
> > In preparation for this change, factor out the dev_dax_resize logic.
> > For static regions use dax_region->res as the parent to find space for
> > the dax ranges.  Future patches will use the same algorithm with
> > individual extent resources as the parent.
> > 
> > Signed-off-by: Ira Weiny <ira.weiny@...el.com>
> I'm not 100% confident on this one, so will probably take another look
> before giving a tag.

Thanks.

> One trivial comment below.
> 
> 
> 
> > +static ssize_t dev_dax_resize(struct dax_region *dax_region,
> > +		struct dev_dax *dev_dax, resource_size_t size)
> > +{
> > +	resource_size_t avail = dax_region_avail_size(dax_region), to_alloc;
> > +	resource_size_t dev_size = dev_dax_size(dev_dax);
> > +	struct device *dev = &dev_dax->dev;
> > +	resource_size_t alloc = 0;
> 
> No path in which this is not set before use.

fixed thanks
Ira

[snip]