rtc: alarm: Proper handling of spinlock

In alarm_shutdown hook, taking interruptible mutex
lock in interrupt disabled context. This patch fixes
alarm_shutdown function to call rtc_read_time and
rtc_set_alarm APIs in interrupt enabled context.

Change-Id: I9392d8908c19365993dccc22504f4b6f83ae8f72
CRs-Fixed: 619657
Signed-off-by: Mohit Aggarwal <maggarwa@codeaurora.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: I222bbf55856d5849da813b730de0636c80966c8e
CRs-Fixed: 608832
Signed-off-by: Laura Abbott <lauraa@codeaurora.org>
msm: kgsl: Treat 0x0 as valid GPU pagetable physical address

Iommu driver could be allocating a valid GPU pagetable at
physical address 0x0, remove assumption from GPU kernel driver
that 0x0 is invalid pagetable address.

Change-Id: I213c0fbc1d90a13bef83c7d7589ad9e5729771fd
Signed-off-by: Tarun Karra <tkarra@codeaurora.org>
msm: mpm-of: fix for "cxo_lpm_clk is unbalanced" slowpath warning.

The variable xo_enabled needs protection. It might get called
simultaneously from suspend and mpm worker thread context.
Added a mutex to prevent this.

WARNING: at kernel/arch/arm/mach-msm/clock.c:411 clk_disable+0xc8/0x150()
cxo_lpm_clk is unbalanced
Modules linked in: adsprpc texfat(PO) mwlan_aarp(PO)
[<c010d24c>] (unwind_backtrace+0x0/0x138) from [<c01a0408>]
(warn_slowpath_common+0x4c/0x64)
[<c01a0408>] (warn_slowpath_common+0x4c/0x64) from [<c01a04b4>]
(warn_slowpath_fmt+0x30/0x40)
[<c01a04b4>] (warn_slowpath_fmt+0x30/0x40) from [<c011a068>]
(clk_disable+0xc8/0x150)
[<c011a068>] (clk_disable+0xc8/0x150) from [<c0180568>]
(msm_mpm_sys_low_power_modes+0x28/0x84)
[<c0180568>] (msm_mpm_sys_low_power_modes+0x28/0x84) from [<c0180768>]
(msm_mpm_work_fn+0x1c/0x5c)
[<c0180768>] (msm_mpm_work_fn+0x1c/0x5c) from [<c01b9568>]
(process_one_work+0x128/0x490)
[<c01b9568>] (process_one_work+0x128/0x490) from [<c01b9c14>]
(worker_thread+0x164/0x35c)
[<c01b9c14>] (worker_thread+0x164/0x35c) from [<c01be9a8>]
(kthread+0x88/0x94)
[<c01be9a8>] (kthread+0x88/0x94) from [<c0107a04>]
(kernel_thread_exit+0x0/0x8)
---[ end trace d18a7d72e45b272f ]---
------------[ cut here ]------------
WARNING: at kernel/arch/arm/mach-msm/clock.c:436 clk_unprepare+0xac/0xd4()
cxo_lpm_clk is unbalanced (prepare)
Modules linked in: adsprpc texfat(PO) mwlan_aarp(PO)
[<c010d24c>] (unwind_backtrace+0x0/0x138) from [<c01a0408>]
(warn_slowpath_common+0x4c/0x64)
[<c01a0408>] (warn_slowpath_common+0x4c/0x64) from [<c01a04b4>]
(warn_slowpath_fmt+0x30/0x40)
[<c01a04b4>] (warn_slowpath_fmt+0x30/0x40) from [<c011aa78>]
(clk_unprepare+0xac/0xd4)
[<c011aa78>] (clk_unprepare+0xac/0xd4) from [<c0180570>]
(msm_mpm_sys_low_power_modes+0x30/0x84)
[<c0180570>] (msm_mpm_sys_low_power_modes+0x30/0x84) from [<c0180768>]
(msm_mpm_work_fn+0x1c/0x5c)
[<c0180768>] (msm_mpm_work_fn+0x1c/0x5c) from [<c01b9568>]
(process_one_work+0x128/0x490)
[<c01b9568>] (process_one_work+0x128/0x490) from [<c01b9c14>]
(worker_thread+0x164/0x35c)
[<c01b9c14>] (worker_thread+0x164/0x35c) from [<c01be9a8>]
(kthread+0x88/0x94)
[<c01be9a8>] (kthread+0x88/0x94) from [<c0107a04>]
(kernel_thread_exit+0x0/0x8)
---[ end trace d18a7d72e45b2730 ]---

CRs-fixed: 596765
Change-Id: Ibe685e8f37eb63c4e9e9d3434719985f33c63376
Signed-off-by: Anil kumar mamidala <amami@codeaurora.org>
mm: vmscan: If kswapd has been running too long, allow it to sleep

Under constant allocation pressure, kswapd can be in the situation where
sleeping_prematurely() will always return true even if kswapd has been
running a long time. Check if kswapd needs to be scheduled.

Signed-off-by: Mel Gorman <mgorman@suse.de>
mm: slub: Default slub_max_order to 0

To avoid locking and per-cpu overhead, SLUB optimisically uses
high-order allocations up to order-3 by default and falls back to
lower allocations if they fail. While care is taken that the caller
and kswapd take no unusual steps in response to this, there are
further consequences like shrinkers who have to free more objects to
release any memory. There is anecdotal evidence that significant time
is being spent looping in shrinkers with insufficient progress being
made (https://lkml.org/lkml/2011/4/28/361) and keeping kswapd awake.

SLUB is now the default allocator and some bug reports have been
pinned down to SLUB using high orders during operations like
copying large amounts of data. SLUBs use of high-orders benefits
applications that are sized to memory appropriately but this does not
necessarily apply to large file servers or desktops.  This patch
causes SLUB to use order-0 pages like SLAB does by default.
There is further evidence that this keeps kswapd's usage lower
(https://lkml.org/lkml/2011/5/10/383).

Signed-off-by: Mel Gorman <mgorman@suse.de>
msm: kgsl: Use high priority workqueue