ARM: mm: fix MMU mapping of CMA regions

Fix dma_contiguous_remap() so that it continues through all the
regions, even after encountering one that is outside lowmem.
Without this change, if you have two CMA regions, the first outside
lowmem and the seocnd inside lowmem, only the second one will get
set up in the MMU. Data written to that region then doesn't get
automatically flushed from the cache into memory.

Change-Id: I941c46baa951cb2a2c7aa151779fb48a4a488a74
CRs-Fixed: 467034
Signed-off-by: Chris Brand <cbrand@broadcom.com>
[extended patch subject with 'fix' word]
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Laura Abbott <lauraa@codeaurora.org>
ARM: dma-mapping: add support for CMA regions placed in highmem zone

This patch adds missing pieces to correctly support memory pages served
from CMA regions placed in high memory zones. Please note that the default
global CMA area is still put into lowmem and is limited by optional
architecture specific DMA zone. One can however put device specific CMA
regions in high memory zone to reduce lowmem usage.

Change-Id: I92ae4a772f24e0ca90c5560a826207850618b506
CRs-Fixed: 467034
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
[lauraa@codeaurora.org: Context fixups]
Signed-off-by: Laura Abbott <lauraa@codeaurora.org>
ARM: dma-mapping: Allow highmem pages to not have a mapping

The DMA_ATTR_NO_KERNEL_MAPPING is used to make sure that CMA
pages have no kernel mapping. Add support to make sure that
highmem pages have no mapping.

Change-Id: Ife76df126ecfedf0dba81a35e0de8a1787355b3d
CRs-Fixed: 467034
Signed-off-by: Laura Abbott <lauraa@codeaurora.org>
ARM: 7693/1: mm: clean-up in order to reduce to call kmap_high_get()

In kmap_atomic(), kmap_high_get() is invoked for checking already
mapped area. In __flush_dcache_page() and dma_cache_maint_page(),
we explicitly call kmap_high_get() before kmap_atomic()
when cache_is_vipt(), so kmap_high_get() can be invoked twice.
This is useless operation, so remove one.

v2: change cache_is_vipt() to cache_is_vipt_nonaliasing() in order to
be self-documented

Change-Id: I36e5a63fdae158d9e7562f564f7e593b351f6960
Acked-by: Nicolas Pitre <nico@linaro.org>
Signed-off-by: Joonsoo Kim <iamjoonsoo.kim@lge.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Git-commit: dd0f67f4747797f36f0c6bab7fed6a1f2448476d
Git-repo: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/
Signed-off-by: Chintan Pandya <cpandya@codeaurora.org>
msm: Make CONFIG_STRICT_MEMORY_RWX even stricter

If CONFIG_STRICT_MEMORY_RWX was set, the first section (containing
the kernel page table and the initial code) and the section
containing the init code were both given RWX permission, which is
a potential security hole.

Pad the first section after the initial code (which will never
be executed when the MMU is on) to make the rest of the kernel
text start in the second section and make the first section RW.

Move some data which had ended up in the "init text"
section into the "init data" one, as this is RW, not RX.
Make the "init text" RX.

We will not free the section containing the "init text",
because if we do, the kernel will allocate memory for RW data there.

Change-Id: I6ca5f4e07342c374246f04a3fee18042fd47c33b
CRs-fixed: 513919
Signed-off-by: Larry Bassel <lbassel@codeaurora.org>
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>
mm: cma: remove watermark hacks

Commits 2139cbe627b8 ("cma: fix counting of isolated pages") and
d95ea5d18e69 ("cma: fix watermark checking") introduced a reliable
method of free page accounting when memory is being allocated from CMA
regions, so the workaround introduced earlier by commit 49f223a9cd96
("mm: trigger page reclaim in alloc_contig_range() to stabilise
watermarks") can be finally removed.

Change-Id: Iae17de8185eeabffd46752dbaf819591e6585869
CRs-Fixed: 480377
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Cc: Kyungmin Park <kyungmin.park@samsung.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Mel Gorman <mel@csn.ul.ie>
Acked-by: Michal Nazarewicz <mina86@mina86.com>
Cc: Minchan Kim <minchan@kernel.org>
Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Git-commit: bc357f431c836c6631751e3ef7dfe7882394ad67
Git-repo: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
[lauraa@codeaurora.org: Context fixup in mmzone.h, keep zone definition in
alloc_contig_range for other purposes]
Signed-off-by: Laura Abbott <lauraa@codeaurora.org>
mm: cma: fix accounting of CMA pages placed in high memory

The total number of low memory pages is determined as totalram_pages -
totalhigh_pages, so without this patch all CMA pageblocks placed in
highmem were accounted to low memory.

Change-Id: I10b78fa6a710828520a487b2fc2419b4f7521a6f
CRs-Fixed: 480377
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Acked-by: Kyungmin Park <kyungmin.park@samsung.com>
Cc: Minchan Kim <minchan.kim@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Git-repo: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
Git-commit: 41a7973447b0b8717f0a214d4328dc31ec2291d7
Signed-off-by: Laura Abbott <lauraa@codeaurora.org>
mm: Don't use CMA page for file cache

Despite the best efforts of redirection, the file system may still
allocate CMA pages with references held for long periods of time.
If a CMA page ends up being allocated, free it and get a non-CMA page.

Change-Id: I2001151a2936a6d0780d223dda85a87c04ddb8c6
Signed-off-by: Laura Abbott <lauraa@codeaurora.org>
mm/page_alloc.c: fix watermark check in __zone_watermark_ok()

The watermark check consists of two sub-checks.  The first one is:

	if (free_pages <= min + lowmem_reserve)
		return false;

The check assures that there is minimal amount of RAM in the zone.  If
CMA is used then the free_pages is reduced by the number of free pages
in CMA prior to the over-mentioned check.

	if (!(alloc_flags & ALLOC_CMA))
		free_pages -= zone_page_state(z, NR_FREE_CMA_PAGES);

This prevents the zone from being drained from pages available for
non-movable allocations.

The second check prevents the zone from getting too fragmented.

	for (o = 0; o < order; o++) {
		free_pages -= z->free_area[o].nr_free << o;
		min >>= 1;
		if (free_pages <= min)
			return false;
	}

The field z->free_area[o].nr_free is equal to the number of free pages
including free CMA pages.  Therefore the CMA pages are subtracted twice.
This may cause a false positive fail of __zone_watermark_ok() if the CMA
area gets strongly fragmented.  In such a case there are many 0-order
free pages located in CMA.  Those pages are subtracted twice therefore
they will quickly drain free_pages during the check against
fragmentation.  The test fails even though there are many free non-cma
pages in the zone.

This patch fixes this issue by subtracting CMA pages only for a purpose of
(free_pages <= min + lowmem_reserve) check.

Laura said:

  We were observing allocation failures of higher order pages (order 5 =
  128K typically) under tight memory conditions resulting in driver
  failure.  The output from the page allocation failure showed plenty of
  free pages of the appropriate order/type/zone and mostly CMA pages in
  the lower orders.

  For full disclosure, we still observed some page allocation failures
  even after applying the patch but the number was drastically reduced and
  those failures were attributed to fragmentation/other system issues.

Change-Id: Ic2c0c233993c41c630e24d71df5e12aa614588e5
CRs-Fixed:549847
Signed-off-by: Tomasz Stanislawski <t.stanislaws@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Tested-by: Laura Abbott <lauraa@codeaurora.org>
Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Acked-by: Minchan Kim <minchan@kernel.org>
Cc: Mel Gorman <mel@csn.ul.ie>
Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>
Cc: <stable@vger.kernel.org>	[3.7+]
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Git-commit: 026b08147923142e925a7d0aaa39038055ae0156
Git-repo: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git
Signed-off-by: Srinivasarao P <spathi@codeaurora.org>
swap: add per-partition lock for swapfile

swap_lock is heavily contended when I test swap to 3 fast SSD (even
slightly slower than swap to 2 such SSD).  The main contention comes
from swap_info_get().  This patch tries to fix the gap with adding a new
per-partition lock.

Global data like nr_swapfiles, total_swap_pages, least_priority and
swap_list are still protected by swap_lock.

nr_swap_pages is an atomic now, it can be changed without swap_lock.  In
theory, it's possible get_swap_page() finds no swap pages but actually
there are free swap pages.  But sounds not a big problem.

Accessing partition specific data (like scan_swap_map and so on) is only
protected by swap_info_struct.lock.

Changing swap_info_struct.flags need hold swap_lock and
swap_info_struct.lock, because scan_scan_map() will check it.  read the
flags is ok with either the locks hold.

If both swap_lock and swap_info_struct.lock must be hold, we always hold
the former first to avoid deadlock.

swap_entry_free() can change swap_list.  To delete that code, we add a
new highest_priority_index.  Whenever get_swap_page() is called, we
check it.  If it's valid, we use it.

It's a pity get_swap_page() still holds swap_lock().  But in practice,
swap_lock() isn't heavily contended in my test with this patch (or I can
say there are other much more heavier bottlenecks like TLB flush).  And
BTW, looks get_swap_page() doesn't really need the lock.  We never free
swap_info[] and we check SWAP_WRITEOK flag.  The only risk without the
lock is we could swapout to some low priority swap, but we can quickly
recover after several rounds of swap, so sounds not a big deal to me.
But I'd prefer to fix this if it's a real problem.

"swap: make each swap partition have one address_space" improved the
swapout speed from 1.7G/s to 2G/s.  This patch further improves the
speed to 2.3G/s, so around 15% improvement.  It's a multi-process test,
so TLB flush isn't the biggest bottleneck before the patches.

CRs-Fixed: 573027
Change-Id: Ic8d600653479c0e6767f04462c3f057b0fe94332
[arnd@arndb.de: fix it for nommu]
[hughd@google.com: add missing unlock]
[minchan@kernel.org: get rid of lockdep whinge on sys_swapon]
Signed-off-by: Shaohua Li <shli@fusionio.com>
Cc: Hugh Dickins <hughd@google.com>
Cc: Rik van Riel <riel@redhat.com>
Cc: Minchan Kim <minchan.kim@gmail.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Seth Jennings <sjenning@linux.vnet.ibm.com>
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: Xiao Guangrong <xiaoguangrong@linux.vnet.ibm.com>
Cc: Dan Magenheimer <dan.magenheimer@oracle.com>
Cc: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Hugh Dickins <hughd@google.com>
Signed-off-by: Minchan Kim <minchan@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Git-commit: ec8acf20afb8534ed511f6613dd2226b9e301010
Git-repo: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
[lauraa@codeaurora.org: Various context fixups due to backport]
Signed-off-by: Laura Abbott <lauraa@codeaurora.org>
Signed-off-by: Swetha Chikkaboraiah <schikk@codeaurora.org>
mm: vmscan: fix do_try_to_free_pages() livelock

This patch is based on KOSAKI's work and I add a little more description,
please refer https://lkml.org/lkml/2012/6/14/74.

Currently, I found system can enter a state that there are lots of free
pages in a zone but only order-0 and order-1 pages which means the zone is
heavily fragmented, then high order allocation could make direct reclaim
path's long stall(ex, 60 seconds) especially in no swap and no compaciton
enviroment.  This problem happened on v3.4, but it seems issue still lives
in current tree, the reason is do_try_to_free_pages enter live lock:

kswapd will go to sleep if the zones have been fully scanned and are still
not balanced.  As kswapd thinks there's little point trying all over again
to avoid infinite loop.  Instead it changes order from high-order to
0-order because kswapd think order-0 is the most important.  Look at
73ce02e9 in detail.  If watermarks are ok, kswapd will go back to sleep
and may leave zone->all_unreclaimable =3D 0.  It assume high-order users
can still perform direct reclaim if they wish.

Direct reclaim continue to reclaim for a high order which is not a
COSTLY_ORDER without oom-killer until kswapd turn on
zone->all_unreclaimble= .  This is because to avoid too early oom-kill.
So it means direct_reclaim depends on kswapd to break this loop.

In worst case, direct-reclaim may continue to page reclaim forever when
kswapd sleeps forever until someone like watchdog detect and finally kill
the process.  As described in:
http://thread.gmane.org/gmane.linux.kernel.mm/103737

We can't turn on zone->all_unreclaimable from direct reclaim path because
direct reclaim path don't take any lock and this way is racy.  Thus this
patch removes zone->all_unreclaimable field completely and recalculates
zone reclaimable state every time.

Note: we can't take the idea that direct-reclaim see zone->pages_scanned
directly and kswapd continue to use zone->all_unreclaimable.  Because, it
is racy.  commit 929bea7c71 (vmscan: all_unreclaimable() use
zone->all_unreclaimable as a name) describes the detail.

CRs-fixed: 573027
Change-Id: I49970a0fa751cf33af293fd1ee784e36422785b1
[akpm@linux-foundation.org: uninline zone_reclaimable_pages() and zone_reclaimable()]
Cc: Aaditya Kumar <aaditya.kumar.30@gmail.com>
Cc: Ying Han <yinghan@google.com>
Cc: Nick Piggin <npiggin@gmail.com>
Acked-by: Rik van Riel <riel@redhat.com>
Cc: Mel Gorman <mel@csn.ul.ie>
Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Cc: Christoph Lameter <cl@linux.com>
Cc: Bob Liu <lliubbo@gmail.com>
Cc: Neil Zhang <zhangwm@marvell.com>
Cc: Russell King - ARM Linux <linux@arm.linux.org.uk>
Reviewed-by: Michal Hocko <mhocko@suse.cz>
Acked-by: Minchan Kim <minchan@kernel.org>
Acked-by: Johannes Weiner <hannes@cmpxchg.org>
Signed-off-by: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Signed-off-by: Lisa Du <cldu@marvell.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Git-repo: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
Git-commit: 6e543d5780e36ff5ee56c44d7e2e30db3457a7ed
[lauraa@codeaurora.org: Some context fixups and variable name changes due
to backporting. Dropped parts that don't apply to older kernels]
Signed-off-by: Laura Abbott <lauraa@codeaurora.org>
Signed-off-by: Swetha Chikkaboraiah <schikk@codeaurora.org>
gpu: ion: Free the sgtable for CMA based heaps

When an sgtable is allocated with sg_alloc_table, the table needs
to be destroyed in addition to being freed. Destroy the sgtable
when freeing the associated memory.

Change-Id: Iedba81146ba453070790f071848f86826f7eec9c
Signed-off-by: Laura Abbott <lauraa@codeaurora.org>
Signed-off-by: Srinivasarao P <spathi@codeaurora.org>
gpu: ion: enable the kmalloc heap

There are some Ion clients who would like to use the kmalloc
heap. Enable it.

Change-Id: Ie818be9e1211d52d489ad2cb63d94e2fddfc0f01
Signed-off-by: Mitchel Humpherys <mitchelh@codeaurora.org>
gpu: ion: Use correct type for variables

Use correct type for variables to prevent overflow of signed
type when assiging from an unsigned type.

Change-Id: I0055d35c7310d111de590db3798950fd98f1b298
Signed-off-by: Olav Haugan <ohaugan@codeaurora.org>
gpu: ion: Do fallback when allocating large sizes

The preferred allocation of memory for kernel data structures in
ION is to use kmalloc. This is mainly for performance reasons. However,
we are not guaranteed to be able to allocate large sizes. So to keep
the code performing well and at the same time allow for larger allocations,
implement a fallback mechanism for allocation of memory for ION kernel data
structures.

CRs-Fixed: 488521
Change-Id: I8c6a13ad74cce69f590920d28c01a58f7a540fd2
Signed-off-by: Olav Haugan <ohaugan@codeaurora.org>
[Resolved merge conflict]
Signed-off-by: Chintan Pandya <cpandya@codeaurora.org>

Signed-off-by: Sridhar Gujje <sgujje@codeaurora.org>
msm: msm_bus: Fix the 64-bit division during interleaving

When interleaving flag is enabled, the bandwidth is divided
between ports. There was an error in the division as the
macro was not correctly updated with the right order of using
bandwidth and port number when 64-bit division function
was used by the bus driver.
Correcting this for fixing the token allocation issues
observed.

CRs-Fixed: 472791
Change-Id: Ie7c7f9557006cbb946eaa9eff4b50771cc60525e
Signed-off-by: Gagan Mac <gmac@codeaurora.org>
Revert "Display: fix blue screen issue (underrun)"

This reverts commit 456b8170a03b7403eaddf321241644f9de2ea95c.
msm_fb: display: add mdp master port1 bandwidth request

mdp bus traffic go through both mdp port0 and port1, but now mdp
bandwidth request is only for port0.

Change-Id: Ie902de6362cd9225abf6e9c42f260b5af7c3c6f8
Signed-off-by: Huaibin Yang <huaibiny@codeaurora.org>