On Mon, Dec 05, 2016 at 08:42:49AM +0100, Christian König wrote:
Am 05.12.2016 um 08:27 schrieb Daniel Vetter:
On Sat, Dec 03, 2016 at 03:47:00PM +0100, Nicolai Stange wrote:
Since commit 8a357d10043c ("drm: Nerf DRM_CONTROL nodes"), a struct drm_device's ->control member is always NULL.
In the case of CONFIG_DEBUG_FS=y, radeon_debugfs_add_files() accesses ->control->debugfs_root though. This results in the following Oops:
BUG: unable to handle kernel NULL pointer dereference at 0000000000000018 IP: radeon_debugfs_add_files+0x90/0x100 [radeon] PGD 0 Oops: 0000 [#1] SMP [...] Call Trace: ? work_on_cpu+0xb0/0xb0 radeon_fence_driver_init+0x120/0x150 [radeon] si_init+0x122/0xd50 [radeon] ? _raw_spin_unlock_irq+0x2c/0x40 ? device_pm_check_callbacks+0xb3/0xc0 radeon_device_init+0x958/0xda0 [radeon] radeon_driver_load_kms+0x9a/0x210 [radeon] drm_dev_register+0xa9/0xd0 [drm] drm_get_pci_dev+0x9c/0x1e0 [drm] radeon_pci_probe+0xb8/0xe0 [radeon] [...]
Fix this by omitting the drm_debugfs_create_files() call for the control minor debugfs directory which is now non-existent anyway.
Fixes: 8a357d10043c ("drm: Nerf DRM_CONTROL nodes") Signed-off-by: Nicolai Stange nicstange@gmail.com
Applied to drm-misc with Dave's irc ack, thanks for your patch.
If it's still worth it the patch is Reviewed-by: Christian König christian.koenig@amd.com.
On the other hand when ->control is always NULL, why do we still have ->control anyway?
I'm chicken and didn't want to mass-delete code from the start. But yeah after a few kernel releases to make sure no one noticed the removal of control nodes we can garbage collected. I guess I've been bitten a few too many times when trying to remove old stuff ;-)
And BTW: Please double check the other drivers as well.
Yeah, I've done a full audit, only qxl turned up to have similar code. Already merged with Dave's irc ack. -Daniel