linux.git/include/drm/drmP.h, branch v2.6.36

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: block userspace under allocating buffer and having drivers overwrite it (v2)

2010-08-17T04:52:25+00:00

With the current screwed but its ABI, ioctls for the drm, Linus pointed out that we could allow userspace to specify the allocation size, but we pass it to the driver which then uses it blindly to store a struct. Now if userspace specifies the allocation size as smaller than the driver needs, the driver can possibly overwrite memory.

This patch restructures the driver ioctls so we store the structure size we are expecting, and make sure we allocate at least that size. The copy from/to userspace are still restricted to the size the user specifies, this allows ioctl structs to grow on both sides of the equation.

Up until now we didn't really use the DRM_IOCTL defines in the kernel, so this cleans them up and adds them for nouveau.

v2:
fix nouveau pushbuf arg (thanks to Ben for pointing it out)

Reported-by: Linus Torvalds 
Signed-off-by: Dave Airlie

drm: Fix support for PCI domains

2010-08-09T22:20:20+00:00

(For some reason I thought that went in ages ago ...)

This fixes support for PCI domains in what should hopefully be a backward
compatible way along with a change to libdrm.

When the interface version is set to 1.4, we assume userspace understands
domains and the world is at peace. We thus pass proper domain numbers
instead of 0 to userspace.

The newer libdrm will then try 1.4 first, and fallback to 1.1, along with
ignoring domains in the later case (well, except on alpha of course)

Signed-off-by: Benjamin Herrenschmidt 
Signed-off-by: Dave Airlie

drm: kill BKL from common code

2010-08-05T01:54:40+00:00

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: Arnd Bergmann 
Cc: David Airlie 
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Dave Airlie

drm: move ttm global code to core drm

2010-08-03T23:46:06+00:00

I wrote this for the prime sharing work, but I also noticed other external
non-upstream drivers from a large company carrying a similiar patch, so I
may as well ship it in master.

Signed-off-by: Dave Airlie

Merge branch 'drm-tracepoints' into drm-testing

2010-07-07T08:38:44+00:00

drm: add per-event vblank event trace points

2010-07-02T04:03:24+00:00

Allows us to track each process that requests and completes events.

Signed-off-by: Jesse Barnes 
Signed-off-by: Dave Airlie

drm: Add support for platform devices to register as DRM devices

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

Allow platform devices without PCI resources to be DRM devices.

[airlied: fixup warnings with dev pointers]

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