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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <19f34abd0908211020l6888d68w5c14cbadbca5c6c4@mail.gmail.com>
Date:	Fri, 21 Aug 2009 19:20:20 +0200
From:	Vegard Nossum <vegard.nossum@...il.com>
To:	Eric Paris <eparis@...hat.com>
Cc:	linux-kernel@...r.kernel.org, penberg@...helsinki.fi, mingo@...e.hu
Subject: Re: kmemcheck in linux-next causes NULL pointer dereference at 
	task_rq_lock

2009/8/10 Eric Paris <eparis@...hat.com>:
> On Mon, 2009-08-10 at 20:56 +0200, Vegard Nossum wrote:
>> 2009/8/10 Eric Paris <eparis@...hat.com>:
>> > 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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/