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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <58981468-ca67-0bb4-86b9-5cb2c3678737@amd.com>
Date: Wed, 8 Jan 2025 14:11:46 +0000
From: Alejandro Lucero Palau <alucerop@....com>
To: Dan Williams <dan.j.williams@...el.com>, alejandro.lucero-palau@....com,
 linux-cxl@...r.kernel.org, netdev@...r.kernel.org, martin.habets@...inx.com,
 edward.cree@....com, davem@...emloft.net, kuba@...nel.org,
 pabeni@...hat.com, edumazet@...gle.com, dave.jiang@...el.com
Subject: Re: [PATCH v8 01/27] cxl: add type2 device basic support


On 1/7/25 23:42, Dan Williams wrote:
> alejandro.lucero-palau@ wrote:
>> From: Alejandro Lucero <alucerop@....com>
>>
>> Differentiate CXL memory expanders (type 3) from CXL device accelerators
>> (type 2) with a new function for initializing cxl_dev_state.
>>
>> Create accessors to cxl_dev_state to be used by accel drivers.
>>
>> Based on previous work by Dan Williams [1]
>>
>> Link: [1] https://lore.kernel.org/linux-cxl/168592160379.1948938.12863272903570476312.stgit@dwillia2-xfh.jf.intel.com/
>> Signed-off-by: Alejandro Lucero <alucerop@....com>
>> Co-developed-by: Dan Williams <dan.j.williams@...el.com>
>> Reviewed-by: Dave Jiang <dave.jiang@...el.com>
>> Reviewed-by: Fan Ni <fan.ni@...sung.com>
> This patch causes
>> ---
>>   drivers/cxl/core/memdev.c | 51 +++++++++++++++++++++++++++++++++++++++
>>   drivers/cxl/core/pci.c    |  1 +
>>   drivers/cxl/cxlpci.h      | 16 ------------
>>   drivers/cxl/pci.c         | 13 +++++++---
>>   include/cxl/cxl.h         | 21 ++++++++++++++++
>>   include/cxl/pci.h         | 23 ++++++++++++++++++
>>   6 files changed, 105 insertions(+), 20 deletions(-)
>>   create mode 100644 include/cxl/cxl.h
>>   create mode 100644 include/cxl/pci.h
>>
>> diff --git a/drivers/cxl/core/memdev.c b/drivers/cxl/core/memdev.c
>> index ae3dfcbe8938..99f533caae1e 100644
>> --- a/drivers/cxl/core/memdev.c
>> +++ b/drivers/cxl/core/memdev.c
>> @@ -7,6 +7,7 @@
>>   #include <linux/slab.h>
>>   #include <linux/idr.h>
>>   #include <linux/pci.h>
>> +#include <cxl/cxl.h>
>>   #include <cxlmem.h>
>>   #include "trace.h"
>>   #include "core.h"
>> @@ -616,6 +617,25 @@ static void detach_memdev(struct work_struct *work)
>>   
>>   static struct lock_class_key cxl_memdev_key;
>>   
>> +struct cxl_dev_state *cxl_accel_state_create(struct device *dev)
> Lets just call this cxl_dev_state_create and have cxl_memdev_state use
> it internally for the truly common init functionality.
>
> Move the cxlds->type setting to a passed in parameter as that appears to
> be the only common init piece that needs to change to make this usable
> by cxl_memdev_state_create().
>
> That would also fix the missing initialization of these values the
> cxl_memdev_state_create() currently handles:
>
>          mds->cxlds.reg_map.resource = CXL_RESOURCE_NONE;
>          mds->ram_perf.qos_class = CXL_QOS_CLASS_INVALID;
>          mds->pmem_perf.qos_class = CXL_QOS_CLASS_INVALID;
>

Ok. It makes sense.


>> +{
>> +	struct cxl_dev_state *cxlds;
>> +
>> +	cxlds = kzalloc(sizeof(*cxlds), GFP_KERNEL);
>> +	if (!cxlds)
>> +		return ERR_PTR(-ENOMEM);
>> +
>> +	cxlds->dev = dev;
>> +	cxlds->type = CXL_DEVTYPE_DEVMEM;
>> +
>> +	cxlds->dpa_res = DEFINE_RES_MEM_NAMED(0, 0, "dpa");
>> +	cxlds->ram_res = DEFINE_RES_MEM_NAMED(0, 0, "ram");
>> +	cxlds->pmem_res = DEFINE_RES_MEM_NAMED(0, 0, "pmem");
>> +
>> +	return cxlds;
>> +}
>> +EXPORT_SYMBOL_NS_GPL(cxl_accel_state_create, "CXL");
> So, this is the only new function I would expect in this patch based on
> the changelog...
>
>> +
>>   static struct cxl_memdev *cxl_memdev_alloc(struct cxl_dev_state *cxlds,
>>   					   const struct file_operations *fops)
>>   {
>> @@ -693,6 +713,37 @@ static int cxl_memdev_open(struct inode *inode, struct file *file)
>>   	return 0;
>>   }
>>   
>> +void cxl_set_dvsec(struct cxl_dev_state *cxlds, u16 dvsec)
>> +{
>> +	cxlds->cxl_dvsec = dvsec;
>> +}
>> +EXPORT_SYMBOL_NS_GPL(cxl_set_dvsec, "CXL");
>> +
>> +void cxl_set_serial(struct cxl_dev_state *cxlds, u64 serial)
>> +{
>> +	cxlds->serial = serial;
>> +}
>> +EXPORT_SYMBOL_NS_GPL(cxl_set_serial, "CXL");
> What are these doing in this patch? Why are new exports needed for such
> trivial functions? If they are common values to move to init time I would
> just make them common argument to cxl_dev_state_create().


I was told to merge those simple changes in this one instead of 
additional patches.

And I have no problem dropping them and use extra  args.

I'll do so it v10.


>> +
>> +int cxl_set_resource(struct cxl_dev_state *cxlds, struct resource res,
> Additionally, why does this take a 'struct resource' rather than a 'struct resource *'?


The driver does not need the resource but for this initialization, so it 
is a locally allocated resource which will not exist later on.

It is a small struct so I guess your concern is not with the stack, 
maybe about security. If it is due to some rule to avoid it which I'm 
not familiar with, it has gone undetected through a lot of eyes ...


>> +		     enum cxl_resource type)
>> +{
>> +	switch (type) {
>> +	case CXL_RES_DPA:
>> +		cxlds->dpa_res = res;
>> +		return 0;
>> +	case CXL_RES_RAM:
>> +		cxlds->ram_res = res;
>> +		return 0;
>> +	case CXL_RES_PMEM:
>> +		cxlds->pmem_res = res;
>> +		return 0;
> This appears to misunderstand the relationship between these resources.
> dpa_res is the overall device internal DPA address space resource tree.
> ram_res and pmem_res are shortcuts to get to the volatile and pmem
> partitions of the dpa space. I can imagine it would ever be desirable to
> trust the caller to fully initialize all the values of the resource,
> especially 'parent', 'sibling', and 'child' which should only be touched
> under the resource lock in the common case.


No, I'm aware of this, but also I think there is a need for setting them 
independently, and the reason behind this code.

Maybe you have in mind some complex devices requiring another approach 
for this set up.



Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ