| Message ID | 4BB31731.9060104@trash.net |
|---|---|
| State | RFC, archived |
| Delegated to: | David Miller |
| Headers | show |
W dniu 2010-03-31 11:34, Patrick McHardy pisze: > Paweł Staszewski wrote: > >> 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 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. > > > 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 -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Paweł Staszewski wrote: > W dniu 2010-03-31 11:34, Patrick McHardy pisze: >> Paweł Staszewski wrote: >> >>> 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 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. >> >> >> > 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. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
W dniu 2010-03-31 11:46, Patrick McHardy pisze: > Paweł Staszewski wrote: > >> W dniu 2010-03-31 11:34, Patrick McHardy pisze: >> >>> Paweł Staszewski wrote: >>> >>> >>>> 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 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. >>> >>> >>> >>> >> 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ł > -- > To unsubscribe from this list: send the line "unsubscribe netdev" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > > > -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Paweł Staszewski wrote: > W dniu 2010-03-31 11:46, Patrick McHardy pisze: >>>>> 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. >>>> >>>> >>>> >>>> >>> 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 for testing, I'll let you know once I have a complete patch for this problem. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/net/sched/sch_hfsc.c b/net/sched/sch_hfsc.c index b38b39c..a435cf1 100644 --- a/net/sched/sch_hfsc.c +++ b/net/sched/sch_hfsc.c @@ -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 */