commit f39c8bf9da4f90904787f63abfa138ceae0f5db9
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Tue May 13 14:11:45 2014 +0200

    Linux 3.4.90

commit 53b67ae8d3d01efbdfd7ae431d8d46cba70084b9
Author: Mike Snitzer <snitzer@redhat.com>
Date:   Fri Mar 28 02:15:02 2014 -0400

    dm thin: fix dangling bio in process_deferred_bios error path
    
    commit fe76cd88e654124d1431bb662a0fc6e99ca811a5 upstream.
    
    If unable to ensure_next_mapping() we must add the current bio, which
    was removed from the @bios list via bio_list_pop, back to the
    deferred_bios list before all the remaining @bios.
    
    Signed-off-by: Mike Snitzer <snitzer@redhat.com>
    Acked-by: Joe Thornber <ejt@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b4e472edda0a5993ede690aca9a3fa3d8750c5f2
Author: Giacomo Comes <comes@naic.edu>
Date:   Thu Apr 3 14:13:55 2014 -0400

    Skip intel_crt_init for Dell XPS 8700
    
    commit 10b6ee4a87811a110cb01eaca01eb04da6801baf upstream.
    
    The Dell XPS 8700 has a onboard Display port and HDMI port and no VGA port.
    The call intel_crt_init freeze the machine, so skip such call.
    
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=73559
    Signed-off-by: Giacomo Comes <comes at naic.edu>
    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9a9269138723e71e87f4adb00c0c2bbdc7bdcd0b
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Thu Dec 5 17:53:50 2013 +0300

    mtd: sm_ftl: heap corruption in sm_create_sysfs_attributes()
    
    commit b4c233057771581698a13694ab6f33b48ce837dc upstream.
    
    We always put a NUL terminator one space past the end of the "vendor"
    buffer.  Walter Harms also pointed out that this should just use
    kstrndup().
    
    Fixes: 7d17c02a01a1 ('mtd: Add new SmartMedia/xD FTL')
    
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: Brian Norris <computersforpeace@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c3a47361053bdd9059eec78510de21684f4112c5
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Mon Feb 17 23:03:08 2014 +0300

    mtd: nuc900_nand: NULL dereference in nuc900_nand_enable()
    
    commit c69dbbf3335a21aae74376d7e5db50a486d52439 upstream.
    
    Instead of writing to "nand->reg + REG_FMICSR" we write to "REG_FMICSR"
    which is NULL and not a valid register.
    
    Fixes: 8bff82cbc308 ('mtd: add nand support for w90p910 (v2)')
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: Brian Norris <computersforpeace@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fd9a5e6cd4d5f923eff026dd288764cf65c001a7
Author: Mikulas Patocka <mpatocka@redhat.com>
Date:   Thu Jan 23 14:43:10 2014 -0500

    tgafb: fix data copying
    
    commit 6b0df6827bb6fcacb158dff29ad0a62d6418b534 upstream.
    
    The functions for data copying copyarea_foreward_8bpp and
    copyarea_backward_8bpp are buggy, they produce screen corruption.
    
    This patch fixes the functions and moves the logic to one function
    "copyarea_8bpp". For simplicity, the function only handles copying that
    is aligned on 8 pixes. If we copy an unaligned area, generic function
    cfb_copyarea is used.
    
    Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
    Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0e0dc73524d0e17a6dce2d3cd7ec3d6a785eb6df
Author: Marek Vasut <marex@denx.de>
Date:   Mon Mar 24 03:38:10 2014 +0100

    gpio: mxs: Allow for recursive enable_irq_wake() call
    
    commit a585f87c863e4e1d496459d382b802bf5ebe3717 upstream.
    
    The scenario here is that someone calls enable_irq_wake() from somewhere
    in the code. This will result in the lockdep producing a backtrace as can
    be seen below. In my case, this problem is triggered when using the wl1271
    (TI WlCore) driver found in drivers/net/wireless/ti/ .
    
    The problem cause is rather obvious from the backtrace, but let's outline
    the dependency. enable_irq_wake() grabs the IRQ buslock in irq_set_irq_wake(),
    which in turns calls mxs_gpio_set_wake_irq() . But mxs_gpio_set_wake_irq()
    calls enable_irq_wake() again on the one-level-higher IRQ , thus it tries to
    grab the IRQ buslock again in irq_set_irq_wake() . Because the spinlock in
    irq_set_irq_wake()->irq_get_desc_buslock()->__irq_get_desc_lock() is not
    marked as recursive, lockdep will spew the stuff below.
    
    We know we can safely re-enter the lock, so use IRQ_GC_INIT_NESTED_LOCK to
    fix the spew.
    
     =============================================
     [ INFO: possible recursive locking detected ]
     3.10.33-00012-gf06b763-dirty #61 Not tainted
     ---------------------------------------------
     kworker/0:1/18 is trying to acquire lock:
      (&irq_desc_lock_class){-.-...}, at: [<c00685f0>] __irq_get_desc_lock+0x48/0x88
    
     but task is already holding lock:
      (&irq_desc_lock_class){-.-...}, at: [<c00685f0>] __irq_get_desc_lock+0x48/0x88
    
     other info that might help us debug this:
      Possible unsafe locking scenario:
    
            CPU0
            ----
       lock(&irq_desc_lock_class);
       lock(&irq_desc_lock_class);
    
      *** DEADLOCK ***
    
      May be due to missing lock nesting notation
    
     3 locks held by kworker/0:1/18:
      #0:  (events){.+.+.+}, at: [<c0036308>] process_one_work+0x134/0x4a4
      #1:  ((&fw_work->work)){+.+.+.}, at: [<c0036308>] process_one_work+0x134/0x4a4
      #2:  (&irq_desc_lock_class){-.-...}, at: [<c00685f0>] __irq_get_desc_lock+0x48/0x88
    
     stack backtrace:
     CPU: 0 PID: 18 Comm: kworker/0:1 Not tainted 3.10.33-00012-gf06b763-dirty #61
     Workqueue: events request_firmware_work_func
     [<c0013eb4>] (unwind_backtrace+0x0/0xf0) from [<c0011c74>] (show_stack+0x10/0x14)
     [<c0011c74>] (show_stack+0x10/0x14) from [<c005bb08>] (__lock_acquire+0x140c/0x1a64)
     [<c005bb08>] (__lock_acquire+0x140c/0x1a64) from [<c005c6a8>] (lock_acquire+0x9c/0x104)
     [<c005c6a8>] (lock_acquire+0x9c/0x104) from [<c051d5a4>] (_raw_spin_lock_irqsave+0x44/0x58)
     [<c051d5a4>] (_raw_spin_lock_irqsave+0x44/0x58) from [<c00685f0>] (__irq_get_desc_lock+0x48/0x88)
     [<c00685f0>] (__irq_get_desc_lock+0x48/0x88) from [<c0068e78>] (irq_set_irq_wake+0x20/0xf4)
     [<c0068e78>] (irq_set_irq_wake+0x20/0xf4) from [<c027260c>] (mxs_gpio_set_wake_irq+0x1c/0x24)
     [<c027260c>] (mxs_gpio_set_wake_irq+0x1c/0x24) from [<c0068cf4>] (set_irq_wake_real+0x30/0x44)
     [<c0068cf4>] (set_irq_wake_real+0x30/0x44) from [<c0068ee4>] (irq_set_irq_wake+0x8c/0xf4)
     [<c0068ee4>] (irq_set_irq_wake+0x8c/0xf4) from [<c0310748>] (wlcore_nvs_cb+0x10c/0x97c)
     [<c0310748>] (wlcore_nvs_cb+0x10c/0x97c) from [<c02be5e8>] (request_firmware_work_func+0x38/0x58)
     [<c02be5e8>] (request_firmware_work_func+0x38/0x58) from [<c0036394>] (process_one_work+0x1c0/0x4a4)
     [<c0036394>] (process_one_work+0x1c0/0x4a4) from [<c0036a4c>] (worker_thread+0x138/0x394)
     [<c0036a4c>] (worker_thread+0x138/0x394) from [<c003cb74>] (kthread+0xa4/0xb0)
     [<c003cb74>] (kthread+0xa4/0xb0) from [<c000ee00>] (ret_from_fork+0x14/0x34)
     wlcore: loaded
    
    Signed-off-by: Marek Vasut <marex@denx.de>
    Acked-by: Shawn Guo <shawn.guo@linaro.org>
    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f8f3dc1af7bfe87bafce271fd3f7b65078cd8778
Author: Larry Finger <Larry.Finger@lwfinger.net>
Date:   Tue Mar 4 16:53:51 2014 -0600

    rtlwifi: rtl8192se: Fix too long disable of IRQs
    
    commit 2610decdd0b3808ba20471a999835cfee5275f98 upstream.
    
    In commit f78bccd79ba3cd9d9664981b501d57bdb81ab8a4 entitled "rtlwifi:
    rtl8192ce: Fix too long disable of IRQs", Olivier Langlois
    <olivier@trillion01.com> fixed a problem caused by an extra long disabling
    of interrupts. This patch makes the same fix for rtl8192se.
    
    Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 04dbe2b495485ba9172da476beedbba76bca2bc8
Author: Larry Finger <Larry.Finger@lwfinger.net>
Date:   Tue Mar 4 16:53:50 2014 -0600

    rtlwifi: rtl8192cu: Fix too long disable of IRQs
    
    commit a53268be0cb9763f11da4f6fe3fb924cbe3a7d4a upstream.
    
    In commit f78bccd79ba3cd9d9664981b501d57bdb81ab8a4 entitled "rtlwifi:
    rtl8192ce: Fix too long disable of IRQs", Olivier Langlois
    <olivier@trillion01.com> fixed a problem caused by an extra long disabling
    of interrupts. This patch makes the same fix for rtl8192cu.
    
    Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 08f36d9d2cbe95df935378c220215791fc1dd111
Author: Jeff Layton <jlayton@redhat.com>
Date:   Tue Apr 15 08:44:12 2014 -0400

    locks: allow __break_lease to sleep even when break_time is 0
    
    commit 4991a628a789dc5954e98e79476d9808812292ec upstream.
    
    A fl->fl_break_time of 0 has a special meaning to the lease break code
    that basically means "never break the lease". knfsd uses this to ensure
    that leases don't disappear out from under it.
    
    Unfortunately, the code in __break_lease can end up passing this value
    to wait_event_interruptible as a timeout, which prevents it from going
    to sleep at all. This causes __break_lease to spin in a tight loop and
    causes soft lockups.
    
    Fix this by ensuring that we pass a minimum value of 1 as a timeout
    instead.
    
    Cc: J. Bruce Fields <bfields@fieldses.org>
    Reported-by: Terry Barnaby <terry1@beam.ltd.uk>
    Signed-off-by: Jeff Layton <jlayton@redhat.com>
    Signed-off-by: J. Bruce Fields <bfields@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e45d91ae6e931aec803c5cbbe36b53e64c3e3077
Author: Dan Williams <dan.j.williams@intel.com>
Date:   Thu Apr 17 11:48:21 2014 -0700

    libata/ahci: accommodate tag ordered controllers
    
    commit 8a4aeec8d2d6a3edeffbdfae451cdf05cbf0fefd upstream.
    
    The AHCI spec allows implementations to issue commands in tag order
    rather than FIFO order:
    
    	5.3.2.12 P:SelectCmd
    	HBA sets pSlotLoc = (pSlotLoc + 1) mod (CAP.NCS + 1)
    	or HBA selects the command to issue that has had the
    	PxCI bit set to '1' longer than any other command
    	pending to be issued.
    
    The result is that commands posted sequentially (time-wise) may play out
    of sequence when issued by hardware.
    
    This behavior has likely been hidden by drives that arrange for commands
    to complete in issue order.  However, it appears recent drives (two from
    different vendors that we have found so far) inflict out-of-order
    completions as a matter of course.  So, we need to take care to maintain
    ordered submission, otherwise we risk triggering a drive to fall out of
    sequential-io automation and back to random-io processing, which incurs
    large latency and degrades throughput.
    
    This issue was found in simple benchmarks where QD=2 seq-write
    performance was 30-50% *greater* than QD=32 seq-write performance.
    
    Tagging for -stable and making the change globally since it has a low
    risk-to-reward ratio.  Also, word is that recent versions of an unnamed
    OS also does it this way now.  So, drives in the field are already
    experienced with this tag ordering scheme.
    
    Cc: Dave Jiang <dave.jiang@intel.com>
    Cc: Ed Ciechanowski <ed.ciechanowski@intel.com>
    Reviewed-by: Matthew Wilcox <matthew.r.wilcox@intel.com>
    Signed-off-by: Dan Williams <dan.j.williams@intel.com>
    Signed-off-by: Tejun Heo <tj@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b9fbc5762da741f3fa89246193acdce428ce6816
Author: Rafał Miłecki <zajec5@gmail.com>
Date:   Sat Apr 5 18:08:25 2014 +0200

    b43: Fix machine check error due to improper access of B43_MMIO_PSM_PHY_HDR
    
    commit 12cd43c6ed6da7bf7c5afbd74da6959cda6d056b upstream.
    
    Register B43_MMIO_PSM_PHY_HDR is 16 bit one, so accessing it with 32b
    functions isn't safe. On my machine it causes delayed (!) CPU exception:
    
    Disabling lock debugging due to kernel taint
    mce: [Hardware Error]: CPU 0: Machine Check Exception: 4 Bank 4: b200000000070f0f
    mce: [Hardware Error]: TSC 164083803dc
    mce: [Hardware Error]: PROCESSOR 2:20fc2 TIME 1396650505 SOCKET 0 APIC 0 microcode 0
    mce: [Hardware Error]: Run the above through 'mcelog --ascii'
    mce: [Hardware Error]: Machine check: Processor context corrupt
    Kernel panic - not syncing: Fatal machine check on current CPU
    Kernel Offset: 0x0 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffff9fffffff)
    
    Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
    Acked-by: Larry Finger <Larry.Finger@lwfinger.net>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 34dc182bf300e62e830c19ad174dfcb6ea973e6a
Author: Mikulas Patocka <mpatocka@redhat.com>
Date:   Thu Jan 23 14:41:59 2014 -0500

    mach64: fix cursor when character width is not a multiple of 8 pixels
    
    commit 43751a1b8ee2e70ce392bf31ef3133da324e68b3 upstream.
    
    This patch fixes the hardware cursor on mach64 when font width is not a
    multiple of 8 pixels.
    
    If you load such a font, the cursor is expanded to the next 8-byte
    boundary and a part of the next character after the cursor is not
    visible.
    For example, when you load a font with 12-pixel width, the cursor width
    is 16 pixels and when the cursor is displayed, 4 pixels of the next
    character are not visible.
    
    The reason is this: atyfb_cursor is called with proper parameters to
    load an image that is 12-pixel wide. However, the number is aligned on
    the next 8-pixel boundary on the line
    "unsigned int width = (cursor->image.width + 7) >> 3;" and the whole
    function acts as it is was loading a 16-pixel image.
    
    This patch fixes it so that the value written to the framebuffer is
    padded with 0xaaaa (the transparent pattern) when the image size it not
    a multiple of 8 pixels. The transparent pattern causes that the cursor
    will not interfere with the next character.
    
    Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
    Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit caf6f52449661bfcc4c5d3f79d65c1cda23f4a89
Author: Mikulas Patocka <mpatocka@redhat.com>
Date:   Thu Jan 23 14:41:09 2014 -0500

    mach64: use unaligned access
    
    commit c29dd8696dc5dbd50b3ac441b8a26751277ba520 upstream.
    
    This patch fixes mach64 to use unaligned access to the font bitmap.
    
    This fixes unaligned access warning on sparc64 when 14x8 font is loaded.
    
    On x86(64), unaligned access is handled in hardware, so both functions
    le32_to_cpup and get_unaligned_le32 perform the same operation.
    
    On RISC machines, unaligned access is not handled in hardware, so we
    better use get_unaligned_le32 to avoid the unaligned trap and warning.
    
    Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
    Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7ea30442913175c11e9e142c45c11bd88570bbad
Author: Mikulas Patocka <mpatocka@redhat.com>
Date:   Thu Jan 23 14:39:04 2014 -0500

    matroxfb: restore the registers M_ACCESS and M_PITCH
    
    commit a772d4736641ec1b421ad965e13457c17379fc86 upstream.
    
    When X11 is running and the user switches back to console, the card
    modifies the content of registers M_MACCESS and M_PITCH in periodic
    intervals.
    
    This patch fixes it by restoring the content of these registers before
    issuing any accelerator command.
    
    Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
    Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8b26a7a7b4abd06f3eca2772317bc7840f6e834a
Author: Mikulas Patocka <mpatocka@redhat.com>
Date:   Thu Jan 23 14:39:29 2014 -0500

    framebuffer: fix cfb_copyarea
    
    commit 00a9d699bc85052d2d3ed56251cd928024ce06a3 upstream.
    
    The function cfb_copyarea is buggy when the copy operation is not aligned on
    long boundary (4 bytes on 32-bit machines, 8 bytes on 64-bit machines).
    
    How to reproduce:
    - use x86-64 machine
    - use a framebuffer driver without acceleration (for example uvesafb)
    - set the framebuffer to 8-bit depth
    	(for example fbset -a 1024x768-60 -depth 8)
    - load a font with character width that is not a multiple of 8 pixels
    	note: the console-tools package cannot load a font that has
    	width different from 8 pixels. You need to install the packages
    	"kbd" and "console-terminus" and use the program "setfont" to
    	set font width (for example: setfont Uni2-Terminus20x10)
    - move some text left and right on the bash command line and you get a
    	screen corruption
    
    To expose more bugs, put this line to the end of uvesafb_init_info:
    info->flags |= FBINFO_HWACCEL_COPYAREA | FBINFO_READS_FAST;
    - Now framebuffer console will use cfb_copyarea for console scrolling.
    You get a screen corruption when console is scrolled.
    
    This patch is a rewrite of cfb_copyarea. It fixes the bugs, with this
    patch, console scrolling in 8-bit depth with a font width that is not a
    multiple of 8 pixels works fine.
    
    The cfb_copyarea code was very buggy and it looks like it was written
    and never tried with non-8-pixel font.
    
    Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
    Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 89a3abc1fd0dd979929362a2a355d899f4574dab
Author: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Date:   Thu Mar 27 18:14:40 2014 +0100

    crypto: ghash-clmulni-intel - use C implementation for setkey()
    
    commit 8ceee72808d1ae3fb191284afc2257a2be964725 upstream.
    
    The GHASH setkey() function uses SSE registers but fails to call
    kernel_fpu_begin()/kernel_fpu_end(). Instead of adding these calls, and
    then having to deal with the restriction that they cannot be called from
    interrupt context, move the setkey() implementation to the C domain.
    
    Note that setkey() does not use any particular SSE features and is not
    expected to become a performance bottleneck.
    
    Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
    Acked-by: H. Peter Anvin <hpa@linux.intel.com>
    Fixes: 0e1227d356e9b (crypto: ghash - Add PCLMULQDQ accelerated implementation)
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a2295c4263fe35f674f0061fe0419c73238d5b5b
Author: Tyler Stachecki <tstache1@binghamton.edu>
Date:   Fri Apr 25 16:41:04 2014 -0400

    mpt2sas: Don't disable device twice at suspend.
    
    commit af61e27c3f77c7623b5335590ae24b6a5c323e22 upstream.
    
    On suspend, _scsih_suspend calls mpt2sas_base_free_resources, which
    in turn calls pci_disable_device if the device is enabled prior to
    suspending. However, _scsih_suspend also calls pci_disable_device
    itself.
    
    Thus, in the event that the device is enabled prior to suspending,
    pci_disable_device will be called twice. This patch removes the
    duplicate call to pci_disable_device in _scsi_suspend as it is both
    unnecessary and results in a kernel oops.
    
    Signed-off-by: Tyler Stachecki <tstache1@binghamton.edu>
    Signed-off-by: James Bottomley <JBottomley@Parallels.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 983327a48a263bd65fa869a0aad76baaf75fff86
Author: Rusty Russell <rusty@rustcorp.com.au>
Date:   Thu Mar 13 11:23:38 2014 +1030

    virtio_balloon: don't softlockup on huge balloon changes.
    
    commit 1f74ef0f2d7d692fcd615621e0e734c3e7771413 upstream.
    
    When adding or removing 100G from a balloon:
    
        BUG: soft lockup - CPU#0 stuck for 22s! [vballoon:367]
    
    We have a wait_event_interruptible(), but the condition is always true
    (more ballooning to do) so we don't ever sleep.  We also have a
    wait_event() for the host to ack, but that is also always true as QEMU
    is synchronous for balloon operations.
    
    Reported-by: Gopesh Kumar Chaudhary <gopchaud@in.ibm.com>
    Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ef9146785e023ef84cb777aac6deae53c53a2b84
Author: Huacai Chen <chenhc@lemote.com>
Date:   Sat Mar 22 17:21:44 2014 +0800

    MIPS: Hibernate: Flush TLB entries in swsusp_arch_resume()
    
    commit c14af233fbe279d0e561ecf84f1208b1bae087ef upstream.
    
    The original MIPS hibernate code flushes cache and TLB entries in
    swsusp_arch_resume(). But they are removed in Commit 44eeab67416711
    (MIPS: Hibernation: Remove SMP TLB and cacheflushing code.). A cross-
    CPU flush is surely unnecessary because all but the local CPU have
    already been disabled. But a local flush (at least the TLB flush) is
    needed. When we do hibernation on Loongson-3 with an E1000E NIC, it is
    very easy to produce a kernel panic (kernel page fault, or unaligned
    access). The root cause is E1000E driver use vzalloc_node() to allocate
    pages, the stale TLB entries of the booting kernel will be misused by
    the resumed target kernel.
    
    Signed-off-by: Huacai Chen <chenhc@lemote.com>
    Cc: John Crispin <john@phrozen.org>
    Cc: Steven J. Hill <Steven.Hill@imgtec.com>
    Cc: Aurelien Jarno <aurelien@aurel32.net>
    Cc: linux-mips@linux-mips.org
    Cc: Fuxin Zhang <zhangfx@lemote.com>
    Cc: Zhangjin Wu <wuzhangjin@gmail.com>
    Patchwork: https://patchwork.linux-mips.org/patch/6643/
    Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit bfa779779247e9421b23155747e1779ce87aa040
Author: Matthew Daley <mattd@bugfuzz.com>
Date:   Mon Apr 28 19:05:21 2014 +1200

    floppy: don't write kernel-only members to FDRAWCMD ioctl output
    
    commit 2145e15e0557a01b9195d1c7199a1b92cb9be81f upstream.
    
    Do not leak kernel-only floppy_raw_cmd structure members to userspace.
    This includes the linked-list pointer and the pointer to the allocated
    DMA space.
    
    Signed-off-by: Matthew Daley <mattd@bugfuzz.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a04d8ef979b661ce9051d0f22b0b2c25fc94b955
Author: Matthew Daley <mattd@bugfuzz.com>
Date:   Mon Apr 28 19:05:20 2014 +1200

    floppy: ignore kernel-only members in FDRAWCMD ioctl input
    
    commit ef87dbe7614341c2e7bfe8d32fcb7028cc97442c upstream.
    
    Always clear out these floppy_raw_cmd struct members after copying the
    entire structure from userspace so that the in-kernel version is always
    valid and never left in an interdeterminate state.
    
    Signed-off-by: Matthew Daley <mattd@bugfuzz.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5c5aeb0ca78c6b9cdca6462bf54f50ac28756cbb
Author: Tomoki Sekiyama <tomoki.sekiyama@hds.com>
Date:   Fri May 2 18:58:24 2014 -0400

    drivers/tty/hvc: don't free hvc_console_setup after init
    
    commit 501fed45b7e8836ee9373f4d31e2d85e3db6103a upstream.
    
    When 'console=hvc0' is specified to the kernel parameter in x86 KVM guest,
    hvc console is setup within a kthread. However, that will cause SEGV
    and the boot will fail when the driver is builtin to the kernel,
    because currently hvc_console_setup() is annotated with '__init'. This
    patch removes '__init' to boot the guest successfully with 'console=hvc0'.
    
    Signed-off-by: Tomoki Sekiyama <tomoki.sekiyama@hds.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>