[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Oops when deleting filters...



Hi!

I sent a mail about a possible memory hole in diffserv in december
last year (see below). After playing a little more with the problem, I
found that you can produce an oops in the same context using the
following commands, taken from the example script ef-prio (ds version
8, linux 2.2.14):

First adding dsmark and a prio qdisc:
# tc qdisc add dev eth0 handle 1:0 root dsmark indices 64 set_tc_index
# tc qdisc add dev eth0 parent 1:0 handle 2:0 prio

Now adding a filter to the prio qdisc:
# tc filter add dev eth0 parent 2:0 protocol ip prio 1 handle 0x2e tcindex classid 2:1 pass_on

# tc filter show dev eth0 parent 2:0
filter protocol ip pref 1 tcindex hash 64 mask 0xffff shift 0 pass_on 
filter protocol ip pref 1 tcindex handle 0x002e classid 2:1 

First try to delete the filter, does not work, filter is still there
# tc filter delete dev eth0 parent 2:0 protocol ip prio 1 handle 0x2e tcindex classid 2:1 pass_on

Second try to delete the filter:
# tc filter delete dev eth0 parent 2:0 protocol ip prio 1 handle 0x2e tcindex classid 2:1 pass_on
Segmentation fault

The log is showing the following:
---------------------------------

dsmark_init(sch c10cff20,[qdisc c10cff88],opt c10cfeb0)
dsmark_init: qdisc c10cff88
dsmark_get(sch c10cff20,[qdisc c10cff88],classid 10000)
dsmark_get(sch c10cff20,[qdisc c10cff88],classid 10000)
dsmark_graft(sch c10cff20,[qdisc c10cff88],new c1d63260,old c1353d20)
tcindex_init(tp c1fabf80)
tcindex_get(tp c1fabf80,handle 0x0000002e)
tcindex_change(tp c1fabf80,handle 0x0000002e,tca c1353d74,arg c1353d0c),opt c12a0ad0,p c0b76120,r 00000000
*arg = 0x0
classid/police c12a0ad4/00000000
hash 64 mask 65535
r=00000000
r=c1353c84
tcindex_dump(tp c1fabf80,fh 0x0,skb c0a67180,t c13b5010),p c0b76120,r 00000000,b c13b5038
p->perfect 00000000 p->h c1d63da0
tcindex_dump(tp c1fabf80,fh 0x0,skb c0a1e6e0,t c13b5010),p c0b76120,r 00000000,b c13b5038
p->perfect 00000000 p->h c1d63da0
tcindex_walk(tp c1fabf80,walker c1353cc4),p c0b76120
tcindex_dump(tp c1fabf80,fh 0xc0b76da4,skb c0a1e6e0,t c13b506c),p c0b76120,r c0b76da4,b c13b5094
p->perfect 00000000 p->h c1d63da0
handle = 46
tcindex_get(tp c1fabf80,handle 0x0000002e)
tcindex_delete(tp c1fabf80,arg 0xc0b76da4),p c0b76120,f 00000000
tcindex_get(tp c1fabf80,handle 0x0000002e)
Unable to handle kernel paging request at virtual address 0000312e
current->tss.cr3 = 01351000, %cr3 = 01351000
*pde = 00000000
Oops: 0000
CPU:    0
EIP:    0010:[<c2817098>]
EFLAGS: 00010206
eax: 0000312e   ebx: c0b76120   ecx: 0000002e   edx: 0000002e
esi: c1d63da0   edi: c1fabf80   ebp: ffffffea   esp: c1353c7c
ds: 0018   es: 0018   ss: 0018
Process tc (pid: 235, process nr: 31, stackpage=c1353000)
Stack: c2817176 c0b76120 0000002e c2817b00 c1fabf80 0000002e c12a05c4 c12a05d0 
       c014c565 c1fabf80 0000002e c0a1e6e0 c1353d74 00000000 c12a05a0 c1352000 
       c1353e68 00000024 c2815680 00000202 c09c0000 00000002 c0a1e6e0 c1fabf80 
Call Trace: [<c2817176>] [<c2817b00>] [<c014c565>] [<c2815680>] [<c2817150>] [<c28156c0>] [<c014946e>] 
       [<c01498fd>] [<c016a945>] [<c016a15b>] [<c016a5ba>] [<c016a41c>] [<c0141c6c>] [<c016a41c>] [<c0142b6f>] 
       [<c0142da9>] [<c014275b>] [<c0118ee5>] [<c0118f4b>] [<c011901d>] [<c0142fbc>] [<c0107ae1>] [<c01079dc>] 
Code: 66 39 08 74 e3 8b 40 10 85 c0 75 f4 31 c0 5b 5e c3 8d 76 00 

----------------

I think both, the oops and the wrong reference counter for the modules
are related. 

Any ideas?

Best regards,

/J"org

------------
From: dieder@ibr.cs.tu-bs.de (Joerg Diederich)
Newsgroups: ibr.mailinglists.linux-diffserv
Subject: Deleting filters: memory hole?
Date: 8 Dec 1999 17:45:26 +0100

Hi!

I have just started to play with the linux DiffServ distribution (so
this is probably a newbie problem...)

My environment: linux 2.2.10, ds6 patches, iproute2-2.2.4-now-ss990630

Compiling the kernel with the patches went fine (although I had to
apply the patch from this list from 10.9.1999 from dtm@vramp.net
(David McWherter) to compile the tc-modules from linux/net/sched as
modules.

After executing the ef-prio script from iproute2/examples/diffserv
lsmod states:

Module                  Size  Used by
sch_red                 1604   1  (autoclean)
sch_tbf                 2044   1  (autoclean)
sch_prio                1800   1  (autoclean)
cls_tcindex             3648   3  (autoclean)
sch_dsmark              3064   1  (autoclean)

which is fine according to the script: 
- 3 different qdiscs (red, tbf, prio, dsmark) and
- 3 tcindex filters.

I can view the filter with parent 1:0 with:

$ tc filter show dev eth0 protocol ip           
filter parent 1: pref 1 tcindex hash 0 mask 0x00fc shift 2 fall_through

And the other 2 filters with parent 2:0 with: 

$ tc filter show dev eth0 protocol ip parent 2:0
filter pref 1 tcindex hash 64 mask 0xffff shift 0 pass_on 
filter pref 1 tcindex handle 0x002e classid 2:1 
filter pref 2 tcindex hash 1 mask 0x0000 shift 0 pass_on 
filter pref 2 tcindex handle 0x0000 classid 2:2 


The problem occurs when I try to delete the filters again:

I can delete the parent 1:0 filter with:

$ tc filter del dev eth0 protocol ip pref 1 parent 1:0

Another 'tc filter show...' shows nothing left and also the modcount from
lsmod is decread by one:

cls_tcindex             3648   2  (autoclean)

I can also delete the first parent 2:0 filter with:

$ tc filter del dev eth0 protocol ip pref 1 parent 2:0 

'tc filter show' is ok and the modcount from 'lsmod' too.

However, I cannot delete the second parent 2:0 filter:

$ tc filter del dev eth0 protocol ip pref 2 parent 2:0

does not complain with errors or something, but 'tc filter show ...'
still has the filter entry left and 'lsmod' has not decreased the
modcount. 

It does not matter, in which order I delete the three filters.

When I do:

'tc qdisc del dev eth0 root'

'tc filter show...' does not show any filter left, but in 'lsmod' the
modcount has not decreased. 

If I do 'tc qdisc del dev eth0 root' right after having executed the
ef-prio script (without deleting filters by hand), lsmod shows a
modcount of 2 for cls_tcindex (thus, 2 filters have not been deleted
properly).

It seems to me that the filter entry is not deleted (or, at least, the
modcount is not decreased properly) and that there might be a
potential memory hole here (only if you play a lot with different
scripts, but...)

Best regards,

/J"org
----
J"org Diederich
Institute of Operating Systems and Computer Networks, 
Technical University Braunschweig, Germany
Email: dieder@ibr.cs.tu-bs.de