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

From: Kevin Winchester
Date: Fri May 16 2008 - 20:38:08 EST

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.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.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:


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
Please read the FAQ at