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

[John Groves <John@groves.net>]

On 26/03/25 12:06PM, Jonathan Cameron wrote:
> 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
> 

Acknowledged. Are you thinking of a one-off for sanitize, or is there
a class of commands that might ought to provide such an upper-bound?

I'd be happy to try to push something through, but the solution ought
to come from somebody who experiences the inconvenience directtly :D

Regards,
John