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

[Ido Schimmel <idosch@nvidia.com>]

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.