Re: [BUG] NULL pointer deref with rcutorture

[Eric Sesterhenn <snakebyte@gmx.de>]

hi,

* Paul E. McKenney (paulmck@linux.vnet.ibm.com) wrote:
> On Sun, Jan 04, 2009 at 03:57:26PM +0100, Eric Sesterhenn wrote:
> > 
> > Just tell me what i need to do, I am not really familiar with ftrace.
> > I am only able to test 2.6.28-04980-gb58602a, since current -git is not
> > able to boot on this box :|
> 
> Very cool!
> 
> The idea is to have __call_rcu() in kernel/rcutree.c record the
> address of the callback (argument "head") and the function (argument
> "func").  In rcu_do_batch(), just before invoking list->func(list),
> also record the address of the callback ("list") and the function
> (again, "func").
> 
> The new ftrace package has some mechanisms for doing this, but there is
> always the old-fashioned way of using printk(), for example in
> rcu_do_batch():
> 
> 	prefetch(next);
> 	if (rcu_dump_callbacks)
> 		printk("rcu_head=%p, func=%p\n", list, func);
> 	list->func(list);
> 
> Initialize rcu_dump_callbacks to zero, then use a small kernel module
> (or some such) to set it to one just before running your test.

i did it via the ugly printk and captured it via netconsole

for the box with rcutree you can find the log here:
http://www.cccmz.de/~snakebyte/200.log
The interesting part seems start at 155.858923, thats when I load
the rcutorture module

with http://www.cccmz.de/~snakebyte/200_1.log i had another try,
actually saw a rcu_do_batch: rcu_head=d1907720, func=(null) in the traces,
box went into unresponsive mode afterwards

And just in case it helps somehow: http://www.cccmz.de/~snakebyte/200_3.log

for the one with rcupreemt you can find the log here:
http://www.cccmz.de/~snakebyte/201.log
rcutorture is loaded at 87.312399

Greetings, Eric