drivers/cpufreq/cpufreq_stats.c Prevent memory leak on hotplug (Pershoot)
    arch/arm/mm/alignment: fix warning in alignment fixup [Jamie Iles]
    ashmem: fix deadlock when system is low on memory

        When system is low on memory, allocating memory while holding the
        ashmem_mutex may try to directly reclaim memory. Then ashmem_shrink()
        is called in same thread. It will deadlock at acquiring ashmem_mutex.
        This change lets ashmem_shrink() return failure if ashmem_mutex is not
        available. Memory will be reclaimed from others.

        Change-Id: I3b6024d5477d37245f4ebde6d7069fb77af789ee
        Signed-off-by: Yuanyuan Zhong <yuanyuan.zhong@gmail.com>
    lib/decompress_bunzip2: fix checkstack warning [Prarit Bhargava]
    cgroup: fix cpuset permission check

        The permission check code added by "cgroup: Add generic cgroup subsystem
        permission checks" does not build and also leaves a variable uninitialized.
        Fix it.

        Change-Id: I8009d6315527725d45b20792b7cd74aedc9bff44
        Signed-off-by: Rabin Vincent <rabin.vincent@stericsson.com>
        Signed-off-by: Christian Bejram <christian.bejram@stericsson.com>
    mmc: Attribute the IO wait time properly in mmc_wait_for_req().

        In mmc_wait_for_req() function, change the call wait_for_completion()
        to wait_for_completion_io(). This change makes the kernel account for
        wait time as I/O wait and through another configuration this I/O wait
        is treated as busy which makes the acpu clock to scale up.

        CRs-Fixed: 283420
        Change-Id: If3de6325b7e4cf8141c808e5853f4fc2dbb4e3ec
        Signed-off-by: Murali Palnati <palnatim@codeaurora.org>
    fs: mark_inode_dirty barrier fix

        Filesystems appear to be using ->dirty_inode, expecting that the dirtying
        operating is done and visible to all CPUs (eg. setting private inode dirty
        bits, without any barriers themselves). So release the dirty "critical
        section" with a barrier before calling ->dirty_inode.

        Cost is not significantly changed, because we're just moving the barrier.
        Those filesystems that do use ->dirty_inode should have to care slightly
        less about barriers, which is a good thing.

        Signed-off-by: Nick Piggin <npiggin@kernel.dk>
    fs: simple fsync race fix

        It is incorrect to test inode dirty bits without participating in the inode
        writeback protocol. Inode writeback sets I_SYNC and clears I_DIRTY_?, then
        writes out the particular bits, then clears I_SYNC when it is done. BTW. it
        may not completely write all pages out, so I_DIRTY_PAGES would get set
        again.

        This is a standard pattern used throughout the kernel's writeback caches
        (I_SYNC ~= I_WRITEBACK, if that makes it clearer).

        And so it is not possible to determine an inode's dirty status just by
        checking I_DIRTY bits. Especially not for the purpose of data integrity
        syncs.

        Missing the check for these bits means that fsync can complete while
        writeback to the inode is underway. Inode writeback functions get this
        right, so call into them rather than try to shortcut things by testing
        dirty state improperly.

        Signed-off-by: Nick Piggin <npiggin@kernel.dk>
    mm/page_alloc.c: prevent unending loop in __alloc_pages_slowpath()

        commit cfa54a0fcfc1017c6f122b6f21aaba36daa07f71 upstream.

        I believe I found a problem in __alloc_pages_slowpath, which allows a
        process to get stuck endlessly looping, even when lots of memory is
        available.

        Running an I/O and memory intensive stress-test I see a 0-order page
        allocation with __GFP_IO and __GFP_WAIT, running on a system with very
        little free memory.  Right about the same time that the stress-test gets
        killed by the OOM-killer, the utility trying to allocate memory gets stuck
        in __alloc_pages_slowpath even though most of the systems memory was freed
        by the oom-kill of the stress-test.

        The utility ends up looping from the rebalance label down through the
        wait_iff_congested continiously.  Because order=0,
        __alloc_pages_direct_compact skips the call to get_page_from_freelist.
        Because all of the reclaimable memory on the system has already been
        reclaimed, __alloc_pages_direct_reclaim skips the call to
        get_page_from_freelist.  Since there is no __GFP_FS flag, the block with
        __alloc_pages_may_oom is skipped.  The loop hits the wait_iff_congested,
        then jumps back to rebalance without ever trying to
        get_page_from_freelist.  This loop repeats infinitely.

        The test case is pretty pathological.  Running a mix of I/O stress-tests
        that do a lot of fork() and consume all of the system memory, I can pretty
        reliably hit this on 600 nodes, in about 12 hours.  32GB/node.

        Signed-off-by: Andrew Barry <abarry@cray.com>
        Signed-off-by: Minchan Kim <minchan.kim@gmail.com>
        Reviewed-by: Rik van Riel<riel@redhat.com>
        Acked-by: Mel Gorman <mgorman@suse.de>
        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@suse.de>
    vmalloc: remove redundant unlikely()

        IS_ERR() already implies unlikely(), so it can be omitted here.

        Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
        Reviewed-by: Minchan Kim <minchan.kim@gmail.com>
        Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
        Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    mm: remove likely() from mapping_unevictable()

        The mapping_unevictable() has a likely() around the mapping parameter.
        This mapping parameter comes from page_mapping() which has an unlikely()
        that the page will be set as PAGE_MAPPING_ANON, and if so, it will return
        NULL.  One would think that this unlikely() means that the mapping
        returned by page_mapping() would not be NULL, but where page_mapping() is
        used just above mapping_unevictable(), that unlikely() is incorrect most
        of the time.  This means that the "likely(mapping)" in
        mapping_unevictable() is incorrect most of the time.

        Running the annotated branch profiler on my main box which runs firefox,
        evolution, xchat and is part of my distcc farm, I had this:

         correct incorrect  %        Function                  File              Line
         ------- ---------  -        --------                  ----              ----
        12872836 1269443893  98 mapping_unevictable            pagemap.h            51
        35935762 1270265395  97 page_mapping                   mm.h                 659
        1306198001   143659   0 page_mapping                   mm.h                 657
        203131478   121586   0 page_mapping                   mm.h                 657
         5415491     1116   0 page_mapping                   mm.h                 657
        74899487     1116   0 page_mapping                   mm.h                 657
        203132845      224   0 page_mapping                   mm.h                 659
         5415464       27   0 page_mapping                   mm.h                 659
           13552        0   0 page_mapping                   mm.h                 657
           13552        0   0 page_mapping                   mm.h                 659
          242630        0   0 page_mapping                   mm.h                 657
          242630        0   0 page_mapping                   mm.h                 659
        74899487        0   0 page_mapping                   mm.h                 659

        The page_mapping() is a static inline, which is why it shows up multiple
        times.  The mapping_unevictable() is also a static inline but seems to be
        used only once in my setup.

        The unlikely in page_mapping() was correct a total of 1909540379 times and
        incorrect 1270533123 times, with a 39% being incorrect.  Perhaps this is
        enough to remove the unlikely from page_mapping() as well.

        Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
        Reviewed-by: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
        Acked-by: Nick Piggin <npiggin@kernel.dk>
        Acked-by: Rik van Riel <riel@redhat.com>
        Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
        Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
        Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    mm: remove likely() from grab_cache_page_write_begin()

        Running the annotated branch profiler on a box doing average work
        (firefox, evolution, xchat, distcc farm), the likely() used in
        grab_cache_page_write_begin() was incorrect most of the time:

         correct incorrect  %        Function                  File              Line
         ------- ---------  -        --------                  ----              ----
         1924262 71332401  97 grab_cache_page_write_begin    filemap.c           2206

        Adding a trace_printk() and running the function tracer limited to
        just this function I can see:

                gconfd-2-2696  [000]  4467.268935: grab_cache_page_write_begin: page=          (null) mapping=ffff8800676a9460 index=7
                gconfd-2-2696  [000]  4467.268946: grab_cache_page_write_begin <-ext3_write_begin
                gconfd-2-2696  [000]  4467.268947: grab_cache_page_write_begin: page=          (null) mapping=ffff8800676a9460 index=8
                gconfd-2-2696  [000]  4467.268959: grab_cache_page_write_begin <-ext3_write_begin
                gconfd-2-2696  [000]  4467.268960: grab_cache_page_write_begin: page=          (null) mapping=ffff8800676a9460 index=9
                gconfd-2-2696  [000]  4467.268972: grab_cache_page_write_begin <-ext3_write_begin
                gconfd-2-2696  [000]  4467.268973: grab_cache_page_write_begin: page=          (null) mapping=ffff8800676a9460 index=10
                gconfd-2-2696  [000]  4467.268991: grab_cache_page_write_begin <-ext3_write_begin
                gconfd-2-2696  [000]  4467.268992: grab_cache_page_write_begin: page=          (null) mapping=ffff8800676a9460 index=11
                gconfd-2-2696  [000]  4467.269005: grab_cache_page_write_begin <-ext3_write_begin

        Which shows that a lot of calls from ext3_write_begin will result in the
        page returned by "find_lock_page" will be NULL.

        Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
        Acked-by: Nick Piggin <npiggin@kernel.dk>
        Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
        Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    writeback: avoid unnecessary determine_dirtyable_memory call

        I think determine_dirtyable_memory() is a rather costly function since it
        need many atomic reads for gathering zone/global page state.  But when we
        use vm_dirty_bytes && dirty_background_bytes, we don't need that costly
        calculation.

        This patch eliminates such unnecessary overhead.

        NOTE : newly added if condition might add overhead in normal path.
               But it should be _really_ small because anyway we need the
               access both vm_dirty_bytes and dirty_background_bytes so it is
               likely to hit the cache.

        [akpm@linux-foundation.org: fix used-uninitialised warning]
        Signed-off-by: Minchan Kim <minchan.kim@gmail.com>
        Cc: Wu Fengguang <fengguang.wu@intel.com>
        Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
        Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
        Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    brk: fix min_brk lower bound computation for COMPAT_BRK

        Even if CONFIG_COMPAT_BRK is set in the kernel configuration, it can still
        be overriden by randomize_va_space sysctl.

        If this is the case, the min_brk computation in sys_brk() implementation
        is wrong, as it solely takes into account COMPAT_BRK setting, assuming
        that brk start is not randomized.  But that might not be the case if
        randomize_va_space sysctl has been set to '2' at the time the binary has
        been loaded from disk.

        In such case, the check has to be done in a same way as in
        !CONFIG_COMPAT_BRK case.

        In addition to that, the check for the COMPAT_BRK case introduced back in
        a5b4592c ("brk: make sys_brk() honor COMPAT_BRK when computing lower
        bound") is slightly wrong -- the lower bound shouldn't be mm->end_code,
        but mm->end_data instead, as that's where the legacy applications expect
        brk section to start (i.e.  immediately after last global variable).

        [akpm@linux-foundation.org: fix comment]
        Signed-off-by: Jiri Kosina <jkosina@suse.cz>
        Cc: Geert Uytterhoeven <geert@linux-m68k.org>
        Cc: Ingo Molnar <mingo@elte.hu>
        Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
        Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    mm/dmapool.c: take lock only once in dma_pool_free()

        dma_pool_free() scans for the page to free in the pool list holding the
        pool lock.  Then it releases the lock basically to acquire it immediately
        again.  Modify the code to only take the lock once.

        This will do some additional loops and computations with the lock held in
        if memory debugging is activated.  If it is not activated the only new
        operations with this lock is one if and one substraction.

        Signed-off-by: Rolf Eike Beer <eike-kernel@sf-tec.de>
        Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
        Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    mm/dmapool.c: use TASK_UNINTERRUPTIBLE in dma_pool_alloc()

        As it stands this code will degenerate into a busy-wait if the calling task
        has signal_pending().

        Cc: Rolf Eike Beer <eike-kernel@sf-tec.de>
        Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
        Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    fs: add hole punching to fallocate

        Hole punching has already been implemented by XFS and OCFS2, and has the
        potential to be implemented on both BTRFS and EXT4 so we need a generic way to
        get to this feature.  The simplest way in my mind is to add FALLOC_FL_PUNCH_HOLE
        to fallocate() since it already looks like the normal fallocate() operation.
        I've tested this patch with XFS and BTRFS to make sure XFS did what it's
        supposed to do and that BTRFS failed like it was supposed to.  Thank you,

        Signed-off-by: Josef Bacik <josef@redhat.com>
        Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
    fs/select.c: fix information leak to userspace

        On some architectures __kernel_suseconds_t is int.  On these archs struct
        timeval has padding bytes at the end.  This struct is copied to userspace
        with these padding bytes uninitialized.  This leads to leaking of contents
        of kernel stack memory.

        This bug was added with v2.6.27-rc5-286-gb773ad4.

        [akpm@linux-foundation.org: avoid the memset on architectures which don't need it]
        Signed-off-by: Vasiliy Kulikov <segooon@gmail.com>
        Cc: Al Viro <viro@zeniv.linux.org.uk>
        Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
        Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    PM: Lock PM device list mutex in show_dev_hash()

    Lock the PM device list mutex using device_pm_lock() and
    device_pm_unlock() around the list iteration in show_dev_hash().

    show_dev_hash() was reverse iterating dpm_list without first locking the
    mutex that the functions in drivers/base/power/main.c lock. I assume
    this was unintentional since there is no comment suggesting why the lock
    might not be necessary.

    Signed-off-by: James Hogan <james@albanarts.com>
    Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
    PM: Use proper ccflag flag in kernel/power/Makefile

    Use the ccflags-$ flag instead of EXTRA_CFLAGS because EXTRA_CFLAGS is
    deprecated and should now be switched.  According to
    (documentation/kbuild/makefiles.txt).

    Signed-off-by: Tracey Dent <tdent48227@gmail.com>
    Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>