Re: [xen] double fault: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC

[Ingo Molnar <mingo@kernel.org>]

* Ingo Molnar <mingo@kernel.org> wrote:

> * Fengguang Wu <fengguang.wu@intel.com> wrote:
> 
> > After enabling CONFIG_DEBUG_OBJECTS_TIMERS=y, it will issue a WARNING followed by a "BUG: ..."
> 
> Cool!
> 
> > [    2.802167] parport_pc 00:04: reported by Plug and Play ACPI
> > [    2.803818] parport0: PC-style at 0x378, irq 7 [PCSPP(,...)]
> > [    2.806035] kobject: 'parport_pc.956' (ffff880006dc3820): kobject_release, parent           (null) (delayed)
> > [    2.808626] ------------[ cut here ]------------                                                            
> > [    2.809776] WARNING: CPU: 1 PID: 1 at /c/wfg/linux/lib/debugobjects.c:260 debug_print_object+0x7c/0x8d()
> > [    2.812433] ODEBUG: init active (active state 0) object type: timer_list hint:           (null)         
> > ......
> > [    3.796079] BUG: unable to handle kernel NULL pointer dereference at           (null)
> 
> Mind posting the full backtrace? It should show the actual callsite that 
> zaps the timer. I don't think we got that dump so far, I've only seen 
> timer list corruption backtraces. (but I haven't read the whole thread.)

I see you already posted the dmesg in another part of this thread, so the 
relevant call-trace for parport_pc.c is:

> [    2.812579] Call Trace:
> [    2.812579]  [<ffffffff8184ea6e>] dump_stack+0x4f/0x84
> [    2.812579]  [<ffffffff8108f38d>] warn_slowpath_common+0x72/0x8c
> [    2.812579]  [<ffffffff81223681>] ? debug_print_object+0x7c/0x8d
> [    2.812579]  [<ffffffff8108f40b>] warn_slowpath_fmt+0x41/0x43
> [    2.812579]  [<ffffffff81223681>] debug_print_object+0x7c/0x8d
> [    2.812579]  [<ffffffff812239e0>] __debug_object_init+0x27c/0x2c6
> [    2.812579]  [<ffffffff81223a1b>] ? __debug_object_init+0x2b7/0x2c6
> [    2.812579]  [<ffffffff81223a3e>] debug_object_init+0x14/0x16
> [    2.812579]  [<ffffffff810992e8>] init_timer_key+0x23/0x65
> [    2.812579]  [<ffffffff8121352f>] kobject_release+0x90/0xba
> [    2.812579]  [<ffffffff812137ac>] kobject_put+0x4d/0x51
> [    2.812579]  [<ffffffff81482cfb>] put_device+0x12/0x14
> [    2.812579]  [<ffffffff814873a2>] platform_device_put+0x12/0x14
> [    2.812579]  [<ffffffff81487727>] platform_device_unregister+0x16/0x1a
> [    2.812579]  [<ffffffff814810f9>] parport_pc_probe_port+0x7c4/0x7d9
> [    2.812579]  [<ffffffff81e36c75>] parport_pc_init+0x2b0/0x317
> [    2.812579]  [<ffffffff81e369c5>] ? parport_setup+0x147/0x147
> [    2.812579]  [<ffffffff81e11e0c>] do_one_initcall+0x8e/0x132
> [    2.812579]  [<ffffffff810a7000>] ? param_array_set+0x7f/0xf2
> [    2.812579]  [<ffffffff810a7275>] ? parse_args+0x1ad/0x26c
> [    2.812579]  [<ffffffff81e11fe2>] kernel_init_freeable+0x132/0x1bc
> [    2.812579]  [<ffffffff81e116e3>] ? do_early_param+0x86/0x86
> [    2.812579]  [<ffffffff818488bf>] ? rest_init+0xc3/0xc3
> [    2.812579]  [<ffffffff818488c8>] kernel_init+0x9/0xcc
> [    2.812579]  [<ffffffff81859e3c>] ret_from_fork+0x7c/0xb0
> [    2.812579]  [<ffffffff818488bf>] ? rest_init+0xc3/0xc3
> [    2.812579] ---[ end trace ce7dd707bef7dc3e ]---

It appears a delayed callback is already active for that platform device? 
Looks weird, because in theory platform devices are allocated anew in 
parport_pc_probe_port():

                pdev = platform_device_register_simple("parport_pc",
                                                       base, NULL, 0);
                if (IS_ERR(pdev))
                        return NULL;
                dev = &pdev->dev;

Which is allocated via zalloc(), so no reuse.

and then released if the hardware port is not present:

 out1:
        if (pdev)
                platform_device_unregister(pdev);

Thanks,

	Ingo