Skip to contentSkip to conversation

Clear MAF_GSQUERY flag when process MLDv1 general query messages.

PATCH In review Yan Zheng 4 participants 5 messages Nov 7, 2005 – Nov 8, 2005

Subsystems (3)
Networking Network drivers IPv4/IPv6
lore
Share & tools
lore

Yan Zheng

author
#0 lore raw

PATCH 1/1 Clear MAF_GSQUERY flag when process MLDv1 general query messages.

Hi.

MAF_GSQUERY flag may cause problem when MLDv1 compatibility mode expires.

Signed-off-by Yan Zheng <[email protected]>
net/ipv6/mcast.c +0 -0
Index: net/ipv6/mcast.c
================================================================================
@@ -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);
		}
#1 lore raw
Quoted 1 line · Yan Zheng

MAF_GSQUERY flag may cause problem when MLDv1 compatibility mode expires.

Could you be more specific about what problem it will cause?

Thanks,

John

Signature · 2 lines
John W. Linville
[email protected]
#2 lore raw
Quoted 8 lines

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

#3 lore raw

Yan Zheng <[email protected]> wrote on 11/07/2005 06:46:20 AM:

Quoted 5 lines

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
#4 lore raw
Quoted 10 lines

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.

Quoted 5 lines
                                                        +-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 .

Quoted 1 line

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