netdev - Re: [PATCH v17 20/22] sfc: create cxl region

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: <fb959fa6-26bd-4aaf-b5cd-3b8184d9f79f@amd.com>
Date: Mon, 11 Aug 2025 15:38:37 +0100
From: Alejandro Lucero Palau <alucerop@....com>
To: dan.j.williams@...el.com, alejandro.lucero-palau@....com,
 linux-cxl@...r.kernel.org, netdev@...r.kernel.org, edward.cree@....com,
 davem@...emloft.net, kuba@...nel.org, pabeni@...hat.com,
 edumazet@...gle.com, dave.jiang@...el.com
Subject: Re: [PATCH v17 20/22] sfc: create cxl region


On 7/28/25 17:20, dan.j.williams@...el.com wrote:
> alejandro.lucero-palau@ wrote:
>> From: Alejandro Lucero <alucerop@....com>
>>
>> Use cxl api for creating a region using the endpoint decoder related to
>> a DPA range.
>>
>> Add a callback for unwinding sfc cxl initialization when the endpoint port
>> is destroyed by potential cxl_acpi or cxl_mem modules removal.
>>
>> Signed-off-by: Alejandro Lucero <alucerop@....com>
>> ---
>>   drivers/net/ethernet/sfc/efx_cxl.c | 24 +++++++++++++++++++++++-
>>   1 file changed, 23 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/net/ethernet/sfc/efx_cxl.c b/drivers/net/ethernet/sfc/efx_cxl.c
>> index ffbf0e706330..7365effe974e 100644
>> --- a/drivers/net/ethernet/sfc/efx_cxl.c
>> +++ b/drivers/net/ethernet/sfc/efx_cxl.c
>> @@ -18,6 +18,16 @@
>>   
>>   #define EFX_CTPIO_BUFFER_SIZE	SZ_256M
>>   
>> +static void efx_release_cxl_region(void *priv_cxl)
>> +{
>> +	struct efx_probe_data *probe_data = priv_cxl;
>> +	struct efx_cxl *cxl = probe_data->cxl;
>> +
>> +	iounmap(cxl->ctpio_cxl);
> There is no synchronization here. If someone unbinds the a cxl_port
> while the driver is using @ctpio_cxl, it looks it will cause a crash.


Yes, the unmapping should be after changing cxl_pio_initialised. I will 
fix it if this mechanism stays ...


>
> The loss of CXL connectivity after the driver has already committed to
> it likely means that the whole driver needs to be shutdown, not just
> this region cleanup.


What I am trying to handle here is not an CXL error but removal of cxl 
modules. If the latter happens, the driver will keep using other 
datapath but not the cxl_pio memory.


About a CXL error, I really do not know what is the right thing to do 
here. If further CXL.mem writes after such an error are not problematic, 
then this is enough. If not, I'm afraid we can not safely deal with this 
since the host/driver will be notified too late.