Messages in this thread | | | Subject | fixme: possibly bug in some sch_* qdiscs? | Date | Sat, 29 Mar 2003 18:12:12 +0300 | From | "Dimitry V. Ketov" <> |
| |
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/
| |