Re: [RFC PATCH 0/1] cxl: Media Operations

[Jonathan Cameron <jonathan.cameron@huawei.com>]

On Tue, 24 Mar 2026 11:07:54 -0700
Davidlohr Bueso <dave@stgolabs.net> wrote:

> On Tue, 24 Mar 2026, Jonathan Cameron wrote:
> 
> >On Mon, 23 Mar 2026 13:40:12 -0700
> >Davidlohr Bueso <dave@stgolabs.net> wrote:
> >  
> >> Hello,
> >>
> >> This implements support for Media Operation cmd. It is marked RFC because of these
> >> noteworthy points:
> >>
> >>  (i) Sysfs interfaces. These changes implement 'security/zero' and multiplex
> >>      'security/sanitize' to allow dpa, len pairs for the range (no impact for
> >>      current usage as whole-device). This breaks the 1 value per file "rule",
> >>      and would be a first for drivers/cxl/*, so am I open to suggestions.  
> >
> >Value is a vague sort of term.  It's one thing (an range) so seems fine to me.  
> 
> I agree.
> 
> >  
> >>
> >>  (ii) Background cmd handling semantics. Media operations are synchronous,
> >>       which for raged zeroing operations makes sense and for range sanitize  
> >
> >ranged
> >  
> >>       differs from the current async handling for whole-device, so user response
> >>       differs significantly, something I am not crazy about. Another downside
> >>       of this is that it exposes lock hold times to be user-controllable, but is
> >>       no different than what we do for fw. Fundamentally, users have the
> >>       responsibility to break up the work into sane ranges.  
> >
> >We could apply a limit on this and make that discoverable via another sysfs attribute.
> >So let userspace request in say 1Gig chunks.  Would have to check that the device
> >supports that granularity though.  
> 
> If we agree that this will be performed synchronously, then yes, adding a size cap
> would be necessary. I don't love having it in ie: security/range_limit(?), but that
> could be created at discovery time when we know the granularity. Another way would
> be to avoid the extra file and just print the limit in the error message - but I
> guess dev_dbg() would be needed to not spam the dmesg. In any case with a cap,
> while no guarantees, this also reduces the chances of the user triggering driver timeouts.
> 
> >I don't think there is anything in the spec today to let us query how long
> >something takes (which would be a better way to bound this).  
> 
> Correct, that is just something Scan Media allows for - and yes, that's exactly
> the sane way to do the work breakup.
> 
Yo John,

I'm sure you are keeping a list of potential improvements for the appropriate group
that I believe you have some leadership role in ;)

I'd like devices to provide info to allow us to establish an upper bound on how
long a zero / sanitize media operation would take.  This one doesn't need to be
code first so we can consider this a potential feature request.

Jonathan

> Thanks,
> Davidlohr