netdev - Re: [PATCH v17 22/22] sfc: support pio mapping based on cxl

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: <20250627104635.000003c4@huawei.com>
Date: Fri, 27 Jun 2025 10:46:35 +0100
From: Jonathan Cameron <Jonathan.Cameron@...wei.com>
To: <alejandro.lucero-palau@....com>
CC: <linux-cxl@...r.kernel.org>, <netdev@...r.kernel.org>,
	<dan.j.williams@...el.com>, <edward.cree@....com>, <davem@...emloft.net>,
	<kuba@...nel.org>, <pabeni@...hat.com>, <edumazet@...gle.com>,
	<dave.jiang@...el.com>, Alejandro Lucero <alucerop@....com>
Subject: Re: [PATCH v17 22/22] sfc: support pio mapping based on cxl

On Tue, 24 Jun 2025 15:13:55 +0100
alejandro.lucero-palau@....com wrote:

> From: Alejandro Lucero <alucerop@....com>
> 
> A PIO buffer is a region of device memory to which the driver can write a
> packet for TX, with the device handling the transmit doorbell without
> requiring a DMA for getting the packet data, which helps reducing latency
> in certain exchanges. With CXL mem protocol this latency can be lowered
> further.
> 
> With a device supporting CXL and successfully initialised, use the cxl
> region to map the memory range and use this mapping for PIO buffers.
> 
> Add the disabling of those CXL-based PIO buffers if the callback for
> potential cxl endpoint removal by the CXL code happens.
> 
> Signed-off-by: Alejandro Lucero <alucerop@....com>
There is quite a bit of ifdef magic in here.  If there is any way
to push that to stubs in headers, it would probably improved code
readability.

I was expecting to at somepoint see handling of the CXL code being
called returning EPROBE_DEFER but that's not here so I don't
understand exactly how that is supposed to work if the CXL infrastructure
hasn't arrived at time of first probe.

Otherwise, main overall concern is that lifetimes are (I think) more
complex than they need to be.  I suggest a solution in an earlier patch (and
in reply to previous version)  Devres groups are really handy for wrapping
up a bunch of devm calls with the option to unwind them all on error or at
a specific point in the remove() path for a driver.  That should resolve
most of my concerns as you'll have something closely approximating a non devm flow.

Jonathan