Kevin Winchester wrote:
quoted text
> 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


--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/