linux.git/drivers/gpu/drm/drm_gem.c, branch v2.6.37

Merge remote branch 'korg/drm-fixes' into drm-vmware-next

2010-10-06T01:10:48+00:00

necessary for some of the vmware fixes to be pushed in.

Conflicts:
	drivers/gpu/drm/drm_gem.c
	drivers/gpu/drm/i915/intel_fb.c
	include/drm/drmP.h

drm: Move the GTT accounting to i915

2010-10-01T13:45:20+00:00

Only drm/i915 does the bookkeeping that makes the information useful,
and the information maintained is driver specific, so move it out of the
core and into its single user.

Signed-off-by: Chris Wilson 
Cc: Dave Airlie

drm: Hold the mutex when dropping the last GEM reference (v2)

2010-10-01T11:08:45+00:00

In order to be fully threadsafe we need to check that the drm_gem_object
refcount is still 0 after acquiring the mutex in order to call the free
function. Otherwise, we may encounter scenarios like:

Thread A:                                        Thread B:
drm_gem_close
unreference_unlocked
kref_put                                         mutex_lock
...                                              i915_gem_evict
...                                              kref_get -> BUG
...                                              i915_gem_unbind
...                                              kref_put
...                                              i915_gem_object_free
...                                              mutex_unlock
mutex_lock
i915_gem_object_free -> BUG
i915_gem_object_unbind
kfree
mutex_unlock

Note that no driver is currently using the free_unlocked vfunc and it is
scheduled for removal, hasten that process.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=30454
Reported-and-Tested-by: Magnus Kessler 
Signed-off-by: Chris Wilson 
Cc: stable@kernel.org
Signed-off-by: Dave Airlie

drm/gem: handlecount isn't really a kref so don't make it one.

2010-09-30T23:17:44+00:00

There were lots of places being inconsistent since handle count
looked like a kref but it really wasn't.

Fix this my just making handle count an atomic on the object,
and have it increase the normal object kref.

Now i915/radeon/nouveau drivers can drop the normal reference on
userspace object creation, and have the handle hold it.

This patch fixes a memory leak or corruption on unload, because
the driver had no way of knowing if a handle had been actually
added for this object, and the fbcon object needed to know this
to clean itself up properly.

Reviewed-by: Chris Wilson 
Signed-off-by: Dave Airlie

drm: Prune GEM vma entries

2010-09-27T23:14:34+00:00

Hook the GEM vm open/close ops into the generic drm vm open/close so
that the private vma entries are created and destroy appropriately.
Fixes the leak of the drm_vma_entries during the lifetime of the filp.

Reported-by: Matt Mackall 
Cc: Jesse Barnes 
Signed-off-by: Chris Wilson 
Acked-by: Jesse Barnes 
Cc: stable@kernel.org
Signed-off-by: Dave Airlie

drm: kill gem_free_object_unlocked driver callback

2010-08-29T23:38:18+00:00

Not used by any current driver.

Signed-off-by: Daniel Vetter 
Signed-off-by: Dave Airlie

drm: Use ENOENT consistently for the error return for an unmatched handle.

2010-08-10T00:46:55+00:00

This is consistent with trying to access a filename that not exist
within a directory which is a good analogy here. The main reason for the
change is that it is easy to confuse the error code of EBADF as an
performing an ioctl on an invalid file descriptor (rather than an
unknown object).

Signed-off-by: Chris Wilson 
Signed-off-by: Dave Airlie

drm: Free the idr layers before calling idr_destroy()

2010-08-02T00:13:56+00:00

/* A typical clean-up sequence for objects stored in an idr tree, will
 * use idr_for_each() to free all objects, if necessary, then
 * idr_remove_all() to remove all ids, and idr_destroy() to free
 * up the cached idr_layers.
 */

We were missing the vital idr_rmove_all() step and so were leaking
the used layers for every dri client:

unreferenced object 0xf32133c0 (size 148):
  comm "plymouthd", pid 131, jiffies 4294678490 (age 2308.030s)
  hex dump (first 32 bytes):
    04 00 00 00 00 00 00 00 00 00 00 00 00 40 19 f3  .............@..
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
  backtrace:
    [] create_object+0x124/0x1f1
    [] kmemleak_alloc+0x4c/0x90
    [] kmem_cache_alloc+0xee/0x13c
    [] idr_pre_get+0x24/0x61
    [] drm_gem_handle_create+0x27/0x7f [drm]
    [] i915_gem_create_ioctl+0x4f/0x71 [i915]
    [] drm_ioctl+0x272/0x356 [drm]
    [] vfs_ioctl+0x33/0x91
    [] do_vfs_ioctl+0x46b/0x496
    [] sys_ioctl+0x46/0x66
    [] sysenter_do_call+0x12/0x38
    [] 0xffffffff

Fixes https://bugzilla.kernel.org/show_bug.cgi?id=15803

Signed-off-by: Chris Wilson 
Signed-off-by: Dave Airlie

drm: Make sure the DRM offset matches the CPU

2010-06-01T00:07:57+00:00

The pgoff option in mmap() is defined as an unsigned long
so the offset generated by DRM needs to fit into
BITS_PER_LONG for the CPU in question.

Signed-off-by: Jordan Crouse 
Signed-off-by: Dave Airlie

drm: free core gem object from driver callbacks

2010-04-20T03:19:33+00:00

When drivers embed the core gem object into their own structures,
they'll have to do this. Temporarily this results in an ugly

kfree(gem_obj);

in every gem driver.

Signed-off-by: Daniel Vetter 
Acked-by: Eric Anholt 
Signed-off-by: Dave Airlie