commit 8299a17a0544a45529a954cf27f9bf40e8890ac6
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Thu Apr 25 12:52:16 2013 -0700

    Linux 3.8.9

commit 65dcded2f1e5582e8f0fe6ef315b2274270a6302
Author: Ralf Baechle <ralf@linux-mips.org>
Date:   Mon Apr 22 17:57:54 2013 +0200

    Revert "MIPS: page.h: Provide more readable definition for PAGE_MASK."
    
    commit 3b5e50edaf500f392f4a372296afc0b99ffa7e70 upstream.
    
    This reverts commit c17a6554782ad531f4713b33fd6339ba67ef6391.
    
    Manuel Lauss writes:
    
    lmo commit c17a6554 (MIPS: page.h: Provide more readable definition for
    PAGE_MASK) apparently breaks ioremap of 36-bit addresses on my Alchemy
    systems (PCI and PCMCIA) The reason is that in arch/mips/mm/ioremap.c
    line 157  (phys_addr &= PAGE_MASK) bits 32-35 are cut off.  Seems the
    new PAGE_MASK is explicitly 32bit, or one could make it signed instead
    of unsigned long.
    
    From: Ralf Baechle <ralf@linux-mips.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7a5324f9edf0e920c99ed90872e1baeaf04acbc1
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Wed Apr 17 08:46:19 2013 -0700

    s390: move dummy io_remap_pfn_range() to asm/pgtable.h
    
    commit 4f2e29031e6c67802e7370292dd050fd62f337ee upstream.
    
    Commit b4cbb197c7e7 ("vm: add vm_iomap_memory() helper function") added
    a helper function wrapper around io_remap_pfn_range(), and every other
    architecture defined it in <asm/pgtable.h>.
    
    The s390 choice of <asm/io.h> may make sense, but is not very convenient
    for this case, and gratuitous differences like that cause unexpected errors like this:
    
       mm/memory.c: In function 'vm_iomap_memory':
       mm/memory.c:2439:2: error: implicit declaration of function 'io_remap_pfn_range' [-Werror=implicit-function-declaration]
    
    Glory be the kbuild test robot who noticed this, bisected it, and
    reported it to the guilty parties (ie me).
    
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
    Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c5627099f70b1187b84fa711f6b5daf32f16b10e
Author: Josef Bacik <jbacik@fusionio.com>
Date:   Fri Apr 5 20:50:09 2013 +0000

    Btrfs: make sure nbytes are right after log replay
    
    commit 4bc4bee4595662d8bff92180d5c32e3313a704b0 upstream.
    
    While trying to track down a tree log replay bug I noticed that fsck was always
    complaining about nbytes not being right for our fsynced file.  That is because
    the new fsync stuff doesn't wait for ordered extents to complete, so the inodes
    nbytes are not necessarily updated properly when we log it.  So to fix this we
    need to set nbytes to whatever it is on the inode that is on disk, so when we
    replay the extents we can just add the bytes that are being added as we replay
    the extent.  This makes it work for the case that we have the wrong nbytes or
    the case that we logged everything and nbytes is actually correct.  With this
    I'm no longer getting nbytes errors out of btrfsck.
    
    Signed-off-by: Josef Bacik <jbacik@fusionio.com>
    Signed-off-by: Chris Mason <chris.mason@fusionio.com>
    Signed-off-by: Lingzhu Xiang <lxiang@redhat.com>
    Reviewed-by: CAI Qian <caiqian@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fdb6d5c17e8fe339de73879c18d5084ca3264e86
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Fri Apr 19 09:53:07 2013 -0700

    vm: convert mtdchar mmap to vm_iomap_memory() helper
    
    commit 8558e4a26b00225efeb085725bc319f91201b239 upstream.
    
    This is my example conversion of a few existing mmap users.  The mtdchar
    case is actually disabled right now (and stays disabled), but I did it
    because it showed up on my "git grep", and I was familiar with the code
    due to fixing an overflow problem in the code in commit 9c603e53d380
    ("mtdchar: fix offset overflow detection").
    
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 969163b21e0449ffc341a07d8cd73c8859b7e70a
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Fri Apr 19 09:46:39 2013 -0700

    vm: convert HPET mmap to vm_iomap_memory() helper
    
    commit 2323036dfec8ce3ce6e1c86a49a31b039f3300d1 upstream.
    
    This is my example conversion of a few existing mmap users.  The HPET
    case is simple, widely available, and easy to test (Clemens Ladisch sent
    a trivial test-program for it).
    
    Test-program-by: Clemens Ladisch <clemens@ladisch.de>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b3ea73c2d47633f9c1059e6832c7784c12c6aa75
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Fri Apr 19 09:57:35 2013 -0700

    vm: convert fb_mmap to vm_iomap_memory() helper
    
    commit fc9bbca8f650e5f738af8806317c0a041a48ae4a upstream.
    
    This is my example conversion of a few existing mmap users.  The
    fb_mmap() case is a good example because it is a bit more complicated
    than some: fb_mmap() mmaps one of two different memory areas depending
    on the page offset of the mmap (but happily there is never any mixing of
    the two, so the helper function still works).
    
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b88e2557725053ef3ca54ee46be4143ba38b0cd4
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Fri Apr 19 10:01:04 2013 -0700

    vm: convert snd_pcm_lib_mmap_iomem() to vm_iomap_memory() helper
    
    commit 0fe09a45c4848b5b5607b968d959fdc1821c161d upstream.
    
    This is my example conversion of a few existing mmap users.  The pcm
    mmap case is one of the more straightforward ones.
    
    Acked-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d8b1c028720bb2f3ba634c64ac2e834982b7ee7a
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Tue Apr 16 13:45:37 2013 -0700

    vm: add vm_iomap_memory() helper function
    
    commit b4cbb197c7e7a68dbad0d491242e3ca67420c13e upstream.
    
    Various drivers end up replicating the code to mmap() their memory
    buffers into user space, and our core memory remapping function may be
    very flexible but it is unnecessarily complicated for the common cases
    to use.
    
    Our internal VM uses pfn's ("page frame numbers") which simplifies
    things for the VM, and allows us to pass physical addresses around in a
    denser and more efficient format than passing a "phys_addr_t" around,
    and having to shift it up and down by the page size.  But it just means
    that drivers end up doing that shifting instead at the interface level.
    
    It also means that drivers end up mucking around with internal VM things
    like the vma details (vm_pgoff, vm_start/end) way more than they really
    need to.
    
    So this just exports a function to map a certain physical memory range
    into user space (using a phys_addr_t based interface that is much more
    natural for a driver) and hides all the complexity from the driver.
    Some drivers will still end up tweaking the vm_page_prot details for
    things like prefetching or cacheability etc, but that's actually
    relevant to the driver, rather than caring about what the page offset of
    the mapping is into the particular IO memory region.
    
    Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

commit 37ed4a3f3bb107bfb307610b9ab2b87db03df3a6
Author: Andy Lutomirski <luto@amacapital.net>
Date:   Sun Apr 14 11:44:04 2013 -0700

    userns: Changing any namespace id mappings should require privileges
    
    commit 41c21e351e79004dbb4efa4bc14a53a7e0af38c5 upstream.
    
    Changing uid/gid/projid mappings doesn't change your id within the
    namespace; it reconfigures the namespace.  Unprivileged programs should
    *not* be able to write these files.  (We're also checking the privileges
    on the wrong task.)
    
    Given the write-once nature of these files and the other security
    checks, this is likely impossible to usefully exploit.
    
    Signed-off-by: Andy Lutomirski <luto@amacapital.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit be4c1b46075d42cbd82bc0d1e833dc4de052ae85
Author: Andy Lutomirski <luto@amacapital.net>
Date:   Sun Apr 14 16:28:19 2013 -0700

    userns: Check uid_map's opener's fsuid, not the current fsuid
    
    commit e3211c120a85b792978bcb4be7b2886df18d27f0 upstream.
    
    Signed-off-by: Andy Lutomirski <luto@amacapital.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d2b12161ea5208d87dae24bcc5f3fed9da79262e
Author: Eric W. Biederman <ebiederm@xmission.com>
Date:   Sun Apr 14 13:47:02 2013 -0700

    userns: Don't let unprivileged users trick privileged users into setting the id_map
    
    commit 6708075f104c3c9b04b23336bb0366ca30c3931b upstream.
    
    When we require privilege for setting /proc/<pid>/uid_map or
    /proc/<pid>/gid_map no longer allow an unprivileged user to
    open the file and pass it to a privileged program to write
    to the file.
    
    Instead when privilege is required require both the opener and the
    writer to have the necessary capabilities.
    
    I have tested this code and verified that setting /proc/<pid>/uid_map
    fails when an unprivileged user opens the file and a privielged user
    attempts to set the mapping, that unprivileged users can still map
    their own id, and that a privileged users can still setup an arbitrary
    mapping.
    
    Reported-by: Andy Lutomirski <luto@amacapital.net>
    Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
    Signed-off-by: Andy Lutomirski <luto@amacapital.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 73f25feefdcc89cce395b86e135e0936cbd2c7ae
Author: Stephane Eranian <eranian@google.com>
Date:   Tue Apr 16 13:51:43 2013 +0200

    perf/x86: Fix offcore_rsp valid mask for SNB/IVB
    
    commit f1923820c447e986a9da0fc6bf60c1dccdf0408e upstream.
    
    The valid mask for both offcore_response_0 and
    offcore_response_1 was wrong for SNB/SNB-EP,
    IVB/IVB-EP. It was possible to write to
    reserved bit and cause a GP fault crashing
    the kernel.
    
    This patch fixes the problem by correctly marking the
    reserved bits in the valid mask for all the processors
    mentioned above.
    
    A distinction between desktop and server parts is introduced
    because bits 24-30 are only available on the server parts.
    
    This version of the  patch is just a rebase to perf/urgent tree
    and should apply to older kernels as well.
    
    Signed-off-by: Stephane Eranian <eranian@google.com>
    Cc: peterz@infradead.org
    Cc: jolsa@redhat.com
    Cc: ak@linux.intel.com
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ff91fd5bc105f29a34755a6dd6d547c877b7d027
Author: Tommi Rantala <tt.rantala@gmail.com>
Date:   Sat Apr 13 22:49:14 2013 +0300

    perf: Treat attr.config as u64 in perf_swevent_init()
    
    commit 8176cced706b5e5d15887584150764894e94e02f upstream.
    
    Trinity discovered that we fail to check all 64 bits of
    attr.config passed by user space, resulting to out-of-bounds
    access of the perf_swevent_enabled array in
    sw_perf_event_destroy().
    
    Introduced in commit b0a873ebb ("perf: Register PMU
    implementations").
    
    Signed-off-by: Tommi Rantala <tt.rantala@gmail.com>
    Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
    Cc: davej@redhat.com
    Cc: Paul Mackerras <paulus@samba.org>
    Cc: Arnaldo Carvalho de Melo <acme@ghostprotocols.net>
    Link: http://lkml.kernel.org/r/1365882554-30259-1-git-send-email-tt.rantala@gmail.com
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2822050e7d8bb82bced08b21c711ff79a4636f3e
Author: Mathias Krause <minipli@googlemail.com>
Date:   Sun Apr 7 14:05:39 2013 +0200

    crypto: algif - suppress sending source address information in recvmsg
    
    commit 72a763d805a48ac8c0bf48fdb510e84c12de51fe upstream.
    
    The current code does not set the msg_namelen member to 0 and therefore
    makes net/socket.c leak the local sockaddr_storage variable to userland
    -- 128 bytes of kernel stack memory. Fix that.
    
    Signed-off-by: Mathias Krause <minipli@googlemail.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 401716d9514ff77c86d93805f3a45f5e6fdd8f10
Author: Rafał Miłecki <zajec5@gmail.com>
Date:   Tue Apr 2 15:57:26 2013 +0200

    ssb: implement spurious tone avoidance
    
    commit 46fc4c909339f5a84d1679045297d9d2fb596987 upstream.
    
    And make use of it in b43. This fixes a regression introduced with
    49d55cef5b1925a5c1efb6aaddaa40fc7c693335
    b43: N-PHY: implement spurious tone avoidance
    This commit made BCM4322 use only MCS 0 on channel 13, which of course
    resulted in performance drop (down to 0.7Mb/s).
    
    Reported-by: Stefan Brüns <stefan.bruens@rwth-aachen.de>
    Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7ac7dd50d62c02b055f4e7f53b39040f863ff48a
Author: Johannes Berg <johannes.berg@intel.com>
Date:   Wed Apr 10 21:38:36 2013 +0200

    mac80211: fix cfg80211 interaction on auth/assoc request
    
    commit 7b119dc06d871405fc7c3e9a73a6c987409ba639 upstream.
    
    If authentication (or association with FT) is requested by
    userspace, mac80211 currently doesn't tell cfg80211 that it
    disconnected from the AP. That leaves inconsistent state:
    cfg80211 thinks it's connected while mac80211 thinks it's
    not. Typically this won't last long, as soon as mac80211
    reports the new association to cfg80211 the old one goes
    away. If, however, the new authentication or association
    doesn't succeed, then cfg80211 will forever think the old
    one still exists and will refuse attempts to authenticate
    or associate with the AP it thinks it's connected to.
    
    Anders reported that this leads to it taking a very long
    time to reconnect to a network, or never even succeeding.
    I tested this with an AP hacked to never respond to auth
    frames, and one that works, and with just those two the
    system never recovers because one won't work and cfg80211
    thinks it's connected to the other so refuses connections
    to it.
    
    To fix this, simply make mac80211 tell cfg80211 when it is
    no longer connected to the old AP, while authenticating or
    associating to a new one.
    
    Reported-by: Anders Kaseorg <andersk@mit.edu>
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 42a2d01229b66c76d96fc2e5eb96e8d9c3caaac0
Author: Felix Fietkau <nbd@openwrt.org>
Date:   Wed Apr 10 15:26:06 2013 +0200

    ath9k_hw: change AR9580 initvals to fix a stability issue
    
    commit f09a878511997c25a76bf111a32f6b8345a701a5 upstream.
    
    The hardware parsing of Control Wrapper Frames needs to be disabled, as
    it has been causing spurious decryption error reports. The initvals for
    other chips have been updated to disable it, but AR9580 was left out for
    some reason.
    
    Signed-off-by: Felix Fietkau <nbd@openwrt.org>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8387f3cbc4710e2e2df013ba1b0e7ba09499c016
Author: Felix Fietkau <nbd@openwrt.org>
Date:   Sun Apr 7 21:10:48 2013 +0200

    ath9k_htc: accept 1.x firmware newer than 1.3
    
    commit 319e7bd96aca64a478f3aad40711c928405b8b77 upstream.
    
    Since the firmware has been open sourced, the minor version has been
    bumped to 1.4 and the API/ABI will stay compatible across further 1.x
    releases.
    
    Signed-off-by: Felix Fietkau <nbd@openwrt.org>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e64371e1f2a968e70e950b2d9742718eb5699e35
Author: Will Deacon <will.deacon@arm.com>
Date:   Fri Apr 12 19:04:19 2013 +0100

    ARM: 7698/1: perf: fix group validation when using enable_on_exec
    
    commit cb2d8b342aa084d1f3ac29966245dec9163677fb upstream.
    
    Events may be created with attr->disabled == 1 and attr->enable_on_exec
    == 1, which confuses the group validation code because events with the
    PERF_EVENT_STATE_OFF are not considered candidates for scheduling, which
    may lead to failure at group scheduling time.
    
    This patch fixes the validation check for ARM, so that events in the
    OFF state are still considered when enable_on_exec is true.
    
    Reported-by: Sudeep KarkadaNagesha <Sudeep.KarkadaNagesha@arm.com>
    Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
    Cc: Arnaldo Carvalho de Melo <acme@ghostprotocols.net>
    Cc: Jiri Olsa <jolsa@redhat.com>
    Signed-off-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e644d5af6228ef011179bae1ba7052fd2c481a3f
Author: Illia Ragozin <illia.ragozin@grapecom.com>
Date:   Wed Apr 10 19:43:34 2013 +0100

    ARM: 7696/1: Fix kexec by setting outer_cache.inv_all for Feroceon
    
    commit cd272d1ea71583170e95dde02c76166c7f9017e6 upstream.
    
    On Feroceon the L2 cache becomes non-coherent with the CPU
    when the L1 caches are disabled. Thus the L2 needs to be invalidated
    after both L1 caches are disabled.
    
    On kexec before the starting the code for relocation the kernel,
    the L1 caches are disabled in cpu_froc_fin (cpu_v7_proc_fin for Feroceon),
    but after L2 cache is never invalidated, because inv_all is not set
    in cache-feroceon-l2.c.
    So kernel relocation and decompression may has (and usually has) errors.
    Setting the function enables L2 invalidation and fixes the issue.
    
    Signed-off-by: Illia Ragozin <illia.ragozin@grapecom.com>
    Acked-by: Jason Cooper <jason@lakedaemon.net>
    Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit dd135b0d8977ef119c7908c0153c3e94d8110e58
Author: libin <huawei.libin@huawei.com>
Date:   Mon Apr 8 14:39:12 2013 +0800

    sched/debug: Fix sd->*_idx limit range avoiding overflow
    
    commit fd9b86d37a600488dbd80fe60cca46b822bff1cd upstream.
    
    Commit 201c373e8e ("sched/debug: Limit sd->*_idx range on
    sysctl") was an incomplete bug fix.
    
    This patch fixes sd->*_idx limit range to [0 ~ CPU_LOAD_IDX_MAX-1]
    avoiding array overflow caused by setting sd->*_idx to CPU_LOAD_IDX_MAX
    on sysctl.
    
    Signed-off-by: Libin <huawei.libin@huawei.com>
    Cc: <jiang.liu@huawei.com>
    Cc: <guohanjun@huawei.com>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Link: http://lkml.kernel.org/r/51626610.2040607@huawei.com
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Jonghwan Choi <jhbird.choi@samsung.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4f795d18597696cc0da217c5177ddd8e2fbbb932
Author: Tejun Heo <tj@kernel.org>
Date:   Mon Mar 18 12:22:34 2013 -0700

    sched: Convert BUG_ON()s in try_to_wake_up_local() to WARN_ON_ONCE()s
    
    commit 383efcd00053ec40023010ce5034bd702e7ab373 upstream.
    
    try_to_wake_up_local() should only be invoked to wake up another
    task in the same runqueue and BUG_ON()s are used to enforce the
    rule. Missing try_to_wake_up_local() can stall workqueue
    execution but such stalls are likely to be finite either by
    another work item being queued or the one blocked getting
    unblocked.  There's no reason to trigger BUG while holding rq
    lock crashing the whole system.
    
    Convert BUG_ON()s in try_to_wake_up_local() to WARN_ON_ONCE()s.
    
    Signed-off-by: Tejun Heo <tj@kernel.org>
    Acked-by: Steven Rostedt <rostedt@goodmis.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Link: http://lkml.kernel.org/r/20130318192234.GD3042@htj.dyndns.org
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 641a15a68775a9e477c4c0738f9844d36ac3b59e
Author: Matt Carlson <mcarlson@broadcom.com>
Date:   Thu Feb 14 14:27:51 2013 +0000

    tg3: Add 57766 device support.
    
    commit d3f677afb8076d09d090ff0a5d1229c9dd9f136e upstream.
    
    The patch also adds a couple of fixes
    
     - For the 57766 and non Ax versions of 57765, bootcode needs to setup
       the PCIE Fast Training Sequence (FTS) value to prevent transmit hangs.
       Unfortunately, it does not have enough room in the selfboot case (i.e.
       devices with no NVRAM).  The driver needs to implement this.
    
     - For performance reasons, the 2k DMA engine mode on the 57766 should
       be enabled and dma size limited to 2k for standard sized packets.
    
    Signed-off-by: Nithin Nayak Sujir <nsujir@broadcom.com>
    Signed-off-by: Michael Chan <mchan@broadcom.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Joseph Salisbury <joseph.salisbury@canonical.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0234185d8e7157d2f5eb884cdc1b3a00e95ba759
Author: Markus Pargmann <mpa@pengutronix.de>
Date:   Fri Mar 29 16:20:09 2013 +0100

    ARM: clk-imx35: Bugfix iomux clock
    
    commit cab1e0a36c9dd0b0671fb84197ed294513f5adc1 upstream.
    
    This patch enables iomuxc_gate clock. It is necessary to be able to
    reconfigure iomux pads. Without this clock enabled, the
    clk_disable_unused function will disable this clock and the iomux pads
    are not configurable anymore. This happens at every boot. After a reboot
    (watchdog system reset) the clock is not enabled again, so all iomux pad
    reconfigurations in boot code are without effect.
    
    The iomux pads should be always configurable, so this patch always
    enables it.
    
    Signed-off-by: Markus Pargmann <mpa@pengutronix.de>
    Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
    Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
    Cc: Lingzhu Xiang <lxiang@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1ed8d46cfb1af390003553d504d6ad38be31a443
Author: Sascha Hauer <s.hauer@pengutronix.de>
Date:   Tue Feb 26 10:55:18 2013 +0100

    ARM: i.MX35: enable MAX clock
    
    commit 5dc2eb7da1e387e31ce54f54af580c6a6f512ca6 upstream.
    
    The i.MX35 has two bits per clock gate which are decoded as follows:
          0b00 -> clock off
          0b01 -> clock is on in run mode, off in wait/doze
          0b10 -> clock is on in run/wait mode, off in doze
          0b11 -> clock is always on
    
    The reset value for the MAX clock is 0b10.
    
    The MAX clock is needed by the SoC, yet unused in the Kernel, so the
    common clock framework will disable it during late init time. It will
    only disable clocks though which it detects as being turned on. This
    detection is made depending on the lower bit of the gate. If the reset
    value has been altered by the bootloader to 0b11 the clock framework
    will detect the clock as turned on, yet unused, hence it will turn it
    off and the system locks up.
    
    This patch turns the MAX clock on unconditionally making the Kernel
    independent of the bootloader.
    
    Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
    Cc: Lingzhu Xiang <lxiang@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit cdbaff4e7c7d4730d37aa1da8c00b37bbbadbf23
Author: Andrew Honig <ahonig@google.com>
Date:   Fri Mar 29 09:35:21 2013 -0700

    KVM: Allow cross page reads and writes from cached translations.
    
    commit 8f964525a121f2ff2df948dac908dcc65be21b5b upstream.
    
    This patch adds support for kvm_gfn_to_hva_cache_init functions for
    reads and writes that will cross a page.  If the range falls within
    the same memslot, then this will be a fast operation.  If the range
    is split between two memslots, then the slower kvm_read_guest and
    kvm_write_guest are used.
    
    Tested: Test against kvm_clock unit tests.
    
    Signed-off-by: Andrew Honig <ahonig@google.com>
    Signed-off-by: Gleb Natapov <gleb@redhat.com>
    Cc: Ben Hutchings <ben@decadent.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 24a5d26686ee4bb22fcf5d3c8b9d9227cbc0c187
Author: Andy Honig <ahonig@google.com>
Date:   Wed Feb 20 14:49:16 2013 -0800

    KVM: Fix bounds checking in ioapic indirect register reads (CVE-2013-1798)
    
    commit a2c118bfab8bc6b8bb213abfc35201e441693d55 upstream.
    
    If the guest specifies a IOAPIC_REG_SELECT with an invalid value and follows
    that with a read of the IOAPIC_REG_WINDOW KVM does not properly validate
    that request.  ioapic_read_indirect contains an
    ASSERT(redir_index < IOAPIC_NUM_PINS), but the ASSERT has no effect in
    non-debug builds.  In recent kernels this allows a guest to cause a kernel
    oops by reading invalid memory.  In older kernels (pre-3.3) this allows a
    guest to read from large ranges of host memory.
    
    Tested: tested against apic unit tests.
    
    Signed-off-by: Andrew Honig <ahonig@google.com>
    Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>
    Cc: Ben Hutchings <ben@decadent.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 17b61c3d1ca2a739c44e0c24565ce97a2086156f
Author: Andy Honig <ahonig@google.com>
Date:   Wed Feb 20 14:48:10 2013 -0800

    KVM: x86: Convert MSR_KVM_SYSTEM_TIME to use gfn_to_hva_cache functions (CVE-2013-1797)
    
    commit 0b79459b482e85cb7426aa7da683a9f2c97aeae1 upstream.
    
    There is a potential use after free issue with the handling of
    MSR_KVM_SYSTEM_TIME.  If the guest specifies a GPA in a movable or removable
    memory such as frame buffers then KVM might continue to write to that
    address even after it's removed via KVM_SET_USER_MEMORY_REGION.  KVM pins
    the page in memory so it's unlikely to cause an issue, but if the user
    space component re-purposes the memory previously used for the guest, then
    the guest will be able to corrupt that memory.
    
    Tested: Tested against kvmclock unit test
    
    Signed-off-by: Andrew Honig <ahonig@google.com>
    Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>
    Cc: Ben Hutchings <ben@decadent.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 23488565ac95f40c5d6804614f36e0a1b0d27ec9
Author: Andy Honig <ahonig@google.com>
Date:   Mon Mar 11 09:34:52 2013 -0700

    KVM: x86: fix for buffer overflow in handling of MSR_KVM_SYSTEM_TIME (CVE-2013-1796)
    
    commit c300aa64ddf57d9c5d9c898a64b36877345dd4a9 upstream.
    
    If the guest sets the GPA of the time_page so that the request to update the
    time straddles a page then KVM will write onto an incorrect page.  The
    write is done byusing kmap atomic to get a pointer to the page for the time
    structure and then performing a memcpy to that page starting at an offset
    that the guest controls.  Well behaved guests always provide a 32-byte aligned
    address, however a malicious guest could use this to corrupt host kernel
    memory.
    
    Tested: Tested against kvmclock unit test.
    
    Signed-off-by: Andrew Honig <ahonig@google.com>
    Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>
    Cc: Ben Hutchings <ben@decadent.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c402e9ee7a5313c962bf38da206ff593a53454a7
Author: Joe Lawrence <Joe.Lawrence@stratus.com>
Date:   Thu Feb 21 13:28:09 2013 +1100

    md: raid1,10: Handle REQ_WRITE_SAME flag in write bios
    
    commit c8dc9c654794a765ca61baed07f84ed8aaa7ca8c upstream.
    
    Set mddev queue's max_write_same_sectors to its chunk_sector value (before
    disk_stack_limits merges the underlying disk limits.)  With that in place,
    be sure to handle writes coming down from the block layer that have the
    REQ_WRITE_SAME flag set.  That flag needs to be copied into any newly cloned
    write bio.
    
    Signed-off-by: Joe Lawrence <joe.lawrence@stratus.com>
    Acked-by: "Martin K. Petersen" <martin.petersen@oracle.com>
    Signed-off-by: NeilBrown <neilb@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a7be4986fe82c5a8465749c4a0f3e1367d588b03
Author: Vyacheslav Dubeyko <slava@dubeyko.com>
Date:   Wed Apr 17 15:58:33 2013 -0700

    hfsplus: fix potential overflow in hfsplus_file_truncate()
    
    commit 12f267a20aecf8b84a2a9069b9011f1661c779b4 upstream.
    
    Change a u32 to loff_t hfsplus_file_truncate().
    
    Signed-off-by: Vyacheslav Dubeyko <slava@dubeyko.com>
    Cc: Christoph Hellwig <hch@infradead.org>
    Cc: Al Viro <viro@zeniv.linux.org.uk>
    Cc: Hin-Tak Leung <htl10@users.sourceforge.net>
    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 998f85133fd3067d715050826cf066efd59775f1
Author: Emese Revfy <re.emese@gmail.com>
Date:   Wed Apr 17 15:58:36 2013 -0700

    kernel/signal.c: stop info leak via the tkill and the tgkill syscalls
    
    commit b9e146d8eb3b9ecae5086d373b50fa0c1f3e7f0f upstream.
    
    This fixes a kernel memory contents leak via the tkill and tgkill syscalls
    for compat processes.
    
    This is visible in the siginfo_t->_sifields._rt.si_sigval.sival_ptr field
    when handling signals delivered from tkill.
    
    The place of the infoleak:
    
    int copy_siginfo_to_user32(compat_siginfo_t __user *to, siginfo_t *from)
    {
            ...
            put_user_ex(ptr_to_compat(from->si_ptr), &to->si_ptr);
            ...
    }
    
    Signed-off-by: Emese Revfy <re.emese@gmail.com>
    Reviewed-by: PaX Team <pageexec@freemail.hu>
    Signed-off-by: Kees Cook <keescook@chromium.org>
    Cc: Al Viro <viro@zeniv.linux.org.uk>
    Cc: Oleg Nesterov <oleg@redhat.com>
    Cc: "Eric W. Biederman" <ebiederm@xmission.com>
    Cc: Serge Hallyn <serge.hallyn@canonical.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 eb586a6aac367fe5589ae115d470c2c2de45f6fb
Author: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
Date:   Wed Apr 17 15:58:28 2013 -0700

    fs/binfmt_elf.c: fix hugetlb memory check in vma_dump_size()
    
    commit 23d9e482136e31c9d287633a6e473daa172767c4 upstream.
    
    Documentation/filesystems/proc.txt says about coredump_filter bitmask,
    
      Note bit 0-4 doesn't effect any hugetlb memory. hugetlb memory are only
      effected by bit 5-6.
    
    However current code can go into the subsequent flag checks of bit 0-4
    for vma(VM_HUGETLB). So this patch inserts 'return' and makes it work
    as written in the document.
    
    Signed-off-by: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
    Reviewed-by: Rik van Riel <riel@redhat.com>
    Acked-by: Michal Hocko <mhocko@suse.cz>
    Reviewed-by: HATAYAMA Daisuke <d.hatayama@jp.fujitsu.com>
    Acked-by: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.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>

commit bff55c65c423aad2d509e01e6703f098620b3c58
Author: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
Date:   Wed Apr 17 15:58:30 2013 -0700

    hugetlbfs: add swap entry check in follow_hugetlb_page()
    
    commit 9cc3a5bd40067b9a0fbd49199d0780463fc2140f upstream.
    
    With applying the previous patch "hugetlbfs: stop setting VM_DONTDUMP in
    initializing vma(VM_HUGETLB)" to reenable hugepage coredump, if a memory
    error happens on a hugepage and the affected processes try to access the
    error hugepage, we hit VM_BUG_ON(atomic_read(&page->_count) <= 0) in
    get_page().
    
    The reason for this bug is that coredump-related code doesn't recognise
    "hugepage hwpoison entry" with which a pmd entry is replaced when a memory
    error occurs on a hugepage.
    
    In other words, physical address information is stored in different bit
    layout between hugepage hwpoison entry and pmd entry, so
    follow_hugetlb_page() which is called in get_dump_page() returns a wrong
    page from a given address.
    
    The expected behavior is like this:
    
      absent   is_swap_pte   FOLL_DUMP   Expected behavior
      -------------------------------------------------------------------
       true     false         false       hugetlb_fault
       false    true          false       hugetlb_fault
       false    false         false       return page
       true     false         true        skip page (to avoid allocation)
       false    true          true        hugetlb_fault
       false    false         true        return page
    
    With this patch, we can call hugetlb_fault() and take proper actions (we
    wait for migration entries, fail with VM_FAULT_HWPOISON_LARGE for
    hwpoisoned entries,) and as the result we can dump all hugepages except
    for hwpoisoned ones.
    
    Signed-off-by: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
    Cc: Rik van Riel <riel@redhat.com>
    Acked-by: Michal Hocko <mhocko@suse.cz>
    Cc: HATAYAMA Daisuke <d.hatayama@jp.fujitsu.com>
    Acked-by: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.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: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 17e4c92ba62fc45697bd214592248e41db65888b
Author: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
Date:   Wed Apr 17 15:58:27 2013 -0700

    hugetlbfs: stop setting VM_DONTDUMP in initializing vma(VM_HUGETLB)
    
    commit a2fce9143057f4eb7675a21cca1b6beabe585c8b upstream.
    
    Currently we fail to include any data on hugepages into coredump,
    because VM_DONTDUMP is set on hugetlbfs's vma.  This behavior was
    recently introduced by commit 314e51b9851b ("mm: kill vma flag
    VM_RESERVED and mm->reserved_vm counter").
    
    This looks to me a serious regression, so let's fix it.
    
    Signed-off-by: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
    Acked-by: Konstantin Khlebnikov <khlebnikov@openvz.org>
    Acked-by: Michal Hocko <mhocko@suse.cz>
    Reviewed-by: Rik van Riel <riel@redhat.com>
    Acked-by: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.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: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3f78a9f022c9bc045a6d2cc864a1d77ad3c3f784
Author: Christoph Fritz <chf.fritz@googlemail.com>
Date:   Thu Apr 11 21:32:57 2013 +0200

    can: sja1000: fix handling on dt properties on little endian systems
    
    commit 0443de5fbf224abf41f688d8487b0c307dc5a4b4 upstream.
    
    To get correct endianes on little endian cpus (like arm) while reading device
    tree properties, this patch replaces of_get_property() with
    of_property_read_u32(). While there use of_property_read_bool() for the
    handling of the boolean "nxp,no-comparator-bypass" property.
    
    Signed-off-by: Christoph Fritz <chf.fritz@googlemail.com>
    Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b15bae9faecfb714cbf0c4585cd46b32d0a40e5a
Author: Marc Kleine-Budde <mkl@pengutronix.de>
Date:   Thu Apr 11 10:08:27 2013 +0200

    can: mcp251x: add missing IRQF_ONESHOT to request_threaded_irq
    
    commit db388d6460ffa53b3b38429da6f70a913f89b048 upstream.
    
    Since commit:
    
        1c6c695 genirq: Reject bogus threaded irq requests
    
    threaded irqs must provide a primary handler or set the IRQF_ONESHOT flag.
    Since the mcp251x driver doesn't make use of a primary handler set the
    IRQF_ONESHOT flag.
    
    Reported-by: Mylene Josserand <Mylene.Josserand@navocap.com>
    Tested-by: Mylene Josserand <Mylene.Josserand@navocap.com>
    Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d7e0ec47be2ac4c26c4a2ed44e9541d790e7bb94
Author: Michael Bohan <mbohan@codeaurora.org>
Date:   Tue Mar 19 19:19:25 2013 -0700

    hrtimer: Don't reinitialize a cpu_base lock on CPU_UP
    
    commit 84cc8fd2fe65866e49d70b38b3fdf7219dd92fe0 upstream.
    
    The current code makes the assumption that a cpu_base lock won't be
    held if the CPU corresponding to that cpu_base is offline, which isn't
    always true.
    
    If a hrtimer is not queued, then it will not be migrated by
    migrate_hrtimers() when a CPU is offlined. Therefore, the hrtimer's
    cpu_base may still point to a CPU which has subsequently gone offline
    if the timer wasn't enqueued at the time the CPU went down.
    
    Normally this wouldn't be a problem, but a cpu_base's lock is blindly
    reinitialized each time a CPU is brought up. If a CPU is brought
    online during the period that another thread is performing a hrtimer
    operation on a stale hrtimer, then the lock will be reinitialized
    under its feet, and a SPIN_BUG() like the following will be observed:
    
    <0>[   28.082085] BUG: spinlock already unlocked on CPU#0, swapper/0/0
    <0>[   28.087078]  lock: 0xc4780b40, value 0x0 .magic: dead4ead, .owner: <none>/-1, .owner_cpu: -1
    <4>[   42.451150] [<c0014398>] (unwind_backtrace+0x0/0x120) from [<c0269220>] (do_raw_spin_unlock+0x44/0xdc)
    <4>[   42.460430] [<c0269220>] (do_raw_spin_unlock+0x44/0xdc) from [<c071b5bc>] (_raw_spin_unlock+0x8/0x30)
    <4>[   42.469632] [<c071b5bc>] (_raw_spin_unlock+0x8/0x30) from [<c00a9ce0>] (__hrtimer_start_range_ns+0x1e4/0x4f8)
    <4>[   42.479521] [<c00a9ce0>] (__hrtimer_start_range_ns+0x1e4/0x4f8) from [<c00aa014>] (hrtimer_start+0x20/0x28)
    <4>[   42.489247] [<c00aa014>] (hrtimer_start+0x20/0x28) from [<c00e6190>] (rcu_idle_enter_common+0x1ac/0x320)
    <4>[   42.498709] [<c00e6190>] (rcu_idle_enter_common+0x1ac/0x320) from [<c00e6440>] (rcu_idle_enter+0xa0/0xb8)
    <4>[   42.508259] [<c00e6440>] (rcu_idle_enter+0xa0/0xb8) from [<c000f268>] (cpu_idle+0x24/0xf0)
    <4>[   42.516503] [<c000f268>] (cpu_idle+0x24/0xf0) from [<c06ed3c0>] (rest_init+0x88/0xa0)
    <4>[   42.524319] [<c06ed3c0>] (rest_init+0x88/0xa0) from [<c0c00978>] (start_kernel+0x3d0/0x434)
    
    As an example, this particular crash occurred when hrtimer_start() was
    executed on CPU #0. The code locked the hrtimer's current cpu_base
    corresponding to CPU #1. CPU #0 then tried to switch the hrtimer's
    cpu_base to an optimal CPU which was online. In this case, it selected
    the cpu_base corresponding to CPU #3.
    
    Before it could proceed, CPU #1 came online and reinitialized the
    spinlock corresponding to its cpu_base. Thus now CPU #0 held a lock
    which was reinitialized. When CPU #0 finally ended up unlocking the
    old cpu_base corresponding to CPU #1 so that it could switch to CPU
    #3, we hit this SPIN_BUG() above while in switch_hrtimer_base().
    
    CPU #0                            CPU #1
    ----                              ----
    ...                               <offline>
    hrtimer_start()
    lock_hrtimer_base(base #1)
    ...                               init_hrtimers_cpu()
    switch_hrtimer_base()             ...
    ...                               raw_spin_lock_init(&cpu_base->lock)
    raw_spin_unlock(&cpu_base->lock)  ...
    <spin_bug>
    
    Solve this by statically initializing the lock.
    
    Signed-off-by: Michael Bohan <mbohan@codeaurora.org>
    Link: http://lkml.kernel.org/r/1363745965-23475-1-git-send-email-mbohan@codeaurora.org
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0e55be921acde0e057419d570005913252f4efb7
Author: Thomas Gleixner <tglx@linutronix.de>
Date:   Tue Apr 9 09:33:34 2013 +0200

    kthread: Prevent unpark race which puts threads on the wrong cpu
    
    commit f2530dc71cf0822f90bb63ea4600caaef33a66bb upstream.
    
    The smpboot threads rely on the park/unpark mechanism which binds per
    cpu threads on a particular core. Though the functionality is racy:
    
    CPU0	       	 	CPU1  	     	    CPU2
    unpark(T)				    wake_up_process(T)
      clear(SHOULD_PARK)	T runs
    			leave parkme() due to !SHOULD_PARK
      bind_to(CPU2)		BUG_ON(wrong CPU)
    
    We cannot let the tasks move themself to the target CPU as one of
    those tasks is actually the migration thread itself, which requires
    that it starts running on the target cpu right away.
    
    The solution to this problem is to prevent wakeups in park mode which
    are not from unpark(). That way we can guarantee that the association
    of the task to the target cpu is working correctly.
    
    Add a new task state (TASK_PARKED) which prevents other wakeups and
    use this state explicitly for the unpark wakeup.
    
    Peter noticed: Also, since the task state is visible to userspace and
    all the parked tasks are still in the PID space, its a good hint in ps
    and friends that these tasks aren't really there for the moment.
    
    The migration thread has another related issue.
    
    CPU0	      	     	 CPU1
    Bring up CPU2
    create_thread(T)
    park(T)
     wait_for_completion()
    			 parkme()
    			 complete()
    sched_set_stop_task()
    			 schedule(TASK_PARKED)
    
    The sched_set_stop_task() call is issued while the task is on the
    runqueue of CPU1 and that confuses the hell out of the stop_task class
    on that cpu. So we need the same synchronizaion before
    sched_set_stop_task().
    
    Reported-by: Dave Jones <davej@redhat.com>
    Reported-and-tested-by: Dave Hansen <dave@sr71.net>
    Reported-and-tested-by: Borislav Petkov <bp@alien8.de>
    Acked-by: Peter Ziljstra <peterz@infradead.org>
    Cc: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
    Cc: dhillf@gmail.com
    Cc: Ingo Molnar <mingo@kernel.org>
    Link: http://lkml.kernel.org/r/alpine.LFD.2.02.1304091635430.21884@ionos
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3d9203cb7216794cd49cfb2aa90e7f69976fbe6d
Author: Russell King <rmk+kernel@arm.linux.org.uk>
Date:   Mon Apr 8 11:44:57 2013 +0100

    ARM: Do 15e0d9e37c (ARM: pm: let platforms select cpu_suspend support) properly
    
    commit b6c7aabd923a17af993c5a5d5d7995f0b27c000a upstream.
    
    Let's do the changes properly and fix the same problem everywhere, not
    just for one case.
    
    Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 518a8ee27d903ee9d2340c264994c813e1d421b5
Author: Scott Wood <scottwood@freescale.com>
Date:   Mon Feb 18 18:13:09 2013 +0000

    kvm/powerpc/e500mc: fix tlb invalidation on cpu migration
    
    commit c5e6cb051c5f7d56f05bd6a4af22cb300a4ced79 upstream.
    
    The existing check handles the case where we've migrated to a different
    core than we last ran on, but it doesn't handle the case where we're
    still on the same cpu we last ran on, but some other vcpu has run on
    this cpu in the meantime.
    
    Without this, guest segfaults (and other misbehavior) have been seen in
    smp guests.
    
    Signed-off-by: Scott Wood <scottwood@freescale.com>
    Signed-off-by: Alexander Graf <agraf@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d2c298eb24fe580153f1e122bb6da1bfdd798c59
Author: Kevin Hao <haokexin@gmail.com>
Date:   Tue Apr 9 22:31:24 2013 +0000

    powerpc: add a missing label in resume_kernel
    
    commit d8b92292408831d86ff7b781e66bf79301934b99 upstream.
    
    A label 0 was missed in the patch a9c4e541 (powerpc/kprobe: Complete
    kprobe and migrate exception frame). This will cause the kernel
    branch to an undetermined address if there really has a conflict when
    updating the thread flags.
    
    Signed-off-by: Kevin Hao <haokexin@gmail.com>
    Acked-By: Tiejun Chen <tiejun.chen@windriver.com>
    Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>