From: "William A. Kennington III" <william@wkennington.com>
To: Jeremy Kerr <jk@codeconstruct.com.au>,
Matt Johnston <matt@codeconstruct.com.au>,
Andrew Lunn <andrew+netdev@lunn.ch>,
"David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
Wolfram Sang <wsa@kernel.org>
Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] mctp i2c: check packet length before marking flow active
Date: Wed, 22 Apr 2026 23:55:21 -0700 [thread overview]
Message-ID: <c94fc7c9-279b-4b4b-92f3-7f1b88bc0c64@wkennington.com> (raw)
In-Reply-To: <61bb1b3838609996600f46ccb2c4ff89d085ee6f.camel@codeconstruct.com.au>
On 4/22/26 20:47, Jeremy Kerr wrote:
> Hi William,
>
>> Move the mctp_i2c_get_tx_flow_state() call to after the length sanity
>> check to ensure we only transition the flow state if we are actually
>> going to proceed with the transmission and locking.
> Good catch, thanks!
>
>> Subject: [PATCH] mctp i2c: check packet length before marking flow active
> You'll want to indicate that this is for the net tree, rather than
> net-next, so something like:
>
> Subject: [PATCH net] net: mctp i2c: check packet length [...]
Thanks, forgot the convention...
>
> With that change:
>
> Acked-by: Jeremy Kerr <jk@codeconstruct.com.au>
>
> Out of curiosity though, how did you hit the hdr_byte_count mismatch in
> the first place?
Our current theory is that we have known buggy firmware on our NVME MCTP
devices and we are seeing some kind of corruption on the bus that we are
going to fix in on the firmware side. We started also seeing kernel
crashes along with the bad firmware symptoms, walked through ~110 kdumps
and found i2c locks that were held by 2 owners (eeprom reading and the
MCTP TX queue). This ended up causing deadlocks in the i2c stack that
result in panics. We noticed in many of these cases that we had 10K+
BERs and 800+ NACKs in the i2c driver stats struct at the time of crash.
>
> Cheers,
>
>
> Jeremy
next prev parent reply other threads:[~2026-04-23 6:55 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-23 0:15 [PATCH] mctp i2c: check packet length before marking flow active William A. Kennington III
2026-04-23 3:47 ` Jeremy Kerr
2026-04-23 6:55 ` William A. Kennington III [this message]
2026-04-23 7:46 ` [PATCH net v2] net: mctp i2c: check " William A. Kennington III
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=c94fc7c9-279b-4b4b-92f3-7f1b88bc0c64@wkennington.com \
--to=william@wkennington.com \
--cc=andrew+netdev@lunn.ch \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=jk@codeconstruct.com.au \
--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=wsa@kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox