Squashed update of kernel from 3.4.86 to 3.4.87
ARM: fix executability of CMA mappings

The CMA region was being marked executable:

0xdc04e000-0xdc050000           8K     RW x      MEM/CACHED/WBRA
0xdc060000-0xdc100000         640K     RW x      MEM/CACHED/WBRA
0xdc4f5000-0xdc500000          44K     RW x      MEM/CACHED/WBRA
0xdcce9000-0xe0000000       52316K     RW x      MEM/CACHED/WBRA

This is mainly due to the badly worded MT_MEMORY_DMA_READY symbol, but
there are also a few other places in dma-mapping which should be
corrected to use the right constant.  Fix all these places:

0xdc04e000-0xdc050000           8K     RW NX     MEM/CACHED/WBRA
0xdc060000-0xdc100000         640K     RW NX     MEM/CACHED/WBRA
0xdc280000-0xdc300000         512K     RW NX     MEM/CACHED/WBRA
0xdc6fc000-0xe0000000       58384K     RW NX     MEM/CACHED/WBRA

Change-Id: I044360a8f08b1a4ae3e3e9e623fb77af2b427c51
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Git-commit: 71b55663c5d0a6f8473045db1c8b376803780191
Git-repo: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
[lauraa@codeaurora.org: Context fixups due to __dma_remap signature change]
Signed-off-by: Laura Abbott <lauraa@codeaurora.org>
ARM: dma-mapping: don't allow DMA mappings to be marked executable

DMA mapping permissions were being derived from pgprot_kernel directly
without using PAGE_KERNEL.  This causes them to be marked with executable
permission, which is not what we want.  Fix this.

Change-Id: Ib40f59f3c569f82409943cf8f9a86a9869d922cc
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Git-commit: 0ea1ec713f04bdfac343c9702b21cd3a7c711826
Git-repo: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
[lauraa@codeaurora.org: dropped functions not in older builds]
Signed-off-by: Laura Abbott <lauraa@codeaurora.org>
msm: display: clear sec_active when the pipe is not for secure

Make sure secure memory is unmapped properly

Change-Id: Ie0f2bc586ab4de45ceaaa6834db64ba7b94b2c0b
Signed-off-by: Ken Zhang <kenz@codeaurora.org>
Signed-off-by: c_hharis <hharis@codeaurora.org>
Signed-off-by: Nirmal Abraham <nabrah@codeaurora.org>
lib/scatterlist: error handling in __sg_alloc_table()

I was reviewing code which I suspected might allocate a zero size SG
table.  That will cause memory corruption.  Also we can't return before
doing the memset or we could end up using uninitialized memory in the
cleanup path.

Change-Id: Icee6be8ea22644d7f16264d9d2a0887c7145996b
CRs-Fixed: 611562
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Cc: Akinobu Mita <akinobu.mita@gmail.com>
Cc: Imre Deak <imre.deak@intel.com>
Cc: Tejun Heo <tj@kernel.org>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Maxim Levitsky <maximlevitsky@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Squashed update of kernel from 3.4.87 to 3.4.88
CHROMIUM: mm: Fix calculation of dirtyable memory

The system uses global_dirtyable_memory() to calculate
number of dirtyable pages/pages that can be allocated
to the page cache.  A bug causes an underflow thus making
the page count look like a big unsigned number.  This in turn
confuses the dirty writeback throttling to aggressively write
back pages as they become dirty (usually 1 page at a time).

Fix is to ensure there is no underflow while doing the math.

Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Signed-off-by: Puneet Kumar <puneetster@chromium.org>

BUG=chrome-os-partner:16011
TEST=Manual; boot kernel, powerwash, login with testaccount and
make sure no jank occurs on sync of applications

Change-Id: I614e7c3156e014f0f28a4ef9bdd8cb8a2cd07b2a
Reviewed-on: https://gerrit.chromium.org/gerrit/37612
Reviewed-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Olof Johansson <olofj@chromium.org>
Commit-Ready: Puneet Kumar <puneetster@chromium.org>
Reviewed-by: Puneet Kumar <puneetster@chromium.org>
Tested-by: Puneet Kumar <puneetster@chromium.org>
staging: android: ashmem: Avoid deadlock with mmap/shrink

Both ashmem_mmap and ashmem_shrink take the ashmem_lock. It may
be possible for ashmem_mmap to invoke ashmem_shrink:

-000|mutex_lock(lock = 0x0)
-001|ashmem_shrink(?, sc = 0x0) <--- try to take ashmem_mutex again
-002|shrink_slab(shrink = 0xDA5F1CC0, nr_pages_scanned = 0, lru_pages
-002|=
-002|124)
-003|try_to_free_pages(zonelist = 0x0, ?, ?, ?)
-004|__alloc_pages_nodemask(gfp_mask = 21200, order = 1, zonelist =
-004|0xC11D0940,
-005|new_slab(s = 0xE4841E80, ?, node = -1)
-006|__slab_alloc.isra.43.constprop.50(s = 0xE4841E80, gfpflags =
-006|2148925462, ad
-007|kmem_cache_alloc(s = 0xE4841E80, gfpflags = 208)
-008|shmem_alloc_inode(?)
-009|alloc_inode(sb = 0xE480E800)
-010|new_inode_pseudo(?)
-011|new_inode(?)
-012|shmem_get_inode(sb = 0xE480E800, dir = 0x0, ?, dev = 0, flags =
-012|187)
-013|shmem_file_setup(?, ?, flags = 187)
-014|ashmem_mmap(?, vma = 0xC5D64210) <---- Acquire ashmem_mutex
-015|mmap_region(file = 0xDF8E2C00, addr = 1772974080, len = 233472,
-015|flags = 57,
-016|sys_mmap_pgoff(addr = 0, len = 230400, prot = 3, flags = 1, fd =
-016|157, pgoff
-017|ret_fast_syscall(asm)
-->|exception
-018|NUR:0x40097508(asm)
---|end of frame

Avoid this deadlock by using mutex_trylock in ashmem_shrink; if the mutex
is already held, do not attempt to shrink.

Change-Id: I26933f4cc7f5668cb6713e56acb9f895257ddc6b
CRs-Fixed: 608832
Signed-off-by: Laura Abbott <lauraa@codeaurora.org>
nf: IDLETIMER: time-stamp and suspend/resume handling.

Message notifications contains an additional timestamp field in nano seconds.
The expiry time for the timers are modified during suspend/resume.
If timer was supposed to expire while the system is suspended then a
notification is sent when it resumes with the timestamp of the scheduled expiry.

Removes the race condition for multiple work scheduled.

Bug: 13247811

Change-Id: I752c5b00225fe7085482819f975cc0eb5af89bff
Signed-off-by: Ruchi Kandoi <kandoiruchi@google.com>
ARM: mm: remove IPI broadcasting on ASID rollover

ASIDs are allocated to MMU contexts based on a rolling counter. This
means that after 255 allocations we must invalidate all existing ASIDs
via an expensive IPI mechanism to synchronise all of the online CPUs and
ensure that all tasks execute with an ASID from the new generation.

This patch changes the rollover behaviour so that we rely instead on the
hardware broadcasting of the TLB invalidation to avoid the IPI calls.
This works by keeping track of the active ASID on each core, which is
then reserved in the case of a rollover so that currently scheduled
tasks can continue to run. For cores without hardware TLB broadcasting,
we keep track of pending flushes in a cpumask, so cores can flush their
local TLB before scheduling a new mm.

CRs-Fixed: 623919

Change-Id: I2ed0f2ab6635bf900bcb81e29efbd01991da8e86
Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
Tested-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Git-commit: b5466f8728527a05a493cc4abe9e6f034a1bbaab
Git-repo: https://android.googlesource.com/kernel/common/
[spathi@codeaurora.org: removed unused function set_asid().
The function cpu_set_reserved_ttbr0() is not available since patch
"ARM: Use TTBR1 instead of reserved context ID" is not merged
so used old functionlity by calling cpu_set_asid(0)]
Signed-off-by: Srinivasarao P <spathi@codeaurora.org>
nf: Remove compilation error caused by
e254d2c28c880da28626af6d53b7add5f7d6afee

Signed-off-by: Ruchi Kandoi <kandoiruchi@google.com>
net: ipv4: current group_info should be put after using.

Plug a group_info refcount leak in ping_init.
group_info is only needed during initialization and
the code failed to release the reference on exit.
While here move grabbing the reference to a place
where it is actually needed.

Signed-off-by: Chuansheng Liu <chuansheng.liu@intel.com>
Signed-off-by: Zhang Dongxing <dongxing.zhang@intel.com>
Signed-off-by: xiaoming wang <xiaoming.wang@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

Conflicts:
	net/ipv4/ping.c

Change-Id: I51931e439cce7f19b4179f5828d7355bb3b1dcfa
genalloc: Correct nbytes calculation on long boundary

In existing code we calculate nbytes based on the byte
boundary, but genalloc uses bitmap for maintaining the
memory allocation aligned to long. So while calculating
nbytes we end up getting wrong nbytes.
example: lets say nbytes comes to 9 bytes for 70 bits when
bytes aligned,but if long aligned we will have 3 long words
i.e 12 bytes. This difference may lead to choosing the
wrong api for freeing the memory i.e Between kfree() and
vfree().
Fix was inspired by an upstream commit
eedce141cd2dad8d0cefc5468ef41898949a7031, bringing same fix
into the gen_pool_detroy path.

Change-Id: I942caf59e25515c780896b328b912604df9e10bf
Signed-off-by: Hareesh Gundu <hareeshg@codeaurora.org>
Signed-off-by: Sunil Khatri <sunilkh@codeaurora.org>
Squashed update of kernel from 3.4.88 to 3.4.89
diag: Remove error message

Some diag messages are marked as error messages which should
be marked as debug. This patch fixes that issue.

Change-Id: If24b6cfdfca40321ff403826d8c149e8a3032803
Signed-off-by: Katish Paran <kparan@codeaurora.org>
block: bfq: Squashed update from BFQ-v7r2 to BFQ-v7r3

Change-Id: Id0ef3399d83bf4fd407eff64e695a7a3ec059646