Re: one more... iproute commands lockup whole system

2007-04-04 Thread jamal
On Wed, 2007-04-04 at 16:39 +0200, Patrick McHardy wrote: > Have a tasklet to avoid the deadlocks. sounds like a good idea from the outset. The principle of punishing only users of mirred is the right one. It will also provide a clean way to drop all redirect to self. The dilema is that the cost

Re: one more... iproute commands lockup whole system

2007-04-04 Thread Denys
Yes, it is real setup by the way, i just copy&paste script here. I tried to remove some commands to leave only minimum to reproduce the problem. Right now i dont have another ethernet card on that system, i will add it today, when i come back home and i will test in different situations. Also it

Re: one more... iproute commands lockup whole system

2007-04-04 Thread Patrick McHardy
jamal wrote: > On Wed, 2007-04-04 at 16:07 +0200, Patrick McHardy wrote: > >>How about adding something like ifb's ri_tasklet to act_mirred? > > > You mean having a tasklet or the constraint checks? Have a tasklet to avoid the deadlocks. - To unsubscribe from this list: send the line "unsubscr

Re: one more... iproute commands lockup whole system

2007-04-04 Thread jamal
On Wed, 2007-04-04 at 16:07 +0200, Patrick McHardy wrote: > He only used a single redirect to eth0.5, but its probably due to the > fact that the VLAN hard_start_xmit function transmits on eth0 again. Ok, that validates what i was saying earlier then - so i dont need to run the test. > How about

Re: one more... iproute commands lockup whole system

2007-04-04 Thread jamal
On Wed, 2007-04-04 at 15:56 +0300, Denys wrote: > 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: prot

Re: one more... iproute commands lockup whole system

2007-04-04 Thread Patrick McHardy
jamal wrote: > On Wed, 2007-04-04 at 15:36 +0200, Patrick McHardy wrote: > >>It would be interesting to find out what the problem is exactly. >>The configuration itself looks harmless, so I'm guessing its >>rather a deadlock than a loop. > > > We know it is a deadlock. > If you redirect the fir

Re: one more... iproute commands lockup whole system

2007-04-04 Thread jamal
On Wed, 2007-04-04 at 15:36 +0200, Patrick McHardy wrote: > > We have a loop counter (RTTL) in tc_verd. For some reason it is reset > after ing_filter though. > Essentially it is valuable just to avoid a lot of stacking (separate issue) and not to avoid the locking issue he is seeing. > It wo

Re: one more... iproute commands lockup whole system

2007-04-04 Thread Denys
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, add

Re: one more... iproute commands lockup whole system

2007-04-04 Thread Patrick McHardy
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,

Re: one more... iproute commands lockup whole system

2007-04-04 Thread jamal
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

Re: one more... iproute commands lockup whole system

2007-04-03 Thread Denys
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,

Re: one more... iproute commands lockup whole system

2007-04-03 Thread jamal
On Wed, 2007-04-04 at 03:39 +0200, Patrick McHardy wrote: > Are you refering to "What NOT to do if you dont want your machine to > crash:"? yes. > I think we should make sure users can't even accidentally > crash their box, so this should at least be caught at runtime. It is hard to do without

Re: one more... iproute commands lockup whole system

2007-04-03 Thread Patrick McHardy
jamal wrote: > On Wed, 2007-04-04 at 03:03 +0300, Denys wrote: > >>I'm not sure it is mistake or error, but i feel it is dangerous, cause >>commands locking up the system, no kernel panic, no oops, so only watchdog >>can save poor server (and not sure this even) >> >>Commands to lockup system (j

Re: one more... iproute commands lockup whole system

2007-04-03 Thread jamal
On Wed, 2007-04-04 at 03:03 +0300, Denys wrote: > I'm not sure it is mistake or error, but i feel it is dangerous, cause > commands locking up the system, no kernel panic, no oops, so only watchdog > can save poor server (and not sure this even) > > Commands to lockup system (just i am giving