commit 1e91ad229456cca04b8b98f1df805ac38a910543
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Sat Feb 22 13:32:50 2014 -0800

    Linux 3.12.13

commit c7e30e0abd1de37aee88b7a91db39ad2edb323a3
Author: Borislav Petkov <bp@suse.de>
Date:   Wed Feb 12 18:15:00 2014 +0100

    EDAC: Correct workqueue setup path
    
    commit cb6ef42e516cb8948f15e4b70dc03af8020050a2 upstream.
    
    We're using edac_mc_workq_setup() both on the init path, when
    we load an edac driver and when we change the polling period
    (edac_mc_reset_delay_period) through /sys/.../edac_mc_poll_msec.
    
    On that second path we don't need to init the workqueue which has been
    initialized already.
    
    Thanks to Tejun for workqueue insights.
    
    Signed-off-by: Borislav Petkov <bp@suse.de>
    Link: http://lkml.kernel.org/r/1391457913-881-1-git-send-email-prarit@redhat.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0e790ebdbef30619e0e52f738ef7d1c27abe6c54
Author: Borislav Petkov <bp@suse.de>
Date:   Mon Feb 3 15:05:13 2014 -0500

    EDAC: Poll timeout cannot be zero, p2
    
    commit 9da21b1509d8aa7ab4846722817d16c72d656c91 upstream.
    
    Sanitize code even more to accept unsigned longs only and to not allow
    polling intervals below 1 second as this is unnecessary and doesn't make
    much sense anyway for polling errors.
    
    Signed-off-by: Borislav Petkov <bp@suse.de>
    Link: http://lkml.kernel.org/r/1391457913-881-1-git-send-email-prarit@redhat.com
    Cc: Doug Thompson <dougthompson@xmission.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3e475641a0ebe23d4d4a28e53e70acaf2e24801c
Author: Prarit Bhargava <prarit@redhat.com>
Date:   Mon Feb 10 14:25:43 2014 -0800

    drivers/edac/edac_mc_sysfs.c: poll timeout cannot be zero
    
    commit 79040cad3f8235937e229f1b9401ba36dd5ad69b upstream.
    
    If you do
    
      echo 0 > /sys/module/edac_core/parameters/edac_mc_poll_msec
    
    the following stack trace is output because the edac module is not
    designed to poll with a timeout of zero.
    
      WARNING: CPU: 12 PID: 0 at lib/list_debug.c:33 __list_add+0xac/0xc0()
      list_add corruption. prev->next should be next (ffff8808291dd1b8), but was           (null). (prev=ffff8808286fe3f8).
      Modules linked in: sg nfsv3 rpcsec_gss_krb5 nfsv4 dns_resolver nfs fscache cfg80211 rfkill x86_pkg_temp_thermal coretemp kvm_intel kvm ixgbe e1000e crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_intel aesni_intel lrw gf128mul glue_helper ablk_helper cryptd iTCO_wdt ptp sb_edac iTCO_vendor_support pps_core mdio ipmi_devintf edac_core ioatdma microcode shpchp lpc_ich pcspkr i2c_i801 dca mfd_core ipmi_si wmi ipmi_msghandler nfsd auth_rpcgss nfs_acl lockd sunrpc xfs libcrc32c sd_mod sr_mod cdrom crc_t10dif crct10dif_common mgag200 syscopyarea sysfillrect sysimgblt isci i2c_algo_bit drm_kms_helper ttm drm libsas ahci libahci scsi_transport_sas libata i2c_core dm_mirror dm_region_hash dm_log dm_mod
      CPU: 12 PID: 0 Comm: swapper/12 Not tainted 3.13.0+ #1
      Hardware name: Intel Corporation LH Pass ........../SVRBD-ROW_T, BIOS SE5C600.86B.01.08.0003.022620131521 02/26/2013
      Call Trace:
       <IRQ>
        __list_add+0xac/0xc0
        __internal_add_timer+0xab/0x130
        internal_add_timer+0x17/0x40
        mod_timer_pinned+0xca/0x170
        intel_pstate_timer_func+0x28a/0x380
        call_timer_fn+0x36/0x100
        run_timer_softirq+0x1ff/0x2f0
        __do_softirq+0xf5/0x2e0
        irq_exit+0x10d/0x120
        smp_apic_timer_interrupt+0x45/0x60
        apic_timer_interrupt+0x6d/0x80
       <EOI>
        cpuidle_idle_call+0xb9/0x1f0
        arch_cpu_idle+0xe/0x30
        cpu_startup_entry+0x9e/0x240
        start_secondary+0x1e4/0x290
    
      kernel BUG at kernel/timer.c:1084!
      invalid opcode: 0000 [#1] SMP
      Modules linked in: sg nfsv3 rpcsec_gss_krb5 nfsv4 dns_resolver nfs fscache cfg80211 rfkill x86_pkg_temp_thermal coretemp kvm_intel kvm ixgbe e1000e crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_intel aesni_intel lrw gf128mul glue_helper ablk_helper cryptd iTCO_wdt ptp sb_edac iTCO_vendor_support pps_core mdio ipmi_devintf edac_core ioatdma microcode shpchp lpc_ich pcspkr i2c_i801 dca mfd_core ipmi_si wmi ipmi_msghandler nfsd auth_rpcgss nfs_acl lockd sunrpc xfs libcrc32c sd_mod sr_mod cdrom crc_t10dif crct10dif_common mgag200 syscopyarea sysfillrect sysimgblt isci i2c_algo_bit drm_kms_helper ttm drm libsas ahci libahci scsi_transport_sas libata i2c_core dm_mirror dm_region_hash dm_log dm_mod
      CPU: 12 PID: 0 Comm: swapper/12 Tainted: G        W    3.13.0+ #1
      Hardware name: Intel Corporation LH Pass ........../SVRBD-ROW_T, BIOS SE5C600.86B.01.08.0003.022620131521 02/26/2013
      Call Trace:
       <IRQ>
        run_timer_softirq+0x245/0x2f0
        __do_softirq+0xf5/0x2e0
        irq_exit+0x10d/0x120
        smp_apic_timer_interrupt+0x45/0x60
        apic_timer_interrupt+0x6d/0x80
       <EOI>
        cpuidle_idle_call+0xb9/0x1f0
        arch_cpu_idle+0xe/0x30
        cpu_startup_entry+0x9e/0x240
        start_secondary+0x1e4/0x290
      RIP   cascade+0x93/0xa0
    
      WARNING: CPU: 36 PID: 1154 at kernel/workqueue.c:1461 __queue_delayed_work+0xed/0x1a0()
      Modules linked in: sg nfsv3 rpcsec_gss_krb5 nfsv4 dns_resolver nfs fscache cfg80211 rfkill x86_pkg_temp_thermal coretemp kvm_intel kvm ixgbe e1000e crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_intel aesni_intel lrw gf128mul glue_helper ablk_helper cryptd iTCO_wdt ptp sb_edac iTCO_vendor_support pps_core mdio ipmi_devintf edac_core ioatdma microcode shpchp lpc_ich pcspkr i2c_i801 dca mfd_core ipmi_si wmi ipmi_msghandler nfsd auth_rpcgss nfs_acl lockd sunrpc xfs libcrc32c sd_mod sr_mod cdrom crc_t10dif crct10dif_common mgag200 syscopyarea sysfillrect sysimgblt isci i2c_algo_bit drm_kms_helper ttm drm libsas ahci libahci scsi_transport_sas libata i2c_core dm_mirror dm_region_hash dm_log dm_mod
      CPU: 36 PID: 1154 Comm: kworker/u481:3 Tainted: G        W    3.13.0+ #1
      Hardware name: Intel Corporation LH Pass ........../SVRBD-ROW_T, BIOS SE5C600.86B.01.08.0003.022620131521 02/26/2013
      Workqueue: edac-poller edac_mc_workq_function [edac_core]
      Call Trace:
        dump_stack+0x45/0x56
        warn_slowpath_common+0x7d/0xa0
        warn_slowpath_null+0x1a/0x20
        __queue_delayed_work+0xed/0x1a0
        queue_delayed_work_on+0x27/0x50
        edac_mc_workq_function+0x72/0xa0 [edac_core]
        process_one_work+0x17b/0x460
        worker_thread+0x11b/0x400
        kthread+0xd2/0xf0
        ret_from_fork+0x7c/0xb0
    
    This patch adds a range check in the edac_mc_poll_msec code to check for 0.
    
    Signed-off-by: Prarit Bhargava <prarit@redhat.com>
    Cc: Doug Thompson <dougthompson@xmission.com>
    Cc: Mauro Carvalho Chehab <mchehab@infradead.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d588c3d869bb593b685cdf0e0f620f146923fe05
Author: Paul Gortmaker <paul.gortmaker@windriver.com>
Date:   Mon Feb 10 13:39:53 2014 -0500

    genirq: Add missing irq_to_desc export for CONFIG_SPARSE_IRQ=n
    
    commit 2c45aada341121438affc4cb8d5b4cfaa2813d3d upstream.
    
    In allmodconfig builds for sparc and any other arch which does
    not set CONFIG_SPARSE_IRQ, the following will be seen at modpost:
    
      CC [M]  lib/cpu-notifier-error-inject.o
      CC [M]  lib/pm-notifier-error-inject.o
    ERROR: "irq_to_desc" [drivers/gpio/gpio-mcp23s08.ko] undefined!
    make[2]: *** [__modpost] Error 1
    
    This happens because commit 3911ff30f5 ("genirq: export
    handle_edge_irq() and irq_to_desc()") added one export for it, but
    there were actually two instances of it, in an if/else clause for
    CONFIG_SPARSE_IRQ.  Add the second one.
    
    Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
    Cc: Jiri Kosina <jkosina@suse.cz>
    Link: http://lkml.kernel.org/r/1392057610-11514-1-git-send-email-paul.gortmaker@windriver.com
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e495ac8fa1a22c8f9ea21b0270248592487a2b94
Author: Nicholas Bellinger <nab@linux-iscsi.org>
Date:   Thu Jan 30 13:08:49 2014 -0800

    target: Fix free-after-use regression in PR unregister
    
    commit fc09149df6e20cfbb0bb86f10899607c321a31eb upstream.
    
    This patch addresses a >= v3.11 free-after-use regression
    in core_scsi3_emulate_pro_register() that was introduced
    in the following commit:
    
    commit bc118fe4c4a8cfa453491ba77c0a146a6d0e73e0
    Author: Andy Grover <agrover@redhat.com>
    Date:   Thu May 16 10:41:04 2013 -0700
    
        target: Further refactoring of core_scsi3_emulate_pro_register()
    
    To avoid the free-after-use, save an type value before hand, and
    only call core_scsi3_put_pr_reg() with a valid *pr_reg.
    
    Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
    Cc: Andy Grover <agrover@redhat.com>
    Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fd60cc9e8dea0e93400fd9163d77f50b182322f3
Author: Steven Rostedt (Red Hat) <rostedt@goodmis.org>
Date:   Tue Feb 11 13:38:54 2014 -0500

    ring-buffer: Fix first commit on sub-buffer having non-zero delta
    
    commit d651aa1d68a2f0a7ee65697b04c6a92f8c0a12f2 upstream.
    
    Each sub-buffer (buffer page) has a full 64 bit timestamp. The events on
    that page use a 27 bit delta against that timestamp in order to save on
    bits written to the ring buffer. If the time between events is larger than
    what the 27 bits can hold, a "time extend" event is added to hold the
    entire 64 bit timestamp again and the events after that hold a delta from
    that timestamp.
    
    As a "time extend" is always paired with an event, it is logical to just
    allocate the event with the time extend, to make things a bit more efficient.
    
    Unfortunately, when the pairing code was written, it removed the "delta = 0"
    from the first commit on a page, causing the events on the page to be
    slightly skewed.
    
    Fixes: 69d1b839f7ee "ring-buffer: Bind time extend and data events together"
    Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c12b12edd8e38e05cbe103e65d61ea71f0746421
Author: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Date:   Thu Jan 30 14:32:45 2014 +0100

    power: max17040: Fix NULL pointer dereference when there is no platform_data
    
    commit ac323d8d807060f7c95a685a9fe861e7b6300993 upstream.
    
    Fix NULL pointer dereference of "chip->pdata" if platform_data was not
    supplied to the driver.
    
    The driver during probe stored the pointer to the platform_data:
    	chip->pdata = client->dev.platform_data;
    Later it was dereferenced in max17040_get_online() and
    max17040_get_status().
    
    If platform_data was not supplied, the NULL pointer exception would
    happen:
    
    [    6.626094] Unable to handle kernel  of a at virtual address 00000000
    [    6.628557] pgd = c0004000
    [    6.632868] [00000000] *pgd=66262564
    [    6.634636] Unable to handle kernel paging request at virtual address e6262000
    [    6.642014] pgd = de468000
    [    6.644700] [e6262000] *pgd=00000000
    [    6.648265] Internal error: Oops: 5 [#1] PREEMPT SMP ARM
    [    6.653552] Modules linked in:
    [    6.656598] CPU: 0 PID: 31 Comm: kworker/0:1 Not tainted 3.10.14-02717-gc58b4b4 #505
    [    6.664334] Workqueue: events max17040_work
    [    6.668488] task: dfa11b80 ti: df9f6000 task.ti: df9f6000
    [    6.673873] PC is at show_pte+0x80/0xb8
    [    6.677687] LR is at show_pte+0x3c/0xb8
    [    6.681503] pc : [<c001b7b8>]    lr : [<c001b774>]    psr: 600f0113
    [    6.681503] sp : df9f7d58  ip : 600f0113  fp : 00000009
    [    6.692965] r10: 00000000  r9 : 00000000  r8 : dfa11b80
    [    6.698171] r7 : df9f7ea0  r6 : e6262000  r5 : 00000000  r4 : 00000000
    [    6.704680] r3 : 00000000  r2 : e6262000  r1 : 600f0193  r0 : c05b3750
    [    6.711194] Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment kernel
    [    6.718485] Control: 10c53c7d  Table: 5e46806a  DAC: 00000015
    [    6.724218] Process kworker/0:1 (pid: 31, stack limit = 0xdf9f6238)
    [    6.730465] Stack: (0xdf9f7d58 to 0xdf9f8000)
    [    6.914325] [<c001b7b8>] (show_pte+0x80/0xb8) from [<c047107c>] (__do_kernel_fault.part.9+0x44/0x74)
    [    6.923425] [<c047107c>] (__do_kernel_fault.part.9+0x44/0x74) from [<c001bb7c>] (do_page_fault+0x2c4/0x360)
    [    6.933144] [<c001bb7c>] (do_page_fault+0x2c4/0x360) from [<c0008400>] (do_DataAbort+0x34/0x9c)
    [    6.941825] [<c0008400>] (do_DataAbort+0x34/0x9c) from [<c000e5d8>] (__dabt_svc+0x38/0x60)
    [    6.950058] Exception stack(0xdf9f7ea0 to 0xdf9f7ee8)
    [    6.955099] 7ea0: df0c1790 00000000 00000002 00000000 df0c1794 df0c1790 df0c1790 00000042
    [    6.963271] 7ec0: df0c1794 00000001 00000000 00000009 00000000 df9f7ee8 c0306268 c0306270
    [    6.971419] 7ee0: a00f0113 ffffffff
    [    6.974902] [<c000e5d8>] (__dabt_svc+0x38/0x60) from [<c0306270>] (max17040_work+0x8c/0x144)
    [    6.983317] [<c0306270>] (max17040_work+0x8c/0x144) from [<c003f364>] (process_one_work+0x138/0x440)
    [    6.992429] [<c003f364>] (process_one_work+0x138/0x440) from [<c003fa64>] (worker_thread+0x134/0x3b8)
    [    7.001628] [<c003fa64>] (worker_thread+0x134/0x3b8) from [<c00454bc>] (kthread+0xa4/0xb0)
    [    7.009875] [<c00454bc>] (kthread+0xa4/0xb0) from [<c000eb28>] (ret_from_fork+0x14/0x2c)
    [    7.017943] Code: e1a03005 e2422480 e0826104 e59f002c (e7922104)
    [    7.024017] ---[ end trace 73bc7006b9cc5c79 ]---
    
    Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
    Fixes: c6f4a42de60b981dd210de01cd3e575835e3158e
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 536bfe9d31fdcb332e739e8b7e8219eab5665be9
Author: Mikulas Patocka <mpatocka@redhat.com>
Date:   Fri Jan 24 16:41:36 2014 -0500

    time: Fix overflow when HZ is smaller than 60
    
    commit 80d767d770fd9c697e434fd080c2db7b5c60c6dd upstream.
    
    When compiling for the IA-64 ski emulator, HZ is set to 32 because the
    emulation is slow and we don't want to waste too many cycles processing
    timers. Alpha also has an option to set HZ to 32.
    
    This causes integer underflow in
    kernel/time/jiffies.c:
    kernel/time/jiffies.c:66:2: warning: large integer implicitly truncated to unsigned type [-Woverflow]
      .mult  = NSEC_PER_JIFFY << JIFFIES_SHIFT, /* details above */
      ^
    
    This patch reduces the JIFFIES_SHIFT value to avoid the overflow.
    
    Signed-off-by: Mikulas Patocka <mikulas@artax.karlin.mff.cuni.cz>
    Link: http://lkml.kernel.org/r/alpine.LRH.2.02.1401241639100.23871@file01.intranet.prod.int.rdu2.redhat.com
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3bf3519dc494280350278693b4e2cdc6f43438b7
Author: Wolfram Sang <wsa@the-dreams.de>
Date:   Thu Feb 13 21:36:29 2014 +0100

    i2c: mv64xxx: refactor message start to ensure proper initialization
    
    commit 79970db213344b4a4034645db5ebfc31571f3fa3 upstream.
    
    Because the offload mechanism can fall back to a standard transfer,
    having two seperate initialization states is unfortunate. Let's just
    have one state which does things consistently. This fixes a bug where
    some preparation was missing when the fallback happened. And it makes
    the code much easier to follow. To implement this, we put the check
    if offload is possible at the top of the offload setup function.
    
    Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
    Tested-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
    Fixes: 930ab3d403ae (i2c: mv64xxx: Add I2C Transaction Generator support)
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2d470eab8a6136e063773be8c28794336c1055b8
Author: Oleg Nesterov <oleg@redhat.com>
Date:   Thu Feb 6 03:42:45 2014 +0530

    md/raid5: Fix CPU hotplug callback registration
    
    commit 789b5e0315284463617e106baad360cb9e8db3ac upstream.
    
    Subsystems that want to register CPU hotplug callbacks, as well as perform
    initialization for the CPUs that are already online, often do it as shown
    below:
    
    	get_online_cpus();
    
    	for_each_online_cpu(cpu)
    		init_cpu(cpu);
    
    	register_cpu_notifier(&foobar_cpu_notifier);
    
    	put_online_cpus();
    
    This is wrong, since it is prone to ABBA deadlocks involving the
    cpu_add_remove_lock and the cpu_hotplug.lock (when running concurrently
    with CPU hotplug operations).
    
    Interestingly, the raid5 code can actually prevent double initialization and
    hence can use the following simplified form of callback registration:
    
    	register_cpu_notifier(&foobar_cpu_notifier);
    
    	get_online_cpus();
    
    	for_each_online_cpu(cpu)
    		init_cpu(cpu);
    
    	put_online_cpus();
    
    A hotplug operation that occurs between registering the notifier and calling
    get_online_cpus(), won't disrupt anything, because the code takes care to
    perform the memory allocations only once.
    
    So reorganize the code in raid5 this way to fix the deadlock with callback
    registration.
    
    Cc: linux-raid@vger.kernel.org
    Fixes: 36d1c6476be51101778882897b315bd928c8c7b5
    Signed-off-by: Oleg Nesterov <oleg@redhat.com>
    [Srivatsa: Fixed the unregister_cpu_notifier() deadlock, added the
    free_scratch_buffer() helper to condense code further and wrote the changelog.]
    Signed-off-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
    Signed-off-by: NeilBrown <neilb@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 93bc05512d3f7bb51e1d0631be065099292708f2
Author: NeilBrown <neilb@suse.de>
Date:   Wed Feb 5 12:17:01 2014 +1100

    md/raid1: restore ability for check and repair to fix read errors.
    
    commit 1877db75589a895bbdc4c4c3f23558e57b521141 upstream.
    
    commit 30bc9b53878a9921b02e3b5bc4283ac1c6de102a
        md/raid1: fix bio handling problems in process_checks()
    
    Move the bio_reset() to a point before where BIO_UPTODATE is checked,
    so that check now always report that the bio is uptodate, even if it is not.
    
    This causes process_check() to sometimes treat read-errors as
    successful matches so the good data isn't written out.
    
    This patch preserves the flag until it is needed.
    
    Bug was introduced in 3.11, but backported to 3.10-stable (as it fixed
    an even worse bug).  So suitable for any -stable since 3.10.
    
    Reported-and-tested-by: Michael Tokarev <mjt@tls.msk.ru>
    Fixed: 30bc9b53878a9921b02e3b5bc4283ac1c6de102a
    Signed-off-by: NeilBrown <neilb@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fb4251e444b1cb99969952d9e5c040f40d2935bc
Author: Thomas Gleixner <tglx@linutronix.de>
Date:   Tue Feb 11 14:35:40 2014 +0100

    tick: Clear broadcast pending bit when switching to oneshot
    
    commit dd5fd9b91a77b4c9c28b7ef9c181b1a875820d0a upstream.
    
    AMD systems which use the C1E workaround in the amd_e400_idle routine
    trigger the WARN_ON_ONCE in the broadcast code when onlining a CPU.
    
    The reason is that the idle routine of those AMD systems switches the
    cpu into forced broadcast mode early on before the newly brought up
    CPU can switch over to high resolution / NOHZ mode. The timer related
    CPU1 bringup looks like this:
    
      clockevent_register_device(local_apic);
      tick_setup(local_apic);
      ...
      idle()
    	tick_broadcast_on_off(FORCE);
    	tick_broadcast_oneshot_control(ENTER)
    	  cpumask_set(cpu, broadcast_oneshot_mask);
    	halt();
    
    Now the broadcast interrupt on CPU0 sets CPU1 in the
    broadcast_pending_mask and wakes CPU1. So CPU1 continues:
    
    	local_apic_timer_interrupt()
    	   tick_handle_periodic();
    	   softirq()
    	     tick_init_highres();
    	       cpumask_clr(cpu, broadcast_oneshot_mask);
    
    	tick_broadcast_oneshot_control(ENTER)
    	   WARN_ON(cpumask_test(cpu, broadcast_pending_mask);
    
    So while we remove CPU1 from the broadcast_oneshot_mask when we switch
    over to highres mode, we do not clear the pending bit, which then
    triggers the warning when we go back to idle.
    
    The reason why this is only visible on C1E affected AMD systems is
    that the other machines enter the deep sleep states via
    acpi_idle/intel_idle and exit the broadcast mode before executing the
    remote triggered local_apic_timer_interrupt. So the pending bit is
    already cleared when the switch over to highres mode is clearing the
    oneshot mask.
    
    The solution is simple: Clear the pending bit together with the mask
    bit when we switch over to highres mode.
    
    Stanislaw came up independently with the same patch by enforcing the
    C1E workaround and debugging the fallout. I picked mine, because mine
    has a changelog :)
    
    Reported-by: poma <pomidorabelisima@gmail.com>
    Debugged-by: Stanislaw Gruszka <sgruszka@redhat.com>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Cc: Olaf Hering <olaf@aepfle.de>
    Cc: Dave Jones <davej@redhat.com>
    Cc: Justin M. Forbes <jforbes@redhat.com>
    Cc: Josh Boyer <jwboyer@redhat.com>
    Link: http://lkml.kernel.org/r/alpine.DEB.2.02.1402111434180.21991@ionos.tec.linutronix.de
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3f77ba3387bd35cac3e3c0e3807b44b9262937b7
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Wed Jan 29 16:16:39 2014 +0300

    KVM: return an error code in kvm_vm_ioctl_register_coalesced_mmio()
    
    commit aac5c4226e7136c331ed384c25d5560204da10a0 upstream.
    
    If kvm_io_bus_register_dev() fails then it returns success but it should
    return an error code.
    
    I also did a little cleanup like removing an impossible NULL test.
    
    Fixes: 2b3c246a682c ('KVM: Make coalesced mmio use a device per zone')
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 309c25722e0880a98d950da657ca395860b67586
Author: Mike Marciniszyn <mike.marciniszyn@intel.com>
Date:   Wed Feb 12 11:54:15 2014 -0500

    IB/qib: Add missing serdes init sequence
    
    commit 2f75e12c4457a9b3d042c0a0d748fa198dc2ffaf upstream.
    
    Research has shown that commit a77fcf895046 ("IB/qib: Use a single
    txselect module parameter for serdes tuning") missed a key serdes init
    sequence.
    
    This patch add that sequence.
    
    Reviewed-by: Dennis Dalessandro <dennis.dalessandro@intel.com>
    Signed-off-by: Mike Marciniszyn <mike.marciniszyn@intel.com>
    Signed-off-by: Roland Dreier <roland@purestorage.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a6ad68bc9fd3159cfb3495d4f96b2d20bb625fad
Author: Steven Noonan <steven@uplinklabs.net>
Date:   Wed Feb 12 23:01:07 2014 -0800

    compiler/gcc4: Make quirk for asm_volatile_goto() unconditional
    
    commit a9f180345f5378ac87d80ed0bea55ba421d83859 upstream.
    
    I started noticing problems with KVM guest destruction on Linux
    3.12+, where guest memory wasn't being cleaned up. I bisected it
    down to the commit introducing the new 'asm goto'-based atomics,
    and found this quirk was later applied to those.
    
    Unfortunately, even with GCC 4.8.2 (which ostensibly fixed the
    known 'asm goto' bug) I am still getting some kind of
    miscompilation. If I enable the asm_volatile_goto quirk for my
    compiler, KVM guests are destroyed correctly and the memory is
    cleaned up.
    
    So make the quirk unconditional for now, until bug is found
    and fixed.
    
    Suggested-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Steven Noonan <steven@uplinklabs.net>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Steven Rostedt <rostedt@goodmis.org>
    Cc: Jakub Jelinek <jakub@redhat.com>
    Cc: Richard Henderson <rth@twiddle.net>
    Cc: Andrew Morton <akpm@linux-foundation.org>
    Cc: Oleg Nesterov <oleg@redhat.com>
    Link: http://lkml.kernel.org/r/1392274867-15236-1-git-send-email-steven@uplinklabs.net
    Link: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58670
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1f25819485fdaee53cc5b8ec96a44a440a63cf46
Author: Mika Westerberg <mika.westerberg@linux.intel.com>
Date:   Tue Feb 11 12:42:37 2014 +0200

    ACPI / hotplug / PCI: Relax the checking of _STA return values
    
    commit 7282059489868e0ed1b0d79765730c6b233a8399 upstream.
    
    The ACPI specification (ACPI 5.0A, Section 6.3.7) says:
    
     _STA may return bit 0 clear (not present) with bit 3 set (device is
     functional). This case is used to indicate a valid device for which
     no device driver should be loaded (for example, a bridge device.)
     Children of this device may be present and valid. OSPM should
     continue enumeration below a device whose _STA returns this bit
     combination.
    
    Evidently, some BIOSes follow that and return 0x0A from _STA, which
    causes problems to happen when they trigger bus check or device check
    notifications for those devices too.  Namely, ACPIPHP thinks that they
    are gone and may drop them, for example, if such a notification is
    triggered during a resume from system suspend.
    
    To fix that, modify ACPICA to regard devies as present and
    functioning if _STA returns both the ACPI_STA_DEVICE_ENABLED
    and ACPI_STA_DEVICE_FUNCTIONING bits set for them.
    
    Reported-and-tested-by: Peter Wu <lekensteyn@gmail.com>
    [rjw: Subject and changelog, minor code modifications]
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 50f9027cd5e959f1f14777c4c3dccf91fc0b8fc0
Author: Jens Axboe <axboe@fb.com>
Date:   Wed Feb 12 09:34:01 2014 -0700

    block: add cond_resched() to potentially long running ioctl discard loop
    
    commit c8123f8c9cb517403b51aa41c3c46ff5e10b2c17 upstream.
    
    When mkfs issues a full device discard and the device only
    supports discards of a smallish size, we can loop in
    blkdev_issue_discard() for a long time. If preempt isn't enabled,
    this can turn into a softlock situation and the kernel will
    start complaining.
    
    Add an explicit cond_resched() at the end of the loop to avoid
    that.
    
    Signed-off-by: Jens Axboe <axboe@fb.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e028fddcb873c16722b44e6bcab14aa56500e9d9
Author: Martin K. Petersen <martin.petersen@oracle.com>
Date:   Thu Feb 6 15:14:13 2014 -0500

    block: Fix nr_vecs for inline integrity vectors
    
    commit 087787959ce851d7bbb19f10f6e9241b7f85a3ca upstream.
    
    Commit 9f060e2231ca changed the way we handle allocations for the
    integrity vectors. When the vectors are inline there is no associated
    slab and consequently bvec_nr_vecs() returns 0. Ensure that we check
    against BIP_INLINE_VECS in that case.
    
    Reported-by: David Milburn <dmilburn@redhat.com>
    Tested-by: David Milburn <dmilburn@redhat.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Jens Axboe <axboe@fb.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b98625aa1d9394316eca6ef099e4cd7c8b404c58
Author: Tejun Heo <tj@kernel.org>
Date:   Wed Jan 29 14:56:16 2014 -0700

    block: __elv_next_request() shouldn't call into the elevator if bypassing
    
    commit 556ee818c06f37b2e583af0363e6b16d0e0270de upstream.
    
    request_queue bypassing is used to suppress higher-level function of a
    request_queue so that they can be switched, reconfigured and shut
    down.  A request_queue does the followings while bypassing.
    
    * bypasses elevator and io_cq association and queues requests directly
      to the FIFO dispatch queue.
    
    * bypasses block cgroup request_list lookup and always uses the root
      request_list.
    
    Once confirmed to be bypassing, specific elevator and block cgroup
    policy implementations can assume that nothing is in flight for them
    and perform various operations which would be dangerous otherwise.
    
    Such confirmation is acheived by short-circuiting all new requests
    directly to the dispatch queue and waiting for all the requests which
    were issued before to finish.  Unfortunately, while the request
    allocating and draining sides were properly handled, we forgot to
    actually plug the request dispatch path.  Even after bypassing mode is
    confirmed, if the attached driver tries to fetch a request and the
    dispatch queue is empty, __elv_next_request() would invoke the current
    elevator's elevator_dispatch_fn() callback.  As all in-flight requests
    were drained, the elevator wouldn't contain any request but once
    bypass is confirmed we don't even know whether the elevator is even
    there.  It might be in the process of being switched and half torn
    down.
    
    Frank Mayhar reports that this actually happened while switching
    elevators, leading to an oops.
    
    Let's fix it by making __elv_next_request() avoid invoking the
    elevator_dispatch_fn() callback if the queue is bypassing.  It already
    avoids invoking the callback if the queue is dying.  As a dying queue
    is guaranteed to be bypassing, we can simply replace blk_queue_dying()
    check with blk_queue_bypass().
    
    Reported-by: Frank Mayhar <fmayhar@google.com>
    References: http://lkml.kernel.org/g/1390319905.20232.38.camel@bobble.lax.corp.google.com
    Tested-by: Frank Mayhar <fmayhar@google.com>
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f3affbef5aac603a1a691a0b308d180748f74e30
Author: Jan Moskyto Matejka <mq@suse.cz>
Date:   Fri Feb 7 19:15:11 2014 +0100

    Modpost: fixed USB alias generation for ranges including 0x9 and 0xA
    
    commit 03b56329f9bb5a1cb73d7dc659d529a9a9bf3acc upstream.
    
    Commit afe2dab4f6 ("USB: add hex/bcd detection to usb modalias generation")
    changed the routine that generates alias ranges. Before that change, only
    digits 0-9 were supported; the commit tried to fix the case when the range
    includes higher values than 0x9.
    
    Unfortunately, the commit didn't fix the case when the range includes both
    0x9 and 0xA, meaning that the final range must look like [x-9A-y] where
    x <= 0x9 and y >= 0xA -- instead the [x-9A-x] range was produced.
    
    Modprobe doesn't complain as it sees no difference between no-match and
    bad-pattern results of fnmatch().
    
    Fixing this simple bug to fix the aliases.
    Also changing the hardcoded beginning of the range to uppercase as all the
    other letters are also uppercase in the device version numbers.
    
    Fortunately, this affects only the dvb-usb-dib0700 module, AFAIK.
    
    Signed-off-by: Jan Moskyto Matejka <mq@suse.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit bda2443499975f730bef75971396c7da0c6bab4c
Author: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Date:   Wed Jan 22 13:35:02 2014 -0800

    Revert "usbcore: set lpm_capable field for LPM capable root hubs"
    
    commit 140e3026a57ab7d830dab2f2c57796c222db0ea9 upstream.
    
    Commit 9df89d85b407690afa46ddfbccc80bec6869971d "usbcore: set
    lpm_capable field for LPM capable root hubs" was created under the
    assumption that all USB host controllers should have USB 3.0 Link PM
    enabled for all devices under the hosts.
    
    Unfortunately, that's not the case.  The xHCI driver relies on knowledge
    of the host hardware scheduler to calculate the LPM U1/U2 timeout
    values, and it only sets lpm_capable to one for Intel host controllers
    (that have the XHCI_LPM_SUPPORT quirk set).
    
    When LPM is enabled for some Fresco Logic hosts, it causes failures with
    a AgeStar 3UBT USB 3.0 hard drive dock:
    
    Jan 11 13:59:03 sg-laptop kernel: usb 3-1: new SuperSpeed USB device number 2 using xhci_hcd
    Jan 11 13:59:03 sg-laptop kernel: usb 3-1: Set SEL for device-initiated U1 failed.
    Jan 11 13:59:08 sg-laptop kernel: usb 3-1: Set SEL for device-initiated U2 failed.
    Jan 11 13:59:08 sg-laptop kernel: usb-storage 3-1:1.0: USB Mass Storage device detected
    Jan 11 13:59:08 sg-laptop mtp-probe[613]: checking bus 3, device 2: "/sys/devices/pci0000:00/0000:00:1c.3/0000:04:00.0/usb3/3-1"
    Jan 11 13:59:08 sg-laptop mtp-probe[613]: bus: 3, device: 2 was not an MTP device
    Jan 11 13:59:08 sg-laptop kernel: scsi6 : usb-storage 3-1:1.0
    Jan 11 13:59:13 sg-laptop kernel: usb 3-1: Set SEL for device-initiated U1 failed.
    Jan 11 13:59:18 sg-laptop kernel: usb 3-1: Set SEL for device-initiated U2 failed.
    Jan 11 13:59:18 sg-laptop kernel: usbcore: registered new interface driver usb-storage
    Jan 11 13:59:40 sg-laptop kernel: usb 3-1: reset SuperSpeed USB device number 2 using xhci_hcd
    Jan 11 13:59:41 sg-laptop kernel: usb 3-1: device descriptor read/8, error -71
    Jan 11 13:59:41 sg-laptop kernel: usb 3-1: reset SuperSpeed USB device number 2 using xhci_hcd
    Jan 11 13:59:46 sg-laptop kernel: usb 3-1: device descriptor read/8, error -110
    Jan 11 13:59:46 sg-laptop kernel: scsi 6:0:0:0: Device offlined - not ready after error recovery
    Jan 11 13:59:46 sg-laptop kernel: usb 3-1: USB disconnect, device number 2
    
    lspci for the affected host:
    
    04:00.0 0c03: 1b73:1000 (rev 04) (prog-if 30 [XHCI])
            Subsystem: 1043:1039
            Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
            Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
            Latency: 0, Cache Line Size: 64 bytes
            Interrupt: pin A routed to IRQ 19
            Region 0: Memory at dd200000 (32-bit, non-prefetchable) [size=64K]
            Capabilities: [50] Power Management version 3
                    Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold-)
                    Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
            Capabilities: [68] MSI: Enable- Count=1/1 Maskable- 64bit+
                    Address: 0000000000000000  Data: 0000
            Capabilities: [80] Express (v1) Endpoint, MSI 00
                    DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s <2us, L1 <32us
                            ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset-
                    DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
                            RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+
                            MaxPayload 128 bytes, MaxReadReq 512 bytes
                    DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- TransPend-
                    LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s L1, Latency L0 unlimited, L1 unlimited
                            ClockPM- Surprise- LLActRep- BwNot-
                    LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk+
                            ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
                    LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
            Kernel driver in use: xhci_hcd
            Kernel modules: xhci_hcd
    
    The commit was backported to stable kernels, and will need to be
    reverted there as well.
    
    Signed-off-by: Sarah Sharp <sarah.a.sharp@intel.com>
    Reported-by: Sergey Galanov <sergey.e.galanov@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit aad850bd0d8be9038f887bae8b76ac81da6ddd2a
Author: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Date:   Fri Jan 31 11:52:57 2014 -0800

    Revert "usb: xhci: Link TRB must not occur within a USB payload burst"
    
    commit 3d4b81eda2211f32886e2978daf6f39885042fc4 upstream.
    
    This reverts commit 35773dac5f862cb1c82ea151eba3e2f6de51ec3e.  It's a
    hack that caused regressions in the usb-storage and userspace USB
    drivers that use usbfs and libusb.  Commit 70cabb7d992f "xhci 1.0: Limit
    arbitrarily-aligned scatter gather." should fix the issues seen with the
    ax88179_178a driver on xHCI 1.0 hosts, without causing regressions.
    
    Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f47a7fb0a06f44707d416b752508d79ce59575e5
Author: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Date:   Fri Jan 31 11:51:59 2014 -0800

    Revert "xhci: Avoid infinite loop when sg urb requires too many trbs"
    
    commit 9cf00d91708221ff2d8a11143315f7ebab8d5da8 upstream.
    
    This reverts commit d6c9ea9069af684358efedcaf2f2f687f51c58ee.
    
    We are ripping out commit 35773dac5f862cb1c82ea151eba3e2f6de51ec3e "usb:
    xhci: Link TRB must not occur within a USB payload burst" because it's a
    hack that caused regressions in the usb-storage and userspace USB
    drivers that use usbfs and libusb.  This commit attempted to fix the
    issues with that patch.
    
    Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 563f01094b4a1b860521b156f233d7292a7b9d57
Author: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Date:   Fri Jan 31 11:45:02 2014 -0800

    Revert "xhci: Set scatter-gather limit to avoid failed block writes."
    
    commit 1386ff75797a187df324062fb4e929152392da88 upstream.
    
    This reverts commit f2d9b991c549f159dc9ae81f77d8206c790cbfee.
    
    We are ripping out commit 35773dac5f862cb1c82ea151eba3e2f6de51ec3e "usb:
    xhci: Link TRB must not occur within a USB payload burst" because it's a
    hack that caused regressions in the usb-storage and userspace USB
    drivers that use usbfs and libusb.  This commit attempted to fix the
    issues with that patch.
    
    Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d6472e8a66fb882548361ddbf96de6db00f3c2b3
Author: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Date:   Fri Jan 31 11:26:25 2014 -0800

    xhci 1.0: Limit arbitrarily-aligned scatter gather.
    
    commit 247bf557273dd775505fb9240d2d152f4f20d304 upstream.
    
    xHCI 1.0 hosts have a set of requirements on how to align transfer
    buffers on the endpoint rings called "TD fragment" rules.  When the
    ax88179_178a driver added support for scatter gather in 3.12, with
    commit 804fad45411b48233b48003e33a78f290d227c8 "USBNET: ax88179_178a:
    enable tso if usb host supports sg dma", it broke the device under xHCI
    1.0 hosts.  Under certain network loads, the device would see an
    unexpected short packet from the host, which would cause the device to
    stop sending ethernet packets, even through USB packets would still be
    sent.
    
    Commit 35773dac5f86 "usb: xhci: Link TRB must not occur within a USB
    payload burst" attempted to fix this.  It was a quick hack to partially
    implement the TD fragment rules.  However, it caused regressions in the
    usb-storage layer and userspace USB drivers using libusb.  The patches
    to attempt to fix this are too far reaching into the USB core, and we
    really need to implement the TD fragment rules correctly in the xHCI
    driver, instead of continuing to wallpaper over the issues.
    
    Disable arbitrarily-aligned scatter-gather in the xHCI driver for 1.0
    hosts.  Only the ax88179_178a driver checks the no_sg_constraint flag,
    so don't set it for 1.0 hosts.  This should not impact usb-storage or
    usbfs behavior, since they pass down max packet sized aligned sg-list
    entries (512 for USB 2.0 and 1024 for USB 3.0).
    
    Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
    Tested-by: Mark Lord <mlord@pobox.com>
    Cc: David Laight <David.Laight@ACULAB.COM>
    Cc: Bjørn Mork <bjorn@mork.no>
    Cc: Freddy Xin <freddy@asix.com.tw>
    Cc: Ming Lei <ming.lei@canonical.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f72d5bdddc617fba8057cc898cb146efac588c34
Author: Kristóf Ralovich <kristof.ralovich@gmail.com>
Date:   Fri Jan 24 12:18:35 2014 +0100

    USB: simple: add Dynastream ANT USB-m Stick device support
    
    commit 2240c365108adbc4100a55654a5707e8e877a401 upstream.
    
    Add support for ANT USB-m Stick from Dynastream Innovations, by listing
    USB pid
    
    [34366.944805] usb 6-1: New USB device found, idVendor=0fcf, idProduct=1009
    [34366.944817] usb 6-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
    [34366.944824] usb 6-1: Product: ANT USB-m Stick
    [34366.944831] usb 6-1: Manufacturer: Dynastream Innovations
    
    Device reported (https://code.google.com/p/antpm/issues/detail?id=5) to
    work through:
    $ modprobe usbserial vendor=0x0fcf product=0x1009
    
    Signed-off-by: Kristóf Ralovich <kristof.ralovich@gmail.com>
    Signed-off-by: Johan Hovold <jhovold@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2a4183d252c53afa060ba8416303bd9a09a394be
Author: Raymond Wanyoike <raymond.wanyoike@gmail.com>
Date:   Sun Feb 9 11:59:46 2014 +0300

    usb: option: blacklist ZTE MF667 net interface
    
    commit 3635c7e2d59f7861afa6fa5e87e2a58860ff514d upstream.
    
    Interface #5 of 19d2:1270 is a net interface which has been submitted to the
    qmi_wwan driver so consequently remove it from the option driver.
    
    Signed-off-by: Raymond Wanyoike <raymond.wanyoike@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit dc73eb45fbcb06a93b71d5d88bc8eff42c20804a
Author: Alan Stern <stern@rowland.harvard.edu>
Date:   Thu Jan 30 10:43:22 2014 -0500

    usb-storage: enable multi-LUN scanning when needed
    
    commit 823d12c95c666fa7ab7dad208d735f6bc6afabdc upstream.
    
    People sometimes create their own custom-configured kernels and forget
    to enable CONFIG_SCSI_MULTI_LUN.  This causes problems when they plug
    in a USB storage device (such as a card reader) with more than one
    LUN.
    
    Fortunately, we can tell fairly easily when a storage device claims to
    have more than one LUN.  When that happens, this patch asks the SCSI
    layer to probe all the LUNs automatically, regardless of the config
    setting.
    
    The patch also updates the Kconfig help text for usb-storage,
    explaining that CONFIG_SCSI_MULTI_LUN may be necessary.
    
    Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
    Reported-by: Thomas Raschbacher <lordvan@lordvan.com>
    CC: Matthew Dharm <mdharm-usb@one-eyed-alien.net>
    CC: James Bottomley <James.Bottomley@HansenPartnership.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4c43e4acd66456f5da9b3365eaf7de6c793c8567
Author: Alan Stern <stern@rowland.harvard.edu>
Date:   Thu Jan 30 10:20:29 2014 -0500

    usb-storage: restrict bcdDevice range for Super Top in Cypress ATACB
    
    commit a9c143c82608bee2a36410caa56d82cd86bdc7fa upstream.
    
    The Cypress ATACB unusual-devs entry for the Super Top SATA bridge
    causes problems.  Although it was originally reported only for
    bcdDevice = 0x160, its range was much larger.  This resulted in a bug
    report for bcdDevice 0x220, so the range was capped at 0x219.  Now
    Milan reports errors with bcdDevice 0x150.
    
    Therefore this patch restricts the range to just 0x160.
    
    Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
    Reported-and-tested-by: Milan Svoboda <milan.svoboda@centrum.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 52c95efe90fdd5fc754f2dc51b9fead2a36a175f
Author: Alan Stern <stern@rowland.harvard.edu>
Date:   Tue Jan 21 10:38:45 2014 -0500

    usb-storage: add unusual-devs entry for BlackBerry 9000
    
    commit c5637e5119c43452a00e27c274356b072263ecbb upstream.
    
    This patch adds an unusual-devs entry for the BlackBerry 9000.  This
    fixes Bugzilla #22442.
    
    Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
    Reported-by: Moritz Moeller-Herrmann <moritz-kernel@moeller-herrmann.de>
    Tested-by: Moritz Moeller-Herrmann <moritz-kernel@moeller-herrmann.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ee01689df1bcc12b0be610adaad37d3472acf3e9
Author: Ulrich Hahn <uhahn@eanco.de>
Date:   Sun Feb 2 14:42:52 2014 +0100

    USB: ftdi_sio: add Tagsys RFID Reader IDs
    
    commit 76f24e3f39a1a94bab0d54e98899d64abcd9f69c upstream.
    
    Adding two more IDs to the ftdi_sio usb serial driver.
    It now connects Tagsys RFID readers.
    There might be more IDs out there for other Tagsys models.
    
    Signed-off-by: Ulrich Hahn <uhahn@eanco.de>
    Cc: Johan Hovold <johan@hovold.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 821059049a21209c268534f8816e17a60087c7b2
Author: Bjørn Mork <bjorn@mork.no>
Date:   Tue Jan 14 18:56:54 2014 +0100

    usb: ftdi_sio: add Mindstorms EV3 console adapter
    
    commit 67847baee056892dc35efb9c3fd05ae7f075588c upstream.
    
    Signed-off-by: Bjørn Mork <bjorn@mork.no>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 261fae784b3281ee2679a7a49738c609eb997aa8
Author: K. Y. Srinivasan <kys@microsoft.com>
Date:   Thu Jan 16 11:59:58 2014 -0800

    Drivers: hv: vmbus: Don't timeout during the initial connection with host
    
    commit 269f979467cf49f2ea8132316c1f00f8c9678f7c upstream.
    
    When the guest attempts to connect with the host when there may already be a
    connection with the host (as would be the case during the kdump/kexec path),
    it is difficult to guarantee timely response from the host. Starting with
    WS2012 R2, the host supports this ability to re-connect with the host
    (explicitly to support kexec). Prior to responding to the guest, the host
    needs to ensure that device states based on the previous connection to
    the host have been properly torn down. This may introduce unbounded delays.
    To deal with this issue, don't do a timed wait during the initial connect
    with the host.
    
    Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 83d0c11c30091dac57f76692c46e65e8a0aadedb
Author: Martyn Welch <martyn.welch@ge.com>
Date:   Fri Feb 7 15:48:56 2014 +0000

    VME: Correct read/write alignment algorithm
    
    commit f0342e66b397947ed8c3eef8c37b5ca2d5b1bb50 upstream.
    
    In order to ensure the correct width cycles on the VME bus, the VME bridge
    drivers implement an algorithm to utilise the largest possible width reads and
    writes whilst maintaining natural alignment constraints. The algorithm
    currently looks at the start address rather than the current read/write address
    when determining whether a 16-bit width cycle is required to get to 32-bit
    alignment.  This results in incorrect alignment,
    
    Reported-by: Jim Strouth <james.strouth@ge.com>
    Tested-by: Jim Strouth <james.strouth@ge.com>
    Signed-off-by: Martyn Welch <martyn.welch@ge.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1a1d81ccf47de68b59c798cb7448e655a59372bc
Author: Alexander Usyskin <alexander.usyskin@intel.com>
Date:   Mon Jan 27 22:27:24 2014 +0200

    mei: don't unset read cb ptr on reset
    
    commit 5cb906c7035f03a3a44fecece9d3ff8fcc75d6e0 upstream.
    
    Don't set read callback to NULL during reset as
    this leads to memory leak of both cb and its buffer.
    The memory is correctly freed during mei_release.
    
    The memory leak is detectable by kmemleak if
    application has open read call while system is going through
    suspend/resume.
    
    unreferenced object 0xecead780 (size 64):
      comm "AsyncTask #1", pid 1018, jiffies 4294949621 (age 152.440s)
      hex dump (first 32 bytes):
        00 01 10 00 00 02 20 00 00 bf 30 f1 00 00 00 00  ...... ...0.....
        00 00 00 00 00 00 00 00 36 01 00 00 00 70 da e2  ........6....p..
      backtrace:
        [<c1a60aec>] kmemleak_alloc+0x3c/0xa0
        [<c131ed56>] kmem_cache_alloc_trace+0xc6/0x190
        [<c16243c9>] mei_io_cb_init+0x29/0x50
        [<c1625722>] mei_cl_read_start+0x102/0x360
        [<c16268f3>] mei_read+0x103/0x4e0
        [<c1324b09>] vfs_read+0x89/0x160
        [<c1324d5f>] SyS_read+0x4f/0x80
        [<c1a7b318>] syscall_call+0x7/0xb
        [<ffffffff>] 0xffffffff
    unreferenced object 0xe2da7000 (size 512):
      comm "AsyncTask #1", pid 1018, jiffies 4294949621 (age 152.440s)
      hex dump (first 32 bytes):
        00 6c da e2 7c 00 00 00 00 00 00 00 c0 eb 0c 59  .l..|..........Y
        1b 00 00 00 01 00 00 00 02 10 00 00 01 00 00 00  ................
      backtrace:
        [<c1a60aec>] kmemleak_alloc+0x3c/0xa0
        [<c131f127>] __kmalloc+0xe7/0x1d0
        [<c162447e>] mei_io_cb_alloc_resp_buf+0x2e/0x60
        [<c162574c>] mei_cl_read_start+0x12c/0x360
        [<c16268f3>] mei_read+0x103/0x4e0
        [<c1324b09>] vfs_read+0x89/0x160
        [<c1324d5f>] SyS_read+0x4f/0x80
        [<c1a7b318>] syscall_call+0x7/0xb
        [<ffffffff>] 0xffffffff
    
    Signed-off-by: Alexander Usyskin <alexander.usyskin@intel.com>
    Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit cb2a6e8a6e423b1424fdd792640943a53a3d70f3
Author: Alexander Usyskin <alexander.usyskin@intel.com>
Date:   Mon Jan 27 22:27:23 2014 +0200

    mei: clear write cb from waiting list on reset
    
    commit 30c54df7cb9b15b222529a028390b9c9582dd65e upstream.
    
    Clear write callbacks sitting in write_waiting list on reset.
    Otherwise these callbacks are left dangling and cause memory leak.
    
    Signed-off-by: Alexander Usyskin <alexander.usyskin@intel.com>
    Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 92cf5e3789ac4f7ee72029b4df1451966a83a43c
Author: Takashi Iwai <tiwai@suse.de>
Date:   Fri Feb 7 12:07:59 2014 +0100

    ALSA: hda - Fix mic capture on Sony VAIO Pro 11
    
    commit f88abaa0d0dc0d1f1a9ae21f8e822918e5aadfdf upstream.
    
    The very same fixup is needed to make the mic on Sony VAIO Pro 11
    working as well as VAIO Pro 13 model.
    
    Reported-and-tested-by: Hendrik-Jan Heins <hjheins@gmail.com>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9b4d54ac4276d7988e92ed7a3853ae08931f07aa
Author: Steven Rostedt (Red Hat) <rostedt@goodmis.org>
Date:   Tue Feb 11 20:19:44 2014 -0500

    ftrace/x86: Use breakpoints for converting function graph caller
    
    commit 87fbb2ac6073a7039303517546a76074feb14c84 upstream.
    
    When the conversion was made to remove stop machine and use the breakpoint
    logic instead, the modification of the function graph caller is still
    done directly as though it was being done under stop machine.
    
    As it is not converted via stop machine anymore, there is a possibility
    that the code could be layed across cache lines and if another CPU is
    accessing that function graph call when it is being updated, it could
    cause a General Protection Fault.
    
    Convert the update of the function graph caller to use the breakpoint
    method as well.
    
    Cc: H. Peter Anvin <hpa@zytor.com>
    Fixes: 08d636b6d4fb "ftrace/x86: Have arch x86_64 use breakpoints instead of stop machine"
    Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c9eb176b7135ee278c71e80722ffffdc261d6dfe
Author: H. Peter Anvin <hpa@linux.intel.com>
Date:   Thu Feb 13 07:46:04 2014 -0800

    x86, smap: smap_violation() is bogus if CONFIG_X86_SMAP is off
    
    commit 4640c7ee9b8953237d05a61ea3ea93981d1bc961 upstream.
    
    If CONFIG_X86_SMAP is disabled, smap_violation() tests for conditions
    which are incorrect (as the AC flag doesn't matter), causing spurious
    faults.
    
    The dynamic disabling of SMAP (nosmap on the command line) is fine
    because it disables X86_FEATURE_SMAP, therefore causing the
    static_cpu_has() to return false.
    
    Found by Fengguang Wu's test system.
    
    [ v3: move all predicates into smap_violation() ]
    [ v2: use IS_ENABLED() instead of #ifdef ]
    
    Reported-by: Fengguang Wu <fengguang.wu@intel.com>
    Link: http://lkml.kernel.org/r/20140213124550.GA30497@localhost
    Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b59b02d5ca3daad846815aba98f017bc8fdcc907
Author: H. Peter Anvin <hpa@linux.intel.com>
Date:   Thu Feb 13 07:34:30 2014 -0800

    x86, smap: Don't enable SMAP if CONFIG_X86_SMAP is disabled
    
    commit 03bbd596ac04fef47ce93a730b8f086d797c3021 upstream.
    
    If SMAP support is not compiled into the kernel, don't enable SMAP in
    CR4 -- in fact, we should clear it, because the kernel doesn't contain
    the proper STAC/CLAC instructions for SMAP support.
    
    Found by Fengguang Wu's test system.
    
    Reported-by: Fengguang Wu <fengguang.wu@intel.com>
    Link: http://lkml.kernel.org/r/20140213124550.GA30497@localhost
    Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9b53049a956cb9db81bf268c75b5538c295056c6
Author: Beomho Seo <beomho.seo@samsung.com>
Date:   Wed Apr 2 09:15:00 2014 +0100

    iio: ak8975: Fix calculation formula for convert micro tesla to gauss unit
    
    commit bef44abccb2677e8d16e50b75316d4fd1061be81 upstream.
    
    This effects the reported scale of the raw values, and thus userspace
    applications that use this value.
    
    One micro tesla equal 0.01 gauss. So I have fixed calculation formula And add RAW_TO_GAUSS macro.
    ASA is in the range of 0 to 255. If multiply 0.003, calculation result(in_magn_[*]_scale) is
    always 0. So multiply 3000 and return and IIO_VAL_INT_PLUS_MICRO.
    As a result, read_raw call back function return accurate scale value.
    
    Signed-off-by: Beomho Seo <beomho.seo@samsung.com>
    Signed-off-by: Jonathan Cameron <jic23@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0f543e6a6b01a50b1514ec3f9295aa62488a4bd7
Author: Marcus Folkesson <marcus.folkesson@gmail.com>
Date:   Fri Jan 24 11:24:00 2014 +0000

    iio: adis16400: Set timestamp as the last element in chan_spec
    
    commit c76782d151dab7ecfdcdf9a01561c2d61d9b490f upstream.
    
    This is necessary since timestamp is calculated as the last element
    in iio_compute_scan_bytes().
    
    Without this fix any userspace code reading the layout of the buffer via
    sysfs will incorrectly interpret the data leading some nasty corruption.
    
    Signed-off-by: Marcus Folkesson <marcus.folkesson@gmail.com>
    Acked-by: Lars-Peter Clausen <lars@metafoo.de>
    Signed-off-by: Jonathan Cameron <jic23@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5be594952c283412027639d60bc51116f64fdcbe
Author: Guenter Roeck <linux@roeck-us.net>
Date:   Mon Jan 27 18:10:00 2014 +0000

    iio: max1363: Use devm_regulator_get_optional for optional regulator
    
    commit 55b40d37311807a6bb2acdae0df904f54a0da3ae upstream.
    
    In kernel version 3.13, devm_regulator_get() may return no error
    if a regulator is undeclared. regulator_get_voltage() will return
    -EINVAL if this happens. This causes the driver to fail loading if
    the vref regulator is not declared.
    
    Since vref is optional, call devm_regulator_get_optional instead.
    
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Jonathan Cameron <jic23@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit aee63f4dc12b2f5208c8fcd44185f26422ad6ed9
Author: Hartmut Knaack <knaack.h@gmx.de>
Date:   Wed Jan 1 23:04:00 2014 +0000

    staging:iio:ad799x fix error_free_irq which was freeing an irq that may not have been requested
    
    commit 38408d056188be29a6c4e17f3703c796551bb330 upstream.
    
    Only free an IRQ in error_free_irq, if it has been requested previously.
    
    Signed-off-by: Hartmut Knaack <knaack.h@gmx.de>
    Acked-by: Lars-Peter Clausen <lars@metafoo.de>
    Signed-off-by: Jonathan Cameron <jic23@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit efab4626e2c8867ab669caec1b1be2458ea3a052
Author: H Hartley Sweeten <hsweeten@visionengravers.com>
Date:   Wed Feb 5 14:59:53 2014 -0700

    staging: comedi: adv_pci1710: fix analog output readback value
    
    commit 1e85c1ea1ff2a60659e790ef8ec76c7339445841 upstream.
    
    The last value written to a analog output channel is cached in the
    private data of this driver for readback.
    
    Currently, the wrong value is cached in the (*insn_write) functions.
    The current code stores the data[n] value for readback afer the loop
    has written all the values. At this time 'n' points past the end of
    the data array.
    
    Fix the functions by using a local variable to hold the data being
    written to the analog output channel. This variable is then used
    after the loop is complete to store the readback value. The current
    value is retrieved before the loop in case no values are actually
    written..
    
    Signed-off-by: H Hartley Sweeten <hsweeten@visionengravers.com>
    Reviewed-by: Ian Abbott <abbotti@mev.co.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 398c2614126ad6c247e6a3c596e3dba51273863f
Author: Larry Finger <Larry.Finger@lwfinger.net>
Date:   Sun Feb 2 22:23:06 2014 -0600

    staging: r8188eu: Fix typo in USB_DEVICE list
    
    commit 08951f10ae146d0c4114ac508310ad316b6f8798 upstream.
    
    There is a typo in the device list that interchanges the vendor and
    product codes for one of the entries. This exchange was determined
    by noticing that the vendor code is 0x07b8 for Abocom at
    http://www.linux-usb.org/usb.ids.
    
    Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ad96de0aba42b6b51592f94774aec6186784bf4c
Author: Cédric Dufour <cedric.dufour@idiap.ch>
Date:   Fri Jan 24 20:57:05 2014 +0100

    staging: lustre: fix quotactl permission denied (LU-4530)
    
    commit 8b9e418c013e8b671fc10108ab14243f0657bffd upstream.
    
    The changes introduced in commit 4b1a25f06b30b203 ("fix build when
    CONFIG_UIDGID_STRICT_TYPE_CHECKS is on") got the UID check the wrong way
    around, leading to "Permission denied" when a regular user attempts to
    retrieve his quota (lfs quota -u ...) but allowing him to retrieve other
    users quota.
    
    Full details at: https://jira.hpdd.intel.com/browse/LU-4530
    
    Cc: Peng Tao <tao.peng@emc.com>
    Signed-off-by: Cédric Dufour <cedric.dufour@idiap.ch>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f71d15f0f5c6a2ef55f3424bcaee1e9c467b905e
Author: Bjørn Mork <bjorn@mork.no>
Date:   Tue Feb 4 13:02:31 2014 +0100

    usb: qcserial: add Netgear Aircard 340U
    
    commit f948dcf9e9973c05d957bc65b3185682f45feda3 upstream.
    
    This device was mentioned in an OpenWRT forum.  Seems to have a "standard"
    Sierra Wireless ifnumber to function layout:
     0: qcdm
     2: nmea
     3: modem
     8: qmi
     9: storage
    
    Signed-off-by: Bjørn Mork <bjorn@mork.no>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0f37eca655d4e2dbb7c7432b74fcb1bf446293e9
Author: Petr Písař <petr.pisar@atlas.cz>
Date:   Thu Feb 6 21:01:23 2014 +0100

    vt: Fix secure clear screen
    
    commit 0930b0950a8996aa88b0d2ba4bb2bab27cc36bc7 upstream.
    
    \E[3J console code (secure clear screen) needs to update_screen(vc)
    in order to write-through blanks into off-screen video memory.
    
    This has been removed accidentally in 3.6 by:
    
    commit 81732c3b2fede049a692e58a7ceabb6d18ffb18c
    Author: Jean-François Moine <moinejf@free.fr>
    Date:   Thu Sep 6 19:24:13 2012 +0200
    
        tty vt: Fix line garbage in virtual console on command line edition
    
    Signed-off-by: Petr Písař <petr.pisar@atlas.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7d1489786d4c011215407a63f671d83c830d6ab7
Author: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Date:   Fri Feb 7 17:40:50 2014 +0200

    drm/i915: Pair va_copy with va_end in i915_error_vprintf
    
    commit 1d2cb9a54abc6e1d239f28f07661366d5662a94a upstream.
    
    Each invocation of va_copy() must be matched by a corresponding
    invocation of va_end() in the same function.
    
    This regression has been introduced in
    
    commit e29bb4ebbf000ff9ac081d29784a3331618f012e
    Author: Chris Wilson <chris@chris-wilson.co.uk>
    Date:   Fri Sep 20 10:20:59 2013 +0100
    
        drm/i915: Use a temporary va_list for two-pass string handling
    
    Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
    Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 689e5a435568228702d534a69dac8fd8fcf99ecb
Author: Christian König <christian.koenig@amd.com>
Date:   Thu Jan 30 19:01:16 2014 +0100

    drm/radeon: fix UVD IRQ support on SI
    
    commit b927e1c20462c1ad9caf4c4fa3a30e838a2d4037 upstream.
    
    Otherwise decoding isn't really useable.
    
    bug:
    https://bugs.freedesktop.org/show_bug.cgi?id=71448
    
    Signed-off-by: Christian König <christian.koenig@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5b470dca1f69d9ce3290316272b24a509e284357
Author: Alex Deucher <alexander.deucher@amd.com>
Date:   Thu Jan 30 14:35:04 2014 -0500

    drm/radeon: fix UVD IRQ support on 7xx
    
    commit 858a41c853cef2cb01de34dae334c19c1c15b237 upstream.
    
    Otherwise decoding isn't really useable.
    
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ebcca55846e8c4fda540dcf62b58e2f726e798b8
Author: Lars Poeschel <poeschel@lemonage.de>
Date:   Tue Jan 7 13:34:37 2014 +0100

    tty: n_gsm: Fix for modems with brk in modem status control
    
    commit 3ac06b905655b3ef2fd2196bab36e4587e1e4e4f upstream.
    
    3GPP TS 07.10 states in section 5.4.6.3.7:
    "The length byte contains the value 2 or 3 ... depending on the break
    signal." The break byte is optional and if it is sent, the length is
    3. In fact the driver was not able to work with modems that send this
    break byte in their modem status control message. If the modem just
    sends the break byte if it is really set, then weird things might
    happen.
    The code for deconding the modem status to the internal linux
    presentation in gsm_process_modem has already a big comment about
    this 2 or 3 byte length thing and it is already able to decode the
    brk, but the code calling the gsm_process_modem function in
    gsm_control_modem does not encode it and hand it over the right way.
    This patch fixes this.
    Without this fix if the modem sends the brk byte in it's modem status
    control message the driver will hang when opening a muxed channel.
    
    Signed-off-by: Lars Poeschel <poeschel@lemonage.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 44ff717ceeadf2035504f9eee48f0f14333cae2c
Author: NeilBrown <neilb@suse.de>
Date:   Fri Feb 7 17:10:26 2014 +1100

    lockd: send correct lock when granting a delayed lock.
    
    commit 2ec197db1a56c9269d75e965f14c344b58b2a4f6 upstream.
    
    If an NFS client attempts to get a lock (using NLM) and the lock is
    not available, the server will remember the request and when the lock
    becomes available it will send a GRANT request to the client to
    provide the lock.
    
    If the client already held an adjacent lock, the GRANT callback will
    report the union of the existing and new locks, which can confuse the
    client.
    
    This happens because __posix_lock_file (called by vfs_lock_file)
    updates the passed-in file_lock structure when adjacent or
    over-lapping locks are found.
    
    To avoid this problem we take a copy of the two fields that can
    be changed (fl_start and fl_end) before the call and restore them
    afterwards.
    An alternate would be to allocate a 'struct file_lock', initialise it,
    use locks_copy_lock() to take a copy, then locks_release_private()
    after the vfs_lock_file() call.  But that is a lot more work.
    
    Reported-by: Olaf Kirch <okir@suse.com>
    Signed-off-by: NeilBrown <neilb@suse.de>
    Signed-off-by: J. Bruce Fields <bfields@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    
    --
    v1 had a couple of issues (large on-stack struct and didn't really work properly).
    This version is much better tested.
    Signed-off-by: J. Bruce Fields <bfields@redhat.com>

commit 8c2d483428e53ce4a532f340471e25e79c0ec1f5
Author: Doug Anderson <dianders@chromium.org>
Date:   Thu Feb 13 14:39:34 2014 -0800

    hwmon: (ntc_thermistor) Avoid math overflow
    
    commit d3d89c468ceebbcf9423d1a3d66c5bf91f569570 upstream.
    
    The ntc thermistor code was doing math whose temporary result might
    have overflowed 32-bits.  We need some casts in there to make it safe.
    
    In one example I found:
    - pullup_uV: 1800000
    - result of iio_read_channel_raw: 3226
    - 1800000 * 3226 => 0x15a1cbc80
    
    Signed-off-by: Doug Anderson <dianders@chromium.org>
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b8b06e137054f0c3b9ab556dd646885d6f07609f
Author: Paul Bolle <pebolle@tiscali.nl>
Date:   Tue Feb 4 23:23:12 2014 +0100

    raw: test against runtime value of max_raw_minors
    
    commit 5bbb2ae3d6f896f8d2082d1eceb6131c2420b7cf upstream.
    
    bind_get() checks the device number it is called with. It uses
    MAX_RAW_MINORS for the upper bound. But MAX_RAW_MINORS is set at compile
    time while the actual number of raw devices can be set at runtime. This
    means the test can either be too strict or too lenient. And if the test
    ends up being too lenient bind_get() might try to access memory beyond
    what was allocated for "raw_devices".
    
    So check against the runtime value (max_raw_minors) in this function.
    
    Signed-off-by: Paul Bolle <pebolle@tiscali.nl>
    Acked-by: Jan Kara <jack@suse.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 44efe16da47fe49f0eb2ec5b00f8e53efb37e0e4
Author: Qipan Li <Qipan.Li@csr.com>
Date:   Mon Jan 27 14:23:39 2014 +0800

    serial: sirf: fix kernel panic caused by unpaired spinlock
    
    commit fb78b811422cd2d8c8605949cc4cc13618347ad5 upstream.
    
    commit 8b9ade9f74f8a279 coming from Viresh Kumar "tty: serial: sirfsoc: drop
    uart_port->lock before calling tty_flip_buffer_push()" broke sirfsoc uart
    driver by knic:
    
    	[    5.129122] BUG: spinlock already unlocked on CPU#0, ip6tables/1331
    	[    5.132554]  lock: sirfsoc_uart_ports+0x4/0x8a0, .magic: dead4ead,
    	.owner: <none>/-1, .owner_cpu: -1
    	[    5.141651] CPU: 0 PID: 1331 Comm: ip6tables Tainted: G
    	W  O 3.10.16 #3
    	[    5.148866] [<c0013528>] (unwind_backtrace+0x0/0xe0) from
    	[<c0010e70>] (show_stack+0x10/0x14)
    	[    5.157362] [<c0010e70>] (show_stack+0x10/0x14) from
    	[<c01a5e68>] (do_raw_spin_unlock+0x40/0xc8)
    	[    5.166125] [<c01a5e68>] (do_raw_spin_unlock+0x40/0xc8) from
    	[<c03ff8b4>] (_raw_spin_unlock+0x8/0x40)
    	[    5.175322] [<c03ff8b4>] (_raw_spin_unlock+0x8/0x40) from
    	[<c0203fcc>] (sirfsoc_uart_pio_rx_chars+0xa4/0xc0)
    	[    5.185120] [<c0203fcc>]
    	(sirfsoc_uart_pio_rx_chars+0xa4/0xc0) from [<c0204fb8>]
    	(sirfsoc_rx_tmo_process_tl+0xdc/0x1e0)
    	[    5.195875] [<c0204fb8>]
    	(sirfsoc_rx_tmo_process_tl+0xdc/0x1e0) from [<c0024b50>]
    	(tasklet_action+0x8c/0xec)
    	[    5.205673] [<c0024b50>] (tasklet_action+0x8c/0xec) from
    	[<c00242a8>] (__do_softirq+0xec/0x1d4)
    	[    5.214347] [<c00242a8>] (__do_softirq+0xec/0x1d4) from
    	[<c0024428>] (do_softirq+0x48/0x54)
    	[    5.222674] [<c0024428>] (do_softirq+0x48/0x54) from
    	[<c0024690>] (irq_exit+0x74/0xc0)
    	[    5.230573] [<c0024690>] (irq_exit+0x74/0xc0) from
    	[<c000e1e8>] (handle_IRQ+0x6c/0x90)
    	[    5.238465] [<c000e1e8>] (handle_IRQ+0x6c/0x90) from
    	[<c000d500>] (__irq_svc+0x40/0x70)
    	[    5.246446] [<c000d500>] (__irq_svc+0x40/0x70) from
    	[<c0092e7c>] (mark_page_accessed+0xc/0x68)
    	[    5.255034] [<c0092e7c>] (mark_page_accessed+0xc/0x68) from
    	[<c00a2a4c>] (unmap_single_vma+0x3bc/0x550)
    	[    5.264402] [<c00a2a4c>] (unmap_single_vma+0x3bc/0x550) from
    	[<c00a3b4c>] (unmap_vmas+0x44/0x54)
    	[    5.273164] [<c00a3b4c>] (unmap_vmas+0x44/0x54) from
    	[<c00a81a8>] (exit_mmap+0xc4/0x1e0)
    	[    5.281233] [<c00a81a8>] (exit_mmap+0xc4/0x1e0) from
    	[<c001bb78>] (mmput+0x3c/0xdc)
    	[    5.288868] [<c001bb78>] (mmput+0x3c/0xdc) from [<c0021b0c>]
    	(do_exit+0x30c/0x828)
    	[    5.296413] [<c0021b0c>] (do_exit+0x30c/0x828) from
    	[<c0022dac>] (do_group_exit+0x4c/0xb0)
    	[    5.304653] [<c0022dac>] (do_group_exit+0x4c/0xb0) from
    	[<c0022e20>] (__wake_up_parent+0x0/0x18)
    
    Root cause:
    the commit dropped uart_port->lock before calling tty_flip_buffer_push(), but in sirfsoc-uart,
    sirfsoc_uart_pio_rx_chars() can be called by sirfsoc_rx_tmo_process_tl(). here uart_port->lock
    has not been taken yet. so that caused unpaired lock/unlock.
    
    Solution:
    This patch is doing a quick fix for that, it adds spin_lock/unlock(&port->lock) protect to
    sirfsoc_uart_pio_rx_chars() in sirfsoc_rx_tmo_process_tl() to keep spin_lock/unlock in pair.
    
    Signed-off-by: Qipan Li <Qipan.Li@csr.com>
    Signed-off-by: Barry Song <Baohua.Song@csr.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2376a9891b6658971bcc5c467acf3772f8a33eda
Author: Axel Lin <axel.lin@ingics.com>
Date:   Mon Jan 20 23:22:07 2014 +0800

    spi: nuc900: Set SPI_LSB_FIRST for master->mode_bits if hw->pdata->lsb is true
    
    commit f7db1588d6028c97c098bb6445eaabc56a25fed8 upstream.
    
    Otherwise, spi_setup() fails with unsupported mode bits message.
    
    Signed-off-by: Axel Lin <axel.lin@ingics.com>
    Signed-off-by: Mark Brown <broonie@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 639558a469aacd66b586a52656e9d14e350483e4
Author: Kleber Sacilotto de Souza <klebers@linux.vnet.ibm.com>
Date:   Mon Feb 3 13:31:03 2014 -0200

    of: fix PCI bus match for PCIe slots
    
    commit 14e2abb732e485ee57d9d5b2cb8884652238e5c1 upstream.
    
    On IBM pseries systems the device_type device-tree property of a PCIe
    bridge contains the string "pciex". The of_bus_pci_match() function was
    looking only for "pci" on this property, so in such cases the bus
    matching code was falling back to the default bus, causing problems on
    functions that should be using "assigned-addresses" for region address
    translation. This patch fixes the problem by also looking for "pciex" on
    the PCI bus match function.
    
    v2: added comment
    
    Signed-off-by: Kleber Sacilotto de Souza <klebers@linux.vnet.ibm.com>
    Acked-by: Grant Likely <grant.likely@linaro.org>
    Signed-off-by: Rob Herring <robh@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit eb79343f14a21e9183fb555827b43267a2be0da5
Author: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Date:   Tue Jan 28 12:27:31 2014 +0200

    iwlwifi: mvm: BT Coex - disable BT when TXing probe request in scan
    
    commit 8e2a866ef214af4e104ec8d593e3269d8fe66d19 upstream.
    
    Not doing so will let BT kill our probe requests leading to
    failures in scan.
    
    Reviewed-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0e964f37636d720cd72c256bf3994d68a5709bb0
Author: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Date:   Thu Jan 23 11:55:16 2014 +0200

    iwlwifi: mvm: print the version of the firmware when it asserts
    
    commit b900a87b2eb90c0b9586496c82a323a1b8832d73 upstream.
    
    This can be useful to be able to spot the firmware version
    from the error reports without needing to fetch it from
    another place.
    
    Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
    Reviewed-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 363f04a893cccaa2d2c26c7ab1d8c197c428e344
Author: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Date:   Thu Dec 5 22:42:55 2013 +0200

    iwlwifi: mvm: don't allow A band if SKU forbids it
    
    commit c512865446e6dd5b6e91e81187e75b734ad7cfc7 upstream.
    
    The driver wasn't reading the NVM properly. While this
    didn't lead to any issue until now, it seems that there
    is an old version of the NVM in the wild.
    In this version, the A band channels appear to be valid
    but the SKU capabilities (another field of the NVM) says
    that A band isn't supported at all.
    With this specific version of the NVM, the driver would
    think that A band is supported while the HW / firmware
    don't. This leads to asserts.
    
    Reviewed-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9a446020f5ee8dd8d7b6522ac42933275f99d991
Author: Geert Uytterhoeven <geert+renesas@linux-m68k.org>
Date:   Tue Jan 28 10:33:03 2014 +0100

    spi: Fix crash with double message finalisation on error handling
    
    commit 1f802f8249a0da536877842c43c7204064c4de8b upstream.
    
    This reverts commit e120cc0dcf2880a4c5c0a6cb27b655600a1cfa1d.
    
    It causes a NULL pointer dereference with drivers using the generic
    spi_transfer_one_message(), which always calls
    spi_finalize_current_message(), which zeroes master->cur_msg.
    
    Drivers implementing transfer_one_message() theirselves must always call
    spi_finalize_current_message(), even if the transfer failed:
    
     * @transfer_one_message: the subsystem calls the driver to transfer a single
     *      message while queuing transfers that arrive in the meantime. When the
     *      driver is finished with this message, it must call
     *      spi_finalize_current_message() so the subsystem can issue the next
     *      transfer
    
    Signed-off-by: Geert Uytterhoeven <geert+renesas@linux-m68k.org>
    Signed-off-by: Mark Brown <broonie@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d87e47c32aad947e6ce5d3eb3ca077cabb0387b7
Author: Pontus Fuchs <pontus.fuchs@gmail.com>
Date:   Thu Jan 16 15:00:40 2014 +0100

    nl80211: Reset split_start when netlink skb is exhausted
    
    commit f12cb2893069495726c21a4b0178705dacfecfe0 upstream.
    
    When the netlink skb is exhausted split_start is left set. In the
    subsequent retry, with a larger buffer, the dump is continued from the
    failing point instead of from the beginning.
    
    This was causing my rt28xx based USB dongle to now show up when
    running "iw list" with an old iw version without split dump support.
    
    Fixes: 3713b4e364ef ("nl80211: allow splitting wiphy information in dumps")
    Signed-off-by: Pontus Fuchs <pontus.fuchs@gmail.com>
    [avoid the entire workaround when state->split is set]
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9ee59d9a5b03f45d9b421b020947846d13f27d08
Author: Martin Schwidefsky <schwidefsky@de.ibm.com>
Date:   Mon Feb 3 17:37:15 2014 +0100

    s390: fix kernel crash due to linkage stack instructions
    
    commit 8d7f6690cedb83456edd41c9bd583783f0703bf0 upstream.
    
    The kernel currently crashes with a low-address-protection exception
    if a user space process executes an instruction that tries to use the
    linkage stack. Set the base-ASTE origin and the subspace-ASTE origin
    of the dispatchable-unit-control-table to point to a dummy ASTE.
    Set up control register 15 to point to an empty linkage stack with no
    room left.
    
    A user space process with a linkage stack instruction will still crash
    but with a different exception which is correctly translated to a
    segmentation fault instead of a kernel oops.
    
    Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 098aca659bb61ee89b8c7faf88f407b3fff322c3
Author: Michael Holzheu <holzheu@linux.vnet.ibm.com>
Date:   Thu Jan 30 16:14:02 2014 +0100

    s390/dump: Fix dump memory detection
    
    commit d7736ff5be31edaa4fe5ab62810c64529a24b149 upstream.
    
    Dumps created by kdump or zfcpdump can contain invalid memory holes when
    dumping z/VM systems that have memory pressure.
    
    For example:
    
       # zgetdump -i /proc/vmcore.
       Memory map:
       0000000000000000 - 0000000000bfffff (12 MB)
       0000000000e00000 - 00000000014fffff (7 MB)
       000000000bd00000 - 00000000f3bfffff (3711 MB)
    
    The memory detection function find_memory_chunks() issues tprot to
    find valid memory chunks. In case of CMM it can happen that pages are
    marked as unstable via set_page_unstable() in arch_free_page().
    If z/VM has released that pages, tprot returns -EFAULT and indicates
    a memory hole.
    
    So fix this and switch off CMM in case of kdump or zfcpdump.
    
    Signed-off-by: Michael Holzheu <holzheu@linux.vnet.ibm.com>
    Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b0fbb64d2152697878b4a84b4a7c155c2c22a7d7
Author: Oleksij Rempel <linux@rempel-privat.de>
Date:   Sun Feb 2 10:55:18 2014 +0100

    ar5523: fix usb id for Gigaset.
    
    commit 4fcfc7443d072582b5047b8b391d711590e5645c upstream.
    
    Raw id and FW id should be switched.
    
    Tested-by: Oleksij Rempel <linux@rempel-privat.de>
    Signed-off-by: Oleksij Rempel <linux@rempel-privat.de>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c7a4978f970e78a009b4aae79317fd922f4e0122
Author: Sujith Manoharan <c_manoha@qca.qualcomm.com>
Date:   Tue Feb 4 08:37:53 2014 +0530

    ath9k: Do not support PowerSave by default
    
    commit 8298383c2cd5a6d0639f1bb1781fba181bd20154 upstream.
    
    Even though we make sure PowerSave is not enabled by default
    by disabling the flag, WIPHY_FLAG_PS_ON_BY_DEFAULT on init,
    PS could be enabled by userspace based on various factors
    like battery usage etc. Since PS in ath9k is just broken
    and has been untested for years, remove support for it, but
    allow a user to explicitly enable it using a module parameter.
    
    Signed-off-by: Sujith Manoharan <c_manoha@qca.qualcomm.com>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f419ef66970eb9d45094deb69385c2bbb88f52f1
Author: Oleksij Rempel <linux@rempel-privat.de>
Date:   Thu Jan 30 09:14:53 2014 +0100

    ath9k_htc: Do not support PowerSave by default
    
    commit 6bca610d97b6139a1d7598b8009da9d339daa50f upstream.
    
    It is a copy/paste of patch provided by Sujith for ath9k.
    
    "Even though we make sure PowerSave is not enabled by default
    by disabling the flag, WIPHY_FLAG_PS_ON_BY_DEFAULT on init,
    PS could be enabled by userspace based on various factors
    like battery usage etc. Since PS in ath9k is just broken
    and has been untested for years, remove support for it, but
    allow a user to explicitly enable it using a module parameter."
    
    Signed-off-by: Oleksij Rempel <linux@rempel-privat.de>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8c0f2ee6b5d414e019638e1f5ea94908dcae2742
Author: Stanislaw Gruszka <sgruszka@redhat.com>
Date:   Tue Jan 28 09:14:48 2014 +0100

    ath9k_htc: make ->sta_rc_update atomic for most calls
    
    commit 2fa4cb905605c863bf570027233af7afd8149ae4 upstream.
    
    sta_rc_update() callback must be atomic, hence we can not take mutexes
    or do other operations, which can sleep in ath9k_htc_sta_rc_update().
    
    I think we can just return from ath9k_htc_sta_rc_update(), if it is
    called without IEEE80211_RC_SUPP_RATES_CHANGED bit. That will help
    with scheduling while atomic bug for most cases (except mesh and IBSS
    modes).
    
    For mesh and IBSS I do not see other solution like creating additional
    workqueue, because sending firmware command require us to sleep, but
    this can be done in additional patch.
    
    Patch partially fixes bug:
    https://bugzilla.redhat.com/show_bug.cgi?id=990955
    
    Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5258fec859e55f79a80a00b3ca05181a488de766
Author: Johannes Berg <johannes.berg@intel.com>
Date:   Sat Feb 1 00:16:23 2014 +0100

    mac80211: fix fragmentation code, particularly for encryption
    
    commit 338f977f4eb441e69bb9a46eaa0ac715c931a67f upstream.
    
    The "new" fragmentation code (since my rewrite almost 5 years ago)
    erroneously sets skb->len rather than using skb_trim() to adjust
    the length of the first fragment after copying out all the others.
    This leaves the skb tail pointer pointing to after where the data
    originally ended, and thus causes the encryption MIC to be written
    at that point, rather than where it belongs: immediately after the
    data.
    
    The impact of this is that if software encryption is done, then
     a) encryption doesn't work for the first fragment, the connection
        becomes unusable as the first fragment will never be properly
        verified at the receiver, the MIC is practically guaranteed to
        be wrong
     b) we leak up to 8 bytes of plaintext (!) of the packet out into
        the air
    
    This is only mitigated by the fact that many devices are capable
    of doing encryption in hardware, in which case this can't happen
    as the tail pointer is irrelevant in that case. Additionally,
    fragmentation is not used very frequently and would normally have
    to be configured manually.
    
    Fix this by using skb_trim() properly.
    
    Fixes: 2de8e0d999b8 ("mac80211: rewrite fragmentation")
    Reported-by: Jouni Malinen <j@w1.fi>
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit abb35aa82a51197698f556dcec31ca854f147172
Author: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Date:   Mon Jan 27 11:07:42 2014 +0200

    mac80211: release the channel in error path in start_ap
    
    commit 0297ea17bf7879fb5846fafd1be4c0471e72848d upstream.
    
    When the driver cannot start the AP or when the assignement
    of the beacon goes wrong, we need to unassign the vif.
    
    Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6f912f7351c1240780b9e212b00e1cd118ba5bd9
Author: Eliad Peller <eliad@wizery.com>
Date:   Sun Jan 12 11:06:37 2014 +0200

    mac80211: move roc cookie assignment earlier
    
    commit 2f617435c3a6fe3f39efb9ae2baa77de2d6c97b8 upstream.
    
    ieee80211_start_roc_work() might add a new roc
    to existing roc, and tell cfg80211 it has already
    started.
    
    However, this might happen before the roc cookie
    was set, resulting in REMAIN_ON_CHANNEL (started)
    event with null cookie. Consequently, it can make
    wpa_supplicant go out of sync.
    
    Fix it by setting the roc cookie earlier.
    
    Signed-off-by: Eliad Peller <eliad@wizery.com>
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 05cdb9ef5488a3f40868d435b82982ee9a3690fa
Author: Steve French <smfrench@gmail.com>
Date:   Sun Feb 2 23:31:47 2014 -0600

    retrieving CIFS ACLs when mounted with SMB2 fails dropping session
    
    commit 83e3bc23ef9ce7c03b7b4e5d3d790246ea59db3e upstream.
    
    The get/set ACL xattr support for CIFS ACLs attempts to send old
    cifs dialect protocol requests even when mounted with SMB2 or later
    dialects. Sending cifs requests on an smb2 session causes problems -
    the server drops the session due to the illegal request.
    
    This patch makes CIFS ACL operations protocol specific to fix that.
    
    Attempting to query/set CIFS ACLs for SMB2 will now return
    EOPNOTSUPP (until we add worker routines for sending query
    ACL requests via SMB2) instead of sending invalid (cifs)
    requests.
    
    A separate followon patch will be needed to fix cifs_acl_to_fattr
    (which takes a cifs specific u16 fid so can't be abstracted
    to work with SMB2 until that is changed) and will be needed
    to fix mount problems when "cifsacl" is specified on mount
    with e.g. vers=2.1
    
    Signed-off-by: Steve French <smfrench@gmail.com>
    Reviewed-by: Shirish Pargaonkar <spargaonkar@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a792f65c502f3b2028f62afd3f357cb967ab075b
Author: Steve French <smfrench@gmail.com>
Date:   Sat Feb 1 23:27:18 2014 -0600

    Add protocol specific operation for CIFS xattrs
    
    commit d979f3b0a1f0b5499ab85e68cdf02b56852918b6 upstream.
    
    Changeset 666753c3ef8fc88b0ddd5be4865d0aa66428ac35 added protocol
    operations for get/setxattr to avoid calling cifs operations
    on smb2/smb3 mounts for xattr operations and this changeset
    adds the calls to cifs specific protocol operations for xattrs
    (in order to reenable cifs support for xattrs which was
    temporarily disabled by the previous changeset.  We do not
    have SMB2/SMB3 worker function for setting xattrs yet so
    this only enables it for cifs.
    
    CCing stable since without these two small changsets (its
    small coreq 666753c3ef8fc88b0ddd5be4865d0aa66428ac35 is
    also needed) calling getfattr/setfattr on smb2/smb3 mounts
    causes problems.
    
    Signed-off-by: Steve French <smfrench@gmail.com>
    Reviewed-by: Shirish Pargaonkar <spargaonkar@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit abd26808eb1d798830d6cb7bd97b8ef0919082bc
Author: Steve French <smfrench@gmail.com>
Date:   Sun Jan 26 23:53:43 2014 -0600

    CIFS: Fix SMB2 mounts so they don't try to set or get xattrs via cifs
    
    commit 666753c3ef8fc88b0ddd5be4865d0aa66428ac35 upstream.
    
    When mounting with smb2 (or smb2.1 or smb3) we need to check to make
    sure that attempts to query or set extended attributes do not
    attempt to send the request with the older cifs protocol instead
    (eventually we also need to add the support in SMB2
    to query/set extended attributes but this patch prevents us from
    using the wrong protocol for extended attribute operations).
    
    Signed-off-by: Steve French <smfrench@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4ee4d7ae04c4996b3dbd02b5990927432c7eddec
Author: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
Date:   Mon Feb 10 14:25:50 2014 -0800

    mm/memory-failure.c: move refcount only in !MF_COUNT_INCREASED
    
    commit 8d547ff4ac5927245e0833ac18528f939da0ee0e upstream.
    
    mce-test detected a test failure when injecting error to a thp tail
    page.  This is because we take page refcount of the tail page in
    madvise_hwpoison() while the fix in commit a3e0f9e47d5e
    ("mm/memory-failure.c: transfer page count from head page to tail page
    after split thp") assumes that we always take refcount on the head page.
    
    When a real memory error happens we take refcount on the head page where
    memory_failure() is called without MF_COUNT_INCREASED set, so it seems
    to me that testing memory error on thp tail page using madvise makes
    little sense.
    
    This patch cancels moving refcount in !MF_COUNT_INCREASED for valid
    testing.
    
    [akpm@linux-foundation.org: s/&&/&/]
    Signed-off-by: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
    Cc: Andi Kleen <andi@firstfloor.org>
    Cc: Wanpeng Li <liwanp@linux.vnet.ibm.com>
    Cc: Chen Gong <gong.chen@linux.intel.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 b030653420504093cef2be358449f34934635ed9
Author: Rafael Aquini <aquini@redhat.com>
Date:   Mon Feb 10 14:25:48 2014 -0800

    mm: fix page leak at nfs_symlink()
    
    commit a0b54adda3fe4b4cc6d28f2a9217cd35d1aa888c upstream.
    
    Changes in commit a0b8cab3b9b2 ("mm: remove lru parameter from
    __pagevec_lru_add and remove parts of pagevec API") have introduced a
    call to add_to_page_cache_lru() which causes a leak in nfs_symlink() as
    now the page gets an extra refcount that is not dropped.
    
    Jan Stancek observed and reported the leak effect while running test8
    from Connectathon Testsuite.  After several iterations over the test
    case, which creates several symlinks on a NFS mountpoint, the test
    system was quickly getting into an out-of-memory scenario.
    
    This patch fixes the page leak by dropping that extra refcount
    add_to_page_cache_lru() is grabbing.
    
    Signed-off-by: Jan Stancek <jstancek@redhat.com>
    Signed-off-by: Rafael Aquini <aquini@redhat.com>
    Acked-by: Mel Gorman <mgorman@suse.de>
    Acked-by: Rik van Riel <riel@redhat.com>
    Cc: Jeff Layton <jlayton@redhat.com>
    Cc: Trond Myklebust <trond.myklebust@primarydata.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 e69755bbbc05f297b09e88ac607d2b16cd71fac8
Author: Eric W. Biederman <ebiederm@xmission.com>
Date:   Mon Feb 10 14:25:41 2014 -0800

    fs/file.c:fdtable: avoid triggering OOMs from alloc_fdmem
    
    commit 96c7a2ff21501691587e1ae969b83cbec8b78e08 upstream.
    
    Recently due to a spike in connections per second memcached on 3
    separate boxes triggered the OOM killer from accept.  At the time the
    OOM killer was triggered there was 4GB out of 36GB free in zone 1.  The
    problem was that alloc_fdtable was allocating an order 3 page (32KiB) to
    hold a bitmap, and there was sufficient fragmentation that the largest
    page available was 8KiB.
    
    I find the logic that PAGE_ALLOC_COSTLY_ORDER can't fail pretty dubious
    but I do agree that order 3 allocations are very likely to succeed.
    
    There are always pathologies where order > 0 allocations can fail when
    there are copious amounts of free memory available.  Using the pigeon
    hole principle it is easy to show that it requires 1 page more than 50%
    of the pages being free to guarantee an order 1 (8KiB) allocation will
    succeed, 1 page more than 75% of the pages being free to guarantee an
    order 2 (16KiB) allocation will succeed and 1 page more than 87.5% of
    the pages being free to guarantee an order 3 allocate will succeed.
    
    A server churning memory with a lot of small requests and replies like
    memcached is a common case that if anything can will skew the odds
    against large pages being available.
    
    Therefore let's not give external applications a practical way to kill
    linux server applications, and specify __GFP_NORETRY to the kmalloc in
    alloc_fdmem.  Unless I am misreading the code and by the time the code
    reaches should_alloc_retry in __alloc_pages_slowpath (where
    __GFP_NORETRY becomes signification).  We have already tried everything
    reasonable to allocate a page and the only thing left to do is wait.  So
    not waiting and falling back to vmalloc immediately seems like the
    reasonable thing to do even if there wasn't a chance of triggering the
    OOM killer.
    
    Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
    Cc: Eric Dumazet <eric.dumazet@gmail.com>
    Acked-by: David Rientjes <rientjes@google.com>
    Cc: Cong Wang <cwang@twopensource.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 e998c107c0953cced1b8c3ac828c80b5e182cc6c
Author: David Vrabel <david.vrabel@citrix.com>
Date:   Tue Feb 4 18:53:56 2014 +0000

    xen-blkfront: handle backend CLOSED without CLOSING
    
    commit 3661371701e714f0cea4120f6a365340858fb4e4 upstream.
    
    Backend drivers shouldn't transistion to CLOSED unless the frontend is
    CLOSED.  If a backend does transition to CLOSED too soon then the
    frontend may not see the CLOSING state and will not properly shutdown.
    
    So, treat an unexpected backend CLOSED state the same as CLOSING.
    
    Signed-off-by: David Vrabel <david.vrabel@citrix.com>
    Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
    Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1160ce4b7c6ec657c9a315f4dbd234b4ea8ca145
Author: Mel Gorman <mgorman@suse.de>
Date:   Mon Feb 10 14:25:40 2014 -0800

    xen: properly account for _PAGE_NUMA during xen pte translations
    
    commit a9c8e4beeeb64c22b84c803747487857fe424b68 upstream.
    
    Steven Noonan forwarded a users report where they had a problem starting
    vsftpd on a Xen paravirtualized guest, with this in dmesg:
    
      BUG: Bad page map in process vsftpd  pte:8000000493b88165 pmd:e9cc01067
      page:ffffea00124ee200 count:0 mapcount:-1 mapping:     (null) index:0x0
      page flags: 0x2ffc0000000014(referenced|dirty)
      addr:00007f97eea74000 vm_flags:00100071 anon_vma:ffff880e98f80380 mapping:          (null) index:7f97eea74
      CPU: 4 PID: 587 Comm: vsftpd Not tainted 3.12.7-1-ec2 #1
      Call Trace:
        dump_stack+0x45/0x56
        print_bad_pte+0x22e/0x250
        unmap_single_vma+0x583/0x890
        unmap_vmas+0x65/0x90
        exit_mmap+0xc5/0x170
        mmput+0x65/0x100
        do_exit+0x393/0x9e0
        do_group_exit+0xcc/0x140
        SyS_exit_group+0x14/0x20
        system_call_fastpath+0x1a/0x1f
      Disabling lock debugging due to kernel taint
      BUG: Bad rss-counter state mm:ffff880e9ca60580 idx:0 val:-1
      BUG: Bad rss-counter state mm:ffff880e9ca60580 idx:1 val:1
    
    The issue could not be reproduced under an HVM instance with the same
    kernel, so it appears to be exclusive to paravirtual Xen guests.  He
    bisected the problem to commit 1667918b6483 ("mm: numa: clear numa
    hinting information on mprotect") that was also included in 3.12-stable.
    
    The problem was related to how xen translates ptes because it was not
    accounting for the _PAGE_NUMA bit.  This patch splits pte_present to add
    a pteval_present helper for use by xen so both bare metal and xen use
    the same code when checking if a PTE is present.
    
    [mgorman@suse.de: wrote changelog, proposed minor modifications]
    [akpm@linux-foundation.org: fix typo in comment]
    Reported-by: Steven Noonan <steven@uplinklabs.net>
    Tested-by: Steven Noonan <steven@uplinklabs.net>
    Signed-off-by: Elena Ufimtseva <ufimtseva@gmail.com>
    Signed-off-by: Mel Gorman <mgorman@suse.de>
    Reviewed-by: David Vrabel <david.vrabel@citrix.com>
    Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.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>