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>
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/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: Prototype the pm_generic_ operations

    The pm_generic_ operations are all exported but are not prototyped in any
    header file for direct use. Do so.

    [rjw: Added extern.]

    Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
    Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
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>
add patches from roqu3 kernel