From: Dave Airlie <airlied@gmail.com>
To: Andy Whitcroft <apw@canonical.com>
Cc: David Airlie <airlied@linux.ie>,
dri-devel@lists.freedesktop.org,
Jesse Barnes <jbarnes@virtuousgeek.org>,
Bryce Harrington <bryce@canonical.com>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 0/1] [RFC] DRM locking issues during early open
Date: Fri, 20 Apr 2012 11:34:43 +0100 [thread overview]
Message-ID: <CAPM=9txRi3=0=211S7RO=OqJwVPkFfQTtMC=DAhxZUUAW3voww@mail.gmail.com> (raw)
In-Reply-To: <20120420103110.GD3467@shadowen.org>
>
> I may be reading things wrong but the initialisation does indeed hold
> drm_global_mutex, but and back when this first occured we would have
> been using kernel_lock() which was at least partially reentrant right?
Yup if we slept with the BKL held we'd have allowed others to get past it,
but also I introduced the global mutex in pci a while back
commit b64c115eb22516ecd187c74ad6de3f1693f1dc7b
Author: Dave Airlie <airlied@redhat.com>
Date: Tue Sep 14 20:14:38 2010 +1000
drm: fix race between driver loading and userspace open.
Not 100% sure this is due to BKL removal, its most likely a combination
of that + userspace timing changes in udev/plymouth. The drm adds the sysfs
device before the driver has completed internal loading, this causes udev
to make the node and plymouth to open it before we've completed loading.
The proper solution is to delay the sysfs manipulation until later
in loading
however this causes knock on issues with sysfs connector nodes, so
we can use
the global mutex to serialise loading and userspace opens.
Reported-by: Toni Spets (hifi on #radeon)
Signed-off-by: Dave Airlie <airlied@redhat.com>
by a while I mean nearly 1.5 yrs ago, with the intent of fixing it this way.
Dave.
next prev parent reply other threads:[~2012-04-20 10:34 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-04-19 16:22 [PATCH 0/1] [RFC] DRM locking issues during early open 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: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 [this message]
2012-04-20 17:25 ` Andy Whitcroft
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='CAPM=9txRi3=0=211S7RO=OqJwVPkFfQTtMC=DAhxZUUAW3voww@mail.gmail.com' \
--to=airlied@gmail.com \
--cc=airlied@linux.ie \
--cc=apw@canonical.com \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.