From: Jeremy Kerr <jk@codeconstruct.com.au>
To: Patrick Williams <patrick@stwcx.xyz>,
Matt Johnston <matt@codeconstruct.com.au>,
"David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
Simon Horman <horms@kernel.org>,
Kuniyuki Iwashima <kuniyu@amazon.com>,
Peter Yin <peteryin.openbmc@gmail.com>,
Andrew Jeffery <andrew@codeconstruct.com.au>
Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] net: mctp: fix infinite data from mctp_dump_addrinfo
Date: Sat, 07 Jun 2025 15:47:09 +0800 [thread overview]
Message-ID: <575fa12e699f6f65b47f5b776ec91ef9c350644a.camel@codeconstruct.com.au> (raw)
In-Reply-To: <0ee86d6d80c08f6dce6422503b247a253fa75874.camel@codeconstruct.com.au>
Hi Patrick,
[+CC Andrew, for openbmc kernel reasons]
> So, it seems like there's something more subtle happening here - or I
> have misunderstood something about the fix (I'm unsure of the
> reference to xa_for_each_start; for_each_netdev_dump only calls xa_start?).
Ah! Are you on the openbmc 6.6 backport perhaps?
It look the xa_for_each_start()-implementation of netdev_for_each_dump()
would not be compatible with a direct backport of 2d20773aec14 ("mctp: no
longer rely on net->dev_index_head[]").
This was the update for the for_each_netdev_dump() macro:
commit f22b4b55edb507a2b30981e133b66b642be4d13f
Author: Jakub Kicinski <kuba@kernel.org>
Date: Thu Jun 13 14:33:16 2024 -0700
net: make for_each_netdev_dump() a little more bug-proof
I find the behavior of xa_for_each_start() slightly counter-intuitive.
It doesn't end the iteration by making the index point after the last
element. IOW calling xa_for_each_start() again after it "finished"
will run the body of the loop for the last valid element, instead
of doing nothing.
... which sounds like what's happening here.
Cheers,
Jeremy
next prev parent reply other threads:[~2025-06-07 7:47 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-06-06 11:11 [PATCH] net: mctp: fix infinite data from mctp_dump_addrinfo Patrick Williams
2025-06-07 7:10 ` Jeremy Kerr
2025-06-07 7:47 ` Jeremy Kerr [this message]
2025-06-09 12:54 ` Patrick Williams
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=575fa12e699f6f65b47f5b776ec91ef9c350644a.camel@codeconstruct.com.au \
--to=jk@codeconstruct.com.au \
--cc=andrew@codeconstruct.com.au \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=horms@kernel.org \
--cc=kuba@kernel.org \
--cc=kuniyu@amazon.com \
--cc=linux-kernel@vger.kernel.org \
--cc=matt@codeconstruct.com.au \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=patrick@stwcx.xyz \
--cc=peteryin.openbmc@gmail.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.