linux-kernel - Re: [xen] double fault: 0000 [#1] PREEMPT SMP DEBUG

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:	Tue, 8 Oct 2013 11:11:52 +0800
From:	Fengguang Wu <fengguang.wu@...el.com>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Russell King - ARM Linux <linux@....linux.org.uk>,
	xen-devel@...ts.xenproject.org,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Subject: Re: [xen] double fault: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC

On Mon, Oct 07, 2013 at 07:51:37PM -0700, Linus Torvalds wrote:
> On Mon, Oct 7, 2013 at 7:14 PM, Fengguang Wu <fengguang.wu@...el.com> wrote:
> >
> > I got a call trace containing parport_pc_probe_port() (is it the
> > culprit?) after recompiling kernel with
> >
> > CONFIG_DEBUG_OBJECTS_TIMERS=y
> >
> > and booting with "ignore_loglevel". Here is the log for two kernel boots.
> 
> Ok, so it's definitely parport_pc. I don't see what it would do wrong, though.

Yeah, I see no timer usage in parport_pc driver, so it's still questionable.

I'm now trying to disable all drivers shows up in the kobject_release messages:

[    2.756392] kobject: 'ipmi_si' (ffff880007764a00): kobject_release, parent ffff8800001b7648 (delayed)
[    2.758091] kobject: 'ipmi_si' (ffff880007764800): kobject_release, parent ffff880000221248 (delayed)
[    2.759858] kobject: 'ipmi_si' (ffff880007764c00): kobject_release, parent ffff880000189248 (delayed)
[    2.929669] kobject: 'drm' (ffff880006db2848): kobject_release, parent ffff880000189648 (delayed)
[    2.932143] kobject: 'drm' (ffff880006daf000): kobject_release, parent           (null) (delayed)
[    2.941844] kobject: 'controlD64' (ffff880006db2020): kobject_release, parent           (null) (delayed)
[    2.958432] kobject: 'parport_pc.956' (ffff880006db2020): kobject_release, parent           (null) (delayed)
[    2.965698] kobject: 'parport_pc.888' (ffff880006dc5820): kobject_release, parent           (null) (delayed)
[    2.972583] kobject: 'parport_pc.632' (ffff880006dc5020): kobject_release, parent           (null) (delayed)
[    3.031704] kobject: 'physmap-flash' (ffff880006ddc800): kobject_release, parent ffff880000189248 (delayed)
[    3.055119] kobject: 'docg3' (ffff880006de3c00): kobject_release, parent ffff880000189248 (delayed)
[    3.496256] kobject: 'gpio-vbus' (ffff880006817400): kobject_release, parent ffff880000189248 (delayed)
[    3.619023] kobject: '(null)' (ffff88000777baf0): kobject_release, parent           (null) (delayed)
[    3.657587] kobject: 'proc-osm' (ffff88000684be00): kobject_release, parent ffff880006849848 (delayed)
[    3.662546] kobject: 'mc13xxx-rtc' (ffff880006851e00): kobject_release, parent ffff880000189248 (delayed)
[    3.669144] kobject: 'rtc-msm6242' (ffff880006851c00): kobject_release, parent ffff880000189248 (delayed)
[    3.677494] kobject: 'pcap-rtc' (ffff880006851a00): kobject_release, parent ffff880000189248 (delayed)
[    3.680280] kobject: 'rtc-rp5c01' (ffff880006855a00): kobject_release, parent ffff880000189248 (delayed)
[    3.750200] kobject: 'mc13783-adc' (ffff880007707000): kobject_release, parent ffff880000189248 (delayed)

with some manual bisects, I find a good config (attached) that can
reliably boot the kernel up.

Based on that config, I tried adding parport_pc and see that it still
boots fine.

Adding drm, however will bring back the oops. Will try a kernel based
on the original kconfig with drm disabled only.

Thanks,
Fengguang

View attachment ".config.good" of type "text/plain" (77618 bytes)