On Thu, Jul 9, 2026 at 7:52 PM Greg KH <[email protected]> wrote: > > On Thu, Jul 09, 2026 at 06:35:04PM +0530, Ujjal Roy wrote: > > 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. > > > > But this really seems like a new feature being added, it's not fixing a > regression of something that previously worked, right? > > WHy can't people just update to the latest kernel release to get this if > they need it for their environments? > > thanks, > > greg k-h
This is a corner case when people set the query timer value higher than 128. People usually use the default value and don't change it, so they may not encounter this issue. But I found it when I changed the value during some extensive validation of protocol timeouts. If one host doesn't have this fix, clients will observe premature multicast group expiration. For example, a set-top box channel might disconnect early. But we can ignore this until few more people request this fix for older kernels.
