commit 94402d16da4e122c8976b61145432e1c3ccfbd29
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Tue Apr 16 21:43:02 2013 -0700

    Linux 3.4.41

commit 06ce3e44cb3152be067f7a637a08df8c577f4620
Author: David Woodhouse <David.Woodhouse@intel.com>
Date:   Tue Oct 9 15:08:10 2012 +0100

    mtd: Disable mtdchar mmap on MMU systems
    
    commit f5cf8f07423b2677cebebcebc863af77223a4972 upstream.
    
    This code was broken because it assumed that all MTD devices were map-based.
    Disable it for now, until it can be fixed properly for the next merge window.
    
    Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 880f56d9b7d77917de8bde461c69e4293cc04dd0
Author: Hayes Wang <hayeswang@realtek.com>
Date:   Sat Apr 13 12:26:32 2013 +0200

    r8169: fix auto speed down issue
    
    commit e2409d83434d77874b461b78af6a19cd6e6a1280 upstream.
    
    It would cause no link after suspending or shutdowning when the
    nic changes the speed to 10M and connects to a link partner which
    forces the speed to 100M.
    
    Check the link partner ability to determine which speed to set.
    
    Signed-off-by: Hayes Wang <hayeswang@realtek.com>
    Acked-by: Francois Romieu <romieu@fr.zoreil.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2931b31ff9987ddbaebc4101e159a9e298e792ef
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Sat Apr 13 15:15:30 2013 -0700

    kobject: fix kset_find_obj() race with concurrent last kobject_put()
    
    commit a49b7e82cab0f9b41f483359be83f44fbb6b4979 upstream.
    
    Anatol Pomozov identified a race condition that hits module unloading
    and re-loading.  To quote Anatol:
    
     "This is a race codition that exists between kset_find_obj() and
      kobject_put().  kset_find_obj() might return kobject that has refcount
      equal to 0 if this kobject is freeing by kobject_put() in other
      thread.
    
      Here is timeline for the crash in case if kset_find_obj() searches for
      an object tht nobody holds and other thread is doing kobject_put() on
      the same kobject:
    
        THREAD A (calls kset_find_obj())     THREAD B (calls kobject_put())
        splin_lock()
                                             atomic_dec_return(kobj->kref), counter gets zero here
                                             ... starts kobject cleanup ....
                                             spin_lock() // WAIT thread A in kobj_kset_leave()
        iterate over kset->list
        atomic_inc(kobj->kref) (counter becomes 1)
        spin_unlock()
                                             spin_lock() // taken
                                             // it does not know that thread A increased counter so it
                                             remove obj from list
                                             spin_unlock()
                                             vfree(module) // frees module object with containing kobj
    
        // kobj points to freed memory area!!
        kobject_put(kobj) // OOPS!!!!
    
      The race above happens because module.c tries to use kset_find_obj()
      when somebody unloads module.  The module.c code was introduced in
      commit 6494a93d55fa"
    
    Anatol supplied a patch specific for module.c that worked around the
    problem by simply not using kset_find_obj() at all, but rather than make
    a local band-aid, this just fixes kset_find_obj() to be thread-safe
    using the proper model of refusing the get a new reference if the
    refcount has already dropped to zero.
    
    See examples of this proper refcount handling not only in the kref
    documentation, but in various other equivalent uses of this pattern by
    grepping for atomic_inc_not_zero().
    
    [ Side note: the module race does indicate that module loading and
      unloading is not properly serialized wrt sysfs information using the
      module mutex.  That may require further thought, but this is the
      correct fix at the kobject layer regardless. ]
    
    Reported-analyzed-and-tested-by: Anatol Pomozov <anatol.pomozov@gmail.com>
    Cc: 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 a7d507200f9a0de5b0d516cd67d088fa399ed54a
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Sat Sep 8 12:57:30 2012 -0700

    mtdchar: fix offset overflow detection
    
    commit 9c603e53d380459fb62fec7cd085acb0b74ac18f upstream.
    
    Sasha Levin has been running trinity in a KVM tools guest, and was able
    to trigger the BUG_ON() at arch/x86/mm/pat.c:279 (verifying the range of
    the memory type).  The call trace showed that it was mtdchar_mmap() that
    created an invalid remap_pfn_range().
    
    The problem is that mtdchar_mmap() does various really odd and subtle
    things with the vma page offset etc, and uses the wrong types (and the
    wrong overflow) detection for it.
    
    For example, the page offset may well be 32-bit on a 32-bit
    architecture, but after shifting it up by PAGE_SHIFT, we need to use a
    potentially 64-bit resource_size_t to correctly hold the full value.
    
    Also, we need to check that the vma length plus offset doesn't overflow
    before we check that it is smaller than the length of the mtdmap region.
    
    This fixes things up and tries to make the code a bit easier to read.
    
    Reported-and-tested-by: Sasha Levin <levinsasha928@gmail.com>
    Acked-by: Suresh Siddha <suresh.b.siddha@intel.com>
    Acked-by: Artem Bityutskiy <dedekind1@gmail.com>
    Cc: David Woodhouse <dwmw2@infradead.org>
    Cc: linux-mtd@lists.infradead.org
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Ben Hutchings <ben@decadent.org.uk>
    Cc: Brad Spengler <spender@grsecurity.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7ad0908564a3554f9b13258a7927411af62bf3bc
Author: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Date:   Sat Mar 23 09:36:36 2013 -0400

    x86, mm: Patch out arch_flush_lazy_mmu_mode() when running on bare metal
    
    commit 511ba86e1d386f671084b5d0e6f110bb30b8eeb2 upstream.
    
    Invoking arch_flush_lazy_mmu_mode() results in calls to
    preempt_enable()/disable() which may have performance impact.
    
    Since lazy MMU is not used on bare metal we can patch away
    arch_flush_lazy_mmu_mode() so that it is never called in such
    environment.
    
    [ hpa: the previous patch "Fix vmalloc_fault oops during lazy MMU
      updates" may cause a minor performance regression on
      bare metal.  This patch resolves that performance regression.  It is
      somewhat unclear to me if this is a good -stable candidate. ]
    
    Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
    Link: http://lkml.kernel.org/r/1364045796-10720-2-git-send-email-konrad.wilk@oracle.com
    Tested-by: Josh Boyer <jwboyer@redhat.com>
    Tested-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
    Acked-by: Borislav Petkov <bp@suse.de>
    Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
    Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e082a177477ef0221076a201236a20c8f51c0090
Author: Samu Kallio <samu.kallio@aberdeencloud.com>
Date:   Sat Mar 23 09:36:35 2013 -0400

    x86, mm, paravirt: Fix vmalloc_fault oops during lazy MMU updates
    
    commit 1160c2779b826c6f5c08e5cc542de58fd1f667d5 upstream.
    
    In paravirtualized x86_64 kernels, vmalloc_fault may cause an oops
    when lazy MMU updates are enabled, because set_pgd effects are being
    deferred.
    
    One instance of this problem is during process mm cleanup with memory
    cgroups enabled. The chain of events is as follows:
    
    - zap_pte_range enables lazy MMU updates
    - zap_pte_range eventually calls mem_cgroup_charge_statistics,
      which accesses the vmalloc'd mem_cgroup per-cpu stat area
    - vmalloc_fault is triggered which tries to sync the corresponding
      PGD entry with set_pgd, but the update is deferred
    - vmalloc_fault oopses due to a mismatch in the PUD entries
    
    The OOPs usually looks as so:
    
    ------------[ cut here ]------------
    kernel BUG at arch/x86/mm/fault.c:396!
    invalid opcode: 0000 [#1] SMP
    .. snip ..
    CPU 1
    Pid: 10866, comm: httpd Not tainted 3.6.10-4.fc18.x86_64 #1
    RIP: e030:[<ffffffff816271bf>]  [<ffffffff816271bf>] vmalloc_fault+0x11f/0x208
    .. snip ..
    Call Trace:
     [<ffffffff81627759>] do_page_fault+0x399/0x4b0
     [<ffffffff81004f4c>] ? xen_mc_extend_args+0xec/0x110
     [<ffffffff81624065>] page_fault+0x25/0x30
     [<ffffffff81184d03>] ? mem_cgroup_charge_statistics.isra.13+0x13/0x50
     [<ffffffff81186f78>] __mem_cgroup_uncharge_common+0xd8/0x350
     [<ffffffff8118aac7>] mem_cgroup_uncharge_page+0x57/0x60
     [<ffffffff8115fbc0>] page_remove_rmap+0xe0/0x150
     [<ffffffff8115311a>] ? vm_normal_page+0x1a/0x80
     [<ffffffff81153e61>] unmap_single_vma+0x531/0x870
     [<ffffffff81154962>] unmap_vmas+0x52/0xa0
     [<ffffffff81007442>] ? pte_mfn_to_pfn+0x72/0x100
     [<ffffffff8115c8f8>] exit_mmap+0x98/0x170
     [<ffffffff810050d9>] ? __raw_callee_save_xen_pmd_val+0x11/0x1e
     [<ffffffff81059ce3>] mmput+0x83/0xf0
     [<ffffffff810624c4>] exit_mm+0x104/0x130
     [<ffffffff8106264a>] do_exit+0x15a/0x8c0
     [<ffffffff810630ff>] do_group_exit+0x3f/0xa0
     [<ffffffff81063177>] sys_exit_group+0x17/0x20
     [<ffffffff8162bae9>] system_call_fastpath+0x16/0x1b
    
    Calling arch_flush_lazy_mmu_mode immediately after set_pgd makes the
    changes visible to the consistency checks.
    
    RedHat-Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=914737
    Tested-by: Josh Boyer <jwboyer@redhat.com>
    Reported-and-Tested-by: Krishna Raman <kraman@redhat.com>
    Signed-off-by: Samu Kallio <samu.kallio@aberdeencloud.com>
    Link: http://lkml.kernel.org/r/1364045796-10720-1-git-send-email-konrad.wilk@oracle.com
    Tested-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
    Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
    Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fdd9ce008f3de39fa7fcd17717f1d7a0895269ea
Author: Thomas Gleixner <tglx@linutronix.de>
Date:   Sat Apr 6 10:10:27 2013 +0200

    sched_clock: Prevent 64bit inatomicity on 32bit systems
    
    commit a1cbcaa9ea87b87a96b9fc465951dcf36e459ca2 upstream.
    
    The sched_clock_remote() implementation has the following inatomicity
    problem on 32bit systems when accessing the remote scd->clock, which
    is a 64bit value.
    
    CPU0			CPU1
    
    sched_clock_local()	sched_clock_remote(CPU0)
    ...
    			remote_clock = scd[CPU0]->clock
    			    read_low32bit(scd[CPU0]->clock)
    cmpxchg64(scd->clock,...)
    			    read_high32bit(scd[CPU0]->clock)
    
    While the update of scd->clock is using an atomic64 mechanism, the
    readout on the remote cpu is not, which can cause completely bogus
    readouts.
    
    It is a quite rare problem, because it requires the update to hit the
    narrow race window between the low/high readout and the update must go
    across the 32bit boundary.
    
    The resulting misbehaviour is, that CPU1 will see the sched_clock on
    CPU1 ~4 seconds ahead of it's own and update CPU1s sched_clock value
    to this bogus timestamp. This stays that way due to the clamping
    implementation for about 4 seconds until the synchronization with
    CLOCK_MONOTONIC undoes the problem.
    
    The issue is hard to observe, because it might only result in a less
    accurate SCHED_OTHER timeslicing behaviour. To create observable
    damage on realtime scheduling classes, it is necessary that the bogus
    update of CPU1 sched_clock happens in the context of an realtime
    thread, which then gets charged 4 seconds of RT runtime, which results
    in the RT throttler mechanism to trigger and prevent scheduling of RT
    tasks for a little less than 4 seconds. So this is quite unlikely as
    well.
    
    The issue was quite hard to decode as the reproduction time is between
    2 days and 3 weeks and intrusive tracing makes it less likely, but the
    following trace recorded with trace_clock=global, which uses
    sched_clock_local(), gave the final hint:
    
      <idle>-0   0d..30 400269.477150: hrtimer_cancel: hrtimer=0xf7061e80
      <idle>-0   0d..30 400269.477151: hrtimer_start:  hrtimer=0xf7061e80 ...
    irq/20-S-587 1d..32 400273.772118: sched_wakeup:   comm= ... target_cpu=0
      <idle>-0   0dN.30 400273.772118: hrtimer_cancel: hrtimer=0xf7061e80
    
    What happens is that CPU0 goes idle and invokes
    sched_clock_idle_sleep_event() which invokes sched_clock_local() and
    CPU1 runs a remote wakeup for CPU0 at the same time, which invokes
    sched_remote_clock(). The time jump gets propagated to CPU0 via
    sched_remote_clock() and stays stale on both cores for ~4 seconds.
    
    There are only two other possibilities, which could cause a stale
    sched clock:
    
    1) ktime_get() which reads out CLOCK_MONOTONIC returns a sporadic
       wrong value.
    
    2) sched_clock() which reads the TSC returns a sporadic wrong value.
    
    #1 can be excluded because sched_clock would continue to increase for
       one jiffy and then go stale.
    
    #2 can be excluded because it would not make the clock jump
       forward. It would just result in a stale sched_clock for one jiffy.
    
    After quite some brain twisting and finding the same pattern on other
    traces, sched_clock_remote() remained the only place which could cause
    such a problem and as explained above it's indeed racy on 32bit
    systems.
    
    So while on 64bit systems the readout is atomic, we need to verify the
    remote readout on 32bit machines. We need to protect the local->clock
    readout in sched_clock_remote() on 32bit as well because an NMI could
    hit between the low and the high readout, call sched_clock_local() and
    modify local->clock.
    
    Thanks to Siegfried Wulsch for bearing with my debug requests and
    going through the tedious tasks of running a bunch of reproducer
    systems to generate the debug information which let me decode the
    issue.
    
    Reported-by: Siegfried Wulsch <Siegfried.Wulsch@rovema.de>
    Acked-by: Peter Zijlstra <peterz@infradead.org>
    Cc: Steven Rostedt <rostedt@goodmis.org>
    Link: http://lkml.kernel.org/r/alpine.LFD.2.02.1304051544160.21884@ionos
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit bff6627568427d14375d84426f491646fdf71a1f
Author: Dave Airlie <airlied@gmail.com>
Date:   Fri Apr 12 13:25:20 2013 +1000

    udl: handle EDID failure properly.
    
    commit 1baee58638fc58248625255f5c5fcdb987f11b1f upstream.
    
    Don't oops seems proper.
    
    Signed-off-by: Dave Airlie <airlied@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e3a55052f4773105dbd23f72dec4aeac82dea871
Author: Thomas Hellstrom <thellstrom@vmware.com>
Date:   Tue Nov 6 11:31:49 2012 +0000

    kref: Implement kref_get_unless_zero v3
    
    commit 4b20db3de8dab005b07c74161cb041db8c5ff3a7 upstream.
    
    This function is intended to simplify locking around refcounting for
    objects that can be looked up from a lookup structure, and which are
    removed from that lookup structure in the object destructor.
    Operations on such objects require at least a read lock around
    lookup + kref_get, and a write lock around kref_put + remove from lookup
    structure. Furthermore, RCU implementations become extremely tricky.
    With a lookup followed by a kref_get_unless_zero *with return value check*
    locking in the kref_put path can be deferred to the actual removal from
    the lookup structure and RCU lookups become trivial.
    
    v2: Formatting fixes.
    v3: Invert the return value.
    
    Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
    Signed-off-by: Dave Airlie <airlied@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7077c66b3ab3a1d336648cf88f54df43709ebac3
Author: Suleiman Souhlal <suleiman@google.com>
Date:   Sat Apr 13 16:03:06 2013 -0700

    vfs: Revert spurious fix to spinning prevention in prune_icache_sb
    
    commit 5b55d708335a9e3e4f61f2dadf7511502205ccd1 upstream.
    
    Revert commit 62a3ddef6181 ("vfs: fix spinning prevention in prune_icache_sb").
    
    This commit doesn't look right: since we are looking at the tail of the
    list (sb->s_inode_lru.prev) if we want to skip an inode, we should put
    it back at the head of the list instead of the tail, otherwise we will
    keep spinning on it.
    
    Discovered when investigating why prune_icache_sb came top in perf
    reports of a swapping load.
    
    Signed-off-by: Suleiman Souhlal <suleiman@google.com>
    Signed-off-by: Hugh Dickins <hughd@google.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit eced4ec1b69c8cc5428ef29b947376bc6d57c8ce
Author: Nicholas Bellinger <nab@linux-iscsi.org>
Date:   Wed Apr 10 15:00:27 2013 -0700

    target: Fix incorrect fallthrough of ALUA Standby/Offline/Transition CDBs
    
    commit 30f359a6f9da65a66de8cadf959f0f4a0d498bba upstream.
    
    This patch fixes a bug where a handful of informational / control CDBs
    that should be allowed during ALUA access state Standby/Offline/Transition
    where incorrectly returning CHECK_CONDITION + ASCQ_04H_ALUA_TG_PT_*.
    
    This includes INQUIRY + REPORT_LUNS, which would end up preventing LUN
    registration when LUN scanning occured during these ALUA access states.
    
    Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
    Cc: Hannes Reinecke <hare@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e0b4cef3446f77889a3699309a9aad5f70d9a939
Author: Sachin Prabhu <sprabhu@redhat.com>
Date:   Tue Apr 9 18:17:41 2013 +0100

    cifs: Allow passwords which begin with a delimitor
    
    commit c369c9a4a7c82d33329d869cbaf93304cc7a0c40 upstream.
    
    Fixes a regression in cifs_parse_mount_options where a password
    which begins with a delimitor is parsed incorrectly as being a blank
    password.
    
    Signed-off-by: Sachin Prabhu <sprabhu@redhat.com>
    Acked-by: Jeff Layton <jlayton@redhat.com>
    Signed-off-by: Steve French <sfrench@us.ibm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b7dba0e4be51d0924af476456d2cb0f903e8aa77
Author: Lukasz Dorau <lukasz.dorau@intel.com>
Date:   Wed Apr 3 10:27:17 2013 +0200

    SCSI: libsas: fix handling vacant phy in sas_set_ex_phy()
    
    commit d4a2618fa77b5e58ec15342972bd3505a1c3f551 upstream.
    
    If a result of the SMP discover function is PHY VACANT,
    the content of discover response structure (dr) is not valid.
    It sometimes happens that dr->attached_sas_addr can contain
    even SAS address of other phy. In such case an invalid phy
    is created, what causes NULL pointer dereference during
    destruction of expander's phys.
    
    So if a result of SMP function is PHY VACANT, the content of discover
    response structure (dr) must not be copied to phy structure.
    
    This patch fixes the following bug:
    
    BUG: unable to handle kernel NULL pointer dereference at 0000000000000030
    IP: [<ffffffff811c9002>] sysfs_find_dirent+0x12/0x90
    Call Trace:
      [<ffffffff811c95f5>] sysfs_get_dirent+0x35/0x80
      [<ffffffff811cb55e>] sysfs_unmerge_group+0x1e/0xb0
      [<ffffffff813329f4>] dpm_sysfs_remove+0x24/0x90
      [<ffffffff8132b0f4>] device_del+0x44/0x1d0
      [<ffffffffa016fc59>] sas_rphy_delete+0x9/0x20 [scsi_transport_sas]
      [<ffffffffa01a16f6>] sas_destruct_devices+0xe6/0x110 [libsas]
      [<ffffffff8107ac7c>] process_one_work+0x16c/0x350
      [<ffffffff8107d84a>] worker_thread+0x17a/0x410
      [<ffffffff81081b76>] kthread+0x96/0xa0
      [<ffffffff81464944>] kernel_thread_helper+0x4/0x10
    
    Signed-off-by: Lukasz Dorau <lukasz.dorau@intel.com>
    Signed-off-by: Pawel Baldysiak <pawel.baldysiak@intel.com>
    Reviewed-by: Maciej Patelczyk <maciej.patelczyk@intel.com>
    Signed-off-by: James Bottomley <JBottomley@Parallels.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 706d153865d8efb9164faf220a66f224969fed84
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Fri Aug 24 09:12:22 2012 +0100

    drm/i915: Use the correct size of the GTT for placing the per-process entries
    
    commit 9a0f938bde74bf9e50bd75c8de9e38c1787398cd upstream.
    
    The current layout is to place the per-process tables at the end of the
    GTT. However, this is currently using a hardcoded maximum size for the GTT
    and not taking in account limitations imposed by the BIOS. Use the value
    for the total number of entries allocated in the table as provided by
    the configuration registers.
    
    Reported-by: Matthew Garrett <mjg@redhat.com>
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
    Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
    Cc: Ben Widawsky <ben@bwidawsk.net>
    Cc: Matthew Garret <mjg@redhat.com>
    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
    Cc: Jonathan Nieder <jrnieder@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e3573b2133637edf3a6cb39241e9270affa535c7
Author: Huacai Chen <chenhc@lemote.com>
Date:   Sun Apr 7 02:14:14 2013 +0000

    PM / reboot: call syscore_shutdown() after disable_nonboot_cpus()
    
    commit 6f389a8f1dd22a24f3d9afc2812b30d639e94625 upstream.
    
    As commit 40dc166c (PM / Core: Introduce struct syscore_ops for core
    subsystems PM) say, syscore_ops operations should be carried with one
    CPU on-line and interrupts disabled. However, after commit f96972f2d
    (kernel/sys.c: call disable_nonboot_cpus() in kernel_restart()),
    syscore_shutdown() is called before disable_nonboot_cpus(), so break
    the rules. We have a MIPS machine with a 8259A PIC, and there is an
    external timer (HPET) linked at 8259A. Since 8259A has been shutdown
    too early (by syscore_shutdown()), disable_nonboot_cpus() runs without
    timer interrupt, so it hangs and reboot fails. This patch call
    syscore_shutdown() a little later (after disable_nonboot_cpus()) to
    avoid reboot failure, this is the same way as poweroff does.
    
    For consistency, add disable_nonboot_cpus() to kernel_halt().
    
    Signed-off-by: Huacai Chen <chenhc@lemote.com>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e264d3cf890eb1ead5200731b9e3dbd1d1b71fa8
Author: Namhyung Kim <namhyung.kim@lge.com>
Date:   Mon Apr 1 21:46:23 2013 +0900

    tracing: Fix double free when function profile init failed
    
    commit 83e03b3fe4daffdebbb42151d5410d730ae50bd1 upstream.
    
    On the failure path, stat->start and stat->pages will refer same page.
    So it'll attempt to free the same page again and get kernel panic.
    
    Link: http://lkml.kernel.org/r/1364820385-32027-1-git-send-email-namhyung@kernel.org
    
    Signed-off-by: Namhyung Kim <namhyung@kernel.org>
    Cc: Frederic Weisbecker <fweisbec@gmail.com>
    Cc: Namhyung Kim <namhyung.kim@lge.com>
    Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b43105dee8480ca5784de5c858d1cccee74ebfb1
Author: Alban Bedel <alban.bedel@avionic-design.de>
Date:   Tue Apr 9 17:13:59 2013 +0200

    ASoC: wm8903: Fix the bypass to HP/LINEOUT when no DAC or ADC is running
    
    commit f1ca493b0b5e8f42d3b2dc8877860db2983f47b6 upstream.
    
    The Charge Pump needs the DSP clock to work properly, without it the
    bypass to HP/LINEOUT is not working properly. This requirement is not
    mentioned in the datasheet but has been confirmed by Mark Brown from
    Wolfson.
    
    Signed-off-by: Alban Bedel <alban.bedel@avionic-design.de>
    Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit dd541ae5fb912fcc958f9eaf96a90df4e324f440
Author: Eldad Zack <eldad@fogrefinery.com>
Date:   Fri Apr 5 20:49:46 2013 +0200

    ALSA: usb-audio: fix endianness bug in snd_nativeinstruments_*
    
    commit 889d66848b12d891248b03abcb2a42047f8e172a upstream.
    
    The usb_control_msg() function expects __u16 types and performs
    the endianness conversions by itself.
    However, in three places, a conversion is performed before it is
    handed over to usb_control_msg(), which leads to a double conversion
    (= no conversion):
    * snd_usb_nativeinstruments_boot_quirk()
    * snd_nativeinstruments_control_get()
    * snd_nativeinstruments_control_put()
    
    Caught by sparse:
    
    sound/usb/mixer_quirks.c:512:38: warning: incorrect type in argument 6 (different base types)
    sound/usb/mixer_quirks.c:512:38:    expected unsigned short [unsigned] [usertype] index
    sound/usb/mixer_quirks.c:512:38:    got restricted __le16 [usertype] <noident>
    sound/usb/mixer_quirks.c:543:35: warning: incorrect type in argument 5 (different base types)
    sound/usb/mixer_quirks.c:543:35:    expected unsigned short [unsigned] [usertype] value
    sound/usb/mixer_quirks.c:543:35:    got restricted __le16 [usertype] <noident>
    sound/usb/mixer_quirks.c:543:56: warning: incorrect type in argument 6 (different base types)
    sound/usb/mixer_quirks.c:543:56:    expected unsigned short [unsigned] [usertype] index
    sound/usb/mixer_quirks.c:543:56:    got restricted __le16 [usertype] <noident>
    sound/usb/quirks.c:502:35: warning: incorrect type in argument 5 (different base types)
    sound/usb/quirks.c:502:35:    expected unsigned short [unsigned] [usertype] value
    sound/usb/quirks.c:502:35:    got restricted __le16 [usertype] <noident>
    
    Signed-off-by: Eldad Zack <eldad@fogrefinery.com>
    Acked-by: Daniel Mack <zonque@gmail.com>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>