Re: [patch 2/5] infrastructure to debug (dynamic) objects

[Randy Dunlap <randy.dunlap@oracle.com>]

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