Date:	Wed, 4 Apr 2007 15:56:51 +0300
From:	"Denys" <denys@...p.net.lb>
To:	hadi@...erus.ca
Cc:	Patrick McHardy <kaber@...sh.net>,
	Stephen Hemminger <shemminger@...ux-foundation.org>,
	netdev@...r.kernel.org
Subject: Re: one more... iproute commands lockup whole system

Well, my case is my own mistake, i guess it is just misconfiguration, not 
actual bug. And also it is good push for me "read doc's and think well before 
adding rules".
Maybe it can be in TODO, but it is not N1 priority i guess. There is more 
important things, what u want to do. Another thing, adding one more field in 
skb will add more overhead to whole kernel(i guess).

I have some interesting thing:

Rules:
tc qdisc del dev eth0.5 root
tc qdisc add dev eth0.5 handle 1: root htb
tc class add dev eth0.5 parent 1:0 classid 1:2 htb rate 128Kbit

tc qdisc add dev eth0.5 parent 1:2 handle 2: prio

tc filter add dev eth0.5 parent 1: protocol ip prio 10 u32 \
match ip src 195.69.208.253/32 flowid 1:2

tc filter add dev eth0.5 parent 2: protocol ip prio 10 u32 \
    match ip src 195.69.208.253/32 flowid 2:1 \
    action mirred egress redirect dev eth0.6

(it is not working, but just i tried few things)

At morning i wakeup and see in dmesg, also not sure if it's bug or result of 
misconfiguration:

[46632.941527] KERNEL: assertion (!cl->level && cl->un.leaf.q && cl-
>un.leaf.q->q.qlen) failed at net/sched/sch_htb.c (585)
[46633.270732] KERNEL: assertion (!cl->level && cl->un.leaf.q && cl-
>un.leaf.q->q.qlen) failed at net/sched/sch_htb.c (585)
[46633.379446] KERNEL: assertion (!cl->level && cl->un.leaf.q && cl-
>un.leaf.q->q.qlen) failed at net/sched/sch_htb.c (585)
[46633.450751] KERNEL: assertion (!cl->level && cl->un.leaf.q && cl-
>un.leaf.q->q.qlen) failed at net/sched/sch_htb.c (585)
[46633.570702] KERNEL: assertion (!cl->level && cl->un.leaf.q && cl-
>un.leaf.q->q.qlen) failed at net/sched/sch_htb.c (585)



On Wed, 04 Apr 2007 06:55:14 -0400, jamal wrote
> On Wed, 2007-04-04 at 05:11 +0300, Denys wrote:
> > I think this highly useful feature given by jamal, difficult to be 
avoided 
> > from crash, if user not enough experienced in networking(like me). I 
guess 
> > packet can be even not ipv4/ipv6 packet, maybe it can be cloned IPX or 
ARP, 
> > so TTL field cannot be used. I checked maybe sk_buff have some fields, 
seems 
> > also bad luck, if there can be something like "internal" counter for 
packet, 
> > how much times it got redirected, it will help.
> 
> Adding a field in the skb that keeps track of things would work well,
> but would be a controvesial thing to do because it actually requires 
> a vector not just one field. There is a filed called cb[] but it 
> cant be used in this case because every time we redirect it could be 
> trampled.
> 
> > But in my case of VLAN's it 
> > is really my own mistake and difficult to avoid it. Only bad thing - 
machine 
> > got completely locked up, and if it is remote system - it will not oops/
or 
> > reboot even. But i dont have any idea in mind how to avoid this, only 
than 
> > big warning in DOC and internal iproute2 help :-)
> 
> Your case is easy to detect in user space because it is within the same
> policy.
> Would simple detection and rejection in tc/userspace be useful to 
> add? Note, this doesnt help the general problem though where you 
> have nesting as described in the document.
> 
> cheers,
> jamal
> 
> -
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@...r.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


--
Denys Fedoryshchenko
Technical Manager
Virtual ISP S.A.L.

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

Powered by blists - more mailing lists