All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jonathan Cameron <Jonathan.Cameron@Huawei.com>
To: Robert Richter <rrichter@amd.com>
Cc: Alison Schofield <alison.schofield@intel.com>,
	Vishal Verma <vishal.l.verma@intel.com>,
	Ira Weiny <ira.weiny@intel.com>,
	Ben Widawsky <bwidawsk@kernel.org>,
	Dan Williams <dan.j.williams@intel.com>,
	Dave Jiang <dave.jiang@intel.com>, <linux-cxl@vger.kernel.org>,
	<linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v2] cxl/mbox: Fix Payload Length check for Get Log command
Date: Fri, 13 Jan 2023 14:10:10 +0000	[thread overview]
Message-ID: <20230113141010.000075d8@Huawei.com> (raw)
In-Reply-To: <Y8FfNA2Se9UIVJAJ@rric.localdomain>

On Fri, 13 Jan 2023 14:40:04 +0100
Robert Richter <rrichter@amd.com> wrote:

> On 13.01.23 11:53:54, Jonathan Cameron wrote:
> > On Wed, 4 Jan 2023 21:29:54 +0100
> > Robert Richter <rrichter@amd.com> wrote:
> >   
> > > Commit 2aeaf663b85e introduced strict checking for variable length
> > > payload size validation. The payload length of received data must
> > > match the size of the requested data by the caller except for the case
> > > where the min_out value is set.
> > > 
> > > The Get Log command does not have a header with a length field set.
> > > The Log size is determined by the Get Supported Logs command (CXL 3.0,
> > > 8.2.9.5.1). However, the actual size can be smaller and the number of
> > > valid bytes in the payload output must be determined reading the
> > > Payload Length field (CXL 3.0, Table 8-36, Note 2).
> > > 
> > > Two issues arise: The command can successfully complete with a payload
> > > length of zero. And, the valid payload length must then also be
> > > consumed by the caller.
> > > 
> > > Change cxl_xfer_log() to pass the number of payload bytes back to the
> > > caller to determine the number of log entries. Implement the payload
> > > handling as a special case where mbox_cmd->size_out is consulted when
> > > cxl_internal_send_cmd() returns -EIO. A WARN_ONCE() is added to check
> > > that -EIO is only returned in case of an unexpected output size.
> > > 
> > > Logs can be bigger than the maximum payload length and multiple Get
> > > Log commands can be issued. If the received payload size is smaller
> > > than the maximum payload size we can assume all valid bytes have been
> > > fetched. Stop sending further Get Log commands then.
> > > 
> > > On that occasion, change debug messages to also report the opcodes of
> > > supported commands.
> > > 
> > > The variable payload commands GET_LSA and SET_LSA could be also
> > > affected by this strict check, but SET_LSA cannot be broken because
> > > SET_LSA does not return an output payload, and GET_LSA never expects
> > > short reads.
> > > 
> > > Fixes: 2aeaf663b85e ("cxl/mbox: Add variable output size validation for internal commands")
> > > Signed-off-by: Robert Richter <rrichter@amd.com>  
> > Hi Robert, a few comments inline.  
> 
> Oh, just found your comments here after replying to the other mail
> thread.
> 
> > 
> > Thanks,
> > 
> > Jonathan
> >   
> > > ---
> > >  drivers/cxl/core/mbox.c | 28 ++++++++++++++++++++--------
> > >  1 file changed, 20 insertions(+), 8 deletions(-)
> > > 
> > > diff --git a/drivers/cxl/core/mbox.c b/drivers/cxl/core/mbox.c
> > > index b03fba212799..e93df0d39022 100644
> > > --- a/drivers/cxl/core/mbox.c
> > > +++ b/drivers/cxl/core/mbox.c
> > > @@ -170,6 +170,8 @@ int cxl_internal_send_cmd(struct cxl_dev_state *cxlds,
> > >  	out_size = mbox_cmd->size_out;
> > >  	min_out = mbox_cmd->min_out;
> > >  	rc = cxlds->mbox_send(cxlds, mbox_cmd);
> > > +	if (WARN_ONCE(rc == -EIO, "Bad return code: -EIO"))  
> > 
> > This is unusual. Why the WARN_ONCE?  How can an error code
> > be bad?  It may well panic.  Fine to have a dev_err() or similar
> > but this seems excessive.  
> 
> This function should only return -EIO if the size is unexpected. The
> mbox_send() function doesn't have a size information and should never
> return with -EIO. I think a comment is need here?

Makes sense.  A comment so we don't forget the reasoning would be great.

Thanks,

Jonathan



      reply	other threads:[~2023-01-13 14:14 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-04 20:29 [PATCH v2] cxl/mbox: Fix Payload Length check for Get Log command Robert Richter
2023-01-13 11:53 ` Jonathan Cameron
2023-01-13 13:40   ` Robert Richter
2023-01-13 14:10     ` Jonathan Cameron [this message]

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=20230113141010.000075d8@Huawei.com \
    --to=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=ira.weiny@intel.com \
    --cc=linux-cxl@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rrichter@amd.com \
    --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.