We kzalloc this structure, and for real kms devices we should never
loose track of things really.

But ums/legacy drivers rely on the drm core to clean up a bit of cruft
between lastclose and firstopen (i.e. when X is being restarted), so
keep this around. But give it a clear drm_legacy_ prefix and
conditionalize the code on !DRIVER_MODESET.

Cc: David Herrmann <dh.herrmann@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: NDavid Herrmann <dh.herrmann@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

It has way too much potential for driver writers to do stupid things
like delayed hw setup because the load sequence is somehow racy (e.g.
the imx driver in staging). So don't call it for modesetting drivers,
which reduces the complexity of the drm core -> driver interface a
notch.

v2: Don't forget to update DocBook.

v3: Go with Laurent's slightly more elaborate proposal for the DocBook
update. Add a few words on top of his diff to elaborate a bit on what
KMS drivers should and shouldn't do in lastclose. There was already a
paragraph present talking about restoring properties, I've simply
extended that one.

Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NDave Airlie <airlied@redhat.com>

So I've stumbled over drm_fasync and wondered what it does. Digging
that up is quite a story.

First I've had to read up on what this does and ended up being rather
bewildered why peopled loved signals so much back in the days that
they've created SIGIO just for that ...

Then I wondered how this ever works, and what that strange "No-op."
comment right above it should mean. After all calling the core fasync
helper is pretty obviously not a noop. After reading through the
kernels FASYNC implementation I've noticed that signals are only sent
out to the processes attached with FASYNC by calling kill_fasync.

No merged drm driver has ever done that.

After more digging I've found out that the only driver that ever used
this is the so called GAMMA driver. I've frankly never heard of such a
gpu brand ever before. Now FASYNC seems to not have been the only bad
thing with that driver, since Dave Airlie removed it from the drm
driver with prejudice:

commit 1430163b4bbf7b00367ea1066c1c5fe85dbeefed
Author: Dave Airlie <airlied@linux.ie>
Date:   Sun Aug 29 12:04:35 2004 +0000

    Drop GAMMA DRM from a great height ...

Long story short, the drm fasync support seems to be doing absolutely
nothing. And the only user of it was never merged into the upstream
kernel. And we don't need any fops->fasync callback since the fcntl
implementation in the kernel already implements the noop case
correctly.

So stop this particular cargo-cult and rip it all out.

v2: Kill drm_fasync assignments in rcar (newly added) and imx drivers
(somehow I've missed that one in staging). Also drop the reference in
the drm DocBook. ARM compile-fail reported by Rob Clark.

v3: Move the removal of dev->buf_asnyc assignment in drm_setup to this
patch here.

v4: Actually git add ... tsk.

Cc: Dave Airlie <airlied@linux.ie>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Rob Clark <robdclark@gmail.com>
Acked-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: NDavid Herrmann <dh.herrmann@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

So after a lot of digging around in git histories it looks like this
has only ever be used by dri1 render clients. Hence we can fully
disable the entire thing for modesetting drivers and so greatly reduce
the attack surface for potential exploits (or at least tools like
trinity ...).

Also add the drm_legacy prefix for functions which are called from
common code. To further reduce the impact on common code also extract
all the ctx release handling into a function (instead of only
releasing individual handles) and make ctxbitmap_cleanup return void -
it can never fail.
Reviewed-by: NEric Anholt <eric@anholt.net>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NDave Airlie <airlied@redhat.com>

And hide the checks a bit better. This was already disallowed for
modesetting drivers, so no functinal change here.
Reviewed-by: NEric Anholt <eric@anholt.net>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Only ever re-cleared in drm_setup, otherwise completely unused.
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NDave Airlie <airlied@gmail.com>

Again totally unused, so just remove them.
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NDave Airlie <airlied@gmail.com>

Again completely unused, so just remove it.
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NDave Airlie <airlied@gmail.com>

Completely unused, so just remove them.
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NDave Airlie <airlied@gmail.com>

Only ever assigned in the context code for real, with no readers
anywhere. Remove it.
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NDave Airlie <airlied@gmail.com>

No one ever waits on this waitqueue, so the wake_up call is wasted.
Remove it all.
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NDave Airlie <airlied@gmail.com>

There are missing parts to handle error in drm_open_helper().
The priv->minor, assigned by idr_find() which can return NULL,
should be checked whether it is NULL or not before referencing it.
put_pid(), drm_gem_release(), and drm_prime_destory_file_private()
should be called when error happens after their pair functions are
called. If an error occurs after executing dev->driver->open()
which allocates driver specific per-file private data, then the
private data should be released.
Signed-off-by: NYoungJun Cho <yj44.cho@samsung.com>
Signed-off-by: NSeung-Woo Kim <sw0312.kim@samsung.com>
Signed-off-by: NKyungmin Park <kyungmin.park@samsung.com>
Reviewed-by: Chris Wilson <chris-wilson.co.uk>
Signed-off-by: NDave Airlie <airlied@redhat.com>

If first drm_open fails, the error-handling path will
incorrectly restore inode's mapping to NULL. This can
cause the crash later on. Fix by separately storing
away mapping pointers that drm_open can touch and
restore each from its own respective variable if the
call fails.

Fixes: https://bugzilla.novell.com/show_bug.cgi?id=807850
(thanks to Michal Hocko for investigating investigating and
finding the root cause of the bug)

Reference:
http://lists.freedesktop.org/archives/dri-devel/2013-March/036564.html

v2: Use one variable to store file and inode mapping
    since they are the same at the function entry.
    Fix spelling mistakes in commit message.

v3: Add reference to the original bug report.
Reported-by: NMarco Munderloh <munderl@tnt.uni-hannover.de>
Tested-by: NMarco Munderloh <munderl@tnt.uni-hannover.de>
Signed-off-by: NIlija Hadzic <ihadzic@research.bell-labs.com>
Cc: Michal Hocko <mhocko@suse.cz>
Cc: stable@vger.kernel.org
Signed-off-by: NDave Airlie <airlied@redhat.com>

Well, at least step 1. The goal here is that framebuffer objects can
survive outside of the mode_config lock, with just a reference held
as protection. The first step to get there is to introduce a special
fb_lock which protects fb lookup, creation and destruction, to make
them appear atomic.

This new fb_lock can nest within the mode_config lock. But the idea is
(once the reference counting part is completed) that we only quickly
take that fb_lock to lookup a framebuffer and grab a reference,
without any other locks involved.

vmwgfx is the only driver which does framebuffer lookups itself, also
wrap those calls to drm_mode_object_find with the new lock.

Also protect the fb_list walking in i915 and omapdrm with the new lock.

As a slight complication there's also the list of user-created fbs
attached to the file private. The problem now is that at fclose() time
we need to walk that list, eventually do a modeset call to remove the
fb from active usage (and are required to be able to take the
mode_config lock), but in the end we need to grab the new fb_lock to
remove the fb from the list. The easiest solution is to add another
mutex to protect this per-file list.

Currently that new fbs_lock nests within the modeset locks and so
appears redudant. But later patches will switch around this sequence
so that taking the modeset locks in the fb destruction path is
optional in the fastpath. Ultimately the goal is that addfb and rmfb
do not require the mode_config lock, since otherwise they have the
potential to introduce stalls in the pageflip sequence of a compositor
(if the compositor e.g. switches to a fullscreen client or if it
enables a plane). But that requires a few more steps and hoops to jump
through.

Note that framebuffer creation/destruction is now double-protected -
once by the fb_lock and in parts by the idr_lock. The later would be
unnecessariy if framebuffers would have their own idr allocator. But
that's material for another patch (series).

v2: Properly initialize the fb->filp_head list in _init, otherwise the
newly added WARN to check whether the fb isn't on a fpriv list any
more will fail for driver-private objects.

v3: Fixup two error-case unlock bugs spotted by Richard Wilbur.
Reviewed-by: NRob Clark <rob@ti.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Some drivers (specifically vmwgfx) look at dev_mapping
in their open hook, so we have to set dev->dev_mapping
earlier in the process.

Reference:
http://lists.freedesktop.org/archives/dri-devel/2012-October/029420.htmlSigned-off-by: NIlija Hadzic <ihadzic@research.bell-labs.com>
Reported-by: NThomas Hellstrom <thellstrom@vmware.com>
Cc: stable@vger.kernel.org
Reviewed-by: NThomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

If drm_setup (called at first open) fails, the whole
open call has failed, so we should not keep the
open_count incremented.
Signed-off-by: NIlija Hadzic <ihadzic@research.bell-labs.com>
Cc: stable@vger.kernel.org
Reviewed-by: NThomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Convert #include "..." to #include <path/...> in drivers/gpu/.
Signed-off-by: NDavid Howells <dhowells@redhat.com>
Acked-by: NDave Airlie <airlied@redhat.com>
Acked-by: NArnd Bergmann <arnd@arndb.de>
Acked-by: NThomas Gleixner <tglx@linutronix.de>
Acked-by: NPaul E. McKenney <paulmck@linux.vnet.ibm.com>
Acked-by: NDave Jones <davej@redhat.com>

Blink Blink this had not been converted to use struct pid ages ago?

- On drm open capture the openers kuid and struct pid.
- On drm close release the kuid and struct pid
- When reporting the uid and pid convert the kuid and struct pid
  into values in the appropriate namespace.

Cc: dri-devel@lists.freedesktop.org
Acked-by: NDave Airlie <airlied@redhat.com>
Acked-by: NSerge Hallyn <serge.hallyn@canonical.com>
Signed-off-by: NEric W. Biederman <ebiederm@xmission.com>

Setting dev_mapping (pointer to the address_space structure
used for memory mappings) to the address_space of the first
opener's inode and then failing if other openers come in
through a different inode has a few restrictions that are
eliminated by this patch.

If we already have valid dev_mapping and we spot an opener
with different i_node, we force its i_mapping pointer to the
already established address_space structure (first opener's
inode). This will make all mappings from drm device hang off
the same address_space object.

Some benefits (things that now work and didn't work
before) of this patch are:

 * user space can mknod and use any number of device
   nodes and they will all work fine as long as the major
   device number is that of the drm module.
 * user space can even remove the first opener's device
   nodes and mknod the new one and the applications and
   windowing system will still work.
 * GPU drivers can safely assume that dev->dev_mapping is
   correct address_space and just blindly copy it
   into their (private) bdev.dev_mapping

For reference, some discussion that lead to this patch can
be found here:

http://lists.freedesktop.org/archives/dri-devel/2012-April/022283.htmlSigned-off-by: NIlija Hadzic <ihadzic@research.bell-labs.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

With the last patch to ditch DMA_QUEUE support, we should be able
to call the dma cleanup uncoditionally, even when the master has
disappeared.

Do so because it just makes more sense.
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Absolutely unused. All the values are only ever initialized and
then used at most in some debug printout functions.
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NDave Airlie <airlied@redhat.com>

All leftover users either haven't set DRIVER_HAVE_DMA, in which
case this will never be called, or use the drm_core implementation.

Call that directly in the only callsite.
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NDave Airlie <airlied@redhat.com>

i810 was the last user of this code, with that gone, kill it.
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NDave Airlie <airlied@redhat.com>

The only two users are now folded into the drivers preclose functions,
so this is unused.
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NDave Airlie <airlied@redhat.com>

During DRM release, all the FBs and gem objects are released. If
a gem object is being used as a FB and set to a crtc, it must not
be freed before releasing the framebuffer first.

If FBs are released first, the crtc using the FB is disabled first
so now the GEM object can be freed safely. The CRTC will be enabled
again when the driver restores fbdev mode.
Signed-off-by: NPrathyush K <prathyush.k@samsung.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

This adds the basic drm dma-buf interface layer, called PRIME. This
commit doesn't add any driver support, it is simply and agreed upon starting
point so we can work towards merging driver support for the next merge window.

Current drivers with work done are nouveau, i915, udl, exynos and omap.

The main APIs exposed to userspace allow translating a 32-bit object handle
to a file descriptor, and a file descriptor to a 32-bit object handle.

The flags value is currently limited to O_CLOEXEC.

Acknowledgements:
Daniel Vetter: lots of review
Rob Clark: cleaned up lots of the internals and did lifetime review.

v2: rename some functions after Chris preferred a green shed
fix IS_ERR_OR_NULL -> IS_ERR
v3: Fix Ville pointed out using buffer + kmalloc
v4: add locking as per ickle review
v5: allow re-exporting the original dma-buf (Daniel)
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: NRob Clark <rob.clark@linaro.org>
Reviewed-by: NSumit Semwal <sumit.semwal@linaro.org>
Reviewed-by: NInki Dae <inki.dae@samsung.com>
Acked-by: NBen Widawsky <benjamin.widawsky@intel.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Two parts to this, one is simple unplug from sysfs for the device node.

The second adds an unplugged state, if we have device opens, we
just set the unplugged state and return, if we have no device
opens we drop the drm device.

If after a lastclose we discover we are unplugged we then
drop the drm device.

v2: use an atomic for unplugged and wrap it for users,
add checks on open + mmap + ioctl entry points.
Signed-off-by: NDave Airlie <airlied@redhat.com>

If the master tries to authenticate a client using drm_authmagic and
that client has already closed its drm file descriptor,
either wilfully or because it was terminated, the
call to drm_authmagic will dereference a stale pointer into kmalloc'ed memory
and corrupt it.

Typically this results in a hard system hang.

This patch fixes that problem by removing any authentication tokens
(struct drm_magic_entry) open for a file descriptor when that file
descriptor is closed.
Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Cc: stable@vger.kernel.org
Signed-off-by: NDave Airlie <airlied@redhat.com>

From fdf1fdebaa00f81de18c227f32f8074c8b352d50 Mon Sep 17 00:00:00 2001
From: Arjan van de Ven <arjan@linux.intel.com>
Date: Sun, 30 Oct 2011 19:06:07 -0700
Subject: [PATCH] drm: Make the per-driver file_operations struct const

The DRM layer keeps a copy of struct file_operations inside its
big driver struct... which prevents it from being consistent and static.
For consistency (and the general security objective of having such things
static), it's desirable to get this fixed.

This patch splits out the file_operations field to its own struct,
which is then "static const", and just stick a pointer to this into
the driver struct, making it more consistent with how the rest of the
kernel does this.
Signed-off-by: NArjan van de Ven <arjan@linux.intel.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

So that we don't get build failures once the implicit module.h
presence is removed.
Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>

We need to track the state of the switch in drivers, so that after s/r
we don't resume the card we've explicitly switched off before. Also
don't allow a userspace open to occur if we've switched the gpu off.
Signed-off-by: NDave Airlie <airlied@redhat.com>

The big kernel lock has been removed from all these files at some point,
leaving only the #include.

Remove this too as a cleanup.
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Nouveau needs to be able to drop the mutex before sleeping to prevent a
deadlock from occuring.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

When removing of the BKL the locking around lastclose() was rearranged
and resulted in the holding of the open_count spinlock over the call
into drm_lastclose(). The drivers were not ready for this path to be
atomic - it may indeed involve long waits to release old objects and
cleanup the GPU - and so we ended up scheduling whilst atomic.

[   54.625598] BUG: scheduling while atomic: X/3546/0x00000002
[   54.625600] Modules linked in: sco bridge stp llc input_polldev rfcomm bnep l2cap crc16 sch_sfq ipv6 md_mod acpi_cpufreq mperf cryptd aes_x86_64 aes_generic xts gf128mul dm_crypt dm_mod btusb bluetooth usbhid hid zaurus cdc_ether usbnet mii cdc_wdm cdc_acm uvcvideo videodev v4l1_compat v4l2_compat_ioctl32 snd_hda_codec_conexant arc4 pcmcia ecb snd_hda_intel joydev sdhci_pci sdhci snd_hda_codec tpm_tis firewire_ohci mmc_core e1000e uhci_hcd thinkpad_acpi nvram yenta_socket pcmcia_rsrc pcmcia_core tpm wmi sr_mod firewire_core iwlagn ehci_hcd snd_hwdep snd_pcm usbcore tpm_bios thermal led_class snd_timer iwlcore snd soundcore ac snd_page_alloc pcspkr psmouse serio_raw battery sg mac80211 evdev cfg80211 i2c_i801 iTCO_wdt iTCO_vendor_support cdrom processor crc_itu_t rfkill xfs exportfs sd_mod crc_t10dif ahci libahci libata scsi_mod [last unloaded: scsi_wait_scan]
[   54.625663] Pid: 3546, comm: X Not tainted 2.6.35-04771-g17879857 #301
[   54.625665] Call Trace:
[   54.625671]  [<ffffffff8102d599>] __schedule_bug+0x57/0x5c
[   54.625675]  [<ffffffff81384141>] schedule+0xe5/0x832
[   54.625679]  [<ffffffff81163e77>] ? put_dec+0x20/0x3c
[   54.625682]  [<ffffffff81384dd4>] schedule_timeout+0x275/0x29f
[   54.625686]  [<ffffffff810455e1>] ? process_timeout+0x0/0xb
[   54.625688]  [<ffffffff81384e17>] schedule_timeout_uninterruptible+0x19/0x1b
[   54.625691]  [<ffffffff81045893>] msleep+0x16/0x1d
[   54.625695]  [<ffffffff812a2e53>] i9xx_crtc_dpms+0x273/0x2ae
[   54.625698]  [<ffffffff812a18be>] intel_crtc_dpms+0x28/0xe7
[   54.625702]  [<ffffffff811ec0fa>] drm_helper_disable_unused_functions+0xf0/0x118
[   54.625705]  [<ffffffff811ecde3>] drm_crtc_helper_set_config+0x644/0x7c8
[   54.625708]  [<ffffffff811f12dd>] ? drm_copy_field+0x40/0x50
[   54.625711]  [<ffffffff811ebca2>] drm_fb_helper_force_kernel_mode+0x3e/0x85
[   54.625713]  [<ffffffff811ebcf2>] drm_fb_helper_restore+0x9/0x24
[   54.625717]  [<ffffffff81290a41>] i915_driver_lastclose+0x2b/0x5c
[   54.625720]  [<ffffffff811f14a7>] drm_lastclose+0x44/0x2ad
[   54.625722]  [<ffffffff811f1ed2>] drm_release+0x5c6/0x609
[   54.625726]  [<ffffffff810d1275>] fput+0x109/0x1c7
[   54.625728]  [<ffffffff810ce5e4>] filp_close+0x61/0x6b
[   54.625731]  [<ffffffff810ce680>] sys_close+0x92/0xd4
[   54.625734]  [<ffffffff81002a2b>] system_call_fastpath+0x16/0x1b

v2: The spinlock is actually superfluous as access to open_count is
entirely serialised by drm_global_mutex and so can be dropped. The
count_lock spinlock instead appears to be used to protect access to
dev->buf_alloc and dev->buf_use.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDave Airlie <airlied@redhat.com>

This restricts the use of the big kernel lock to the i830 and i810
device drivers. The three remaining users in common code (open, ioctl
and release) get converted to a new mutex, the drm_global_mutex,
making the locking stricter than the big kernel lock.

This may have a performance impact, but only in those cases that
currently don't use DRM_UNLOCKED flag in the ioctl list and would
benefit from that anyway.

The reason why i810 and i830 cannot use drm_global_mutex in their
mmap functions is a lock-order inversion problem between the current
use of the BKL and mmap_sem in these drivers. Since the BKL has
release-on-sleep semantics, it's harmless but it would cause trouble
if we replace the BKL with a mutex.

Instead, these drivers get their own ioctl wrappers that take the
BKL around every ioctl call and then set their own handlers as
DRM_UNLOCKED.
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Cc: David Airlie <airlied@linux.ie>
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: NDave Airlie <airlied@redhat.com>

Use kzalloc rather than the combination of kmalloc and memset.

The semantic patch that makes this change is as follows:
(http://coccinelle.lip6.fr/)

// <smpl>
@@
expression x,size,flags;
statement S;
@@

-x = kmalloc(size,flags);
+x = kzalloc(size,flags);
 if (x == NULL) S
-memset(x, 0, size);
// </smpl>
Signed-off-by: NJulia Lawall <julia@diku.dk>
Reviewed-by: NCorbin Simpson <MostAwesomeDude@gmail.com>
Reviewed-by: NMatt Turner <mattst88@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Replace a BUG_ON with an error code in the event that the inode mapping
changes between calls to drm_open. This may happen for instance if udev
is loaded subsequent to the original opening of the device:

[  644.291870] kernel BUG at drivers/gpu/drm/drm_fops.c:146!
[  644.291876] invalid opcode: 0000 [#1] SMP
[  644.291882] last sysfs file: /sys/kernel/uevent_seqnum
[  644.291888]
[  644.291895] Pid: 7276, comm: lt-cairo-test-s Not tainted 2.6.34-rc1 #2 N150/N210/N220             /N150/N210/N220
[  644.291903] EIP: 0060:[<c11c70e3>] EFLAGS: 00210283 CPU: 0
[  644.291912] EIP is at drm_open+0x4b1/0x4e2
[  644.291918] EAX: f72d8d18 EBX: f790a400 ECX: f73176b8 EDX: 00000000
[  644.291923] ESI: f790a414 EDI: f790a414 EBP: f647ae20 ESP: f647adfc
[  644.291929]  DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
[  644.291937] Process lt-cairo-test-s (pid: 7276, ti=f647a000 task=f73f5c80 task.ti=f647a000)
[  644.291941] Stack:
[  644.291945]  00000000 f7bb7400 00000080 f6451100 f73176b8 f6479214 f6451100 f73176b8
[  644.291957] <0> c1297ce0 f647ae34 c11c6c04 f73176b8 f7949800 00000000 f647ae54 c1080ac5
[  644.291969] <0> f7949800 f6451100 00000000 f6451100 f73176b8 f6452780 f647ae70 c107d1e6
[  644.291982] Call Trace:
[  644.291991]  [<c11c6c04>] ? drm_stub_open+0x8a/0xb8
[  644.292000]  [<c1080ac5>] ? chrdev_open+0xef/0x106
[  644.292008]  [<c107d1e6>] ? __dentry_open+0xd4/0x1a6
[  644.292015]  [<c107d35b>] ? nameidata_to_filp+0x31/0x45
[  644.292022]  [<c10809d6>] ? chrdev_open+0x0/0x106
[  644.292030]  [<c10864e2>] ? do_last+0x346/0x423
[  644.292037]  [<c108789f>] ? do_filp_open+0x190/0x415
[  644.292046]  [<c1071eb5>] ? handle_mm_fault+0x214/0x710
[  644.292053]  [<c107d008>] ? do_sys_open+0x4d/0xe9
[  644.292061]  [<c1016462>] ? do_page_fault+0x211/0x23f
[  644.292068]  [<c107d0f0>] ? sys_open+0x23/0x2b
[  644.292075]  [<c1002650>] ? sysenter_do_call+0x12/0x26
[  644.292079] Code: 89 f0 89 55 dc e8 8d 96 0a 00 8b 45 e0 8b 55 dc 83 78 04 01 75 28 8b 83 18 02 00 00 85 c0 74 0f 8b 4d ec 3b 81 ac 00 00 00 74 13 <0f> 0b eb fe 8b 4d ec 8b 81 ac 00 00 00 89 83 18 02 00 00 89 f0
[  644.292143] EIP: [<c11c70e3>] drm_open+0x4b1/0x4e2 SS:ESP 0068:f647adfc
[  644.292175] ---[ end trace 2ddd476af89a60fa ]---
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: stable@kernel.org
Signed-off-by: NDave Airlie <airlied@redhat.com>

include cleanup: Update gfp.h and slab.h includes to prepare for breaking implicit slab.h inclusion from percpu.h

percpu.h is included by sched.h and module.h and thus ends up being
included when building most .c files.  percpu.h includes slab.h which
in turn includes gfp.h making everything defined by the two files
universally available and complicating inclusion dependencies.

percpu.h -> slab.h dependency is about to be removed.  Prepare for
this change by updating users of gfp and slab facilities include those
headers directly instead of assuming availability.  As this conversion
needs to touch large number of source files, the following script is
used as the basis of conversion.

  http://userweb.kernel.org/~tj/misc/slabh-sweep.py

The script does the followings.

* Scan files for gfp and slab usages and update includes such that
  only the necessary includes are there.  ie. if only gfp is used,
  gfp.h, if slab is used, slab.h.

* When the script inserts a new include, it looks at the include
  blocks and try to put the new include such that its order conforms
  to its surrounding.  It's put in the include block which contains
  core kernel includes, in the same order that the rest are ordered -
  alphabetical, Christmas tree, rev-Xmas-tree or at the end if there
  doesn't seem to be any matching order.

* If the script can't find a place to put a new include (mostly
  because the file doesn't have fitting include block), it prints out
  an error message indicating which .h file needs to be added to the
  file.

The conversion was done in the following steps.

1. The initial automatic conversion of all .c files updated slightly
   over 4000 files, deleting around 700 includes and adding ~480 gfp.h
   and ~3000 slab.h inclusions.  The script emitted errors for ~400
   files.

2. Each error was manually checked.  Some didn't need the inclusion,
   some needed manual addition while adding it to implementation .h or
   embedding .c file was more appropriate for others.  This step added
   inclusions to around 150 files.

3. The script was run again and the output was compared to the edits
   from #2 to make sure no file was left behind.

4. Several build tests were done and a couple of problems were fixed.
   e.g. lib/decompress_*.c used malloc/free() wrappers around slab
   APIs requiring slab.h to be added manually.

5. The script was run on all .h files but without automatically
   editing them as sprinkling gfp.h and slab.h inclusions around .h
   files could easily lead to inclusion dependency hell.  Most gfp.h
   inclusion directives were ignored as stuff from gfp.h was usually
   wildly available and often used in preprocessor macros.  Each
   slab.h inclusion directive was examined and added manually as
   necessary.

6. percpu.h was updated not to include slab.h.

7. Build test were done on the following configurations and failures
   were fixed.  CONFIG_GCOV_KERNEL was turned off for all tests (as my
   distributed build env didn't work with gcov compiles) and a few
   more options had to be turned off depending on archs to make things
   build (like ipr on powerpc/64 which failed due to missing writeq).

   * x86 and x86_64 UP and SMP allmodconfig and a custom test config.
   * powerpc and powerpc64 SMP allmodconfig
   * sparc and sparc64 SMP allmodconfig
   * ia64 SMP allmodconfig
   * s390 SMP allmodconfig
   * alpha SMP allmodconfig
   * um on x86_64 SMP allmodconfig

8. percpu.h modifications were reverted so that it could be applied as
   a separate patch and serve as bisection point.

Given the fact that I had only a couple of failures from tests on step
6, I'm fairly confident about the coverage of this conversion patch.
If there is a breakage, it's likely to be something in one of the arch
headers which should be easily discoverable easily on most builds of
the specific arch.
Signed-off-by: NTejun Heo <tj@kernel.org>
Guess-its-ok-by: NChristoph Lameter <cl@linux-foundation.org>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>

The vmwgfx driver has a per master rw lock around TTM, to guarantee 
mutual exclusion when needed.

This is typically when all evictable buffers are evicted due to

1) vt switch
2) master switch
3) suspend / resume.

In the multi-master case, on master switch the new master takes the 
previously active master lock in write mode, and then evicts all 
buffers. Any clients to previous masters will then block on that lock 
when trying to validate a buffer. fbdev also acts as a virtual master
wrt this.
Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: NJakob Bornecrantz <jakob@vmware.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

This patch adds a new flag to the drmWaitVblank ioctl, which asks the drm
to return immediately and notify userspace when the specified vblank sequence
happens by sending an event back on the drm fd.

The event mechanism works with the other flags supported by the ioctls,
specifically, the vblank sequence can be specified relatively or absolutely,
and works for primary and seconday crtc.

The signal field of the vblank request is used to provide user data,
which will be sent back to user space in the vblank event.
Signed-off-by: NKristian Høgsberg <krh@redhat.com>
Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NDave Airlie <airlied@redhat.com>