update new kgsl driver from CAF, Work in progress
pmem: respect PMEM_DEBUG config
msm: kgsl: Make sure kmemleak tool does not report incorrect mem leak.

Certain memory allocations are not properly tracked by kmemleak tool,
which makes it to incorrectly detect memory leak. Notify the tool by using
kmemleak_not_leak() to ignore the memory allocation so that incorrect leaks
report are avoided.

CRs-Fixed: 334294
Signed-off-by: Anshuman Dani <adani@codeaurora.org>
(cherry picked from commit eecd52061a50325db02d2396bfd455b306a04f34)

Change-Id: If2c955f95c650a73a04aca01977dc7ac13319878
Signed-off-by: Ram Kumar Chakravarthy Chebathini <rcheba@codeaurora.org>
msm: kgsl: Do not BUG in GPU recovery if a valid context can't be found

Don't BUG() if we can't find a valid context to recover to; just fail and
go into a zombie state. This usually happens after a first hang goes bad
and the system keeps hanging while trying to find its way. The problem with
a BUG() in this case is that the system goes down and we can't recover the
snapshot or other debug information.

Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org>
(cherry picked from commit a400d8da2d5464a47b3fe19b96a3bb04af82114e)

Change-Id: I68581017f6e78a866a6d91033f980ecd06d96360
Signed-off-by: Gopal G Goberu <ggober@codeaurora.org>
base: genlock: Use a signed long for the result from wait_timeout
arm: Allow saving of stacktraces from other processes

Currently, a process is only able to save its own stacktrace
due to concerns about other processes going away while the
saving is occuring. Realistaically though, hititng this
case is very unlikely and the debugging benefit outweighs
the risk. Enable saving of other stacktraces for access
through systems such as procfs.

Change-Id: I584388f6edb48431bfec8d11d217f0fdc116f73e
Signed-off-by: Laura Abbott <lauraa@codeaurora.org>
USB: f_mtp: Remove existing duplicate code

autoconfig of out endpoint is being done twice for mtp driver.
Hence, removing the duplicate code of autoconfig of out endpoint.

CRs-Fixed: 339985
Change-Id: I677462999d0bcc1387aafe4c068e09fda5df15f6
Signed-off-by: Chiranjeevi Velempati <cvelempa@codeaurora.org>
(cherry picked from commit 5e27b7675695c82b8fd61565950863567e5c0628)
ASoC: core: Fix the suspend/resume failure

The suspend/resume schedule work fails because of the
uninsantiated sound card. The fix is to skip the
schedule work for the uninsantiated sound card.

CRs-fixed: 339411
Signed-off-by: Kuirong Wang <kuirongw@codeaurora.org>
(cherry picked from commit 5ab054fb0655bb0ab6820a18e931fabf69053ea9)

Change-Id: Icf303ffef9d7019c936510dc676ba83eeec84f1c
Signed-off-by: Zhoulu Luo <zluo@codeaurora.org>
mm: Avoid livelocking of WB_SYNC_ALL writeback (bananacakes)
ksm: amend struct anon_vma
ksm: fix bad user data when swapping

Building under memory pressure, with KSM on 2.6.36-rc5, collapsed with
an internal compiler error: typically indicating an error in swapping.

Perhaps there's a timing issue which makes it now more likely, perhaps
it's just a long time since I tried for so long: this bug goes back to
KSM swapping in 2.6.33.

Notice how reuse_swap_page() allows an exclusive page to be reused, but
only does SetPageDirty if it can delete it from swap cache right then -
if it's currently under Writeback, it has to be left in cache and we
don't SetPageDirty, but the page can be reused.  Fine, the dirty bit
will get set in the pte; but notice how zap_pte_range() does not bother
to transfer pte_dirty to page_dirty when unmapping a PageAnon.

If KSM chooses to share such a page, it will look like a clean copy of
swapcache, and not be written out to swap when its memory is needed;
then stale data read back from swap when it's needed again.

We could fix this in reuse_swap_page() (or even refuse to reuse a
page under writeback), but it's more honest to fix my oversight in
KSM's write_protect_page().  Several days of testing on three machines
confirms that this fixes the issue they showed.

Signed-off-by: Hugh Dickins <hughd@google.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Andrea Arcangeli <aarcange@redhat.com>
Cc: stable@kernel.org
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
ksm: annotate ksm_thread_mutex is no deadlock source

commit 62b61f611e ("ksm: memory hotremove migration only") caused the
following new lockdep warning.

  =======================================================
  [ INFO: possible circular locking dependency detected ]
  -------------------------------------------------------
  bash/1621 is trying to acquire lock:
   ((memory_chain).rwsem){.+.+.+}, at: [<ffffffff81079339>]
  __blocking_notifier_call_chain+0x69/0xc0

  but task is already holding lock:
   (ksm_thread_mutex){+.+.+.}, at: [<ffffffff8113a3aa>]
  ksm_memory_callback+0x3a/0xc0

  which lock already depends on the new lock.

  the existing dependency chain (in reverse order) is:

  -> #1 (ksm_thread_mutex){+.+.+.}:
       [<ffffffff8108b70a>] lock_acquire+0xaa/0x140
       [<ffffffff81505d74>] __mutex_lock_common+0x44/0x3f0
       [<ffffffff81506228>] mutex_lock_nested+0x48/0x60
       [<ffffffff8113a3aa>] ksm_memory_callback+0x3a/0xc0
       [<ffffffff8150c21c>] notifier_call_chain+0x8c/0xe0
       [<ffffffff8107934e>] __blocking_notifier_call_chain+0x7e/0xc0
       [<ffffffff810793a6>] blocking_notifier_call_chain+0x16/0x20
       [<ffffffff813afbfb>] memory_notify+0x1b/0x20
       [<ffffffff81141b7c>] remove_memory+0x1cc/0x5f0
       [<ffffffff813af53d>] memory_block_change_state+0xfd/0x1a0
       [<ffffffff813afd62>] store_mem_state+0xe2/0xf0
       [<ffffffff813a0bb0>] sysdev_store+0x20/0x30
       [<ffffffff811bc116>] sysfs_write_file+0xe6/0x170
       [<ffffffff8114f398>] vfs_write+0xc8/0x190
       [<ffffffff8114fc14>] sys_write+0x54/0x90
       [<ffffffff810028b2>] system_call_fastpath+0x16/0x1b

  -> #0 ((memory_chain).rwsem){.+.+.+}:
       [<ffffffff8108b5ba>] __lock_acquire+0x155a/0x1600
       [<ffffffff8108b70a>] lock_acquire+0xaa/0x140
       [<ffffffff81506601>] down_read+0x51/0xa0
       [<ffffffff81079339>] __blocking_notifier_call_chain+0x69/0xc0
       [<ffffffff810793a6>] blocking_notifier_call_chain+0x16/0x20
       [<ffffffff813afbfb>] memory_notify+0x1b/0x20
       [<ffffffff81141f1e>] remove_memory+0x56e/0x5f0
       [<ffffffff813af53d>] memory_block_change_state+0xfd/0x1a0
       [<ffffffff813afd62>] store_mem_state+0xe2/0xf0
       [<ffffffff813a0bb0>] sysdev_store+0x20/0x30
       [<ffffffff811bc116>] sysfs_write_file+0xe6/0x170
       [<ffffffff8114f398>] vfs_write+0xc8/0x190
       [<ffffffff8114fc14>] sys_write+0x54/0x90
       [<ffffffff810028b2>] system_call_fastpath+0x16/0x1b

But it's a false positive.  Both memory_chain.rwsem and ksm_thread_mutex
have an outer lock (mem_hotplug_mutex).  So they cannot deadlock.

Thus, This patch annotate ksm_thread_mutex is not deadlock source.

[akpm@linux-foundation.org: update comment, from Hugh]
Signed-off-by: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Acked-by: Hugh Dickins <hughd@google.com>
Cc: Andrea Arcangeli <aarcange@redhat.com>
Cc: Andi Kleen <andi@firstfloor.org>
Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
thp: ksm: free swap when swapcache page is replaced

When a swapcache page is replaced by a ksm page, it's best to free that
swap immediately.

Reported-by: Andrea Arcangeli <aarcange@redhat.com>
Signed-off-by: Hugh Dickins <hughd@google.com>
Signed-off-by: Andrea Arcangeli <aarcange@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
ksm: drain pagevecs to lru

It was hard to explain the page counts which were causing new LTP tests
of KSM to fail: we need to drain the per-cpu pagevecs to LRU occasionally.

Signed-off-by: Hugh Dickins <hughd@google.com>
Reported-by: CAI Qian <caiqian@redhat.com>
Cc:Andrea Arcangeli <aarcange@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>