All of lore.kernel.org
 help / color / mirror / Atom feed
From: Patrick Williams <patrick@stwcx.xyz>
To: Jeremy Kerr <jk@codeconstruct.com.au>
Cc: 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>,
	netdev@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] net: mctp: fix infinite data from mctp_dump_addrinfo
Date: Mon, 9 Jun 2025 08:54:59 -0400	[thread overview]
Message-ID: <aEbZoxqFBnd0Pr32@heinlein> (raw)
In-Reply-To: <575fa12e699f6f65b47f5b776ec91ef9c350644a.camel@codeconstruct.com.au>

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

On Sat, Jun 07, 2025 at 03:47:09PM +0800, Jeremy Kerr wrote:
> 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.

Ah, yep.  That's exactly what is going on here.  I guess this change
isn't needed for master and it looks like you've already requested a
revert for 6.6?

-- 
Patrick Williams

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

      reply	other threads:[~2025-06-09 12:55 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
2025-06-09 12:54     ` Patrick Williams [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=aEbZoxqFBnd0Pr32@heinlein \
    --to=patrick@stwcx.xyz \
    --cc=andrew@codeconstruct.com.au \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=horms@kernel.org \
    --cc=jk@codeconstruct.com.au \
    --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=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.