linux-kernel - Re: Regression: ONE CPU fails bootup at Re: [3.2.0-RC7] BUG: unable to handle kernel NULL pointer dereference at 0000000000000598 1.478005] IP: [<ffffffff8107a6c4>] queue_work

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 for Android: free password hash cracker in your pocket

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

Date:	Wed, 04 Jan 2012 19:50:29 +0100
From:	Stefan Bader <stefan.bader@...onical.com>
To:	John Stultz <john.stultz@...aro.org>
CC:	NeilBrown <neilb@...e.de>,
	Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>,
	Sander Eikelenboom <linux@...elenboom.it>, rjw@...k.pl,
	Thomas Gleixner <tglx@...utronix.de>,
	linux-kernel@...r.kernel.org
Subject: Re: Regression: ONE CPU fails bootup at Re: [3.2.0-RC7] BUG: unable
 to handle kernel NULL pointer dereference at 0000000000000598  1.478005]
 IP: [<ffffffff8107a6c4>] queue_work_on+0x4/0x30

On 04.01.2012 19:36, John Stultz wrote:
> On Wed, 2012-01-04 at 09:17 +0100, Stefan Bader wrote:
>> Over night I had still be thinking on this and maybe one important fact I had
>> been ignoring. This really has only been observed on paravirt guests on Xen as
>> far as I know. And one thing that I should have pointed out is that
>>
>> [    0.792634] rtc_cmos rtc_cmos: rtc core: registered rtc_cmos as rtc0
>> [    0.792725] rtc_cmos: probe of rtc_cmos failed with error -38
>>
>> So first the registration is done and the first line is the last thing printed
>> in the registration function. Then, and that line always comes after, the probe,
>> which looks like being done asynchronously, detects that the rtc is not
>> implemented. I would assume that this causes the rtc to be unregistered again
>> and that is probably the point where, under the right circumstances, the worker
>> triggered by the initialize alarm is trying to set another alarm. Probably while
>> some of the elements of the structure started to be torn down. I need to check
>> on that code path, yet. So right now its more a guess.
> 
> Hrm. Do you see the same probe error with 3.1 kernels as well?  
> 
Yes. But I think this is not really wrong. Remember this is in a paravirtualized
guest. Which does not necessarily have access to all physical hardware. Maybe
something usually not expected. And having the class device registered before
the probe finally finds out about it not being present could be a bit suboptimal
in that case.

-Stefan

> Konrad: Is the probe failure a known issue on Xen? Any clues on whats
> going on there?
> 
> thanks
> -john
> 
> 

--
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/