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.