* [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).