Squashed commits from P4

commit 8ccab2a79340ee502d53f348d6c0954ac8e8d65a
Author: Prashant Somashekar <prashsomash@gmail.com>
Date:   Sun Mar 3 19:09:44 2013 -0500

    Revert "video: tegra: dc: use highest bandwidth setting"

    This reverts commit 60b78bcc68417c159f512268a82312c4b4d076d2.

commit 71276ca491ff20586f46514874ae5c762b7759d7
Author: Kevin Huang <kevinh@nvidia.com>
Date:   Tue Jun 26 01:27:58 2012 -0700

    video: tegra: dc: Fix the check of dirty window.

    Change-Id: I6584c856356d6be123a66731bde414e4925ffe07
    Reviewed-on: http://git-master/r/111184
    Reviewed-by: Rohan Somvanshi <rsomvanshi@nvidia.com>
    Tested-by: Rohan Somvanshi <rsomvanshi@nvidia.com>

commit dc063aa024e4a9fb576095931248ec8caf08c4ff
Author: I-Gene Leong <ileong@nvidia.com>
Date:   Thu Nov 17 18:49:15 2011 -0800

    video: tegra: dc: fix bug causing drawing before flipping

    The tegra_dc_trigger_windows function was improperly using the
    WIN_x_UPDATE bits to determine when a flip has occurred instead of the
    WIN_x_ACT_REQ bits. Without this change, it's possible for the postflip
    syncpoint for a buffer to get incremented before it actually flips.
    Still need to figure out why that's even possible...

    Fixes bug 902955

    Change-Id: I67ba093a0114646977cc8cb95a040ec4178cebfc
    Reviewed-on: http://git-master/r/65389
    Reviewed-by: Jon Mayo <jmayo@nvidia.com>
    Reviewed-by: Nate Huang <nhuang@nvidia.com>
    Tested-by: Nate Huang <nhuang@nvidia.com>
    Reviewed-on: http://git-master/r/98024
    Reviewed-by: Rohan Somvanshi <rsomvanshi@nvidia.com>
    Tested-by: Rohan Somvanshi <rsomvanshi@nvidia.com>

commit da1a0fa3818a8b8e87b26a052d8cfaae27ec95fb
Author: Jon Mayo <jmayo@nvidia.com>
Date:   Tue Dec 27 14:47:15 2011 -0800

    video: tegra: dc: use highest bandwidth setting

    Apply the highest bandwidth setting before windows are programmed rather
    than waiting for vblank.

    Bug 914917

    Change-Id: Iaaede9966191fdfc896bbbb19fbbadf9c4598bff
    Signed-off-by: Jon Mayo <jmayo@nvidia.com>
    Reviewed-on: http://git-master/r/72301
    Reviewed-by: Michael I Gold <gold@nvidia.com>
    Tested-by: Michael I Gold <gold@nvidia.com>

commit 6967657f8de01e481e95b2fd568790c58a0a2d6c
Author: Lance Poore <linuxsociety@gmail.com>
Date:   Sun Aug 12 15:25:06 2012 -0500

    SCHEDULER: Autogroup patch group by current user android UID instead of task ID

commit 1fdb47af5a0c74033fe13af663b2999153454c36
Author: Adam77Root <adam77root@gmail.com>
Date:   Sun Jun 9 18:22:32 2013 +0200

    defconfig: enable ROW

    Change-Id: I8f996dd926a2dc387cb55924ad8a01c81277bf1b

commit fbfbb8e456c668342a07347497869d1838610b5c
Author: franciscofranco <franciscofranco.1990@gmail.com>
Date:   Sat Jan 19 01:39:06 2013 -0800

    block: fixes required to make the kernel compile with ROW.

    Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>

commit 1afeaf87a51fd88018691060c957d53a0bc8659e
Author: franciscofranco <franciscofranco.1990@gmail.com>
Date:   Thu Jan 10 00:00:28 2013 -0800

    block: row: squash commits from codeaurora.

    Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>

commit 4588501834d09228c9deb99c59efed742bdb96b0
Author: Tatyana Brokhman <tlinder@codeaurora.org>
Date:   Tue Dec 4 16:04:15 2012 +0200

    block: Add API for urgent request handling

    This patch add support in block & elevator layers for handling
    urgent requests. The decision if a request is urgent or not is taken
    by the scheduler. Urgent request notification is passed to the underlying
    block device driver (eMMC for example). Block device driver may decide to
    interrupt the currently running low priority request to serve the new
    urgent request. By doing so READ latency is greatly reduced in read&write
    collision scenarios.

    Note that if the current scheduler doesn't implement the urgent request
    mechanism, this code path is never activated.

    Change-Id: I8aa74b9b45c0d3a2221bd4e82ea76eb4103e7cfa
    Signed-off-by: Tatyana Brokhman <tlinder@codeaurora.org>
    Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>

commit c785fa882054e374ea910882bcf44b5a401db9ff
Author: Tatyana Brokhman <tlinder@codeaurora.org>
Date:   Tue Dec 4 15:54:43 2012 +0200

    block: Add support for reinsert a dispatched req

    Add support for reinserting a dispatched request back to the
    scheduler's internal data structures.
    This capability is used by the device driver when it chooses to
    interrupt the current request transmission and execute another (more
    urgent) pending request. For example: interrupting long write in order
    to handle pending read. The device driver re-inserts the
    remaining write request back to the scheduler, to be rescheduled
    for transmission later on.

    Add API for verifying whether the current scheduler
    supports reinserting requests mechanism. If reinsert mechanism isn't
    supported by the scheduler, this code path will never be activated.

    Change-Id: I5c982a66b651ebf544aae60063ac8a340d79e67f
    Signed-off-by: Tatyana Brokhman <tlinder@codeaurora.org>
    Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>

commit b1acfb93997165c552f55a46c1838a24efdef5a5
Author: franciscofranco <franciscofranco.1990@gmail.com>
Date:   Sat Dec 29 12:38:24 2012 -0800

    Add ROW I/O Scheduler by Qualcomm.

    Change-Id: I937bfa6d1d7c3911fa5193e4849310a6a04bd0c2
    Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>

commit dddba6e0531cc4555d48158ada664dcb628ca4aa
Author: Shawn Bohrer <sbohrer@rgmadvisors.com>
Date:   Mon Jan 14 11:55:31 2013 -0600

    sched/rt: Use root_domain of rt_rq not current processor

    commit aa7f67304d1a03180f463258aa6f15a8b434e77d upstream.

    When the system has multiple domains do_sched_rt_period_timer()
    can run on any CPU and may iterate over all rt_rq in
    cpu_online_mask.  This means when balance_runtime() is run for a
    given rt_rq that rt_rq may be in a different rd than the current
    processor.  Thus if we use smp_processor_id() to get rd in
    do_balance_runtime() we may borrow runtime from a rt_rq that is
    not part of our rd.

    This changes do_balance_runtime to get the rd from the passed in
    rt_rq ensuring that we borrow runtime only from the correct rd
    for the given rt_rq.

    This fixes a BUG at kernel/sched/rt.c:687! in __disable_runtime
    when we try reclaim runtime lent to other rt_rq but runtime has
    been lent to a rt_rq in another rd.

    Signed-off-by: Shawn Bohrer <sbohrer@rgmadvisors.com>
    Acked-by: Steven Rostedt <rostedt@goodmis.org>
    Acked-by: Mike Galbraith <bitbucket@online.de>
    Cc: peterz@infradead.org
    Link: http://lkml.kernel.org/r/1358186131-29494-1-git-send-email-sbohrer@rgmadvisors.com
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    [bwh: Backported to 3.2: adjust filename]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 7adb916ec690b625977057604d2afaf69a6f51b6
Author: Arianna Avanzini <avanzini.arianna@gmail.com>
Date:   Wed Feb 6 20:39:00 2013 -0400

    block: introduce the BFQ-v6 I/O sched for 3.1

    Add the BFQ-v6 I/O scheduler to 3.1.
    The general structure is borrowed from CFQ, as much code. A (bfq_)queue is
    associated to each task doing I/O on a device, and each time a scheduling
    decision has to be made a queue is selected and served until it expires.

        - Slices are given in the service domain: tasks are assigned budgets,
          measured in number of sectors. Once got the disk, a task must
          however consume its assigned budget within a configurable maximum time
          (by default, the maximum possible value of the budgets is automatically
          computed to comply with this timeout). This allows the desired latency
          vs "throughput boosting" tradeoff to be set.

        - Budgets are scheduled according to a variant of WF2Q+, implemented
          using an augmented rb-tree to take eligibility into account while
          preserving an O(log N) overall complexity.

        - A low-latency tunable is provided; if enabled, both interactive and soft
          real-time applications are guaranteed very low latency.

        - Latency guarantees are preserved also in presence of NCQ.

        - Also with flash-based devices, a high throughput is achieved while
          still preserving latency guarantees.

        - A useful feature borrowed from CFQ: static fallback queue for OOM.

        - Differently from CFQ, BFQ uses a unified mechanism (Early Queue Merge,
          EQM) to get a sequential read pattern, and hence a high throughput,
          with any set of processes performing interleaved I/O. EQM also
          preserves low latency. The code for detecting whether two queues have
          to be merged is a slightly modified version of the CFQ code for
          detecting whether two queues belong to cooperating processes and whether
          the service of a queue should be preempted to boost the throughput.

        - BFQ supports full hierarchical scheduling, exporting a cgroups
          interface.  Each node has a full scheduler, so each group can
          be assigned its own ioprio (mapped to a weight, see next point)
          and an ioprio_class.

        - If the cgroups interface is used, weights can be explictly assigned,
          otherwise ioprio values are mapped to weights using the relation
          weight = IOPRIO_BE_NR - ioprio.

        - ioprio classes are served in strict priority order, i.e., lower
          priority queues are not served as long as there are higher priority
          queues.  Among queues in the same class the bandwidth is distributed
          in proportion to the weight of each queue. A very thin extra bandwidth
          is however guaranteed to the Idle class, to prevent it from starving.

    Signed-off-by: Paolo Valente <paolo.valente@unimore.it>
    Signed-off-by: Arianna Avanzini <avanzini.arianna@gmail.com>

commit d17958d7f68d654dd9dabf7d98ab48e474ed90da
Author: Prashant Somashekar <prashsomash@gmail.com>
Date:   Fri Feb 15 19:48:06 2013 -0500

    Revert "block: introduce the BFQ-v5r1 I/O sched for 3.1"

    This reverts commit b50e1dec1d9726e5bbd4f0dd00ef974ae994e657.

commit 7897a580d88da347b745a7c4a33d28c115c9de95
Author: Arianna Avanzini <avanzini.arianna@gmail.com>
Date:   Wed Feb 6 20:39:00 2013 -0400

    block: prepare I/O context code for BFQ-v6 for 3.1

    BFQ uses struct cfq_io_context to store its per-process per-device data,
    reusing the same code for cic handling of CFQ.  The code is not shared
    ATM to minimize the impact of these patches.

    This patch introduces a new hlist to each io_context to store all the
    cic's allocated by BFQ to allow calling the right destructor on module
    unload; the radix tree used for cic lookup needs to be duplicated
    because it can contain dead keys inserted by a scheduler and later
    retrieved by the other one.

    Update the io_context exit and free paths to take care also of
    the BFQ cic's.

    Change the type of cfqq inside struct cfq_io_context to void *
    to use it also for BFQ per-queue data.

    A new bfq-specific ioprio_changed field is necessary, too, to avoid
    clobbering cfq's one, so switch ioprio_changed to a bitmap, with one
    element per scheduler.

    Signed-off-by: Paolo Valente <paolo.valente@unimore.it>
    Signed-off-by: Arianna Avanzini <avanzini.arianna@gmail.com>

    Conflicts:
    	block/Kconfig.iosched

    Change-Id: I8c19511d3ca6e5a60be1e28b9903323d1e0fc40c

commit b7e6cd1b3b0b291e2c89df62eaf44ba90d2ad47c
Author: Prashant Somashekar <prashsomash@gmail.com>
Date:   Fri Feb 15 19:44:42 2013 -0500

    Revert "block: prepare I/O context code for BFQ-v4 for 3.1"

    This reverts commit 6d6b528b3e9691629051a46f6fe15d6c3d68324c.

    Change-Id: Ibe14088ec7b3d9fbf1a5d4db472872dd6757eb8e

commit 045bb60a7e93753d665b2ca2bb3f8fea2e45f2b2
Author: Russell King <rmk+kernel@arm.linux.org.uk>
Date:   Sat Jan 19 11:05:57 2013 +0000

    ARM: DMA: Fix struct page iterator in dma_cache_maint() to work with sparsemem

    commit 15653371c67c3fbe359ae37b720639dd4c7b42c5 upstream.

    Subhash Jadavani reported this partial backtrace:
      Now consider this call stack from MMC block driver (this is on the ARMv7
      based board):

      [<c001b50c>] (v7_dma_inv_range+0x30/0x48) from [<c0017b8c>] (dma_cache_maint_page+0x1c4/0x24c)
      [<c0017b8c>] (dma_cache_maint_page+0x1c4/0x24c) from [<c0017c28>] (___dma_page_cpu_to_dev+0x14/0x1c)
      [<c0017c28>] (___dma_page_cpu_to_dev+0x14/0x1c) from [<c0017ff8>] (dma_map_sg+0x3c/0x114)

    This is caused by incrementing the struct page pointer, and running off
    the end of the sparsemem page array.  Fix this by incrementing by pfn
    instead, and convert the pfn to a struct page.

    Suggested-by: James Bottomley <JBottomley@Parallels.com>
    Tested-by: Subhash Jadavani <subhashj@codeaurora.org>
    Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 50cc470c4ee0963ba18a200ebdecd61c1de5c24f
Author: Laura Abbott <lauraa@codeaurora.org>
Date:   Fri Jan 11 14:31:51 2013 -0800

    mm: use aligned zone start for pfn_to_bitidx calculation

    commit c060f943d0929f3e429c5d9522290584f6281d6e upstream.

    The current calculation in pfn_to_bitidx assumes that (pfn -
    zone->zone_start_pfn) >> pageblock_order will return the same bit for
    all pfn in a pageblock.  If zone_start_pfn is not aligned to
    pageblock_nr_pages, this may not always be correct.

    Consider the following with pageblock order = 10, zone start 2MB:

      pfn     | pfn - zone start | (pfn - zone start) >> page block order
      ----------------------------------------------------------------
      0x26000 | 0x25e00	   |  0x97
      0x26100 | 0x25f00	   |  0x97
      0x26200 | 0x26000	   |  0x98
      0x26300 | 0x26100	   |  0x98

    This means that calling {get,set}_pageblock_migratetype on a single page
    will not set the migratetype for the full block.  Fix this by rounding
    down zone_start_pfn when doing the bitidx calculation.

    For our use case, the effects of this bug were mostly tied to the fact
    that CMA allocations would either take a long time or fail to happen.
    Depending on the driver using CMA, this could result in anything from
    visual glitches to application failures.

    Signed-off-by: Laura Abbott <lauraa@codeaurora.org>
    Acked-by: Mel Gorman <mgorman@suse.de>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 2819ebb7bde21da9c5c768b2d199b0d1840a81f2
Author: Prashant Somashekar <prashsomash@gmail.com>
Date:   Thu Jan 24 20:29:02 2013 -0500

    tegra: dvfs: adjust voltages

    Change-Id: I6271c2dca54883cb1eb9f7aa5b257ff69f2ecf80

commit e5ab5fe9a16efd45cd2fff644c4e6740af76fc99
Author: Prashant Somashekar <prashsomash@gmail.com>
Date:   Thu Jan 24 20:27:09 2013 -0500

    Revert "tegra: dvfs: core|speedo/aon +25mv over cpu and adjust DVFS (for TEGRA_OC)"

    This reverts commit 21851c87c25b53d9eea8d2afb8a3bf079ea03abd.

    Change-Id: I3343c45e33d78d52d837ca733f79a19e375b413a

commit 48e3d2984874cfd91381ce15b64f53de249e815e
Author: Michal Hocko <mhocko@suse.cz>
Date:   Fri Jan 4 15:35:12 2013 -0800

    mm: limit mmu_gather batching to fix soft lockups on !CONFIG_PREEMPT

    commit 53a59fc67f97374758e63a9c785891ec62324c81 upstream.

    Since commit e303297e6c3a ("mm: extended batches for generic
    mmu_gather") we are batching pages to be freed until either
    tlb_next_batch cannot allocate a new batch or we are done.

    This works just fine most of the time but we can get in troubles with
    non-preemptible kernel (CONFIG_PREEMPT_NONE or CONFIG_PREEMPT_VOLUNTARY)
    on large machines where too aggressive batching might lead to soft
    lockups during process exit path (exit_mmap) because there are no
    scheduling points down the free_pages_and_swap_cache path and so the
    freeing can take long enough to trigger the soft lockup.

    The lockup is harmless except when the system is setup to panic on
    softlockup which is not that unusual.

    The simplest way to work around this issue is to limit the maximum
    number of batches in a single mmu_gather.  10k of collected pages should
    be safe to prevent from soft lockups (we would have 2ms for one) even if
    they are all freed without an explicit scheduling point.

    This patch doesn't add any new explicit scheduling points because it
    relies on zap_pmd_range during page tables zapping which calls
    cond_resched per PMD.

    The following lockup has been reported for 3.0 kernel with a huge
    process (in order of hundreds gigs but I do know any more details).

      BUG: soft lockup - CPU#56 stuck for 22s! [kernel:31053]
      Modules linked in: af_packet nfs lockd fscache auth_rpcgss nfs_acl sunrpc mptctl mptbase autofs4 binfmt_misc dm_round_robin dm_multipath bonding cpufreq_conservative cpufreq_userspace cpufreq_powersave pcc_cpufreq mperf microcode fuse loop osst sg sd_mod crc_t10dif st qla2xxx scsi_transport_fc scsi_tgt netxen_nic i7core_edac iTCO_wdt joydev e1000e serio_raw pcspkr edac_core iTCO_vendor_support acpi_power_meter rtc_cmos hpwdt hpilo button container usbhid hid dm_mirror dm_region_hash dm_log linear uhci_hcd ehci_hcd usbcore usb_common scsi_dh_emc scsi_dh_alua scsi_dh_hp_sw scsi_dh_rdac scsi_dh dm_snapshot pcnet32 mii edd dm_mod raid1 ext3 mbcache jbd fan thermal processor thermal_sys hwmon cciss scsi_mod
      Supported: Yes
      CPU 56
      Pid: 31053, comm: kernel Not tainted 3.0.31-0.9-default #1 HP ProLiant DL580 G7
      RIP: 0010:  _raw_spin_unlock_irqrestore+0x8/0x10
      RSP: 0018:ffff883ec1037af0  EFLAGS: 00000206
      RAX: 0000000000000e00 RBX: ffffea01a0817e28 RCX: ffff88803ffd9e80
      RDX: 0000000000000200 RSI: 0000000000000206 RDI: 0000000000000206
      RBP: 0000000000000002 R08: 0000000000000001 R09: ffff887ec724a400
      R10: 0000000000000000 R11: dead000000200200 R12: ffffffff8144c26e
      R13: 0000000000000030 R14: 0000000000000297 R15: 000000000000000e
      FS:  00007ed834282700(0000) GS:ffff88c03f200000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
      CR2: 000000000068b240 CR3: 0000003ec13c5000 CR4: 00000000000006e0
      DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
      Process kernel (pid: 31053, threadinfo ffff883ec1036000, task ffff883ebd5d4100)
      Call Trace:
        release_pages+0xc5/0x260
        free_pages_and_swap_cache+0x9d/0xc0
        tlb_flush_mmu+0x5c/0x80
        tlb_finish_mmu+0xe/0x50
        exit_mmap+0xbd/0x120
        mmput+0x49/0x120
        exit_mm+0x122/0x160
        do_exit+0x17a/0x430
        do_group_exit+0x3d/0xb0
        get_signal_to_deliver+0x247/0x480
        do_signal+0x71/0x1b0
        do_notify_resume+0x98/0xb0
        int_signal+0x12/0x17
      DWARF2 unwinder stuck at int_signal+0x12/0x17

    Signed-off-by: Michal Hocko <mhocko@suse.cz>
    Cc: Mel Gorman <mgorman@suse.de>
    Cc: Rik van Riel <riel@redhat.com>
    Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit a777f14306189bffd7f375cbb547e8f387badffa
Author: Hugh Dickins <hughd@google.com>
Date:   Wed Jan 2 02:01:33 2013 -0800

    tmpfs mempolicy: fix /proc/mounts corrupting memory

    commit f2a07f40dbc603c15f8b06e6ec7f768af67b424f upstream.

    Recently I suggested using "mount -o remount,mpol=local /tmp" in NUMA
    mempolicy testing.  Very nasty.  Reading /proc/mounts, /proc/pid/mounts
    or /proc/pid/mountinfo may then corrupt one bit of kernel memory, often
    in a page table (causing "Bad swap" or "Bad page map" warning or "Bad
    pagetable" oops), sometimes in a vm_area_struct or rbnode or somewhere
    worse.  "mpol=prefer" and "mpol=prefer:Node" are equally toxic.

    Recent NUMA enhancements are not to blame: this dates back to 2.6.35,
    when commit e17f74af351c "mempolicy: don't call mpol_set_nodemask() when
    no_context" skipped mpol_parse_str()'s call to mpol_set_nodemask(),
    which used to initialize v.preferred_node, or set MPOL_F_LOCAL in flags.
    With slab poisoning, you can then rely on mpol_to_str() to set the bit
    for node 0x6b6b, probably in the next page above the caller's stack.

    mpol_parse_str() is only called from shmem_parse_options(): no_context
    is always true, so call it unused for now, and remove !no_context code.
    Set v.nodes or v.preferred_node or MPOL_F_LOCAL as mpol_to_str() might
    expect.  Then mpol_to_str() can ignore its no_context argument also,
    the mpol being appropriately initialized whether contextualized or not.
    Rename its no_context unused too, and let subsequent patch remove them
    (that's not needed for stable backporting, which would involve rejects).

    I don't understand why MPOL_LOCAL is described as a pseudo-policy:
    it's a reasonable policy which suffers from a confusing implementation
    in terms of MPOL_PREFERRED with MPOL_F_LOCAL.  I believe this would be
    much more robust if MPOL_LOCAL were recognized in switch statements
    throughout, MPOL_F_LOCAL deleted, and MPOL_PREFERRED use the (possibly
    empty) nodes mask like everyone else, instead of its preferred_node
    variant (I presume an optimization from the days before MPOL_LOCAL).
    But that would take me too long to get right and fully tested.

    Signed-off-by: Hugh Dickins <hughd@google.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit d21dfe4e51a8994150659bfad003f923d6a15fc2
Author: Christoffer Dall <cdall@cs.columbia.edu>
Date:   Fri Dec 21 13:03:50 2012 -0500

    mm: Fix PageHead when !CONFIG_PAGEFLAGS_EXTENDED

    commit ad4b3fb7ff9940bcdb1e4cd62bd189d10fa636ba upstream.

    Unfortunately with !CONFIG_PAGEFLAGS_EXTENDED, (!PageHead) is false, and
    (PageHead) is true, for tail pages.  If this is indeed the intended
    behavior, which I doubt because it breaks cache cleaning on some ARM
    systems, then the nomenclature is highly problematic.

    This patch makes sure PageHead is only true for head pages and PageTail
    is only true for tail pages, and neither is true for non-compound pages.

    [ This buglet seems ancient - seems to have been introduced back in Apr
      2008 in commit 6a1e7f777f61: "pageflags: convert to the use of new
      macros".  And the reason nobody noticed is because the PageHead()
      tests are almost all about just sanity-checking, and only used on
      pages that are actual page heads.  The fact that the old code returned
      true for tail pages too was thus not really noticeable.   - Linus ]

    Signed-off-by: Christoffer Dall <cdall@cs.columbia.edu>
    Acked-by:  Andrea Arcangeli <aarcange@redhat.com>
    Cc: Andrew Morton <akpm@linux-foundation.org>
    Cc: Will Deacon <Will.Deacon@arm.com>
    Cc: Steve Capper <Steve.Capper@arm.com>
    Cc: Christoph Lameter <cl@linux.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 89679578235baad772ac422a839c07139f1e4e39
Author: Henrik Rydberg <rydberg@euromail.se>
Date:   Sat Sep 15 15:23:35 2012 +0200

    Input: Send events one packet at a time

    On heavy event loads, such as a multitouch driver, the irqsoff latency
    can be as high as 250 us.  By accumulating a frame worth of data
    before passing it on, the latency can be dramatically reduced.  As a
    side effect, the special EV_SYN handling can be removed, since the
    frame is now atomic.

    This patch adds the events() handler callback and uses it if it
    exists. The latency is improved by 50 us even without the callback.

    Change-Id: Iebd9b1868ae6300a922a45b6d104e7c2b38e4cf5
    Cc: Daniel Kurtz <djkurtz@chromium.org>
    Tested-by: Benjamin Tissoires <benjamin.tissoires@enac.fr>
    Tested-by: Ping Cheng <pingc@wacom.com>
    Tested-by: Sedat Dilek <sedat.dilek@gmail.com>
    Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Henrik Rydberg <rydberg@euromail.se>

    Input: Improve the events-per-packet estimate

    The events-per-packet estimate has so far been used by MT devices
    only. This patch adjusts the packet buffer size to also accomodate the
    KEY and MSC events.  Keyboards normally send one or two keys at a
    time. MT devices normally send a number of button keys along with the
    MT information.  The buffer size chosen here covers those cases, and
    matches the default buffer size in evdev. Since the input estimate is
    now preferred, remove the special input-mt estimate.

    Reviewed-and-tested-by: Ping Cheng <pingc@wacom.com>
    Tested-by: Benjamin Tissoires <benjamin.tissoires@enac.fr>
    Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Henrik Rydberg <rydberg@euromail.se>

commit 5b53ea4cfc7ad0b409304121797559654f9666d5
Author: Ben Hutchings <ben@decadent.org.uk>
Date:   Thu Dec 27 19:39:54 2012 +0100

    Revert "mm: vmscan: fix endless loop in kswapd balancing"

    This reverts commit 39d18dc4b8b0c000fa681cbae10ac3f8a132814b which
    was commit 60cefed485a02bd99b6299dad70666fe49245da7 upstream.

    This was not needed and is not suitable for 3.2.y.

    Reported-by: Johannes Weiner <hannes@cmpxchg.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit ab97aa73f7cd74654c3d34d3deba3d591d15e0c2
Author: Marek Szyprowski <m.szyprowski@samsung.com>
Date:   Wed Nov 7 15:37:07 2012 +0100

    mm: dmapool: use provided gfp flags for all dma_alloc_coherent() calls

    commit 387870f2d6d679746020fa8e25ef786ff338dc98 upstream.

    dmapool always calls dma_alloc_coherent() with GFP_ATOMIC flag,
    regardless the flags provided by the caller. This causes excessive
    pruning of emergency memory pools without any good reason. Additionaly,
    on ARM architecture any driver which is using dmapools will sooner or
    later  trigger the following error:
    "ERROR: 256 KiB atomic DMA coherent pool is too small!
    Please increase it with coherent_pool= kernel parameter!".
    Increasing the coherent pool size usually doesn't help much and only
    delays such error, because all GFP_ATOMIC DMA allocations are always
    served from the special, very limited memory pool.

    This patch changes the dmapool code to correctly use gfp flags provided
    by the dmapool caller.

    Reported-by: Soeren Moch <smoch@web.de>
    Reported-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
    Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
    Tested-by: Andrew Lunn <andrew@lunn.ch>
    Tested-by: Soeren Moch <smoch@web.de>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 8e9c3163a779bd5748a69e9b2706903a97131aaa
Author: Tejun Heo <tj@kernel.org>
Date:   Mon Nov 19 08:13:35 2012 -0800

    cgroup: remove incorrect dget/dput() pair in cgroup_create_dir()

    commit 175431635ec09b1d1bba04979b006b99e8305a83 upstream.

    cgroup_create_dir() does weird dancing with dentry refcnt.  On
    success, it gets and then puts it achieving nothing.  On failure, it
    puts but there isn't no matching get anywhere leading to the following
    oops if cgroup_create_file() fails for whatever reason.

      ------------[ cut here ]------------
      kernel BUG at /work/os/work/fs/dcache.c:552!
      invalid opcode: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC
      Modules linked in:
      CPU 2
      Pid: 697, comm: mkdir Not tainted 3.7.0-rc4-work+ #3 Bochs Bochs
      RIP: 0010:[<ffffffff811d9c0c>]  [<ffffffff811d9c0c>] dput+0x1dc/0x1e0
      RSP: 0018:ffff88001a3ebef8  EFLAGS: 00010246
      RAX: 0000000000000000 RBX: ffff88000e5b1ef8 RCX: 0000000000000403
      RDX: 0000000000000303 RSI: 2000000000000000 RDI: ffff88000e5b1f58
      RBP: ffff88001a3ebf18 R08: ffffffff82c76960 R09: 0000000000000001
      R10: ffff880015022080 R11: ffd9bed70f48a041 R12: 00000000ffffffea
      R13: 0000000000000001 R14: ffff88000e5b1f58 R15: 00007fff57656d60
      FS:  00007ff05fcb3800(0000) GS:ffff88001fd00000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: 00000000004046f0 CR3: 000000001315f000 CR4: 00000000000006e0
      DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
      Process mkdir (pid: 697, threadinfo ffff88001a3ea000, task ffff880015022080)
      Stack:
       ffff88001a3ebf48 00000000ffffffea 0000000000000001 0000000000000000
       ffff88001a3ebf38 ffffffff811cc889 0000000000000001 ffff88000e5b1ef8
       ffff88001a3ebf68 ffffffff811d1fc9 ffff8800198d7f18 ffff880019106ef8
      Call Trace:
       [<ffffffff811cc889>] done_path_create+0x19/0x50
       [<ffffffff811d1fc9>] sys_mkdirat+0x59/0x80
       [<ffffffff811d2009>] sys_mkdir+0x19/0x20
       [<ffffffff81be1e02>] system_call_fastpath+0x16/0x1b
      Code: 00 48 8d 90 18 01 00 00 48 89 93 c0 00 00 00 4c 89 a0 18 01 00 00 48 8b 83 a0 00 00 00 83 80 28 01 00 00 01 e8 e6 6f a0 00 eb 92 <0f> 0b 66 90 0f 1f 44 00 00 55 48 89 e5 41 57 41 56 49 89 fe 41
      RIP  [<ffffffff811d9c0c>] dput+0x1dc/0x1e0
       RSP <ffff88001a3ebef8>
      ---[ end trace 1277bcfd9561ddb0 ]---

    Fix it by dropping the unnecessary dget/dput() pair.

    Signed-off-by: Tejun Heo <tj@kernel.org>
    Acked-by: Li Zefan <lizefan@huawei.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit b17caf750d500de09ff5d7c82115ae63899b73af
Author: Eric Dumazet <edumazet@google.com>
Date:   Thu Oct 18 04:55:36 2012 -0700

    rcu: Fix batch-limit size problem

    commit 878d7439d0f45a95869e417576774673d1fa243f upstream.

    Commit 29c00b4a1d9e27 (rcu: Add event-tracing for RCU callback
    invocation) added a regression in rcu_do_batch()

    Under stress, RCU is supposed to allow to process all items in queue,
    instead of a batch of 10 items (blimit), but an integer overflow makes
    the effective limit being 1.  So, unless there is frequent idle periods
    (during which RCU ignores batch limits), RCU can be forced into a
    state where it cannot keep up with the callback-generation rate,
    eventually resulting in OOM.

    This commit therefore converts a few variables in rcu_do_batch() from
    int to long to fix this problem, along with the module parameters
    controlling the batch limits.

    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
    [bwh: Backported to 3.2:
     - Adjust context
     - Module parameters remain hidden from sysfs]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit ca355166f6f88b9b9df2fef66e1c8ea0c10754bc
Author: Will Deacon <will.deacon@arm.com>
Date:   Tue Sep 18 19:18:35 2012 +0100

    ARM: mm: use pteval_t to represent page protection values

    commit 864aa04cd02979c2c755cb28b5f4fe56039171c0 upstream.

    When updating the page protection map after calculating the user_pgprot
    value, the base protection map is temporarily stored in an unsigned long
    type, causing truncation of the protection bits when LPAE is enabled.
    This effectively means that calls to mprotect() will corrupt the upper
    page attributes, clearing the XN bit unconditionally.

    This patch uses pteval_t to store the intermediate protection values,
    preserving the upper bits for 64-bit descriptors.

    Acked-by: Nicolas Pitre <nico@linaro.org>
    Acked-by: Catalin Marinas <catalin.marinas@arm.com>
    Signed-off-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit c0554ca177a1197c570ea7dd5eb4f2b6ac935a3d
Author: Will Deacon <will.deacon@arm.com>
Date:   Fri Oct 19 14:03:31 2012 +0100

    mm: highmem: export kmap_to_page for modules

    commit f0263d2d222e9e25f2587e51a9dc58c6fb2a9352 upstream.

    Some virtio device drivers (9p) need to translate high virtual addresses
    to physical addresses, which are inserted into the virtqueue for
    processing by userspace.

    This patch exports the kmap_to_page symbol, so that the affected drivers
    can be compiled as modules.

    Signed-off-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 43e86496ecacf3bc8de38da9cb470d4591714240
Author: Ben Hutchings <ben@decadent.org.uk>
Date:   Tue Jul 31 16:45:02 2012 -0700

    mm: add kmap_to_page()

    This is extracted from Mel Gorman's commit 5a178119b0fb ('mm: add
    support for direct_IO to highmem pages') upstream.

    Required to backport commit b9cdc88df8e6 ('virtio: 9p: correctly pass
    physical address to userspace for high pages').

    Cc: Mel Gorman <mgorman@suse.de>
    Cc: Rik van Riel <riel@redhat.com>
    Cc: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit cb0f2776698a7411660e73df2a0f865c2338a140
Author: Tejun Heo <tj@kernel.org>
Date:   Tue Oct 16 15:03:14 2012 -0700

    cgroup: cgroup_subsys->fork() should be called after the task is added to css_set

    commit 5edee61edeaaebafe584f8fb7074c1ef4658596b upstream.

    cgroup core has a bug which violates a basic rule about event
    notifications - when a new entity needs to be added, you add that to
    the notification list first and then make the new entity conform to
    the current state.  If done in the reverse order, an event happening
    inbetween will be lost.

    cgroup_subsys->fork() is invoked way before the new task is added to
    the css_set.  Currently, cgroup_freezer is the only user of ->fork()
    and uses it to make new tasks conform to the current state of the
    freezer.  If FROZEN state is requested while fork is in progress
    between cgroup_fork_callbacks() and cgroup_post_fork(), the child
    could escape freezing - the cgroup isn't frozen when ->fork() is
    called and the freezer couldn't see the new task on the css_set.

    This patch moves cgroup_subsys->fork() invocation to
    cgroup_post_fork() after the new task is added to the css_set.
    cgroup_fork_callbacks() is removed.

    Because now a task may be migrated during cgroup_subsys->fork(),
    freezer_fork() is updated so that it adheres to the usual RCU locking
    and the rather pointless comment on why locking can be different there
    is removed (if it doesn't make anything simpler, why even bother?).

    Signed-off-by: Tejun Heo <tj@kernel.org>
    Cc: Oleg Nesterov <oleg@redhat.com>
    Cc: Rafael J. Wysocki <rjw@sisk.pl>
    [bwh: Backported to 3.2:
     - Adjust context
     - Iterate over first CGROUP_BUILTIN_SUBSYS_COUNT elements of subsys
     - cgroup_subsys::fork takes cgroup_subsys pointer as first parameter]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 233ab4fcec463a51b4673f784ce7673d9b4609a8
Author: Mel Gorman <mgorman@suse.de>
Date:   Wed Dec 5 14:01:41 2012 -0800

    tmpfs: fix shared mempolicy leak

    commit 18a2f371f5edf41810f6469cb9be39931ef9deb9 upstream.

    This fixes a regression in 3.7-rc, which has since gone into stable.

    Commit 00442ad04a5e ("mempolicy: fix a memory corruption by refcount
    imbalance in alloc_pages_vma()") changed get_vma_policy() to raise the
    refcount on a shmem shared mempolicy; whereas shmem_alloc_page() went
    on expecting alloc_page_vma() to drop the refcount it had acquired.
    This deserves a rework: but for now fix the leak in shmem_alloc_page().

    Hugh: shmem_swapin() did not need a fix, but surely it's clearer to use
    the same refcounting there as in shmem_alloc_page(), delete its onstack
    mempolicy, and the strange mpol_cond_copy() and __mpol_cond_copy() -
    those were invented to let swapin_readahead() make an unknown number of
    calls to alloc_pages_vma() with one mempolicy; but since 00442ad04a5e,
    alloc_pages_vma() has kept refcount in balance, so now no problem.

    Reported-and-tested-by: Tommi Rantala <tt.rantala@gmail.com>
    Signed-off-by: Mel Gorman <mgorman@suse.de>
    Signed-off-by: Hugh Dickins <hughd@google.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    [bwh: Backported to 3.2: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 01c091ec30ec64b00c1bb17780150db09a815179
Author: Mike Galbraith <efault@gmx.de>
Date:   Mon Dec 3 06:25:25 2012 +0100

    Revert "sched, autogroup: Stop going ahead if autogroup is disabled"

    commit fd8ef11730f1d03d5d6555aa53126e9e34f52f12 upstream.

    This reverts commit 800d4d30c8f20bd728e5741a3b77c4859a613f7c.

    Between commits 8323f26ce342 ("sched: Fix race in task_group()") and
    800d4d30c8f2 ("sched, autogroup: Stop going ahead if autogroup is
    disabled"), autogroup is a wreck.

    With both applied, all you have to do to crash a box is disable
    autogroup during boot up, then reboot..  boom, NULL pointer dereference
    due to commit 800d4d30c8f2 not allowing autogroup to move things, and
    commit 8323f26ce342 making that the only way to switch runqueues:

      BUG: unable to handle kernel NULL pointer dereference at           (null)
      IP: [<ffffffff81063ac0>] effective_load.isra.43+0x50/0x90
      Pid: 7047, comm: systemd-user-se Not tainted 3.6.8-smp #7 MEDIONPC MS-7502/MS-7502
      RIP: effective_load.isra.43+0x50/0x90
      Process systemd-user-se (pid: 7047, threadinfo ffff880221dde000, task ffff88022618b3a0)
      Call Trace:
        select_task_rq_fair+0x255/0x780
        try_to_wake_up+0x156/0x2c0
        wake_up_state+0xb/0x10
        signal_wake_up+0x28/0x40
        complete_signal+0x1d6/0x250
        __send_signal+0x170/0x310
        send_signal+0x40/0x80
        do_send_sig_info+0x47/0x90
        group_send_sig_info+0x4a/0x70
        kill_pid_info+0x3a/0x60
        sys_kill+0x97/0x1a0
        ? vfs_read+0x120/0x160
        ? sys_read+0x45/0x90
        system_call_fastpath+0x16/0x1b
      Code: 49 0f af 41 50 31 d2 49 f7 f0 48 83 f8 01 48 0f 46 c6 48 2b 07 48 8b bf 40 01 00 00 48 85 ff 74 3a 45 31 c0 48 8b 8f 50 01 00 00 <48> 8b 11 4c 8b 89 80 00 00 00 49 89 d2 48 01 d0 45 8b 59 58 4c
      RIP  [<ffffffff81063ac0>] effective_load.isra.43+0x50/0x90
       RSP <ffff880221ddfbd8>
      CR2: 0000000000000000

    Signed-off-by: Mike Galbraith <efault@gmx.de>
    Acked-by: Ingo Molnar <mingo@kernel.org>
    Cc: Yong Zhang <yong.zhang0@gmail.com>
    Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    [bwh: Backported to 3.2: adjust filenames]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 7798aaa49e2228d6551b9035608344e0e3a18281
Author: Ben Hutchings <ben@decadent.org.uk>
Date:   Fri Dec 7 01:41:33 2012 +0000

    Revert "device_cgroup: fix RCU usage"

    This reverts commit c5ee58688baa98bc3a4f6095a1acf6fd7fd9e967,
    which was commit 201e72acb2d3821e2de9ce6091e98859c316b29a upstream.

    Herton Ronaldo Krzesinski pointed out that the race condition this
    dealt with does not exist in 3.2.y.

    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit ff3989e9a6b4bacd859dcb3db746722b20ead111
Author: Krishna Reddy <vdumpa@nvidia.com>
Date:   Wed May 23 10:00:51 2012 -0700

    arm: tegra: Enable arm errata 764369

    Enable arm errata 764369 for TEGRA_2x and 3x.
    Bug 981223
    Bug 885467

    Change-Id: Ie013dc1ed4f1417a72dda72ea2d079a6534c3933
    Signed-off-by: Krishna Reddy <vdumpa@nvidia.com>
    Reviewed-on: http://git-master/r/104181
    Reviewed-by: Simone Willett <swillett@nvidia.com>
    Tested-by: Simone Willett <swillett@nvidia.com>

commit 699e017036851441b92638a07cc2353afdbe58a8
Author: Chris Johnson <cwj@nvidia.com>
Date:   Tue Feb 14 17:27:08 2012 -0800

    ARM: tegra: define/enable ARCH_HAS_SUSPEND_PAGETABLE

    For Tegra, the CPU suspend code path installs its own 1:1 pagetable
    setup once at init time. This pagetable is used by all CPUs doing
    suspend/resume.

    We want to use the common ARM code for CPU suspend/resume, but don't
    want the MMU reenable code to patch the current pagetable as it's
    shared (and could cause problems if the pagetable loads/stores were
    were interleaved).

    The installed pagetable already covers the cpu_resume_turn_mmu_on
    VA, so we're able to just use the existing pagetable. This sets up
    the CONFIG option to skip this part of the MMU reenable.

    Bug 929856

    Change-Id: Ibbac258122df6def7f7a2d511778a6f11d474938
    Signed-off-by: Chris Johnson <cwj@nvidia.com>
    Reviewed-on: http://git-master/r/92350
    Reviewed-by: Sang-Hun Lee <sanlee@nvidia.com>
    Tested-by: Sang-Hun Lee <sanlee@nvidia.com>
    Reviewed-by: Thomas Cherry <tcherry@nvidia.com>
    Reviewed-by: Krishna Reddy <vdumpa@nvidia.com>
    Reviewed-by: Ahung Cheng <ahcheng@nvidia.com>
    Tested-by: Ahung Cheng <ahcheng@nvidia.com>
    Reviewed-on: http://git-master/r/103205
    Reviewed-by: Simone Willett <swillett@nvidia.com>
    Tested-by: Simone Willett <swillett@nvidia.com>

    Conflicts:
    	arch/arm/mach-tegra/Kconfig

commit be6946369d51933f6a59688ed3980ae24ce5d9e4
Author: Prashant Gaikwad <pgaikwad@nvidia.com>
Date:   Fri May 25 10:48:09 2012 +0530

    ARM: tegra: clock: Update secondary pll dividers resume

    During resume from LP0 on Tegra2 always enable pll secondary dividers
    before clocks restoration (to make sure clock sources are enabled).
    Restore actual secondary dividers settings after clocks are restored.

    Bug 965928
    Bug 953030

    Signed-off-by: Prashant Gaikwad <pgaikwad@nvidia.com>

    Reviewed on http://git-master/r/#change,104661
    (cherry picked from commit 6350d1fd475373779cf5110403717b2c84e723ba)

    Change-Id: I048e3f925daf02074312472afa667609a8338c15
    Reviewed-on: http://git-master/r/104698
    Reviewed-by: Manish Tuteja <mtuteja@nvidia.com>
    Tested-by: Manish Tuteja <mtuteja@nvidia.com>

commit 213a80747502b3a0e197a09f393e3a4ed147fb5f
Author: Krishna Reddy <vdumpa@nvidia.com>
Date:   Tue May 29 16:29:10 2012 -0700

    mm: Ensure pte and pmd stores ordering.

    Bug 974153
    Signed-off-by: Krishna Reddy <vdumpa@nvidia.com>

    Reviewed-on: http://git-master/r/105215
    (cherry picked from commit 25c3334f0e1ea6bde84c0514bad0eb1859566dba)

    Change-Id: I3a77ce812fab77f785c488a3aac9d0bc66e8236d
    Reviewed-on: http://git-master/r/108446
    GVS: Gerrit_Virtual_Submit
    Reviewed-by: Sang-Hun Lee <sanlee@nvidia.com>
    Tested-by: Sang-Hun Lee <sanlee@nvidia.com>
    Reviewed-by: Krishna Reddy <vdumpa@nvidia.com>

commit 4b4de5f94d7d5ec4a7df879f4e844f3ca6ff0fcf
Author: Johannes Weiner <hannes@cmpxchg.org>
Date:   Thu Nov 29 13:54:23 2012 -0800

    mm: vmscan: fix endless loop in kswapd balancing

    commit 60cefed485a02bd99b6299dad70666fe49245da7 upstream.

    Kswapd does not in all places have the same criteria for a balanced
    zone.  Zones are only being reclaimed when their high watermark is
    breached, but compaction checks loop over the zonelist again when the
    zone does not meet the low watermark plus two times the size of the
    allocation.  This gets kswapd stuck in an endless loop over a small
    zone, like the DMA zone, where the high watermark is smaller than the
    compaction requirement.

    Add a function, zone_balanced(), that checks the watermark, and, for
    higher order allocations, if compaction has enough free memory.  Then
    use it uniformly to check for balanced zones.

    This makes sure that when the compaction watermark is not met, at least
    reclaim happens and progress is made - or the zone is declared
    unreclaimable at some point and skipped entirely.

    Signed-off-by: Johannes Weiner <hannes@cmpxchg.org>
    Reported-by: George Spelvin <linux@horizon.com>
    Reported-by: Johannes Hirte <johannes.hirte@fem.tu-ilmenau.de>
    Reported-by: Tomas Racek <tracek@redhat.com>
    Tested-by: Johannes Hirte <johannes.hirte@fem.tu-ilmenau.de>
    Reviewed-by: Rik van Riel <riel@redhat.com>
    Cc: Mel Gorman <mel@csn.ul.ie>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    [bwh: Backported to 3.2: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit fb168f3cf6590ab90896206b2716cf3f747ec5da
Author: Hugh Dickins <hughd@google.com>
Date:   Fri Nov 16 14:15:04 2012 -0800

    tmpfs: change final i_blocks BUG to WARNING

    commit 0f3c42f522dc1ad7e27affc0a4aa8c790bce0a66 upstream.

    Under a particular load on one machine, I have hit shmem_evict_inode()'s
    BUG_ON(inode->i_blocks), enough times to narrow it down to a particular
    race between swapout and eviction.

    It comes from the "if (freed > 0)" asymmetry in shmem_recalc_inode(),
    and the lack of coherent locking between mapping's nrpages and shmem's
    swapped count.  There's a window in shmem_writepage(), between lowering
    nrpages in shmem_delete_from_page_cache() and then raising swapped
    count, when the freed count appears to be +1 when it should be 0, and
    then the asymmetry stops it from being corrected with -1 before hitting
    the BUG.

    One answer is coherent locking: using tree_lock throughout, without
    info->lock; reasonable, but the raw_spin_lock in percpu_counter_add() on
    used_blocks makes that messier than expected.  Another answer may be a
    further effort to eliminate the weird shmem_recalc_inode() altogether,
    but previous attempts at that failed.

    So far undecided, but for now change the BUG_ON to WARN_ON: in usual
    circumstances it remains a useful consistency check.

    Signed-off-by: Hugh Dickins <hughd@google.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    [bwh: Backported to 3.2: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 2c43dd48b6f810e80bac1de55ac1dd98d3ee2258
Author: Michal Hocko <mhocko@suse.cz>
Date:   Fri Nov 16 14:14:49 2012 -0800

    memcg: oom: fix totalpages calculation for memory.swappiness==0

    commit 9a5a8f19b43430752067ecaee62fc59e11e88fa6 upstream.

    oom_badness() takes a totalpages argument which says how many pages are
    available and it uses it as a base for the score calculation.  The value
    is calculated by mem_cgroup_get_limit which considers both limit and
    total_swap_pages (resp.  memsw portion of it).

    This is usually correct but since fe35004fbf9e ("mm: avoid swapping out
    with swappiness==0") we do not swap when swappiness is 0 which means
    that we cannot really use up all the totalpages pages.  This in turn
    confuses oom score calculation if the memcg limit is much smaller than
    the available swap because the used memory (capped by the limit) is
    negligible comparing to totalpages so the resulting score is too small
    if adj!=0 (typically task with CAP_SYS_ADMIN or non zero oom_score_adj).
    A wrong process might be selected as result.

    The problem can be worked around by checking mem_cgroup_swappiness==0
    and not considering swap at all in such a case.

    Signed-off-by: Michal Hocko <mhocko@suse.cz>
    Acked-by: David Rientjes <rientjes@google.com>
    Acked-by: Johannes Weiner <hannes@cmpxchg.org>
    Acked-by: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
    Acked-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 99e56f29d0ce26fad8ed2c7d13daf26653442472
Author: Tejun Heo <tj@kernel.org>
Date:   Tue Nov 6 09:17:37 2012 -0800

    device_cgroup: fix RCU usage

    commit 201e72acb2d3821e2de9ce6091e98859c316b29a upstream.

    dev_cgroup->exceptions is protected with devcgroup_mutex for writes
    and RCU for reads; however, RCU usage isn't correct.

    * dev_exception_clean() doesn't use RCU variant of list_del() and
      kfree().  The function can race with may_access() and may_access()
      may end up dereferencing already freed memory.  Use list_del_rcu()
      and kfree_rcu() instead.

    * may_access() may be called only with RCU read locked but doesn't use
      RCU safe traversal over ->exceptions.  Use list_for_each_entry_rcu().

    Signed-off-by: Tejun Heo <tj@kernel.org>
    Acked-by: Serge E. Hallyn <serge.hallyn@ubuntu.com>
    Cc: Aristeu Rozanski <aris@redhat.com>
    Cc: Li Zefan <lizefan@huawei.com>
    [bwh: Backported to 3.2:
     - Adjust context
     - Exception list is called whitelist]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 92de39ac89aa6d1c463ac1453d6d5d5960fac4be
Author: Paolo Valente <paolo.valente@unimore.it>
Date:   Tue Dec 11 10:33:00 2012 -0400

    block: introduce the BFQ-v5r1 I/O sched for 3.1

    Add the BFQ-v5r1 I/O scheduler to 3.1.
    The general structure is borrowed from CFQ, as much code. A (bfq_)queue is
    associated to each task doing I/O on a device, and each time a scheduling
    decision has to be taken a queue is selected and it is served until it expires.

        - Slices are given in the service domain: tasks are assigned budgets,
          measured in number of sectors. Once got the disk, a task must
          however consume its assigned budget within a configurable maximum time
          (by default, the maximum possible value of the budgets is automatically
          computed to comply with this timeout). This allows the desired latency
          vs "throughput boosting" tradeoff to be set.

        - Budgets are scheduled according to a variant of WF2Q+, implemented
          using an augmented rb-tree to take eligibility into account while
          preserving an O(log N) overall complexity.

        - A low-latency tunable is provided; if enabled, both interactive and soft
          real-time applications are guaranteed very low latency.

        - Latency guarantees are preserved also in presence of NCQ.

        - High throughput with flash-based devices, while still preserving
          latency guarantees.

        - Useful features borrowed from CFQ: cooperating-queues merging (with
          some additional optimizations with respect to the original CFQ version),
          static fallback queue for OOM.

        - BFQ supports full hierarchical scheduling, exporting a cgroups
          interface.  Each node has a full scheduler, so each group can
          be assigned its own ioprio and an ioprio_class.

        - If the cgroups interface is used, weights can be explictly assigned,
          otherwise ioprio values are mapped to weights using the relation
          weight = IOPRIO_BE_NR - ioprio.

        - ioprio classes are served in strict priority order, i.e., lower
          priority queues are not served as long as there are higher priority
          queues.  Among queues in the same class the bandwidth is distributed
          in proportion to the weights of each queue. A very thin extra bandwidth
          is however guaranteed to the Idle class, to prevent it from starving.

    Signed-off-by: Paolo Valente <paolo.valente@unimore.it>
    Signed-off-by: Arianna Avanzini <avanzini.arianna@gmail.com>

commit ddc81c629876ac8a657da115df271f068ac0a409
Author: Prashant Somashekar <prashsomash@gmail.com>
Date:   Mon Dec 17 12:30:22 2012 -0500

    Revert "block: introduce the BFQ-v5 I/O sched for 3.1"

    This reverts commit 204666c53ee126438e674978022399a8cc2e4bbf.

Change-Id: Ieebc442e894f6d4f7600b47058ab2aff7243edf6