| 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
| ||
|
Message-ID: <63d4543ff214e_ea22229453@dwillia2-xfh.jf.intel.com.notmuch>
Date: Fri, 27 Jan 2023 14:46:24 -0800
From: Dan Williams <dan.j.williams@...el.com>
To: Alison Schofield <alison.schofield@...el.com>,
Dan Williams <dan.j.williams@...el.com>
CC: Ira Weiny <ira.weiny@...el.com>,
Vishal Verma <vishal.l.verma@...el.com>,
Dave Jiang <dave.jiang@...el.com>,
Ben Widawsky <bwidawsk@...nel.org>,
Steven Rostedt <rostedt@...dmis.org>,
<linux-cxl@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
Jonathan Cameron <Jonathan.Cameron@...wei.com>
Subject: Re: [PATCH v5 3/5] cxl/memdev: Add trigger_poison_list sysfs
attribute
Alison Schofield wrote:
> On Fri, Jan 27, 2023 at 11:42:59AM -0800, Dan Williams wrote:
> > alison.schofield@ wrote:
> > > From: Alison Schofield <alison.schofield@...el.com>
> > >
> > > When a boolean 'true' is written to this attribute the memdev driver
> > > retrieves the poison list from the device. The list consists of
> > > addresses that are poisoned, or would result in poison if accessed,
> > > and the source of the poison. This attribute is only visible for
> > > devices supporting the capability. The retrieved errors are logged
> > > as kernel trace events with the label 'cxl_poison'.
> > >
> > > Reviewed-by: Jonathan Cameron <Jonathan.Cameron@...wei.com>
> > > Signed-off-by: Alison Schofield <alison.schofield@...el.com>
> > > ---
> > > Documentation/ABI/testing/sysfs-bus-cxl | 14 ++++++++
> > > drivers/cxl/core/memdev.c | 45 +++++++++++++++++++++++++
> > > drivers/cxl/cxlmem.h | 2 +-
> > > 3 files changed, 60 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/Documentation/ABI/testing/sysfs-bus-cxl b/Documentation/ABI/testing/sysfs-bus-cxl
> > > index 8494ef27e8d2..df40ed09ea67 100644
> > > --- a/Documentation/ABI/testing/sysfs-bus-cxl
> > > +++ b/Documentation/ABI/testing/sysfs-bus-cxl
> > > @@ -388,3 +388,17 @@ Description:
> > > 1), and checks that the hardware accepts the commit request.
> > > Reading this value indicates whether the region is committed or
> > > not.
> > > +
> > > +
> > > +What: /sys/bus/cxl/devices/memX/trigger_poison_list
> > > +Date: November, 2022
> > > +KernelVersion: v6.2
> > > +Contact: linux-cxl@...r.kernel.org
> > > +Description:
> > > + (WO) When a boolean 'true' is written to this attribute the
> > > + memdev driver retrieves the poison list from the device. The
> > > + list consists of addresses that are poisoned, or would result
> > > + in poison if accessed, and the source of the poison. This
> > > + attribute is only visible for devices supporting the
> > > + capability. The retrieved errors are logged as kernel
> > > + trace events with the label 'cxl_poison'.
> > > diff --git a/drivers/cxl/core/memdev.c b/drivers/cxl/core/memdev.c
> > > index a74a93310d26..e0af7e9c9989 100644
> > > --- a/drivers/cxl/core/memdev.c
> > > +++ b/drivers/cxl/core/memdev.c
> > > @@ -106,12 +106,49 @@ static ssize_t numa_node_show(struct device *dev, struct device_attribute *attr,
> > > }
> > > static DEVICE_ATTR_RO(numa_node);
> > >
> > > +static ssize_t trigger_poison_list_store(struct device *dev,
> > > + struct device_attribute *attr,
> > > + const char *buf, size_t len)
> > > +{
> > > + struct cxl_memdev *cxlmd = to_cxl_memdev(dev);
> > > + struct cxl_dev_state *cxlds = cxlmd->cxlds;
> > > + u64 offset, length;
> > > + bool tmp;
> > > + int rc;
> > > +
> > > + if (kstrtobool(buf, &tmp))
> > > + return -EINVAL;
> >
> > Wait, where's the check for "if (tmp)"? Otherwise I can do "echo N >
> > trigger_poison_list" and it will still run. Should probably
> > s/tmp/trigger/.
>
> Got it.
> (I guess I was too loose w the trigger, thinking you write anything to
> it, I'm triggering.)
> >
> > > +
> > > + /* CXL 3.0 Spec 8.2.9.8.4.1 Separate pmem and ram poison requests */
> > > + if (resource_size(&cxlds->pmem_res)) {
> > > + offset = cxlds->pmem_res.start;
> > > + length = resource_size(&cxlds->pmem_res);
> > > + rc = cxl_mem_get_poison(cxlmd, offset, length, NULL);
> >
> > Ah now I see why the region information is not provided in the memdev
> > triggers. I think while the scan needs to be done on partition boundary
> > basis, like you have here, I think the region lookup needs to happen on
> > a per-record basis.
> >
> > However, that's a significant architectural change, so I am going to
> > think out loud about the implications.
>
> I'm thinking that adding region info to the trace event isn't starting
> here. That will be looked up when we log the event. Basically assuming
> assuming find regions memdev participates in, and look for which one
> maps this DPA.
Yup, we're on the same page. Just compare the dpa of the error record to
the dpa ranges of the enabled decoders on the memdev then it is a
straightforward cxld->region de-reference from there.
>
> >
> > A site operator wants to know "is FRU (field-replaceable-unit) X bad,
> > and if so what's the damage?". In that report I expect they want to know
> > if poison impacts media that is allocated to a region (an imminent
> > danger) or is in free space (a problem for a later date). If the memdev
> > trigger does all the region lookup per record it provides that
> > information. Further if the memdev trigger reliably provides region
> > information it allows the region trigger ABI to be deleted. The region
> > trigger can be replaced in userspace with logic that does:
> >
> > set tracepoint filter to look for region_id == $region
> > for endpoint decoder in $region
> > trigger associated memdev
> >
> > ...so I do think the arch change is worth it, but I am willing to hear
> > counter arguments.
>
> My only counter argument was that we could let them have it both ways,
> but, simplifying and reducing code in kernel is good!
Yeah, in this case I think the memdev interface is -><- that close to
being a general purpose poison lister with all the relevant info in the
record. The only thing missing after the info is populated is the filter
logic, but event filtering is a first class feature of the trace events
subsystem.
Powered by blists - more mailing lists