Linux 3.0.68

commit e28c3f2b514b5581e15614f7cf976131092cf4b6
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Mon Mar 4 06:09:28 2013 +0800

    Linux 3.0.68

commit 6c80ee53f3737993f693bf2a3b4b3e4bbde9b51f
Author: Ian Abbott <abbotti@mev.co.uk>
Date:   Wed Feb 27 10:56:19 2013 +0000

    staging: comedi: check s->async for poll(), read() and write()

    commit cc400e185c07c15a42d2635995f422de5b94b696 upstream.

    Some low-level comedi drivers (incorrectly) point `dev->read_subdev` or
    `dev->write_subdev` to a subdevice that does not support asynchronous
    commands.  Comedi's poll(), read() and write() file operation handlers
    assume these subdevices do support asynchronous commands.  In
    particular, they assume `s->async` is valid (where `s` points to the
    read or write subdevice), which it won't be if it has been set
    incorrectly.  This can lead to a NULL pointer dereference.

    Check `s->async` is non-NULL in `comedi_poll()`, `comedi_read()` and
    `comedi_write()` to avoid the bug.

    Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 544da4403b05e874e134919db7124def003ef7cf
Author: Ian Abbott <abbotti@mev.co.uk>
Date:   Wed Feb 27 12:52:46 2013 +0000

    staging: comedi: ni_labpc: set up command4 register *after* command3

    Commit 22056e2b46246d97ff0f7c6e21a77b8daa07f02c upstream.

    Tuomas <tvainikk _at_ gmail _dot_ com> reported problems getting
    meaningful output from a Lab-PC+ in differential mode for AI cmds, but
    AI insn reads gave correct readings.  He tracked it down to two
    problems, one of which is addressed by this patch.

    It seems that writing to the command3 register after writing to the
    command4 register in `labpc_ai_cmd()` messes up the differential
    reference bit setting in the command4 register.  Set up the command4
    register after the command3 register (as in `labpc_ai_rinsn()`) to avoid
    the problem.

    Thanks to Tuomas for suggesting the fix.

    Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5e6af63de116db55be85da4374441f7963d11281
Author: Ian Abbott <abbotti@mev.co.uk>
Date:   Wed Feb 27 12:52:45 2013 +0000

    staging: comedi: ni_labpc: correct differential channel sequence for AI commands

    Commit 4c4bc25d0fa6beaf054c0b4c3b324487f266c820 upstream.

    Tuomas <tvainikk _at_ gmail _dot_ com> reported problems getting
    meaningful output from a Lab-PC+ in differential mode for AI cmds, but
    AI insn reads gave correct readings.  He tracked it down to two
    problems, one of which is addressed by this patch.

    It seems the setting of the channel bits for particular scanning modes
    was incorrect for differential mode.  (Only half the number of channels
    are available in differential mode; comedi refers to them as channels 0,
    1, 2 and 3, but the hardware documentation refers to them as channels 0,
    2, 4 and 6.)  In differential mode, the setting of the channel enable
    bits in the command1 register should depend on whether the scan enable
    bit is set.  Effectively, we need to double the comedi channel number
    when the scan enable bit is not set in differential mode.  The scan
    enable bit gets set when the AI scan mode is `MODE_MULT_CHAN_UP` or
    `MODE_MULT_CHAN_DOWN`, and gets cleared when the AI scan mode is
    `MODE_SINGLE_CHAN` or `MODE_SINGLE_CHAN_INTERVAL`.  The existing test
    for whether the comedi channel number needs to be doubled in
    differential mode is incorrect in `labpc_ai_cmd()`.  This patch corrects
    the test.

    Thanks to Tuomas for suggesting the fix.

    Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d81d788db85abd39fd7753e2482f748c48de202a
Author: Jiri Slaby <jslaby@suse.cz>
Date:   Mon Mar 4 06:09:07 2013 +0800

    s390/kvm: Fix store status for ACRS/FPRS fix

    In 3.0.67, commit 58c9ce6fad8e00d9726447f939fe7e78e2aec891 (s390/kvm:
    Fix store status for ACRS/FPRS), upstream commit
    15bc8d8457875f495c59d933b05770ba88d1eacb, added a call to
    save_access_regs to save ACRS. But we do not have ARCS in kvm_run in
    3.0 yet, so this results in:
    arch/s390/kvm/kvm-s390.c: In function 'kvm_s390_vcpu_store_status':
    arch/s390/kvm/kvm-s390.c:593: error: 'struct kvm_run' has no member named 's'

    Fix it by saving guest_acrs which is where ARCS are in 3.0.

    Signed-off-by: Jiri Slaby <jslaby@suse.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 55bce39db26a3b1d6b18fc0ae5d57948946f0c49
Author: Jiri Slaby <jslaby@suse.cz>
Date:   Mon Mar 4 06:09:07 2013 +0800

    dca: check against empty dca_domains list before unregister provider fix

    In 3.0.67, commit 7a9a20ea77e7508c795dead9ab2f6c98a617762d (dca: check
    against empty dca_domains list before unregister provider), upstream
    commit c419fcfd071cf34ba00f9f65282583772d2655e7, added a fail path to
    unregister_dca_provider. It added there also a call to
    raw_spin_unlock_irqrestore. But in 3.0, the lock is not raw, so this
    results in:
    drivers/dca/dca-core.c: In function 'unregister_dca_provider':
    drivers/dca/dca-core.c:413: warning: passing argument 1 of '_raw_spin_unlock_irqrestore' from incompatible pointer type

    Fix it by calling spin_unlock_irqrestore properly.

    Signed-off-by: Jiri Slaby <jslaby@suse.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit cc0e3e13b0a90e5ff42d5b134939eacf5e7e497c
Author: Li Zefan <lizefan@huawei.com>
Date:   Thu Jan 24 14:43:28 2013 +0800

    cgroup: fix exit() vs rmdir() race

    commit 71b5707e119653039e6e95213f00479668c79b75 upstream.

    In cgroup_exit() put_css_set_taskexit() is called without any lock,
    which might lead to accessing a freed cgroup:

    thread1                           thread2
    ---------------------------------------------
    exit()
      cgroup_exit()
        put_css_set_taskexit()
          atomic_dec(cgrp->count);
                                       rmdir();
          /* not safe !! */
          check_for_release(cgrp);

    rcu_read_lock() can be used to make sure the cgroup is alive.

    Signed-off-by: Li Zefan <lizefan@huawei.com>
    Signed-off-by: Tejun Heo <tj@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6403d47ff9392807fcfa4464527193e0cab65b2a
Author: Li Zefan <lizefan@huawei.com>
Date:   Fri Jan 25 16:08:01 2013 +0800

    cpuset: fix cpuset_print_task_mems_allowed() vs rename() race

    commit 63f43f55c9bbc14f76b582644019b8a07dc8219a upstream.

    rename() will change dentry->d_name. The result of this race can
    be worse than seeing partially rewritten name, but we might access
    a stale pointer because rename() will re-allocate memory to hold
    a longer name.

    It's safe in the protection of dentry->d_lock.

    v2: check NULL dentry before acquiring dentry lock.

    Signed-off-by: Li Zefan <lizefan@huawei.com>
    Signed-off-by: Tejun Heo <tj@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2212f47b734e5b9461b5c3f555dc653ea7aa212f
Author: Stoney Wang <song-bo.wang@hp.com>
Date:   Thu Feb 7 10:53:02 2013 -0800

    x86/apic: Work around boot failure on HP ProLiant DL980 G7 Server systems

    commit cb214ede7657db458fd0b2a25ea0b28dbf900ebc upstream.

    When a HP ProLiant DL980 G7 Server boots a regular kernel,
    there will be intermittent lost interrupts which could
    result in a hang or (in extreme cases) data loss.

    The reason is that this system only supports x2apic physical
    mode, while the kernel boots with a logical-cluster default
    setting.

    This bug can be worked around by specifying the "x2apic_phys" or
    "nox2apic" boot option, but we want to handle this system
    without requiring manual workarounds.

    The BIOS sets ACPI_FADT_APIC_PHYSICAL in FADT table.
    As all apicids are smaller than 255, BIOS need to pass the
    control to the OS with xapic mode, according to x2apic-spec,
    chapter 2.9.

    Current code handle x2apic when BIOS pass with xapic mode
    enabled:

    When user specifies x2apic_phys, or FADT indicates PHYSICAL:

    1. During madt oem check, apic driver is set with xapic logical
       or xapic phys driver at first.

    2. enable_IR_x2apic() will enable x2apic_mode.

    3. if user specifies x2apic_phys on the boot line, x2apic_phys_probe()
       will install the correct x2apic phys driver and use x2apic phys mode.
       Otherwise it will skip the driver will let x2apic_cluster_probe to
       take over to install x2apic cluster driver (wrong one) even though FADT
       indicates PHYSICAL, because x2apic_phys_probe does not check
       FADT PHYSICAL.

    Add checking x2apic_fadt_phys in x2apic_phys_probe() to fix the
    problem.

    Signed-off-by: Stoney Wang <song-bo.wang@hp.com>
    [ updated the changelog and simplified the code ]
    Signed-off-by: Yinghai Lu <yinghai@kernel.org>
    Signed-off-by: Zhang Lin-Bao <Linbao.zhang@hp.com>
    [ make a patch specially for 3.0.66]
    Link: http://lkml.kernel.org/r/1360263182-16226-1-git-send-email-yinghai@kernel.org
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f39edfbf6dbf8e29cfbafd67d93fa1e30196701c
Author: Kees Cook <keescook@chromium.org>
Date:   Thu Feb 7 09:44:13 2013 -0800

    x86: Do not leak kernel page mapping locations

    commit e575a86fdc50d013bf3ad3aa81d9100e8e6cc60d upstream.

    Without this patch, it is trivial to determine kernel page
    mappings by examining the error code reported to dmesg[1].
    Instead, declare the entire kernel memory space as a violation
    of a present page.

    Additionally, since show_unhandled_signals is enabled by
    default, switch branch hinting to the more realistic
    expectation, and unobfuscate the setting of the PF_PROT bit to
    improve readability.

    [1] http://vulnfactory.org/blog/2013/02/06/a-linux-memory-trick/

    Reported-by: Dan Rosenberg <dan.j.rosenberg@gmail.com>
    Suggested-by: Brad Spengler <spender@grsecurity.net>
    Signed-off-by: Kees Cook <keescook@chromium.org>
    Acked-by: H. Peter Anvin <hpa@zytor.com>
    Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
    Cc: Frederic Weisbecker <fweisbec@gmail.com>
    Cc: Eric W. Biederman <ebiederm@xmission.com>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Andrew Morton <akpm@linux-foundation.org>
    Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
    Link: http://lkml.kernel.org/r/20130207174413.GA12485@www.outflux.net
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: CAI Qian <caiqian@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 43f514598ad16af1c6dd08dd429631eaafef7849
Author: Helge Deller <deller@gmx.de>
Date:   Mon Feb 4 19:39:52 2013 +0000

    unbreak automounter support on 64-bit kernel with 32-bit userspace (v2)

    commit 4f4ffc3a5398ef9bdbb32db04756d7d34e356fcf upstream.

    automount-support is broken on the parisc architecture, because the existing
    #if list does not include a check for defined(__hppa__). The HPPA (parisc)
    architecture is similiar to other 64bit Linux targets where we have to define
    autofs_wqt_t (which is passed back and forth to user space) as int type which
    has a size of 32bit across 32 and 64bit kernels.

    During the discussion on the mailing list, H. Peter Anvin suggested to invert
    the #if list since only specific platforms (specifically those who do not have
    a 32bit userspace, like IA64 and Alpha) should have autofs_wqt_t as unsigned
    long type.

    This suggestion is probably the best way to go, since Arm64 (and maybe others?)
    seems to have a non-working automounter. So in the long run even for other new
    upcoming architectures this inverted check seem to be the best solution, since
    it will not require them to change this #if again (unless they are 64bit only).

    Signed-off-by: Helge Deller <deller@gmx.de>
    Acked-by: H. Peter Anvin <hpa@zytor.com>
    Acked-by: Ian Kent <raven@themaw.net>
    Acked-by: Catalin Marinas <catalin.marinas@arm.com>
    CC: James Bottomley <James.Bottomley@HansenPartnership.com>
    CC: Rolf Eike Beer <eike-kernel@sf-tec.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8a9279a5af607d9f59b3921c639df139a28bcef6
Author: Oleg Nesterov <oleg@redhat.com>
Date:   Tue Feb 19 14:56:53 2013 +0100

    wake_up_process() should be never used to wakeup a TASK_STOPPED/TRACED task

    Upstream commit 9067ac85d533651b98c2ff903182a20cbb361fcb.

    wake_up_process() should never wakeup a TASK_STOPPED/TRACED task.
    Change it to use TASK_NORMAL and add the WARN_ON().

    TASK_ALL has no other users, probably can be killed.

    Signed-off-by: Oleg Nesterov <oleg@redhat.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Michal Hocko <mhocko@suse.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a214998c48e204227d52a81dd459ea51a8a9ae36
Author: Oleg Nesterov <oleg@redhat.com>
Date:   Tue Feb 19 14:56:52 2013 +0100

    ptrace: ensure arch_ptrace/ptrace_request can never race with SIGKILL

    Upstream commit 9899d11f654474d2d54ea52ceaa2a1f4db3abd68.

    putreg() assumes that the tracee is not running and pt_regs_access() can
    safely play with its stack.  However a killed tracee can return from
    ptrace_stop() to the low-level asm code and do RESTORE_REST, this means
    that debugger can actually read/modify the kernel stack until the tracee
    does SAVE_REST again.

    set_task_blockstep() can race with SIGKILL too and in some sense this
    race is even worse, the very fact the tracee can be woken up breaks the
    logic.

    As Linus suggested we can clear TASK_WAKEKILL around the arch_ptrace()
    call, this ensures that nobody can ever wakeup the tracee while the
    debugger looks at it.  Not only this fixes the mentioned problems, we
    can do some cleanups/simplifications in arch_ptrace() paths.

    Probably ptrace_unfreeze_traced() needs more callers, for example it
    makes sense to make the tracee killable for oom-killer before
    access_process_vm().

    While at it, add the comment into may_ptrace_stop() to explain why
    ptrace_stop() still can't rely on SIGKILL and signal_pending_state().

    Reported-by: Salman Qazi <sqazi@google.com>
    Reported-by: Suleiman Souhlal <suleiman@google.com>
    Suggested-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Oleg Nesterov <oleg@redhat.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Michal Hocko <mhocko@suse.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 964b12560e1d50f31bc1cc0ac662d52bdbdb6f40
Author: Oleg Nesterov <oleg@redhat.com>
Date:   Tue Feb 19 14:56:51 2013 +0100

    ptrace: introduce signal_wake_up_state() and ptrace_signal_wake_up()

    Upstream commit 910ffdb18a6408e14febbb6e4b6840fd2c928c82.

    Cleanup and preparation for the next change.

    signal_wake_up(resume => true) is overused. None of ptrace/jctl callers
    actually want to wakeup a TASK_WAKEKILL task, but they can't specify the
    necessary mask.

    Turn signal_wake_up() into signal_wake_up_state(state), reintroduce
    signal_wake_up() as a trivial helper, and add ptrace_signal_wake_up()
    which adds __TASK_TRACED.

    This way ptrace_signal_wake_up() can work "inside" ptrace_request()
    even if the tracee doesn't have the TASK_WAKEKILL bit set.

    Signed-off-by: Oleg Nesterov <oleg@redhat.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Michal Hocko <mhocko@suse.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 603b86549a4d6928d1059b19df2dfc5d61070533
Author: Michael S. Tsirkin <mst@redhat.com>
Date:   Mon Nov 26 05:57:27 2012 +0000

    vhost: fix length for cross region descriptor

    commit bd97120fc3d1a11f3124c7c9ba1d91f51829eb85 upstream.

    If a single descriptor crosses a region, the
    second chunk length should be decremented
    by size translated so far, instead it includes
    the full descriptor length.

    Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
    Acked-by: Jason Wang <jasowang@redhat.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4bf6d0956ad678f3ef59362cb41dae05a2259f78
Author: J. Bruce Fields <bfields@redhat.com>
Date:   Sun Feb 10 11:33:48 2013 -0500

    svcrpc: make svc_age_temp_xprts enqueue under sv_lock

    commit e75bafbff2270993926abcc31358361db74a9bc2 upstream.

    svc_age_temp_xprts expires xprts in a two-step process: first it takes
    the sv_lock and moves the xprts to expire off their server-wide list
    (sv_tempsocks or sv_permsocks) to a local list.  Then it drops the
    sv_lock and enqueues and puts each one.

    I see no reason for this: svc_xprt_enqueue() will take sp_lock, but the
    sv_lock and sp_lock are not otherwise nested anywhere (and documentation
    at the top of this file claims it's correct to nest these with sp_lock
    inside.)

    Tested-by: Jason Tibbitts <tibbs@math.uh.edu>
    Tested-by: Paweł Sikora <pawel.sikora@agmk.net>
    Signed-off-by: J. Bruce Fields <bfields@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fd80f53550720f200ca0469e9419c750f895ab50
Author: Niu Yawei <yawei.niu@gmail.com>
Date:   Fri Feb 1 21:31:27 2013 -0500

    ext4: fix race in ext4_mb_add_n_trim()

    commit f1167009711032b0d747ec89a632a626c901a1ad upstream.

    In ext4_mb_add_n_trim(), lg_prealloc_lock should be taken when
    changing the lg_prealloc_list.

    Signed-off-by: Niu Yawei <yawei.niu@intel.com>
    Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5dec43e3d688390256df3343bb444e7ed0022f44
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Tue Nov 27 13:35:09 2012 -0300

    media: rc: unlock on error in show_protocols()

    commit 30ebc5e44d057a1619ad63fe32c8c1670c37c4b8 upstream.

    We recently introduced a new return -ENODEV in this function but we need
    to unlock before returning.

    [mchehab@redhat.com: found two patches with the same fix. Merged SOB's/acks into one patch]
    Acked-by: Herton R. Krzesinski <herton.krzesinski@canonical.com>
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: Douglas Bagnall <douglas@paradise.net.nz>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d6bf427fdac5fb26636d72f04289780a0ff2ca93
Author: Xi Wang <xi.wang@gmail.com>
Date:   Wed Feb 27 17:05:21 2013 -0800

    sysctl: fix null checking in bin_dn_node_address()

    commit df1778be1a33edffa51d094eeda87c858ded6560 upstream.

    The null check of `strchr() + 1' is broken, which is always non-null,
    leading to OOB read.  Instead, check the result of strchr().

    Signed-off-by: Xi Wang <xi.wang@gmail.com>
    Cc: "Eric W. Biederman" <ebiederm@xmission.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 cbf253c44b52b3c6b921a22f05243a1dc7a00122
Author: Tejun Heo <tj@kernel.org>
Date:   Wed Feb 27 17:04:04 2013 -0800

    firewire: add minor number range check to fw_device_init()

    commit 3bec60d511179853138836ae6e1b61fe34d9235f upstream.

    fw_device_init() didn't check whether the allocated minor number isn't
    too large.  Fail if it goes overflows MINORBITS.

    Signed-off-by: Tejun Heo <tj@kernel.org>
    Suggested-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
    Acked-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4ec348232dc21cf79b62f32e0bdb099c9d817941
Author: Tejun Heo <tj@kernel.org>
Date:   Wed Feb 27 17:03:34 2013 -0800

    idr: fix a subtle bug in idr_get_next()

    commit 6cdae7416a1c45c2ce105a78187d9b7e8feb9e24 upstream.

    The iteration logic of idr_get_next() is borrowed mostly verbatim from
    idr_for_each().  It walks down the tree looking for the slot matching
    the current ID.  If the matching slot is not found, the ID is
    incremented by the distance of single slot at the given level and
    repeats.

    The implementation assumes that during the whole iteration id is aligned
    to the layer boundaries of the level closest to the leaf, which is true
    for all iterations starting from zero or an existing element and thus is
    fine for idr_for_each().

    However, idr_get_next() may be given any point and if the starting id
    hits in the middle of a non-existent layer, increment to the next layer
    will end up skipping the same offset into it.  For example, an IDR with
    IDs filled between [64, 127] would look like the following.

              [  0  64 ... ]
           /----/   |
           |        |
          NULL    [ 64 ... 127 ]

    If idr_get_next() is called with 63 as the starting point, it will try
    to follow down the pointer from 0.  As it is NULL, it will then try to
    proceed to the next slot in the same level by adding the slot distance
    at that level which is 64 - making the next try 127.  It goes around the
    loop and finds and returns 127 skipping [64, 126].

    Note that this bug also triggers in idr_for_each_entry() loop which
    deletes during iteration as deletions can make layers go away leaving
    the iteration with unaligned ID into missing layers.

    Fix it by ensuring proceeding to the next slot doesn't carry over the
    unaligned offset - ie.  use round_up(id + 1, slot_distance) instead of
    id += slot_distance.

    Signed-off-by: Tejun Heo <tj@kernel.org>
    Reported-by: David Teigland <teigland@redhat.com>
    Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 975398374dac831d5d5c2825615c489aee24ea3a
Author: Jan Beulich <JBeulich@suse.com>
Date:   Thu Dec 20 10:31:11 2012 +0000

    xen-blkback: do not leak mode property

    commit 9d092603cc306ee6edfe917bf9ab8beb5f32d7bc upstream.

    "be->mode" is obtained from xenbus_read(), which does a kmalloc() for
    the message body. The short string is never released, so do it along
    with freeing "be" itself, and make sure the string isn't kept when
    backend_changed() doesn't complete successfully (which made it
    desirable to slightly re-structure that function, so that the error
    cleanup can be done in one place).

    Reported-by: Olaf Hering <olaf@aepfle.de>
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ad315127433dc9a8147e7f6b43f21b3d0061003a
Author: Xiaowei.Hu <xiaowei.hu@oracle.com>
Date:   Wed Feb 27 17:02:49 2013 -0800

    ocfs2: ac->ac_allow_chain_relink=0 won't disable group relink

    commit 309a85b6861fedbb48a22d45e0e079d1be993b3a upstream.

    ocfs2_block_group_alloc_discontig() disables chain relink by setting
    ac->ac_allow_chain_relink = 0 because it grabs clusters from multiple
    cluster groups.

    It doesn't keep the credits for all chain relink,but
    ocfs2_claim_suballoc_bits overrides this in this call trace:
    ocfs2_block_group_claim_bits()->ocfs2_claim_clusters()->
    __ocfs2_claim_clusters()->ocfs2_claim_suballoc_bits()
    ocfs2_claim_suballoc_bits set ac->ac_allow_chain_relink = 1; then call
    ocfs2_search_chain() one time and disable it again, and then we run out
    of credits.

    Fix is to allow relink by default and disable it in
    ocfs2_block_group_alloc_discontig.

    Without this patch, End-users will run into a crash due to run out of
    credits, backtrace like this:

      RIP: 0010:[<ffffffffa0808b14>]  [<ffffffffa0808b14>]
      jbd2_journal_dirty_metadata+0x164/0x170 [jbd2]
      RSP: 0018:ffff8801b919b5b8  EFLAGS: 00010246
      RAX: 0000000000000000 RBX: ffff88022139ddc0 RCX: ffff880159f652d0
      RDX: ffff880178aa3000 RSI: ffff880159f652d0 RDI: ffff880087f09bf8
      RBP: ffff8801b919b5e8 R08: 0000000000000000 R09: 0000000000000000
      R10: 0000000000001e00 R11: 00000000000150b0 R12: ffff880159f652d0
      R13: ffff8801a0cae908 R14: ffff880087f09bf8 R15: ffff88018d177800
      FS:  00007fc9b0b6b6e0(0000) GS:ffff88022fd40000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
      CR2: 000000000040819c CR3: 0000000184017000 CR4: 00000000000006e0
      DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
      Process dd (pid: 9945, threadinfo ffff8801b919a000, task ffff880149a264c0)
      Call Trace:
        ocfs2_journal_dirty+0x2f/0x70 [ocfs2]
        ocfs2_relink_block_group+0x111/0x480 [ocfs2]
        ocfs2_search_chain+0x455/0x9a0 [ocfs2]
        ...

    Signed-off-by: Xiaowei.Hu <xiaowei.hu@oracle.com>
    Reviewed-by: Srinivas Eeda <srinivas.eeda@oracle.com>
    Cc: Mark Fasheh <mfasheh@suse.com>
    Cc: Joel Becker <jlbec@evilplan.org>
    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 954497ea2037e8c42fe1c7a0882030b62ac9116c
Author: Nicholas Bellinger <nab@linux-iscsi.org>
Date:   Mon Feb 18 18:31:37 2013 -0800

    target: Add missing mapped_lun bounds checking during make_mappedlun setup

    commit fbbf8555a986ed31e54f006b6cc637ea4ff1425b upstream.

    This patch adds missing bounds checking for the configfs provided
    mapped_lun value during target_fabric_make_mappedlun() setup ahead
    of se_lun_acl initialization.

    This addresses a potential OOPs when using a mapped_lun value that
    exceeds the hardcoded TRANSPORT_MAX_LUNS_PER_TPG-1 value within
    se_node_acl->device_list[].

    Reported-by: Jan Engelhardt <jengelh@inai.de>
    Cc: Jan Engelhardt <jengelh@inai.de>
    Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 93b6b299f7a97a8ce2f8ab7b14195f8d2d131905
Author: H. Peter Anvin <hpa@linux.intel.com>
Date:   Wed Feb 27 12:46:40 2013 -0800

    x86: Make sure we can boot in the case the BDA contains pure garbage

    commit 7c10093692ed2e6f318387d96b829320aa0ca64c upstream.

    On non-BIOS platforms it is possible that the BIOS data area contains
    garbage instead of being zeroed or something equivalent (firmware
    people: we are talking of 1.5K here, so please do the sane thing.)

    We need on the order of 20-30K of low memory in order to boot, which
    may grow up to < 64K in the future.  We probably want to avoid the
    lowest of the low memory.  At the same time, it seems extremely
    unlikely that a legitimate EBDA would ever reach down to the 128K
    (which would require it to be over half a megabyte in size.)  Thus,
    pick 128K as the cutoff for "this is insane, ignore."  We may still
    end up reserving a bunch of extra memory on the low megabyte, but that
    is not really a major issue these days.  In the worst case we lose
    512K of RAM.

    This code really should be merged with trim_bios_range() in
    arch/x86/kernel/setup.c, but that is a bigger patch for a later merge
    window.

    Reported-by: Darren Hart <dvhart@linux.intel.com>
    Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
    Cc: Matt Fleming <matt.fleming@intel.com>
    Link: http://lkml.kernel.org/n/tip-oebml055yyfm8yxmria09rja@git.kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 834f139f1613ba0ca3239a6a12be97c70698f189
Author: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date:   Mon Feb 25 15:54:09 2013 -0500

    doc, kernel-parameters: Document 'console=hvc<n>'

    commit a2fd6419174470f5ae6383f5037d0ee21ed9833f upstream.

    Both the PowerPC hypervisor and Xen hypervisor can utilize the
    hvc driver.

    Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
    Link: http://lkml.kernel.org/r/1361825650-14031-3-git-send-email-konrad.wilk@oracle.com
    Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9b1d040fee4c82b3c69283cbb8a4d2a1dc062a21
Author: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date:   Mon Feb 25 15:54:08 2013 -0500

    doc, xen: Mention 'earlyprintk=xen' in the documentation.

    commit 2482a92e7d17187301d7313cfe5021b13393a0b4 upstream.

    The earlyprintk for Xen PV guests utilizes a simple hypercall
    (console_io) to provide output to Xen emergency console.

    Note that the Xen hypervisor should be booted with 'loglevel=all'
    to output said information.

    Reported-by: H. Peter Anvin <hpa@zytor.com>
    Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
    Link: http://lkml.kernel.org/r/1361825650-14031-2-git-send-email-konrad.wilk@oracle.com
    Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 85fed56cdbc7973f34524ee9efa885ef66e4d831
Author: Steven Rostedt (Red Hat) <rostedt@goodmis.org>
Date:   Wed Feb 13 15:18:38 2013 -0500

    ftrace: Call ftrace cleanup module notifier after all other notifiers

    commit 8c189ea64eea01ca20d102ddb74d6936dd16c579 upstream.

    Commit: c1bf08ac "ftrace: Be first to run code modification on modules"

    changed ftrace module notifier's priority to INT_MAX in order to
    process the ftrace nops before anything else could touch them
    (namely kprobes). This was the correct thing to do.

    Unfortunately, the ftrace module notifier also contains the ftrace
    clean up code. As opposed to the set up code, this code should be
    run *after* all the module notifiers have run in case a module is doing
    correct clean-up and unregisters its ftrace hooks. Basically, ftrace
    needs to do clean up on module removal, as it needs to know about code
    being removed so that it doesn't try to modify that code. But after it
    removes the module from its records, if a ftrace user tries to remove
    a probe, that removal will fail due as the record of that code segment
    no longer exists.

    Nothing really bad happens if the probe removal is called after ftrace
    did the clean up, but the ftrace removal function will return an error.
    Correct code (such as kprobes) will produce a WARN_ON() if it fails
    to remove the probe. As people get annoyed by frivolous warnings, it's
    best to do the ftrace clean up after everything else.

    By splitting the ftrace_module_notifier into two notifiers, one that
    does the module load setup that is run at high priority, and the other
    that is called for module clean up that is run at low priority, the
    problem is solved.

    Reported-by: Frank Ch. Eigler <fche@redhat.com>
    Acked-by: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
    Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ffe56d754e59cdb086b76b95fe0c3a0302ec46c8
Author: Tejun Heo <tj@kernel.org>
Date:   Wed Feb 20 15:24:12 2013 -0800

    posix-timer: Don't call idr_find() with out-of-range ID

    commit e182bb38d7db7494fa5dcd82da17fe0dedf60ecf upstream.

    When idr_find() was fed a negative ID, it used to look up the ID
    ignoring the sign bit before recent ("idr: remove MAX_IDR_MASK and
    move left MAX_IDR_* into idr.c") patch. Now a negative ID triggers
    a WARN_ON_ONCE().

    __lock_timer() feeds timer_id from userland directly to idr_find()
    without sanitizing it which can trigger the above malfunctions.  Add a
    range check on @timer_id before invoking idr_find() in __lock_timer().

    While timer_t is defined as int by all archs at the moment, Andrew
    worries that it may be defined as a larger type later on.  Make the
    test cover larger integers too so that it at least is guaranteed to
    not return the wrong timer.

    Note that WARN_ON_ONCE() in idr_find() on id < 0 is transitional
    precaution while moving away from ignoring MSB.  Once it's gone we can
    remove the guard as long as timer_t isn't larger than int.

    Signed-off-by: Tejun Heo <tj@kernel.org>
    Reported-by: Sasha Levin <sasha.levin@oracle.com>
    Cc: Andrew Morton <akpm@linux-foundation.org>
    Link: http://lkml.kernel.org/r/20130220232412.GL3570@htj.dyndns.org
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ffbf1423cc7e8ed018d0ba8fbe3f9f3bb816fa4c
Author: Joerg Roedel <joro@8bytes.org>
Date:   Wed Feb 6 12:55:23 2013 +0100

    iommu/amd: Initialize device table after dma_ops

    commit f528d980c17b8714aedc918ba86e058af914d66b upstream.

    When dma_ops are initialized the unity mappings are
    created. The init_device_table_dma() function makes sure DMA
    from all devices is blocked by default. This opens a short
    window in time where DMA to unity mapped regions is blocked
    by the IOMMU. Make sure this does not happen by initializing
    the device table after dma_ops.

    Signed-off-by: Joerg Roedel <joro@8bytes.org>
    Signed-off-by: Shuah Khan <shuah.khan@hp.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1adbb5db21a1e08537061607abc9b0a9e7e12848
Author: Theodore Ts'o <tytso@mit.edu>
Date:   Thu Jan 24 23:24:56 2013 -0500

    quota: autoload the quota_v2 module for QFMT_VFS_V1 quota format

    commit c3ad83d9efdfe6a86efd44945a781f00c879b7b4 upstream.

    Otherwise, ext4 file systems with the quota featured enable will get a
    very confusing "No such process" error message if the quota code is
    built as a module and the quota_v2 module has not been loaded.

    Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
    Reviewed-by: Carlos Maiolino <cmaiolino@redhat.com>
    Acked-by: Jan Kara <jack@suse.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>