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.

Orig-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

Orig-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
Orig-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.

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

Change-Id: I922e287d4ebb44b088e5ffe36d7b42b1430b54be
add extra free kbytes tunable

Add a userspace visible knob to tell the VM to keep an extra amount
of memory free, by increasing the gap between each zone's min and
low watermarks.

This is useful for realtime applications that call system
calls and have a bound on the number of allocations that happen
in any short time period.  In this application, extra_free_kbytes
would be left at an amount equal to or larger than than the
maximum number of allocations that happen in any burst.

It may also be useful to reduce the memory use of virtual
machines (temporarily?), in a way that does not cause memory
fragmentation like ballooning does.

[ccross]
Revived for use on old kernels where no other solution exists.
The tunable will be removed on kernels that do better at avoiding
direct reclaim.

Orig-Change-Id: I765a42be8e964bfd3e2886d1ca85a29d60c3bb3e
Signed-off-by: Rik van Riel<riel@redhat.com>
Signed-off-by: Colin Cross <ccross@android.com>

Change-Id: I16f4faa93deba66713d4188c73c325ebcb5ad9f0
lzo: This is a combination of 5 commits.

lib/lzo: Rename lzo1x_decompress.c to lzo1x_decompress_safe.c

Rename the source file to match the function name and thereby
also make room for a possible future even slightly faster
"non-safe" decompressor version.

Orig-Change-Id: I482ee415d43c5aaa77d34946ae1fa0af5465b007
Signed-off-by: Markus F.X.J. Oberhumer <markus@oberhumer.com>

lib/lzo: Update LZO compression to current upstream version

This commit updates the kernel LZO code to the current upsteam version
which features a significant speed improvement - benchmarking the Calgary
and Silesia test corpora typically shows a doubled performance in
both compression and decompression on modern i386/x86_64/powerpc machines.

Orig-Change-Id: Ifcde45460c856644097bdeb612f0d68c6429f03c
Signed-off-by: Markus F.X.J. Oberhumer <markus@oberhumer.com>

lib/lzo: huge LZO decompression speedup on ARM by using unaligned access

Orig-Change-Id: I4dc172b2822504c3f2db1913ed9404e031861d55
Signed-off-by: Markus F.X.J. Oberhumer <markus@oberhumer.com>

ARM: kconfig: select HAVE_EFFICIENT_UNALIGNED_ACCESS for CPUv6+ && MMU

Modern ARM CPUs can perform efficient unaligned memory accesses in
hardware and this feature is relied up on by code such as the dcache
word-at-a-time name hashing.

[pawitp: adapt to kernel 3.0]

Orig-Change-Id: I41559fc9255229e2601f4bef28aa8d48246156b7
Signed-off-by: Will Deacon <will.deacon@arm.com>

mm: remove compressed copy from zram in-memory

Swap subsystem does lazy swap slot free with expecting the page would be
swapped out again so we can avoid unnecessary write.

But the problem in in-memory swap(ex, zram) is that it consumes memory
space until vm_swap_full(ie, used half of all of swap device) condition
meet.  It could be bad if we use multiple swap device, small in-memory
swap and big storage swap or in-memory swap alone.

This patch makes swap subsystem free swap slot as soon as swap-read is
completed and make the swapcache page dirty so the page should be
written out the swap device to reclaim it.  It means we never lose it.

I tested this patch with kernel compile workload.

1. before

   compile time : 9882.42
   zram max wasted space by fragmentation: 13471881 byte
   memory space consumed by zram: 174227456 byte
   the number of slot free notify: 206684

2. after

   compile time : 9653.90
   zram max wasted space by fragmentation: 11805932 byte
   memory space consumed by zram: 154001408 byte
   the number of slot free notify: 426972

[akpm@linux-foundation.org: tweak comment text]
[artem.savkov@gmail.com: fix BUG due to non-swapcache pages in end_swap_bio_read()]
[akpm@linux-foundation.org: invert unlikely() test, augment comment, 80-col cleanup]
Signed-off-by: Dan Magenheimer <dan.magenheimer@oracle.com>
Signed-off-by: Minchan Kim <minchan@kernel.org>
Signed-off-by: Artem Savkov <artem.savkov@gmail.com>
Cc: Hugh Dickins <hughd@google.com>
Cc: Seth Jennings <sjenning@linux.vnet.ibm.com>
Cc: Nitin Gupta <ngupta@vflare.org>
Cc: Konrad Rzeszutek Wilk <konrad@darnok.org>
Cc: Shaohua Li <shli@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

Conflicts:
	mm/page_io.c

Change-Id: Iccb6adc92a9fc668e967dce05080f709b4895c02