summaryrefslogtreecommitdiffstats
path: root/drivers/gpu/drm/drm_simple_kms_helper.c
diff options
context:
space:
mode:
authorAlexandru Moise <00moses.alexander00@gmail.com>2017-07-08 23:43:52 +0200
committerDaniel Vetter <daniel.vetter@ffwll.ch>2017-07-11 12:03:11 +0200
commit371c2279aa705c32730e738b3f173fb2e62b33e7 (patch)
treea9ffc3237f59570583d1a2b13c675eecae4626b6 /drivers/gpu/drm/drm_simple_kms_helper.c
parentf74c527591b02a296e34d94c181b423587523f9e (diff)
downloadlinux-stable-371c2279aa705c32730e738b3f173fb2e62b33e7.tar.gz
linux-stable-371c2279aa705c32730e738b3f173fb2e62b33e7.tar.bz2
linux-stable-371c2279aa705c32730e738b3f173fb2e62b33e7.zip
drm: inhibit drm drivers register to uninitialized drm core
If the DRM core fails to init for whatever reason, ensure that no driver ever calls drm_dev_register(). This is best done at drm_dev_init() as it covers drivers that call drm_dev_alloc() as well as drivers that prefer to embed struct drm_device into their own device struct and call drm_dev_init() themselves. In my case I had so many dynamic device majors used that the major number for DRM (226) was stolen, causing DRM core init to fail after failing to register a chrdev, and ultimately calling debugfs_remove() on drm_debugfs_root in drm_core_exit(). After drm core failed to init, VGEM was still calling drm_dev_register(), ultimately leading to drm_debugfs_init(), with drm_debugfs_root passed as the root for the new debugfs dir at debugfs_create_dir(). This led to a kernel panic once we were either derefencing root->d_inode while it was NULL or calling root->d_inode->i_op->lookup() while it was NULL in debugfs at inode_lock() or lookup_*(). Signed-off-by: Alexandru Moise <00moses.alexander00@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/20170708214352.GA27205@gmail.com
Diffstat (limited to 'drivers/gpu/drm/drm_simple_kms_helper.c')
0 files changed, 0 insertions, 0 deletions