From: Alison Schofield <alison.schofield@intel.com>
To: Dan Williams <dan.j.williams@intel.com>
Cc: Ira Weiny <ira.weiny@intel.com>,
Vishal Verma <vishal.l.verma@intel.com>,
Dave Jiang <dave.jiang@intel.com>,
Ben Widawsky <bwidawsk@kernel.org>,
Steven Rostedt <rostedt@goodmis.org>,
Ingo Molnar <mingo@redhat.com>,
linux-cxl@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3 2/6] cxl/mbox: Add GET_POISON_LIST mailbox command
Date: Wed, 7 Dec 2022 19:47:35 -0800 [thread overview]
Message-ID: <Y5FeVySReYXU6E2p@aschofie-mobl2> (raw)
In-Reply-To: <6391082ed3374_3cbe02947d@dwillia2-xfh.jf.intel.com.notmuch>
On Wed, Dec 07, 2022 at 01:39:58PM -0800, Dan Williams wrote:
> Alison Schofield wrote:
> > On Tue, Dec 06, 2022 at 06:41:34PM -0800, Dan Williams wrote:
> > > alison.schofield@ wrote:
> [..]
> > > > +int cxl_mem_get_poison(struct cxl_memdev *cxlmd, u64 offset, u64 len,
> > > > + struct cxl_region *cxlr)
> > > > +{
> > > > + struct cxl_dev_state *cxlds = cxlmd->cxlds;
> > > > + const char *memdev_name = dev_name(&cxlmd->dev);
> > > > + const char *pcidev_name = dev_name(cxlds->dev);
> > > > + struct cxl_mbox_poison_payload_out *po;
> > > > + struct cxl_mbox_poison_payload_in pi;
> > > > + int nr_records = 0;
> > > > + int rc;
> > > > +
> > > > + po = kvmalloc(cxlds->payload_size, GFP_KERNEL);
> > > > + if (!po)
> > > > + return -ENOMEM;
> > > > +
> > > > + pi.offset = cpu_to_le64(offset);
> > > > + pi.length = cpu_to_le64(len);
> > > > +
> > > > + rc = mutex_lock_interruptible(&cxlds->poison_list_mutex);
> > >
> > > So I do not know what this mutex is protecting if there is an allocation
> > > per cxl_mem_get_poison() invocation. Although I suspect that's somewhat
> > > wasteful. Just allocate one buffer at the beginning of time and then use
> > > the lock to protect that buffer.
> >
> > Intent was a single lock on the device to protect the state of the
> > poison list retrieval - do not allow > 1 reader. With > 1 reader
> > software may not know if it retrieved the complete list.
> >
> > I'm not understanding about protecting a buffer, instead of protecting
> > the state. Here I try to protect the state.
>
> Ah, sorry I read cxlds->poison_list_mutex and assumed it was serializing
> access to the buffer, not a state machine. I do think it would be
> worthwhile to make this a self contained structure with its own kdoc to
> explain what is going on, something like:
>
OK thanks, it's getting through to me now.
Will do !
> diff --git a/drivers/cxl/cxlmem.h b/drivers/cxl/cxlmem.h
> index ab138004f644..02697d1d951c 100644
> --- a/drivers/cxl/cxlmem.h
> +++ b/drivers/cxl/cxlmem.h
> @@ -193,6 +193,19 @@ struct cxl_endpoint_dvsec_info {
> struct range dvsec_range[2];
> };
>
> +/**
> + * struct cxl_poison_state - summary
> + * @payload: ...
> + * @lock: ...
> + *
> + * A bit more description of why state needs to be held over successive
> + * mbox commands...
> + */
> +struct cxl_poison_state {
> + void *payload;
> + struct mutex lock;
> +};
> +
> /**
> * struct cxl_dev_state - The driver device state
> *
> @@ -210,6 +223,7 @@ struct cxl_endpoint_dvsec_info {
> * @lsa_size: Size of Label Storage Area
> * (CXL 2.0 8.2.9.5.1.1 Identify Memory Device)
> * @mbox_mutex: Mutex to synchronize mailbox access.
> + * @poison: Poison list retrieval and tracing
> * @firmware_version: Firmware version for the memory device.
> * @enabled_cmds: Hardware commands found enabled in CEL.
> * @exclusive_cmds: Commands that are kernel-internal only
> @@ -244,6 +258,7 @@ struct cxl_dev_state {
> size_t payload_size;
> size_t lsa_size;
> struct mutex mbox_mutex; /* Protects device mailbox and firmware */
> + struct cxl_poison_state poison;
> char firmware_version[0x10];
> DECLARE_BITMAP(enabled_cmds, CXL_MEM_COMMAND_ID_MAX);
> DECLARE_BITMAP(exclusive_cmds, CXL_MEM_COMMAND_ID_MAX);
next prev parent reply other threads:[~2022-12-08 3:47 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-11 3:12 [PATCH v3 0/6] CXL Poison List Retrieval & Tracing alison.schofield
2022-11-11 3:12 ` [PATCH v3 1/6] trace, cxl: Introduce a TRACE_EVENT for CXL poison records alison.schofield
2022-11-16 12:19 ` Jonathan Cameron
2022-12-04 22:42 ` Dan Williams
2022-11-11 3:12 ` [PATCH v3 2/6] cxl/mbox: Add GET_POISON_LIST mailbox command alison.schofield
2022-11-16 12:41 ` Jonathan Cameron
2022-11-17 23:55 ` Alison Schofield
2022-12-07 2:41 ` Dan Williams
2022-12-07 16:10 ` Alison Schofield
2022-12-07 21:39 ` Dan Williams
2022-12-08 3:47 ` Alison Schofield [this message]
2022-11-11 3:12 ` [PATCH v3 3/6] cxl/memdev: Add trigger_poison_list sysfs attribute alison.schofield
2022-11-16 12:48 ` Jonathan Cameron
2022-11-18 0:15 ` Alison Schofield
2022-11-11 3:12 ` [PATCH v3 4/6] cxl/region: " alison.schofield
2022-11-16 12:50 ` Jonathan Cameron
2022-11-18 0:24 ` Alison Schofield
2022-11-11 3:12 ` [PATCH v3 5/6] tools/testing/cxl: Mock the max err records field of Identify cmd alison.schofield
2022-11-16 12:51 ` Jonathan Cameron
2022-11-18 0:25 ` Alison Schofield
2022-11-11 3:12 ` [PATCH v3 6/6] tools/testing/cxl: Mock the Get Poison List mbox command alison.schofield
2022-11-16 12:52 ` Jonathan Cameron
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=Y5FeVySReYXU6E2p@aschofie-mobl2 \
--to=alison.schofield@intel.com \
--cc=bwidawsk@kernel.org \
--cc=dan.j.williams@intel.com \
--cc=dave.jiang@intel.com \
--cc=ira.weiny@intel.com \
--cc=linux-cxl@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox