Web lists-archives.org

Re: [announce] "kill the Big Kernel Lock (BKL)" tree




Kevin Winchester wrote:
Ingo Molnar wrote:

<snip description and patches>

I decided to give this tree a try, and I got:


[4294034.386085] ------------[ cut here ]------------
[4294034.387882] WARNING: at fs/proc/generic.c:669 create_proc_entry+0x3d/0xc5() [4294034.390059] Pid: 2565, comm: Xorg Not tainted 2.6.26-rc2-00456-gd9df34e #35
[4294034.392682]
[4294034.392683] Call Trace:
[4294034.394071]  [<ffffffff8022a8ac>] warn_on_slowpath+0x53/0x81
[4294034.394077]  [<ffffffff802b57b4>] ? proc_register+0xf7/0x162
[4294034.394081]  [<ffffffff802b580b>] ? proc_register+0x14e/0x162
[4294034.394087]  [<ffffffff804afa05>] ? _spin_unlock+0x30/0x4b
[4294034.394091]  [<ffffffff802b580b>] ? proc_register+0x14e/0x162
[4294034.394095]  [<ffffffff8021a127>] ? startup_ioapic_irq+0x54/0x5f
[4294034.394099]  [<ffffffff802b5fcc>] create_proc_entry+0x3d/0xc5
[4294034.394103]  [<ffffffff80252008>] register_irq_proc+0x84/0xa0
[4294034.394108]  [<ffffffff80250b1a>] setup_irq+0x1b2/0x21b
[4294034.394113]  [<ffffffff80250cc8>] request_irq+0xf1/0x117
[4294034.394117]  [<ffffffff8038aaaa>] ? radeon_driver_irq_handler+0x0/0x7e
[4294034.394122]  [<ffffffff803789b6>] ? drm_control+0x0/0x186
[4294034.394126]  [<ffffffff80378acf>] drm_control+0x119/0x186
[4294034.394130]  [<ffffffff803770be>] drm_ioctl+0x1d3/0x265
[4294034.394589]  [<ffffffff80283e5e>] vfs_ioctl+0x5e/0x77
[4294034.394593]  [<ffffffff802840d2>] do_vfs_ioctl+0x25b/0x270
[4294034.394598]  [<ffffffff804af23e>] ? trace_hardirqs_on_thunk+0x35/0x3a
[4294034.394601]  [<ffffffff80284129>] sys_ioctl+0x42/0x65
[4294034.394606]  [<ffffffff8020b2eb>] system_call_after_swapgs+0x7b/0x80
[4294034.411597]
[4294034.411601] ---[ end trace 7f52164e4c2b9927 ]---


And now applying the debugging tips that Linus, Al and others supplied to me awhile back, I see from GDB that:

vfs_ioctl locks the kernel before calling drm_ioctl, and, that create_proc_entry() has the following new line thanks to Ingo:

    WARN_ON_ONCE(kernel_locked());

According to Ingo's patch log:

    The functions, if called from the BKL, show that the calling site
    might have a dependency on the procfs code previously using the BKL
    in the dir-entry manipulation functions.

I do not really know what that means, so I cc'd Dave Airlie to see if he has a solution.

--
Kevin Winchester


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