On Thu, Jul 9, 2026 at 6:23 PM Greg KH <[email protected]> wrote: > > On Thu, Jul 09, 2026 at 06:12:40PM +0530, Ujjal Roy wrote: > > On Thu, Jul 9, 2026 at 4:34 PM Greg KH <[email protected]> wrote: > > > > > > On Thu, Jul 09, 2026 at 10:13:27AM +0000, Ujjal Roy wrote: > > > > Hi Greg, > > > > > > > > Please consider backporting the following bridge multicast fix series > > > > to 6.1.y, 6.6.y, 6.12.y, 6.18.y and 7.0.y. > > > > > > > > 726fa7da2d8c ("ipv4: igmp: get rid of IGMPV3_{QQIC,MRC} and simplify > > > > calculation") > > > > 12cfb4ecc471 ("ipv6: mld: rename mldv2_mrc() and add mldv2_qqi()") > > > > 95bfd196f0dc ("ipv4: igmp: encode multicast exponential fields") > > > > e51560f4220a ("ipv6: mld: encode multicast exponential fields") > > > > 529dbe762de0 ("selftests: net: bridge: add MRC and QQIC field encoding > > > > tests") > > > > > > Why is any of this needed in older kernels? > > > > > > And 7.0.y is long end-of-life. > > > > > > And why, if this does fix issues, was it not tagged for stable to start > > > with? > > > > > > thanks, > > > > > > greg k-h > > > > I already explained this in the email thread, "Please backport bridge > > multicast exponential field encoding fix series to stable kernels". > > Sorry, but that's not here (remember, some of us get 1000+ emails a > day.) > > Please explain why patches need to be backported when asking for them to > be backported. > > thanks, > > greg k-h
Sorry for breaking the thread. I understand your point, I will maintain this in the future. How should I send the patchset that addresses the conflicts on 5.10.y and 7.1.y? Shall I send the conflicts patchset as a series via a different thread or how? I've never done this before, so I'm asking. Here is the explanation for why the patches need to be backported: History: The multicast stack currently supports decoding of IGMPv3 and MLDv2 exponential timer field encodings, but lacks the corresponding encoding logic when generating multicast query packets. As a result, query intervals and response codes exceeding the linear encoding range can be transmitted incorrectly. This can cause multicast queriers and listeners to interpret different timing values, resulting in protocol interoperability issues, membership timeouts, and premature multicast group expiration. Testing: The series adds the missing encoding support for both IGMPv3 and MLDv2 and includes selftests that validate the behavior. I backported the series to v6.6.123.2 and verified the accompanying selftests. The selftests fail on the unpatched kernel and pass after applying the series, demonstrating both the bug and the effectiveness of the fix. Given that this is a protocol correctness issue affecting multicast query generation, please consider backporting the complete series to all applicable stable kernels.
