Re: [LARTC] imq crash investigation

["Roy" <roy@xxx.lt>]

Now I am continuing imq development, but seems it is hopeless, no mater what
i do it crashes when qdisc are used
seems that it can be not imq problem but somthing wrong with htb.
I completely rewrote imq driver, only device registration left. I checked
many diferent variants of code, and no mater what, it crashes as allways
I even made that packets are never dropped but still  it crashes completely
with no reason, probability to crash increases with load.

here is new imq code:

int wequeue=stats->rx_packets-stats->tx_packets;
stats->rx_dropped=wequeue;
if (wequeue >70){
nf_reinject(skb, info, NF_ACCEPT);  //not alow to fill queue full so htb
wont drop packets
stats->tx_dropped++;
return 0;
}
stats->rx_packets++;
//--------  the main part of the driver ( packets are newer dropped)
skb->destructor = imq_skb_destructor; // not used this time
skb->real_dev=skb->dev; //not used
skb->dev=imq_dev; //not used also
if (dev_queue_xmit(skb)){
skb->dev=skb->real_dev;
printk("cant queue %p \n",skb);  // if this occurs then queue is full. what
never happens
}
//-----------------------------------
As you see it is so simple that there is no space for bugs.
now kernel do not crash, it just hags completely with no output.

so I suspect that there is problem with shaper itself or netfilter, or linux
dont like when packets are reordered.

Now I am going to try completely diferent idea, I thing I should name it not
INQ but  NFD because it will be netfilter interface( the part of netfilter
core itself) so EVERYTHING will pass this interface.





> Hello.
>
> As you know Patrick McHardy stopped to support IMQ. As for now, this
> stuff has an annoying problem and I've made a little investigation of
> it. So, maybe it will be useful for someone.
>
> First, pass all traffic of the interface (as in, as out) though imq
> device. Something like:
>
> iptables -t mangle -I PREROUTING -i $DEV -j IMQ
> iptables -t mangle -I POSTROUTING -o $DEV -j IMQ
>
> This works ok. At least, after a day of running this setup seems to be
> stable. Now, lets attach a qdisc to imq:
>
> RATE\x187
> tc qdisc add dev imq0 handle 1: root tbf rate ${RATE}kbit \
>      burst 15kb/8 limit 15kb
>
> Ok, here it is. After some time (minutes,hours) I get a kernel panic.
>
> As far as I know, IMQ is the _only_ way for now in Linux to limit the
> total bandwidth of the link (in+out). It would be excellent if somebody,
>   enough expirenced in kernel hacking, will be so kind to fix that
problem.
>
> Best regards,
>    Ivan Pesin
> _______________________________________________
> LARTC mailing list / LARTC@mailman.ds9a.nl
> http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/

_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/