All of lore.kernel.org
 help / color / mirror / Atom feed
From: Klaus Jensen <its@irrelevant.dk>
To: Corey Minyard <minyard@acm.org>
Cc: qemu-devel@nongnu.org, "Corey Minyard" <cminyard@mvista.com>,
	"Jeremy Kerr" <jk@codeconstruct.com.au>,
	qemu-arm@nongnu.org, "Peter Delevoryas" <peter@pjd.dev>,
	"Keith Busch" <kbusch@kernel.org>,
	"Cédric Le Goater" <clg@kaod.org>,
	"Jason Wang" <jasowang@redhat.com>,
	"Lior Weintraub" <liorw@pliops.com>,
	qemu-block@nongnu.org, "Peter Maydell" <peter.maydell@linaro.org>,
	"Matt Johnston" <matt@codeconstruct.com.au>,
	"Jonathan Cameron" <Jonathan.Cameron@huawei.com>,
	"Klaus Jensen" <k.jensen@samsung.com>
Subject: Re: [PATCH v2 1/3] hw/i2c: add mctp core
Date: Wed, 26 Apr 2023 09:11:16 +0200	[thread overview]
Message-ID: <ZEjOlBlEH3KH8f6d@cormorant.local> (raw)
In-Reply-To: <ZEfvkWCbJoKGIOnT@minyard.net>

[-- Attachment #1: Type: text/plain, Size: 1527 bytes --]

On Apr 25 10:19, Corey Minyard wrote:
> On Tue, Apr 25, 2023 at 08:35:38AM +0200, Klaus Jensen wrote:
> > From: Klaus Jensen <k.jensen@samsung.com>
> > 
> > Add an abstract MCTP over I2C endpoint model. This implements MCTP
> > control message handling as well as handling the actual I2C transport
> > (packetization).
> > 
> > Devices are intended to derive from this and implement the class
> > methods.
> > 
> > Parts of this implementation is inspired by code[1] previously posted by
> > Jonathan Cameron.
> 
> All in all this looks good.  Two comments:
> 
> I would like to see the buffer handling consolidated into one function
> and the length checked, even for (especially for) the outside users of
> this code, like the nvme code.  Best to avoid future issues with buffer
> overruns.  This will require reworking the get_message_types function,
> unfortunately.
> 

Right now the implementations (i.e. hw/nvme/nmi-i2c.c) writes directly
into the mctp core buffer for get_message_bytes(). The contract is that
it must not write more than the `maxlen` parameter. Is that bad? Would
it be better that get_message_bytes() returned a pointer to its own
buffer that hw/mctp can then copy from?

> You have one trace function on a bad receive message check, but lots of
> other bad receive message checks with no trace.  Just a suggestion, but
> it might be nice for tracking down issues to trace all the reasons a
> message is dropped.
> 

Sounds reasonable! :)

Thanks for the review!

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

  reply	other threads:[~2023-04-26  7:12 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-04-25  6:35 [PATCH v2 0/3] hw/{i2c, nvme}: mctp endpoint, nvme management interface model Klaus Jensen
2023-04-25  6:35 ` [PATCH v2 1/3] hw/i2c: add mctp core Klaus Jensen
2023-04-25 15:19   ` Corey Minyard
2023-04-26  7:11     ` Klaus Jensen [this message]
2023-04-26 11:52       ` Corey Minyard
2023-05-25 11:27   ` Jonathan Cameron via
2023-05-25 11:27     ` Jonathan Cameron via
2023-05-25 11:33     ` Klaus Jensen
2023-04-25  6:35 ` [PATCH v2 2/3] i2c/mctp: Allow receiving messages to dest eid 0 Klaus Jensen
2023-05-25 11:29   ` Jonathan Cameron via
2023-05-25 11:29     ` Jonathan Cameron via
2023-04-25  6:35 ` [PATCH v2 3/3] hw/nvme: add nvme management interface model Klaus Jensen
2023-05-25 11:34   ` Jonathan Cameron via
2023-05-25 11:34     ` Jonathan Cameron via

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=ZEjOlBlEH3KH8f6d@cormorant.local \
    --to=its@irrelevant.dk \
    --cc=Jonathan.Cameron@huawei.com \
    --cc=clg@kaod.org \
    --cc=cminyard@mvista.com \
    --cc=jasowang@redhat.com \
    --cc=jk@codeconstruct.com.au \
    --cc=k.jensen@samsung.com \
    --cc=kbusch@kernel.org \
    --cc=liorw@pliops.com \
    --cc=matt@codeconstruct.com.au \
    --cc=minyard@acm.org \
    --cc=peter.maydell@linaro.org \
    --cc=peter@pjd.dev \
    --cc=qemu-arm@nongnu.org \
    --cc=qemu-block@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    /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.