* [PATCH][MCAST]Clear MAF_GSQUERY flag when process MLDv1 general query messages.
@ 2005-11-07 14:13 Yan Zheng
2005-11-07 14:25 ` John W. Linville
0 siblings, 1 reply; 5+ messages in thread
From: Yan Zheng @ 2005-11-07 14:13 UTC (permalink / raw)
To: netdev, linux-kernel, David Stevens
Hi.
MAF_GSQUERY flag may cause problem when MLDv1 compatibility mode expires.
Signed-off-by: Yan Zheng <yanzheng@21cn.com>
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);
}
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH][MCAST]Clear MAF_GSQUERY flag when process MLDv1 general query messages.
2005-11-07 14:13 [PATCH][MCAST]Clear MAF_GSQUERY flag when process MLDv1 general query messages Yan Zheng
@ 2005-11-07 14:25 ` John W. Linville
2005-11-07 14:46 ` Yan Zheng
0 siblings, 1 reply; 5+ messages in thread
From: John W. Linville @ 2005-11-07 14:25 UTC (permalink / raw)
To: Yan Zheng; +Cc: netdev, linux-kernel, David Stevens
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
linville@tuxdriver.com
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH][MCAST]Clear MAF_GSQUERY flag when process MLDv1 general query messages.
2005-11-07 14:25 ` John W. Linville
@ 2005-11-07 14:46 ` Yan Zheng
2005-11-07 21:47 ` David Stevens
0 siblings, 1 reply; 5+ messages in thread
From: Yan Zheng @ 2005-11-07 14:46 UTC (permalink / raw)
To: Yan Zheng, netdev, linux-kernel, David Stevens
> Could you be more specific about what problem it will cause?
>
> Thanks,
>
> John
> --
> John W. Linville
> linville@tuxdriver.com
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH][MCAST]Clear MAF_GSQUERY flag when process MLDv1 general query messages.
2005-11-07 14:46 ` Yan Zheng
@ 2005-11-07 21:47 ` David Stevens
2005-11-08 0:33 ` Yan Zheng
0 siblings, 1 reply; 5+ messages in thread
From: David Stevens @ 2005-11-07 21:47 UTC (permalink / raw)
To: Yan Zheng; +Cc: linux-kernel, netdev
Yan Zheng <yzcorp@gmail.com> 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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH][MCAST]Clear MAF_GSQUERY flag when process MLDv1 general query messages.
2005-11-07 21:47 ` David Stevens
@ 2005-11-08 0:33 ` Yan Zheng
0 siblings, 0 replies; 5+ messages in thread
From: Yan Zheng @ 2005-11-08 0:33 UTC (permalink / raw)
Cc: linux-kernel, netdev
> 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
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2005-11-08 0:33 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2005-11-07 14:13 [PATCH][MCAST]Clear MAF_GSQUERY flag when process MLDv1 general query messages Yan Zheng
2005-11-07 14:25 ` John W. Linville
2005-11-07 14:46 ` Yan Zheng
2005-11-07 21:47 ` David Stevens
2005-11-08 0:33 ` Yan Zheng
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).