diff options
author | Alexandru Moise <00moses.alexander00@gmail.com> | 2017-07-08 23:43:52 +0200 |
---|---|---|
committer | Daniel Vetter <daniel.vetter@ffwll.ch> | 2017-07-11 12:03:11 +0200 |
commit | 371c2279aa705c32730e738b3f173fb2e62b33e7 (patch) | |
tree | a9ffc3237f59570583d1a2b13c675eecae4626b6 /drivers/scsi/scsi_dh.c | |
parent | f74c527591b02a296e34d94c181b423587523f9e (diff) | |
download | linux-371c2279aa705c32730e738b3f173fb2e62b33e7.tar.bz2 |
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/scsi/scsi_dh.c')
0 files changed, 0 insertions, 0 deletions