Re: [PATCH v2] cxl/mbox: Support Media Operation

["Dan Williams" <djbw@kernel.org>]

K

On Sat, May 2, 2026, at 12:34 PM, Davidlohr Bueso wrote:
> On Tue, 28 Apr 2026, Dave Jiang wrote:
>>> +What:		/sys/bus/cxl/devices/memX/security/zero
>>> +Date:		April, 2026
>>> +KernelVersion:	v7.2
>>> +Contact:	linux-cxl@vger.kernel.org
>>> +Description:
>>> +		(WO) Write a DPA range as 'start length' in bytes to this
>>
>>Same comment about multiple input in a single attribute. Maybe introduce these:
>>
>>security/zero_start_dpa
>>security/zero_len
>>security/zero
>
> I had missed this feedback - this suggested interface is horrible. While the
> sysfs documentation mentions the one rule per file, this is not strict and
> (as Jonathan also agreed previously) we can do <start> <len> inputs. There
> are plenty of examples that do not follow this rule when it makes sense.
>
> So my follow up patches will do
>
> echo <start_dpa> <len> > /sys/bus/cxl/devices/mem0/security/sanitize_range
> echo <start_dpa> <len> > /sys/bus/cxl/devices/mem0/security/zero_range
>

Isn't a "start:len" tuple ABI a solved problem? It would be nice to share the same parsing as memmap=. For example, then you get features like "echo 1G:1G ..." to specify a range.

However does userspace really need to pick ranges? Would it be sufficient to start with a "sanitize / zero all unmapped" semantic to walk all not mapped DPA. Or perhaps a "sanitize / zero on unmap" flag to the decoder to make it similar to a storage "trim on delete" semantic. The nice thing about that, you can defer freeing the DPA until it's clean to avoid reallocation races. You actually know what you're zapping because it had some recent prior association.

Otherwise I do not trust the security properties of policy wanting to clean a DPA range but an unsuspecting thread can race to allocate between lock drops. Looks like a footgun.

What use case is missed with a per decoder automatic cleaning on unmap setting? Zero before map policy might be nice too...