Re: kmemcheck in linux-next causes NULL pointer dereference at task_rq_lock

[Vegard Nossum]

2009/8/10 Eric Paris <eparis@xxxxxxxxxx>:
> On Mon, 2009-08-10 at 20:56 +0200, Vegard Nossum wrote:
>> 2009/8/10 Eric Paris <eparis@xxxxxxxxxx>:
>> > I'm using 2.6.31-rc5-next-20090810 on a vmware server. ÂOriginally I saw
>> > messages about setting to one cpu, so I booted with maxcpu=1. ÂI get
>> > this same panic with and without maxpu. ÂBooting with kmemcheck=0 boots
>> > just fine.
>> >
>> > I have not tested kmemcheck in linus' tree but will start looking for a
>> > working version now. ÂAny suggestions or things I should try?
>>
>> Hi, thanks for the report, and for trying it out.
>>
>> Does it crash with "kmemcheck=0 maxcpus=1" (it should be maxcpus, not
>> maxcpu). This should be a simple way of determining whether it was
>> kmemcheck or the existing maxcpus code, which we use, that broke.
>
> I boots fine with kmemcheck=0
>
> I did get the command line right. Âmaxcpus=1 kmemcheck=1 was the panic I
> showed in the last message.
>
>> If you can send config (off-list, probably), I will try to reproduce
>> and investigate more tomorrow.
>
> Will send it now.

Thanks. I've tried your config with next-20090810, next-20090820, and
current mainline, and wasn't able to reproduce it anywhere :-/

Does it still occur for you with the most recent linux-next or current mainline?

In any case, I think the kmemcheck SMP-handling code has to be fixed.
It seems that we currently allow CPU hotplug while kmemcheck is
enabled, which could lead to, erm, interesting crashes. Maybe we could
do something like what mmiotrace does.


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