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

drm: drm_gem, check kzalloc retval

2009-07-15T05:56:12+00:00

Check kzalloc retval against NULL in drm_gem_object_alloc and bail out
appropriately.

While at it merge the fail paths and jump to them by gotos at the end
of the function.

Signed-off-by: Jiri Slaby 
Signed-off-by: Dave Airlie

drm: Remove memory debugging infrastructure.

2009-06-18T20:00:33+00:00

It hasn't been used in ages, and having the user tell your how much
memory is being freed at free time is a recipe for disaster even if it
was ever used.

Signed-off-by: Eric Anholt

drm: simplify kcalloc() call to kzalloc().

2009-06-11T06:10:30+00:00

Calls to kcalloc() for a single element can be simplified to calls to
kzalloc().

Signed-off-by: Robert P. J. Day 
Cc: Dave Airlie 
Cc: Eric Anholt 
Signed-off-by: Andrew Morton 
Signed-off-by: Dave Airlie

drm: Use pgprot_writecombine in GEM GTT mapping to get the right bits for !PAT.

2009-04-02T21:28:32+00:00

Otherwise, the PAGE_CACHE_WC would end up getting us a UC-only mapping, and
the write performance of GTT maps dropped 10x.

Signed-off-by: Jesse Barnes 
[anholt: cleaned up unused var]
Signed-off-by: Eric Anholt

drm: Split drm_map and drm_local_map

2009-03-13T04:23:56+00:00

Once upon a time, the DRM made the distinction between the drm_map
data structure exchanged with user space and the drm_local_map used
in the kernel.

For some reasons, while the BSD port still has that "feature", the
linux part abused drm_map for kernel internal usage as the local
map only existed as a typedef of the struct drm_map.

This patch fixes it by declaring struct drm_local_map separately
(though its content is currently identical to the userspace variant),
and changing the kernel code to only use that, except when it's a
user<->kernel interface (ie. ioctl).

This allows subsequent changes to the in-kernel format

I've also replaced the use of drm_local_map_t with struct drm_local_map
in a couple of places. Mostly by accident but they are the same (the
former is a typedef of the later) and I have some remote plans and
half finished patch to completely kill the drm_local_map_t typedef
so I left those bits in.

Signed-off-by: Benjamin Herrenschmidt 
Acked-by: Eric Anholt 
Signed-off-by: Dave Airlie

drm/i915: Keep refs on the object over the lifetime of vmas for GTT mmap.

2009-02-20T02:21:13+00:00

This fixes potential fault at fault time if the object was unreferenced
while the mapping still existed.  Now, while the mmap_offset only lives
for the lifetime of the object, the object also stays alive while a vma
exists that needs it.

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

drm: Do not leak a new reference for flink() on an existing name

2009-02-20T02:21:10+00:00

The name table should only hold a single reference, so avoid leaking
additional references for secondary calls to flink().

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

drm: Free the object ref on error.

2009-02-20T02:21:08+00:00

Ensure that the object is unreferenced if we fail to allocate during
drm_gem_flink_ioctl().

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

drm: Potential use-after-free on error path.

2009-02-20T02:21:08+00:00

Remove the member from the hash table before we free the structure!

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

Stop playing silly games with the VM_ACCOUNT flag

2009-01-31T23:08:56+00:00

The mmap_region() code would temporarily set the VM_ACCOUNT flag for
anonymous shared mappings just to inform shmem_zero_setup() that it
should enable accounting for the resulting shm object.  It would then
clear the flag after calling ->mmap (for the /dev/zero case) or doing
shmem_zero_setup() (for the MAP_ANON case).

This just resulted in vma merge issues, but also made for just
unnecessary confusion.  Use the already-existing VM_NORESERVE flag for
this instead, and let shmem_{zero|file}_setup() just figure it out from
that.

This also happens to make it obvious that the new DRI2 GEM layer uses a
non-reserving backing store for its object allocation - which is quite
possibly not intentional.  But since I didn't want to change semantics
in this patch, I left it alone, and just updated the caller to use the
new flag semantics.

Signed-off-by: Linus Torvalds