Re: [PATCH net v3 1/1] ipmr: only copy pktinfo to cache reports

Ido Schimmel <[email protected]>
Newsgroups org.kernel.vger.netdev
Message-ID <20260806103807.GA1818763@shredder>
On Wed, Aug 05, 2026 at 04:36:24PM -0700, Jakub Kicinski wrote:
> On Wed, 5 Aug 2026 11:17:37 +0300 Ido Schimmel wrote:
> > On Tue, Aug 04, 2026 at 06:31:26PM -0700, Jakub Kicinski wrote:
> > > This is an AI-generated review of your patch. The human sending this
> > > email says "Looks legit, let's fix both in one patch?"  
> > 
> > I suggested [1], but the bug in the IGMPMSG_WHOLEPKT /
> > IGMPMSG_WRVIFWHOLE branch needs a different Fixes tag (it precedes
> > bb7403655b3c) and Sashiko [2][3] found another bug in this code:
> > 
> > ipv4_pktinfo_prepare() modifies the control block of 'pkt', which can
> > result in this packet being processed incorrectly after
> > ipmr_cache_report() returns. I *think* that [4] takes care of it, but
> > all of this needs to be explained in the commit message which should
> > carry the appropriate Fixes tags (bb7403655b3c + 1da177e4c3f4).
> 
> TBH no strong preference on the geometry of the patches (could also 
> be two fixes in a series I guess?)  It'd be great if we could start
> grouping the sufficiently similar fixes a little bit more. Otherwise
> it's increasingly hard to make sense of the patch queue for me, if
> nothing else.
> 
> > Note that this upcall is not fast path, so the extra work shouldn't be a
> > problem.
> > 
> > Is this what you prefer?
> 
> diff looks good at a glance..

So let's go with one patch and two Fixes tags assuming Zhiling can
confirm that this diff works well and solves the reported problems.
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.