Linux 3.4.82

commit 2606524141e4ff9b6a5d0bcbd9d601dfc5a8285c
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Sat Feb 22 10:33:35 2014 -0800

    Linux 3.4.82

commit df1cc7da2a599bde8f28f94601b7ec4c85ec441b
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 17ff13b428cc2900bc04570f3a74d746856f35e6
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 7db019a232f3577a92a2a81d34e4add1c4b80483
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 d6e20e8145341ed1b5d605a8d9ab8463b0ca6ed8
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 cd6f6b709eebe70d80a3e542d218228bcf189654
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 5a0d43c3374c287711f4191922835e18fc8ae3ec
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 cc512a4a4a197603c83e9c920832d06ffe81f9b9
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 c5bdb3a52d40d1ef3b3f6fb3617d20bb47cee46c
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 e7a95613d77dcbcbefe99b465c6488550caf2c85
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 f0fbd5c4c3cc62df9dca096c5d20943ba608e735
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 99c30d65f863a6b6d53f69572c2958ed764994a5
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 2aac5d817f6b063a511e6f6270efe861e04b94a2
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 65404686fff96a6f84f86628d86686b702faeda1
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 400cbedf7d18881f36408095b5f3387c53aaa2a1
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 1c41ee3a84da5eff41aaf5e58b18a3233e4ae637
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 402d5390c91374880c4028490087b8cffe338be3
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 dce0ea4a4732af1333525b76bde5572073d4bbfa
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 cc01cae91828041fd1dfa5c1b6bf09221c1659c8
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 e24cfb1b4f4942681c3ce382e83cc090f0ad1550
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 566d9875cb708d907f8a0b3c2a0dffb96dcb973c
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 9558f9d82eed2e0015783c553794aeed79dfa0f8
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 021139f22c744a254870dcb23b326037a32a1aa7
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 fb11ab59b2999e2afee7c7fcd3687bf07b2fc988
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 ce5562e5704bf715fc3084d9f218e5ba3fbf0991
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 2af3263a0d1d456ba63d7d167fadd7f08fd8fe1c
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>