linux-kernel - Re: [PATCH 00/26] DCD: Add support for Dynamic Capacity Devices (DCD)

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]

Date: Wed, 3 Apr 2024 21:39:58 +0100
From: Jonathan Cameron <Jonathan.Cameron@...wei.com>
To: Ira Weiny <ira.weiny@...el.com>
CC: fan <nifan.cxl@...il.com>, Dave Jiang <dave.jiang@...el.com>, Fan Ni
	<fan.ni@...sung.com>, Navneet Singh <navneet.singh@...el.com>, 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>, Chris Mason
	<clm@...com>, Josef Bacik <josef@...icpanda.com>, David Sterba
	<dsterba@...e.com>
Subject: Re: [PATCH 00/26] DCD: Add support for Dynamic Capacity Devices
 (DCD)

On Wed, 27 Mar 2024 22:20:45 -0700
Ira Weiny <ira.weiny@...el.com> wrote:

> fan wrote:
> > On Sun, Mar 24, 2024 at 04:18:03PM -0700, ira.weiny@...el.com wrote:  
> > > A git tree of this series can be found here:  
> 
> [snip]
> 
> > >   
> > 
> > Hi Ira,
> > Have not got a chance to check the code yet, but I noticed one thing
> > when testing with my DCD emulation code.
> > Currently, if we do partial release, it seems the whole extent will be
> > removed. Is it designed intentionally?
> >   
> 
> Yes that is my intent.  I specifically called that out in patch 18.
> 
> https://lore.kernel.org/all/20240324-dcd-type2-upstream-v1-18-b7b00d623625@intel.com/
> 
> I thought we discussed this in one of the collaboration calls.  Mainly
> this is to simplify by not attempting any split of the extents the host is
> tracking.  It really is expected that the FM/device is going to keep those
> extents offered and release them in their entirety.  I understand this may
> complicate the device because it may see a release of memory prior to the
> request of that release.  And perhaps this complicates the device.  But in
> that case it (or the FM really) should not attempt to release partial
> extents.

It was discussed at some point as you say. Feels like something that might not
be set in stone for ever, but for now it is a reasonable simplifying assumption.
The device might not maintain the separation of neighboring extents
but the FM probably will.  If it turns out real use models are different,
then we 'guessed' wrong and get to write more complex code. 

Device always has to cope with unsolicited release so don't think this adds
any burden.  That includes a race where the host releases capacity when
it hasn't yet seen the event the device has sent to release part of the same
capacity.  There is text about async release always being possible in the
spec to cover these overlapping cases but upshot of that one is it must be
permissible to release a containing capacity as you are doing.

Jonathan

> Ira
> 
> [snip]