[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