mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Andy Whitcroft <apw@canonical.com>
To: Andy Whitcroft <apw@canonical.com>,
	David Airlie <airlied@linux.ie>,
	dri-devel@lists.freedesktop.org
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>,
	Bryce Harrington <bryce@canonical.com>,
	linux-kernel@vger.kernel.org
Subject: [PATCH 0/1] [RFC] DRM locking issues during early open
Date: Thu, 19 Apr 2012 17:22:04 +0100	[thread overview]
Message-ID: <1334852525-14950-1-git-send-email-apw@canonical.com> (raw)

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?

-apw

Andy Whitcroft (1):
  drm -- stop early access to drm devices

 drivers/gpu/drm/drm_fops.c     |    8 ++++++--
 drivers/gpu/drm/drm_pci.c      |    4 ++++
 drivers/gpu/drm/drm_platform.c |    4 ++++
 drivers/gpu/drm/drm_stub.c     |    2 +-
 4 files changed, 15 insertions(+), 3 deletions(-)

-- 
1.7.9.5


             reply	other threads:[~2012-04-19 16:22 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-04-19 16:22 Andy Whitcroft [this message]
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
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=1334852525-14950-1-git-send-email-apw@canonical.com \
    --to=apw@canonical.com \
    --cc=airlied@linux.ie \
    --cc=bryce@canonical.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=jbarnes@virtuousgeek.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

all inboxes | Powered by JetHome®