Messages in this thread Patch in this message | | | Date | Fri, 21 Mar 2008 13:55:13 -0700 | From | Randy Dunlap <> | Subject | Re: [patch 2/5] infrastructure to debug (dynamic) objects |
| |
On Fri, 21 Mar 2008 20:26:18 -0000 Thomas Gleixner wrote:
> Documentation/kernel-parameters.txt | 2 > include/linux/debugobjects.h | 90 +++ > init/main.c | 3 > lib/Kconfig.debug | 23 > lib/Makefile | 1 > lib/debugobjects.c | 890 ++++++++++++++++++++++++++++++++++++ > mm/page_alloc.c | 10 > mm/slab.c | 10 > mm/slub.c | 3 > mm/vmalloc.c | 2 > 10 files changed, 1030 insertions(+), 4 deletions(-) > > Index: linux-2.6/lib/Kconfig.debug > =================================================================== > --- linux-2.6.orig/lib/Kconfig.debug > +++ linux-2.6/lib/Kconfig.debug > @@ -183,6 +183,29 @@ config TIMER_STATS > (it defaults to deactivated on bootup and will only be activated > if some application like powertop activates it explicitly). > > +config DEBUG_OBJECTS > + bool "Debug object operations" > + depends on DEBUG_KERNEL > + help > + If you say Y here, additional code will be inserted into the > + kernel to track the life time of various objects and validate
lifetime
> + the operations on those objects. > + > +config DEBUG_OBJECTS_SELFTEST > + bool "Debug objects selftest" > + depends on DEBUG_OBJECTS > + help > + This enables the selftest of the object debug code. > + > +config DEBUG_OBJECTS_FREE > + bool "Debug objects in freed memory" > + depends on DEBUG_OBJECTS > + help > + This enables checks whether a k/v free operation frees an area
Please say "kfree/vfree" so that we (I, others) don't have to think "what the heck is a k/v free operation?".
> + which contains an object which has not been deactivated > + properly. This can make kmalloc/kfree-intensive workloads > + much slower. > + > config DEBUG_SLAB > bool "Debug slab memory allocations" > depends on DEBUG_KERNEL && SLAB
> Index: linux-2.6/lib/debugobjects.c > =================================================================== > --- /dev/null > +++ linux-2.6/lib/debugobjects.c > @@ -0,0 +1,890 @@ ...
> +/* > + * We run out of memory. That means we probably have tons of objects
ran
> + * allocated. > + */ > +static void debug_objects_oom(void) > +{ > + struct debug_bucket *db = obj_hash; > + struct hlist_node *node, *tmp; > + struct debug_obj *obj; > + unsigned long flags; > + int i; > + > + printk(KERN_WARNING "ODEBUG: Out of memory. ODEBUG disabled\n"); > + > + for (i = 0; i < ODEBUG_HASH_SIZE; i++, db++) { > + spin_lock_irqsave(&db->lock, flags); > + hlist_for_each_entry_safe(obj, node, tmp, &db->list, node) { > + hlist_del(&obj->node); > + free_object(obj); > + } > + spin_unlock_irqrestore(&db->lock, flags); > + } > +}
> +/** > + * debug_object_init_on_stack - debug checks when an object on stack is > + * initialized
Unfortunately the first line of kernel-doc notation ("short description") is limited to one line. Even if it exceeds 80 columns. :(
> + * @addr: address of the object > + * @descr: pointer to an object specific debug description structure > + */ > +void debug_object_init_on_stack(void *addr, struct debug_obj_descr *descr) > +{ > + if (!debug_objects_enabled) > + return; > + > + __debug_object_init(addr, descr, 1); > +}
--- ~Randy
| |