commit 016ea480c9ca2344006d3ef592a0154ba03b507a
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Thu Jan 29 17:41:44 2015 -0800

    Linux 3.14.31

commit 50606f9a4cdba0499ae76a3111b3a7acfdb4a9d0
Author: NeilBrown <neilb@suse.de>
Date:   Wed Dec 3 16:07:58 2014 +1100

    md/raid5: fetch_block must fetch all the blocks handle_stripe_dirtying wants.
    
    commit 108cef3aa41669610e1836fe638812dd067d72de upstream.
    
    It is critical that fetch_block() and handle_stripe_dirtying()
    are consistent in their analysis of what needs to be loaded.
    Otherwise raid5 can wait forever for a block that won't be loaded.
    
    Currently when writing to a RAID5 that is resyncing, to a location
    beyond the resync offset, handle_stripe_dirtying chooses a
    reconstruct-write cycle, but fetch_block() assumes a
    read-modify-write, and a lockup can happen.
    
    So treat that case just like RAID6, just as we do in
    handle_stripe_dirtying.  RAID6 always does reconstruct-write.
    
    This bug was introduced when the behaviour of handle_stripe_dirtying
    was changed in 3.7, so the patch is suitable for any kernel since,
    though it will need careful merging for some versions.
    
    Cc: stable@vger.kernel.org (v3.7+)
    Fixes: a7854487cd7128a30a7f4f5259de9f67d5efb95f
    Reported-by: Henry Cai <henryplusplus@gmail.com>
    Signed-off-by: NeilBrown <neilb@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 525f2d01368852ed91d220e0106bbfcefe5f1450
Author: Michal Hocko <mhocko@suse.cz>
Date:   Mon Dec 29 20:30:35 2014 +0100

    mm: get rid of radix tree gfp mask for pagecache_get_page
    
    commit 45f87de57f8fad59302fd263dd81ffa4843b5b24 upstream.
    
    Commit 2457aec63745 ("mm: non-atomically mark page accessed during page
    cache allocation where possible") has added a separate parameter for
    specifying gfp mask for radix tree allocations.
    
    Not only this is less than optimal from the API point of view because it
    is error prone, it is also buggy currently because
    grab_cache_page_write_begin is using GFP_KERNEL for radix tree and if
    fgp_flags doesn't contain FGP_NOFS (mostly controlled by fs by
    AOP_FLAG_NOFS flag) but the mapping_gfp_mask has __GFP_FS cleared then
    the radix tree allocation wouldn't obey the restriction and might
    recurse into filesystem and cause deadlocks.  This is the case for most
    filesystems unfortunately because only ext4 and gfs2 are using
    AOP_FLAG_NOFS.
    
    Let's simply remove radix_gfp_mask parameter because the allocation
    context is same for both page cache and for the radix tree.  Just make
    sure that the radix tree gets only the sane subset of the mask (e.g.  do
    not pass __GFP_WRITE).
    
    Long term it is more preferable to convert remaining users of
    AOP_FLAG_NOFS to use mapping_gfp_mask instead and simplify this
    interface even further.
    
    Reported-by: Dave Chinner <david@fromorbit.com>
    Signed-off-by: Michal Hocko <mhocko@suse.cz>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a0d134d3e45980551e98d9b8ff11713e81622e02
Author: Mel Gorman <mgorman@suse.de>
Date:   Thu Aug 28 19:35:45 2014 +0100

    mm: page_alloc: reduce cost of the fair zone allocation policy
    
    commit 4ffeaf3560a52b4a69cc7909873d08c0ef5909d4 upstream.
    
    The fair zone allocation policy round-robins allocations between zones
    within a node to avoid age inversion problems during reclaim.  If the
    first allocation fails, the batch counts are reset and a second attempt
    made before entering the slow path.
    
    One assumption made with this scheme is that batches expire at roughly
    the same time and the resets each time are justified.  This assumption
    does not hold when zones reach their low watermark as the batches will
    be consumed at uneven rates.  Allocation failure due to watermark
    depletion result in additional zonelist scans for the reset and another
    watermark check before hitting the slowpath.
    
    On UMA, the benefit is negligible -- around 0.25%.  On 4-socket NUMA
    machine it's variable due to the variability of measuring overhead with
    the vmstat changes.  The system CPU overhead comparison looks like
    
              3.16.0-rc3  3.16.0-rc3  3.16.0-rc3
                 vanilla   vmstat-v5 lowercost-v5
    User          746.94      774.56      802.00
    System      65336.22    32847.27    40852.33
    Elapsed     27553.52    27415.04    27368.46
    
    However it is worth noting that the overall benchmark still completed
    faster and intuitively it makes sense to take as few passes as possible
    through the zonelists.
    
    Signed-off-by: Mel Gorman <mgorman@suse.de>
    Acked-by: Johannes Weiner <hannes@cmpxchg.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Mel Gorman <mgorman@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a54cf1b3210610ebd9285e7bd79cb7613f54f0cd
Author: Mel Gorman <mgorman@suse.de>
Date:   Thu Aug 28 19:35:44 2014 +0100

    mm: page_alloc: abort fair zone allocation policy when remotes nodes are encountered
    
    commit f7b5d647946aae1647bf5cd26c16b3a793c1ac49 upstream.
    
    The purpose of numa_zonelist_order=zone is to preserve lower zones for
    use with 32-bit devices.  If locality is preferred then the
    numa_zonelist_order=node policy should be used.
    
    Unfortunately, the fair zone allocation policy overrides this by
    skipping zones on remote nodes until the lower one is found.  While this
    makes sense from a page aging and performance perspective, it breaks the
    expected zonelist policy.  This patch restores the expected behaviour
    for zone-list ordering.
    
    Signed-off-by: Mel Gorman <mgorman@suse.de>
    Acked-by: Johannes Weiner <hannes@cmpxchg.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Mel Gorman <mgorman@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 442ae03a52461e81eb95a776c9a3009fd4f7daca
Author: Mel Gorman <mgorman@suse.de>
Date:   Wed Aug 6 16:07:18 2014 -0700

    mm: vmscan: only update per-cpu thresholds for online CPU
    
    commit bb0b6dffa2ccfbd9747ad0cc87c7459622896e60 upstream.
    
    When kswapd is awake reclaiming, the per-cpu stat thresholds are lowered
    to get more accurate counts to avoid breaching watermarks.  This
    threshold update iterates over all possible CPUs which is unnecessary.
    Only online CPUs need to be updated.  If a new CPU is onlined,
    refresh_zone_stat_thresholds() will set the thresholds correctly.
    
    Signed-off-by: Mel Gorman <mgorman@suse.de>
    Acked-by: Johannes Weiner <hannes@cmpxchg.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Mel Gorman <mgorman@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e341f2a89ab31ede47254feac4f7abc3203ee56c
Author: Mel Gorman <mgorman@suse.de>
Date:   Wed Aug 6 16:07:16 2014 -0700

    mm: move zone->pages_scanned into a vmstat counter
    
    commit 0d5d823ab4e608ec7b52ac4410de4cb74bbe0edd upstream.
    
    zone->pages_scanned is a write-intensive cache line during page reclaim
    and it's also updated during page free.  Move the counter into vmstat to
    take advantage of the per-cpu updates and do not update it in the free
    paths unless necessary.
    
    On a small UMA machine running tiobench the difference is marginal.  On
    a 4-node machine the overhead is more noticable.  Note that automatic
    NUMA balancing was disabled for this test as otherwise the system CPU
    overhead is unpredictable.
    
              3.16.0-rc3  3.16.0-rc3  3.16.0-rc3
                 vanillarearrange-v5   vmstat-v5
    User          746.94      759.78      774.56
    System      65336.22    58350.98    32847.27
    Elapsed     27553.52    27282.02    27415.04
    
    Note that the overhead reduction will vary depending on where exactly
    pages are allocated and freed.
    
    Signed-off-by: Mel Gorman <mgorman@suse.de>
    Acked-by: Johannes Weiner <hannes@cmpxchg.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Mel Gorman <mgorman@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 36806371a2a9c34c6e3cde683cb36732142f0627
Author: Mel Gorman <mgorman@suse.de>
Date:   Wed Aug 6 16:07:14 2014 -0700

    mm: rearrange zone fields into read-only, page alloc, statistics and page reclaim lines
    
    commit 3484b2de9499df23c4604a513b36f96326ae81ad upstream.
    
    The arrangement of struct zone has changed over time and now it has
    reached the point where there is some inappropriate sharing going on.
    On x86-64 for example
    
    o The zone->node field is shared with the zone lock and zone->node is
      accessed frequently from the page allocator due to the fair zone
      allocation policy.
    
    o span_seqlock is almost never used by shares a line with free_area
    
    o Some zone statistics share a cache line with the LRU lock so
      reclaim-intensive and allocator-intensive workloads can bounce the cache
      line on a stat update
    
    This patch rearranges struct zone to put read-only and read-mostly
    fields together and then splits the page allocator intensive fields, the
    zone statistics and the page reclaim intensive fields into their own
    cache lines.  Note that the type of lowmem_reserve changes due to the
    watermark calculations being signed and avoiding a signed/unsigned
    conversion there.
    
    On the test configuration I used the overall size of struct zone shrunk
    by one cache line.  On smaller machines, this is not likely to be
    noticable.  However, on a 4-node NUMA machine running tiobench the
    system CPU overhead is reduced by this patch.
    
              3.16.0-rc3  3.16.0-rc3
                 vanillarearrange-v5r9
    User          746.94      759.78
    System      65336.22    58350.98
    Elapsed     27553.52    27282.02
    
    Signed-off-by: Mel Gorman <mgorman@suse.de>
    Acked-by: Johannes Weiner <hannes@cmpxchg.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Mel Gorman <mgorman@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 84532d77391d45a2a204c039664fa6dbcc121a01
Author: Mel Gorman <mgorman@suse.de>
Date:   Wed Aug 6 16:07:11 2014 -0700

    mm: pagemap: avoid unnecessary overhead when tracepoints are deactivated
    
    commit 24b7e5819ad5cbef2b7c7376510862aa8319d240 upstream.
    
    This was formerly the series "Improve sequential read throughput" which
    noted some major differences in performance of tiobench since 3.0.
    While there are a number of factors, two that dominated were the
    introduction of the fair zone allocation policy and changes to CFQ.
    
    The behaviour of fair zone allocation policy makes more sense than
    tiobench as a benchmark and CFQ defaults were not changed due to
    insufficient benchmarking.
    
    This series is what's left.  It's one functional fix to the fair zone
    allocation policy when used on NUMA machines and a reduction of overhead
    in general.  tiobench was used for the comparison despite its flaws as
    an IO benchmark as in this case we are primarily interested in the
    overhead of page allocator and page reclaim activity.
    
    On UMA, it makes little difference to overhead
    
              3.16.0-rc3   3.16.0-rc3
                 vanilla lowercost-v5
    User          383.61      386.77
    System        403.83      401.74
    Elapsed      5411.50     5413.11
    
    On a 4-socket NUMA machine it's a bit more noticable
    
              3.16.0-rc3   3.16.0-rc3
                 vanilla lowercost-v5
    User          746.94      802.00
    System      65336.22    40852.33
    Elapsed     27553.52    27368.46
    
    This patch (of 6):
    
    The LRU insertion and activate tracepoints take PFN as a parameter
    forcing the overhead to the caller.  Move the overhead to the tracepoint
    fast-assign method to ensure the cost is only incurred when the
    tracepoint is active.
    
    Signed-off-by: Mel Gorman <mgorman@suse.de>
    Acked-by: Johannes Weiner <hannes@cmpxchg.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Mel Gorman <mgorman@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 299040331834e81a720acb85be2acfdf85a32b56
Author: Jerome Marchand <jmarchan@redhat.com>
Date:   Wed Aug 6 16:08:03 2014 -0700

    memcg, vmscan: Fix forced scan of anonymous pages
    
    commit 2ab051e11bfa3cbb7b24177f3d6aaed10a0d743e upstream.
    
    When memory cgoups are enabled, the code that decides to force to scan
    anonymous pages in get_scan_count() compares global values (free,
    high_watermark) to a value that is restricted to a memory cgroup (file).
    It make the code over-eager to force anon scan.
    
    For instance, it will force anon scan when scanning a memcg that is
    mainly populated by anonymous page, even when there is plenty of file
    pages to get rid of in others memcgs, even when swappiness == 0.  It
    breaks user's expectation about swappiness and hurts performance.
    
    This patch makes sure that forced anon scan only happens when there not
    enough file pages for the all zone, not just in one random memcg.
    
    [hannes@cmpxchg.org: cleanups]
    Signed-off-by: Jerome Marchand <jmarchan@redhat.com>
    Acked-by: Michal Hocko <mhocko@suse.cz>
    Acked-by: Johannes Weiner <hannes@cmpxchg.org>
    Reviewed-by: Rik van Riel <riel@redhat.com>
    Cc: Mel Gorman <mgorman@suse.de>
    Signed-off-by: Johannes Weiner <hannes@cmpxchg.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Mel Gorman <mgorman@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit cbc42af9f6d80d270ce02c6f5daf21afed3fcb71
Author: Joonsoo Kim <iamjoonsoo.kim@lge.com>
Date:   Wed Aug 6 16:05:06 2014 -0700

    vmalloc: use rcu list iterator to reduce vmap_area_lock contention
    
    commit 474750aba88817c53f39424e5567b8e4acc4b39b upstream.
    
    Richard Yao reported a month ago that his system have a trouble with
    vmap_area_lock contention during performance analysis by /proc/meminfo.
    Andrew asked why his analysis checks /proc/meminfo stressfully, but he
    didn't answer it.
    
      https://lkml.org/lkml/2014/4/10/416
    
    Although I'm not sure that this is right usage or not, there is a
    solution reducing vmap_area_lock contention with no side-effect.  That
    is just to use rcu list iterator in get_vmalloc_info().
    
    rcu can be used in this function because all RCU protocol is already
    respected by writers, since Nick Piggin commit db64fe02258f1 ("mm:
    rewrite vmap layer") back in linux-2.6.28
    
    Specifically :
       insertions use list_add_rcu(),
       deletions use list_del_rcu() and kfree_rcu().
    
    Note the rb tree is not used from rcu reader (it would not be safe),
    only the vmap_area_list has full RCU protection.
    
    Note that __purge_vmap_area_lazy() already uses this rcu protection.
    
            rcu_read_lock();
            list_for_each_entry_rcu(va, &vmap_area_list, list) {
                    if (va->flags & VM_LAZY_FREE) {
                            if (va->va_start < *start)
                                    *start = va->va_start;
                            if (va->va_end > *end)
                                    *end = va->va_end;
                            nr += (va->va_end - va->va_start) >> PAGE_SHIFT;
                            list_add_tail(&va->purge_list, &valist);
                            va->flags |= VM_LAZY_FREEING;
                            va->flags &= ~VM_LAZY_FREE;
                    }
            }
            rcu_read_unlock();
    
    Peter:
    
    : While rcu list traversal over the vmap_area_list is safe, this may
    : arrive at different results than the spinlocked version. The rcu list
    : traversal version will not be a 'snapshot' of a single, valid instant
    : of the entire vmap_area_list, but rather a potential amalgam of
    : different list states.
    
    Joonsoo:
    
    : Yes, you are right, but I don't think that we should be strict here.
    : Meminfo is already not a 'snapshot' at specific time.  While we try to get
    : certain stats, the other stats can change.  And, although we may arrive at
    : different results than the spinlocked version, the difference would not be
    : large and would not make serious side-effect.
    
    [edumazet@google.com: add more commit description]
    Signed-off-by: Joonsoo Kim <iamjoonsoo.kim@lge.com>
    Reported-by: Richard Yao <ryao@gentoo.org>
    Acked-by: Eric Dumazet <edumazet@google.com>
    Cc: Peter Hurley <peter@hurleysoftware.com>
    Cc: Zhang Yanfei <zhangyanfei.yes@gmail.com>
    Cc: Johannes Weiner <hannes@cmpxchg.org>
    Cc: Andi Kleen <andi@firstfloor.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Mel Gorman <mgorman@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 63aefc47b630e845bd46e5303cb7a3a3f44c8e6f
Author: Jerome Marchand <jmarchan@redhat.com>
Date:   Wed Aug 6 16:06:56 2014 -0700

    mm: make copy_pte_range static again
    
    commit 21bda264f4243f61dfcc485174055f12ad0530b4 upstream.
    
    Commit 71e3aac0724f ("thp: transparent hugepage core") adds
    copy_pte_range prototype to huge_mm.h.  I'm not sure why (or if) this
    function have been used outside of memory.c, but it currently isn't.
    This patch makes copy_pte_range() static again.
    
    Signed-off-by: Jerome Marchand <jmarchan@redhat.com>
    Acked-by: David Rientjes <rientjes@google.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Mel Gorman <mgorman@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 06ed94e91856817cc64e81378c0f1d7fd605d169
Author: David Rientjes <rientjes@google.com>
Date:   Wed Aug 6 16:07:29 2014 -0700

    mm, thp: only collapse hugepages to nodes with affinity for zone_reclaim_mode
    
    commit 14a4e2141e24304fff2c697be6382ffb83888185 upstream.
    
    Commit 9f1b868a13ac ("mm: thp: khugepaged: add policy for finding target
    node") improved the previous khugepaged logic which allocated a
    transparent hugepages from the node of the first page being collapsed.
    
    However, it is still possible to collapse pages to remote memory which
    may suffer from additional access latency.  With the current policy, it
    is possible that 255 pages (with PAGE_SHIFT == 12) will be collapsed
    remotely if the majority are allocated from that node.
    
    When zone_reclaim_mode is enabled, it means the VM should make every
    attempt to allocate locally to prevent NUMA performance degradation.  In
    this case, we do not want to collapse hugepages to remote nodes that
    would suffer from increased access latency.  Thus, when
    zone_reclaim_mode is enabled, only allow collapsing to nodes with
    RECLAIM_DISTANCE or less.
    
    There is no functional change for systems that disable
    zone_reclaim_mode.
    
    Signed-off-by: David Rientjes <rientjes@google.com>
    Cc: Dave Hansen <dave.hansen@intel.com>
    Cc: Andrea Arcangeli <aarcange@redhat.com>
    Acked-by: Vlastimil Babka <vbabka@suse.cz>
    Acked-by: Mel Gorman <mgorman@suse.de>
    Cc: Rik van Riel <riel@redhat.com>
    Cc: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>
    Cc: Bob Liu <bob.liu@oracle.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Mel Gorman <mgorman@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2eeaa64a14ceda1f4b08697548c16601e3942c20
Author: Hugh Dickins <hughd@google.com>
Date:   Wed Aug 6 16:05:08 2014 -0700

    mm/memory.c: use entry = ACCESS_ONCE(*pte) in handle_pte_fault()
    
    commit c0d73261f5c1355a35b8b40e871d31578ce0c044 upstream.
    
    Use ACCESS_ONCE() in handle_pte_fault() when getting the entry or
    orig_pte upon which all subsequent decisions and pte_same() tests will
    be made.
    
    I have no evidence that its lack is responsible for the mm/filemap.c:202
    BUG_ON(page_mapped(page)) in __delete_from_page_cache() found by
    trinity, and I am not optimistic that it will fix it.  But I have found
    no other explanation, and ACCESS_ONCE() here will surely not hurt.
    
    If gcc does re-access the pte before passing it down, then that would be
    disastrous for correct page fault handling, and certainly could explain
    the page_mapped() BUGs seen (concurrent fault causing page to be mapped
    in a second time on top of itself: mapcount 2 for a single pte).
    
    Signed-off-by: Hugh Dickins <hughd@google.com>
    Cc: Sasha Levin <sasha.levin@oracle.com>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>
    Cc: Konstantin Khlebnikov <koct9i@gmail.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Mel Gorman <mgorman@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 15c145c39719fbcb3818fbc0df843f7263bbbe89
Author: Hugh Dickins <hughd@google.com>
Date:   Wed Jul 2 15:22:38 2014 -0700

    shmem: fix init_page_accessed use to stop !PageLRU bug
    
    commit 66d2f4d28cd030220e7ea2a628993fcabcb956d1 upstream.
    
    Under shmem swapping load, I sometimes hit the VM_BUG_ON_PAGE(!PageLRU)
    in isolate_lru_pages() at mm/vmscan.c:1281!
    
    Commit 2457aec63745 ("mm: non-atomically mark page accessed during page
    cache allocation where possible") looks like interrupted work-in-progress.
    
    mm/filemap.c's call to init_page_accessed() is fine, but not mm/shmem.c's
    - shmem_write_begin() is clearly wrong to use it after shmem_getpage(),
    when the page is always visible in radix_tree, and often already on LRU.
    
    Revert change to shmem_write_begin(), and use init_page_accessed() or
    mark_page_accessed() appropriately for SGP_WRITE in shmem_getpage_gfp().
    
    SGP_WRITE also covers shmem_symlink(), which did not mark_page_accessed()
    before; but since many other filesystems use [__]page_symlink(), which did
    and does mark the page accessed, consider this as rectifying an oversight.
    
    Signed-off-by: Hugh Dickins <hughd@google.com>
    Acked-by: Mel Gorman <mgorman@suse.de>
    Cc: Johannes Weiner <hannes@cmpxchg.org>
    Cc: Vlastimil Babka <vbabka@suse.cz>
    Cc: Michal Hocko <mhocko@suse.cz>
    Cc: Dave Hansen <dave.hansen@intel.com>
    Cc: Prabhakar Lad <prabhakar.csengg@gmail.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Mel Gorman <mgorman@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 07e97c1e9bb85706d84395aa46d47c8ae5ff3e0f
Author: Mel Gorman <mgorman@suse.de>
Date:   Wed Jun 4 16:10:34 2014 -0700

    mm: avoid unnecessary atomic operations during end_page_writeback()
    
    commit 888cf2db475a256fb0cda042140f73d7881f81fe upstream.
    
    If a page is marked for immediate reclaim then it is moved to the tail of
    the LRU list.  This occurs when the system is under enough memory pressure
    for pages under writeback to reach the end of the LRU but we test for this
    using atomic operations on every writeback.  This patch uses an optimistic
    non-atomic test first.  It'll miss some pages in rare cases but the
    consequences are not severe enough to warrant such a penalty.
    
    While the function does not dominate profiles during a simple dd test the
    cost of it is reduced.
    
    73048     0.7428  vmlinux-3.15.0-rc5-mmotm-20140513 end_page_writeback
    23740     0.2409  vmlinux-3.15.0-rc5-lessatomic     end_page_writeback
    
    Signed-off-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: Mel Gorman <mgorman@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 35dbe179fe2af754b0ac92c629435c39bd95681c
Author: Mel Gorman <mgorman@suse.de>
Date:   Wed Jun 4 16:10:31 2014 -0700

    mm: non-atomically mark page accessed during page cache allocation where possible
    
    commit 2457aec63745e235bcafb7ef312b182d8682f0fc upstream.
    
    aops->write_begin may allocate a new page and make it visible only to have
    mark_page_accessed called almost immediately after.  Once the page is
    visible the atomic operations are necessary which is noticable overhead
    when writing to an in-memory filesystem like tmpfs but should also be
    noticable with fast storage.  The objective of the patch is to initialse
    the accessed information with non-atomic operations before the page is
    visible.
    
    The bulk of filesystems directly or indirectly use
    grab_cache_page_write_begin or find_or_create_page for the initial
    allocation of a page cache page.  This patch adds an init_page_accessed()
    helper which behaves like the first call to mark_page_accessed() but may
    called before the page is visible and can be done non-atomically.
    
    The primary APIs of concern in this care are the following and are used
    by most filesystems.
    
    	find_get_page
    	find_lock_page
    	find_or_create_page
    	grab_cache_page_nowait
    	grab_cache_page_write_begin
    
    All of them are very similar in detail to the patch creates a core helper
    pagecache_get_page() which takes a flags parameter that affects its
    behavior such as whether the page should be marked accessed or not.  Then
    old API is preserved but is basically a thin wrapper around this core
    function.
    
    Each of the filesystems are then updated to avoid calling
    mark_page_accessed when it is known that the VM interfaces have already
    done the job.  There is a slight snag in that the timing of the
    mark_page_accessed() has now changed so in rare cases it's possible a page
    gets to the end of the LRU as PageReferenced where as previously it might
    have been repromoted.  This is expected to be rare but it's worth the
    filesystem people thinking about it in case they see a problem with the
    timing change.  It is also the case that some filesystems may be marking
    pages accessed that previously did not but it makes sense that filesystems
    have consistent behaviour in this regard.
    
    The test case used to evaulate this is a simple dd of a large file done
    multiple times with the file deleted on each iterations.  The size of the
    file is 1/10th physical memory to avoid dirty page balancing.  In the
    async case it will be possible that the workload completes without even
    hitting the disk and will have variable results but highlight the impact
    of mark_page_accessed for async IO.  The sync results are expected to be
    more stable.  The exception is tmpfs where the normal case is for the "IO"
    to not hit the disk.
    
    The test machine was single socket and UMA to avoid any scheduling or NUMA
    artifacts.  Throughput and wall times are presented for sync IO, only wall
    times are shown for async as the granularity reported by dd and the
    variability is unsuitable for comparison.  As async results were variable
    do to writback timings, I'm only reporting the maximum figures.  The sync
    results were stable enough to make the mean and stddev uninteresting.
    
    The performance results are reported based on a run with no profiling.
    Profile data is based on a separate run with oprofile running.
    
    async dd
                                        3.15.0-rc3            3.15.0-rc3
                                           vanilla           accessed-v2
    ext3    Max      elapsed     13.9900 (  0.00%)     11.5900 ( 17.16%)
    tmpfs	Max      elapsed      0.5100 (  0.00%)      0.4900 (  3.92%)
    btrfs   Max      elapsed     12.8100 (  0.00%)     12.7800 (  0.23%)
    ext4	Max      elapsed     18.6000 (  0.00%)     13.3400 ( 28.28%)
    xfs	Max      elapsed     12.5600 (  0.00%)      2.0900 ( 83.36%)
    
    The XFS figure is a bit strange as it managed to avoid a worst case by
    sheer luck but the average figures looked reasonable.
    
            samples percentage
    ext3       86107    0.9783  vmlinux-3.15.0-rc4-vanilla        mark_page_accessed
    ext3       23833    0.2710  vmlinux-3.15.0-rc4-accessed-v3r25 mark_page_accessed
    ext3        5036    0.0573  vmlinux-3.15.0-rc4-accessed-v3r25 init_page_accessed
    ext4       64566    0.8961  vmlinux-3.15.0-rc4-vanilla        mark_page_accessed
    ext4        5322    0.0713  vmlinux-3.15.0-rc4-accessed-v3r25 mark_page_accessed
    ext4        2869    0.0384  vmlinux-3.15.0-rc4-accessed-v3r25 init_page_accessed
    xfs        62126    1.7675  vmlinux-3.15.0-rc4-vanilla        mark_page_accessed
    xfs         1904    0.0554  vmlinux-3.15.0-rc4-accessed-v3r25 init_page_accessed
    xfs          103    0.0030  vmlinux-3.15.0-rc4-accessed-v3r25 mark_page_accessed
    btrfs      10655    0.1338  vmlinux-3.15.0-rc4-vanilla        mark_page_accessed
    btrfs       2020    0.0273  vmlinux-3.15.0-rc4-accessed-v3r25 init_page_accessed
    btrfs        587    0.0079  vmlinux-3.15.0-rc4-accessed-v3r25 mark_page_accessed
    tmpfs      59562    3.2628  vmlinux-3.15.0-rc4-vanilla        mark_page_accessed
    tmpfs       1210    0.0696  vmlinux-3.15.0-rc4-accessed-v3r25 init_page_accessed
    tmpfs         94    0.0054  vmlinux-3.15.0-rc4-accessed-v3r25 mark_page_accessed
    
    [akpm@linux-foundation.org: don't run init_page_accessed() against an uninitialised pointer]
    Signed-off-by: Mel Gorman <mgorman@suse.de>
    Cc: Johannes Weiner <hannes@cmpxchg.org>
    Cc: Vlastimil Babka <vbabka@suse.cz>
    Cc: Jan Kara <jack@suse.cz>
    Cc: Michal Hocko <mhocko@suse.cz>
    Cc: Hugh Dickins <hughd@google.com>
    Cc: Dave Hansen <dave.hansen@intel.com>
    Cc: Theodore Ts'o <tytso@mit.edu>
    Cc: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
    Cc: Oleg Nesterov <oleg@redhat.com>
    Cc: Rik van Riel <riel@redhat.com>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Tested-by: Prabhakar Lad <prabhakar.csengg@gmail.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Mel Gorman <mgorman@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 45f8d6eb309ebf1cb9d7ac30fb48d7aba7e8b15e
Author: Mel Gorman <mgorman@suse.de>
Date:   Wed Jun 4 16:10:29 2014 -0700

    fs: buffer: do not use unnecessary atomic operations when discarding buffers
    
    commit e7470ee89f003634a88e7b5e5a7b65b3025987de upstream.
    
    Discarding buffers uses a bunch of atomic operations when discarding
    buffers because ......  I can't think of a reason.  Use a cmpxchg loop to
    clear all the necessary flags.  In most (all?) cases this will be a single
    atomic operations.
    
    [akpm@linux-foundation.org: move BUFFER_FLAGS_DISCARD into the .c file]
    Signed-off-by: Mel Gorman <mgorman@suse.de>
    Cc: Johannes Weiner <hannes@cmpxchg.org>
    Cc: Vlastimil Babka <vbabka@suse.cz>
    Cc: Jan Kara <jack@suse.cz>
    Cc: Michal Hocko <mhocko@suse.cz>
    Cc: Hugh Dickins <hughd@google.com>
    Cc: Dave Hansen <dave.hansen@intel.com>
    Cc: Theodore Ts'o <tytso@mit.edu>
    Cc: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
    Cc: Oleg Nesterov <oleg@redhat.com>
    Cc: Rik van Riel <riel@redhat.com>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Mel Gorman <mgorman@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b09d8d5662e0f74339a10be3fb960e879828b925
Author: Mel Gorman <mgorman@suse.de>
Date:   Wed Jun 4 16:10:28 2014 -0700

    mm: do not use unnecessary atomic operations when adding pages to the LRU
    
    commit 6fb81a17d21f2a138b8f424af4cf379f2b694060 upstream.
    
    When adding pages to the LRU we clear the active bit unconditionally.
    As the page could be reachable from other paths we cannot use unlocked
    operations without risk of corruption such as a parallel
    mark_page_accessed.  This patch tests if is necessary to clear the
    active flag before using an atomic operation.  This potentially opens a
    tiny race when PageActive is checked as mark_page_accessed could be
    called after PageActive was checked.  The race already exists but this
    patch changes it slightly.  The consequence is that that the page may be
    promoted to the active list that might have been left on the inactive
    list before the patch.  It's too tiny a race and too marginal a
    consequence to always use atomic operations for.
    
    Signed-off-by: Mel Gorman <mgorman@suse.de>
    Acked-by: Johannes Weiner <hannes@cmpxchg.org>
    Cc: Vlastimil Babka <vbabka@suse.cz>
    Cc: Jan Kara <jack@suse.cz>
    Cc: Michal Hocko <mhocko@suse.cz>
    Cc: Hugh Dickins <hughd@google.com>
    Cc: Dave Hansen <dave.hansen@intel.com>
    Cc: Theodore Ts'o <tytso@mit.edu>
    Cc: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
    Cc: Oleg Nesterov <oleg@redhat.com>
    Cc: Rik van Riel <riel@redhat.com>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Mel Gorman <mgorman@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d065df14f73b74f173e2540591185a69e0a55749
Author: Mel Gorman <mgorman@suse.de>
Date:   Wed Jun 4 16:10:26 2014 -0700

    mm: do not use atomic operations when releasing pages
    
    commit e3741b506c5088fa8c911bb5884c430f770fb49d upstream.
    
    There should be no references to it any more and a parallel mark should
    not be reordered against us.  Use non-locked varient to clear page active.
    
    Signed-off-by: Mel Gorman <mgorman@suse.de>
    Acked-by: Rik van Riel <riel@redhat.com>
    Cc: Johannes Weiner <hannes@cmpxchg.org>
    Cc: Vlastimil Babka <vbabka@suse.cz>
    Cc: Jan Kara <jack@suse.cz>
    Cc: Michal Hocko <mhocko@suse.cz>
    Cc: Hugh Dickins <hughd@google.com>
    Cc: Dave Hansen <dave.hansen@intel.com>
    Cc: Theodore Ts'o <tytso@mit.edu>
    Cc: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
    Cc: Oleg Nesterov <oleg@redhat.com>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Mel Gorman <mgorman@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1183f6ad43ab12f33b01d39bd9e64655e9773e38
Author: Mel Gorman <mgorman@suse.de>
Date:   Wed Jun 4 16:10:24 2014 -0700

    mm: shmem: avoid atomic operation during shmem_getpage_gfp
    
    commit 07a427884348d38a6fd56fa4d78249c407196650 upstream.
    
    shmem_getpage_gfp uses an atomic operation to set the SwapBacked field
    before it's even added to the LRU or visible.  This is unnecessary as what
    could it possible race against?  Use an unlocked variant.
    
    Signed-off-by: Mel Gorman <mgorman@suse.de>
    Acked-by: Johannes Weiner <hannes@cmpxchg.org>
    Acked-by: Rik van Riel <riel@redhat.com>
    Cc: Vlastimil Babka <vbabka@suse.cz>
    Cc: Jan Kara <jack@suse.cz>
    Cc: Michal Hocko <mhocko@suse.cz>
    Cc: Hugh Dickins <hughd@google.com>
    Cc: Dave Hansen <dave.hansen@intel.com>
    Cc: Theodore Ts'o <tytso@mit.edu>
    Cc: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
    Cc: Oleg Nesterov <oleg@redhat.com>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Mel Gorman <mgorman@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ddfef57105382a49c9c38199b434dbced40797fa
Author: Mel Gorman <mgorman@suse.de>
Date:   Wed Jun 4 16:10:19 2014 -0700

    mm: page_alloc: lookup pageblock migratetype with IRQs enabled during free
    
    commit cfc47a2803db42140167b92d991ef04018e162c7 upstream.
    
    get_pageblock_migratetype() is called during free with IRQs disabled.
    This is unnecessary and disables IRQs for longer than necessary.
    
    Signed-off-by: Mel Gorman <mgorman@suse.de>
    Acked-by: Rik van Riel <riel@redhat.com>
    Cc: Johannes Weiner <hannes@cmpxchg.org>
    Acked-by: Vlastimil Babka <vbabka@suse.cz>
    Cc: Jan Kara <jack@suse.cz>
    Cc: Michal Hocko <mhocko@suse.cz>
    Cc: Hugh Dickins <hughd@google.com>
    Cc: Dave Hansen <dave.hansen@intel.com>
    Cc: Theodore Ts'o <tytso@mit.edu>
    Cc: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
    Cc: Oleg Nesterov <oleg@redhat.com>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Mel Gorman <mgorman@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5cfde3e59e6cbc3e5f894906559529efd04d869d
Author: Mel Gorman <mgorman@suse.de>
Date:   Wed Jun 4 16:10:22 2014 -0700

    mm: page_alloc: convert hot/cold parameter and immediate callers to bool
    
    commit b745bc85f21ea707e4ea1a91948055fa3e72c77b upstream.
    
    cold is a bool, make it one.  Make the likely case the "if" part of the
    block instead of the else as according to the optimisation manual this is
    preferred.
    
    Signed-off-by: Mel Gorman <mgorman@suse.de>
    Acked-by: Rik van Riel <riel@redhat.com>
    Cc: Johannes Weiner <hannes@cmpxchg.org>
    Cc: Vlastimil Babka <vbabka@suse.cz>
    Cc: Jan Kara <jack@suse.cz>
    Cc: Michal Hocko <mhocko@suse.cz>
    Cc: Hugh Dickins <hughd@google.com>
    Cc: Dave Hansen <dave.hansen@intel.com>
    Cc: Theodore Ts'o <tytso@mit.edu>
    Cc: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
    Cc: Oleg Nesterov <oleg@redhat.com>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Mel Gorman <mgorman@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 722191a52ad6b1c89ab89f98114f5d88c5578bfe
Author: Mel Gorman <mgorman@suse.de>
Date:   Wed Jun 4 16:10:17 2014 -0700

    mm: page_alloc: reduce number of times page_to_pfn is called
    
    commit dc4b0caff24d9b2918e9f27bc65499ee63187eba upstream.
    
    In the free path we calculate page_to_pfn multiple times. Reduce that.
    
    Signed-off-by: Mel Gorman <mgorman@suse.de>
    Acked-by: Rik van Riel <riel@redhat.com>
    Cc: Johannes Weiner <hannes@cmpxchg.org>
    Acked-by: Vlastimil Babka <vbabka@suse.cz>
    Cc: Jan Kara <jack@suse.cz>
    Cc: Michal Hocko <mhocko@suse.cz>
    Cc: Hugh Dickins <hughd@google.com>
    Cc: Dave Hansen <dave.hansen@intel.com>
    Cc: Theodore Ts'o <tytso@mit.edu>
    Cc: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
    Cc: Oleg Nesterov <oleg@redhat.com>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Mel Gorman <mgorman@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 89712aa0964866059f13be8f771fbd7df1766776
Author: Mel Gorman <mgorman@suse.de>
Date:   Wed Jun 4 16:10:21 2014 -0700

    mm: page_alloc: use unsigned int for order in more places
    
    commit 7aeb09f9104b760fc53c98cb7d20d06640baf9e6 upstream.
    
    X86 prefers the use of unsigned types for iterators and there is a
    tendency to mix whether a signed or unsigned type if used for page order.
    This converts a number of sites in mm/page_alloc.c to use unsigned int for
    order where possible.
    
    Signed-off-by: Mel Gorman <mgorman@suse.de>
    Acked-by: Rik van Riel <riel@redhat.com>
    Cc: Johannes Weiner <hannes@cmpxchg.org>
    Cc: Vlastimil Babka <vbabka@suse.cz>
    Cc: Jan Kara <jack@suse.cz>
    Cc: Michal Hocko <mhocko@suse.cz>
    Cc: Hugh Dickins <hughd@google.com>
    Cc: Dave Hansen <dave.hansen@intel.com>
    Cc: Theodore Ts'o <tytso@mit.edu>
    Cc: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
    Cc: Oleg Nesterov <oleg@redhat.com>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Mel Gorman <mgorman@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6a6d151242e4ae6b4988ff3fd10d808363f78784
Author: Mel Gorman <mgorman@suse.de>
Date:   Wed Jun 4 16:10:14 2014 -0700

    mm: page_alloc: take the ALLOC_NO_WATERMARK check out of the fast path
    
    commit 5dab29113ca56335c78be3f98bf5ddf2ef8eb6a6 upstream.
    
    ALLOC_NO_WATERMARK is set in a few cases.  Always by kswapd, always for
    __GFP_MEMALLOC, sometimes for swap-over-nfs, tasks etc.  Each of these
    cases are relatively rare events but the ALLOC_NO_WATERMARK check is an
    unlikely branch in the fast path.  This patch moves the check out of the
    fast path and after it has been determined that the watermarks have not
    been met.  This helps the common fast path at the cost of making the slow
    path slower and hitting kswapd with a performance cost.  It's a reasonable
    tradeoff.
    
    Signed-off-by: Mel Gorman <mgorman@suse.de>
    Acked-by: Johannes Weiner <hannes@cmpxchg.org>
    Reviewed-by: Rik van Riel <riel@redhat.com>
    Cc: Vlastimil Babka <vbabka@suse.cz>
    Cc: Jan Kara <jack@suse.cz>
    Cc: Michal Hocko <mhocko@suse.cz>
    Cc: Hugh Dickins <hughd@google.com>
    Cc: Dave Hansen <dave.hansen@intel.com>
    Cc: Theodore Ts'o <tytso@mit.edu>
    Cc: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
    Cc: Oleg Nesterov <oleg@redhat.com>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Mel Gorman <mgorman@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e1ca6f43c34e234f4d156a04ac340c28bb41b7db
Author: Mel Gorman <mgorman@suse.de>
Date:   Wed Jun 4 16:10:12 2014 -0700

    mm: page_alloc: only check the alloc flags and gfp_mask for dirty once
    
    commit a6e21b14f22041382e832d30deda6f26f37b1097 upstream.
    
    Currently it's calculated once per zone in the zonelist.
    
    Signed-off-by: Mel Gorman <mgorman@suse.de>
    Acked-by: Johannes Weiner <hannes@cmpxchg.org>
    Reviewed-by: Rik van Riel <riel@redhat.com>
    Cc: Vlastimil Babka <vbabka@suse.cz>
    Cc: Jan Kara <jack@suse.cz>
    Cc: Michal Hocko <mhocko@suse.cz>
    Cc: Hugh Dickins <hughd@google.com>
    Cc: Dave Hansen <dave.hansen@intel.com>
    Cc: Theodore Ts'o <tytso@mit.edu>
    Cc: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
    Cc: Oleg Nesterov <oleg@redhat.com>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Mel Gorman <mgorman@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 993afbb8f012326a5b7b881202a7611de37a6c57
Author: Mel Gorman <mgorman@suse.de>
Date:   Wed Jun 4 16:10:10 2014 -0700

    mm: page_alloc: only check the zone id check if pages are buddies
    
    commit d34c5fa06fade08a689fc171bf756fba2858ae73 upstream.
    
    A node/zone index is used to check if pages are compatible for merging
    but this happens unconditionally even if the buddy page is not free. Defer
    the calculation as long as possible. Ideally we would check the zone boundary
    but nodes can overlap.
    
    Signed-off-by: Mel Gorman <mgorman@suse.de>
    Acked-by: Johannes Weiner <hannes@cmpxchg.org>
    Acked-by: Rik van Riel <riel@redhat.com>
    Cc: Vlastimil Babka <vbabka@suse.cz>
    Cc: Jan Kara <jack@suse.cz>
    Cc: Michal Hocko <mhocko@suse.cz>
    Cc: Hugh Dickins <hughd@google.com>
    Cc: Dave Hansen <dave.hansen@intel.com>
    Cc: Theodore Ts'o <tytso@mit.edu>
    Cc: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
    Cc: Oleg Nesterov <oleg@redhat.com>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Mel Gorman <mgorman@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a5667128a33f8fffb738f3dc4b02ac80e3bafd21
Author: Mel Gorman <mgorman@suse.de>
Date:   Wed Jun 4 16:10:33 2014 -0700

    mm: page_alloc: calculate classzone_idx once from the zonelist ref
    
    commit d8846374a85f4290a473a4e2a64c1ba046c4a0e1 upstream.
    
    There is no need to calculate zone_idx(preferred_zone) multiple times
    or use the pgdat to figure it out.
    
    Signed-off-by: Mel Gorman <mgorman@suse.de>
    Acked-by: Rik van Riel <riel@redhat.com>
    Acked-by: David Rientjes <rientjes@google.com>
    Cc: Johannes Weiner <hannes@cmpxchg.org>
    Cc: Vlastimil Babka <vbabka@suse.cz>
    Cc: Jan Kara <jack@suse.cz>
    Cc: Michal Hocko <mhocko@suse.cz>
    Cc: Hugh Dickins <hughd@google.com>
    Cc: Dave Hansen <dave.hansen@intel.com>
    Cc: Theodore Ts'o <tytso@mit.edu>
    Cc: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
    Cc: Oleg Nesterov <oleg@redhat.com>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Mel Gorman <mgorman@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ab9f54b2d1589e20d6722ec5ecb359debf9f1fc7
Author: Mel Gorman <mgorman@suse.de>
Date:   Wed Jun 4 16:10:08 2014 -0700

    mm: page_alloc: use jump labels to avoid checking number_of_cpusets
    
    commit 664eeddeef6539247691197c1ac124d4aa872ab6 upstream.
    
    If cpusets are not in use then we still check a global variable on every
    page allocation.  Use jump labels to avoid the overhead.
    
    Signed-off-by: Mel Gorman <mgorman@suse.de>
    Reviewed-by: Rik van Riel <riel@redhat.com>
    Cc: Johannes Weiner <hannes@cmpxchg.org>
    Cc: Vlastimil Babka <vbabka@suse.cz>
    Cc: Jan Kara <jack@suse.cz>
    Cc: Michal Hocko <mhocko@suse.cz>
    Cc: Hugh Dickins <hughd@google.com>
    Cc: Dave Hansen <dave.hansen@intel.com>
    Cc: Theodore Ts'o <tytso@mit.edu>
    Cc: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
    Cc: Oleg Nesterov <oleg@redhat.com>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Stephen Rothwell <sfr@canb.auug.org.au>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Mel Gorman <mgorman@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7a0b5ca9ba11c70b7b960c7b3eedbbdd746d12a0
Author: Mel Gorman <mgorman@suse.de>
Date:   Wed Jun 4 16:10:07 2014 -0700

    include/linux/jump_label.h: expose the reference count
    
    commit ea5e9539abf1258f23e725cb9cb25aa74efa29eb upstream.
    
    This patch exposes the jump_label reference count in preparation for the
    next patch.  cpusets cares about both the jump_label being enabled and how
    many users of the cpusets there currently are.
    
    Signed-off-by: Peter Zijlstra <peterz@infradead.org>
    Signed-off-by: Mel Gorman <mgorman@suse.de>
    Cc: Johannes Weiner <hannes@cmpxchg.org>
    Cc: Vlastimil Babka <vbabka@suse.cz>
    Cc: Jan Kara <jack@suse.cz>
    Cc: Michal Hocko <mhocko@suse.cz>
    Cc: Hugh Dickins <hughd@google.com>
    Cc: Dave Hansen <dave.hansen@intel.com>
    Cc: Theodore Ts'o <tytso@mit.edu>
    Cc: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
    Cc: Oleg Nesterov <oleg@redhat.com>
    Cc: Rik van Riel <riel@redhat.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Mel Gorman <mgorman@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e937b98c04ea762d011f7d4a38ef500bba6875a5
Author: Mel Gorman <mgorman@suse.de>
Date:   Wed Jun 4 16:10:06 2014 -0700

    mm: page_alloc: do not treat a zone that cannot be used for dirty pages as "full"
    
    commit 800a1e750c7b04c2aa2459afca77e936e01c0029 upstream.
    
    If a zone cannot be used for a dirty page then it gets marked "full" which
    is cached in the zlc and later potentially skipped by allocation requests
    that have nothing to do with dirty zones.
    
    Signed-off-by: Mel Gorman <mgorman@suse.de>
    Acked-by: Johannes Weiner <hannes@cmpxchg.org>
    Reviewed-by: Rik van Riel <riel@redhat.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Mel Gorman <mgorman@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c9c1e5d1d2b69554b7c922c88a3b5a7e8c2207c4
Author: Mel Gorman <mgorman@suse.de>
Date:   Wed Jun 4 16:10:05 2014 -0700

    mm: page_alloc: do not update zlc unless the zlc is active
    
    commit 65bb371984d6a2c909244eb749e482bb40b72e36 upstream.
    
    The zlc is used on NUMA machines to quickly skip over zones that are full.
     However it is always updated, even for the first zone scanned when the
    zlc might not even be active.  As it's a write to a bitmap that
    potentially bounces cache line it's deceptively expensive and most
    machines will not care.  Only update the zlc if it was active.
    
    Signed-off-by: Mel Gorman <mgorman@suse.de>
    Acked-by: Johannes Weiner <hannes@cmpxchg.org>
    Reviewed-by: Rik van Riel <riel@redhat.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Mel Gorman <mgorman@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 83a1ac8aeb09007988ea2dc858e1827d0523ad2e
Author: Jianyu Zhan <nasa4836@gmail.com>
Date:   Wed Jun 4 16:07:31 2014 -0700

    mm/swap.c: clean up *lru_cache_add* functions
    
    commit 2329d3751b082b4fd354f334a88662d72abac52d upstream.
    
    In mm/swap.c, __lru_cache_add() is exported, but actually there are no
    users outside this file.
    
    This patch unexports __lru_cache_add(), and makes it static.  It also
    exports lru_cache_add_file(), as it is use by cifs and fuse, which can
    loaded as modules.
    
    Signed-off-by: Jianyu Zhan <nasa4836@gmail.com>
    Cc: Minchan Kim <minchan@kernel.org>
    Cc: Johannes Weiner <hannes@cmpxchg.org>
    Cc: Shaohua Li <shli@kernel.org>
    Cc: Bob Liu <bob.liu@oracle.com>
    Cc: Seth Jennings <sjenning@linux.vnet.ibm.com>
    Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
    Cc: Rafael Aquini <aquini@redhat.com>
    Cc: Mel Gorman <mgorman@suse.de>
    Acked-by: Rik van Riel <riel@redhat.com>
    Cc: Andrea Arcangeli <aarcange@redhat.com>
    Cc: Khalid Aziz <khalid.aziz@oracle.com>
    Cc: Christoph Hellwig <hch@lst.de>
    Reviewed-by: Zhang Yanfei <zhangyanfei@cn.fujitsu.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Mel Gorman <mgorman@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 94732f734786f4388aecf47e238b933fa779d61d
Author: Sjoerd Simons <sjoerd.simons@collabora.co.uk>
Date:   Mon Jan 19 23:07:09 2015 +0100

    mmc: sdhci: Don't signal the sdio irq if it's not setup
    
    [Not needed in newer kernels due to refactoring fixing this issue.]
    
    With 3.14.29 (and older kernels) some of my I.mx6 Sabrelite boards were
    crashing with the following oops:
    
      sdhci: Secure Digital Host Controller Interface driver
      sdhci: Copyright(c) Pierre Ossman
      sdhci-pltfm: SDHCI platform and OF driver helper
      sdhci-esdhc-imx 2198000.usdhc: could not get ultra high speed state, work on normal mode
      mmc0: no vqmmc regulator found
      mmc0: SDHCI controller on 2198000.usdhc [2198000.usdhc] using ADMA
      Unable to handle kernel NULL pointer dereference at virtual address 00000000
      pgd = c0004000
      [00000000] *pgd=00000000
      Internal error: Oops: 5 [#1] SMP ARM
      Modules linked in:
      CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.14.29 #1
      task: c08a7120 ti: c089c000 task.ti: c089c000
      PC is at wake_up_process+0x8/0x40
      LR is at sdhci_irq+0x748/0x9c4
    
    Full boot log can be found at:
      http://storage.kernelci.org/stable/v3.14.29/arm-multi_v7_defconfig/lab-collabora/boot-imx6q-sabrelite.html
    
    This happens if the sdhci interrupt status contains SDHCI_INT_CARD_INT,
    while the sdio irq was never setup.  This patch fixes that in a minimal
    way by checking if the sdio irq was setup.
    
    In more recent kernels this bug went away due to refactoring done by
    Russel King. So an alternative (potentially better?) fix for this patch
    is to cherrypick the following patches from a recent kernel:
    
    18258f7239a6 - genirq: Provide synchronize_hardirq()
    bf3b5ec66bd0 - mmc: sdio_irq: rework sdio irq handling
    41005003bcaf - mmc: sdhci: clean up interrupt handling
    781e989cf593 - mmc: sdhci: convert to new SDIO IRQ handling
    
    Signed-off-by: Sjoerd Simons <sjoerd.simons@collabora.co.uk>
    Cc: Russell King <linux@arm.linux.org.uk>
    Cc: Tyler Baker <tyler.baker@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0e03c6a8708bce57b06326208e494712f5543491
Author: Francesco Ruggeri <fruggeri@aristanetworks.com>
Date:   Fri Oct 10 13:09:53 2014 -0700

    tty: Fix pty master poll() after slave closes v2
    
    commit c4dc304677e8d566572c4738d95c48be150c6606 upstream.
    
    Commit f95499c3030f ("n_tty: Don't wait for buffer work in read() loop")
    introduces a race window where a pty master can be signalled that the pty
    slave was closed before all the data that the slave wrote is delivered.
    Commit f8747d4a466a ("tty: Fix pty master read() after slave closes") fixed the
    problem in case of n_tty_read, but the problem still exists for n_tty_poll.
    This can be seen by running 'for ((i=0; i<100;i++));do ./test.py ;done'
    where test.py is:
    
    import os, select, pty
    
    (pid, pty_fd) = pty.fork()
    
    if pid == 0:
       os.write(1, 'This string should be received by parent')
    else:
       poller = select.epoll()
       poller.register( pty_fd, select.EPOLLIN )
       ready = poller.poll( 1 * 1000 )
       for fd, events in ready:
          if not events & select.EPOLLIN:
             print 'missed POLLIN event'
          else:
             print os.read(fd, 100)
       poller.close()
    
    The string from the slave is missed several times.
    This patch takes the same approach as the fix for read and special cases
    this condition for poll.
    Tested on 3.16.
    
    Signed-off-by: Francesco Ruggeri <fruggeri@arista.com>
    Cc: Peter Hurley <peter@hurleysoftware.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit bb58e89d00af0644a87cd7c0f1392584238dc3e4
Author: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Date:   Mon Oct 6 10:55:49 2014 -0700

    Input: evdev - fix EVIOCG{type} ioctl
    
    commit 7c4f56070fde2367766fa1fb04852599b5e1ad35 upstream.
    
    The 'max' size passed into the function is measured in number of bits
    (KEY_MAX, LED_MAX, etc) so we need to convert it accordingly before trying
    to copy the data out, otherwise we will try copying too much and end up
    with up with a page fault.
    
    Reported-by: Pavel Machek <pavel@ucw.cz>
    Reviewed-by: Pavel Machek <pavel@ucw.cz>
    Reviewed-by: David Herrmann <dh.herrmann@gmail.com>
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7a079c1aabcf1e2cf3c5f2ffb493e26d2204450e
Author: Vineet Gupta <vgupta@synopsys.com>
Date:   Tue Jun 24 19:33:39 2014 +0530

    ARC: Fix build breakage for !CONFIG_ARC_DW2_UNWIND
    
    commit ba25915fb2cd18152cb14b144dbe8bf2f2bd8e45 upstream.
    
    Fixes: ec7ac6afd07b (ARC: switch to generic ENTRY/END assembler annotations)
    Reported-by: Anton Kolesov <akolesov@synopsys.com>
    Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c6aee0d0280bd4ff974a8d093010e8cb885f0f32
Author: Vineet Gupta <Vineet.Gupta1@synopsys.com>
Date:   Fri Apr 18 13:38:34 2014 +0530

    ARC: Delete stale barrier.h
    
    commit 64ee9f32c33cbd53545284742e73c17fedf9d429 upstream.
    
    Commit 93ea02bb8435 ("arch: Clean up asm/barrier.h implementations")
    wired generic barrier.h for ARC, but failed to delete the existing file.
    
    In 3.15, due to rcupdate.h updates, this causes a build breakage on ARC:
    
          CC      arch/arc/kernel/asm-offsets.s
        In file included from include/linux/sched.h:45:0,
                         from arch/arc/kernel/asm-offsets.c:9:
        include/linux/rculist.h: In function __list_add_rcu:
        include/linux/rculist.h:54:2: error: implicit declaration of function smp_store_release [-Werror=implicit-function-declaration]
          rcu_assign_pointer(list_next_rcu(prev), new);
          ^
    
    Cc: Peter Zijlstra <peterz@infradead.org>
    Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 85976492d2ae1659f9bf9c810c304822970a0c95
Author: Mathias Krause <minipli@googlemail.com>
Date:   Sun Jan 11 18:17:42 2015 +0100

    crypto: add missing crypto module aliases
    
    commit 3e14dcf7cb80b34a1f38b55bc96f02d23fdaaaaf upstream.
    
    Commit 5d26a105b5a7 ("crypto: prefix module autoloading with "crypto-"")
    changed the automatic module loading when requesting crypto algorithms
    to prefix all module requests with "crypto-". This requires all crypto
    modules to have a crypto specific module alias even if their file name
    would otherwise match the requested crypto algorithm.
    
    Even though commit 5d26a105b5a7 added those aliases for a vast amount of
    modules, it was missing a few. Add the required MODULE_ALIAS_CRYPTO
    annotations to those files to make them get loaded automatically, again.
    This fixes, e.g., requesting 'ecb(blowfish-generic)', which used to work
    with kernels v3.18 and below.
    
    Also change MODULE_ALIAS() lines to MODULE_ALIAS_CRYPTO(). The former
    won't work for crypto modules any more.
    
    Fixes: 5d26a105b5a7 ("crypto: prefix module autoloading with "crypto-"")
    Cc: Kees Cook <keescook@chromium.org>
    Signed-off-by: Mathias Krause <minipli@googlemail.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f6e8b55035cb1cc1b6ac054fbfed633177524362
Author: Kees Cook <keescook@chromium.org>
Date:   Mon Nov 24 16:32:38 2014 -0800

    crypto: include crypto- module prefix in template
    
    commit 4943ba16bbc2db05115707b3ff7b4874e9e3c560 upstream.
    
    This adds the module loading prefix "crypto-" to the template lookup
    as well.
    
    For example, attempting to load 'vfat(blowfish)' via AF_ALG now correctly
    includes the "crypto-" prefix at every level, correctly rejecting "vfat":
    
    	net-pf-38
    	algif-hash
    	crypto-vfat(blowfish)
    	crypto-vfat(blowfish)-all
    	crypto-vfat
    
    Reported-by: Mathias Krause <minipli@googlemail.com>
    Signed-off-by: Kees Cook <keescook@chromium.org>
    Acked-by: Mathias Krause <minipli@googlemail.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 31c8446aacd8595a9de61610b2625bcf84e1b7aa
Author: Kees Cook <keescook@chromium.org>
Date:   Thu Nov 20 17:05:53 2014 -0800

    crypto: prefix module autoloading with "crypto-"
    
    commit 5d26a105b5a73e5635eae0629b42fa0a90e07b7b upstream.
    
    This prefixes all crypto module loading with "crypto-" so we never run
    the risk of exposing module auto-loading to userspace via a crypto API,
    as demonstrated by Mathias Krause:
    
    https://lkml.org/lkml/2013/3/4/70
    
    Signed-off-by: Kees Cook <keescook@chromium.org>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ebdb44da666e70bbf8ab45b9d4d750bacab72a78
Author: Lars Ellenberg <lars.ellenberg@linbit.com>
Date:   Mon Nov 10 17:21:13 2014 +0100

    drbd: merge_bvec_fn: properly remap bvm->bi_bdev
    
    commit 3b9d35d744bb5139f9fed57f38c019bb8c7d351c upstream.
    
    This was not noticed for many years. Affects operation if
    md raid is used a backing device for DRBD.
    
    CC: stable@kernel.org # v3.2+
    Signed-off-by: Philipp Reisner <philipp.reisner@linbit.com>
    Signed-off-by: Lars Ellenberg <lars.ellenberg@linbit.com>
    Signed-off-by: Jens Axboe <axboe@fb.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 98047ad0dcb515a19dec0d9179ef3f7c0c0f3cee
Author: David Vrabel <david.vrabel@citrix.com>
Date:   Wed Dec 10 14:48:43 2014 +0000

    Revert "swiotlb-xen: pass dev_addr to swiotlb_tbl_unmap_single"
    
    commit dbdd74763f1faf799fbb9ed30423182e92919378 upstream.
    
    This reverts commit 2c3fc8d26dd09b9d7069687eead849ee81c78e46.
    
    This commit broke on x86 PV because entries in the generic SWIOTLB are
    indexed using (pseudo-)physical address not DMA address and these are
    not the same in a x86 PV guest.
    
    Signed-off-by: David Vrabel <david.vrabel@citrix.com>
    Reviewed-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0838c7fba01ddf0114d0a0b9ddd5f921c2370da9
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Sat Dec 6 16:49:24 2014 +0300

    ipvs: uninitialized data with IP_VS_IPV6
    
    commit 3b05ac3824ed9648c0d9c02d51d9b54e4e7e874f upstream.
    
    The app_tcp_pkt_out() function expects "*diff" to be set and ends up
    using uninitialized data if CONFIG_IP_VS_IPV6 is turned on.
    
    The same issue is there in app_tcp_pkt_in().  Thanks to Julian Anastasov
    for noticing that.
    
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Acked-by: Julian Anastasov <ja@ssi.bg>
    Signed-off-by: Simon Horman <horms@verge.net.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 15d25f97e23d65b62c4c99ea4769940fced9250d
Author: Pablo Neira Ayuso <pablo@netfilter.org>
Date:   Sun Jan 4 15:20:29 2015 +0100

    netfilter: nfnetlink: validate nfnetlink header from batch
    
    commit 9ea2aa8b7dba9e99544c4187cc298face254569f upstream.
    
    Make sure there is enough room for the nfnetlink header in the
    netlink messages that are part of the batch. There is a similar
    check in netlink_rcv_skb().
    
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit cf69173f59163182c12e0ecbda52721397468763
Author: Sasha Levin <sasha.levin@oracle.com>
Date:   Mon Dec 29 09:39:01 2014 -0500

    KEYS: close race between key lookup and freeing
    
    commit a3a8784454692dd72e5d5d34dcdab17b4420e74c upstream.
    
    When a key is being garbage collected, it's key->user would get put before
    the ->destroy() callback is called, where the key is removed from it's
    respective tracking structures.
    
    This leaves a key hanging in a semi-invalid state which leaves a window open
    for a different task to try an access key->user. An example is
    find_keyring_by_name() which would dereference key->user for a key that is
    in the process of being garbage collected (where key->user was freed but
    ->destroy() wasn't called yet - so it's still present in the linked list).
    
    This would cause either a panic, or corrupt memory.
    
    Fixes CVE-2014-9529.
    
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
    Signed-off-by: David Howells <dhowells@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 065566a604b11aa93d7bae59e8c053d2cf1a91f5
Author: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Date:   Wed Jan 7 15:24:19 2015 +0200

    sata_dwc_460ex: fix resource leak on error path
    
    commit 4aaa71873ddb9faf4b0c4826579e2f6d18ff9ab4 upstream.
    
    DMA mapped IO should be unmapped on the error path in probe() and
    unconditionally on remove().
    
    Fixes: 62936009f35a ([libata] Add 460EX on-chip SATA driver, sata_dwc_460ex)
    Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
    Signed-off-by: Tejun Heo <tj@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit aaef7ece8199e21a21ed4f5d065044cd1ce37f81
Author: Andy Lutomirski <luto@amacapital.net>
Date:   Mon Nov 24 17:39:06 2014 -0800

    x86/asm/traps: Disable tracing and kprobes in fixup_bad_iret and sync_regs
    
    commit 7ddc6a2199f1da405a2fb68c40db8899b1a8cd87 upstream.
    
    These functions can be executed on the int3 stack, so kprobes
    are dangerous. Tracing is probably a bad idea, too.
    
    Fixes: b645af2d5905 ("x86_64, traps: Rework bad_iret")
    Signed-off-by: Andy Lutomirski <luto@amacapital.net>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Steven Rostedt <rostedt@goodmis.org>
    Link: http://lkml.kernel.org/r/50e33d26adca60816f3ba968875801652507d0c4.1416870125.git.luto@amacapital.net
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    [bwh: Backported to 3.10:
     - Use __kprobes instead of NOKPROBE_SYMBOL()
     - Adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 252f71a8d49ff96ba626376306a6eb18b57b2f65
Author: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Date:   Thu Jan 22 22:58:49 2015 +0000

    x86/apic: Re-enable PCI_MSI support for non-SMP X86_32
    
    commit 38a1dfda8e77d7ba74c94d06d8bc41ba98a4bc8c upstream.
    
    Commit 0dbc6078c06bc0 ('x86, build, pci: Fix PCI_MSI build on !SMP')
    introduced the dependency that X86_UP_APIC is only available when
    PCI_MSI is false. This effectively prevents PCI_MSI support on 32bit
    UP systems because it disables both APIC and IO-APIC. But APIC support
    is architecturally required for PCI_MSI.
    
    The intention of the patch was to enforce APIC support when PCI_MSI is
    enabled, but failed to do so.
    
    Remove the !PCI_MSI dependency from X86_UP_APIC and enforce
    X86_UP_APIC when PCI_MSI support is enabled on 32bit UP systems.
    
    [ tglx: Massaged changelog ]
    
    Fixes 0dbc6078c06bc0 'x86, build, pci: Fix PCI_MSI build on !SMP'
    Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
    Suggested-by: Thomas Gleixner <tglx@linutronix.de>
    Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
    Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
    Link: http://lkml.kernel.org/r/1421967529-9037-1-git-send-email-pure.logic@nexus-software.ie
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 83df3d59f5b53a66adf67569d0689aeb5706bf13
Author: Andy Lutomirski <luto@amacapital.net>
Date:   Thu Jan 22 11:27:59 2015 -0800

    x86, tls: Interpret an all-zero struct user_desc as "no segment"
    
    commit 3669ef9fa7d35f573ec9c0e0341b29251c2734a7 upstream.
    
    The Witcher 2 did something like this to allocate a TLS segment index:
    
            struct user_desc u_info;
            bzero(&u_info, sizeof(u_info));
            u_info.entry_number = (uint32_t)-1;
    
            syscall(SYS_set_thread_area, &u_info);
    
    Strictly speaking, this code was never correct.  It should have set
    read_exec_only and seg_not_present to 1 to indicate that it wanted
    to find a free slot without putting anything there, or it should
    have put something sensible in the TLS slot if it wanted to allocate
    a TLS entry for real.  The actual effect of this code was to
    allocate a bogus segment that could be used to exploit espfix.
    
    The set_thread_area hardening patches changed the behavior, causing
    set_thread_area to return -EINVAL and crashing the game.
    
    This changes set_thread_area to interpret this as a request to find
    a free slot and to leave it empty, which isn't *quite* what the game
    expects but should be close enough to keep it working.  In
    particular, using the code above to allocate two segments will
    allocate the same segment both times.
    
    According to FrostbittenKing on Github, this fixes The Witcher 2.
    
    If this somehow still causes problems, we could instead allocate
    a limit==0 32-bit data segment, but that seems rather ugly to me.
    
    Fixes: 41bdc78544b8 x86/tls: Validate TLS entries to protect espfix
    Signed-off-by: Andy Lutomirski <luto@amacapital.net>
    Cc: torvalds@linux-foundation.org
    Link: http://lkml.kernel.org/r/0cb251abe1ff0958b8e468a9a9a905b80ae3a746.1421954363.git.luto@amacapital.net
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1fe84f910afa365b64a8c210f3a2dd68a001c7d3
Author: Andy Lutomirski <luto@amacapital.net>
Date:   Thu Jan 22 11:27:58 2015 -0800

    x86, tls, ldt: Stop checking lm in LDT_empty
    
    commit e30ab185c490e9a9381385529e0fd32f0a399495 upstream.
    
    32-bit programs don't have an lm bit in their ABI, so they can't
    reliably cause LDT_empty to return true without resorting to memset.
    They shouldn't need to do this.
    
    This should fix a longstanding, if minor, issue in all 64-bit kernels
    as well as a potential regression in the TLS hardening code.
    
    Fixes: 41bdc78544b8 x86/tls: Validate TLS entries to protect espfix
    Signed-off-by: Andy Lutomirski <luto@amacapital.net>
    Cc: torvalds@linux-foundation.org
    Link: http://lkml.kernel.org/r/72a059de55e86ad5e2935c80aa91880ddf19d07c.1421954363.git.luto@amacapital.net
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0f5e12ba20bf7f95d7f1b65b44a3689223230acb
Author: Kees Cook <keescook@chromium.org>
Date:   Thu Jan 15 16:51:46 2015 -0800

    x86, boot: Skip relocs when load address unchanged
    
    commit f285f4a21c3253887caceed493089ece17579d59 upstream.
    
    On 64-bit, relocation is not required unless the load address gets
    changed. Without this, relocations do unexpected things when the kernel
    is above 4G.
    
    Reported-by: Baoquan He <bhe@redhat.com>
    Signed-off-by: Kees Cook <keescook@chromium.org>
    Tested-by: Thomas D. <whissi@whissi.de>
    Cc: Vivek Goyal <vgoyal@redhat.com>
    Cc: Jan Beulich <JBeulich@suse.com>
    Cc: Junjie Mao <eternal.n08@gmail.com>
    Cc: Andi Kleen <ak@linux.intel.com>
    Link: http://lkml.kernel.org/r/20150116005146.GA4212@www.outflux.net
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 16107331facdb20497adbdb99088ebd0bfc9176e
Author: Alexandre Demers <alexandre.f.demers@gmail.com>
Date:   Tue Dec 9 01:27:50 2014 -0500

    x86/tsc: Change Fast TSC calibration failed from error to info
    
    commit 520452172e6b318f3a8bd9d4fe1e25066393de25 upstream.
    
    Many users see this message when booting without knowning that it is
    of no importance and that TSC calibration may have succeeded by
    another way.
    
    As explained by Paul Bolle in
    http://lkml.kernel.org/r/1348488259.1436.22.camel@x61.thuisdomein
    
      "Fast TSC calibration failed" should not be considered as an error
      since other calibration methods are being tried afterward. At most,
      those send a warning if they fail (not an error). So let's change
      the message from error to warning.
    
    [ tglx: Make if pr_info. It's really not important at all ]
    
    Fixes: c767a54ba065 x86/debug: Add KERN_<LEVEL> to bare printks, convert printks to pr_<level>
    Signed-off-by: Alexandre Demers <alexandre.f.demers@gmail.com>
    Link: http://lkml.kernel.org/r/1418106470-6906-1-git-send-email-alexandre.f.demers@gmail.com
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 10ee480d03d54dbdf38a82711ab58baee9df3e80
Author: K. Y. Srinivasan <kys@microsoft.com>
Date:   Mon Jan 12 16:26:02 2015 -0800

    x86, hyperv: Mark the Hyper-V clocksource as being continuous
    
    commit 32c6590d126836a062b3140ed52d898507987017 upstream.
    
    The Hyper-V clocksource is continuous; mark it accordingly.
    
    Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
    Acked-by: jasowang@redhat.com
    Cc: gregkh@linuxfoundation.org
    Cc: devel@linuxdriverproject.org
    Cc: olaf@aepfle.de
    Cc: apw@canonical.com
    Link: http://lkml.kernel.org/r/1421108762-3331-1-git-send-email-kys@microsoft.com
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0cbcd35fe591013cac84bcff3a740b1aa0a30008
Author: Tobias Jakobi <tjakobi@math.uni-bielefeld.de>
Date:   Wed Oct 22 03:37:08 2014 +0200

    clocksource: exynos_mct: Fix bitmask regression for exynos4_mct_write
    
    commit 8c38d28ba8da98f7102c31d35359b4dbe9d1f329 upstream.
    
    EXYNOS4_MCT_L_MASK is defined as 0xffffff00, so applying this bitmask
    produces a number outside the range 0x00 to 0xff, which always results
    in execution of the default switch statement.
    
    Obviously this is wrong and git history shows that the bitmask inversion
    was incorrectly set during a refactoring of the MCT code.
    
    Fix this by putting the inversion at the correct position again.
    
    Acked-by: Kukjin Kim <kgene.kim@samsung.com>
    Reported-by: GP Orcullo <kinsamanka@gmail.com>
    Reviewed-by: Doug Anderson <dianders@chromium.org>
    Signed-off-by: Tobias Jakobi <tjakobi@math.uni-bielefeld.de>
    Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8d01cc87a9a660ed7de390350d414515f5429a50
Author: Oliver Hartkopp <socketcan@hartkopp.net>
Date:   Mon Jan 5 18:40:15 2015 +0100

    can: dev: fix crtlmode_supported check
    
    commit 9b1087aa5e86448fe6ad40a58964e35f3ba423d5 upstream.
    
    When changing flags in the CAN drivers ctrlmode the provided new content has to
    be checked whether the bits are allowed to be changed. The bits that are to be
    changed are given as a bitfield in cm->mask. Therefore checking against
    cm->flags is wrong as the content can hold any kind of values.
    
    The iproute2 tool sets the bits in cm->mask and cm->flags depending on the
    detected command line options. To be robust against bogus user space
    applications additionally sanitize the provided flags with the provided mask.
    
    Cc: Wolfgang Grandegger <wg@grandegger.com>
    Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
    Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ba7883e486bebfbba41608b1ef2da6a6da672e1a
Author: Al Viro <viro@zeniv.linux.org.uk>
Date:   Sun Jan 18 23:37:32 2015 -0500

    fix deadlock in cifs_ioctl_clone()
    
    commit 378ff1a53b5724f3ac97b0aba3c9ecac072f6fcd upstream.
    
    It really needs to check that src is non-directory *and* use
    {un,}lock_two_nodirectories().  As it is, it's trivial to cause
    double-lock (ioctl(fd, CIFS_IOC_COPYCHUNK_FILE, fd)) and if the
    last argument is an fd of directory, we are asking for trouble
    by violating the locking order - all directories go before all
    non-directories.  If the last argument is an fd of parent
    directory, it has 50% odds of locking child before parent,
    which will cause AB-BA deadlock if we race with unlink().
    
    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit edecb42f3408f1f95bfa7ed96f6a69859ba12f4c
Author: Andrew Lunn <andrew@lunn.ch>
Date:   Sun Jan 18 09:46:10 2015 -0600

    bus: mvebu-mbus: fix support of MBus window 13
    
    commit 38bdf45f4aa5cb6186d50a29e6cbbd9d486a1519 upstream.
    
    On Armada XP, 375 and 38x the MBus window 13 has the remap capability,
    like windows 0 to 7. However, the mvebu-mbus driver isn't currently
    taking into account this special case, which means that when window 13
    is actually used, the remap registers are left to 0, making the device
    using this MBus window unavailable.
    
    As a minimal fix for stable, don't use window 13. A full fix will
    follow later.
    
    Fixes: fddddb52a6c ("bus: introduce an Marvell EBU MBus driver")
    Reviewed-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
    Signed-off-by: Andrew Lunn <andrew@lunn.ch>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e3143069ec2bd188b6c2f958cb74eeb6a22f341f
Author: Fabio Estevam <fabio.estevam@freescale.com>
Date:   Wed Jan 14 11:11:03 2015 -0200

    ARM: dts: imx25: Fix PWM "per" clocks
    
    commit 7ecd0bde5bfea524a843ad8fa8cb66ccbce68779 upstream.
    
    Currently PWM functionality is broken on mx25 due to the wrong assignment of the
    PWM "per" clock.
    
    According to Documentation/devicetree/bindings/clock/imx25-clock.txt:
    	pwm_ipg_per		52
    
    ,so update the pwm "per" to use 'pwm_ipg_per' instead of 'per10' clock.
    
    With this change PWM can work fine on mx25.
    
    Reported-by: Carlos Soto <csotoalonso@gmail.com>
    Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
    Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 09ee0cd0c2072c353bc3c096b36267bfeb0a8a9f
Author: Sasha Levin <sasha.levin@oracle.com>
Date:   Wed Dec 3 19:25:05 2014 -0500

    time: adjtimex: Validate the ADJ_FREQUENCY values
    
    commit 5e5aeb4367b450a28f447f6d5ab57d8f2ab16a5f upstream.
    
    Verify that the frequency value from userspace is valid and makes sense.
    
    Unverified values can cause overflows later on.
    
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
    [jstultz: Fix up bug for negative values and drop redunent cap check]
    Signed-off-by: John Stultz <john.stultz@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5fea291eddb2b2721874c860783e0516df3ad699
Author: Sasha Levin <sasha.levin@oracle.com>
Date:   Wed Dec 3 19:22:48 2014 -0500

    time: settimeofday: Validate the values of tv from user
    
    commit 6ada1fc0e1c4775de0e043e1bd3ae9d065491aa5 upstream.
    
    An unvalidated user input is multiplied by a constant, which can result in
    an undefined behaviour for large values. While this is validated later,
    we should avoid triggering undefined behaviour.
    
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
    [jstultz: include trivial milisecond->microsecond correction noticed
    by Andy]
    Signed-off-by: John Stultz <john.stultz@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ba42a61e500b1619c4f29cd2b6ac693c0ecc9645
Author: Joe Thornber <ejt@redhat.com>
Date:   Fri Jan 23 10:16:16 2015 +0000

    dm cache: fix problematic dual use of a single migration count variable
    
    commit a59db67656021fa212e9b95a583f13c34eb67cd9 upstream.
    
    Introduce a new variable to count the number of allocated migration
    structures.  The existing variable cache->nr_migrations became
    overloaded.  It was used to:
    
     i) track of the number of migrations in flight for the purposes of
        quiescing during suspend.
    
     ii) to estimate the amount of background IO occuring.
    
    Recent discard changes meant that REQ_DISCARD bios are processed with
    a migration.  Discards are not background IO so nr_migrations was not
    incremented.  However this could cause quiescing to complete early.
    
    (i) is now handled with a new variable cache->nr_allocated_migrations.
    cache->nr_migrations has been renamed cache->nr_io_migrations.
    cleanup_migration() is now called free_io_migration(), since it
    decrements that variable.
    
    Also, remove the unused cache->next_migration variable that got replaced
    with with prealloc_structs a while ago.
    
    Signed-off-by: Joe Thornber <ejt@redhat.com>
    Signed-off-by: Mike Snitzer <snitzer@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 90e6c435b7f08718f7c5394bd18c42355ac70ec2
Author: Joe Thornber <ejt@redhat.com>
Date:   Fri Jan 23 10:00:07 2015 +0000

    dm cache: share cache-metadata object across inactive and active DM tables
    
    commit 9b1cc9f251affdd27f29fe46d0989ba76c33faf6 upstream.
    
    If a DM table is reloaded with an inactive table when the device is not
    suspended (normal procedure for LVM2), then there will be two dm-bufio
    objects that can diverge.  This can lead to a situation where the
    inactive table uses bufio to read metadata at the same time the active
    table writes metadata -- resulting in the inactive table having stale
    metadata buffers once it is promoted to the active table slot.
    
    Fix this by using reference counting and a global list of cache metadata
    objects to ensure there is only one metadata object per metadata device.
    
    Signed-off-by: Joe Thornber <ejt@redhat.com>
    Signed-off-by: Mike Snitzer <snitzer@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e614e0c6e088c4066b3118a8c1d228b54fff33fb
Author: Brian King <brking@linux.vnet.ibm.com>
Date:   Thu Oct 30 17:27:10 2014 -0500

    ipr: wait for aborted command responses
    
    commit 6cdb08172bc89f0a39e1643c5e7eab362692fd1b upstream.
    
    Fixes a race condition in abort handling that was injected
    when multiple interrupt support was added. When only a single
    interrupt is present, the adapter guarantees it will send
    responses for aborted commands prior to the response for the
    abort command itself. With multiple interrupts, these responses
    generally come back on different interrupts, so we need to
    ensure the abort thread waits until the aborted command is
    complete so we don't perform a double completion. This race
    condition was being hit frequently in environments which
    were triggering command timeouts, which was resulting in
    a double completion causing a kernel oops.
    
    Signed-off-by: Brian King <brking@linux.vnet.ibm.com>
    Reviewed-by: Wendy Xiong <wenxiong@linux.vnet.ibm.com>
    Tested-by: Wendy Xiong <wenxiong@linux.vnet.ibm.com>
    Signed-off-by: Christoph Hellwig <hch@lst.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4de16a49e7fbdec6f54387a34b21b531ee41dd0f
Author: Alex Williamson <alex.williamson@redhat.com>
Date:   Thu Jan 15 18:17:12 2015 -0600

    PCI: Mark Atheros AR93xx to avoid bus reset
    
    commit c3e59ee4e76686b0c84ca8faa1011d10cd4ca1b8 upstream.
    
    Reports against the TL-WDN4800 card indicate that PCI bus reset of this
    Atheros device cause system lock-ups and resets.  I've also been able to
    confirm this behavior on multiple systems.  The device never returns from
    reset and attempts to access config space of the device after reset result
    in hangs.  Blacklist bus reset for the device to avoid this issue.
    
    [bhelgaas: This regression appeared in v3.14.  Andreas bisected it to
    425c1b223dac ("PCI: Add Virtual Channel to save/restore support"), but we
    don't understand the mechanism by which that commit affects the reset
    path.]
    
    [bhelgaas: changelog, references]
    Link: http://lkml.kernel.org/r/20140923210318.498dacbd@dualc.maya.org
    Reported-by: Andreas Hartmann <andihartmann@freenet.de>
    Tested-by: Andreas Hartmann <andihartmann@freenet.de>
    Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 408f4508ec06f940450603a6782f370df1a048a2
Author: Alex Williamson <alex.williamson@redhat.com>
Date:   Thu Jan 15 18:16:04 2015 -0600

    PCI: Add flag for devices where we can't use bus reset
    
    commit f331a859e0ee5a898c1f47596eddad4c4f02d657 upstream.
    
    Enable a mechanism for devices to quirk that they do not behave when
    doing a PCI bus reset.  We require a modest level of spec compliant
    behavior in order to do a reset, for instance the device should come
    out of reset without throwing errors and PCI config space should be
    accessible after reset.  This is too much to ask for some devices.
    
    Link: http://lkml.kernel.org/r/20140923210318.498dacbd@dualc.maya.org
    Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fdb1698eadff17e6b2f48281084955ec08b25e1c
Author: Alex Deucher <alexander.deucher@amd.com>
Date:   Thu Jan 15 10:52:33 2015 -0500

    drm/radeon: use rv515_ring_start on r5xx
    
    commit d8a74e186949e1a2c2f1309212478b0659bf9225 upstream.
    
    This was accidently lost in 76a0df859def.
    
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4caa38ee4ea1193820385016ae1c0c81f23583ee
Author: Alex Deucher <alexander.deucher@amd.com>
Date:   Mon Jan 12 17:15:12 2015 -0500

    drm/radeon: add si dpm quirk list
    
    commit 5615f890bc6babdc2998dec62f3552326d06eb7b upstream.
    
    This adds a quirks list to fix stability problems with
    certain SI boards.
    
    bug:
    https://bugs.freedesktop.org/show_bug.cgi?id=76490
    
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 563f9a6244ab90aaa31e12cab6c958bd3d406b0b
Author: Alex Deucher <alexander.deucher@amd.com>
Date:   Thu Jan 8 10:46:33 2015 -0500

    drm/radeon: add a dpm quirk list
    
    commit 4369a69ec6ab86821352bd753c68af5880f87956 upstream.
    
    Disable dpm on certain problematic boards rather than
    disabling dpm for the entire chip family since most
    boards work fine.
    
    https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1386534
    https://bugzilla.kernel.org/show_bug.cgi?id=83731
    
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 20ad9d37cfbfdfe594d1d1da55f8c2a367f410d8
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Fri Jan 2 09:47:10 2015 +0000

    drm/i915: Fix mutex->owner inspection race under DEBUG_MUTEXES
    
    commit 226e5ae9e5f9108beb0bde4ac69f68fe6210fed9 upstream.
    
    If CONFIG_DEBUG_MUTEXES is set, the mutex->owner field is only cleared
    if the mutex debugging is enabled which introduces a race in our
    mutex_is_locked_by() - i.e. we may inspect the old owner value before it
    is acquired by the new task.
    
    This is the root cause of this error:
    
    # diff --git a/kernel/locking/mutex-debug.c b/kernel/locking/mutex-debug.c
    # index 5cf6731..3ef3736 100644
    # --- a/kernel/locking/mutex-debug.c
    # +++ b/kernel/locking/mutex-debug.c
    # @@ -80,13 +80,13 @@ void debug_mutex_unlock(struct mutex *lock)
    # 			DEBUG_LOCKS_WARN_ON(lock->owner != current);
    #
    # 		DEBUG_LOCKS_WARN_ON(!lock->wait_list.prev && !lock->wait_list.next);
    # -		mutex_clear_owner(lock);
    # 	}
    #
    # 	/*
    # 	 * __mutex_slowpath_needs_to_unlock() is explicitly 0 for debug
    # 	 * mutexes so that we can do it here after we've verified state.
    # 	 */
    # +	mutex_clear_owner(lock);
    # 	atomic_set(&lock->count, 1);
    #  }
    
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=87955
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
    Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
    Signed-off-by: Jani Nikula <jani.nikula@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit eb2a7a2c3c611967c9a6dec19d8a3f91204db079
Author: Michael Karcher <kernel@mkarcher.dialup.fu-berlin.de>
Date:   Sun Jan 18 00:36:15 2015 +0100

    scripts/recordmcount.pl: There is no -m32 gcc option on Super-H anymore
    
    commit 1caf6aaaa47471831d77c75f094d4e00ad1ec808 upstream.
    
    Compiling SH with gcc-4.8 fails due to the -m32 option not being
    supported.
    
    From http://buildd.debian-ports.org/status/fetch.php?pkg=linux&arch=sh4&ver=3.16.7-ckt4-1&stamp=1421425783
    
          CC      init/main.o
        gcc-4.8: error: unrecognized command line option '-m32'
        ld: cannot find init/.tmp_mc_main.o: No such file or directory
        objcopy: 'init/.tmp_mx_main.o': No such file
        rm: cannot remove 'init/.tmp_mx_main.o': No such file or directory
        rm: cannot remove 'init/.tmp_mc_main.o': No such file or directory
    
    Link: http://lkml.kernel.org/r/1421537778-29001-1-git-send-email-kernel@mkarcher.dialup.fu-berlin.de
    Link: http://lkml.kernel.org/r/54BCBDD4.10102@physik.fu-berlin.de
    
    Cc: Matt Fleming <matt@console-pimps.org>
    Reported-by: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
    Signed-off-by: Michael Karcher <kernel@mkarcher.dialup.fu-berlin.de>
    Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 01680bc55fcfc8269b0afa62d4f812ee870af5c6
Author: Jason Lee Cragg <jcragg@gmail.com>
Date:   Sat Jan 17 12:28:29 2015 -0500

    ALSA: usb-audio: Add mic volume fix quirk for Logitech Webcam C210
    
    commit 6455931186bff407493135e74c5f32efd30860e2 upstream.
    
    Signed-off-by: Jason Lee Cragg <jcragg@gmail.com>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3142f62b91e4f8932809b18f8413141fd9b5cba0
Author: David Jeffery <djeffery@redhat.com>
Date:   Mon Jan 19 13:03:25 2015 -0600

    libata: prevent HSM state change race between ISR and PIO
    
    commit ce7514526742c0898b837d4395f515b79dfb5a12 upstream.
    
    It is possible for ata_sff_flush_pio_task() to set ap->hsm_task_state to
    HSM_ST_IDLE in between the time __ata_sff_port_intr() checks for HSM_ST_IDLE
    and before it calls ata_sff_hsm_move() causing ata_sff_hsm_move() to BUG().
    
    This problem is hard to reproduce making this patch hard to verify, but this
    fix will prevent the race.
    
    I have not been able to reproduce the problem, but here is a crash dump from
    a 2.6.32 kernel.
    
    On examining the ata port's state, its hsm_task_state field has a value of HSM_ST_IDLE:
    
    crash> struct ata_port.hsm_task_state ffff881c1121c000
      hsm_task_state = 0
    
    Normally, this should not be possible as ata_sff_hsm_move() was called from ata_sff_host_intr(),
    which checks hsm_task_state and won't call ata_sff_hsm_move() if it has a HSM_ST_IDLE value.
    
    PID: 11053  TASK: ffff8816e846cae0  CPU: 0   COMMAND: "sshd"
     #0 [ffff88008ba03960] machine_kexec at ffffffff81038f3b
     #1 [ffff88008ba039c0] crash_kexec at ffffffff810c5d92
     #2 [ffff88008ba03a90] oops_end at ffffffff8152b510
     #3 [ffff88008ba03ac0] die at ffffffff81010e0b
     #4 [ffff88008ba03af0] do_trap at ffffffff8152ad74
     #5 [ffff88008ba03b50] do_invalid_op at ffffffff8100cf95
     #6 [ffff88008ba03bf0] invalid_op at ffffffff8100bf9b
        [exception RIP: ata_sff_hsm_move+317]
        RIP: ffffffff813a77ad  RSP: ffff88008ba03ca0  RFLAGS: 00010097
        RAX: 0000000000000000  RBX: ffff881c1121dc60  RCX: 0000000000000000
        RDX: ffff881c1121dd10  RSI: ffff881c1121dc60  RDI: ffff881c1121c000
        RBP: ffff88008ba03d00   R8: 0000000000000000   R9: 000000000000002e
        R10: 000000000001003f  R11: 000000000000009b  R12: ffff881c1121c000
        R13: 0000000000000000  R14: 0000000000000050  R15: ffff881c1121dd78
        ORIG_RAX: ffffffffffffffff  CS: 0010  SS: 0018
     #7 [ffff88008ba03d08] ata_sff_host_intr at ffffffff813a7fbd
     #8 [ffff88008ba03d38] ata_sff_interrupt at ffffffff813a821e
     #9 [ffff88008ba03d78] handle_IRQ_event at ffffffff810e6ec0

commit 2f5a82124eaeb9d55f1a27a9c1747d86d67a29bc
Author: Jim Lin <jilin@nvidia.com>
Date:   Thu Jan 8 20:25:05 2015 +0800

    pinctrl: Fix two deadlocks
    
    commit db93facfb0ef542aa5d8079e47580b3e669a4d82 upstream.
    
    This patch is to fix two deadlock cases.
    Deadlock 1:
    CPU #1
     pinctrl_register-> pinctrl_get ->
     create_pinctrl
     (Holding lock pinctrl_maps_mutex)
     -> get_pinctrl_dev_from_devname
     (Trying to acquire lock pinctrldev_list_mutex)
    CPU #0
     pinctrl_unregister
     (Holding lock pinctrldev_list_mutex)
     -> pinctrl_put ->> pinctrl_free ->
     pinctrl_dt_free_maps -> pinctrl_unregister_map
     (Trying to acquire lock pinctrl_maps_mutex)
    
    Simply to say
    CPU#1 is holding lock A and trying to acquire lock B,
    CPU#0 is holding lock B and trying to acquire lock A.
    
    Deadlock 2:
    CPU #3
     pinctrl_register-> pinctrl_get ->
     create_pinctrl
     (Holding lock pinctrl_maps_mutex)
     -> get_pinctrl_dev_from_devname
     (Trying to acquire lock pinctrldev_list_mutex)
    CPU #2
     pinctrl_unregister
     (Holding lock pctldev->mutex)
     -> pinctrl_put ->> pinctrl_free ->
     pinctrl_dt_free_maps -> pinctrl_unregister_map
     (Trying to acquire lock pinctrl_maps_mutex)
    CPU #0
     tegra_gpio_request
     (Holding lock pinctrldev_list_mutex)
     -> pinctrl_get_device_gpio_range
     (Trying to acquire lock pctldev->mutex)
    
    Simply to say
    CPU#3 is holding lock A and trying to acquire lock D,
    CPU#2 is holding lock B and trying to acquire lock A,
    CPU#0 is holding lock D and trying to acquire lock B.
    
    Signed-off-by: Jim Lin <jilin@nvidia.com>
    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ff82fa873154bc596616600f53dcb960996a48e6
Author: Johan Hovold <johan@kernel.org>
Date:   Tue Jan 13 13:00:05 2015 +0100

    gpio: sysfs: fix gpio device-attribute leak
    
    commit 0915e6feb38de8d3601819992a5bd050201a56fa upstream.
    
    The gpio device attributes were never destroyed when the gpio was
    unexported (or on export failures).
    
    Use device_create_with_groups() to create the default device attributes
    of the gpio class device. Note that this also fixes the
    attribute-creation race with userspace for these attributes.
    
    Remove contingent attributes in export error path and on unexport.
    
    Fixes: d8f388d8dc8d ("gpio: sysfs interface")
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8345de68658e052faf769e5d33ea3ca2db43a49b
Author: Johan Hovold <johan@kernel.org>
Date:   Tue Jan 13 13:00:04 2015 +0100

    gpio: sysfs: fix gpio-chip device-attribute leak
    
    commit 121b6a79955a3a3fd7bbb9b8cb88d5b9dad6283d upstream.
    
    The gpio-chip device attributes were never destroyed when the device was
    removed.
    
    Fix by using device_create_with_groups() to create the device attributes
    of the chip class device.
    
    Note that this also fixes the attribute-creation race with userspace.
    
    Fixes: d8f388d8dc8d ("gpio: sysfs interface")
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>