* [2.6.0-test9] QoS HTB crash... @ 2003-10-30 16:10 Daniel Blueman 2003-10-30 19:50 ` devik 0 siblings, 1 reply; 9+ messages in thread From: Daniel Blueman @ 2003-10-30 16:10 UTC (permalink / raw) To: netdev, linux-net, devik, linux-kernel With the LARTC 'wondershaper' HTB script [1] for good latency over ADSL, I get an oops [3] when sending traffic via ppp0 (and when bringing the interface down). Kernel is 2.6.0-test9 and 'debug 3333333' appended to the 'tc' command, to show HTB debug information [2] (not shown in [1]). Please CC me when replying, and I can provide further details, debugging, testing etc...this problem has been around for a while it seems. --- [1] (relevant lines from http://lartc.org/wondershaper/) tc qdisc add dev ppp0 root handle 1: htb default 20 tc class add dev ppp0 parent 1: classid 1:1 htb rate 210kbit burst 6k tc class add dev ppp0 parent 1:1 classid 1:10 htb rate 210kbit burst 6k prio 1 tc class add dev ppp0 parent 1:1 classid 1:20 htb rate 189kbit burst 6k prio 2 tc class add dev ppp0 parent 1:1 classid 1:30 htb rate 168kbit burst 6k prio 2 --- [2] (HTB debug messages) HTB init, kernel part version 3.13 htb_init sch=dc28e7f8 handle=10000 r2q=10 htb_dump sch=dc28e7f8, handle=10000 htb*g j=179519 lj=0 htb*r7 m=0 htb*r6 m=0 htb*r5 m=0 htb*r4 m=0 htb*r3 m=0 htb*r2 m=0 htb*r1 m=0 htb*r0 m=0 htb_get clid=10010 q=dc28e86c cl=00000000 ref=0 htb_get clid=10010 q=dc28e86c cl=00000000 ref=0 htb_get clid=10020 q=dc28e86c cl=00000000 ref=0 htb_get clid=10020 q=dc28e86c cl=00000000 ref=0 htb_get clid=10030 q=dc28e86c cl=00000000 ref=0 htb_get clid=10030 q=dc28e86c cl=00000000 ref=0 htb_tcf q=dc28e86c clid=0 fref=0 fl=00000000 htb_bind q=dc28e86c clid=10010 cl=00000000 fref=0 htb_tcf q=dc28e86c clid=0 fref=1 fl=df4ecd7c htb_bind q=dc28e86c clid=10010 cl=00000000 fref=1 htb_tcf q=dc28e86c clid=0 fref=2 fl=df4ecd7c htb_bind q=dc28e86c clid=10010 cl=00000000 fref=2 htb_tcf q=dc28e86c clid=0 fref=3 fl=df4ecd7c htb_bind q=dc28e86c clid=10020 cl=00000000 fref=3 htb_reset sch=dc28e7f8, handle=10000 --- [3] (ksymoops-processed oops report) Oops: 0000 [#1] CPU: 0 EIP: 0060:[<c02cbbad>] Not tainted >>EIP; c02cbbad <htb_enqueue+ab/126> <===== >>ebx; ffffffff <__kernel_rt_sigreturn+1bbf/????> >>ecx; dc28e86c <_end+1be20f60/3fb906f4> >>esi; d9cf3f50 <_end+19886644/3fb906f4> >>edi; dc28e7f8 <_end+1be20eec/3fb906f4> >>ebp; dbef5ab8 <_end+1ba881ac/3fb906f4> >>esp; dbef5a9c <_end+1ba88190/3fb906f4> Trace; c02b3570 <dev_queue_xmit+593/73a> Trace; c02e9c98 <ip_finish_output2+0/1c4> Trace; c02e9d97 <ip_finish_output2+ff/1c4> Trace; c02c0259 <nf_hook_slow+ef/13a> Trace; c02e9c98 <ip_finish_output2+0/1c4> Trace; c02e76d7 <ip_finish_output+21d/222> Trace; c02e9c98 <ip_finish_output2+0/1c4> Trace; c02bff12 <nf_iterate+6b/9f> Trace; c02e9c80 <dst_output+15/2d> Trace; c02c0259 <nf_hook_slow+ef/13a> Trace; c02e9c6b <dst_output+0/2d> Trace; c02e9620 <ip_push_pending_frames+3ac/408> Trace; c02e9c6b <dst_output+0/2d> Trace; c030da69 <udp_push_pending_frames+134/23c> Trace; c030e1b4 <udp_sendmsg+60d/f3d> Trace; c031900a <inet_sendmsg+4b/56> Trace; c02aa4cc <sock_sendmsg+92/af> Trace; c02aa582 <sock_recvmsg+99/b4> Trace; c02a9f68 <move_addr_to_kernel+7e/a7> Trace; c02b01a0 <verify_iovec+80/fa> Trace; c02ac13d <sys_sendmsg+256/2f4> Trace; c0141e28 <filemap_nopage+21c/2f9> Trace; c0155610 <do_no_page+29b/631> Trace; c0155c54 <handle_mm_fault+132/30c> Trace; c018becd <inode_update_time+8e/b9> Trace; c0119419 <do_page_fault+34b/56a> Trace; c02ac67e <sys_socketcall+261/29a> Trace; c0164327 <sys_write+5b/5d> Trace; c010a3eb <syscall_call+7/b> Code; c02cbbad <htb_enqueue+ab/126> 00000000 <_EIP>: Code; c02cbbad <htb_enqueue+ab/126> <===== 0: 8b 43 04 mov 0x4(%ebx),%eax <===== Code; c02cbbb0 <htb_enqueue+ae/126> 3: 89 44 24 04 mov %eax,0x4(%esp,1) Code; c02cbbb4 <htb_enqueue+b2/126> 7: c7 04 24 2b 30 38 c0 movl $0xc038302b,(%esp,1) Code; c02cbbbb <htb_enqueue+b9/126> e: e8 e3 6e e5 ff call ffe56ef6 <_EIP+0xffe56ef6> Code; c02cbbc0 <htb_enqueue+be/126> 13: 31 00 xor %eax,(%eax) <0>Kernel panic: Fatal exception in interrupt -- Daniel J Blueman NEU FÜR ALLE - GMX MediaCenter - für Fotos, Musik, Dateien... Fotoalbum, File Sharing, MMS, Multimedia-Gruß, GMX FotoService Jetzt kostenlos anmelden unter http://www.gmx.net +++ GMX - die erste Adresse für Mail, Message, More! +++ ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [2.6.0-test9] QoS HTB crash... 2003-10-30 16:10 [2.6.0-test9] QoS HTB crash Daniel Blueman @ 2003-10-30 19:50 ` devik 2003-10-30 21:08 ` David S. Miller 0 siblings, 1 reply; 9+ messages in thread From: devik @ 2003-10-30 19:50 UTC (permalink / raw) To: Daniel Blueman; +Cc: netdev, linux-net, linux-kernel Hi, thanks for the report. I know that there is an issue regarding HTB in 2.6.x. Please send me net/sched/sch_htb.o, net/sched/sch_htb.c (just to be sure) and be sure that you build the kernel with debugging symbols (see debugging section of menuconfig/xconfig). thanks, ------------------------------- Martin Devera aka devik Linux kernel QoS/HTB maintainer http://luxik.cdi.cz/~devik/ On Thu, 30 Oct 2003, Daniel Blueman wrote: > With the LARTC 'wondershaper' HTB script [1] for good latency over ADSL, I > get an oops [3] when sending traffic via ppp0 (and when bringing the interface > down). > > Kernel is 2.6.0-test9 and 'debug 3333333' appended to the 'tc' command, to > show HTB debug information [2] (not shown in [1]). > > Please CC me when replying, and I can provide further details, debugging, > testing etc...this problem has been around for a while it seems. > > --- [1] (relevant lines from http://lartc.org/wondershaper/) > > tc qdisc add dev ppp0 root handle 1: htb default 20 > tc class add dev ppp0 parent 1: classid 1:1 htb rate 210kbit burst 6k > tc class add dev ppp0 parent 1:1 classid 1:10 htb rate 210kbit burst 6k prio > 1 > tc class add dev ppp0 parent 1:1 classid 1:20 htb rate 189kbit burst 6k prio > 2 > tc class add dev ppp0 parent 1:1 classid 1:30 htb rate 168kbit burst 6k prio > 2 > > --- [2] (HTB debug messages) > > HTB init, kernel part version 3.13 > htb_init sch=dc28e7f8 handle=10000 r2q=10 > htb_dump sch=dc28e7f8, handle=10000 > htb*g j=179519 lj=0 > htb*r7 m=0 > htb*r6 m=0 > htb*r5 m=0 > htb*r4 m=0 > htb*r3 m=0 > htb*r2 m=0 > htb*r1 m=0 > htb*r0 m=0 > htb_get clid=10010 q=dc28e86c cl=00000000 ref=0 > htb_get clid=10010 q=dc28e86c cl=00000000 ref=0 > htb_get clid=10020 q=dc28e86c cl=00000000 ref=0 > htb_get clid=10020 q=dc28e86c cl=00000000 ref=0 > htb_get clid=10030 q=dc28e86c cl=00000000 ref=0 > htb_get clid=10030 q=dc28e86c cl=00000000 ref=0 > htb_tcf q=dc28e86c clid=0 fref=0 fl=00000000 > htb_bind q=dc28e86c clid=10010 cl=00000000 fref=0 > htb_tcf q=dc28e86c clid=0 fref=1 fl=df4ecd7c > htb_bind q=dc28e86c clid=10010 cl=00000000 fref=1 > htb_tcf q=dc28e86c clid=0 fref=2 fl=df4ecd7c > htb_bind q=dc28e86c clid=10010 cl=00000000 fref=2 > htb_tcf q=dc28e86c clid=0 fref=3 fl=df4ecd7c > htb_bind q=dc28e86c clid=10020 cl=00000000 fref=3 > htb_reset sch=dc28e7f8, handle=10000 > > --- [3] (ksymoops-processed oops report) > > Oops: 0000 [#1] > CPU: 0 > EIP: 0060:[<c02cbbad>] Not tainted > > >>EIP; c02cbbad <htb_enqueue+ab/126> <===== > > >>ebx; ffffffff <__kernel_rt_sigreturn+1bbf/????> > >>ecx; dc28e86c <_end+1be20f60/3fb906f4> > >>esi; d9cf3f50 <_end+19886644/3fb906f4> > >>edi; dc28e7f8 <_end+1be20eec/3fb906f4> > >>ebp; dbef5ab8 <_end+1ba881ac/3fb906f4> > >>esp; dbef5a9c <_end+1ba88190/3fb906f4> > > Trace; c02b3570 <dev_queue_xmit+593/73a> > Trace; c02e9c98 <ip_finish_output2+0/1c4> > Trace; c02e9d97 <ip_finish_output2+ff/1c4> > Trace; c02c0259 <nf_hook_slow+ef/13a> > Trace; c02e9c98 <ip_finish_output2+0/1c4> > Trace; c02e76d7 <ip_finish_output+21d/222> > Trace; c02e9c98 <ip_finish_output2+0/1c4> > Trace; c02bff12 <nf_iterate+6b/9f> > Trace; c02e9c80 <dst_output+15/2d> > Trace; c02c0259 <nf_hook_slow+ef/13a> > Trace; c02e9c6b <dst_output+0/2d> > Trace; c02e9620 <ip_push_pending_frames+3ac/408> > Trace; c02e9c6b <dst_output+0/2d> > Trace; c030da69 <udp_push_pending_frames+134/23c> > Trace; c030e1b4 <udp_sendmsg+60d/f3d> > Trace; c031900a <inet_sendmsg+4b/56> > Trace; c02aa4cc <sock_sendmsg+92/af> > Trace; c02aa582 <sock_recvmsg+99/b4> > Trace; c02a9f68 <move_addr_to_kernel+7e/a7> > Trace; c02b01a0 <verify_iovec+80/fa> > Trace; c02ac13d <sys_sendmsg+256/2f4> > Trace; c0141e28 <filemap_nopage+21c/2f9> > Trace; c0155610 <do_no_page+29b/631> > Trace; c0155c54 <handle_mm_fault+132/30c> > Trace; c018becd <inode_update_time+8e/b9> > Trace; c0119419 <do_page_fault+34b/56a> > Trace; c02ac67e <sys_socketcall+261/29a> > Trace; c0164327 <sys_write+5b/5d> > Trace; c010a3eb <syscall_call+7/b> > > Code; c02cbbad <htb_enqueue+ab/126> > 00000000 <_EIP>: > Code; c02cbbad <htb_enqueue+ab/126> <===== > 0: 8b 43 04 mov 0x4(%ebx),%eax <===== > Code; c02cbbb0 <htb_enqueue+ae/126> > 3: 89 44 24 04 mov %eax,0x4(%esp,1) > Code; c02cbbb4 <htb_enqueue+b2/126> > 7: c7 04 24 2b 30 38 c0 movl $0xc038302b,(%esp,1) > Code; c02cbbbb <htb_enqueue+b9/126> > e: e8 e3 6e e5 ff call ffe56ef6 <_EIP+0xffe56ef6> > Code; c02cbbc0 <htb_enqueue+be/126> > 13: 31 00 xor %eax,(%eax) > > <0>Kernel panic: Fatal exception in interrupt > > -- > Daniel J Blueman > > NEU FÜR ALLE - GMX MediaCenter - für Fotos, Musik, Dateien... > Fotoalbum, File Sharing, MMS, Multimedia-Gruß, GMX FotoService > > Jetzt kostenlos anmelden unter http://www.gmx.net > > +++ GMX - die erste Adresse für Mail, Message, More! +++ > > > ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [2.6.0-test9] QoS HTB crash... 2003-10-30 19:50 ` devik @ 2003-10-30 21:08 ` David S. Miller 2003-10-31 7:40 ` devik 2003-11-01 18:13 ` Daniel Blueman 0 siblings, 2 replies; 9+ messages in thread From: David S. Miller @ 2003-10-30 21:08 UTC (permalink / raw) To: devik; +Cc: daniel.blueman, netdev, linux-net, linux-kernel On Thu, 30 Oct 2003 20:50:16 +0100 (CET) devik <devik@cdi.cz> wrote: > thanks for the report. I know that there is an issue regarding > HTB in 2.6.x. Please send me net/sched/sch_htb.o, > net/sched/sch_htb.c (just to be sure) and be sure that you > build the kernel with debugging symbols (see debugging section > of menuconfig/xconfig). I think the problem is the changes that were made in 2.5.x to htb_next_rb_node(). It used to be: static void htb_next_rb_node(rb_node_t **n) { rb_node_t *p; if ((*n)->rb_right) { /* child at right. use it or its leftmost ancestor */ *n = (*n)->rb_right; while ((*n)->rb_left) *n = (*n)->rb_left; return; } while ((p = (*n)->rb_parent) != NULL) { /* if we've arrived from left child then we have next node */ if (p->rb_left == *n) break; *n = p; } *n = p; } But it was changed into: static void htb_next_rb_node(struct rb_node **n) { *n = rb_next(*n); } This is wrong, the new code has much different side effects than the original code. This looks like the problem, devik what do you think? ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [2.6.0-test9] QoS HTB crash... 2003-10-30 21:08 ` David S. Miller @ 2003-10-31 7:40 ` devik 2003-11-01 18:13 ` Daniel Blueman 1 sibling, 0 replies; 9+ messages in thread From: devik @ 2003-10-31 7:40 UTC (permalink / raw) To: David S. Miller; +Cc: daniel.blueman, netdev, linux-net, linux-kernel Hmm - I have to look at 2.6's definition of rb_next. It might be the case ! I'll check it. Thanks, devik On Thu, 30 Oct 2003, David S. Miller wrote: > On Thu, 30 Oct 2003 20:50:16 +0100 (CET) > devik <devik@cdi.cz> wrote: > > > thanks for the report. I know that there is an issue regarding > > HTB in 2.6.x. Please send me net/sched/sch_htb.o, > > net/sched/sch_htb.c (just to be sure) and be sure that you > > build the kernel with debugging symbols (see debugging section > > of menuconfig/xconfig). > > I think the problem is the changes that were made > in 2.5.x to htb_next_rb_node(). It used to be: > > static void htb_next_rb_node(rb_node_t **n) > { > rb_node_t *p; > if ((*n)->rb_right) { > /* child at right. use it or its leftmost ancestor */ > *n = (*n)->rb_right; > while ((*n)->rb_left) > *n = (*n)->rb_left; > return; > } > while ((p = (*n)->rb_parent) != NULL) { > /* if we've arrived from left child then we have next node */ > if (p->rb_left == *n) break; > *n = p; > } > *n = p; > } > > But it was changed into: > > static void htb_next_rb_node(struct rb_node **n) > { > *n = rb_next(*n); > } > > This is wrong, the new code has much different side effects > than the original code. > > This looks like the problem, devik what do you think? > > ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [2.6.0-test9] QoS HTB crash... 2003-10-30 21:08 ` David S. Miller 2003-10-31 7:40 ` devik @ 2003-11-01 18:13 ` Daniel Blueman 2003-12-06 14:18 ` HTB 2.6.0-test10 oops related patch devik 1 sibling, 1 reply; 9+ messages in thread From: Daniel Blueman @ 2003-11-01 18:13 UTC (permalink / raw) To: David S. Miller; +Cc: devik, netdev, linux-net, linux-kernel Having applied this patch, I still get this issue when I kill pppd: Oops: 0002 [#1] CPU: 0 >>EIP; c02ced99 <htb_unbind_filter+49/6b> <===== >>ebx; d9c0586c <_end+19797f60/3fb906f4> >>ecx; dc95adf8 <_end+1c4ed4ec/3fb906f4> >>edx; d9c057f8 <_end+19797eec/3fb906f4> >>esi; dc95adf8 <_end+1c4ed4ec/3fb906f4> >>edi; df4eceac <_end+1f07f5a0/3fb906f4> >>ebp; d9c4bdfc <_end+197de4f0/3fb906f4> >>esp; d9c4bde4 <_end+197de4d8/3fb906f4> Trace; c011a647 <kernel_map_pages+28/5d> Trace; c02d3876 <u32_destroy_key+6a/6c> Trace; c02d3b1f <u32_clear_hnode+2e/48> Trace; c02d3b5e <u32_destroy_hnode+25/a9> Trace; c011a647 <kernel_map_pages+28/5d> Trace; c02d3cc4 <u32_destroy+e2/110> Trace; c02ce073 <htb_destroy_class+18b/1c3> Trace; c02cdedc <htb_destroy_filters+1d/29> Trace; c02ce112 <htb_destroy+67/d2> Trace; c02c1ea9 <qdisc_destroy+81/92> Trace; c02c260a <dev_shutdown+aa/268> Trace; c01398e8 <wakeme_after_rcu+0/c> Trace; c02b59e2 <unregister_netdevice+db/352> Trace; c02bd6ce <rtnl_lock+22/37> Trace; c0235f8c <unregister_netdev+19/25> Trace; c023c1ce <ppp_shutdown_interface+21e/3ba> Trace; c0183836 <dput+23/723> Trace; c016527c <__fput+7c/cd> Trace; c02363a5 <ppp_release+5f/61> Trace; c01652bb <__fput+bb/cd> Trace; c0163353 <filp_close+57/81> Trace; c0163481 <sys_close+104/228> Trace; c010a3eb <syscall_call+7/b> Code; c02ced99 <htb_unbind_filter+49/6b> 00000000 <_EIP>: Code; c02ced99 <htb_unbind_filter+49/6b> <===== 0: 83 ae 58 01 00 00 01 subl $0x1,0x158(%esi) <===== Code; c02ceda0 <htb_unbind_filter+50/6b> 7: 8b 5d f8 mov 0xfffffff8(%ebp),%ebx Code; c02ceda3 <htb_unbind_filter+53/6b> a: 8b 75 fc mov 0xfffffffc(%ebp),%esi Code; c02ceda6 <htb_unbind_filter+56/6b> d: 89 ec mov %ebp,%esp Code; c02ceda8 <htb_unbind_filter+58/6b> f: 5d pop %ebp Code; c02ceda9 <htb_unbind_filter+59/6b> 10: c3 ret Code; c02cedaa <htb_unbind_filter+5a/6b> 11: 83 ab 3c 00 00 00 00 subl $0x0,0x3c(%ebx) <0>Kernel panic: Fatal exception in interrupt --- > On Thu, 30 Oct 2003 20:50:16 +0100 (CET) > devik <devik@cdi.cz> wrote: > > > thanks for the report. I know that there is an issue regarding > > HTB in 2.6.x. Please send me net/sched/sch_htb.o, > > net/sched/sch_htb.c (just to be sure) and be sure that you > > build the kernel with debugging symbols (see debugging section > > of menuconfig/xconfig). > > I think the problem is the changes that were made > in 2.5.x to htb_next_rb_node(). It used to be: > > static void htb_next_rb_node(rb_node_t **n) > { > rb_node_t *p; > if ((*n)->rb_right) { > /* child at right. use it or its leftmost ancestor */ > *n = (*n)->rb_right; > while ((*n)->rb_left) > *n = (*n)->rb_left; > return; > } > while ((p = (*n)->rb_parent) != NULL) { > /* if we've arrived from left child then we have next node > */ > if (p->rb_left == *n) break; > *n = p; > } > *n = p; > } > > But it was changed into: > > static void htb_next_rb_node(struct rb_node **n) > { > *n = rb_next(*n); > } > > This is wrong, the new code has much different side effects > than the original code. > > This looks like the problem, devik what do you think? > -- Daniel J Blueman NEU FÜR ALLE - GMX MediaCenter - für Fotos, Musik, Dateien... Fotoalbum, File Sharing, MMS, Multimedia-Gruß, GMX FotoService Jetzt kostenlos anmelden unter http://www.gmx.net +++ GMX - die erste Adresse für Mail, Message, More! +++ ^ permalink raw reply [flat|nested] 9+ messages in thread
* HTB 2.6.0-test10 oops related patch 2003-11-01 18:13 ` Daniel Blueman @ 2003-12-06 14:18 ` devik 2003-12-07 7:10 ` David S. Miller 0 siblings, 1 reply; 9+ messages in thread From: devik @ 2003-12-06 14:18 UTC (permalink / raw) To: David S. Miller; +Cc: netdev, linux-net, daniel.blueman [-- Attachment #1: Type: TEXT/PLAIN, Size: 502 bytes --] Hello Dave, I discovered reason of the first Daniel's OOPS. It is change which was not forward-ported to 2.6. It is attached. However other Daniel's oops (pppd detach related) is of unknown reason yet. I tried to duplicate all conditions but pppoe (have no pppoe device here) and I was able to kill pppd with htb under full load with no problem. I'll look into it again today. ------------------------------- Martin Devera aka devik Linux kernel QoS/HTB maintainer http://luxik.cdi.cz/~devik/ [-- Attachment #2: Type: TEXT/PLAIN, Size: 1004 bytes --] --- sch_htb.old Sat Dec 6 15:05:21 2003 +++ sch_htb.c Sat Dec 6 15:05:24 2003 @@ -703,7 +703,7 @@ sch->q.qlen++; sch->stats.packets++; sch->stats.bytes += skb->len; - HTB_DBG(1,1,"htb_enq_ok cl=%X skb=%p\n",cl?cl->classid:0,skb); + HTB_DBG(1,1,"htb_enq_ok cl=%X skb=%p\n",(cl && cl != HTB_DIRECT)?cl->classid:0,skb); return NET_XMIT_SUCCESS; } @@ -731,7 +731,7 @@ htb_activate (q,cl); sch->q.qlen++; - HTB_DBG(1,1,"htb_req_ok cl=%X skb=%p\n",cl?cl->classid:0,skb); + HTB_DBG(1,1,"htb_req_ok cl=%X skb=%p\n",(cl && cl != HTB_DIRECT)?cl->classid:0,skb); return NET_XMIT_SUCCESS; } @@ -1477,7 +1477,7 @@ cl->magic = HTB_CMAGIC; #endif - /* create leaf qdisc early because it uses kmalloc(GPF_KERNEL) + /* create leaf qdisc early because it uses kmalloc(GFP_KERNEL) so that can't be used inside of sch_tree_lock -- thanks to Karlis Peisenieks */ new_q = qdisc_create_dflt(sch->dev, &pfifo_qdisc_ops); ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: HTB 2.6.0-test10 oops related patch 2003-12-06 14:18 ` HTB 2.6.0-test10 oops related patch devik @ 2003-12-07 7:10 ` David S. Miller 2003-12-07 11:30 ` devik 0 siblings, 1 reply; 9+ messages in thread From: David S. Miller @ 2003-12-07 7:10 UTC (permalink / raw) To: devik; +Cc: netdev, linux-net, daniel.blueman On Sat, 6 Dec 2003 15:18:37 +0100 (CET) devik <devik@cdi.cz> wrote: > I discovered reason of the first Daniel's OOPS. It is change > which was not forward-ported to 2.6. > It is attached. Thanks a lot for tracking this problem down Devik. Patch applied, thanks again. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: HTB 2.6.0-test10 oops related patch 2003-12-07 7:10 ` David S. Miller @ 2003-12-07 11:30 ` devik 2003-12-07 23:29 ` David S. Miller 0 siblings, 1 reply; 9+ messages in thread From: devik @ 2003-12-07 11:30 UTC (permalink / raw) To: David S. Miller; +Cc: netdev, linux-net, daniel.blueman [-- Attachment #1: Type: TEXT/PLAIN, Size: 1120 bytes --] Hello Dave, I just spotted the second bug too. (For those interested it is described in the patch). Please revert the small patch I sent you yesterday before applying the new one. It contains yesterday's one too (it is because it is for 2.4 too). Please apply it against both 2.4.23 and 2.6.0-test10. It should apply cleanly in 2.4.23 case and with some offsets to 2.6.0-test10. Patch comments: - Fixed oops in debugging of enqueue/requeue. - Fixed oops in htb_destroy. Note that I tested 2.6 only because I'm still downloading 2.4.22 patch on my slow line. I just wanted to sent the patch ASAP. I'll inform you about result later but I expect no problems. ------------------------------- Martin Devera aka devik Linux kernel QoS/HTB maintainer http://luxik.cdi.cz/~devik/ On Sat, 6 Dec 2003, David S. Miller wrote: > On Sat, 6 Dec 2003 15:18:37 +0100 (CET) > devik <devik@cdi.cz> wrote: > > > I discovered reason of the first Daniel's OOPS. It is change > > which was not forward-ported to 2.6. > > It is attached. > > Thanks a lot for tracking this problem down Devik. > > Patch applied, thanks again. > > [-- Attachment #2: Type: TEXT/PLAIN, Size: 2396 bytes --] --- sch_htb.2423.c Sun Dec 7 11:50:42 2003 +++ sch_htb.c Sun Dec 7 12:12:39 2003 @@ -23,7 +23,7 @@ * spotted bug in dequeue code and helped with fix * and many others. thanks. * - * $Id: sch_htb.c,v 1.24 2003/07/28 15:25:23 devik Exp devik $ + * $Id: sch_htb.c,v 1.25 2003/12/07 11:08:25 devik Exp devik $ */ #include <linux/config.h> #include <linux/module.h> @@ -75,7 +75,7 @@ #define HTB_HYSTERESIS 1/* whether to use mode hysteresis for speedup */ #define HTB_QLOCK(S) spin_lock_bh(&(S)->dev->queue_lock) #define HTB_QUNLOCK(S) spin_unlock_bh(&(S)->dev->queue_lock) -#define HTB_VER 0x3000d /* major must be matched with number suplied by TC as version */ +#define HTB_VER 0x3000e /* major must be matched with number suplied by TC as version */ #if HTB_VER >> 16 != TC_HTB_PROTOVER #error "Mismatched sch_htb.c and pkt_sch.h" @@ -717,7 +717,7 @@ sch->q.qlen++; sch->stats.packets++; sch->stats.bytes += skb->len; - HTB_DBG(1,1,"htb_enq_ok cl=%X skb=%p\n",cl?cl->classid:0,skb); + HTB_DBG(1,1,"htb_enq_ok cl=%X skb=%p\n",(cl && cl != HTB_DIRECT)?cl->classid:0,skb); return NET_XMIT_SUCCESS; } @@ -745,7 +745,7 @@ htb_activate (q,cl); sch->q.qlen++; - HTB_DBG(1,1,"htb_req_ok cl=%X skb=%p\n",cl?cl->classid:0,skb); + HTB_DBG(1,1,"htb_req_ok cl=%X skb=%p\n",(cl && cl != HTB_DIRECT)?cl->classid:0,skb); return NET_XMIT_SUCCESS; } @@ -1396,11 +1396,16 @@ #ifdef HTB_RATECM del_timer_sync (&q->rttim); #endif + /* This line used to be after htb_destroy_class call below + and surprisingly it worked in 2.4. But it must precede it + because filter need its target class alive to be able to call + unbind_filter on it (without Oops). */ + htb_destroy_filters(&q->filter_list); + while (!list_empty(&q->root)) htb_destroy_class (sch,list_entry(q->root.next, struct htb_class,sibling)); - htb_destroy_filters(&q->filter_list); __skb_queue_purge(&q->direct_queue); MOD_DEC_USE_COUNT; } @@ -1493,7 +1498,7 @@ cl->magic = HTB_CMAGIC; #endif - /* create leaf qdisc early because it uses kmalloc(GPF_KERNEL) + /* create leaf qdisc early because it uses kmalloc(GFP_KERNEL) so that can't be used inside of sch_tree_lock -- thanks to Karlis Peisenieks */ new_q = qdisc_create_dflt(sch->dev, &pfifo_qdisc_ops); ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: HTB 2.6.0-test10 oops related patch 2003-12-07 11:30 ` devik @ 2003-12-07 23:29 ` David S. Miller 0 siblings, 0 replies; 9+ messages in thread From: David S. Miller @ 2003-12-07 23:29 UTC (permalink / raw) To: devik; +Cc: netdev, linux-net, daniel.blueman On Sun, 7 Dec 2003 12:30:20 +0100 (CET) devik <devik@cdi.cz> wrote: > I just spotted the second bug too. (For those interested it is described > in the patch). > Please revert the small patch I sent you yesterday before applying the > new one. It contains yesterday's one too (it is because it is for 2.4 too). > Please apply it against both 2.4.23 and 2.6.0-test10. It should apply > cleanly in 2.4.23 case and with some offsets to 2.6.0-test10. Great work, applied. Thanks. ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2003-12-07 23:29 UTC | newest] Thread overview: 9+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2003-10-30 16:10 [2.6.0-test9] QoS HTB crash Daniel Blueman 2003-10-30 19:50 ` devik 2003-10-30 21:08 ` David S. Miller 2003-10-31 7:40 ` devik 2003-11-01 18:13 ` Daniel Blueman 2003-12-06 14:18 ` HTB 2.6.0-test10 oops related patch devik 2003-12-07 7:10 ` David S. Miller 2003-12-07 11:30 ` devik 2003-12-07 23:29 ` David S. Miller
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).