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: Thu, 4 Apr 2024 18:49:01 +0100
From: Jonathan Cameron <Jonathan.Cameron@...wei.com>
To: <ira.weiny@...el.com>
CC: 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)


> 
> Fan Ni's latest v5 of Qemu DCD was used for testing.[2]
Hi Ira, Navneet.
> 
> Remaining work:
> 
> 	1) Integrate the QoS work from Dave Jiang
> 	2) Interleave support


More flag.  This one I think is potentially important and don't
see any handling in here.

Whilst an FM could in theory be careful to avoid sending a
sparse set of extents, if the device is managing the memory range
(which is possible all it supports) and the FM issues an Initiate Dynamic
Capacity Add with Free (again may be all device supports) then we
can't stop the device issuing a bunch of sparse extents.

Now it won't be broken as such without this, but every time we
accept the first extent that will implicitly reject the rest.
That will look very ugly to an FM which has to poke potentially many
times to successfully allocate memory to a host.

I also don't think it will be that hard to support, but maybe I'm
missing something? 

My first thought is it's just a loop in cxl_handle_dcd_add_extent()
over a list of extents passed in then slightly more complex response
generation.

I don't want this to block getting initial DCD support in but it
will be a bit ugly if we quickly support the more flag and then end
up with just one kernel that an FM has to be careful with...

Jonathan

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ