public inbox for netdev@vger.kernel.org
 help / color / mirror / Atom feed
From: Jeremy Kerr <jk@codeconstruct.com.au>
To: wit_yuan <yuanzhaoming901030@126.com>
Cc: yuanzm2@lenovo.com, matt@codeconstruct.com.au,
	davem@davemloft.net,  edumazet@google.com, kuba@kernel.org,
	pabeni@redhat.com, netdev@vger.kernel.org,
	 linux-kernel@vger.kernel.org
Subject: Re: [PATCH next-next v2] net:mctp: fix setting mctp hdr ver reserved field cause  data dropped
Date: Fri, 10 Apr 2026 15:05:43 +0800	[thread overview]
Message-ID: <071438dea6e35df4a313142c91aaa9673179ab98.camel@codeconstruct.com.au> (raw)
In-Reply-To: <20260410061703.3547-2-yuanzhaoming901030@126.com>

Hi,

Looks like a better approach, thanks for the improvements, including the
net-next patch prefix.

I would suggest reading up on the contribution guidelines too:

 https://docs.kernel.org/process/maintainer-netdev.html

(in this case, the 24 hour spacing between revisions).

> Subject: [PATCH next-next v2] net:mctp: fix setting mctp hdr ver reserved
>   field cause  data dropped

Add a space between the 'net:mctp:'. That should be 'net: mctp: [...]'

And perhaps a tweak to the wording, giving:

  net: mctp: don't require received header reserved bits to be zero

> From: Yuan Zhaoming <yuanzm2@lenovo.com>
> 
> from spec dsp0236_1.2.1.pdf page 26, the mctp header contains the
> RSVD(4bit) and Hdr version(4 bit).

Some wording things there - It would be more clear to reference the spec
by name, rather than by filename, giving something like:

  From the MCTP Base specification (DSP0236 v1.2.1), the first byte of
  the MCTP header contains a 4 bit reserved field, and 4 bit version.

Then, explain the current issue:

  On our current receive path, we require those 4 reserved bits to be
  zero, but at least one device is non-conformant, and may set these
  reserved bits.

[If you can name the specific device, that will certainly help others
with future debugging. I assume the device is currently public?]

Then, maybe some rationale about the change, and an overview of the
implementation:

  DSP0236 states that the reserved bits must be written as zero, and
  ignored when read. While the device might not conform to the former,
  we should accept these message to conform to the latter.

  Relax our check on the MCTP version byte to allow non-zero bits in the
  reserved field.

  Signed-off-by: ...

> mctp_pkttype_receive invoke mctp_hdr, and get mh->ver whole byte 
> compare the MCTP_VER_MIN, MCTP_VER_MAX. the reserver bits may be by 
> misleading used.

This is no longer relevant for the new revision.

> @@ -35,6 +35,7 @@ struct mctp_hdr {
>  #define MCTP_HDR_SEQ_MASK      GENMASK(1, 0)
>  #define MCTP_HDR_TAG_SHIFT     0
>  #define MCTP_HDR_TAG_MASK      GENMASK(2, 0)
> +#define MCTP_HDR_VER_MASK      GENMASK(3, 0)

This section of #defines is commented to represent the flags/seq/tag
field. I would prefer to move this definition above that comment.

>  
>  #define MCTP_INITIAL_DEFAULT_NET       1
>  
> diff --git a/net/mctp/route.c b/net/mctp/route.c
> index 56c441e90..aa0e89d67 100644
> --- a/net/mctp/route.c
> +++ b/net/mctp/route.c
> @@ -464,7 +464,7 @@ static int mctp_dst_input(struct mctp_dst *dst, struct sk_buff *skb)
>         netid = mctp_cb(skb)->net;
>         skb_pull(skb, sizeof(struct mctp_hdr));
>  
> -       if (mh->ver != 1)
> +       if (((mh->ver & MCTP_HDR_VER_MASK)) < MCTP_VER_MIN || (mh->ver & MCTP_HDR_VER_MASK) > MCTP_VER_MAX)

Use a temporary for the version, rather than repeating the mask
operation. This makes the conditional much easier to read:

    if (ver < MCTP_VER_MIN || ver > MCTP_VER_MAX)

Cheers,


Jeremy

  reply	other threads:[~2026-04-10  7:05 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-04-09 12:51 [PATCH] net:mctp: split mctp hdr version to ver and rsvd wit_yuan
2026-04-10  0:13 ` Jeremy Kerr
2026-04-10  6:17   ` wit_yuan
2026-04-10  6:17     ` [PATCH next-next v2] net:mctp: fix setting mctp hdr ver reserved field cause data dropped wit_yuan
2026-04-10  7:05       ` Jeremy Kerr [this message]
     [not found] <ff147a3f0d27ef2aa6026cc86f9113d56a8c61ac.camel@codeconstruct.com.au/T/#rc39d8ae7e5ee7e74556d16fc836cc9f2bf745701>
2026-04-10  6:09 ` wit_yuan
2026-04-10  6:09   ` [PATCH next-next v2] net:mctp: fix setting mctp hdr ver reserved field cause data dropped wit_yuan
2026-04-10  6:33     ` wit_yuan
2026-04-10  6:33       ` [PATCH next-next v2] net:mctp: fix setting mctp hdr ver reserved field cause data dropped wit_yuan

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=071438dea6e35df4a313142c91aaa9673179ab98.camel@codeconstruct.com.au \
    --to=jk@codeconstruct.com.au \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=matt@codeconstruct.com.au \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=yuanzhaoming901030@126.com \
    --cc=yuanzm2@lenovo.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