Upgrade ashmem to kk_3.5_rb1.21 from drivers/staging/android (4 commits)

drivers: staging: android: Fix ashmem vm range comparison to stop roll-over

Every time ASHMEM_CACHE_INV_RANGE was sent to an IOCTL a roll-over was
occurring, causing the check to fail. This was comparing a start + size
range with a start + end range, and if the start + end was less than the
start + size the ioctl would fail. The end value was always equal to
start + size from all tests I ran, and since the roll-over occurred with
start + end, it was always less than start. Setting the check to compare
start + size > end fixes this.

Change-Id: I3e4356ab40d8c745fd91eb0cc6b1aaed73494140
Signed-off-by: Matthew Trusten <mtrusten@codeaurora.org>

staging: android: ashmem: get_name,set_name not to hold ashmem_mutex

Problem:
There exists a path in ashmem driver that could lead to acquistion
of mm->mmap_sem, ashmem_mutex in reverse order. This could lead
to deadlock in the system.
For Example, assume that mmap is called on a ashmem region
in the context of a thread say T1.
 sys_mmap_pgoff (1. acquires mm->mmap_sem)
  |
   --> mmap_region
 	|
         ----> ashmem_mmap (2. acquires asmem_mutex)
 Now if there is a context switch after 1 and before 2,
 and if another thread T2 (that shares the mm struct) invokes an
 ioctl say ASHMEM_GET_NAME, this can lead to the following path

ashmem_ioctl
  |
  -->get_name (3. acquires ashmem_mutex)
	|
	---> copy_to_user (4. acquires the mm->mmap_sem)
Note that the copy_to_user could lead to a valid fault if no
physical page is allocated yet for the user address passed.
Now T1 has mmap_sem and is waiting for ashmem_mutex.
and T2 has the ashmem_mutex and is waiting for mmap_sem
Thus leading to deadlock.

Solution:
Do not call copy_to_user or copy_from_user while holding the
ahsmem_mutex. Instead copy this to a local buffer that lives
in the stack while holding this lock. This will maintain data
integrity as well never reverse the lock order.

Testing:
Created a unit test case to reproduce the problem.
Used the same to test this fix on kernel version 3.4.0
Ported the same patch to 3.8

Change-Id: Ib66f6265da91691acfd3be9ea8f5c9332c978751
CRs-Fixed: 600362
Signed-off-by: Shankar Brahadeeswaran <shankoo77@gmail.com>
Reviewed-by: Dan Carpenter <dan.carpenter@oracle.com>
Acked-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Git-commit: e5834d620d61d01444c41958f1816d688a96433c
Git-repo: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
Signed-off-by: Laura Abbott <lauraa@codeaurora.org>

ashmem: avoid deadlock between read and mmap calls

Avoid holding ashmem_mutex across code that can page fault.  Page faults
grab the mmap_sem for the process, which are also held by mmap calls
prior to calling ashmem_mmap, which locks ashmem_mutex.  The reversed
order of locking between the two can deadlock.

The calls that can page fault are read() and the ASHMEM_SET_NAME and
ASHMEM_GET_NAME ioctls.  Move the code that accesses userspace pages
outside the ashmem_mutex.

Bug: 9261835
Change-Id: If1322e981d29c889a56cdc9dfcbc6df2729a45e9
CRs-Fixed: 600362
Signed-off-by: Todd Poynor <toddpoynor@google.com>
Git-repo: https://android.googlesource.com/kernel/common/
Git-commit: 0a9dea28170c90a7265250b66cc0df1253b0c501
Signed-off-by: Laura Abbott <lauraa@codeaurora.org>

staging: ashmem: Fix the build failure when OUTER_CACHE is enabled

ashmem driver is failing to build when OUTER_CACHE is enabled
through the CACHE_L2X0 option. Fix it with appropriate new
offset routines.

Change-Id: I298f9bb32899f20e17407b5210d0859d6308c035
Signed-off-by: Trilok Soni <tsoni@codeaurora.org>