From: Alison Schofield <alison.schofield@intel.com>
To: "Verma, Vishal L" <vishal.l.verma@intel.com>
Cc: "linux-cxl@vger.kernel.org" <linux-cxl@vger.kernel.org>,
"nvdimm@lists.linux.dev" <nvdimm@lists.linux.dev>
Subject: Re: [ndctl PATCH v2 3/5] cxl/list: collect and parse the poison list records
Date: Fri, 17 Nov 2023 08:44:54 -0800 [thread overview]
Message-ID: <ZVeYhkyoWhCacC0l@aschofie-mobl2> (raw)
In-Reply-To: <40bfee841cfcaaf5fe139f53fafe74ca394ebc54.camel@intel.com>
On Wed, Nov 15, 2023 at 02:09:15AM -0800, Vishal Verma wrote:
> On Sun, 2023-10-01 at 15:31 -0700, alison.schofield@intel.com wrote:
snip
> >
> > +/* CXL 8.2.9.5.4.1 Get Poison List: Poison Source */
>
> These usually have a spec version too - "CXL 3.0 8.2.9... "
Got it. Fixed up the two like this and also a commit log reference.
Moved them all to the now released CXL 3.1 spec.
> > +static struct json_object *
> > +util_cxl_poison_events_to_json(struct tracefs_instance *inst, bool is_region,
> > + unsigned long flags)
> > +{
> > + struct json_object *jerrors, *jmedia, *jobj = NULL;
>
> Since everything else is now 'poison', might be good to also
> s/jmedia/jpoison/ everywhere.
Done.
> > +
> > + list_for_each_safe(&ectx.jlist_head, jnode, next, list) {
> > + struct json_object *jval = NULL;
> > + struct json_object *jp = NULL;
>
> Are the NULL assignments needed? At least for @jp, it is
> unconditionally assigned below, and isn't used before that. I suspect
> json-c probably doesn't care about what's in @jval either before
> writing it.
>
jp init, obvious not init needed.
For jval init, I guess I worried about garbage in jval, but the way the
trace event is built, it's not a concern.
Removed both those inits.
snip
> > + if (json_object_object_get_ex(jnode->jobj, "source", &jval)) {
> > + source = json_object_get_int(jval);
> > + if (source == CXL_POISON_SOURCE_UNKNOWN)
> > + jobj = json_object_new_string("Unknown");
> > + else if (source == CXL_POISON_SOURCE_EXTERNAL)
> > + jobj = json_object_new_string("External");
> > + else if (source == CXL_POISON_SOURCE_INTERNAL)
> > + jobj = json_object_new_string("Internal");
> > + else if (source == CXL_POISON_SOURCE_INJECTED)
> > + jobj = json_object_new_string("Injected");
> > + else if (source == CXL_POISON_SOURCE_VENDOR)
> > + jobj = json_object_new_string("Vendor");
> > + else
> > + jobj = json_object_new_string("Reserved");
>
> Minor nit, but maybe 'switch (source) ...' would look a bit cleaner?
Done.
>
> > +
> > + /* Always include the count. If count is zero, no records follow. */
> > + jobj = json_object_new_int(count);
> > + if (jobj)
> > + json_object_object_add(jmedia, "nr_poison_records", jobj);
> > + if (count)
> > + json_object_object_add(jmedia, "poison_records", jerrors);
>
> Since these are already nested under a 'poison' JSON object, I'm
> tempted to say these can just be 'nr_records' and 'records'
> respectively.
>
Done.
> > +
> > + return jmedia;
> > +}
> > +
> > +struct cxl_poison_ctx {
> > + void *dev;
> > + bool is_region;
> > +};
>
> This structure is a bit awkward - what do you think about creating
> different wrappers for the memdev and region case -
>
> util_cxl_memdev_poison_list_to_json(), and
> util_cxl_region_poison_list_to_json() that are called respectively by
>
> util_cxl_{memdev,region}_to_json(), and internally they can call:
>
> util_cxl_poison_list_to_json(NULL, memdev, flags), or
> util_cxl_poison_list_to_json(region, NULL, flags)
>
> For the next level down, i.e. poison_events_to_json, the @is_region
> bool passed in directly is fine as it doesn't need the memdev or region
> objects passed in via void *.
Thanks! I did something like this but didn't actually add wrappers.
Please look in v3 and let me know.
>
snip
> > + if (pctx->is_region)
> > + rc = cxl_region_trigger_poison_list(pctx->dev);
> > + else
> > + rc = cxl_memdev_trigger_poison_list(pctx->dev);
> > + if (rc) {
> > + fprintf(stderr, "Failed write of sysfs attribute: %d\n", rc);
>
> This would be incorrect if the memdev trigger reported an ENOMEM, and
> then this reported a sysfs write failure.
>
> It should at least be something like 'failed to trigger poison" - but
> since the memdev trigger helper has prints for every failure case,
> maybe this can just be omitted?
Removed it.
>
snip
> > diff --git a/util/json.h b/util/json.h
> > index ea370df4d1b7..3ae4074a95c3 100644
> > --- a/util/json.h
> > +++ b/util/json.h
> > @@ -21,6 +21,7 @@ enum util_json_flags {
> > UTIL_JSON_TARGETS = (1 << 11),
> > UTIL_JSON_PARTITION = (1 << 12),
> > UTIL_JSON_ALERT_CONFIG = (1 << 13),
> > + UTIL_JSON_POISON_LIST = (1 << 14),
>
> There's already a UTIL_JSON_MEDIA_ERRORS, can we just reuse that (in
> spite of the name :))
Since it's not visible to user, changed it.
Thanks for the review Vishal!
>
next prev parent reply other threads:[~2023-11-17 16:44 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-01 22:31 [ndctl PATCH v2 0/3] Support poison list retrieval alison.schofield
2023-10-01 22:31 ` [ndctl PATCH v2 1/5] libcxl: add interfaces for GET_POISON_LIST mailbox commands alison.schofield
2023-11-15 10:08 ` Verma, Vishal L
2023-11-17 16:21 ` Alison Schofield
2023-10-01 22:31 ` [ndctl PATCH v2 2/5] cxl: add an optional pid check to event parsing alison.schofield
2023-10-01 22:31 ` [ndctl PATCH v2 3/5] cxl/list: collect and parse the poison list records alison.schofield
2023-11-15 10:09 ` Verma, Vishal L
2023-11-17 16:44 ` Alison Schofield [this message]
2023-10-01 22:31 ` [ndctl PATCH v2 4/5] cxl/list: add --poison option to cxl list alison.schofield
2023-10-01 22:31 ` [ndctl PATCH v2 5/5] cxl/test: add cxl-poison.sh unit test alison.schofield
2023-11-15 10:13 ` Verma, Vishal L
2023-11-17 16:52 ` Alison Schofield
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZVeYhkyoWhCacC0l@aschofie-mobl2 \
--to=alison.schofield@intel.com \
--cc=linux-cxl@vger.kernel.org \
--cc=nvdimm@lists.linux.dev \
--cc=vishal.l.verma@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox