From: Daniel Vetter <daniel@ffwll.ch>
To: Dave Airlie <airlied@gmail.com>
Cc: Andy Whitcroft <apw@canonical.com>,
dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 0/1] [RFC] DRM locking issues during early open
Date: Thu, 19 Apr 2012 18:41:25 +0200 [thread overview]
Message-ID: <20120419164125.GI4256@phenom.ffwll.local> (raw)
In-Reply-To: <CAPM=9tzWO46u5L1jnRvi_zhgOhmzH1df7cQTnP6+0Kh4Znpn7g@mail.gmail.com>
On Thu, Apr 19, 2012 at 05:30:03PM +0100, Dave Airlie wrote:
> On Thu, Apr 19, 2012 at 5:22 PM, Andy Whitcroft <apw@canonical.com> wrote:
> > We have been carrying a (rather poor) patch for an issue we identified in
> > the DRM driver. This issue is triggered when a DRM device is initialising
> > and userspace attempts to open it, typically in response to the sysfs
> > device added event. Basically we allocate the minor numbers making
> > the device available, and then call the drm load callback. Until this
> > completes the device is really not ready and these early opens typically
> > lead to oopses.
> >
> > We have been using the following patch to avoid this by marking the minors
> > as in error until the load method has completed. This avoids the early
> > open by simply erroring out the opens with EAGAIN. Obviously we should
> > be delaying the open until the load method complete.
> >
> > I include the existing patch for completness (it is not really ready for
> > merging) to illustrate the issue. I think it is logical that the wait
> > should simply be delayed until the load has completed. I am proposing
> > to include a wait queue associated with the idr cache for the drm minors
> > which we can use to allow open callers to wait_event_interruptible() on.
> > I'll be putting together a prototype shortly and will follow up with it.
> >
> > Thoughts?
>
> Couldn't we just delay registering things until the driver is ready to
> accept an open?
It's somewhere on my eternal&epic todo list.
> Granted the midlayer of drm doesn't make that easy,
... after fixing this one ;-)
> thanks for sending this out, it keeps falling off my radar, I don't
> think I've ever seen this reported on RHEL/Fedora, which makes me
> wonder what we are doing that makes us lucky.
I think it's just a matter of races, if you load the drm module early
enough (like fedora does already in the initrd) and ensure that nothing
pokes drm devices for a few seconds, you'll be fine. Iirc ubuntus powerd
stuff is really got at brining everything down. Also, not loading the
module with udev, but loading it with X resulted in nice fireworks last
time I've tried that (radeon ums was trying to set up the card while the
kms code was doing the same, hilarity ensued).
-Daniel
--
Daniel Vetter
Mail: daniel@ffwll.ch
Mobile: +41 (0)79 365 57 48
next prev parent reply other threads:[~2012-04-19 16:40 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-04-19 16:22 Andy Whitcroft
2012-04-19 16:22 ` [PATCH 1/1] drm -- stop early access to drm devices Andy Whitcroft
2012-04-19 16:30 ` [PATCH 0/1] [RFC] DRM locking issues during early open Dave Airlie
2012-04-19 16:41 ` Andy Whitcroft
2012-04-19 16:47 ` Dave Airlie
2012-04-19 16:52 ` Dave Airlie
2012-04-19 16:55 ` Jesse Barnes
2012-04-19 16:56 ` Dave Airlie
2012-04-19 17:00 ` Dave Airlie
2012-04-19 16:41 ` Daniel Vetter [this message]
2012-04-20 9:40 ` Dave Airlie
2012-04-20 10:31 ` Andy Whitcroft
2012-04-20 10:34 ` Dave Airlie
2012-04-20 17:25 ` Andy Whitcroft
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=20120419164125.GI4256@phenom.ffwll.local \
--to=daniel@ffwll.ch \
--cc=airlied@gmail.com \
--cc=apw@canonical.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=linux-kernel@vger.kernel.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
Powered by JetHome