Backport: PR_{GET,SET}_NO_NEW_PRIVS to prevent execve from granting privs

Original message:

Add PR_{GET,SET}_NO_NEW_PRIVS to prevent execve from granting privs

With this set, a lot of dangerous operations (chroot, unshare, etc)
become a lot less dangerous because there is no possibility of
subverting privileged binaries.

This patch completely breaks apparmor.  Someone who understands (and
uses) apparmor should fix it or at least give me a hint.

Signed-off-by: Andy Lutomirski <luto@amacapital.net>

Change-Id: I370e8cc0fd6046c0b733c35447698e4e4531454f
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: I8f11fb7f0391954435002e7f290352f311c907d4
(cherry picked from commit 40eeed8767d7fba76e45bc462165cb4962472658)
Merge changes I8f11fb7f,I370e8cc0 into cm-11.0

* changes:
  mm: remove compressed copy from zram in-memory
  Backport: PR_{GET,SET}_NO_NEW_PRIVS to prevent execve from granting privs
general: restore README

taken from marvel-2.6.35-crc.tar.gz

Change-Id: I4ee4030c4d95f43e0fe7e8e53e675eafcaf84d19
Merge "general: restore README" into cm-11.0
general: restore README

taken from marvel-2.6.35-crc.tar.gz

Change-Id: I4ee4030c4d95f43e0fe7e8e53e675eafcaf84d19
Merge commit '2dd3188bee18c09a12897882a7b71560d6bdd15e' into cm-11.0
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.

Change-Id: I765a42be8e964bfd3e2886d1ca85a29d60c3bb3e
Signed-off-by: Rik van Riel<riel@redhat.com>
Signed-off-by: Colin Cross <ccross@android.com>
(cherry picked from commit 6c3749439c710c18514cb6b4c629d3f3bac6ddd2)
This is a combination of 36 commits.

ARM: zImage: don't hard code the stack size twice

Acked-by: Eric Miao <eric.miao@canonical.com>
Acked-by: Nicolas Pitre <nicolas.pitre@linaro.org>
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
(cherry picked from commit bd6e732de8cf2510ac4389feb7269009eee5ee9a)

ARM: zImage: some comments for __armv3_mpu_cache_on

__armv3_mpu_cache_on seems broken.  As there is noone around who knows
about these machines just keep the code as is but point out the strange
things.

Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
(cherry picked from commit d8430e24332704fad02240120b116bc5d2c4346e)

ARM: zImage: __armv3_mpu_cache_flush: respect should-be-zero specification

Probably the register content for cache operations is "don't care" in
practice, but as r1 is explicitly zeroed, use that one.

Acked-by: Eric Miao <eric.miao@canonical.com>
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>

ARM: zImage: annotate debug functions about corrupted registers

Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>

ARM: remove bit-rotten STANDALONE_DEBUG for decompressor

I tried to get this running to debug the regression introduced by
e7db7b4 without success.  But this has several problems that make it
hard to fix:

  - lib/decompress_inflate.c includes in-kernel headers that make
    it difficult to compile for user space.
  - the binary formats changed both in kernel and user space and
    at least for the kernel side there isn't only a single
    variant.

Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Acked-by: Nicolas Pitre <nicolas.pitre@linaro.org>

ARM: zImage: don't define unused symbol initrd_phys

The only user of initrd_phys is arch/arm/boot/bootp/init.S which still
gets the value passed to.

Acked-by: Eric Miao <eric.miao@canonical.com>
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>

ARM: Remove unused PARAMS_PHYS from arch/arm/boot/compressed

The only reference in arch/arm/boot/compressed to PARAMS_PHYS is
params() in head.S, which can be directly converted to the exact
address as specified by arch/arm/mach-rpc/Makefile.boot.

Signed-off-by: Eric Miao <eric.miao@canonical.com>
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>

ARM: Auto calculate ZRELADDR and provide option for exceptions

As long as the zImage is placed within the 128MB range from the start of
memory, ZRELADDR (Address where the decompressed kernel will be placed,
usually == PHYS_OFFSET + TEXT_OFFSET) can be determined at run-time by
masking PC with 0xf80000000.

Running through all the Makefile.boot, all those zreladdr-y
addresses == 0x[0-f][08]00_0000 + TEXT_OFFSET can be determined at
run-time.

Option CONFIG_AUTO_ZRELADDR and CONFIG_ZRELADDR are introduced,
CONFIG_ZRELADDR _must_ be explicitly specified if:

- ((zreladdr-y - TEXT_OFFSET) & ~0xf8000000) != 0, which means
  masking PC with 0xf8000000 will result in an incorrect address.
  Currently this is only a problem on u300.

- or the assumption of the zImage being loaded by the bootloader within
  the first 128MB of RAM is incorrect

- or when ZBOOT_ROM is used, where the above assumption is usually wrong.

[ukleinek: changed mask from 0xf0000000 to 0xf8000000 for mx1 and shark
+ some review fixes from the mailing list]

Original-Idea-and-Signed-off-by: Nicolas Pitre <nicolas.pitre@linaro.org>
Signed-off-by: Eric Miao <eric.miao@canonical.com>
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>

ARM: 6286/1: fix Thumb-2 decompressor broken by "Auto calculate ZRELADDR"

"ARM: Auto calculate ZRELADDR and provide option for exceptions" broke
the Thumb-2 decompressor because it removed an entry in the LC0 table
but didn't adjust the offset the Thumb-2 code uses to load the SP from
that table.

Fix it, and also change the ARM code to use the separate SP-load since
ARM instructions that include the SP in the LDM register list are
deprecated.

Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Rabin Vincent <rabin@rab.in>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

ARM: Fix build error when using KCONFIG_CONFIG

Jonathan Cameron reports that when using the environment
variable KCONFIG_CONFIG, he encounters this error:

make[2]: *** No rule to make target `.config', needed by `arch/arm/boot/compressed/vmlinux.lds'

Reported-by: Jonathan Cameron <jic23@cam.ac.uk>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

ARM: Partially revert "Auto calculate ZRELADDR and provide option for exceptions"

Partially revert e69edc7, which introduced automatic zreladdr
support.  The change in the way the manual definition is defined
seems to be error and conflict prone.  Go back to the original way
we were handling this for the time being, while keeping the automatic
zreladdr facility.

Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

Conflicts:

	arch/arm/Kconfig

ARM: avoid marking decompressor .stack section as having contents

The .stack section doesn't contain any contents, and doesn't require
initialization either.  Rather than marking the output section with
'NOLOAD' but still having it exist in the object files, mark it with
%nobits which avoids the assembler marking the section with 'CONTENTS'.

Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

ARM: 6499/1: Thumb-2: Correct data alignment for CONFIG_THUMB2_KERNEL in bootp/init.S

Directives such as .long and .word do not magically cause the
assembler location counter to become aligned in gas.  As a result,
using these directives in code sections can result in misaligned
data words when building a Thumb-2 kernel (CONFIG_THUMB2_KERNEL).

This is a Bad Thing, since the ABI permits the compiler to assume
that fundamental types of word size or above are word- aligned when
accessing them from C.  If the data is not really word-aligned,
this can cause impaired performance and stray alignment faults in
some circumstances.

In general, the following rules should be applied when using data
word declaration directives inside code sections:

    * .quad and .double:
         .align 3

    * .long, .word, .single, .float:
         .align (or .align 2)

    * .short:
        No explicit alignment required, since Thumb-2
        instructions are always 2 or 4 bytes in size.
        immediately after an instruction.

Reviewed-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Dave Martin <dave.martin@linaro.org>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

ARM: 6502/1: Thumb-2: Fix CONFIG_THUMB2_KERNEL breakage in compressed/head.S

Some instruction operand combinations are used here which are nor
permitted in Thumb-2.

In particular, most uses of pc as an operand are disallowed in
Thumb-2, and deprecated in ARM from ARMv7 onwards.

The modified code introduced by this patch should be compatible
with all architecture versions >= v3, with or without
CONFIG_THUMB2_KERNEL.

Reviewed-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Dave Martin <dave.martin@linaro.org>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Acked-by: Nicolas Pitre <nicolas.pitre@linaro.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

ARM: 6750/1: improvements to compressed/head.S

In the case of a conflict between the memory used by the compressed
kernel with its decompressor code and the memory used for the
decompressed kernel, we currently store the later after the former and
relocate it afterwards.

This would be more efficient to do this the other way around i.e.
relocate the compressed data up front instead, resulting in a smaller
copy.  That also has the advantage of making the code smaller and more
straight forward.

Signed-off-by: Nicolas Pitre <nicolas.pitre@linaro.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

Conflicts:

	arch/arm/boot/compressed/head.S

ARM: 6503/1: Thumb-2: Restore sensible zImage header layout for CONFIG_THUMB2_KERNEL

The code which makes up the zImage header intends to leave a
32-byte gap followed by a branch to the real entry point, a magic
number, and a word containing the absolute entry point address.

This gets messed up with with CONFIG_THUMB2_KERNEL, because the
size of the initial padding NOPs changes.

Instead, the header can be made fully compatible by restoring it to
ARM.

In the Thumb-2 case, we can replace the initial NOPs with a
sequence which switches to Thumb and jumps to the real entry point.

As a consequence, the zImage entry point is now always ARM, so no
special magic is needed any more for the uImage rules in the
Thumb-2 case.

Signed-off-by: Dave Martin <dave.martin@linaro.org>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Acked-by: Nicolas Pitre <nicolas.pitre@linaro.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

ARM: 6739/1: update .gitignore for boot/compressed

Signed-off-by: Nicolas Pitre <nicolas.pitre@linaro.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

Conflicts:
	arch/arm/boot/compressed/.gitignore

Change-Id: I03de4cf2368311d4cbf64f335723beff7b2e812f

ARM: 6746/1: remove the 4x expansion presumption while decompressing the kernel

We currently presume a 4x expansion to guess the decompressed kernel size
in order to determine if the decompressed kernel is in conflict with
the location where zImage is loaded.  This guess may cause many issues
by overestimating the final kernel image size:

- This may force a needless relocation if the location of zImage was
  fine, wasting some precious microseconds of boot time.

- The relocation may be located way too far, possibly overwriting the
  initrd image in RAM.

- If the kernel image includes a large already-compressed initramfs image
  then the problem is even more exacerbated.

And if by some strange means the 4x guess is too low then we may overwrite
ourselves with the decompressed image.

So let's use the exact decompressed kernel image size instead.  For that
we need to rely on the stat command, but this is hardly a new build
dependency as the kernel already depends on many external commands
to be built provided by the coreutils package where stat is found.

Signed-off-by: Nicolas Pitre <nicolas.pitre@linaro.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

ARM: 6778/1: compressed/head.S: make LDFLAGS_vmlinux into a recursively expanded variable

The simply expanded variable may be evaluated before the target file for
the stat command is up to date or even exists.  Switching to a recursively
expanded variable move the execution of the stat command to the location
where LDFLAGS_vmlinux is actually used, fixing the dependency issue
introduced by patch #6746/1.

Signed-off-by: Nicolas Pitre <nicolas.pitre@linaro.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

arm: change to new flag variables

Replace EXTRA_CFLAGS with ccflags-y and EXTRA_AFLAGS with asflags-y.

Signed-off-by: matt mooney <mfm@muteddisk.com>
Acked-by: WANG Cong <xiyou.wangcong@gmail.com>
Signed-off-by: Michal Marek <mmarek@suse.cz>

ARM: zImage: make sure the stack is 64-bit aligned

With ARMv5+ and EABI, the compiler expects a 64-bit aligned stack so
instructions like STRD and LDRD can be used.  Without this, mysterious
boot failures were seen semi randomly with the LZMA decompressor.

While at it, let's align .bss as well.

Signed-off-by: Nicolas Pitre <nicolas.pitre@linaro.org>
Tested-by: Shawn Guo <shawn.guo@linaro.org>
Acked-by: Tony Lindgren <tony@atomide.com>
CC: stable@kernel.org

ARM: zImage: Fix bad SP address after relocating kernel

Otherwise cache_clean_flush can overwrite some of the relocated
area depending on where the kernel image gets loaded. This fixes
booting on n900 after commit 6d7d0ae51574943bf571d269da3243257a2d15db
(ARM: 6750/1: improvements to compressed/head.S).

Thanks to Aaro Koskinen <aaro.koskinen@nokia.com> for debugging
the address of the relocated area that gets corrupted, and to
Nicolas Pitre <nicolas.pitre@linaro.org> for the other uncompress
related fixes.

Signed-off-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Nicolas Pitre <nicolas.pitre@linaro.org>

ARM: zImage: make sure not to relocate on top of the relocation code

If the zImage load address is slightly below the relocation address,
there is a risk for the copied data to overwrite the copy loop or
cache flush code that the relocation process requires.  Always
bump the relocation address by the size of that code to avoid this
issue.

Noticed by Tony Lindgren <tony@atomide.com>.

While at it, let's start the copy from the restart symbol which makes
the above code size computation possible by the assembler directly
(same sections), given that we don't need to preserve the code before
that point anyway. And therefore we don't need to carry the _start
pointer in r5 anymore.

Signed-off-by: Nicolas Pitre <nicolas.pitre@linaro.org>
Tested-by: Tony Lindgren <tony@atomide.com>

ARM: zImage: the page table memory must be considered before relocation

For correctness, the initial page table located right before the
decompressed kernel should be considered when determining if relocation
is required.

Signed-off-by: Nicolas Pitre <nicolas.pitre@linaro.org>
Tested-by: Shawn Guo <shawn.guo@linaro.org>
Acked-by: Tony Lindgren <tony@atomide.com>

ARM: zImage: no need to get the decompressed size from the filesystem

In commit d239b1dc093d the hardcoded 4x estimate for the decompressed
kernel size was replaced by the exact Image file size and passed to
the linker as a symbol value.  Turns out that this is unneeded as the
size is already included at the end of the compressed piggy data.
For those compressed formats that don't include this data, the build
system already takes care of appending it using size_append in
scripts/Makefile.lib.  So let's use that instead.

Signed-off-by: Nicolas Pitre <nicolas.pitre@linaro.org>
Tested-by: Shawn Guo <shawn.guo@linaro.org>
Tested-by: Tony Lindgren <tony@atomide.com>

ARM: zImage: simplify decompress_kernel()

The return value for decompress_kernel() is no longer used.  Furthermore,
this was obtained and stored in a variable called output_ptr which is
a complete misnomer for what is actually the size of the decompressed
kernel image.  Let's get rid of it.

Signed-off-by: Nicolas Pitre <nicolas.pitre@linaro.org>
Tested-by: Shawn Guo <shawn.guo@linaro.org>
Tested-by: Tony Lindgren <tony@atomide.com>

ARM: zImage: don't ignore error returned from decompress()

If decompress() returns an error without calling error(), we must
not attempt to boot the resulting kernel.

Signed-off-by: Nicolas Pitre <nicolas.pitre@linaro.org>
Tested-by: Shawn Guo <shawn.guo@linaro.org>
Tested-by: Tony Lindgren <tony@atomide.com>

ARM: zImage: make sure no GOTOFF relocs are used with .bss symbols

To be able to relocate the .bss section at run time independently from
the rest of the code, we must make sure that no GOTOFF relocations are
used with .bss symbols.  This usually means that no global variables can
be marked static unless they're also const.

To enforce this, suffice to fail the build whenever a private symbol
is allocated to .bss and list those symbols for convenience.

The user_stack and user_stack_end labels in head.S were converted into
non exported symbols to remove false positives.

Signed-off-by: Nicolas Pitre <nicolas.pitre@linaro.org>
Tested-by: Tony Lindgren <tony@atomide.com>

ARM: 6859/1: Add writethrough dcache support for ARM926EJS processor

The ARM kernel supports writethrough data cache via the
CONFIG_CPU_DCACHE_WRITETHROUGH option.  However, that
functionality wasn't implemented in the arch/arm/boot/compressed
code.  It is now necessary due to a new ARM926EJS processor
that has an issue with writeback data cache.

Signed-off-by: Mark A. Greer <mgreer@mvista.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

ARM: 6954/1: zImage: fix Thumb2 breakage

Commit af3e4fd37a "ARM: 6859/1: Add writethrough dcache support for
ARM926EJS processor" broke Thumb2 compilation by omitting to maintain
the wide encoding for the added branch instructions which made the
ARM926EJ-S record smaller than expected, breaking the record walk code.

Signed-off-by: Nicolas Pitre <nicolas.pitre@linaro.org>
Cc: Mark A. Greer <mgreer@mvista.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

ARM: 6961/1: zImage: Add build-time check for correctly-sized proc_type entries

It is easy to mis-maintain the proc_types table such that the
entries become wrongly-sized and misaligned when the kernel is
built in Thumb-2.

This patch adds an assembly-time check which will turn most common
size/alignment mistakes in this table into build failures, to avoid
having to debug the boot-time kernel hang which would happen if the
resulting kernel were actually booted.

Signed-off-by: Dave Martin <dave.martin@linaro.org>
Acked-by: Nicolas Pitre <nicolas.pitre@linaro.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

ARM: decompressor: use better output sections

Place read-only data in a .rodata output section, and the compressed
piggy data in .piggydata.  Place the .got.plt section before the .got
section as is standard ELF practise.

This allows the piggydata to be more easily extracted from the
compressed vmlinux file for verification purposes.

Acked-by: Nicolas Pitre <nicolas.pitre@linaro.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

ARM: 6999/1: head, zImage: Always Enter the kernel in ARM state

Currently, the documented kernel entry requirements are not
explicit about whether the kernel should be entered in ARM or
Thumb, leading to an ambiguitity about how to enter Thumb-2
kernels.  As a result, the kernel is reliant on the zImage
decompressor to enter the kernel proper in the correct instruction
set state.

This patch changes the boot entry protocol for head.S and Image to
be the same as for zImage: in all cases, the kernel is now entered
in ARM.

Documentation/arm/Booting is updated to reflect this new policy.

A different rule will be needed for Cortex-M class CPUs as and when
support for those lands in mainline, since these CPUs don't support
the ARM instruction set at all: a note is added to the effect that
the kernel must be entered in Thumb on such systems.

Signed-off-by: Dave Martin <dave.martin@linaro.org>
Acked-by: Nicolas Pitre <nicolas.pitre@linaro.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

ARM: zImage: ensure it is always a multiple of 64 bits in size

This is needed for proper alignment when the DTB appending feature
is used.

Signed-off-by: Nicolas Pitre <nicolas.pitre@linaro.org>
Acked-by: Tony Lindgren <tony@atomide.com>
Tested-by: Shawn Guo <shawn.guo@linaro.org>
Tested-by: Dave Martin <dave.martin@linaro.org>
Tested-by: Thomas Abraham <thomas.abraham@linaro.org>

ARM: zImage: gather some string functions into string.c

This is a small subset of string functions needed by commits to come.
Except for memcpy() which is unchanged from its original location, their
implementation is meant to be small, and -Os is enforced to prevent gcc
from doing pointless loop unrolling.

Signed-off-by: Nicolas Pitre <nicolas.pitre@linaro.org>
Tested-by: Shawn Guo <shawn.guo@linaro.org>
Tested-by: Dave Martin <dave.martin@linaro.org>
Tested-by: Thomas Abraham <thomas.abraham@linaro.org>

ARM: zImage: prevent constant copy+rebuild of lib1funcs.S

The rule to copy this file doesn't have to be forced.  However
lib1funcs.[So] have to be listed amongst the targets.

This prevents zImage from being recreated needlessly.

Signed-off-by: Nicolas Pitre <nicolas.pitre@linaro.org>
Tested-by: Shawn Guo <shawn.guo@linaro.org>
Tested-by: Dave Martin <dave.martin@linaro.org>
Tested-by: Thomas Abraham <thomas.abraham@linaro.org>
(cherry picked from commit ca58d43565dd10cbf9b8f5e10eceabbd3dbdac57)

Change-Id: If8b27225424766f39fedb67338b5a3bfde20bd42
configs: debranding [1/3]

Change-Id: I74ac7d46869e179e9e330f133fb52ed7738d5314
backport lowmemorykiller from CAF msm-3.4

this improves low memory behaviour greatly due to accounting for
lowmem_reserve as well as shmem pages.

Change-Id: I351dda49be388a98edfe6cc31ae4f2667c77429c
(cherry picked from commit a64a14050e32fa79905903cf76c62be5b360c8eb)
lowmemorykiller: skip already freed memory

Change-Id: I1cb221ff7dad399b3b57817706812561f67c6707
staging: android: lowmemorykiller: implement task's adj rbtree

Based on the current LMK implementation, LMK has to scan all processes to
select the correct task to kill during low memory.
The basic idea for the optimization is to :
queue all tasks with oom_score_adj priority, and then LMK just selects the
proper task from the queue(rbtree) to kill.

performance improvement:
the current implementation: average time to find a task to kill : 1004us
the optimized implementation: average time to find a task to kill: 43us

squished another 3 commits:

staging: android: lowmemorykiller: select a new task to kill
Under certain circumstances, a process may take time to handle a SIGKILL.
When lowmemkiller is called again shortly after, it would pick the same
process to kill over and over, so that we cann't get free memory for long time.

Solution is to check fatal_signal_pending() on the selected task, and if it's
already pending, select a new task to kill.

staging: android: lmk: skip if killed by lmk
A task can be selected to kill when it's already exiting. Sending
signal to the task at that state won't set TIF_SIGPENDING for it.
After that, every task including threads in the exiting task itself
running into lmk will compete for the mutex, then spend some time
waiting for the exiting task to release memory or try to send signal
to the same task again.
We want the exiting task to exit as early as possible but it's slowed
down greatly by the mutex and waiting. Skip lmk if current thread
group leader is exiting and is killed by lmk. Also delegate TIF_MEMDIE
to current task.

staging: android: lmk: check TIF directly
When trying to fix that lmk can't kill an exiting task
(commit 895304e
(CR) staging: android: lmk: skip if killed by lmk),
additional check was added for the TIF_MEMDIE flag.
However the task lock has already been taken when examining
the task. The same helper function which tries to grab the
task lock again will be deadlocked.
Change to check the thread flag of thread group leader directly.

Change-Id: Ibbb99cbd36e27a546195b4d4bed59b3829e6b7b0
configs: disable CONFIG_LOCALVERSION_AUTO

Change-Id: Ia60becc688eb014e31420c9c63fd6610c81867f7