Skip to contentSkip to conversation

iproute u32 filter - server hang

DISCUSSION Paweł Staszewski 2 participants 6 messages Mar 31, 2010

Subsystems (3)
Networking Network drivers Traffic control (tc)
lore
Share & tools
lore

Paweł Staszewski

author
#0 lore raw

I find some problem with iproute2 and u32 filters

To reproduce the problem (need to make one mistake in filter parent declaration 1:101):

tc qdisc add dev eth0 root handle 1: hfsc default 63
tc class add dev eth0 parent 1: classid 1:1 hfsc sc rate 100mbit ul rate 100mbit tc class add dev eth0 parent 1:1 classid 1:2 hfsc sc rate 1mbit ul rate 1mbit tc class add dev eth0 parent 1:1 classid 1:63 hfsc sc rate 99mbit ul rate 99mbit tc class add dev eth0 parent 1:1 classid 1:101 hfsc sc rate 8kbit ul rate 1mbit tc class add dev eth0 parent 1:101 classid 1:102 hfsc sc rate 8kbit ul rate 1mbit tc filter add dev eth0 protocol ip parent 1: u32 match ip dst 212.77.100.101 flowid 1:101 tc filter add dev eth0 protocol ip parent 1:101 u32 match ip protocol 1 0xff flowid 1:101

ping 212.77.100.101
And after this server will stop responding to anything - without any error (hang).

With a little different rules:
tc qdisc add dev eth0 root handle 1: hfsc default 63
tc class add dev eth0 parent 1: classid 1:1 hfsc sc rate 100mbit ul rate 100mbit tc class add dev eth0 parent 1:1 classid 1:2 hfsc sc rate 1mbit ul rate 1mbit tc class add dev eth0 parent 1:1 classid 1:63 hfsc sc rate 99mbit ul rate 99mbit tc class add dev eth0 parent 1:1 classid 1:101 hfsc sc rate 8kbit ul rate 1mbit tc class add dev eth0 parent 1:101 classid 1:102 hfsc sc rate 8kbit ul rate 1mbit tc filter add dev eth0 protocol ip parent 1: u32 match ip dst 212.77.100.101 flowid 1:101 tc filter add dev eth0 protocol ip parent 1: u32 match ip protocol 1 0xff flowid 1:101

ping 212.77.100.101
All is ok.

I check this with kernels 2.6.30.1 / 2.6.33 / 2.6.33.1 iproute tc utility version: iproute2-ss090324

Best Regards
Paweł Staszewski

#1 lore raw
Quoted 5 lines · Paweł Staszewski

I find some problem with iproute2 and u32 filters

To reproduce the problem (need to make one mistake in filter parent declaration 1:101):

Quoted 7 lines

...
tc filter add dev eth0 protocol ip parent 1:101 u32 match ip protocol 1 0xff flowid 1:101

ping 212.77.100.101
And after this server will stop responding to anything - without any error (hang).

This is caused by hfsc_classify() looping endlessly since the filter points to the originating class. hfsc_bind_tcf() is actually supposed to prevent this, but it only prevents resolving the filter immediately and we still run into the loop at runtime.

This patch (based on how CBQ handles this) should abort classification and fall back to the default class. It would be better to simply catch this at configuration time, but that looks a bit more involved. I'll try to look into it this weekend.

net/sched/sch_hfsc.c +5 -1
index b38b39c..a435cf1 100644
@@ -1155,7 +1155,7 @@ static struct hfsc_class *
 hfsc_classify(struct sk_buff *skb, struct Qdisc *sch, int *qerr)
 {
 	struct hfsc_sched *q = qdisc_priv(sch);
-	struct hfsc_class *cl;
+	struct hfsc_class *head, *cl;
 	struct tcf_result res;
 	struct tcf_proto *tcf;
 	int result;

@@ -1166,6 +1166,7 @@ hfsc_classify(struct sk_buff *skb, struct Qdisc *sch, int *qerr)
 			return cl;
 
 	*qerr = NET_XMIT_SUCCESS | __NET_XMIT_BYPASS;
+	head = &q->root;
 	tcf = q->root.filter_list;
 	while (tcf && (result = tc_classify(skb, tcf, &res)) >= 0) {
 #ifdef CONFIG_NET_CLS_ACT

@@ -1180,6 +1181,8 @@ hfsc_classify(struct sk_buff *skb, struct Qdisc *sch, int *qerr)
 		if ((cl = (struct hfsc_class *)res.class) == NULL) {
 			if ((cl = hfsc_find_class(res.classid, sch)) == NULL)
 				break; /* filter selected invalid classid */
+			if (cl->level >= head->level)
+				break; /* filter may only point downwards */
 		}
 
 		if (cl->level == 0)

@@ -1187,6 +1190,7 @@ hfsc_classify(struct sk_buff *skb, struct Qdisc *sch, int *qerr)
 
 		/* apply inner filter chain */
 		tcf = cl->filter_list;
+		head = cl;
 	}
 
 	/* classification failed, try default class */
author
#2 lore raw

W dniu 2010-03-31 11:34, Patrick McHardy pisze:

Quoted 20 lines
Quoted 5 lines · Paweł Staszewski

I find some problem with iproute2 and u32 filters

To reproduce the problem (need to make one mistake in filter parent declaration 1:101):

Quoted 8 lines

...
tc filter add dev eth0 protocol ip parent 1:101 u32 match ip protocol 1 0xff flowid 1:101

ping 212.77.100.101
And after this server will stop responding to anything - without any error (hang).

This is caused by hfsc_classify() looping endlessly since the filter points to the originating class. hfsc_bind_tcf() is actually supposed to prevent this, but it only prevents resolving the filter immediately and we still run into the loop at runtime.

Quoted 7 lines

This patch (based on how CBQ handles this) should abort classification and fall back to the default class. It would be better to simply catch this at configuration time, but that looks a bit more involved. I'll try to look into it this weekend.

I check this also with htb and the same problem like with hfsc. This rules also hang my server.

tc qdisc del dev eth4 root
tc qdisc add dev eth4 root handle 1: htb default 63
tc class add dev eth4 parent 1: classid 1:1 htb rate 100mbit ceil 100mbit tc class add dev eth4 parent 1:1 classid 1:2 htb rate 1mbit ceil 1mbit
tc class add dev eth4 parent 1:1 classid 1:63 htb rate 99mbit ceil 99mbit tc class add dev eth4 parent 1:1 classid 1:101 htb rate 8kbit ceil 1mbit
tc class add dev eth4 parent 1:101 classid 1:102 htb rate 8kbit ceil 1mbit tc filter add dev eth4 protocol ip parent 1: u32 match ip dst 212.77.100.101 flowid 1:101 tc filter add dev eth4 protocol ip parent 1:101 u32 match ip protocol 1 0xff flowid 1:101

#3 lore raw
Quoted 28 lines · Paweł Staszewski

W dniu 2010-03-31 11:34, Patrick McHardy pisze:

Quoted 20 lines
Quoted 5 lines · Paweł Staszewski

I find some problem with iproute2 and u32 filters

To reproduce the problem (need to make one mistake in filter parent declaration 1:101):

Quoted 8 lines

...
tc filter add dev eth0 protocol ip parent 1:101 u32 match ip protocol 1 0xff flowid 1:101

ping 212.77.100.101
And after this server will stop responding to anything - without any error (hang).

This is caused by hfsc_classify() looping endlessly since the filter points to the originating class. hfsc_bind_tcf() is actually supposed to prevent this, but it only prevents resolving the filter immediately and we still run into the loop at runtime.

Quoted 7 lines

This patch (based on how CBQ handles this) should abort classification and fall back to the default class. It would be better to simply catch this at configuration time, but that looks a bit more involved. I'll try to look into it this weekend.

Quoted 2 lines

I check this also with htb and the same problem like with hfsc. This rules also hang my server.

Yes, HTB doesn't even catch loops when binding filters. As I said, its a larger piece of work, for now please just try the patch I sent.

author
#4 lore raw

W dniu 2010-03-31 11:46, Patrick McHardy pisze:

Quoted 34 lines
Quoted 32 lines · Paweł Staszewski

W dniu 2010-03-31 11:34, Patrick McHardy pisze:

Quoted 30 lines
Quoted 5 lines · Paweł Staszewski

I find some problem with iproute2 and u32 filters

To reproduce the problem (need to make one mistake in filter parent declaration 1:101):

Quoted 9 lines

...
tc filter add dev eth0 protocol ip parent 1:101 u32 match ip protocol 1 0xff flowid 1:101

ping 212.77.100.101
And after this server will stop responding to anything - without any error (hang).

This is caused by hfsc_classify() looping endlessly since the filter points to the originating class. hfsc_bind_tcf() is actually supposed to prevent this, but it only prevents resolving the filter immediately and we still run into the loop at runtime.

This patch (based on how CBQ handles this) should abort classification and fall back to the default class. It would be better to simply catch this at configuration time, but that looks a bit more involved. I'll try to look into it this weekend.

Quoted 7 lines
Quoted 3 lines

I check this also with htb and the same problem like with hfsc. This rules also hang my server.

Yes, HTB doesn't even catch loops when binding filters. As I said, its a larger piece of work, for now please just try the patch I sent.

Yes.
Your patch fix this problem.

Thanks
Paweł

Quoted 7 lines

--
To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

#5 lore raw
Quoted 27 lines · Paweł Staszewski

W dniu 2010-03-31 11:46, Patrick McHardy pisze:

Quoted 26 lines
Quoted 26 lines
Quoted 14 lines
Quoted 9 lines

tc filter add dev eth0 protocol ip parent 1:101 u32 match ip protocol 1
0xff flowid 1:101

ping 212.77.100.101
And after this server will stop responding to anything - without any error (hang).

This is caused by hfsc_classify() looping endlessly since the filter points to the originating class. hfsc_bind_tcf() is actually supposed to prevent this, but it only prevents resolving the filter immediately and we still run into the loop at runtime.

Quoted 9 lines

This patch (based on how CBQ handles this) should abort classification and fall back to the default class. It would be better to simply catch this at configuration time, but that looks a bit more involved. I'll try
to look into it this weekend.

I check this also with htb and the same problem like with hfsc. This rules also hang my server.

Quoted 7 lines
Quoted 4 lines

Yes, HTB doesn't even catch loops when binding filters. As I said, its a larger piece of work, for now please just try the patch I sent.

Yes.
Your patch fix this problem.

Thanks for testing, I'll let you know once I have a complete patch for this problem.