* iproute u32 filter - server hang @ 2010-03-31 9:10 Paweł Staszewski 2010-03-31 9:34 ` Patrick McHardy 0 siblings, 1 reply; 6+ messages in thread From: Paweł Staszewski @ 2010-03-31 9:10 UTC (permalink / raw) To: Linux Network Development list 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: iproute u32 filter - server hang 2010-03-31 9:10 iproute u32 filter - server hang Paweł Staszewski @ 2010-03-31 9:34 ` Patrick McHardy 2010-03-31 9:42 ` Paweł Staszewski 0 siblings, 1 reply; 6+ messages in thread From: Patrick McHardy @ 2010-03-31 9:34 UTC (permalink / raw) To: Paweł Staszewski; +Cc: Linux Network Development list [-- Attachment #1: Type: text/plain, Size: 889 bytes --] 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. [-- Attachment #2: x --] [-- Type: text/plain, Size: 1295 bytes --] 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 */ ^ permalink raw reply related [flat|nested] 6+ messages in thread
* Re: iproute u32 filter - server hang 2010-03-31 9:34 ` Patrick McHardy @ 2010-03-31 9:42 ` Paweł Staszewski 2010-03-31 9:46 ` Patrick McHardy 0 siblings, 1 reply; 6+ messages in thread From: Paweł Staszewski @ 2010-03-31 9:42 UTC (permalink / raw) To: Patrick McHardy; +Cc: Linux Network Development list 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: iproute u32 filter - server hang 2010-03-31 9:42 ` Paweł Staszewski @ 2010-03-31 9:46 ` Patrick McHardy 2010-03-31 9:59 ` Paweł Staszewski 0 siblings, 1 reply; 6+ messages in thread From: Patrick McHardy @ 2010-03-31 9:46 UTC (permalink / raw) To: Paweł Staszewski; +Cc: Linux Network Development list 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. ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: iproute u32 filter - server hang 2010-03-31 9:46 ` Patrick McHardy @ 2010-03-31 9:59 ` Paweł Staszewski 2010-03-31 10:01 ` Patrick McHardy 0 siblings, 1 reply; 6+ messages in thread From: Paweł Staszewski @ 2010-03-31 9:59 UTC (permalink / raw) To: Patrick McHardy; +Cc: Linux Network Development list 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 > > > ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: iproute u32 filter - server hang 2010-03-31 9:59 ` Paweł Staszewski @ 2010-03-31 10:01 ` Patrick McHardy 0 siblings, 0 replies; 6+ messages in thread From: Patrick McHardy @ 2010-03-31 10:01 UTC (permalink / raw) To: Paweł Staszewski; +Cc: Linux Network Development list 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. ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2010-03-31 10:01 UTC | newest] Thread overview: 6+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2010-03-31 9:10 iproute u32 filter - server hang Paweł Staszewski 2010-03-31 9:34 ` Patrick McHardy 2010-03-31 9:42 ` Paweł Staszewski 2010-03-31 9:46 ` Patrick McHardy 2010-03-31 9:59 ` Paweł Staszewski 2010-03-31 10:01 ` Patrick McHardy
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).