From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Daniel Vetter <daniel@ffwll.ch>
Cc: Alexandru Moise <00moses.alexander00@gmail.com>,
Rusty Russell <rusty@rustcorp.com.au>,
Jessica Yu <jeyu@kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Daniel Vetter <daniel.vetter@intel.com>,
dri-devel <dri-devel@lists.freedesktop.org>,
Dave Airlie <airlied@linux.ie>, Sean Paul <seanpaul@chromium.org>,
"Nikula, Jani" <jani.nikula@linux.intel.com>
Subject: Re: [PATCH] drm: inhibit drm drivers register to uninitialized drm core
Date: Tue, 11 Jul 2017 11:41:02 +0200 [thread overview]
Message-ID: <20170711094102.GB14041@kroah.com> (raw)
In-Reply-To: <CAKMK7uHVO04N_HU_16=HHO+EAGs13i7o-O=teUZzcs2W5qeo1A@mail.gmail.com>
On Mon, Jul 10, 2017 at 08:00:37PM +0200, Daniel Vetter wrote:
> On Mon, Jul 10, 2017 at 9:14 AM, Alexandru Moise
> <00moses.alexander00@gmail.com> wrote:
> > On Mon, Jul 10, 2017 at 08:52:46AM +0200, Daniel Vetter wrote:
> >> On Sat, Jul 08, 2017 at 11:43:52PM +0200, Alexandru Moise wrote:
> >> > 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().
Note, there are patches in my "to-apply" queue to prevent that from
happening, that should show up in 4.14-rc1. So that shouldn't be an
issue in the future.
> I feared that would be the answer :-/ Still feels funny that everyone
> will need to hand-roll this, or does everyone simply assume that their
> subsystem's module_init never fails?
How would we not "hand-roll" this? Every subsystem works a bit
differently. But if you can think of a way to make this generic, that
would be great...
thanks,
greg k-h
next prev parent reply other threads:[~2017-07-11 9:41 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-07-08 21:43 [PATCH] drm: inhibit drm drivers register to uninitialized drm core Alexandru Moise
2017-07-10 6:52 ` Daniel Vetter
2017-07-10 7:14 ` Alexandru Moise
2017-07-10 18:00 ` Daniel Vetter
2017-07-10 19:56 ` Alexandru Moise
2017-07-11 7:53 ` Daniel Vetter
2017-07-11 9:41 ` Greg Kroah-Hartman [this message]
2017-07-11 10:02 ` Daniel Vetter
2017-07-11 10:04 ` Daniel Vetter
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20170711094102.GB14041@kroah.com \
--to=gregkh@linuxfoundation.org \
--cc=00moses.alexander00@gmail.com \
--cc=airlied@linux.ie \
--cc=daniel.vetter@intel.com \
--cc=daniel@ffwll.ch \
--cc=dri-devel@lists.freedesktop.org \
--cc=jani.nikula@linux.intel.com \
--cc=jeyu@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=rusty@rustcorp.com.au \
--cc=seanpaul@chromium.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox