Hi.
MAF_GSQUERY flag may cause problem when MLDv1 compatibility mode expires.
Signed-off-by: Yan Zheng <[email protected]>
Index: net/ipv6/mcast.c
================================================================================
--- linux-2.6.14/net/ipv6/mcast.c 2005-11-05 09:09:47.000000000 +0800
+++ linux/net/ipv6/mcast.c 2005-11-07 21:57:27.000000000 +0800
@@ -1166,6 +1166,7 @@ int igmp6_event_query(struct sk_buff *sk
if (group_type == IPV6_ADDR_ANY) {
for (ma = idev->mc_list; ma; ma=ma->next) {
spin_lock_bh(&ma->mca_lock);
+ ma->mca_flags &= ~MAF_GSQUERY;
igmp6_group_queried(ma, max_delay);
spin_unlock_bh(&ma->mca_lock);
}
On Mon, Nov 07, 2005 at 10:13:34PM +0800, Yan Zheng wrote:
> MAF_GSQUERY flag may cause problem when MLDv1 compatibility mode expires.
Could you be more specific about what problem it will cause?
Thanks,
John
--
John W. Linville
[email protected]
> Could you be more specific about what problem it will cause?
>
> Thanks,
>
> John
> --
> John W. Linville
> [email protected]
If the first query message receive after expiration is MLDv2 general
query and MAF_GSQUERY flag is set. The report message only contains
sources marked by last MLDv2 Multicast Address and Source Specific
Queries . Although this circumstance happens rare, I think it's
better have it fixed
Regards
Yan Zheng <[email protected]> wrote on 11/07/2005 06:46:20 AM:
> If the first query message receive after expiration is MLDv2 general
> query and MAF_GSQUERY flag is set. The report message only contains
> sources marked by last MLDv2 Multicast Address and Source Specific
> Queries . Although this circumstance happens rare, I think it's
> better have it fixed
Do you have a test case that demonstrates this? It appears to
me that an MLDv2 general query doesn't execute that code (short circuited
above) and an MLDv1 general query (what that code is handling) will
have a timer expiring before switching back to MLDv2 mode (so it'll send
a v1 report, without any sources). Unless I'm missing something, I can't
see any way for the scenario you've described to happen.
That said, I also can't see anything it would hurt, so I don't
object,
but it looks unnecessary to me.
+-DLS
> Do you have a test case that demonstrates this? It appears to
> me that an MLDv2 general query doesn't execute that code (short circuited
> above) and an MLDv1 general query (what that code is handling) will
> have a timer expiring before switching back to MLDv2 mode (so it'll send
> a v1 report, without any sources). Unless I'm missing something, I can't
> see any way for the scenario you've described to happen.
> That said, I also can't see anything it would hurt, so I don't
> object,
> but it looks unnecessary to me.
>
> +-DLS
>
>
>MLDv2 general query doesn't execute that code
Yes, MLDv2 general query also leave that bit unchanged. In MLDv1
compatibility mode, igmp6_timer_handler(...) uses igmp6_send(...) to
send report, it leaves that bit unchanged too. So when switching back
to MLDv2 mode, MAF_GSQUERY flag set long time ago may have effect on
the report .
>That said, I also can't see anything it would hurt
I agree with you. it hurts nothing but a report.
By the way. May I ask a question.
Do you agree my change on is_in(...)? That is check include/exclude
count when type is MLD2_MODE_IS_INCLUDE or MLD2_MODE_IS_EXCLUDE.
(especially for MLD2_MODE_IS_EXCLUDE)
Regards