lowmemorykiller: Force system aggressive shrinking

HACK: In very low memory have the lowmemorykiller
put a lot of pressure onto the  other shrinkers to
force them to return more memory to the system.

Change-Id: I4bf34bf086fc6144ced65844f2cb5ca53d724191
Signed-off-by: Liam Mark <lmark@codeaurora.org>
lowmemorykiller: Protect drop_slab1 function from recursive calls

kswapd task seemed to be in a recuresive loop of
lowmem_shrink and shrink_slab thereby corrupting
its own stack. Protect drop_slab1 function with
lock to ensure that code is mutually exclusive
and prevent recursive calls.

CRs-fixed: 601692
Change-Id: I238668fa22976c047fce8347c13848c43b5cbf55
Signed-off-by: Susheel Khiani <skhiani@codeaurora.org>
android/lowmemorykiller: Account for total_swapcache_pages

The lowmemorykiller relies on NR_FILE_PAGES when measureing
the amount of reclaimable memory in the system.
However when swap is enabled swap cache pages are counted
in NR_FILE_PAGES, and swap cache pages aren't as reclaimable
in low memory as file cache pages. Therefore a large swap
cache can result in the lowmemorykiller not running and
an OOM occuring.

In order to ensure the lowmemorykiller properly evaluates the
amount of reclaimable memory don't count the swap cache pages.

Change-Id: I38239283e572f814b277c718eaf6be7f92abacbb
Signed-off-by: Liam Mark <lmark@codeaurora.org>
Revert "ashmem: avoid deadlock between read and mmap calls"

This reverts commit 8e0ab3090ed07c6bbb539c26ffbad8099dbe3a64.
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>