]> git.baikalelectronics.ru Git - kernel.git/commit
Stop playing silly games with the VM_ACCOUNT flag
authorLinus Torvalds <torvalds@linux-foundation.org>
Sat, 31 Jan 2009 23:08:56 +0000 (15:08 -0800)
committerLinus Torvalds <torvalds@linux-foundation.org>
Sat, 31 Jan 2009 23:08:56 +0000 (15:08 -0800)
commit8d2cb8c1d72319cf1f00cb793d5c0e4c740282a0
tree755f4c4a1cc30567fde4e60c9cc5e6a889c360b0
parent0b5dfea864c00c2f33b54b92ec3eebdfbe69249f
Stop playing silly games with the VM_ACCOUNT flag

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 <torvalds@linux-foundation.org>
drivers/gpu/drm/drm_gem.c
ipc/shm.c
mm/mmap.c
mm/shmem.c