Squashed commits from P4

commit b8a8494156b0868e5c830b08c5ab827835678e5d
Author: Adam77Root <adam77root@gmail.com>
Date:   Sun Jun 9 17:37:30 2013 +0200

    defconfig: remove duplicate

    Change-Id: I688f347a899ecbb926c1faaad6cf42946767dce4

commit 85284d500d6a6ff6e957f29f449ad7064b3f7893
Author: Adam77Root <adam77root@gmail.com>
Date:   Sun Jun 9 17:30:02 2013 +0200

    defconfig: enable UHID

    Change-Id: I353acd9d98afa21d8bd8ca9c401d1e01dd1a68c4

commit bb4c191a9516dab88d7a82c113817ded81b611db
Author: Vinicius Costa Gomes <vinicius.gomes@openbossa.org>
Date:   Sat Jul 14 18:59:25 2012 -0300

    HID: uhid: Fix sending events with invalid data

    This was detected because events with invalid types were arriving
    to userspace.

    The code before this patch would only work for the first event in the
    queue (when uhid->tail is 0).

    Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@openbossa.org>
    Reviewed-by: David Herrmann <dh.herrmann@googlemail.com>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>

commit 8cab1b88d2674bc871cd9c8f75495253c6564f62
Author: Jiri Kosina <jkosina@suse.cz>
Date:   Mon Jun 18 17:08:08 2012 +0200

    HID: uhid: silence gcc warning

    gcc is giving me:

    drivers/hid/uhid.c: In function ‘uhid_hid_get_raw’:
    drivers/hid/uhid.c:157: warning: ‘len’ may be used uninitialized in this function

    which is clearly bogus, as

    - when used as memcpy() argument, it's initialized properly
    - the code is structured in a way that either 'ret' or 'len'
      is always initialized, so the return statement always has
      an initialized value.

    Signed-off-by: Jiri Kosina <jkosina@suse.cz>

commit dd7dfc79700c10c024c26566806af17871e3d33d
Author: David Herrmann <dh.herrmann@googlemail.com>
Date:   Sun Jun 10 15:16:27 2012 +0200

    HID: uhid: add example program

    This adds an example user-space program that emulates a 3 button mouse
    with wheel. It detects keyboard presses and moves the mouse accordingly.

    It register a fake HID device to feed the raw HID reports into the kernel.
    In this example, you could use uinput to get the same result, but this
    shows how to get the same behavior with uhid so you don't need HID parsers
    in user-space.

    Signed-off-by: David Herrmann <dh.herrmann@googlemail.com>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>

commit ca8cdce13357cc3ff7748c59c925413dce314a49
Author: David Herrmann <dh.herrmann@googlemail.com>
Date:   Sun Jun 10 15:16:26 2012 +0200

    HID: uhid: add documentation

    This describes the protocol used by uhid for user-space applications. It
    describes the details like non-blocking I/O and readv/writev for multiple
    events per syscall.

    Signed-off-by: David Herrmann <dh.herrmann@googlemail.com>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>

commit 655fc6be4996d7ec1230c7cabd709d2e3ec62c4d
Author: David Herrmann <dh.herrmann@googlemail.com>
Date:   Sun Jun 10 15:16:25 2012 +0200

    HID: uhid: implement feature requests

    HID standard allows sending a feature request to the device which is
    answered by an HID report. uhid implements this by sending a UHID_FEATURE
    event to user-space which then must answer with UHID_FEATURE_ANSWER. If it
    doesn't do this in a timely manner, the request is discarded silently.

    We serialize the feature requests, that is, there is always only a single
    active feature-request sent to user-space, other requests have to wait.
    HIDP and USB-HID do it the same way.

    Because we discard feature-requests silently, we must make sure to match
    a response to the corresponding request. We use sequence-IDs for this so
    user-space must copy the ID from the request into the answer.
    Feature-answers are ignored if they do not contain the same ID as the
    currently pending feature request.

    Internally, we must make sure that feature-requests are synchronized with
    UHID_DESTROY and close() events. We must not dead-lock when closing the
    HID device, either, so we have to use separate locks.

    Signed-off-by: David Herrmann <dh.herrmann@googlemail.com>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>

commit ccf1b5e4699d768cee9da29433e5d85ca2d21699
Author: David Herrmann <dh.herrmann@googlemail.com>
Date:   Sun Jun 10 15:16:24 2012 +0200

    HID: uhid: forward raw output reports to user-space

    Some drivers that use non-standard HID features require raw output reports
    sent to the device. We now forward these requests directly to user-space
    so the transport-level driver can correctly send it to the device or
    handle it correspondingly.

    There is no way to signal back whether the transmission was successful,
    moreover, there might be lots of messages coming out from the driver
    flushing the output-queue. However, there is currently no driver that
    causes this so we are safe. If some drivers need to transmit lots of data
    this way, we need a method to synchronize this and can implement another
    UHID_OUTPUT_SYNC event.

    Signed-off-by: David Herrmann <dh.herrmann@googlemail.com>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>

commit a14a1e601fb4518dd962978dd96c55e8420f4c6d
Author: David Herrmann <dh.herrmann@googlemail.com>
Date:   Sun Jun 10 15:16:23 2012 +0200

    HID: uhid: forward output request to user-space

    If the hid-driver wants to send standardized data to the device it uses a
    linux input_event. We forward this to the user-space transport-level
    driver so they can perform the requested action on the device.

    Signed-off-by: David Herrmann <dh.herrmann@googlemail.com>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>

commit c87a868ba79c931c21ab3da720f03c74e31e819f
Author: David Herrmann <dh.herrmann@googlemail.com>
Date:   Sun Jun 10 15:16:22 2012 +0200

    HID: uhid: forward open/close events to user-space

    HID core notifies us with *_open/*_close callbacks when there is an actual
    user of our device. We forward these to user-space so they can react on
    this. This allows user-space to skip I/O unless they receive an OPEN
    event. When they receive a CLOSE event they can stop I/O again to save
    energy.

    Signed-off-by: David Herrmann <dh.herrmann@googlemail.com>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>

commit c3b3287848544622be9d28a490f93ce790ff9fb6
Author: David Herrmann <dh.herrmann@googlemail.com>
Date:   Sun Jun 10 15:16:21 2012 +0200

    HID: uhid: add UHID_START and UHID_STOP events

    We send UHID_START and UHID_STOP events to user-space when the HID core
    starts/stops the device. This notifies user-space about driver readiness
    and data-I/O can start now.

    This directly forwards the callbacks from hid-core to user-space.

    Signed-off-by: David Herrmann <dh.herrmann@googlemail.com>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>

commit 69b67c28c6f903e755985b0acab6f7adee45728c
Author: David Herrmann <dh.herrmann@googlemail.com>
Date:   Sun Jun 10 15:16:20 2012 +0200

    HID: uhid: forward hid report-descriptor to hid core

    When the uhid_hid_parse callback is called we simply forward it to
    hid_parse_report() with the data that we got in the UHID_CREATE event.

    Signed-off-by: David Herrmann <dh.herrmann@googlemail.com>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>

commit f81484567e8ef20dbeccb79f04692e08b40704e2
Author: David Herrmann <dh.herrmann@googlemail.com>
Date:   Sun Jun 10 15:16:19 2012 +0200

    HID: uhid: allow feeding input data into uhid devices

    This adds a new event type UHID_INPUT which allows user-space to feed raw
    HID reports into the HID subsystem. We copy the data into kernel memory
    and directly feed it into the HID core.

    There is no error handling of the events couldn't be parsed so user-space
    should consider all events successfull unless read() returns an error.

    Signed-off-by: David Herrmann <dh.herrmann@googlemail.com>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>

commit 5147437a91b810fc58ccb5a14dca93728b78ec29
Author: David Herrmann <dh.herrmann@googlemail.com>
Date:   Sun Jun 10 15:16:18 2012 +0200

    HID: uhid: add UHID_CREATE and UHID_DESTROY events

    UHID_CREATE and UHID_DESTROY are used to create and destroy a device on an
    open uhid char-device. Internally, we allocate and register an HID device
    with the HID core and immediately start the device. From now on events may
    be received or sent to the device.

    The UHID_CREATE event has a payload similar to the data used by
    Bluetooth-HIDP when creating a new connection.

    Signed-off-by: David Herrmann <dh.herrmann@googlemail.com>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>

commit 09136c8bac2053e99ed8f37e19d290bf6bc72289
Author: David Herrmann <dh.herrmann@googlemail.com>
Date:   Sun Jun 10 15:16:17 2012 +0200

    HID: uhid: implement write() on uhid devices

    Similar to read() you can only write() a single event with one call to an
    uhid device. To write multiple events use writev() which is supported by
    uhid.

    We currently always return -EOPNOTSUPP but other events will be added in
    later patches.

    Signed-off-by: David Herrmann <dh.herrmann@googlemail.com>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>

commit 0a0b89ce47acdf869ab19860258700e3179ce76d
Author: David Herrmann <dh.herrmann@googlemail.com>
Date:   Sun Jun 10 15:16:16 2012 +0200

    HID: uhid: implement read() on uhid devices

    User-space can use read() to get a single event from uhid devices. read()
    does never return multiple events. This allows us to extend the event
    structure and still keep backwards compatibility.

    If user-space wants to get multiple events in one syscall, they should use
    the readv()/writev() syscalls which are supported by uhid.

    This introduces a new lock which helps us synchronizing simultaneous reads
    from user-space. We also correctly return -EINVAL/-EFAULT only on errors
    and retry the read() when some other thread captured the event faster than
    we did.

    Signed-off-by: David Herrmann <dh.herrmann@googlemail.com>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>

commit 92c2a8f37fd84c8cf00012b38216b0a21daeda45
Author: David Herrmann <dh.herrmann@googlemail.com>
Date:   Sun Jun 10 15:16:15 2012 +0200

    HID: uhid: allow poll()'ing on uhid devices

    As long as the internal buffer is not empty, we return POLLIN to
    user-space.

    uhid->head and uhid->tail are no atomics so the comparison may return
    inexact results. However, this doesn't matter here as user-space would
    need to poll() in two threads simultaneously to trigger this. And in this
    case it doesn't matter if a cached result is returned or the exact new
    result as user-space does not know which thread returns first from poll()
    and the following read(). So it is safe to compare the values without
    locking.

    Signed-off-by: David Herrmann <dh.herrmann@googlemail.com>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>

commit f8b2c6fefd85ecc3f7f7d6edc94c9d9a0b974c12
Author: David Herrmann <dh.herrmann@googlemail.com>
Date:   Sun Jun 10 15:16:14 2012 +0200

    HID: uhid: add internal message buffer

    When receiving messages from the HID subsystem, we need to process them
    and store them in an internal buffer so user-space can read() on the char
    device to retrieve the messages.

    This adds a static buffer for 32 messages to each uhid device. Each
    message is dynamically allocated so the uhid_device structure does not get
    too big.

    uhid_queue() adds a message to the buffer. If the buffer is full, the
    message is discarded. uhid_queue_event() is an helper for messages without
    payload.

    This also adds a public header: uhid.h. It contains the declarations for
    the user-space API. It is built around "struct uhid_event" which contains
    a type field which specifies the event type and each event can then add a
    variable-length payload. For now, there is only a dummy event but later
    patches will add new event types and payloads.

    Signed-off-by: David Herrmann <dh.herrmann@googlemail.com>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>

commit ef11b08276c71877a8e83133ccb2a62b509766d4
Author: David Herrmann <dh.herrmann@googlemail.com>
Date:   Sun Jun 10 15:16:13 2012 +0200

    HID: uhid: introduce user-space I/O driver support for HID

    This adds a dummy driver that will support user-space I/O drivers for the
    HID subsystem. This allows to write transport-level drivers like USB-HID
    and Bluetooth-HID in user-space.

    Low-Energy Bluetooth needs this to feed HID data that is parsed in
    user-space back into the kernel.

    Signed-off-by: David Herrmann <dh.herrmann@googlemail.com>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>

commit 560af5a74b0e6101c70743d4d5870d353ab04d8d
Author: Prashant Somashekar <prashsomash@gmail.com>
Date:   Sun Dec 9 11:45:33 2012 -0500

    drivers: modem_if: use memcpy in dpram_download for header

    -using inline _memcpy for this triggers an internal compiler error in
     GCC 4.6.

commit 58ba4ed0a193306987925f7eb827c13bed255a75
Author: Chanho Min <chanho0207@gmail.com>
Date:   Thu Jan 5 20:00:19 2012 +0900

    sched/rt: Fix task stack corruption under __ARCH_WANT_INTERRUPTS_ON_CTXSW

    commit cb297a3e433dbdcf7ad81e0564e7b804c941ff0d upstream.

    This issue happens under the following conditions:

     1. preemption is off
     2. __ARCH_WANT_INTERRUPTS_ON_CTXSW is defined
     3. RT scheduling class
     4. SMP system

    Sequence is as follows:

     1.suppose current task is A. start schedule()
     2.task A is enqueued pushable task at the entry of schedule()
       __schedule
        prev = rq->curr;
        ...
        put_prev_task
         put_prev_task_rt
          enqueue_pushable_task
     4.pick the task B as next task.
       next = pick_next_task(rq);
     3.rq->curr set to task B and context_switch is started.
       rq->curr = next;
     4.At the entry of context_swtich, release this cpu's rq->lock.
       context_switch
        prepare_task_switch
         prepare_lock_switch
          raw_spin_unlock_irq(&rq->lock);
     5.Shortly after rq->lock is released, interrupt is occurred and start IRQ context
     6.try_to_wake_up() which called by ISR acquires rq->lock
        try_to_wake_up
         ttwu_remote
          rq = __task_rq_lock(p)
          ttwu_do_wakeup(rq, p, wake_flags);
            task_woken_rt
     7.push_rt_task picks the task A which is enqueued before.
       task_woken_rt
        push_rt_tasks(rq)
         next_task = pick_next_pushable_task(rq)
     8.At find_lock_lowest_rq(), If double_lock_balance() returns 0,
       lowest_rq can be the remote rq.
      (But,If preemption is on, double_lock_balance always return 1 and it
       does't happen.)
       push_rt_task
        find_lock_lowest_rq
         if (double_lock_balance(rq, lowest_rq))..
     9.find_lock_lowest_rq return the available rq. task A is migrated to
       the remote cpu/rq.
       push_rt_task
        ...
        deactivate_task(rq, next_task, 0);
        set_task_cpu(next_task, lowest_rq->cpu);
        activate_task(lowest_rq, next_task, 0);
     10. But, task A is on irq context at this cpu.
         So, task A is scheduled by two cpus at the same time until restore from IRQ.
         Task A's stack is corrupted.

    To fix it, don't migrate an RT task if it's still running.

    Signed-off-by: Chanho Min <chanho.min@lge.com>
    Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
    Acked-by: Steven Rostedt <rostedt@goodmis.org>
    Link: http://lkml.kernel.org/r/CAOAMb1BHA=5fm7KTewYyke6u-8DP0iUuJMpgQw54vNeXFsGpoQ@mail.gmail.com
    Signed-off-by: Ingo Molnar <mingo@elte.hu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 229caeaa9d335e1039a3c1c7d080174e68170bc9
Author: Peter Zijlstra <a.p.zijlstra@chello.nl>
Date:   Thu Oct 6 22:39:14 2011 +0200

    sched, rt: Provide means of disabling cross-cpu bandwidth sharing

    Normally the RT bandwidth scheme will share bandwidth across the
    entire root_domain. However sometimes its convenient to disable this
    sharing for debug purposes. Provide a simple feature switch to this
    end.

    Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
    Signed-off-by: Ingo Molnar <mingo@elte.hu>

commit b775bf46b2a811348fd4e20a80d02be182918781
Author: Thomas Gleixner <tglx@linutronix.de>
Date:   Wed Oct 5 13:32:34 2011 +0200

    sched: Warn on rt throttling

    The default rt-throttling is a source of never ending questions. Warn
    once when we go into throttling so folks have that info in dmesg.

    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
    Link: http://lkml.kernel.org/r/alpine.LFD.2.02.1110051331480.18778@ionos
    Signed-off-by: Ingo Molnar <mingo@elte.hu>

commit 1b5a9b59f868bf0502b6ceb6e7d3b54e4ef29c03
Author: Paul Turner <pjt@google.com>
Date:   Thu Jul 21 09:43:27 2011 -0700

    sched: Implement hierarchical task accounting for SCHED_OTHER

    Introduce hierarchical task accounting for the group scheduling case in CFS, as
    well as promoting the responsibility for maintaining rq->nr_running to the
    scheduling classes.

    The primary motivation for this is that with scheduling classes supporting
    bandwidth throttling it is possible for entities participating in throttled
    sub-trees to not have root visible changes in rq->nr_running across activate
    and de-activate operations.  This in turn leads to incorrect idle and
    weight-per-task load balance decisions.

    This also allows us to make a small fixlet to the fastpath in pick_next_task()
    under group scheduling.

    Note: this issue also exists with the existing sched_rt throttling mechanism.
    This patch does not address that.

    Signed-off-by: Paul Turner <pjt@google.com>
    Reviewed-by: Hidetoshi Seto <seto.hidetoshi@jp.fujitsu.com>
    Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
    Link: http://lkml.kernel.org/r/20110721184756.878333391@google.com
    Signed-off-by: Ingo Molnar <mingo@elte.hu>

commit 3fd5371223b8ee37b0e09c3e660ee40b024bd5d0
Author: Steven Rostedt <srostedt@redhat.com>
Date:   Thu Jun 16 21:55:23 2011 -0400

    sched: Use pushable_tasks to determine next highest prio

    Hillf Danton proposed a patch (see link) that cleaned up the
    sched_rt code that calculates the priority of the next highest priority
    task to be used in finding run queues to pull from.

    His patch removed the calculating of the next prio to just use the current
    prio when deteriming if we should examine a run queue to pull from. The problem
    with his patch was that it caused more false checks. Because we check a run
    queue for pushable tasks if the current priority of that run queue is higher
    in priority than the task about to run on our run queue. But after grabbing
    the locks and doing the real check, we find that there may not be a task
    that has a higher prio task to pull. Thus the locks were taken with nothing to
    do.

    I added some trace_printks() to record when and how many times the run queue
    locks were taken to check for pullable tasks, compared to how many times we
    pulled a task.

    With the current method, it was:

      3806 locks taken vs 2812 pulled tasks

    With Hillf's patch:

      6728 locks taken vs 2804 pulled tasks

    The number of times locks were taken to pull a task went up almost double with
    no more success rate.

    But his patch did get me thinking. When we look at the priority of the highest
    task to consider taking the locks to do a pull, a failure to pull can be one
    of the following: (in order of most likely)

     o RT task was pushed off already between the check and taking the lock
     o Waiting RT task can not be migrated
     o RT task's CPU affinity does not include the target run queue's CPU
     o RT task's priority changed between the check and taking the lock

    And with Hillf's patch, the thing that caused most of the failures, is
    the RT task to pull was not at the right priority to pull (not greater than
    the current RT task priority on the target run queue).

    Most of the above cases we can't help. But the current method does not check
    if the next highest prio RT task can be migrated or not, and if it can not,
    we still grab the locks to do the test (we don't find out about this fact until
    after we have the locks). I thought about this case, and realized that the
    pushable task plist that is maintained only holds RT tasks that can migrate.
    If we move the calculating of the next highest prio task from the inc/dec_rt_task()
    functions into the queuing of the pushable tasks, then we only measure the
    priorities of those tasks that we push, and we get this basically for free.

    Not only does this patch make the code a little more efficient, it cleans it
    up and makes it a little simpler.

    Thanks to Hillf Danton for inspiring me on this patch.

    Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
    Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
    Cc: Hillf Danton <dhillf@gmail.com>
    Cc: Gregory Haskins <ghaskins@novell.com>
    Link: http://lkml.kernel.org/r/BANLkTimQ67180HxCx5vgMqumqw1EkFh3qg@mail.gmail.com
    Signed-off-by: Ingo Molnar <mingo@elte.hu>

commit a9e982c1f066b7d40cfbdaba27e484072916d144
Author: Steven Rostedt <srostedt@redhat.com>
Date:   Thu Jun 16 21:55:22 2011 -0400

    sched: Balance RT tasks when forked as well

    When a new task is woken, the code to balance the RT task is currently
    skipped in the select_task_rq() call. But it will be pushed if the rq
    is currently overloaded with RT tasks anyway. The issue is that we
    already queued the task, and if it does get pushed, it will have to
    be dequeued and requeued on the new run queue. The advantage with
    pushing it first is that we avoid this requeuing as we are pushing it
    off before the task is ever queued.

    See commit 318e0893ce3f524 ("sched: pre-route RT tasks on wakeup")
    for more details.

    The return of select_task_rq() when it is not a wake up has also been
    changed to return task_cpu() instead of smp_processor_id(). This is more
    of a sanity because the current only other user of select_task_rq()
    besides wake ups, is an exec, where task_cpu() should also be the same
    as smp_processor_id(). But if it is used for other purposes, lets keep
    the task on the same CPU. Why would we mant to migrate it to the current
    CPU?

    Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
    Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
    Cc: Hillf Danton <dhillf@gmail.com>
    Link: http://lkml.kernel.org/r/20110617015919.832743148@goodmis.org
    Signed-off-by: Ingo Molnar <mingo@elte.hu>

commit 116af47afc697e5129d2a28cfc9bccd2db95be83
Author: Hillf Danton <dhillf@gmail.com>
Date:   Thu Jun 16 21:55:21 2011 -0400

    sched: Remove resetting exec_start in put_prev_task_rt()

    There's no reason to clean the exec_start in put_prev_task_rt() as it is reset
    when the task gets back to the run queue. This saves us doing a store() in the
    fast path.

    Signed-off-by: Hillf Danton <dhillf@gmail.com>
    Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
    Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
    Cc: Mike Galbraith <efault@gmx.de>
    Cc: Yong Zhang <yong.zhang0@gmail.com>
    Link: http://lkml.kernel.org/r/BANLkTimqWD=q6YnSDi-v9y=LMWecgEzEWg@mail.gmail.com
    Signed-off-by: Ingo Molnar <mingo@elte.hu>

commit a083902bfdc09697399cb5725a4b6439f65c626a
Author: Hillf Danton <dhillf@gmail.com>
Date:   Thu Jun 16 21:55:20 2011 -0400

    sched, rt: Fix rq->rt.pushable_tasks bug in push_rt_task()

    Do not call dequeue_pushable_task() when failing to push an eligible
    task, as it remains pushable, merely not at this particular moment.

    Signed-off-by: Hillf Danton <dhillf@gmail.com>
    Signed-off-by: Mike Galbraith <mgalbraith@gmx.de>
    Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
    Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
    Cc: Yong Zhang <yong.zhang0@gmail.com>
    Link: http://lkml.kernel.org/r/1306895385.4791.26.camel@marge.simson.net
    Signed-off-by: Ingo Molnar <mingo@elte.hu>

commit 1b3d1d58bdf1387550aa43cb10e77ff2bdc3509c
Author: Hillf Danton <dhillf@gmail.com>
Date:   Thu Jun 16 21:55:18 2011 -0400

    sched: Remove noop in next_prio()

    When computing the next priority for a given run-queue, the check for
    RT priority of the task determined by the pick_next_highest_task_rt()
    function could be removed, since only RT tasks are returned by the
    function.

    Reviewed-by: Yong Zhang <yong.zhang0@gmail.com>
    Signed-off-by: Hillf Danton <dhillf@gmail.com>
    Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
    Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
    Link: http://lkml.kernel.org/r/BANLkTimxmWiof9s5AvS3v_0X+sMiE=0x5g@mail.gmail.com
    Signed-off-by: Ingo Molnar <mingo@elte.hu>

commit b3a5b37b42ca945df49d05c9d436c87cf3623d68
Author: Takamori Yamaguchi <takamori.yamaguchi@jp.sony.com>
Date:   Thu Nov 8 15:53:39 2012 -0800

    mm: bugfix: set current->reclaim_state to NULL while returning from kswapd()

    commit b0a8cc58e6b9aaae3045752059e5e6260c0b94bc upstream.

    In kswapd(), set current->reclaim_state to NULL before returning, as
    current->reclaim_state holds reference to variable on kswapd()'s stack.

    In rare cases, while returning from kswapd() during memory offlining,
    __free_slab() and freepages() can access the dangling pointer of
    current->reclaim_state.

    Signed-off-by: Takamori Yamaguchi <takamori.yamaguchi@jp.sony.com>
    Signed-off-by: Aaditya Kumar <aaditya.kumar@ap.sony.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: Ben Hutchings <ben@decadent.org.uk>

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

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

    commit ef5d437f71afdf4afdbab99213add99f4b1318fd upstream.

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

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

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

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

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

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

    Signed-off-by: Jan Kara <jack@suse.cz>
    Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
    Cc: Mel Gorman <mgorman@suse.de>
    Cc: Hugh Dickins <hughd@google.com>
    Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    [bwh: Backported to 3.2: adjust context; in particular there is no local
     'anon' in page_remove_rmap()]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit c078d7d702a6890357cda5fc31cfd662813c7384
Author: Hugh Dickins <hughd@google.com>
Date:   Sun Oct 7 20:32:51 2012 -0700

    tmpfs,ceph,gfs2,isofs,reiserfs,xfs: fix fh_len checking

    commit 35c2a7f4908d404c9124c2efc6ada4640ca4d5d5 upstream.

    Fuzzing with trinity oopsed on the 1st instruction of shmem_fh_to_dentry(),
    	u64 inum = fid->raw[2];
    which is unhelpfully reported as at the end of shmem_alloc_inode():

    BUG: unable to handle kernel paging request at ffff880061cd3000
    IP: [<ffffffff812190d0>] shmem_alloc_inode+0x40/0x40
    Oops: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC
    Call Trace:
     [<ffffffff81488649>] ? exportfs_decode_fh+0x79/0x2d0
     [<ffffffff812d77c3>] do_handle_open+0x163/0x2c0
     [<ffffffff812d792c>] sys_open_by_handle_at+0xc/0x10
     [<ffffffff83a5f3f8>] tracesys+0xe1/0xe6

    Right, tmpfs is being stupid to access fid->raw[2] before validating that
    fh_len includes it: the buffer kmalloc'ed by do_sys_name_to_handle() may
    fall at the end of a page, and the next page not be present.

    But some other filesystems (ceph, gfs2, isofs, reiserfs, xfs) are being
    careless about fh_len too, in fh_to_dentry() and/or fh_to_parent(), and
    could oops in the same way: add the missing fh_len checks to those.

    Reported-by: Sasha Levin <levinsasha928@gmail.com>
    Signed-off-by: Hugh Dickins <hughd@google.com>
    Cc: Al Viro <viro@zeniv.linux.org.uk>
    Cc: Sage Weil <sage@inktank.com>
    Cc: Steven Whitehouse <swhiteho@redhat.com>
    Cc: Christoph Hellwig <hch@infradead.org>
    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 15ad5eb87b2ed82c4a03ed79399165b9d45f3325
Author: Hugh Dickins <hughd@google.com>
Date:   Mon Oct 8 16:33:14 2012 -0700

    mm: fix invalidate_complete_page2() lock ordering

    commit ec4d9f626d5908b6052c2973f37992f1db52e967 upstream.

    In fuzzing with trinity, lockdep protested "possible irq lock inversion
    dependency detected" when isolate_lru_page() reenabled interrupts while
    still holding the supposedly irq-safe tree_lock:

    invalidate_inode_pages2
      invalidate_complete_page2
        spin_lock_irq(&mapping->tree_lock)
        clear_page_mlock
          isolate_lru_page
            spin_unlock_irq(&zone->lru_lock)

    isolate_lru_page() is correct to enable interrupts unconditionally:
    invalidate_complete_page2() is incorrect to call clear_page_mlock() while
    holding tree_lock, which is supposed to nest inside lru_lock.

    Both truncate_complete_page() and invalidate_complete_page() call
    clear_page_mlock() before taking tree_lock to remove page from radix_tree.
     I guess invalidate_complete_page2() preferred to test PageDirty (again)
    under tree_lock before committing to the munlock; but since the page has
    already been unmapped, its state is already somewhat inconsistent, and no
    worse if clear_page_mlock() moved up.

    Reported-by: Sasha Levin <levinsasha928@gmail.com>
    Deciphered-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Hugh Dickins <hughd@google.com>
    Acked-by: Mel Gorman <mel@csn.ul.ie>
    Cc: Rik van Riel <riel@redhat.com>
    Cc: Johannes Weiner <hannes@cmpxchg.org>
    Cc: Michel Lespinasse <walken@google.com>
    Cc: Ying Han <yinghan@google.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 a7d74f3b3dc429aba17f0a4cf30fc7fcb1ee74c0
Author: Li Haifeng <omycle@gmail.com>
Date:   Mon Sep 17 14:09:21 2012 -0700

    mm/page_alloc: fix the page address of higher page's buddy calculation

    commit 0ba8f2d59304dfe69b59c034de723ad80f7ab9ac upstream.

    The heuristic method for buddy has been introduced since commit
    43506fad21ca ("mm/page_alloc.c: simplify calculation of combined index
    of adjacent buddy lists").  But the page address of higher page's buddy
    was wrongly calculated, which will lead page_is_buddy to fail for ever.
    IOW, the heuristic method would be disabled with the wrong page address
    of higher page's buddy.

    Calculating the page address of higher page's buddy should be based
    higher_page with the offset between index of higher page and index of
    higher page's buddy.

    Signed-off-by: Haifeng Li <omycle@gmail.com>
    Signed-off-by: Gavin Shan <shangw@linux.vnet.ibm.com>
    Reviewed-by: Michal Hocko <mhocko@suse.cz>
    Cc: KyongHo Cho <pullip.cho@samsung.com>
    Cc: Mel Gorman <mgorman@suse.de>
    Cc: Minchan Kim <minchan.kim@gmail.com>
    Cc: Johannes Weiner <jweiner@redhat.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 3da7a59be07249cc9daf7a3676c722a25fc40a81
Author: Dave Jones <davej@redhat.com>
Date:   Thu Sep 6 12:01:00 2012 -0400

    Remove user-triggerable BUG from mpol_to_str

    commit 80de7c3138ee9fd86a98696fd2cf7ad89b995d0a upstream.

    Trivially triggerable, found by trinity:

      kernel BUG at mm/mempolicy.c:2546!
      Process trinity-child2 (pid: 23988, threadinfo ffff88010197e000, task ffff88007821a670)
      Call Trace:
        show_numa_map+0xd5/0x450
        show_pid_numa_map+0x13/0x20
        traverse+0xf2/0x230
        seq_read+0x34b/0x3e0
        vfs_read+0xac/0x180
        sys_pread64+0xa2/0xc0
        system_call_fastpath+0x1a/0x1f
      RIP: mpol_to_str+0x156/0x360

    Signed-off-by: Dave Jones <davej@redhat.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 8cc7d795a8cc7e247a885f220a4e7d5b69adef78
Author: Satoru Moriya <satoru.moriya@hds.com>
Date:   Tue May 29 15:06:47 2012 -0700

    mm: avoid swapping out with swappiness==0

    commit fe35004fbf9eaf67482b074a2e032abb9c89b1dd upstream.

    Sometimes we'd like to avoid swapping out anonymous memory.  In
    particular, avoid swapping out pages of important process or process
    groups while there is a reasonable amount of pagecache on RAM so that we
    can satisfy our customers' requirements.

    OTOH, we can control how aggressive the kernel will swap memory pages with
    /proc/sys/vm/swappiness for global and
    /sys/fs/cgroup/memory/memory.swappiness for each memcg.

    But with current reclaim implementation, the kernel may swap out even if
    we set swappiness=0 and there is pagecache in RAM.

    This patch changes the behavior with swappiness==0.  If we set
    swappiness==0, the kernel does not swap out completely (for global reclaim
    until the amount of free pages and filebacked pages in a zone has been
    reduced to something very very small (nr_free + nr_filebacked < high
    watermark)).

    Signed-off-by: Satoru Moriya <satoru.moriya@hds.com>
    Acked-by: Minchan Kim <minchan@kernel.org>
    Reviewed-by: Rik van Riel <riel@redhat.com>
    Acked-by: Jerome Marchand <jmarchan@redhat.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
     - vmscan_swappiness() does not have a zone parameter]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 4a12020206f90f5f97ddac9324bb02ae6680c441
Author: Andrew Morton <akpm@linux-foundation.org>
Date:   Tue May 29 15:06:31 2012 -0700

    mm/page_alloc.c: remove pageblock_default_order()

    commit 955c1cd7401565671b064e499115344ec8067dfd upstream.

    This has always been broken: one version takes an unsigned int and the
    other version takes no arguments.  This bug was hidden because one
    version of set_pageblock_order() was a macro which doesn't evaluate its
    argument.

    Simplify it all and remove pageblock_default_order() altogether.

    Reported-by: rajman mekaco <rajman.mekaco@gmail.com>
    Cc: Mel Gorman <mel@csn.ul.ie>
    Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
    Cc: Tejun Heo <tj@kernel.org>
    Cc: Minchan Kim <minchan.kim@gmail.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 47246985029162ea395bf087ba7dc24e96f17847
Author: Hugh Dickins <hughd@google.com>
Date:   Tue Jan 10 15:08:33 2012 -0800

    mm: test PageSwapBacked in lumpy reclaim

    commit 043bcbe5ec51e0478ef2b44acef17193e01d7f70 upstream.

    Stable note: Not tracked in Bugzilla. There were reports of shared
    	mapped pages being unfairly reclaimed in comparison to older kernels.
    	This is being addressed over time. Even though the subject
    	refers to lumpy reclaim, it impacts compaction as well.

    Lumpy reclaim does well to stop at a PageAnon when there's no swap, but
    better is to stop at any PageSwapBacked, which includes shmem/tmpfs too.

    Signed-off-by: Hugh Dickins <hughd@google.com>
    Reviewed-by: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
    Reviewed-by: Minchan Kim <minchan@kernel.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: Ben Hutchings <ben@decadent.org.uk>

commit 76f6fd4e158118a82bd4acbe46093d598a3c6e4d
Author: Minchan Kim <minchan@kernel.org>
Date:   Tue Jan 10 15:08:18 2012 -0800

    mm/vmscan.c: consider swap space when deciding whether to continue reclaim

    commit 86cfd3a45042ab242d47f3935a02811a402beab6 upstream.

    Stable note: Not tracked in Bugzilla. This patch reduces kswapd CPU
    	usage on swapless systems with high anonymous memory usage.

    It's pointless to continue reclaiming when we have no swap space and lots
    of anon pages in the inactive list.

    Without this patch, it is possible when swap is disabled to continue
    trying to reclaim when there are only anonymous pages in the system even
    though that will not make any progress.

    Signed-off-by: Minchan Kim <minchan@kernel.org>
    Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
    Acked-by: Mel Gorman <mgorman@suse.de>
    Reviewed-by: Rik van Riel <riel@redhat.com>
    Cc: Johannes Weiner <jweiner@redhat.com>
    Cc: Andrea Arcangeli <aarcange@redhat.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 9ea1bfb5c2d65f0194a6b227856ee81af6d72ee9
Author: Konstantin Khlebnikov <khlebnikov@openvz.org>
Date:   Tue Jan 10 15:07:03 2012 -0800

    vmscan: activate executable pages after first usage

    commit c909e99364c8b6ca07864d752950b6b4ecf6bef4 upstream.

    Stable note: Not tracked in Bugzilla. There were reports of shared
    	mapped pages being unfairly reclaimed in comparison to older kernels.
    	This is being addressed over time.

    Logic added in commit 8cab4754d24a0 ("vmscan: make mapped executable pages
    the first class citizen") was noticeably weakened in commit
    645747462435d84 ("vmscan: detect mapped file pages used only once").

    Currently these pages can become "first class citizens" only after second
    usage.  After this patch page_check_references() will activate they after
    first usage, and executable code gets yet better chance to stay in memory.

    Signed-off-by: Konstantin Khlebnikov <khlebnikov@openvz.org>
    Cc: Pekka Enberg <penberg@kernel.org>
    Cc: Minchan Kim <minchan.kim@gmail.com>
    Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
    Cc: Wu Fengguang <fengguang.wu@intel.com>
    Cc: Johannes Weiner <hannes@cmpxchg.org>
    Cc: Nick Piggin <npiggin@kernel.dk>
    Cc: Mel Gorman <mel@csn.ul.ie>
    Cc: Shaohua Li <shaohua.li@intel.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: Ben Hutchings <ben@decadent.org.uk>

commit a633c52ffa8f7b6caa31a3e44812598295edc890
Author: Konstantin Khlebnikov <khlebnikov@openvz.org>
Date:   Tue Jan 10 15:06:59 2012 -0800

    vmscan: promote shared file mapped pages

    commit 34dbc67a644f11ab3475d822d72e25409911e760 upstream.

    Stable note: Not tracked in Bugzilla. There were reports of shared
    	mapped pages being unfairly reclaimed in comparison to older kernels.
    	This is being addressed over time. The specific workload being
    	addressed here in described in paragraph four and while paragraph
    	five says it did not help performance as such, it made a difference
    	to major page faults. I'm aware of at least one bug for a large
    	vendor that was due to increased major faults.

    Commit 645747462435 ("vmscan: detect mapped file pages used only once")
    greatly decreases lifetime of single-used mapped file pages.
    Unfortunately it also decreases life time of all shared mapped file
    pages.  Because after commit bf3f3bc5e7347 ("mm: don't mark_page_accessed
    in fault path") page-fault handler does not mark page active or even
    referenced.

    Thus page_check_references() activates file page only if it was used twice
    while it stays in inactive list, meanwhile it activates anon pages after
    first access.  Inactive list can be small enough, this way reclaimer can
    accidentally throw away any widely used page if it wasn't used twice in
    short period.

    After this patch page_check_references() also activate file mapped page at
    first inactive list scan if this page is already used multiple times via
    several ptes.

    I found this while trying to fix degragation in rhel6 (~2.6.32) from rhel5
    (~2.6.18).  There a complete mess with >100 web/mail/spam/ftp containers,
    they share all their files but there a lot of anonymous pages: ~500mb
    shared file mapped memory and 15-20Gb non-shared anonymous memory.  In
    this situation major-pagefaults are very costly, because all containers
    share the same page.  In my load kernel created a disproportionate
    pressure on the file memory, compared with the anonymous, they equaled
    only if I raise swappiness up to 150 =)

    These patches actually wasn't helped a lot in my problem, but I saw
    noticable (10-20 times) reduce in count and average time of
    major-pagefault in file-mapped areas.

    Actually both patches are fixes for commit v2.6.33-5448-g6457474, because
    it was aimed at one scenario (singly used pages), but it breaks the logic
    in other scenarios (shared and/or executable pages)

    Signed-off-by: Konstantin Khlebnikov <khlebnikov@openvz.org>
    Acked-by: Pekka Enberg <penberg@kernel.org>
    Acked-by: Minchan Kim <minchan.kim@gmail.com>
    Reviewed-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
    Cc: Wu Fengguang <fengguang.wu@intel.com>
    Cc: Johannes Weiner <hannes@cmpxchg.org>
    Cc: Nick Piggin <npiggin@kernel.dk>
    Cc: Mel Gorman <mel@csn.ul.ie>
    Cc: Shaohua Li <shaohua.li@intel.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: Ben Hutchings <ben@decadent.org.uk>

commit 0b9398fa9d8cf6804f1e2a1341594cd744d860aa
Author: Mel Gorman <mgorman@suse.de>
Date:   Tue Jan 10 15:07:14 2012 -0800

    mm: reduce the amount of work done when updating min_free_kbytes

    commit 938929f14cb595f43cd1a4e63e22d36cab1e4a1f upstream.

    Stable note: Fixes https://bugzilla.novell.com/show_bug.cgi?id=726210 .
            Large machines with 1TB or more of RAM take a long time to boot
            without this patch and may spew out soft lockup warnings.

    When min_free_kbytes is updated, some pageblocks are marked
    MIGRATE_RESERVE.  Ordinarily, this work is unnoticable as it happens early
    in boot but on large machines with 1TB of memory, this has been reported
    to delay boot times, probably due to the NUMA distances involved.

    The bulk of the work is due to calling calling pageblock_is_reserved() an
    unnecessary amount of times and accessing far more struct page metadata
    than is necessary.  This patch significantly reduces the amount of work
    done by setup_zone_migrate_reserve() improving boot times on 1TB machines.

    [akpm@linux-foundation.org: coding-style fixes]
    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: Ben Hutchings <ben@decadent.org.uk>

commit 714a0d735eb15edd7d0f8170714faf2a4b1bffc2
Author: Aaditya Kumar <aaditya.kumar.30@gmail.com>
Date:   Tue Jul 17 15:48:07 2012 -0700

    mm: fix lost kswapd wakeup in kswapd_stop()

    commit 1c7e7f6c0703d03af6bcd5ccc11fc15d23e5ecbe upstream.

    Offlining memory may block forever, waiting for kswapd() to wake up
    because kswapd() does not check the event kthread->should_stop before
    sleeping.

    The proper pattern, from Documentation/memory-barriers.txt, is:

       ---  waker  ---
       event_indicated = 1;
       wake_up_process(event_daemon);

       ---  sleeper  ---
       for (;;) {
          set_current_state(TASK_UNINTERRUPTIBLE);
          if (event_indicated)
             break;
          schedule();
       }

       set_current_state() may be wrapped by:
          prepare_to_wait();

    In the kswapd() case, event_indicated is kthread->should_stop.

      === offlining memory (waker) ===
       kswapd_stop()
          kthread_stop()
             kthread->should_stop = 1
             wake_up_process()
             wait_for_completion()

      ===  kswapd_try_to_sleep (sleeper) ===
       kswapd_try_to_sleep()
          prepare_to_wait()
               .
               .
          schedule()
               .
               .
          finish_wait()

    The schedule() needs to be protected by a test of kthread->should_stop,
    which is wrapped by kthread_should_stop().

    Reproducer:
       Do heavy file I/O in background.
       Do a memory offline/online in a tight loop

    Signed-off-by: Aaditya Kumar <aaditya.kumar@ap.sony.com>
    Acked-by: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
    Reviewed-by: Minchan Kim <minchan@kernel.org>
    Acked-by: Mel Gorman <mel@csn.ul.ie>
    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 a5badc085fcbab5394926b7e0a8d9649510fca39
Author: Andy Lutomirski <luto@amacapital.net>
Date:   Thu Jul 5 16:00:11 2012 -0700

    mm: Hold a file reference in madvise_remove

    commit 9ab4233dd08036fe34a89c7dc6f47a8bf2eb29eb upstream.

    Otherwise the code races with munmap (causing a use-after-free
    of the vma) or with close (causing a use-after-free of the struct
    file).

    The bug was introduced by commit 90ed52ebe481 ("[PATCH] holepunch: fix
    mmap_sem i_mutex deadlock")

    Cc: Hugh Dickins <hugh@veritas.com>
    Cc: Miklos Szeredi <mszeredi@suse.cz>
    Cc: Badari Pulavarty <pbadari@us.ibm.com>
    Cc: Nick Piggin <npiggin@suse.de>
    Signed-off-by: Andy Lutomirski <luto@amacapital.net>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    [bwh: Backported to 3.2:
     - Adjust context
     - madvise_remove() calls vmtruncate_range(), not do_fallocate()]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 29c420ec2066d487503cb05e49a3f359c7db1224
Author: Eric Dumazet <edumazet@google.com>
Date:   Tue Jun 12 15:24:40 2012 +0200

    splice: fix racy pipe->buffers uses

    commit 047fe3605235888f3ebcda0c728cb31937eadfe6 upstream.

    Dave Jones reported a kernel BUG at mm/slub.c:3474! triggered
    by splice_shrink_spd() called from vmsplice_to_pipe()

    commit 35f3d14dbbc5 (pipe: add support for shrinking and growing pipes)
    added capability to adjust pipe->buffers.

    Problem is some paths don't hold pipe mutex and assume pipe->buffers
    doesn't change for their duration.

    Fix this by adding nr_pages_max field in struct splice_pipe_desc, and
    use it in place of pipe->buffers where appropriate.

    splice_shrink_spd() loses its struct pipe_inode_info argument.

    Reported-by: Dave Jones <davej@redhat.com>
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Cc: Jens Axboe <axboe@kernel.dk>
    Cc: Alexander Viro <viro@zeniv.linux.org.uk>
    Cc: Tom Herbert <therbert@google.com>
    Tested-by: Dave Jones <davej@redhat.com>
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    [bwh: Backported to 3.2:
     - Adjust context in vmsplice_to_pipe()
     - Update one more call to splice_shrink_spd(), from skb_splice_bits()]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 3a9e9e7686497dd67db6014305ca97ba5c1a8631
Author: Hugh Dickins <hughd@google.com>
Date:   Fri Jun 15 17:55:50 2012 -0700

    swap: fix shmem swapping when more than 8 areas

    commit 9b15b817f3d62409290fd56fe3cbb076a931bb0a upstream.

    Minchan Kim reports that when a system has many swap areas, and tmpfs
    swaps out to the ninth or more, shmem_getpage_gfp()'s attempts to read
    back the page cannot locate it, and the read fails with -ENOMEM.

    Whoops.  Yes, I blindly followed read_swap_header()'s pte_to_swp_entry(
    swp_entry_to_pte()) technique for determining maximum usable swap
    offset, without stopping to realize that that actually depends upon the
    pte swap encoding shifting swap offset to the higher bits and truncating
    it there.  Whereas our radix_tree swap encoding leaves offset in the
    lower bits: it's swap "type" (that is, index of swap area) that was
    truncated.

    Fix it by reducing the SWP_TYPE_SHIFT() in swapops.h, and removing the
    broken radix_to_swp_entry(swp_to_radix_entry()) from read_swap_header().

    This does not reduce the usable size of a swap area any further, it
    leaves it as claimed when making the original commit: no change from 3.0
    on x86_64, nor on i386 without PAE; but 3.0's 512GB is reduced to 128GB
    per swapfile on i386 with PAE.  It's not a change I would have risked
    five years ago, but with x86_64 supported for ten years, I believe it's
    appropriate now.

    Hmm, and what if some architecture implements its swap pte with offset
    encoded below type? That would equally break the maximum usable swap
    offset check.  Happily, they all follow the same tradition of encoding
    offset above type, but I'll prepare a check on that for next.

    Reported-and-Reviewed-and-Tested-by: Minchan Kim <minchan@kernel.org>
    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 be39cbdc9282cecbe060750db75ad8c80573d263
Author: KyongHo <pullip.cho@samsung.com>
Date:   Tue May 29 15:06:49 2012 -0700

    mm: fix faulty initialization in vmalloc_init()

    commit dbda591d920b4c7692725b13e3f68ecb251e9080 upstream.

    The transfer of ->flags causes some of the static mapping virtual
    addresses to be prematurely freed (before the mapping is removed) because
    VM_LAZY_FREE gets "set" if tmp->flags has VM_IOREMAP set.  This might
    cause subsequent vmalloc/ioremap calls to fail because it might allocate
    one of the freed virtual address ranges that aren't unmapped.

    va->flags has different types of flags from tmp->flags.  If a region with
    VM_IOREMAP set is registered with vm_area_add_early(), it will be removed
    by __purge_vmap_area_lazy().

    Fix vmalloc_init() to correctly initialize vmap_area for the given
    vm_struct.

    Also initialise va->vm.  If it is not set, find_vm_area() for the early
    vm regions will always fail.

    Signed-off-by: KyongHo Cho <pullip.cho@samsung.com>
    Cc: "Olav Haugan" <ohaugan@codeaurora.org>
    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 8d7abc8845574019bf9d505ebe93d386ccb73311
Author: Minchan Kim <minchan@kernel.org>
Date:   Tue Jan 10 15:08:39 2012 -0800

    mm/vmalloc.c: change void* into explict vm_struct*

    commit db1aecafef58b5dda39c4228debe2c845e4a27ab upstream.

    vmap_area->private is void* but we don't use the field for various purpose
    but use only for vm_struct.  So change it to a vm_struct* with naming to
    improve for readability and type checking.

    Signed-off-by: Minchan Kim <minchan@kernel.org>
    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: Ben Hutchings <ben@decadent.org.uk>

commit 4838a8cef448f1a6b854c5ce5e675aec6864322e
Author: Michal Hocko <mhocko@suse.cz>
Date:   Tue May 29 15:06:45 2012 -0700

    mm: consider all swapped back pages in used-once logic

    commit e48982734ea0500d1eba4f9d96195acc5406cad6 upstream.

    Commit 645747462435 ("vmscan: detect mapped file pages used only once")
    made mapped pages have another round in inactive list because they might
    be just short lived and so we could consider them again next time.  This
    heuristic helps to reduce pressure on the active list with a streaming
    IO worklods.

    This patch fixes a regression introduced by this commit for heavy shmem
    based workloads because unlike Anon pages, which are excluded from this
    heuristic because they are usually long lived, shmem pages are handled
    as a regular page cache.

    This doesn't work quite well, unfortunately, if the workload is mostly
    backed by shmem (in memory database sitting on 80% of memory) with a
    streaming IO in the background (backup - up to 20% of memory).  Anon
    inactive list is full of (dirty) shmem pages when watermarks are hit.
    Shmem pages are kept in the inactive list (they are referenced) in the
    first round and it is hard to reclaim anything else so we reach lower
    scanning priorities very quickly which leads to an excessive swap out.

    Let's fix this by excluding all swap backed pages (they tend to be long
    lived wrt.  the regular page cache anyway) from used-once heuristic and
    rather activate them if they are referenced.

    The customer's workload is shmem backed database (80% of RAM) and they
    are measuring transactions/s with an IO in the background (20%).
    Transactions touch more or less random rows in the table.  The
    transaction rate fell by a factor of 3 (in the worst case) because of
    commit 64574746.  This patch restores the previous numbers.

    Signed-off-by: Michal Hocko <mhocko@suse.cz>
    Acked-by: Johannes Weiner <hannes@cmpxchg.org>
    Cc: Mel Gorman <mel@csn.ul.ie>
    Cc: Minchan Kim <minchan@kernel.org>
    Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
    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: Ben Hutchings <ben@decadent.org.uk>

commit b90702ba6774ddc2d25c80b42c396f8f4dad4980
Author: Shaohua Li <shli@kernel.org>
Date:   Wed Mar 21 16:34:17 2012 -0700

    swap: don't do discard if no discard option added

    commit 052b1987faca3606109d88d96bce124851f7c4c2 upstream.

    When swapon() was not passed the SWAP_FLAG_DISCARD option, sys_swapon()
    will still perform a discard operation.  This can cause problems if
    discard is slow or buggy.

    Reverse the order of the check so that a discard operation is performed
    only if the sys_swapon() caller is attempting to enable discard.

    Signed-off-by: Shaohua Li <shli@fusionio.com>
    Reported-by: Holger Kiehl <Holger.Kiehl@dwd.de>
    Tested-by: Holger Kiehl <Holger.Kiehl@dwd.de>
    Cc: Hugh Dickins <hughd@google.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 e13a0d5655b3963b5fd1b50cdb4736a7840f8c18
Author: Tejun Heo <tj@kernel.org>
Date:   Fri Apr 27 08:42:53 2012 -0700

    percpu: pcpu_embed_first_chunk() should free unused parts after all allocs are complete

    commit 42b64281453249dac52861f9b97d18552a7ec62b upstream.

    pcpu_embed_first_chunk() allocates memory for each node, copies percpu
    data and frees unused portions of it before proceeding to the next
    group.  This assumes that allocations for different nodes doesn't
    overlap; however, depending on memory topology, the bootmem allocator
    may end up allocating memory from a different node than the requested
    one which may overlap with the portion freed from one of the previous
    percpu areas.  This leads to percpu groups for different nodes
    overlapping which is a serious bug.

    This patch separates out copy & partial free from the allocation loop
    such that all allocations are complete before partial frees happen.

    This also fixes overlapping frees which could happen on allocation
    failure path - out_free_areas path frees whole groups but the groups
    could have portions freed at that point.

    Signed-off-by: Tejun Heo <tj@kernel.org>
    Reported-by: "Pavel V. Panteleev" <pp_84@mail.ru>
    Tested-by: "Pavel V. Panteleev" <pp_84@mail.ru>
    LKML-Reference: <E1SNhwY-0007ui-V7.pp_84-mail-ru@f220.mail.ru>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 62c7f55136be1f852bc56d5b101891bebf9cc7d7
Author: Hugh Dickins <hughd@google.com>
Date:   Mon Apr 23 11:14:50 2012 -0700

    mm: fix s390 BUG by __set_page_dirty_no_writeback on swap

    commit aca50bd3b4c4bb5528a1878158ba7abce41de534 upstream.

    Mel reports a BUG_ON(slot == NULL) in radix_tree_tag_set() on s390
    3.0.13: called from __set_page_dirty_nobuffers() when page_remove_rmap()
    tries to transfer dirty flag from s390 storage key to struct page and
    radix_tree.

    That would be because of reclaim's shrink_page_list() calling
    add_to_swap() on this page at the same time: first PageSwapCache is set
    (causing page_mapping(page) to appear as &swapper_space), then
    page->private set, then tree_lock taken, then page inserted into
    radix_tree - so there's an interval before taking the lock when the
    radix_tree slot is empty.

    We could fix this by moving __add_to_swap_cache()'s spin_lock_irq up
    before the SetPageSwapCache.  But a better fix is simply to do what's
    five years overdue: Ken Chen introduced __set_page_dirty_no_writeback()
    (if !PageDirty TestSetPageDirty) for tmpfs to skip all the radix_tree
    overhead, and swap is just the same - it ignores the radix_tree tag, and
    does not participate in dirty page accounting, so should be using
    __set_page_dirty_no_writeback() too.

    s390 testing now confirms that this does indeed fix the problem.

    Reported-by: Mel Gorman <mgorman@suse.de>
    Signed-off-by: Hugh Dickins <hughd@google.com>
    Acked-by: Mel Gorman <mgorman@suse.de>
    Cc: Andrew Morton <akpm@linux-foundation.org>
    Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
    Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
    Cc: Rik van Riel <riel@redhat.com>
    Cc: Ken Chen <kenchen@google.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit da4cd280bad38db4aa36ae79a2ff8b7edde14a95
Author: David Howells <dhowells@redhat.com>
Date:   Thu Feb 23 13:51:00 2012 +0000

    NOMMU: Don't need to clear vm_mm when deleting a VMA

    commit b94cfaf6685d691dc3fab023cf32f65e9b7be09c upstream.

    Don't clear vm_mm in a deleted VMA as it's unnecessary and might
    conceivably break the filesystem or driver VMA close routine.

    Reported-by: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: David Howells <dhowells@redhat.com>
    Acked-by: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 30d4e475bb66e66236511078edf3e7c230554021
Author: David Howells <dhowells@redhat.com>
Date:   Thu Feb 23 13:50:35 2012 +0000

    NOMMU: Lock i_mmap_mutex for access to the VMA prio list

    commit 918e556ec214ed2f584e4cac56d7b29e4bb6bf27 upstream.

    Lock i_mmap_mutex for access to the VMA prio list to prevent concurrent
    access.  Currently, certain parts of the mmap handling are protected by
    the region mutex, but not all.

    Reported-by: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: David Howells <dhowells@redhat.com>
    Acked-by: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 53b1036598106e5f325247a23386590e18a30296
Author: Rabin Vincent <rabin@rab.in>
Date:   Sun Jan 29 12:17:33 2012 -0600

    backing-dev: fix wakeup timer races with bdi_unregister()

    commit 2673b4cf5d59c3ee5e0c12f6d734d38770324dc4 upstream.

    While 7a401a972df8e18 ("backing-dev: ensure wakeup_timer is deleted")
    addressed the problem of the bdi being freed with a queued wakeup
    timer, there are other races that could happen if the wakeup timer
    expires after/during bdi_unregister(), before bdi_destroy() is called.

    wakeup_timer_fn() could attempt to wakeup a task which has already has
    been freed, or could access a NULL bdi->dev via the wake_forker_thread
    tracepoint.

    Cc: Jens Axboe <axboe@kernel.dk>
    Reported-by: Chanho Min <chanho.min@lge.com>
    Reviewed-by: Namjae Jeon <linkinjeon@gmail.com>
    Signed-off-by: Rabin Vincent <rabin@rab.in>
    Signed-off-by: Wu Fengguang <fengguang.wu@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4270d08272d8a153e78b01e6e8acff18d10f988b
Author: Carsten Otte <carsteno@de.ibm.com>
Date:   Fri Feb 3 15:37:14 2012 -0800

    mm/filemap_xip.c: fix race condition in xip_file_fault()

    commit 99f02ef1f18631eb0a4e0ea0a3d56878dbcb4b90 upstream.

    Fix a race condition that shows in conjunction with xip_file_fault() when
    two threads of the same user process fault on the same memory page.

    In this case, the race winner will install the page table entry and the
    unlucky loser will cause an oops: xip_file_fault calls vm_insert_pfn (via
    vm_insert_mixed) which drops out at this check:

    	retval = -EBUSY;
    	if (!pte_none(*pte))
    		goto out_unlock;

    The resulting -EBUSY return value will trigger a BUG_ON() in
    xip_file_fault.

    This fix simply considers the fault as fixed in this case, because the
    race winner has successfully installed the pte.

    [akpm@linux-foundation.org: use conventional (and consistent) comment layout]
    Reported-by: David Sadler <dsadler@us.ibm.com>
    Signed-off-by: Carsten Otte <cotte@de.ibm.com>
    Reported-by: Louis Alex Eisner <leisner@cs.ucsd.edu>
    Cc: Hugh Dickins <hughd@google.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 63e8328cf6ca009f246bc30b043af30e11376c7d
Author: Shaohua Li <shaohua.li@intel.com>
Date:   Fri Feb 3 15:37:17 2012 -0800

    readahead: fix pipeline break caused by block plug

    commit 3deaa7190a8da38453c4fabd9dec7f66d17fff67 upstream.

    Herbert Poetzl reported a performance regression since 2.6.39.  The test
    is a simple dd read, but with big block size.  The reason is:

    T1: ra (A, A+128k), (A+128k, A+256k)
    T2: lock_page for page A, submit the 256k
    T3: hit page A+128K, ra (A+256k, A+384). the range isn't submitted
    because of plug and there isn't any lock_page till we hit page A+256k
    because all pages from A to A+256k is in memory
    T4: hit page A+256k, ra (A+384, A+ 512). Because of plug, the range isn't
    submitted again.
    T5: lock_page A+256k, so (A+256k, A+512k) will be submitted. The task is
    waitting for (A+256k, A+512k) finish.

    There is no request to disk in T3 and T4, so readahead pipeline breaks.

    We really don't need block plug for generic_file_aio_read() for buffered
    I/O.  The readahead already has plug and has fine grained control when I/O
    should be submitted.  Deleting plug for buffered I/O fixes the regression.

    One side effect is plug makes the request size 256k, the size is 128k
    without it.  This is because default ra size is 128k and not a reason we
    need plug here.

    Vivek said:

    : We submit some readahead IO to device request queue but because of nested
    : plug, queue never gets unplugged.  When read logic reaches a page which is
    : not in page cache, it waits for page to be read from the disk
    : (lock_page_killable()) and that time we flush the plug list.
    :
    : So effectively read ahead logic is kind of broken in parts because of
    : nested plugging.  Removing top level plug (generic_file_aio_read()) for
    : buffered reads, will allow unplugging queue earlier for readahead.

    Signed-off-by: Shaohua Li <shaohua.li@intel.com>
    Signed-off-by: Wu Fengguang <fengguang.wu@intel.com>
    Reported-by: Herbert Poetzl <herbert@13thfloor.at>
    Tested-by: Eric Dumazet <eric.dumazet@gmail.com>
    Cc: Christoph Hellwig <hch@infradead.org>
    Cc: Jens Axboe <axboe@kernel.dk>
    Cc: Vivek Goyal <vgoyal@redhat.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3b4930faee7b2388a7eb8b768a92f117a59aea13
Author: Michal Hocko <mhocko@suse.cz>
Date:   Fri Jan 20 14:33:55 2012 -0800

    mm: fix NULL ptr dereference in __count_immobile_pages

    commit 687875fb7de4a95223af20ee024282fa9099f860 upstream.

    Fix the following NULL ptr dereference caused by

      cat /sys/devices/system/memory/memory0/removable

    Pid: 13979, comm: sed Not tainted 3.0.13-0.5-default #1 IBM BladeCenter LS21 -[7971PAM]-/Server Blade
    RIP: __count_immobile_pages+0x4/0x100
    Process sed (pid: 13979, threadinfo ffff880221c36000, task ffff88022e788480)
    Call Trace:
      is_pageblock_removable_nolock+0x34/0x40
      is_mem_section_removable+0x74/0xf0
      show_mem_removable+0x41/0x70
      sysfs_read_file+0xfe/0x1c0
      vfs_read+0xc7/0x130
      sys_read+0x53/0xa0
      system_call_fastpath+0x16/0x1b

    We are crashing because we are trying to dereference NULL zone which
    came from pfn=0 (struct page ffffea0000000000). According to the boot
    log this page is marked reserved:
    e820 update range: 0000000000000000 - 0000000000010000 (usable) ==> (reserved)

    and early_node_map confirms that:
    early_node_map[3] active PFN ranges
        1: 0x00000010 -> 0x0000009c
        1: 0x00000100 -> 0x000bffa3
        1: 0x00100000 -> 0x00240000

    The problem is that memory_present works in PAGE_SECTION_MASK aligned
    blocks so the reserved range sneaks into the the section as well.  This
    also means that free_area_init_node will not take care of those reserved
    pages and they stay uninitialized.

    When we try to read the removable status we walk through all available
    sections and hope that the zone is valid for all pages in the section.
    But this is not true in this case as the zone and nid are not initialized.

    We have only one node in this particular case and it is marked as node=1
    (rather than 0) and that made the problem visible because page_to_nid will
    return 0 and there are no zones on the node.

    Let's check that the zone is valid and that the given pfn falls into its
    boundaries and mark the section not removable.  This might cause some
    false positives, probably, but we do not have any sane way to find out
    whether the page is reserved by the platform or it is just not used for
    whatever other reasons.

    Signed-off-by: Michal Hocko <mhocko@suse.cz>
    Acked-by: Mel Gorman <mgorman@suse.de>
    Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
    Cc: Andrea Arcangeli <aarcange@redhat.com>
    Cc: 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: Greg Kroah-Hartman <gregkh@suse.de>

commit b0887000f93f9dce48be9ef61dd88425c3b5aab2
Author: Andrew Morton <akpm@linux-foundation.org>
Date:   Mon Oct 31 17:13:08 2011 -0700

    llist-return-whether-list-is-empty-before-adding-in-llist_add-fix

    clarify comment

    Cc: Huang Ying <ying.huang@intel.com>
    Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.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>

commit eac930d6d70a526f15065cbf81a89364df874f14
Author: Stephen Rothwell <sfr@canb.auug.org.au>
Date:   Wed Oct 5 17:25:28 2011 +1100

    llist: Add back llist_add_batch() and llist_del_first() prototypes

    Commit 1230db8e1543 ("llist: Make some llist functions inline")
    has deleted the definitions, causing problems for (not upstream yet)
    code that tries to make use of them.

    Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
    Acked-by: Peter Zijlstra <peterz@infradead.org>
    Cc: Huang Ying <ying.huang@intel.com>
    Cc: David Miller <davem@davemloft.net>
    Link: http://lkml.kernel.org/r/20111005172528.0d0a8afc65acef7ace22a24e@canb.auug.org.au
    Signed-off-by: Ingo Molnar <mingo@elte.hu>

commit 7b4ff096f57543f427909f326ebcc2e6dc3f1508
Author: Peter Zijlstra <a.p.zijlstra@chello.nl>
Date:   Mon Sep 12 15:50:49 2011 +0200

    llist: Remove cpu_relax() usage in cmpxchg loops

    Initial benchmarks show they're a net loss:

     $ for i in /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor ; do echo performance > $i; done
     $ echo 4096 32000 64 128 > /proc/sys/kernel/sem
     $ ./sembench -t 2048 -w 1900 -o 0

    Pre:

     run time 30 seconds 778936 worker burns per second
     run time 30 seconds 912190 worker burns per second
     run time 30 seconds 817506 worker burns per second
     run time 30 seconds 830870 worker burns per second
     run time 30 seconds 845056 worker burns per second

    Post:

     run time 30 seconds 905920 worker burns per second
     run time 30 seconds 849046 worker burns per second
     run time 30 seconds 886286 worker burns per second
     run time 30 seconds 822320 worker burns per second
     run time 30 seconds 900283 worker burns per second

    So about 4% faster. (!)

    cpu_relax() stalls the pipeline, therefore, when used in a tight loop
    it has the following benefits:

     - allows SMT siblings to have a go;
     - reduces pressure on the CPU interconnect.

    However, cmpxchg loops are unfair and thus have unbounded completion
    time, therefore we should avoid getting in such heavily contended
    situations where the above benefits make any difference.

    A typical cmpxchg loop should not go round more than a handfull of
    times at worst, therefore adding extra delays just slows things down.

    Since the llist primitives are new, there aren't any bad users yet,
    and we should avoid growing them. Heavily contended sites should
    generally be better off using the ticket locks for serialization since
    they provide bounded completion times (fifo-fair over the cpus).

    Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
    Cc: Huang Ying <ying.huang@intel.com>
    Cc: Andrew Morton <akpm@linux-foundation.org>
    Link: http://lkml.kernel.org/r/1315836358.26517.43.camel@twins
    Signed-off-by: Ingo Molnar <mingo@elte.hu>

commit d5fda78fcdba1da119ed6d37b694d386fc52c1be
Author: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
Date:   Thu May 24 19:46:26 2012 +0530

    CPU hotplug, cpusets, suspend: Don't modify cpusets during suspend/resume

    commit d35be8bab9b0ce44bed4b9453f86ebf64062721e upstream.

    In the event of CPU hotplug, the kernel modifies the cpusets' cpus_allowed
    masks as and when necessary to ensure that the tasks belonging to the cpusets
    have some place (online CPUs) to run on. And regular CPU hotplug is
    destructive in the sense that the kernel doesn't remember the original cpuset
    configurations set by the user, across hotplug operations.

    However, suspend/resume (which uses CPU hotplug) is a special case in which
    the kernel has the responsibility to restore the system (during resume), to
    exactly the same state it was in before suspend.

    In order to achieve that, do the following:

    1. Don't modify cpusets during suspend/resume. At all.
       In particular, don't move the tasks from one cpuset to another, and
       don't modify any cpuset's cpus_allowed mask. So, simply ignore cpusets
       during the CPU hotplug operations that are carried out in the
       suspend/resume path.

    2. However, cpusets and sched domains are related. We just want to avoid
       altering cpusets alone. So, to keep the sched domains updated, build
       a single sched domain (containing all active cpus) during each of the
       CPU hotplug operations carried out in s/r path, effectively ignoring
       the cpusets' cpus_allowed masks.

       (Since userspace is frozen while doing all this, it will go unnoticed.)

    3. During the last CPU online operation during resume, build the sched
       domains by looking up the (unaltered) cpusets' cpus_allowed masks.
       That will bring back the system to the same original state as it was in
       before suspend.

    Ultimately, this will not only solve the cpuset problem related to suspend
    resume (ie., restores the cpusets to exactly what it was before suspend, by
    not touching it at all) but also speeds up suspend/resume because we avoid
    running cpuset update code for every CPU being offlined/onlined.

    Signed-off-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
    Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Andrew Morton <akpm@linux-foundation.org>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Link: http://lkml.kernel.org/r/20120524141611.3692.20155.stgit@srivatsabhat.in.ibm.com
    [Preeti U Murthy: Please apply this patch to the stable tree 3.0.y]
    Signed-off-by: Preeti U Murthy <preeti@linux.vnet.ibm.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 3cd5ef52807e71e0c31d2056c46db1a4d9357b60
Author: Stanislaw Gruszka <sgruszka@redhat.com>
Date:   Wed Aug 8 11:27:15 2012 +0200

    sched: fix divide by zero at {thread_group,task}_times

    commit bea6832cc8c4a0a9a65dd17da6aaa657fe27bc3e upstream.

    On architectures where cputime_t is 64 bit type, is possible to trigger
    divide by zero on do_div(temp, (__force u32) total) line, if total is a
    non zero number but has lower 32 bit's zeroed. Removing casting is not
    a good solution since some do_div() implementations do cast to u32
    internally.

    This problem can be triggered in practice on very long lived processes:

      PID: 2331   TASK: ffff880472814b00  CPU: 2   COMMAND: "oraagent.bin"
       #0 [ffff880472a51b70] machine_kexec at ffffffff8103214b
       #1 [ffff880472a51bd0] crash_kexec at ffffffff810b91c2
       #2 [ffff880472a51ca0] oops_end at ffffffff814f0b00
       #3 [ffff880472a51cd0] die at ffffffff8100f26b
       #4 [ffff880472a51d00] do_trap at ffffffff814f03f4
       #5 [ffff880472a51d60] do_divide_error at ffffffff8100cfff
       #6 [ffff880472a51e00] divide_error at ffffffff8100be7b
          [exception RIP: thread_group_times+0x56]
          RIP: ffffffff81056a16  RSP: ffff880472a51eb8  RFLAGS: 00010046
          RAX: bc3572c9fe12d194  RBX: ffff880874150800  RCX: 0000000110266fad
          RDX: 0000000000000000  RSI: ffff880472a51eb8  RDI: 001038ae7d9633dc
          RBP: ffff880472a51ef8   R8: 00000000b10a3a64   R9: ffff880874150800
          R10: 00007fcba27ab680  R11: 0000000000000202  R12: ffff880472a51f08
          R13: ffff880472a51f10  R14: 0000000000000000  R15: 0000000000000007
          ORIG_RAX: ffffffffffffffff  CS: 0010  SS: 0018
       #7 [ffff880472a51f00] do_sys_times at ffffffff8108845d
       #8 [ffff880472a51f40] sys_times at ffffffff81088524
       #9 [ffff880472a51f80] system_call_fastpath at ffffffff8100b0f2
          RIP: 0000003808caac3a  RSP: 00007fcba27ab6d8  RFLAGS: 00000202
          RAX: 0000000000000064  RBX: ffffffff8100b0f2  RCX: 0000000000000000
          RDX: 00007fcba27ab6e0  RSI: 000000000076d58e  RDI: 00007fcba27ab6e0
          RBP: 00007fcba27ab700   R8: 0000000000000020   R9: 000000000000091b
          R10: 00007fcba27ab680  R11: 0000000000000202  R12: 00007fff9ca41940
          R13: 0000000000000000  R14: 00007fcba27ac9c0  R15: 00007fff9ca41940
          ORIG_RAX: 0000000000000064  CS: 0033  SS: 002b

    Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
    Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
    Link: http://lkml.kernel.org/r/20120808092714.GA3580@redhat.com
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    [bwh: Backported to 3.2:
     - Adjust filename
     - Most conversions in the original code are implicit]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit adba36d2dd6cce5aababa2a7da133807a96eca8b
Author: Peter Zijlstra <peterz@infradead.org>
Date:   Fri Jun 22 13:36:05 2012 +0200

    sched: Fix race in task_group()

    commit 8323f26ce3425460769605a6aece7a174edaa7d1 upstream

    Stefan reported a crash on a kernel before a3e5d1091c1 ("sched:
    Don't call task_group() too many times in set_task_rq()"), he
    found the reason to be that the multiple task_group()
    invocations in set_task_rq() returned different values.

    Looking at all that I found a lack of serialization and plain
    wrong comments.

    The below tries to fix it using an extra pointer which is
    updated under the appropriate scheduler locks. Its not pretty,
    but I can't really see another way given how all the cgroup
    stuff works.

    Reported-and-tested-by: Stefan Bader <stefan.bader@canonical.com>
    Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
    Link: http://lkml.kernel.org/r/1340364965.18025.71.camel@twins
    Signed-off-by: Ingo Molnar <mingo@kernel.org>

    (backported to previous file names and layout)
    Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 9f1b290cf00233e2a4bfbb8197f09a049351716a
Author: Peter Zijlstra <a.p.zijlstra@chello.nl>
Date:   Thu May 17 17:15:29 2012 +0200

    sched/nohz: Fix rq->cpu_load calculations some more

    commit 5aaa0b7a2ed5b12692c9ffb5222182bd558d3146 upstream.

    Follow up on commit 556061b00 ("sched/nohz: Fix rq->cpu_load[]
    calculations") since while that fixed the busy case it regressed the
    mostly idle case.

    Add a callback from the nohz exit to also age the rq->cpu_load[]
    array. This closes the hole where either there was no nohz load
    balance pass during the nohz, or there was a 'significant' amount of
    idle time between the last nohz balance and the nohz exit.

    So we'll update unconditionally from the tick to not insert any
    accidental 0 load periods while busy, and we try and catch up from
    nohz idle balance and nohz exit. Both these are still prone to missing
    a jiffy, but that has always been the case.

    Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
    Cc: pjt@google.com
    Cc: Venkatesh Pallipadi <venki@google.com>
    Link: http://lkml.kernel.org/n/tip-kt0trz0apodbf84ucjfdbr1a@git.kernel.org
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    [bwh: Backported to 3.2: adjust filenames and context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit b38725168cb4a768499571ba9a60e590c6dd16a3
Author: Peter Zijlstra <a.p.zijlstra@chello.nl>
Date:   Fri May 11 17:31:26 2012 +0200

    sched/nohz: Fix rq->cpu_load[] calculations

    commit 556061b00c9f2fd6a5524b6bde823ef12f299ecf upstream.

    While investigating why the load-balancer did funny I found that the
    rq->cpu_load[] tables were completely screwy.. a bit more digging
    revealed that the updates that got through were missing ticks followed
    by a catchup of 2 ticks.

    The catchup assumes the cpu was idle during that time (since only nohz
    can cause missed ticks and the machine is idle etc..) this means that
    esp. the higher indices were significantly lower than they ought to
    be.

    The reason for this is that its not correct to compare against jiffies
    on every jiffy on any other cpu than the cpu that updates jiffies.

    This patch cludges around it by only doing the catch-up stuff from
    nohz_idle_balance() and doing the regular stuff unconditionally from
    the tick.

    Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
    Cc: pjt@google.com
    Cc: Venkatesh Pallipadi <venki@google.com>
    Link: http://lkml.kernel.org/n/tip-tp4kj18xdd5aj4vvj0qg55s2@git.kernel.org
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    [bwh: Backported to 3.2: adjust filenames and context; keep functions static]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 8fb388fd35b99f7e4a8769661d174ac0b06a0296
Author: Peter Zijlstra <a.p.zijlstra@chello.nl>
Date:   Fri Jun 22 15:52:09 2012 +0200

    sched/nohz: Rewrite and fix load-avg computation -- again

    commit 5167e8d5417bf5c322a703d2927daec727ea40dd upstream.

    Thanks to Charles Wang for spotting the defects in the current code:

     - If we go idle during the sample window -- after sampling, we get a
       negative bias because we can negate our own sample.

     - If we wake up during the sample window we get a positive bias
       because we push the sample to a known active period.

    So rewrite the entire nohz load-avg muck once again, now adding
    copious documentation to the code.

    Reported-and-tested-by: Doug Smythies <dsmythies@telus.net>
    Reported-and-tested-by: Charles Wang <muming.wq@gmail.com>
    Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Andrew Morton <akpm@linux-foundation.org>
    Link: http://lkml.kernel.org/r/1340373782.18025.74.camel@twins
    [ minor edits ]
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    [bwh: Backported to 3.2: adjust filenames, context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 5e4709afdcdfa1995b266b6f9bde4511a2398a35
Author: Dimitri Sivanich <sivanich@sgi.com>
Date:   Tue Jun 5 13:44:36 2012 -0500

    sched: Fix the relax_domain_level boot parameter

    commit a841f8cef4bb124f0f5563314d0beaf2e1249d72 upstream.

    It does not get processed because sched_domain_level_max is 0 at the
    time that setup_relax_domain_level() is run.

    Simply accept the value as it is, as we don't know the value of
    sched_domain_level_max until sched domain construction is completed.

    Fix sched_relax_domain_level in cpuset.  The build_sched_domain() routine calls
    the set_domain_attribute() routine prior to setting the sd->level, however,
    the set_domain_attribute() routine relies on the sd->level to decide whether
    idle load balancing will be off/on.

    Signed-off-by: Dimitri Sivanich <sivanich@sgi.com>
    Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
    Link: http://lkml.kernel.org/r/20120605184436.GA15668@sgi.com
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    [bwh: Backported to 3.2: adjust the filename]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit fb1e4220fc8272ca914e3aeb4ed56a1040c372c3
Author: Peter Zijlstra <peterz@infradead.org>
Date:   Thu Mar 1 15:04:46 2012 +0100

    sched: Fix nohz load accounting -- again!

    commit c308b56b5398779cd3da0f62ab26b0453494c3d4 upstream.

    Various people reported nohz load tracking still being wrecked, but Doug
    spotted the actual problem. We fold the nohz remainder in too soon,
    causing us to loose samples and under-account.

    So instead of playing catch-up up-front, always do a single load-fold
    with whatever state we encounter and only then fold the nohz remainder
    and play catch-up.

    Reported-by: Doug Smythies <dsmythies@telus.net>
    Reported-by: LesÅ=82aw Kope=C4=87 <leslaw.kopec@nasza-klasa.pl>
    Reported-by: Aman Gupta <aman@tmm1.net>
    Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
    Link: http://lkml.kernel.org/n/tip-4v31etnhgg9kwd6ocgx3rxl8@git.kernel.org
    Signed-off-by: Ingo Molnar <mingo@elte.hu>
    [bwh: Backported to 3.2: change filename]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit a16e1cd8fb91c03e2f85ae75115c31b7c2e80d08
Author: he, bo <bo.he@intel.com>
Date:   Wed Apr 25 19:59:21 2012 +0800

    sched: Fix OOPS when build_sched_domains() percpu allocation fails

    commit fb2cf2c660971bea0ad86a9a5c19ad39eab61344 upstream.

    Under extreme memory used up situations, percpu allocation
    might fail. We hit it when system goes to suspend-to-ram,
    causing a kworker panic:

     EIP: [<c124411a>] build_sched_domains+0x23a/0xad0
     Kernel panic - not syncing: Fatal exception
     Pid: 3026, comm: kworker/u:3
     3.0.8-137473-gf42fbef #1

     Call Trace:
      [<c18cc4f2>] panic+0x66/0x16c
      [...]
      [<c1244c37>] partition_sched_domains+0x287/0x4b0
      [<c12a77be>] cpuset_update_active_cpus+0x1fe/0x210
      [<c123712d>] cpuset_cpu_inactive+0x1d/0x30
      [...]

    With this fix applied build_sched_domains() will return -ENOMEM and
    the suspend attempt fails.

    Signed-off-by: he, bo <bo.he@intel.com>
    Reviewed-by: Zhang, Yanmin <yanmin.zhang@intel.com>
    Reviewed-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
    Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Andrew Morton <akpm@linux-foundation.org>
    Link: http://lkml.kernel.org/r/1335355161.5892.17.camel@hebo
    [ So, we fail to deallocate a CPU because we cannot allocate RAM :-/
      I don't like that kind of sad behavior but nevertheless it should
      not crash under high memory load. ]
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    [bwh: Backported to 3.2: change filename]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 309fd43ab7248fe4f57c5f931fcc5716e781ee69
Author: Carsten Emde <C.Emde@osadl.org>
Date:   Wed Oct 26 23:14:16 2011 +0200

    sched: Set the command name of the idle tasks in SMP kernels

    In UP systems, the idle task is initialized using the init_task
    structure from which the command name is taken (currently "swapper").

    In SMP systems, one idle task per CPU is forked by the worker thread
    from which the task structure is copied. The command name is, therefore,
    "kworker/0:0" or "kworker/0:1", if not updated. Since such update was
    lacking, all idle tasks in SMP systems were incorrectly named. This
    longtime bug was not discovered immediately, because there is no /proc/0
    entry - the bug only becomes apparent when tracing is enabled.

    This patch sets the command name of the idle tasks in SMP systems to the
    name that is used in the INIT_TASK structure suffixed by a slash and the
    number of the CPU.

    Signed-off-by: Carsten Emde <C.Emde@osadl.org>
    Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
    Link: http://lkml.kernel.org/r/20111026211708.768925506@osadl.org
    Signed-off-by: Ingo Molnar <mingo@elte.hu>

    Conflicts:
    	kernel/sched.c

commit e1bba78fedd5750966717175e1570254159e4693
Author: J. Bruce Fields <bfields@redhat.com>
Date:   Thu Oct 6 15:22:46 2011 -0400

    sched: Document wait_for_completion_*() return values

    The return-value convention for these functions varies depending on
    whether they're interruptible or can timeout.  It can be a little
    confusing--document it.

    Signed-off-by: J. Bruce Fields <bfields@redhat.com>
    Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
    Link: http://lkml.kernel.org/r/20111006192246.GB28026@fieldses.org
    Signed-off-by: Ingo Molnar <mingo@elte.hu>

commit 2f08227d5cc713c69970f60ba0c6d22bd21c0d6c
Author: Thomas Gleixner <tglx@linutronix.de>
Date:   Sun Jul 17 20:47:54 2011 +0200

    sched: Don't use tasklist_lock for debug prints

    Avoid taking locks from debug prints, this avoids latencies on -rt,
    and improves reliability of the debug code.

    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
    Signed-off-by: Ingo Molnar <mingo@elte.hu>

commit 75c684d1fd7cf3005a6e169dfa539d977dda6c6f
Author: Peter Zijlstra <peterz@infradead.org>
Date:   Sat Jun 25 15:45:46 2011 +0200

    sched: Unify the ->cpus_allowed mask copy

    Currently every sched_class::set_cpus_allowed() implementation has to
    copy the cpumask into task_struct::cpus_allowed, this is pointless,
    put this copy in the generic code.

    Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
    Acked-by: Thomas Gleixner <tglx@linutronix.de>
    Link: http://lkml.kernel.org/n/tip-jhl5s9fckd9ptw1fzbqqlrd3@git.kernel.org
    Signed-off-by: Ingo Molnar <mingo@elte.hu>

commit 00a5fe10d533caf4f5b09e52524f3b487ce36332
Author: Peter Zijlstra <peterz@infradead.org>
Date:   Thu Jun 16 12:23:22 2011 +0200

    sched: Wrap scheduler p->cpus_allowed access

    This task is preparatory for the migrate_disable() implementation, but
    stands on its own and provides a cleanup.

    It currently only converts those sites required for task-placement.
    Kosaki-san once mentioned replacing cpus_allowed with a proper
    cpumask_t instead of the NR_CPUS sized array it currently is, that
    would also require something like this.

    Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
    Acked-by: Thomas Gleixner <tglx@linutronix.de>
    Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
    Link: http://lkml.kernel.org/n/tip-e42skvaddos99psip0vce41o@git.kernel.org
    Signed-off-by: Ingo Molnar <mingo@elte.hu>

commit 34de19dad7a45f2e1bc78fa812a4a3addf8fd808
Author: Suresh Siddha <suresh.b.siddha@intel.com>
Date:   Mon Oct 3 15:09:01 2011 -0700

    sched: Request for idle balance during nohz idle load balance

    rq's idle_at_tick is set to idle/busy during the timer tick
    depending on the cpu was idle or not. This will be used later in the load
    balance that will be done in the softirq context (which is a process
    context in -RT kernels).

    For nohz kernels, for the cpu doing nohz idle load balance on behalf of
    all the idle cpu's, its rq->idle_at_tick might have a stale value (which is
    recorded when it got the timer tick presumably when it is busy).

    As the nohz idle load balancing is also being done at the same place
    as the regular load balancing, nohz idle load balancing was bailing out
    when it sees rq's idle_at_tick not set.

    Thus leading to poor system utilization.

    Rename rq's idle_at_tick to idle_balance and set it when someone requests
    for nohz idle balance on an idle cpu.

    Reported-by: Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>
    Signed-off-by: Suresh Siddha <suresh.b.siddha@intel.com>
    Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
    Link: http://lkml.kernel.org/r/20111003220934.892350549@sbsiddha-desk.sc.intel.com
    Signed-off-by: Ingo Molnar <mingo@elte.hu>

commit 49306523dfc68c40313100872cb6212b375bd06e
Author: Suresh Siddha <suresh.b.siddha@intel.com>
Date:   Mon Oct 3 15:09:00 2011 -0700

    sched: Use resched IPI to kick off the nohz idle balance

    Current use of smp call function to kick the nohz idle balance can deadlock
    in this scenario.

    1. cpu-A did a generic_exec_single() to cpu-B and after queuing its call single
    data (csd) to the call single queue, cpu-A took a timer interrupt.  Actual IPI
    to cpu-B to process the call single queue is not yet sent.

    2. As part of the timer interrupt handler, cpu-A decided to kick cpu-B
    for the idle load balancing (sets cpu-B's rq->nohz_balance_kick to 1)
    and __smp_call_function_single() with nowait will queue the csd to the
    cpu-B's queue. But the generic_exec_single() won't send an IPI to cpu-B
    as the call single queue was not empty.

    3. cpu-A is busy with lot of interrupts

    4. Meanwhile cpu-B is entering and exiting idle and noticed that it has
    it's rq->nohz_balance_kick set to '1'. So it will go ahead and do the
    idle load balancer and clear its rq->nohz_balance_kick.

    5. At this point, csd queued as part of the step-2 above is still locked
    and waiting to be serviced on cpu-B.

    6. cpu-A is still busy with interrupt load and now it got another timer
    interrupt and as part of it decided to kick cpu-B for another idle load
    balancing (as it finds cpu-B's rq->nohz_balance_kick cleared in step-4
    above) and does __smp_call_function_single() with the same csd that is
    still locked.

    7. And we get a deadlock waiting for the csd_lock() in the
    __smp_call_function_single().

    Main issue here is that cpu-B can service the idle load balancer kick
    request from cpu-A even with out receiving the IPI and this lead to
    doing multiple __smp_call_function_single() on the same csd leading to
    deadlock.

    To kick a cpu, scheduler already has the reschedule vector reserved. Use
    that mechanism (kick_process()) instead of using the generic smp call function
    mechanism to kick off the nohz idle load balancing and avoid the deadlock.

       [ This issue is present from 2.6.35+ kernels, but marking it -stable
         only from v3.0+ as the proposed fix depends on the scheduler_ipi()
         that is introduced recently. ]

    Reported-by: Prarit Bhargava <prarit@redhat.com>
    Signed-off-by: Suresh Siddha <suresh.b.siddha@intel.com>
    Cc: stable@kernel.org # v3.0+
    Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
    Link: http://lkml.kernel.org/r/20111003220934.834943260@sbsiddha-desk.sc.intel.com
    Signed-off-by: Ingo Molnar <mingo@elte.hu>

commit 2626d9f6c5bc83823308800439f1ec03f2eaf10c
Author: Thomas Gleixner <tglx@linutronix.de>
Date:   Thu Sep 15 15:32:06 2011 +0200

    sched: Fix idle_cpu()

    On -rt we observed hackbench waking all 400 tasks to a single cpu.
    This is because of select_idle_sibling()'s interaction with the new
    ipi based wakeup scheme.

    The existing idle_cpu() test only checks to see if the current task on
    that cpu is the idle task, it does not take already queued tasks into
    account, nor does it take queued to be woken tasks into account.

    If the remote wakeup IPIs come hard enough, there won't be time to
    schedule away from the idle task, and would thus keep thinking the cpu
    was in fact idle, regardless of the fact that there were already
    several hundred tasks runnable.

    We couldn't reproduce on mainline, but there's no reason it couldn't
    happen.

    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
    Link: http://lkml.kernel.org/n/tip-3o30p18b2paswpc9ohy2gltp@git.kernel.org
    Signed-off-by: Ingo Molnar <mingo@elte.hu>

commit 0bf9ed6c1efd591eb5be68d733cb4a4ecb535427
Author: Peter Zijlstra <a.p.zijlstra@chello.nl>
Date:   Mon Sep 12 13:06:17 2011 +0200

    sched: Convert to struct llist

    Use the generic llist primitives.

    We had a private lockless list implementation in the scheduler in the wake-list
    code, now that we have a generic llist implementation that provides all required
    operations, switch to it.

    This patch is not expected to change any behavior.

    Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
    Cc: Huang Ying <ying.huang@intel.com>
    Cc: Andrew Morton <akpm@linux-foundation.org>
    Link: http://lkml.kernel.org/r/1315836353.26517.42.camel@twins
    Signed-off-by: Ingo Molnar <mingo@elte.hu>

commit b113f094f42c0920371b85dd96c97a1cf715b27f
Author: Peter Zijlstra <a.p.zijlstra@chello.nl>
Date:   Mon Sep 12 13:12:28 2011 +0200

    llist: Add llist_next()

    So we don't have to expose the struct list_node member.

    Cc: Huang Ying <ying.huang@intel.com>
    Cc: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
    Link: http://lkml.kernel.org/r/1315836348.26517.41.camel@twins
    Signed-off-by: Ingo Molnar <mingo@elte.hu>

commit fa4fa5e6bf872e6750075c6d8a14fc2db080a72b
Author: Huang Ying <ying.huang@intel.com>
Date:   Thu Sep 8 14:00:46 2011 +0800

    irq_work: Use llist in the struct irq_work logic

    Use llist in irq_work instead of the lock-less linked list
    implementation in irq_work to avoid the code duplication.

    Signed-off-by: Huang Ying <ying.huang@intel.com>
    Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
    Link: http://lkml.kernel.org/r/1315461646-1379-6-git-send-email-ying.huang@intel.com
    Signed-off-by: Ingo Molnar <mingo@elte.hu>

commit 8a2e65ea10476589b59b10247462838a8e710a67
Author: Huang Ying <ying.huang@intel.com>
Date:   Thu Sep 8 14:00:45 2011 +0800

    llist: Return whether list is empty before adding in llist_add()

    Extend the llist_add*() functions to return a success indicator, this
    allows us in the scheduler code to send an IPI if the queue was empty.

    ( There's no effect on existing users, because the list_add_xxx() functions
      are inline, thus this will be optimized out by the compiler if not used
      by callers. )

    Signed-off-by: Huang Ying <ying.huang@intel.com>
    Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
    Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
    Link: http://lkml.kernel.org/r/1315461646-1379-5-git-send-email-ying.huang@intel.com
    Signed-off-by: Ingo Molnar <mingo@elte.hu>

commit d37b3ed8c3b52a10463179a0dd419ea726aadc46
Author: Huang Ying <ying.huang@intel.com>
Date:   Thu Sep 8 14:00:44 2011 +0800

    llist: Move cpu_relax() to after the cmpxchg()

    If in llist_add()/etc. functions the first cmpxchg() call succeeds, it is
    not necessary to use cpu_relax() before the cmpxchg(). So cpu_relax() in
    a busy loop involving cmpxchg() should go after cmpxchg() instead of before
    that.

    This patch fixes this for all involved llist functions.

    Signed-off-by: Huang Ying <ying.huang@intel.com>
    Acked-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
    Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
    Link: http://lkml.kernel.org/r/1315461646-1379-4-git-send-email-ying.huang@intel.com
    Signed-off-by: Ingo Molnar <mingo@elte.hu>

commit 1b5389312cf8d130c63e9e2f72c9a0a49fb2595e
Author: Ingo Molnar <mingo@elte.hu>
Date:   Tue Oct 4 12:43:11 2011 +0200

    llist: Remove the platform-dependent NMI checks

    Remove the nmi() checks spread around the code. in_nmi() is not available
    on every architecture and it's a pretty obscure and ugly check in any case.

    Cc: Huang Ying <ying.huang@intel.com>
    Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
    Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
    Link: http://lkml.kernel.org/r/1315461646-1379-3-git-send-email-ying.huang@intel.com
    Signed-off-by: Ingo Molnar <mingo@elte.hu>

commit 2fc59426f7de65f69044760babb32ce5f9510152
Author: Huang Ying <ying.huang@intel.com>
Date:   Thu Sep 8 14:00:42 2011 +0800

    llist: Make some llist functions inline

    Because llist code will be used in performance critical scheduler
    code path, make llist_add() and llist_del_all() inline to avoid
    function calling overhead and related 'glue' overhead.

    Signed-off-by: Huang Ying <ying.huang@intel.com>
    Acked-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
    Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
    Link: http://lkml.kernel.org/r/1315461646-1379-2-git-send-email-ying.huang@intel.com
    Signed-off-by: Ingo Molnar <mingo@elte.hu>

commit 58d9df206a92af26549fdd959c5ad20922d0354e
Author: Shi, Alex <alex.shi@intel.com>
Date:   Thu Jul 28 14:56:12 2011 +0800

    nohz: Remove nohz_cpu_mask

    RCU no longer uses this global variable, nor does anyone else.  This
    commit therefore removes this variable.  This reduces memory footprint
    and also removes some atomic instructions and memory barriers from
    the dyntick-idle path.

    Signed-off-by: Alex Shi <alex.shi@intel.com>
    Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>

commit 53b38100d600716f0ef063202f4c537e9f5c6977
Author: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Date:   Tue May 24 08:31:09 2011 -0700

    rcu: Restore checks for blocking in RCU read-side critical sections

    Long ago, using TREE_RCU with PREEMPT would result in "scheduling
    while atomic" diagnostics if you blocked in an RCU read-side critical
    section.  However, PREEMPT now implies TREE_PREEMPT_RCU, which defeats
    this diagnostic.  This commit therefore adds a replacement diagnostic
    based on PROVE_RCU.

    Because rcu_lockdep_assert() and lockdep_rcu_dereference() are now being
    used for things that have nothing to do with rcu_dereference(), rename
    lockdep_rcu_dereference() to lockdep_rcu_suspicious() and add a third
    argument that is a string indicating what is suspicious.  This third
    argument is passed in from a new third argument to rcu_lockdep_assert().
    Update all calls to rcu_lockdep_assert() to add an informative third
    argument.

    Also, add a pair of rcu_lockdep_assert() calls from within
    rcu_note_context_switch(), one complaining if a context switch occurs
    in an RCU-bh read-side critical section and another complaining if a
    context switch occurs in an RCU-sched read-side critical section.
    These are present only if the PROVE_RCU kernel parameter is enabled.

    Finally, fix some checkpatch whitespace complaints in lockdep.c.

    Again, you must enable PROVE_RCU to see these new diagnostics.  But you
    are enabling PROVE_RCU to check out new RCU uses in any case, aren't you?

    Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>

commit 83f2c4562cdc7bdc8916970c75ebb779c7891e0a
Author: Sha Zhengju <handai.szj@taobao.com>
Date:   Thu May 10 13:01:45 2012 -0700

    memcg: free spare array to avoid memory leak

    commit 8c7577637ca31385e92769a77e2ab5b428e8b99c upstream.

    When the last event is unregistered, there is no need to keep the spare
    array anymore.  So free it to avoid memory leak.

    Signed-off-by: Sha Zhengju <handai.szj@taobao.com>
    Acked-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
    Reviewed-by: Kirill A. Shutemov <kirill@shutemov.name>
    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 aff453fd02837514723d13d7523f3cf7ea219453
Author: Anton Vorontsov <anton.vorontsov@linaro.org>
Date:   Fri Feb 24 05:14:46 2012 +0400

    mm: memcg: Correct unregistring of events attached to the same eventfd

    commit 371528caec553785c37f73fa3926ea0de84f986f upstream.

    There is an issue when memcg unregisters events that were attached to
    the same eventfd:

    - On the first call mem_cgroup_usage_unregister_event() removes all
      events attached to a given eventfd, and if there were no events left,
      thresholds->primary would become NULL;

    - Since there were several events registered, cgroups core will call
      mem_cgroup_usage_unregister_event() again, but now kernel will oops,
      as the function doesn't expect that threshold->primary may be NULL.

    That's a good question whether mem_cgroup_usage_unregister_event()
    should actually remove all events in one go, but nowadays it can't
    do any better as cftype->unregister_event callback doesn't pass
    any private event-associated cookie. So, let's fix the issue by
    simply checking for threshold->primary.

    FWIW, w/o the patch the following oops may be observed:

     BUG: unable to handle kernel NULL pointer dereference at 0000000000000004
     IP: [<ffffffff810be32c>] mem_cgroup_usage_unregister_event+0x9c/0x1f0
     Pid: 574, comm: kworker/0:2 Not tainted 3.3.0-rc4+ #9 Bochs Bochs
     RIP: 0010:[<ffffffff810be32c>]  [<ffffffff810be32c>] mem_cgroup_usage_unregister_event+0x9c/0x1f0
     RSP: 0018:ffff88001d0b9d60  EFLAGS: 00010246
     Process kworker/0:2 (pid: 574, threadinfo ffff88001d0b8000, task ffff88001de91cc0)
     Call Trace:
      [<ffffffff8107092b>] cgroup_event_remove+0x2b/0x60
      [<ffffffff8103db94>] process_one_work+0x174/0x450
      [<ffffffff8103e413>] worker_thread+0x123/0x2d0

    Signed-off-by: Anton Vorontsov <anton.vorontsov@linaro.org>
    Acked-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
    Cc: Kirill A. Shutemov <kirill@shutemov.name>
    Cc: Michal Hocko <mhocko@suse.cz>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 605fe35c2cad6d6b3db76c72beb3ba91d0769348
Author: Johannes Weiner <jweiner@redhat.com>
Date:   Wed Nov 2 13:38:29 2011 -0700

    memcg: close race between charge and putback

    There is a potential race between a thread charging a page and another
    thread putting it back to the LRU list:

      charge:                         putback:
      SetPageCgroupUsed               SetPageLRU
      PageLRU && add to memcg LRU     PageCgroupUsed && add to memcg LRU

    The order of setting one flag and checking the other is crucial, otherwise
    the charge may observe !PageLRU while the putback observes !PageCgroupUsed
    and the page is not linked to the memcg LRU at all.

    Global memory pressure may fix this by trying to isolate and putback the
    page for reclaim, where that putback would link it to the memcg LRU again.
     Without that, the memory cgroup is undeletable due to a charge whose
    physical page can not be found and moved out.

    Signed-off-by: Johannes Weiner <jweiner@redhat.com>
    Cc: Ying Han <yinghan@google.com>
    Acked-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
    Cc: Daisuke Nishimura <nishimura@mxp.nes.nec.co.jp>
    Cc: Balbir Singh <bsingharora@gmail.com>
    Cc: Michal Hocko <mhocko@suse.cz>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

commit e5fa1cb3e8ff263a13e3b6671fd3592330cd8674
Author: Johannes Weiner <jweiner@redhat.com>
Date:   Wed Nov 2 13:38:23 2011 -0700

    memcg: skip scanning active lists based on individual size

    Reclaim decides to skip scanning an active list when the corresponding
    inactive list is above a certain size in comparison to leave the assumed
    working set alone while there are still enough reclaim candidates around.

    The memcg implementation of comparing those lists instead reports whether
    the whole memcg is low on the requested type of inactive pages,
    considering all nodes and zones.

    This can lead to an oversized active list not being scanned because of the
    state of the other lists in the memcg, as well as an active list being
    scanned while its corresponding inactive list has enough pages.

    Not only is this wrong, it's also a scalability hazard, because the global
    memory state over all nodes and zones has to be gathered for each memcg
    and zone scanned.

    Make these calculations purely based on the size of the two LRU lists
    that are actually affected by the outcome of the decision.

    Signed-off-by: Johannes Weiner <jweiner@redhat.com>
    Reviewed-by: Rik van Riel <riel@redhat.com>
    Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
    Acked-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
    Cc: Daisuke Nishimura <nishimura@mxp.nes.nec.co.jp>
    Cc: Balbir Singh <bsingharora@gmail.com>
    Reviewed-by: Minchan Kim <minchan.kim@gmail.com>
    Reviewed-by: Ying Han <yinghan@google.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

commit e870539f5a066c4ce7f532916137c39eb7178ac7
Author: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Date:   Wed Nov 2 13:38:18 2011 -0700

    memcg: fix oom schedule_timeout()

    Before calling schedule_timeout(), task state should be changed.

    Signed-off-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
    Acked-by: Michal Hocko <mhocko@suse.cz>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

commit 5dd3d8ba440b7c3c06297dd66eb166dc316f00a7
Author: Andrew Bresticker <abrestic@google.com>
Date:   Wed Nov 2 13:40:29 2011 -0700

    memcg: replace ss->id_lock with a rwlock

    While back-porting Johannes Weiner's patch "mm: memcg-aware global
    reclaim" for an internal effort, we noticed a significant performance
    regression during page-reclaim heavy workloads due to high contention of
    the ss->id_lock.  This lock protects idr map, and serializes calls to
    idr_get_next() in css_get_next() (which is used during the memcg hierarchy
    walk).

    Since idr_get_next() is just doing a look up, we need only serialize it
    with respect to idr_remove()/idr_get_new().  By making the ss->id_lock a
    rwlock, contention is greatly reduced and performance improves.

    Tested: cat a 256m file from a ramdisk in a 128m container 50 times on
    each core (one file + container per core) in parallel on a NUMA machine.
    Result is the time for the test to complete in 1 of the containers.
    Both kernels included Johannes' memcg-aware global reclaim patches.

    Before rwlock patch: 1710.778s
    After rwlock patch: 152.227s

    Signed-off-by: Andrew Bresticker <abrestic@google.com>
    Cc: Paul Menage <menage@gmail.com>
    Cc: Li Zefan <lizf@cn.fujitsu.com>
    Acked-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
    Cc: Ying Han <yinghan@google.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

commit 8b69f776dfd788315d22d59e87031169667b0b51
Author: Daisuke Nishimura <nishimura@mxp.nes.nec.co.jp>
Date:   Thu Oct 4 16:37:16 2012 +0900

    cgroup: notify_on_release may not be triggered in some cases

    commit 1f5320d5972aa50d3e8d2b227b636b370e608359 upstream.

    notify_on_release must be triggered when the last process in a cgroup is
    move to another. But if the first(and only) process in a cgroup is moved to
    another, notify_on_release is not triggered.

    	# mkdir /cgroup/cpu/SRC
    	# mkdir /cgroup/cpu/DST
    	#
    	# echo 1 >/cgroup/cpu/SRC/notify_on_release
    	# echo 1 >/cgroup/cpu/DST/notify_on_release
    	#
    	# sleep 300 &
    	[1] 8629
    	#
    	# echo 8629 >/cgroup/cpu/SRC/tasks
    	# echo 8629 >/cgroup/cpu/DST/tasks
    	-> notify_on_release for /SRC must be triggered at this point,
    	   but it isn't.

    This is because put_css_set() is called before setting CGRP_RELEASABLE
    in cgroup_task_migrate(), and is a regression introduce by the
    commit:74a1166d(cgroups: make procs file writable), which was merged
    into v3.0.

    Cc: Ben Blum <bblum@andrew.cmu.edu>
    Acked-by: Li Zefan <lizefan@huawei.com>
    Signed-off-by: Daisuke Nishimura <nishimura@mxp.nes.nec.co.jp>
    Signed-off-by: Tejun Heo <tj@kernel.org>
    [bwh: Backported to 3.2: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit ba50ea661d86df3d562fbedb036690a5f5065541
Author: Ben Blum <bblum@andrew.cmu.edu>
Date:   Wed Nov 2 13:38:07 2011 -0700

    cgroups: don't attach task to subsystem if migration failed

    If a task has exited to the point it has called cgroup_exit() already,
    then we can't migrate it to another cgroup anymore.

    This can happen when we are attaching a task to a new cgroup between the
    call to ->can_attach_task() on subsystems and the migration that is
    eventually tried in cgroup_task_migrate().

    In this case cgroup_task_migrate() returns -ESRCH and we don't want to
    attach the task to the subsystems because the attachment to the new cgroup
    itself failed.

    Fix this by only calling ->attach_task() on the subsystems if the cgroup
    migration succeeded.

    Reported-by: Oleg Nesterov <oleg@redhat.com>
    Signed-off-by: Ben Blum <bblum@andrew.cmu.edu>
    Acked-by: Paul Menage <paul@paulmenage.org>
    Cc: Li Zefan <lizf@cn.fujitsu.com>
    Cc: Tejun Heo <tj@kernel.org>
    Signed-off-by: Frederic Weisbecker <fweisbec@gmail.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

commit f8a55c9c994c3feadaad8c69a422b49b38d3b9bf
Author: Ben Blum <bblum@andrew.cmu.edu>
Date:   Wed Nov 2 13:38:05 2011 -0700

    cgroups: more safe tasklist locking in cgroup_attach_proc

    Fix unstable tasklist locking in cgroup_attach_proc.

    According to this thread - https://lkml.org/lkml/2011/7/27/243 - RCU is
    not sufficient to guarantee the tasklist is stable w.r.t.  de_thread and
    exit.  Taking tasklist_lock for reading, instead of rcu_read_lock, ensures
    proper exclusion.

    Signed-off-by: Ben Blum <bblum@andrew.cmu.edu>
    Acked-by: Paul Menage <paul@paulmenage.org>
    Cc: Oleg Nesterov <oleg@redhat.com>
    Cc: Frederic Weisbecker <fweisbec@gmail.com>
    Cc: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
    Cc: Neil Brown <neilb@suse.de>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

commit 5e14c7ed03d62db3118c9881434d3167cfc62978
Author: Thomas Gleixner <tglx@linutronix.de>
Date:   Sat Jul 25 16:47:45 2009 +0200

    locking, sched, cgroups: Annotate release_list_lock as raw

    The release_list_lock can be taken in atomic context and therefore
    cannot be preempted on -rt - annotate it.

    In mainline this change documents the low level nature of
    the lock - otherwise there's no functional difference. Lockdep
    and Sparse checking will work as usual.

    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: Ingo Molnar <mingo@elte.hu>

commit e69f648c6ff88c4a25fe2728da06f31138c364f5
Author: Alex Frid <afrid@nvidia.com>
Date:   Wed May 16 14:27:13 2012 -0700

    proc: Add time-average nr_running to loadavg printout

    Change-Id: I39a97308050fd36bbcf4e9b909e3087172438f8b
    Signed-off-by: Alex Frid <afrid@nvidia.com>
    Reviewed-on: http://git-master/r/108071
    Reviewed-by: Automatic_Commit_Validation_User
    Reviewed-by: Ryan Wong <ryanw@nvidia.com>
    Tested-by: Ryan Wong <ryanw@nvidia.com>

commit 7efa18cbe481bc5abd72831cbb874a70b7ca44ea
Author: Alex Frid <afrid@nvidia.com>
Date:   Fri May 18 12:18:38 2012 -0700

    scheduler: Re-compute time-average nr_running on read

    Re-compute time-average nr_running when it is read. This would
    prevent reading stalled average value if there were no run-queue
    changes for a long time. New average value is returned to the reader,
    but not stored to avoid concurrent writes. Light-weight sequential
    counter synchronization is used to assure data consistency for
    re-computing average.

    Change-Id: I08de26087414d6663633c723ddfcbf1099a01ce2
    Signed-off-by: Alex Frid <afrid@nvidia.com>
    Reviewed-on: http://git-master/r/108072
    Reviewed-by: Automatic_Commit_Validation_User
    Reviewed-by: Ryan Wong <ryanw@nvidia.com>
    Tested-by: Ryan Wong <ryanw@nvidia.com>

commit 4e98d45f9bcd3d41c461e43c8a80377b01826eca
Author: Diwakar Tundlam <dtundlam@nvidia.com>
Date:   Mon May 7 15:12:25 2012 -0700

    scheduler: compute time-average nr_running per run-queue

    Compute the time-average number of running tasks per run-queue for a
    trailing window of a fixed time period. The detla add/sub to the
    average value is weighted by the amount of time per nr_running value
    relative to the total measurement period.

    Change-Id: I4b1fa8fee82a549889560ceded4b94bdb811671d
    Signed-off-by: Diwakar Tundlam <dtundlam@nvidia.com>
    Reviewed-on: http://git-master/r/108070
    Reviewed-by: Automatic_Commit_Validation_User
    Reviewed-by: Ryan Wong <ryanw@nvidia.com>
    Tested-by: Ryan Wong <ryanw@nvidia.com>

commit dc1b0e7bfc5b7720e7cf47d5afc992c0edb83cde
Author: Adam77Root <adam77root@gmail.com>
Date:   Sun Jun 9 17:23:52 2013 +0200

    defconfig: enable zram

    Change-Id: I5357715f84d1f071f56a6315666da0dc5a4811c7

commit 204ec1b1116962beee4ed5f446b50096a300e473
Author: Prashant Somashekar <prashsomash@gmail.com>
Date:   Thu Nov 8 08:21:23 2012 -0500

    rcu: remove trace events

commit d9fca09686013e98af80e159b1f8e4b01096d4b5
Author: Paul E. McKenney <paul.mckenney@linaro.org>
Date:   Tue Aug 16 17:46:46 2011 -0700

    rcu: Permit rt_mutex_unlock() with irqs disabled

    Create a separate lockdep class for the rt_mutex used for RCU priority
    boosting and enable use of rt_mutex_lock() with irqs disabled.  This
    prevents RCU priority boosting from falling prey to deadlocks when
    someone begins an RCU read-side critical section in preemptible state,
    but releases it with an irq-disabled lock held.

    Unfortunately, the scheduler's runqueue and priority-inheritance locks
    still must either completely enclose or be completely enclosed by any
    overlapping RCU read-side critical section.

    This version removes a redundant local_irq_restore() noted by
    Yong Zhang.

    Signed-off-by: Paul E. McKenney <paul.mckenney@linaro.org>
    Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>

commit 91db89072d58a2abcf2906c9fc6a881982088ae1
Author: Paul E. McKenney <paul.mckenney@linaro.org>
Date:   Thu Aug 4 07:55:34 2011 -0700

    rcu: Simplify unboosting checks

    Commit 7765be (Fix RCU_BOOST race handling current->rcu_read_unlock_special)
    introduced a new ->rcu_boosted field in the task structure.  This is
    redundant because the existing ->rcu_boost_mutex will be non-NULL at
    any time that ->rcu_boosted is nonzero.  Therefore, this commit removes
    ->rcu_boosted and tests ->rcu_boost_mutex instead.

    Signed-off-by: Paul E. McKenney <paul.mckenney@linaro.org>
    Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>

commit e0079a645952b193185b0a364851eea733560925
Author: Paul E. McKenney <paul.mckenney@linaro.org>
Date:   Mon Aug 1 06:22:11 2011 -0700

    rcu: Move __rcu_read_unlock()'s barrier() within if-statement

    We only need to constrain the compiler if we are actually exiting
    the top-level RCU read-side critical section.  This commit therefore
    moves the first barrier() cal in __rcu_read_unlock() to inside the
    "if" statement, thus avoiding needless register flushes for inner
    rcu_read_unlock() calls.

    Signed-off-by: Paul E. McKenney <paul.mckenney@linaro.org>
    Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>

commit 94fe17f81fb6400aa27ca0958e1efd7c4fae0511
Author: Paul E. McKenney <paul.mckenney@linaro.org>
Date:   Tue Jun 21 22:43:26 2011 -0700

    rcu: Add event-trace markers to TREE_RCU kthreads

    Add event-trace markers to TREE_RCU kthreads to allow including these
    kthread's CPU time in the utilization calculations.

    Signed-off-by: Paul E. McKenney <paul.mckenney@linaro.org>
    Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>

commit a23b3d9eacaffb9eacc5cf55f266ef8e44f1a01d
Author: Shaohua Li <shaohua.li@intel.com>
Date:   Thu Jun 16 16:02:54 2011 -0700

    rcu: Avoid unnecessary self-wakeup of per-CPU kthreads

    There are a number of cases where the RCU can find additional work
    for the per-CPU kthread within the context of that per-CPU kthread.
    In such cases, the per-CPU kthread is already running, so attempting
    to wake itself up does nothing except waste CPU cycles.  This commit
    therefore checks to see if it is in the per-CPU kthread context,
    omitting the wakeup in this case.

    Signed-off-by: Shaohua Li <shaohua.li@intel.com>
    Signed-off-by: Paul E. McKenney <paul.mckenney@linaro.org>
    Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>

commit fcb8fb717786113c7b8c82b2a18c5a21de4df7d0
Author: Paul E. McKenney <paul.mckenney@linaro.org>
Date:   Sat Sep 22 13:55:30 2012 -0700

    rcu: Fix day-one dyntick-idle stall-warning bug

    commit a10d206ef1a83121ab7430cb196e0376a7145b22 upstream.

    Each grace period is supposed to have at least one callback waiting
    for that grace period to complete.  However, if CONFIG_NO_HZ=n, an
    extra callback-free grace period is no big problem -- it will chew up
    a tiny bit of CPU time, but it will complete normally.  In contrast,
    CONFIG_NO_HZ=y kernels have the potential for all the CPUs to go to
    sleep indefinitely, in turn indefinitely delaying completion of the
    callback-free grace period.  Given that nothing is waiting on this grace
    period, this is also not a problem.

    That is, unless RCU CPU stall warnings are also enabled, as they are
    in recent kernels.  In this case, if a CPU wakes up after at least one
    minute of inactivity, an RCU CPU stall warning will result.  The reason
    that no one noticed until quite recently is that most systems have enough
    OS noise that they will never remain absolutely idle for a full minute.
    But there are some embedded systems with cut-down userspace configurations
    that consistently get into this situation.

    All this begs the question of exactly how a callback-free grace period
    gets started in the first place.  This can happen due to the fact that
    CPUs do not necessarily agree on which grace period is in progress.
    If a CPU still believes that the grace period that just completed is
    still ongoing, it will believe that it has callbacks that need to wait for
    another grace period, never mind the fact that the grace period that they
    were waiting for just completed.  This CPU can therefore erroneously
    decide to start a new grace period.  Note that this can happen in
    TREE_RCU and TREE_PREEMPT_RCU even on a single-CPU system:  Deadlock
    considerations mean that the CPU that detected the end of the grace
    period is not necessarily officially informed of this fact for some time.

    Once this CPU notices that the earlier grace period completed, it will
    invoke its callbacks.  It then won't have any callbacks left.  If no
    other CPU has any callbacks, we now have a callback-free grace period.

    This commit therefore makes CPUs check more carefully before starting a
    new grace period.  This new check relies on an array of tail pointers
    into each CPU's list of callbacks.  If the CPU is up to date on which
    grace periods have completed, it checks to see if any callbacks follow
    the RCU_DONE_TAIL segment, otherwise it checks to see if any callbacks
    follow the RCU_WAIT_TAIL segment.  The reason that this works is that
    the RCU_WAIT_TAIL segment will be promoted to the RCU_DONE_TAIL segment
    as soon as the CPU is officially notified that the old grace period
    has ended.

    This change is to cpu_needs_another_gp(), which is called in a number
    of places.  The only one that really matters is in rcu_start_gp(), where
    the root rcu_node structure's ->lock is held, which prevents any
    other CPU from starting or completing a grace period, so that the
    comparison that determines whether the CPU is missing the completion
    of a grace period is stable.

    Reported-by: Becky Bruce <bgillbruce@gmail.com>
    Reported-by: Subodh Nijsure <snijsure@grid-net.com>
    Reported-by: Paul Walmsley <paul@pwsan.com>
    Signed-off-by: Paul E. McKenney <paul.mckenney@linaro.org>
    Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
    Tested-by: Paul Walmsley <paul@pwsan.com>  # OMAP3730, OMAP4430
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 20a7e3fc397338c2accacf25e153fd698462129b
Author: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Date:   Wed Aug 24 16:52:09 2011 -0700

    rcu: Move propagation of ->completed from rcu_start_gp() to rcu_report_qs_rsp()

    It is possible for the CPU that noted the end of the prior grace period
    to not need a new one, and therefore to decide to propagate ->completed
    throughout the rcu_node tree without starting another grace period.
    However, in so doing, it releases the root rcu_node structure's lock,
    which can allow some other CPU to start another grace period.  The first
    CPU will be propagating ->completed in parallel with the second CPU
    initializing the rcu_node tree for the new grace period.  In theory
    this is harmless, but in practice we need to keep things simple.

    This commit therefore moves the propagation of ->completed to
    rcu_report_qs_rsp(), and refrains from marking the old grace period
    as having been completed until it has finished doing this.  This
    prevents anyone from starting a new grace period concurrently with
    marking the old grace period as having been completed.

    Of course, the optimization where a CPU needing a new grace period
    doesn't bother marking the old one completed is still in effect:
    In that case, the marking happens implicitly as part of initializing
    the new grace period.

    Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>

commit aaa6d235714c9d57e0a23fc00339e2e1e9416858
Author: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Date:   Sat Aug 20 18:29:32 2011 -0700

    rcu: Remove rcu_needs_cpu_flush() to avoid false quiescent states

    The purpose of rcu_needs_cpu_flush() was to iterate on pushing the
    current grace period in order to help the current CPU enter dyntick-idle
    mode.  However, this can result in failures if the CPU starts entering
    dyntick-idle mode, but then backs out.  In this case, the call to
    rcu_pending() from rcu_needs_cpu_flush() might end up announcing a
    non-existing quiescent state.

    This commit therefore removes rcu_needs_cpu_flush() in favor of letting
    the dyntick-idle machinery at the end of the softirq handler push the
    loop along via its call to rcu_pending().

    Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>

commit 4993d7d2cfa8f070b4c0792b83bea0a61ca630cc
Author: Mike Galbraith <efault@gmx.de>
Date:   Fri Aug 19 11:39:11 2011 -0700

    rcu: Wire up RCU_BOOST_PRIO for rcutree

    RCU boost threads start life at RCU_BOOST_PRIO, while others remain
    at RCU_KTHREAD_PRIO.  While here, change thread names to match other
    kthreads, and adjust rcu_yield() to not override the priority set by
    the user.  This last change sets the stage for runtime changes to
    priority in the -rt tree.

    Signed-off-by: Mike Galbraith <efault@gmx.de>
    Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>

commit 60a4486c464308cf89f2aaca19f67a5b19ac9ff5
Author: Eric Dumazet <eric.dumazet@gmail.com>
Date:   Thu Jun 16 15:53:18 2011 -0700

    rcu: Use kthread_create_on_node()

    Commit a26ac2455ffc (move TREE_RCU from softirq to kthread) added
    per-CPU kthreads.  However, kthread creation uses kthread_create(), which
    can put the kthread's stack and task struct on the wrong NUMA node.
    Therefore, use kthread_create_on_node() instead of kthread_create()
    so that the stacks and task structs are placed on the correct NUMA node.

    A similar change was carried out in commit 94dcf29a11b3 (kthread:
    use kthread_create_on_node()).

    Also change rcutorture's priority-boost-test kthread creation.

    Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
    CC: Tejun Heo <tj@kernel.org>
    CC: Rusty Russell <rusty@rustcorp.com.au>
    CC: Andrew Morton <akpm@linux-foundation.org>
    CC: Andi Kleen <ak@linux.intel.com>
    CC: Ingo Molnar <mingo@elte.hu>
    Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>

commit 71338557bfa5ba35dcf6262d0413ab2cfad359ca
Author: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Date:   Sun Aug 14 15:56:54 2011 -0700

    rcu: Avoid having just-onlined CPU resched itself when RCU is idle

    CPUs set rdp->qs_pending when coming online to resolve races with
    grace-period start.  However, this means that if RCU is idle, the
    just-onlined CPU might needlessly send itself resched IPIs.  Adjust
    the online-CPU initialization to avoid this, and also to correctly
    cause the CPU to respond to the current grace period if needed.

    Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
    Tested-by: Josh Boyer <jwboyer@redhat.com>
    Tested-by: Christian Hoffmann <email@christianhoffmann.info>

commit a95b633fe17a0b0802673d2c2c59170e90acdf3f
Author: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Date:   Sat Aug 13 13:31:47 2011 -0700

    rcu: Suppress NMI backtraces when stall ends before dump

    It is possible for an RCU CPU stall to end just as it is detected, in
    which case the current code will uselessly dump all CPU's stacks.
    This commit therefore checks for this condition and refrains from
    sending needless NMIs.

    And yes, the stall might also end just after we checked all CPUs and
    tasks, but in that case we would at least have given some clue as
    to which CPU/task was at fault.

    Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>

commit a7a7e9b25ff20e49537b98608b6a36ef51090bd9
Author: Paul E. McKenney <paul.mckenney@linaro.org>
Date:   Sun Aug 7 20:26:31 2011 -0700

    rcu: Prohibit grace periods during early boot

    Greater use of RCU during early boot (before the scheduler is operating)
    is causing RCU to attempt to start grace periods during that time, which
    in turn is resulting in both RCU and the callback functions attempting
    to use the scheduler before it is ready.

    This commit prevents these problems by prohibiting RCU grace periods
    until after the scheduler has spawned the first non-idle task.

    Signed-off-by: Paul E. McKenney <paul.mckenney@linaro.org>
    Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>

commit 674ba5b9655b72ec85361808f76097d60163c1c2
Author: Paul E. McKenney <paul.mckenney@linaro.org>
Date:   Thu Aug 4 06:59:03 2011 -0700

    rcu: Prevent early boot set_need_resched() from __rcu_pending()

    There isn't a whole lot of point in poking the scheduler before there
    are other tasks to switch to.  This commit therefore adds a check
    for rcu_scheduler_fully_active in __rcu_pending() to suppress any
    pre-scheduler calls to set_need_resched().  The downside of this approach
    is additional runtime overhead in a reasonably hot code path.

    Signed-off-by: Paul E. McKenney <paul.mckenney@linaro.org>
    Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>

commit 2e3a92f5802ded22235be44519e5293b8b40eac0
Author: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Date:   Wed Aug 3 03:34:24 2011 -0700

    rcu: Dump local stack if cannot dump all CPUs' stacks

    The trigger_all_cpu_backtrace() function is a no-op in architectures that
    do not define arch_trigger_all_cpu_backtrace.  On such architectures, RCU
    CPU stall warning messages contain no stack trace information, which makes
    debugging quite difficult.  This commit therefore substitutes dump_stack()
    for architectures that do not define arch_trigger_all_cpu_backtrace,
    so that at least the local CPU's stack is dumped as part of the RCU CPU
    stall warning message.

    Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>

commit d4506850f8d82170e6a5e81a4392a1a8b2aef121
Author: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Date:   Sat Jul 30 07:32:48 2011 -0700

    rcu: Make rcu_implicit_dynticks_qs() locals be correct size

    When the ->dynticks field in the rcu_dynticks structure changed to an
    atomic_t, its size on 64-bit systems changed from 64 bits to 32 bits.
    The local variables in rcu_implicit_dynticks_qs() need to change as
    well, hence this commit.

    Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>

commit c5e351ec2b375125f059729f3d009292423a1676
Author: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Date:   Fri Aug 5 22:39:02 2011 -0700

    rcu: Eliminate in_irq() checks in rcu_enter_nohz()

    The in_irq() check in rcu_enter_nohz() is redundant because if we really
    are in an interrupt, the attempt to re-enter dyntick-idle mode will invoke
    rcu_needs_cpu() in any case, which will force the check for RCU callbacks.
    So this commit removes the check along with the set_need_resched().

    Suggested-by: Frederic Weisbecker <fweisbec@gmail.com>
    Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>

commit d4546165060940fcab3d7072ddcbeabafc1005e0
Author: Paul E. McKenney <paul.mckenney@linaro.org>
Date:   Mon Jun 27 00:17:43 2011 -0700

    rcu: Simplify quiescent-state accounting

    There is often a delay between the time that a CPU passes through a
    quiescent state and the time that this quiescent state is reported to the
    RCU core.  It is quite possible that the grace period ended before the
    quiescent state could be reported, for example, some other CPU might have
    deduced that this CPU passed through dyntick-idle mode.  It is critically
    important that quiescent state be counted only against the grace period
    that was in effect at the time that the quiescent state was detected.

    Previously, this was handled by recording the number of the last grace
    period to complete when passing through a quiescent state.  The RCU
    core then checks this number against the current value, and rejects
    the quiescent state if there is a mismatch.  However, one additional
    possibility must be accounted for, namely that the quiescent state was
    recorded after the prior grace period completed but before the current
    grace period started.  In this case, the RCU core must reject the
    quiescent state, but the recorded number will match.  This is handled
    when the CPU becomes aware of a new grace period -- at that point,
    it invalidates any prior quiescent state.

    This works, but is a bit indirect.  The new approach records the current
    grace period, and the RCU core checks to see (1) that this is still the
    current grace period and (2) that this grace period has not yet ended.
    This approach simplifies reasoning about correctness, and this commit
    changes over to this new approach.

    Signed-off-by: Paul E. McKenney <paul.mckenney@linaro.org>
    Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>

commit 6bd8fee0d863a9a49cae564e52937753d97bc3e9
Author: Paul E. McKenney <paul.mckenney@linaro.org>
Date:   Sat Jun 25 06:36:56 2011 -0700

    rcu: Add grace-period, quiescent-state, and call_rcu trace events

    Add trace events to record grace-period start and end, quiescent states,
    CPUs noticing grace-period start and end, grace-period initialization,
    call_rcu() invocation, tasks blocking in RCU read-side critical sections,
    tasks exiting those same critical sections, force_quiescent_state()
    detection of dyntick-idle and offline CPUs, CPUs entering and leaving
    dyntick-idle mode (except from NMIs), CPUs coming online and going
    offline, and CPUs being kicked for staying in dyntick-idle mode for too
    long (as in many weeks, even on 32-bit systems).

    Signed-off-by: Paul E. McKenney <paul.mckenney@linaro.org>
    Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>

    rcu: Add the rcu flavor to callback trace events

    The earlier trace events for registering RCU callbacks and for invoking
    them did not include the RCU flavor (rcu_bh, rcu_preempt, or rcu_sched).
    This commit adds the RCU flavor to those trace events.

    Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>

commit ce26dc82e901fe94301e425491b8b2bb51ac30d8
Author: Paul E. McKenney <paul.mckenney@linaro.org>
Date:   Tue Jun 21 01:29:39 2011 -0700

    rcu: Update comments to reflect softirqs vs. kthreads

    We now have kthreads only for flavors of RCU that support boosting,
    so update the now-misleading comments accordingly.

    Signed-off-by: Paul E. McKenney <paul.mckenney@linaro.org>
    Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>

commit 66e0bfff346b4ec26a654e4815eb636298885247
Author: Paul E. McKenney <paul.mckenney@linaro.org>
Date:   Tue Jun 21 01:14:54 2011 -0700

    rcu: Add RCU type to callback-invocation tracing

    Add a string to the rcu_batch_start() and rcu_batch_end() trace
    messages that indicates the RCU type ("rcu_sched", "rcu_bh", or
    "rcu_preempt").  The trace messages for the actual invocations
    themselves are not marked, as it should be clear from the
    rcu_batch_start() and rcu_batch_end() events before and after.

    Signed-off-by: Paul E. McKenney <paul.mckenney@linaro.org>
    Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>

commit d1f5fc294111938c074dfd97cc04e045181c2243
Author: Paul E. McKenney <paul.mckenney@linaro.org>
Date:   Tue Jun 21 00:13:44 2011 -0700

    rcu: Put names into TINY_RCU structures under RCU_TRACE

    In order to allow event tracing to distinguish between flavors of
    RCU, we need those names in the relevant RCU data structures.  TINY_RCU
    has avoided them for memory-footprint reasons, so add them only if
    CONFIG_RCU_TRACE=y.

    Signed-off-by: Paul E. McKenney <paul.mckenney@linaro.org>
    Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>

commit 1b56df6e835b06c110a9f716c040b18ddbeaab67
Author: Paul E. McKenney <paul.mckenney@linaro.org>
Date:   Sat Jun 18 22:26:31 2011 -0700

    rcu: Event-trace markers for computing RCU CPU utilization

    This commit adds the trace_rcu_utilization() marker that is to be
    used to allow postprocessing scripts compute RCU's CPU utilization,
    give or take event-trace overhead.  Note that we do not include RCU's
    dyntick-idle interface because event tracing requires RCU protection,
    which is not available in dyntick-idle mode.

    Signed-off-by: Paul E. McKenney <paul.mckenney@linaro.org>
    Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>

commit 3fb6c2dda29742063209f72962547e2ef5983267
Author: Paul E. McKenney <paul.mckenney@linaro.org>
Date:   Fri Jun 17 15:53:19 2011 -0700

    rcu: Add event-tracing for RCU callback invocation

    There was recently some controversy about the overhead of invoking RCU
    callbacks.  Add TRACE_EVENT()s to obtain fine-grained timings for the
    start and stop of a batch of callbacks and also for each callback invoked.

    Signed-off-by: Paul E. McKenney <paul.mckenney@linaro.org>
    Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>

commit 33121207012a969edbb46ff952ecc551081bd12a
Author: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Date:   Thu May 26 22:14:36 2011 -0700

    rcu: Abstract common code for RCU grace-period-wait primitives

    Pull the code that waits for an RCU grace period into a single function,
    which is then called by synchronize_rcu() and friends in the case of
    TREE_RCU and TREE_PREEMPT_RCU, and from rcu_barrier() and friends in
    the case of TINY_RCU and TINY_PREEMPT_RCU.

    Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>

commit fd5191bc21ae58be61d040deade5c503352c8a28
Author: Prashant Somashekar <prashsomash@gmail.com>
Date:   Thu Nov 8 07:53:38 2012 -0500

    Revert "jrcu: fix compile"

    This reverts commit b8ebb3ee9da99bc12d049b139c7c7ba5b69f487f.

commit cf8a5cd9b3792df8ea6de4d565f74fead4e5e37b
Author: Alex Frid <afrid@nvidia.com>
Date:   Mon May 14 21:06:11 2012 -0700

    cpufreq: Don't clip PM QoS requests to old policy limits

    Clipping PM QoS requests to combined old policy limits that include
    both PM QoS and user policy requests creates a circular dependency.
    As a result new PM QoS maximum limit is rejected if it is above
    previous PM QoS minimum limit even though the new PM QoS minimum
    limit has been already lowered below new PM QoS maximum limit.

    Instead clip PM QoS request to the old user policy limits only.

    Change-Id: Ice0a53a699e0798f07f0e32d6b8a28586fe5db0c
    Signed-off-by: Alex Frid <afrid@nvidia.com>
    Reviewed-on: http://git-master/r/102386
    Reviewed-by: Automatic_Commit_Validation_User
    Reviewed-by: Donghan Ryu <dryu@nvidia.com>
    Reviewed-by: Antti Miettinen <amiettinen@nvidia.com>
    Reviewed-by: Diwakar Tundlam <dtundlam@nvidia.com>
    Tested-by: Vikas Ramesh Kedigehalli <vikasr@nvidia.com>

commit ca8ae87361dab59cc70ffa037aa55ccff7315b16
Author: Jihoon Bang <jbang@nvidia.com>
Date:   Thu May 3 12:20:00 2012 -0700

    media: video: tegra: add EMC clock rate control

    Add EMC clock rate control to tegra_camera ioctl.
    This change allows user space to change EMC clock requirement
    for camera based on use case and resolution.

    For example, video recording use case needs more than double
    memory bandwidth of preview use case.

    Bug 964635

    Change-Id: Ibe5a77a810869b53b6e057f2ee62ebb96997c2f4
    Signed-off-by: Jihoon Bang <jbang@nvidia.com>
    Reviewed-on: http://git-master/r/101274
    Reviewed-by: Automatic_Commit_Validation_User
    GVS: Gerrit_Virtual_Submit
    Reviewed-by: Dan Willemsen <dwillemsen@nvidia.com>

commit a0a3c62cba23d882676fa49c56a93e9df8cca97f
Author: Steve Kondik <shade@chemlab.org>
Date:   Tue Sep 11 00:00:00 2012 -0700

    drivers: cpufreq: Send a uevent when governor changes

    * Useful so userspace tools can reconfigure.

commit 3a46c82090abcb2350165e562eed2f425acc0bdd
Author: Adam77Root <adam77root@gmail.com>
Date:   Sun Jun 9 17:15:55 2013 +0200

    defconfig: add some networking options found in CM's d2

    Change-Id: I2cee149f1bdc9c4bc0aca4b7cf1390f3e0b464ed

commit 707e9e521bde48149730deb06b230d3de3e0b8f7
Author: Paolo Valente <paolo.valente@unimore.it>
Date:   Wed Oct 3 12:00:00 2012 -0400

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

    Add the BFQ-v5 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 2f0ef814e854c2118f0eb7cf1d870bd6e34f5e49
Author: Prashant Somashekar <prashsomash@gmail.com>
Date:   Mon Oct 8 12:41:18 2012 -0400

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

    This reverts commit ed5a3f103b66dd0cf2c9a213bc202830d3115ec1.

commit 32620179c20e84ea23809fe03431a1003e8a2a6e
Author: Adam77Root <adam77root@gmail.com>
Date:   Sun Jun 9 17:11:04 2013 +0200

    defconfig: switch to TREE_PREEMPT_RCU + RCU_BOOST

    Change-Id: Icc1c9e96a3089bdc3c62d09129bd7e0114c925d2

Change-Id: Ie0b3ce861ad986f8a4cf9a7cd668955b32560782