lkml.org 
[lkml]   [2003]   [Mar]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Subjectfixme: possibly bug in some sch_* qdiscs?
Date
From
The matter of problem is:
Some qdiscs (e.g sch_prio) don't destory their filter lists, when
someone deletes qdisc from interface without explicit filter deleting
before:
# tc qdisc add dev eth0 root handle 1: prio
# tc filter add dev eth0 parent 1: pref 1 protocol ip u32 match icmp
type 8 0xff classid 1:1
# tc qdisc del dev eth0 root
As i see (fixme), last tc command forces rtnetlink code to call
tc_get_qdisc() from net/sched/sch_api.c, which in turn, calls
qdisc_destroy() from net/sched/sch_generic.c, which calls qdisc
operations' reset(), then destroy(), then frees memory if needed.
Unfortunately prio_destroy() from net/sched/sch_prio.c code does not
implement (i start digging 2.4.18 code, then checked 2.4.20, then
2.5.66) explicit destroying its filter_list from private data, and losts
that pointer.
I think it causes memory leackage, when we repeating 'tc qdisc del'
operation without explicit 'tc filter del' operations. Next obvious
effect, that in turn cls_u32.o module does not decrement its usage
counter, but increment it on each 'tc filter add' command. And, at some
circumstances 'tc filter show' command shows a few filters, after I
added only one! (think it sees last filters from previous instances of
sch_prio)
Fortunately but only sch_cbq.c, sch_atm.c do their destroy() in the
right way...
Which kernel maintainer I need to contact with to fix that problem (if
it is the problem, of course ;)

Dmitry.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:34    [W:0.047 / U:0.108 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site