Staging: android: binder: Don't call dump_stack in binder_vma_open

If user-space partially unmaps the driver, binder_vma_open
would dump the kernel stack. This is not a kernel bug however
and will be treated as if the whole area was unmapped once
binder_vma_close gets called.

Signed-off-by: Arve HjÃ¸nnevÃ¥g <arve@android.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Staging: android: binder: Fix crashes when sharing a binder file between processes

Opening the binder driver and sharing the file returned with
other processes (e.g. by calling fork) can crash the kernel.
Prevent these crashes with the following changes:
- Add a mutex to protect against two processes mmapping the
  same binder_proc.
- After locking mmap_sem, check that the vma we want to access
  (still) points to the same mm_struct.
- Use proc->tsk instead of current to get the files struct since
  this is where we get the rlimit from.

Signed-off-by: Arve HjÃ¸nnevÃ¥g <arve@android.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Staging:android: Change type for binder_debug_no_lock switch to bool

GCC warns that module_param_named() indirectly returns a bool type value
which is different from 'int' type binder_debug_no_lock declared. Change
it to bool because it is a internal switch for debugging.

Signed-off-by: Zhengwang Ruan <ruan.zhengwang@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Staging: android: binder: Fix use-after-free bug

binder_update_page_range could read freed memory if the vma of the
selected process was freed right before the check that the vma
belongs to the mm struct it just locked.

If the vm_mm pointer in that freed vma struct had also been rewritten
with a value that matched the locked mm struct, then the code would
proceed and possibly modify the freed vma.

Signed-off-by: Arve HjÃ¸nnevÃ¥g <arve@android.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
drivers: staging: android: binder.c: fix printk macros

Change printk() messages to pr_* macros.

Signed-off-by: Sherwin Soltani <sherwin@wybc.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Staging: android: binder: Fix memory leak on thread/process exit

commit 675d66b0ed5fd170d6a44cf8dbb3fa56a5347bdb upstream.

If a thread or process exited while a reply, one-way transaction or
death notification was pending, the struct holding the pending work
was leaked.

Signed-off-by: Arve HjÃ¸nnevÃ¥g <arve@android.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Staging: android: binder: Allow using highmem for binder buffers

commit 585650dcec88e704a19bb226a34b6a7166111623 upstream.

The default kernel mapping for the pages allocated for the binder
buffers is never used. Set the __GFP_HIGHMEM flag when allocating
these pages so we don't needlessly use low memory pages that may
be required elsewhere.

Signed-off-by: Arve HjÃ¸nnevÃ¥g <arve@android.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
lowmemorykiller: kanged from upstream 3.6.6

staging: android: lowmemorykiller: Don't wait more than one second for a process to die

If a process forked and the child process was killed by the
lowmemorykiller, the lowmemory killer would be disabled until
the parent process reaped the child or it died itself.

Signed-off-by: Arve Hjønnevåg <arve@android.com>
Signed-off-by: Anton Vorontsov <anton.vorontsov@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

staging: android/lowmemorykiller: Don't grab tasklist_lock

Grabbing tasklist_lock has its disadvantages, i.e. it blocks
process creation and destruction. If there are lots of processes,
blocking doesn't sound as a great idea.

For LMK, it is sufficient to surround tasks list traverse with
rcu_read_{,un}lock().

>From now on using force_sig() is not safe, as it can race with an
already exiting task, so we use send_sig() now. As a downside, it
won't kill PID namespace init processes, but that's not what we
want anyway.

Suggested-by: Oleg Nesterov <oleg@redhat.com>
Signed-off-by: Anton Vorontsov <anton.vorontsov@linaro.org>
Reviewed-by: Oleg Nesterov <oleg@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

staging: android/lowmemorykiller: Better mm handling

LMK should not directly check for task->mm. The reason is that the
process' threads may exit or detach its mm via use_mm(), but other
threads may still have a valid mm. To catch this we use
find_lock_task_mm(), which walks up all threads and returns an
appropriate task (with lock held).

Suggested-by: Oleg Nesterov <oleg@redhat.com>
Reviewed-by: Oleg Nesterov <oleg@redhat.com>
Signed-off-by: Anton Vorontsov <anton.vorontsov@linaro.org>
Acked-by: KOSAKI Motohiro <kosaki.motohiro@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

staging: android/lowmemorykiller: No need for task->signal check

task->signal == NULL is not possible, so no need for these checks.

Suggested-by: Oleg Nesterov <oleg@redhat.com>
Reviewed-by: Oleg Nesterov <oleg@redhat.com>
Signed-off-by: Anton Vorontsov <anton.vorontsov@linaro.org>
Acked-by: KOSAKI Motohiro <kosaki.motohiro@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

staging: android/lowmemorykiller: Do not kill kernel threads

LMK should not try killing kernel threads.

Suggested-by: Oleg Nesterov <oleg@redhat.com>
Reviewed-by: Oleg Nesterov <oleg@redhat.com>
Signed-off-by: Anton Vorontsov <anton.vorontsov@linaro.org>
Acked-by: KOSAKI Motohiro <kosaki.motohiro@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

staging: android, lowmemorykiller: convert to use oom_score_adj

/proc/pid/oom_adj is deprecated and will be removed in August 2012
according to Documentation/feature-removal-schedule.txt.  Convert its
usage in the lowmemorykiller to use the new interface, oom_score_adj,
instead.

Signed-off-by: David Rientjes <rientjes@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

staging: android/lowmemorykiller: Don't unregister notifier from atomic context

The lowmemorykiller registers an atomic notifier for notfication of when
the task is freed.  From this atomic notifier callback, it removes the
atomic notifier via task_free_unregister().  This is incorrect because
atomic_notifier_chain_unregister() calls syncronize_rcu(), which can
sleep, which shouldn't be done from an atomic notifier.

Fix this by registering the notifier during init, and only unregister it
if the lowmemorykiller is unloaded.

Rebased to -next by Paul E. McKenney.
Rebased to -next again by Anton Vorontsov.

Signed-off-by: Rabin Vincent <rabin.vincent@stericsson.com>
Signed-off-by: Christian Bejram <christian.bejram@stericsson.com>
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Reported-by: John Stultz <john.stultz@linaro.org>
Signed-off-by: Anton Vorontsov <anton.vorontsov@linaro.org>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Staging: android: lowmemorykiller.c

Fix compiler warning about the type of the module parameter.

Cc: San Mehat <san@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

android, lowmemorykiller: remove task handoff notifier

The task handoff notifier leaks task_struct since it never gets freed
after the callback returns NOTIFY_OK, which means it is responsible for
doing so.

It turns out the lowmemorykiller actually doesn't need this notifier at
all.  It's used to prevent unnecessary killing by waiting for a thread
to exit as a result of lowmem_shrink(), however, it's possible to do
this in the same way the kernel oom killer works by setting TIF_MEMDIE
and avoid killing if we're still waiting for it to exit.

The kernel oom killer will already automatically set TIF_MEMDIE for
threads that are attempting to allocate memory that have a fatal signal.
The thread selected by lowmem_shrink() will have such a signal after the
lowmemorykiller sends it a SIGKILL, so this won't result in an
unnecessary use of memory reserves for the thread to exit.

This has the added benefit that we don't have to rely on
CONFIG_PROFILING to prevent needlessly killing tasks.

Reported-by: Werner Landgraf <w.landgraf@ru.ru>
Cc: stable@vger.kernel.org
Signed-off-by: David Rientjes <rientjes@google.com>
Acked-by: Colin Cross <ccross@android.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Revert "lowmemorykiller: kanged from upstream 3.6.6"

This reverts commit ba391360aa50f19b34322a10fb68775e7910b5bc.
Patch to linux 3.0.51
commit ac7b56f4149a2f0e331a9b640f65aed57ed15eb4
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Mon Nov 5 09:44:42 2012 +0100

    Linux 3.0.51

commit a8a0b23d89dc38d1fc33297924edc50de09250da
Author: Ben Skeggs <bskeggs@redhat.com>
Date:   Mon Oct 29 09:03:07 2012 +1000

    drm/nouveau: silence modesetting spam on pre-gf8 chipsets

    commit cee59f15a60cc6269a25e3f6fbf1a577d6ab8115 upstream.

    Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e418b3bbe9a34fc75a148ff890e0b3442628c5c7
Author: Jan Kara <jack@suse.cz>
Date:   Thu Oct 25 13:37:31 2012 -0700

    mm: fix XFS oops due to dirty pages without buffers on s390

    commit ef5d437f71afdf4afdbab99213add99f4b1318fd upstream.

    On s390 any write to a page (even from kernel itself) sets architecture
    specific page dirty bit.  Thus when a page is written to via buffered
    write, HW dirty bit gets set and when we later map and unmap the page,
    page_remove_rmap() finds the dirty bit and calls set_page_dirty().

    Dirtying of a page which shouldn't be dirty can cause all sorts of
    problems to filesystems.  The bug we observed in practice is that
    buffers from the page get freed, so when the page gets later marked as
    dirty and writeback writes it, XFS crashes due to an assertion
    BUG_ON(!PagePrivate(page)) in page_buffers() called from
    xfs_count_page_state().

    Similar problem can also happen when zero_user_segment() call from
    xfs_vm_writepage() (or block_write_full_page() for that matter) set the
    hardware dirty bit during writeback, later buffers get freed, and then
    page unmapped.

    Fix the issue by ignoring s390 HW dirty bit for page cache pages of
    mappings with mapping_cap_account_dirty().  This is safe because for
    such mappings when a page gets marked as writeable in PTE it is also
    marked dirty in do_wp_page() or do_page_fault().  When the dirty bit is
    cleared by clear_page_dirty_for_io(), the page gets writeprotected in
    page_mkclean().  So pagecache page is writeable if and only if it is
    dirty.

    Thanks to Hugh Dickins for pointing out mapping has to have
    mapping_cap_account_dirty() for things to work and proposing a cleaned
    up variant of the patch.

    The patch has survived about two hours of running fsx-linux on tmpfs
    while heavily swapping and several days of running on out build machines
    where the original problem was triggered.

    Signed-off-by: Jan Kara <jack@suse.cz>
    Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
    Cc: Mel Gorman <mgorman@suse.de>
    Cc: Hugh Dickins <hughd@google.com>
    Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 05e02741ed77cace45997d4a7d4092f5ac84e19a
Author: Len Brown <len.brown@intel.com>
Date:   Thu Mar 29 14:49:17 2012 -0700

    x86: Remove the ancient and deprecated disable_hlt() and enable_hlt() facility

    commit f6365201d8a21fb347260f89d6e9b3e718d63c70 upstream.

    The X86_32-only disable_hlt/enable_hlt mechanism was used by the
    32-bit floppy driver. Its effect was to replace the use of the
    HLT instruction inside default_idle() with cpu_relax() - essentially
    it turned off the use of HLT.

    This workaround was commented in the code as:

     "disable hlt during certain critical i/o operations"

     "This halt magic was a workaround for ancient floppy DMA
      wreckage. It should be safe to remove."

    H. Peter Anvin additionally adds:

     "To the best of my knowledge, no-hlt only existed because of
      flaky power distributions on 386/486 systems which were sold to
      run DOS.  Since DOS did no power management of any kind,
      including HLT, the power draw was fairly uniform; when exposed
      to the much hhigher noise levels you got when Linux used HLT
      caused some of these systems to fail.

      They were by far in the minority even back then."

    Alan Cox further says:

     "Also for the Cyrix 5510 which tended to go castors up if a HLT
      occurred during a DMA cycle and on a few other boxes HLT during
      DMA tended to go astray.

      Do we care ? I doubt it. The 5510 was pretty obscure, the 5520
      fixed it, the 5530 is probably the oldest still in any kind of
      use."

    So, let's finally drop this.

    Signed-off-by: Len Brown <len.brown@intel.com>
    Signed-off-by: Josh Boyer <jwboyer@redhat.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Acked-by: "H. Peter Anvin" <hpa@zytor.com>
    Acked-by: Alan Cox <alan@lxorguk.ukuu.org.uk>
    Cc: Stephen Hemminger <shemminger@vyatta.com
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Link: http://lkml.kernel.org/n/tip-3rhk9bzf0x9rljkv488tloib@git.kernel.org
    [ If anyone cares then alternative instruction patching could be
      used to replace HLT with a one-byte NOP instruction. Much simpler. ]
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2000afe4fb86c374650371f41eb287746790d9ff
Author: Herton Ronaldo Krzesinski <herton.krzesinski@canonical.com>
Date:   Mon Aug 27 20:56:52 2012 -0300

    floppy: do put_disk on current dr if blk_init_queue fails

    commit 238ab78469c6ab7845b43d5061cd3c92331b2452 upstream.

    If blk_init_queue fails, we do not call put_disk on the current dr
    (dr is decremented first in the error handling loop).

    Reviewed-by: Ben Hutchings <ben@decadent.org.uk>
    Signed-off-by: Herton Ronaldo Krzesinski <herton.krzesinski@canonical.com>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>