From: Ira Weiny <ira.weiny@intel.com>
To: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Cc: Dan Williams <dan.j.williams@intel.com>,
Alison Schofield <alison.schofield@intel.com>,
Vishal Verma <vishal.l.verma@intel.com>,
"Ben Widawsky" <bwidawsk@kernel.org>,
Steven Rostedt <rostedt@goodmis.org>,
Davidlohr Bueso <dave@stgolabs.net>,
Dave Jiang <dave.jiang@intel.com>, <linux-kernel@vger.kernel.org>,
<linux-cxl@vger.kernel.org>
Subject: Re: [PATCH V2 03/11] cxl/mem: Implement Clear Event Records command
Date: Thu, 1 Dec 2022 07:30:30 -0800 [thread overview]
Message-ID: <Y4jIlte0qPbCJNFE@iweiny-desk3> (raw)
In-Reply-To: <20221201132618.00006602@Huawei.com>
On Thu, Dec 01, 2022 at 01:26:18PM +0000, Jonathan Cameron wrote:
> On Wed, 30 Nov 2022 16:27:11 -0800
> ira.weiny@intel.com wrote:
>
> > From: Ira Weiny <ira.weiny@intel.com>
> >
> > CXL rev 3.0 section 8.2.9.2.3 defines the Clear Event Records mailbox
> > command. After an event record is read it needs to be cleared from the
> > event log.
> >
> > Implement cxl_clear_event_record() to clear all record retrieved from
> > the device.
> >
> > Each record is cleared explicitly. A clear all bit is specified but
> > events could arrive between a get and any final clear all operation.
> > This means events would be missed.
> > Therefore each event is cleared specifically.
> >
> > Signed-off-by: Ira Weiny <ira.weiny@intel.com>
> I think there is a type issue on the min_t() calculation with that addressed
> this looks good to me.
>
> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
>
> >
> > ---
> > Changes from V1:
> > Clear Event Record allows for u8 handles while Get Event Record
> > allows for u16 records to be returned. Based on Jonathan's
> > feedback; allow for all event records to be handled in this
> > clear. Which means a double loop with potentially multiple
> > Clear Event payloads being sent to clear all events sent.
> >
> > Changes from RFC:
> > Jonathan
> > Clean up init of payload and use return code.
> > Also report any error to clear the event.
> > s/v3.0/rev 3.0
> > ---
> > drivers/cxl/core/mbox.c | 61 +++++++++++++++++++++++++++++++-----
> > drivers/cxl/cxlmem.h | 14 +++++++++
> > include/uapi/linux/cxl_mem.h | 1 +
> > 3 files changed, 69 insertions(+), 7 deletions(-)
> >
> > diff --git a/drivers/cxl/core/mbox.c b/drivers/cxl/core/mbox.c
> > index 70b681027a3d..076a3df0ba38 100644
> > --- a/drivers/cxl/core/mbox.c
> > +++ b/drivers/cxl/core/mbox.c
> > @@ -52,6 +52,7 @@ static struct cxl_mem_command cxl_mem_commands[CXL_MEM_COMMAND_ID_MAX] = {
> > #endif
> > CXL_CMD(GET_SUPPORTED_LOGS, 0, CXL_VARIABLE_PAYLOAD, CXL_CMD_FLAG_FORCE_ENABLE),
> > CXL_CMD(GET_EVENT_RECORD, 1, CXL_VARIABLE_PAYLOAD, 0),
> > + CXL_CMD(CLEAR_EVENT_RECORD, CXL_VARIABLE_PAYLOAD, 0, 0),
> > CXL_CMD(GET_FW_INFO, 0, 0x50, 0),
> > CXL_CMD(GET_PARTITION_INFO, 0, 0x20, 0),
> > CXL_CMD(GET_LSA, 0x8, CXL_VARIABLE_PAYLOAD, 0),
> > @@ -708,6 +709,42 @@ int cxl_enumerate_cmds(struct cxl_dev_state *cxlds)
> > }
> > EXPORT_SYMBOL_NS_GPL(cxl_enumerate_cmds, CXL);
> >
> > +static int cxl_clear_event_record(struct cxl_dev_state *cxlds,
> > + enum cxl_event_log_type log,
> > + struct cxl_get_event_payload *get_pl,
> > + u16 total)
> > +{
> > + struct cxl_mbox_clear_event_payload payload = {
> > + .event_log = log,
> > + };
> > + int cnt;
> > +
> > + /*
> > + * Clear Event Records uses u8 for the handle cnt while Get Event
> > + * Record can return up to 0xffff records.
> > + */
> > + for (cnt = 0; cnt < total; /* cnt incremented internally */) {
> > + u8 nr_recs = min_t(u8, (total - cnt),
> > + CXL_CLEAR_EVENT_MAX_HANDLES);
>
> I might be half asleep but isn't this assuming that (total - cnt)
> fits in an u8? Shouldn't this be min_t(u16, ..)
This cast will ensure the value is never out of range for nr_recs which needs
to be u8 and (total - cnt) will never be negative.
But now you have me double thinking myself.
> Also, maybe u16 cnt would be simpler.
>
> Hmm. This is safe but only because of how you call it alongside
> handling of a particular Get event records response (which must
> have fitted in the mailbox and has a longer header).
>
> Looking at this function in isolation, I think the mailbox could be
> small enough that we might not fit 255 records + the header.
> Perhaps we need a comment to say that, or at minimum a check and error
> return if it won't fit?
I did not realize that Payload Size applied to input payloads as well. :-/
There is no check in the send command for that ATM. Looking at the spec I
think you are right.
I'll further limit the payload size here too.
And with this I might get rid of the min_t() and just cap based on that value.
>
> > + int i, rc;
> > +
> > + for (i = 0; i < nr_recs; i++, cnt++) {
> > + payload.handle[i] = get_pl->records[cnt].hdr.handle;
> > + dev_dbg(cxlds->dev, "Event log '%s': Clearning %u\n",
> > + cxl_event_log_type_str(log),
> > + le16_to_cpu(payload.handle[i]));
> > + }
> > + payload.nr_recs = nr_recs;
> > +
> > + rc = cxl_mbox_send_cmd(cxlds, CXL_MBOX_OP_CLEAR_EVENT_RECORD,
> > + &payload, sizeof(payload), NULL, 0);
> > + if (rc)
> > + return rc;
> > + }
> > +
> > + return 0;
> > +}
> > +
> > static void cxl_mem_get_records_log(struct cxl_dev_state *cxlds,
> > enum cxl_event_log_type type)
> > {
> > @@ -732,13 +769,22 @@ static void cxl_mem_get_records_log(struct cxl_dev_state *cxlds,
> This feels miss named now but I can't immediately think of better naming so on that
> basis fine to leave it as is if you don't have a better idea!.
So we leave it. Naming is hard! :-D
Thanks for the quick review, V3 coming ASAP.
Ira
next prev parent reply other threads:[~2022-12-01 15:31 UTC|newest]
Thread overview: 64+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-12-01 0:27 [PATCH V2 00/11] CXL: Process event logs ira.weiny
2022-12-01 0:27 ` [PATCH V2 01/11] cxl/pci: Add generic MSI-X/MSI irq support ira.weiny
2022-12-01 10:18 ` Jonathan Cameron
2022-12-01 18:37 ` Dave Jiang
2022-12-02 0:23 ` Dan Williams
2022-12-02 0:34 ` Ira Weiny
2022-12-02 2:00 ` Dan Williams
2022-12-02 13:04 ` Jonathan Cameron
2022-12-01 0:27 ` [PATCH V2 02/11] cxl/mem: Implement Get Event Records command ira.weiny
2022-12-01 13:06 ` Jonathan Cameron
2022-12-01 15:10 ` Ira Weiny
2022-12-01 17:38 ` Steven Rostedt
2022-12-02 0:09 ` Ira Weiny
2022-12-02 4:40 ` Steven Rostedt
2022-12-02 5:00 ` Steven Rostedt
2022-12-02 21:31 ` Ira Weiny
2022-12-02 1:39 ` Dan Williams
2022-12-02 21:47 ` Ira Weiny
2022-12-03 21:33 ` Dan Williams
2022-12-01 0:27 ` [PATCH V2 03/11] cxl/mem: Implement Clear " ira.weiny
2022-12-01 13:26 ` Jonathan Cameron
2022-12-01 15:30 ` Ira Weiny [this message]
2022-12-02 2:29 ` Dan Williams
2022-12-02 13:18 ` Jonathan Cameron
2022-12-02 13:34 ` Steven Rostedt
2022-12-02 19:27 ` Dan Williams
2022-12-02 21:28 ` Ira Weiny
2022-12-02 23:49 ` Ira Weiny
2022-12-03 1:14 ` Dan Williams
2022-12-06 7:35 ` Ira Weiny
2022-12-01 0:27 ` [PATCH V2 04/11] cxl/mem: Clear events on driver load ira.weiny
2022-12-01 13:30 ` Jonathan Cameron
2022-12-01 17:02 ` Ira Weiny
2022-12-02 2:48 ` Dan Williams
2022-12-02 16:34 ` Ira Weiny
2022-12-02 23:34 ` Dan Williams
2022-12-03 21:00 ` Ira Weiny
2022-12-01 0:27 ` [PATCH V2 05/11] cxl/mem: Trace General Media Event Record ira.weiny
2022-12-01 18:54 ` Dave Jiang
2022-12-02 6:18 ` Dan Williams
2022-12-01 0:27 ` [PATCH V2 06/11] cxl/mem: Trace DRAM " ira.weiny
2022-12-01 18:55 ` Dave Jiang
2022-12-01 0:27 ` [PATCH V2 07/11] cxl/mem: Trace Memory Module " ira.weiny
2022-12-01 13:31 ` Jonathan Cameron
2022-12-01 18:57 ` Dave Jiang
2022-12-02 6:25 ` Dan Williams
2022-12-01 0:27 ` [PATCH V2 08/11] cxl/mem: Wire up event interrupts ira.weiny
2022-12-01 14:21 ` Jonathan Cameron
2022-12-01 17:23 ` Ira Weiny
2022-12-01 18:35 ` Davidlohr Bueso
2022-12-02 7:37 ` Dan Williams
2022-12-02 14:19 ` Jonathan Cameron
2022-12-02 19:43 ` Dan Williams
2022-12-05 13:01 ` Jonathan Cameron
2022-12-05 16:35 ` Dan Williams
2022-12-06 9:38 ` Jonathan Cameron
2022-12-01 0:27 ` [PATCH V2 09/11] cxl/test: Add generic mock events ira.weiny
2022-12-01 14:37 ` Jonathan Cameron
2022-12-01 17:49 ` Ira Weiny
2022-12-02 8:07 ` Dan Williams
2022-12-01 0:27 ` [PATCH V2 10/11] cxl/test: Add specific events ira.weiny
2022-12-01 21:00 ` Dave Jiang
2022-12-01 0:27 ` [PATCH V2 11/11] cxl/test: Simulate event log overflow ira.weiny
2022-12-01 21:28 ` Dave Jiang
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=Y4jIlte0qPbCJNFE@iweiny-desk3 \
--to=ira.weiny@intel.com \
--cc=Jonathan.Cameron@huawei.com \
--cc=alison.schofield@intel.com \
--cc=bwidawsk@kernel.org \
--cc=dan.j.williams@intel.com \
--cc=dave.jiang@intel.com \
--cc=dave@stgolabs.net \
--cc=linux-cxl@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=rostedt@goodmis.org \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.