commit a145cb954f3eb95c682ba8f7f85227784b3cb34b
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Sun Oct 13 18:14:45 2013 -0700

    Linux 3.11.5

commit fe164452c52395b47286b0ba3dfc9b3b3041f547
Author: Kent Overstreet <kmo@daterainc.com>
Date:   Thu Oct 10 17:31:15 2013 -0700

    bcache: Fix a null ptr deref regression
    
    commit 2fe80d3bbf1c8bd9efc5b8154207c8dd104e7306 upstream.
    
    Commit c0f04d88e46d ("bcache: Fix flushes in writeback mode") was fixing
    a reported data corruption bug, but it seems some last minute
    refactoring or rebasing introduced a null pointer deref.
    
    Signed-off-by: Kent Overstreet <kmo@daterainc.com>
    Reported-by: Gabriel de Perthuis <g2p.code@gmail.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c0684969f66a2f636f5c9a78fe7267b38ccd149f
Author: Bjørn Mork <bjorn@mork.no>
Date:   Tue Sep 10 15:06:20 2013 +0200

    net: qmi_wwan: add new Qualcomm devices
    
    commit 0470667caa8261beb8a9141102b04a5357dd45b5 upstream.
    
    Adding the device list from the Windows driver description files
    included with a new Qualcomm MDM9615 based device, "Alcatel-sbell
    ASB TL131 TDD LTE", from China Mobile.  This device is tested
    and verified to work.  The others are assumed to work based on
    using the same Windows driver.
    
    Many of these devices support multiple QMI/wwan ports, requiring
    multiple interface matching entries.  All devices are composite,
    providing a mix of one or more serial, storage or Android Debug
    Brigde functions in addition to the wwan function.
    
    This device list included an update of one previously known device,
    which was incorrectly assumed to have a Gobi 2K layout.  This is
    corrected.
    
    Reported-by: 王康 <scateu@gmail.com>
    Signed-off-by: Bjørn Mork <bjorn@mork.no>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 54e4243b67f631403d689dadfc802013012905e7
Author: David Herrmann <dh.herrmann@gmail.com>
Date:   Mon Sep 9 18:33:54 2013 +0200

    HID: uhid: allocate static minor
    
    commit 19872d20c890073c5207d9e02bb8f14d451a11eb upstream.
    
    udev has this nice feature of creating "dead" /dev/<node> device-nodes if
    it finds a devnode:<node> modalias. Once the node is accessed, the kernel
    automatically loads the module that provides the node. However, this
    requires udev to know the major:minor code to use for the node. This
    feature was introduced by:
    
      commit 578454ff7eab61d13a26b568f99a89a2c9edc881
      Author: Kay Sievers <kay.sievers@vrfy.org>
      Date:   Thu May 20 18:07:20 2010 +0200
    
          driver core: add devname module aliases to allow module on-demand auto-loading
    
    However, uhid uses dynamic minor numbers so this doesn't actually work. We
    need to load uhid to know which minor it's going to use.
    
    Hence, allocate a static minor (just like uinput does) and we're good
    to go.
    
    Reported-by: Tom Gundersen <teg@jklm.no>
    Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9dfe194e32d837b34ac62e06e6357e21442ba009
Author: Marcel Holtmann <marcel@holtmann.org>
Date:   Sun Sep 1 11:02:46 2013 -0700

    HID: uhid: add devname module alias
    
    commit 60cbd53e4bf623fe978e6f23a6da642e730fde3a upstream.
    
    For simple device node creation, add the devname module alias.
    
    Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
    Reviewed-by: David Herrmann <dh.herrmann@gmail.com>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 95f5af75db038b378b7fe2bad64d828f0f35a991
Author: Anders F. U. Kiær <ablacksheep@gmail.com>
Date:   Tue Oct 1 19:22:05 2013 +0200

    HID: add Holtek USB ID 04d9:a081 SHARKOON DarkGlider
    
    commit 7da7cbbbeb60e0939fecdf9723b388136c175e5c upstream.
    
    Added id, bindings and comments for Holtek USB ID 04d9:a081 SHARKOON
    DarkGlider Gaming mouse to use the same corrections of the report
    descriptor as Holtek 04d9:a04a. As the mouse exceed HID_MAX_USAGES
    at the same offsets in the reported descriptor.
    Tested on the hardware.
    
    Signed-off-by: Anders F. U. Kiær <ablacksheep@gmail.com>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 872de0f11f2817020d91aa51ecd8b97be16a516e
Author: Stefan Achatz <erazor_de@users.sourceforge.net>
Date:   Fri Aug 30 14:10:07 2013 +0200

    HID: roccat: add support for KonePureOptical v2
    
    commit a4be0ed39f2b1ea990804ea54e39bc42d17ed5a5 upstream.
    
    KonePureOptical is a KonePure with different sensor.
    
    Signed-off-by: Stefan Achatz <erazor_de@users.sourceforge.net>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit bd525da042d6221b98676f840facf1f9c780ba84
Author: Josef Bacik <jbacik@fusionio.com>
Date:   Thu Aug 22 17:03:29 2013 -0400

    Btrfs: remove ourselves from the cluster list under lock
    
    commit b8d0c69b9469ffd33df30fee3e990f2d4aa68a09 upstream.
    
    A user was reporting weird warnings from btrfs_put_delayed_ref() and I noticed
    that we were doing this list_del_init() on our head ref outside of
    delayed_refs->lock.  This is a problem if we have people still on the list, we
    could end up modifying old pointers and such.  Fix this by removing us from the
    list before we do our run_delayed_ref on our head ref.  Thanks,
    
    Signed-off-by: Josef Bacik <jbacik@fusionio.com>
    Signed-off-by: Chris Mason <chris.mason@fusionio.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1aa65a004a258d3a83eb9f55f4277d9688ec35c5
Author: Josef Bacik <jbacik@fusionio.com>
Date:   Mon Aug 12 10:56:14 2013 -0400

    Btrfs: skip subvol entries when checking if we've created a dir already
    
    commit a05254143cd183b18002cbba7759a1e4629aa762 upstream.
    
    We have logic to see if we've already created a parent directory by check to see
    if an inode inside of that directory has a lower inode number than the one we
    are currently processing.  The logic is that if there is a lower inode number
    then we would have had to made sure the directory was created at that previous
    point.  The problem is that subvols inode numbers count from the lowest objectid
    in the root tree, which may be less than our current progress.  So just skip if
    our dir item key is a root item.  This fixes the original test and the xfstest
    version I made that added an extra subvol create.  Thanks,
    
    Reported-by: Emil Karlson <jekarlson@gmail.com>
    Signed-off-by: Josef Bacik <jbacik@fusionio.com>
    Signed-off-by: Chris Mason <chris.mason@fusionio.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5c9f7ebcf25e00906b62239a457a7bb22b90135d
Author: Josef Bacik <jbacik@fusionio.com>
Date:   Tue Jul 30 16:30:30 2013 -0400

    Btrfs: change how we queue blocks for backref checking
    
    commit b6c60c8018c4e9beb2f83fc82c09f9d033766571 upstream.
    
    Previously we only added blocks to the list to have their backrefs checked if
    the level of the block is right above the one we are searching for.  This is
    because we want to make sure we don't add the entire path up to the root to the
    lists to make sure we process things one at a time.  This assumes that if any
    blocks in the path to the root are going to be not checked (shared in other
    words) then they will be in the level right above the current block on up.  This
    isn't quite right though since we can have blocks higher up the list that are
    shared because they are attached to a reloc root.  But we won't add this block
    to be checked and then later on we will BUG_ON(!upper->checked).  So instead
    keep track of wether or not we've queued a block to be checked in this current
    search, and if we haven't go ahead and queue it to be checked.  This patch fixed
    the panic I was seeing where we BUG_ON(!upper->checked).  Thanks,
    
    Signed-off-by: Josef Bacik <jbacik@fusionio.com>
    Signed-off-by: Chris Mason <chris.mason@fusionio.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6593b34b1251c27d1949878f04bf58130d47625f
Author: Josef Bacik <jbacik@fusionio.com>
Date:   Mon Jul 22 12:50:37 2013 -0400

    Btrfs: reset ret in record_one_backref
    
    commit 50f1319cb5f7690e4d9de18d1a75ea89296d0e53 upstream.
    
    I was getting warnings when running find ./ -type f -exec btrfs fi defrag -f {}
    \; from record_one_backref because ret was set.  Turns out it was because it was
    set to 1 because the search slot didn't come out exact and we never reset it.
    So reset it to 0 right after the search so we don't leak this and get
    uneccessary warnings.  Thanks,
    
    Signed-off-by: Josef Bacik <jbacik@fusionio.com>
    Signed-off-by: Chris Mason <chris.mason@fusionio.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 557801d93e4f3e77c7149da1acd6b068c32c90fb
Author: Martin Schwidefsky <schwidefsky@de.ibm.com>
Date:   Fri Sep 27 15:24:38 2013 +0200

    s390: fix system call restart after inferior call
    
    commit dbbfe487e5f3fc00c9fe5207d63309859704d12f upstream.
    
    Git commit 616498813b11ffef "s390: system call path micro optimization"
    introduced a regression in regard to system call restarting and inferior
    function calls via the ptrace interface. The pointer to the system call
    table needs to be loaded in sysc_sigpending if do_signal returns with
    TIF_SYSCALl set after it restored a system call context.
    
    Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4d686ca4def8f3c56de1f73340770edc58c5251f
Author: Chris Metcalf <cmetcalf@tilera.com>
Date:   Thu Sep 26 13:24:53 2013 -0400

    tile: use a more conservative __my_cpu_offset in CONFIG_PREEMPT
    
    commit f862eefec0b68e099a9fa58d3761ffb10bad97e1 upstream.
    
    It turns out the kernel relies on barrier() to force a reload of the
    percpu offset value.  Since we can't easily modify the definition of
    barrier() to include "tp" as an output register, we instead provide a
    definition of __my_cpu_offset as extended assembly that includes a fake
    stack read to hazard against barrier(), forcing gcc to know that it
    must reread "tp" and recompute anything based on "tp" after a barrier.
    
    This fixes observed hangs in the slub allocator when we are looping
    on a percpu cmpxchg_double.
    
    A similar fix for ARMv7 was made in June in change 509eb76ebf97.
    
    Signed-off-by: Chris Metcalf <cmetcalf@tilera.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4bb5b1a014026ff17f88e0cbb9e21fb6a0869e6d
Author: Franck Jullien <franck.jullien@gmail.com>
Date:   Wed Jul 24 15:17:48 2013 +0200

    mmc: fix null pointer use in mmc_blk_remove_req
    
    commit 8efb83a2f8518a6ffcc074177f8d659c5165ef37 upstream.
    
    A previous commit (fdfa20c1631210d0) reordered the shutdown sequence
    in mmc_blk_remove_req. However, mmc_cleanup_queue is now called before
    we get the card pointer, and mmc_cleanup_queue sets mq->card to NULL.
    
    This patch moves the card pointer assignment before mmc_cleanup_queue.
    
    Signed-off-by: Franck Jullien <franck.jullien@gmail.com>
    Signed-off-by: Chris Ball <cjb@laptop.org>
    Cc: Adrian Hunter <adrian.hunter@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6f94b7b0a15c04649b67135c7edaaeb591131e8f
Author: David Herrmann <dh.herrmann@gmail.com>
Date:   Wed Oct 2 13:47:28 2013 +0200

    HID: wiimote: fix FF deadlock
    
    commit f50f9aabf32db7414551ffdfdccc71be5f3d6e7d upstream.
    
    The input core has an internal spinlock that is acquired during event
    injection via input_event() and friends but also held during FF callbacks.
    That means, there is no way to share a lock between event-injection and FF
    handling. Unfortunately, this is what is required for wiimote state
    tracking and what we do with state.lock and input->lock.
    
    This deadlock can be triggered when using continuous data reporting and FF
    on a wiimote device at the same time. I takes me at least 30m of
    stress-testing to trigger it but users reported considerably shorter
    times (http://bpaste.net/show/132504/) when using some gaming-console
    emulators.
    
    The real problem is that we have two copies of internal state, one in the
    wiimote objects and the other in the input device. As the input-lock is
    not supposed to be accessed from outside of input-core, we have no other
    chance than offloading FF handling into a worker. This actually works
    pretty nice and also allows to implictly merge fast rumble changes into a
    single request.
    
    Due to the 3-layered workers (rumble+queue+l2cap) this might reduce FF
    responsiveness. Initial tests were fine so lets fix the race first and if
    it turns out to be too slow we can always handle FF out-of-band and skip
    the queue-worker.
    
    Reported-by: Thomas Schneider
    Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b5419a98b659a7588cda0b3005f7a6e8c9a63f35
Author: Olof Johansson <olof@lixom.net>
Date:   Mon Sep 16 09:01:24 2013 -0700

    ARM: multi_v7_defconfig: enable ARM_ATAG_DTB_COMPAT
    
    commit a0396b9bd5a4a7baf598b60d2ca53c605c440a42 upstream.
    
    Without this, legacy platforms that can boot with a multiplatform
    kernel but that need the DTB to be appended, won't have a way to pass
    firmware-set bootargs to the kernel.
    
    This is needed to boot multi_v7_defconfig on snowball, for instance.
    
    Signed-off-by: Olof Johansson <olof@lixom.net>
    Cc: Kevin Hilman <khilman@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 10c7a5f1b2fc1a5a8b5288c24853cfa1caf423f4
Author: Takashi Iwai <tiwai@suse.de>
Date:   Mon Sep 30 12:13:44 2013 +0200

    ALSA: hda - Fix GPIO for Acer Aspire 3830TG
    
    commit 4a4370442c996be0fd08234a167c8a127c2488bb upstream.
    
    Acer Aspire 3830TG seems requiring GPIO bit 0 as the primary mute
    control.  When a machine is booted after Windows 8, the GPIO pin is
    turned off and it results in the silent output.
    
    This patch adds the manual fixup of GPIO bit 0 for this model.
    
    Reported-by: Christopher <DIDI2002@web.de>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f5909743240448cffe37fc66ce032582e8c472d6
Author: Stephen Warren <swarren@nvidia.com>
Date:   Tue Aug 6 14:38:51 2013 -0600

    ARM: tegra: unify Tegra's Kconfig a bit more
    
    commit 20984c44b5a08620778ea14fa5807489170fd5ca upstream.
    
    Move all common select clauses from ARCH_TEGRA_*_SOC to ARCH_TEGRA to
    eliminate duplication. The USB-related selects all should have been
    common too, but were missing from Tegra114 previously. Move these to
    ARCH_TEGRA too. The latter fixes a build break when only Tegra114
    support was enabled, but not Tegra20 or Tegra30 support.
    
    Signed-off-by: Stephen Warren <swarren@nvidia.com>
    Reported-by: Paul Walmsley <pwalmsley@nvidia.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2e5ab49a2fc61392ec303c0c82e1060c3ace3e10
Author: Ben Skeggs <bskeggs@redhat.com>
Date:   Tue Sep 10 12:11:01 2013 +1000

    drm/nouveau/bios/init: stub opcode 0xaa
    
    commit 5495e39fb3695182b9f2a72fe4169056cada37a1 upstream.
    
    Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d9645bbc32d900eca739e1aa8d2762e330e7a93c
Author: Mark Tinguely <tinguely@sgi.com>
Date:   Mon Sep 23 12:18:58 2013 -0500

    xfs: fix node forward in xfs_node_toosmall
    
    commit 997def25e4b9cee3b01609e18a52f926bca8bd2b upstream.
    
    Commit f5ea1100 cleans up the disk to host conversions for
    node directory entries, but because a variable is reused in
    xfs_node_toosmall() the next node is not correctly found.
    If the original node is small enough (<= 3/8 of the node size),
    this change may incorrectly cause a node collapse when it should
    not. That will cause an assert in xfstest generic/319:
    
       Assertion failed: first <= last && last < BBTOB(bp->b_length),
       file: /root/newest/xfs/fs/xfs/xfs_trans_buf.c, line: 569
    
    Keep the original node header to get the correct forward node.
    
    (When a node is considered for a merge with a sibling, it overwrites the
     sibling pointers of the original incore nodehdr with the sibling's
     pointers.  This leads to loop considering the original node as a merge
     candidate with itself in the second pass, and so it incorrectly
     determines a merge should occur.)
    
    [v3: added Dave Chinner's (slightly modified) suggestion to the commit header,
    	cleaned up whitespace.  -bpm]
    
    Signed-off-by: Mark Tinguely <tinguely@sgi.com>
    Reviewed-by: Ben Myers <bpm@sgi.com>
    Signed-off-by: Ben Myers <bpm@sgi.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 311a38441f3b71bf993f6b18d56cbfa43007d48c
Author: Lv Zheng <lv.zheng@intel.com>
Date:   Fri Sep 13 13:13:23 2013 +0800

    ACPI / IPMI: Fix atomic context requirement of ipmi_msg_handler()
    
    commit 06a8566bcf5cf7db9843a82cde7a33c7bf3947d9 upstream.
    
    This patch fixes the issues indicated by the test results that
    ipmi_msg_handler() is invoked in atomic context.
    
    BUG: scheduling while atomic: kipmi0/18933/0x10000100
    Modules linked in: ipmi_si acpi_ipmi ...
    CPU: 3 PID: 18933 Comm: kipmi0 Tainted: G       AW    3.10.0-rc7+ #2
    Hardware name: QCI QSSC-S4R/QSSC-S4R, BIOS QSSC-S4R.QCI.01.00.0027.070120100606 07/01/2010
     ffff8838245eea00 ffff88103fc63c98 ffffffff814c4a1e ffff88103fc63ca8
     ffffffff814bfbab ffff88103fc63d28 ffffffff814c73e0 ffff88103933cbd4
     0000000000000096 ffff88103fc63ce8 ffff88102f618000 ffff881035c01fd8
    Call Trace:
     <IRQ>  [<ffffffff814c4a1e>] dump_stack+0x19/0x1b
     [<ffffffff814bfbab>] __schedule_bug+0x46/0x54
     [<ffffffff814c73e0>] __schedule+0x83/0x59c
     [<ffffffff81058853>] __cond_resched+0x22/0x2d
     [<ffffffff814c794b>] _cond_resched+0x14/0x1d
     [<ffffffff814c6d82>] mutex_lock+0x11/0x32
     [<ffffffff8101e1e9>] ? __default_send_IPI_dest_field.constprop.0+0x53/0x58
     [<ffffffffa09e3f9c>] ipmi_msg_handler+0x23/0x166 [ipmi_si]
     [<ffffffff812bf6e4>] deliver_response+0x55/0x5a
     [<ffffffff812c0fd4>] handle_new_recv_msgs+0xb67/0xc65
     [<ffffffff81007ad1>] ? read_tsc+0x9/0x19
     [<ffffffff814c8620>] ? _raw_spin_lock_irq+0xa/0xc
     [<ffffffffa09e1128>] ipmi_thread+0x5c/0x146 [ipmi_si]
     ...
    
    Also Tony Camuso says:
    
     We were getting occasional "Scheduling while atomic" call traces
     during boot on some systems. Problem was first seen on a Cisco C210
     but we were able to reproduce it on a Cisco c220m3. Setting
     CONFIG_LOCKDEP and LOCKDEP_SUPPORT to 'y' exposed a lockdep around
     tx_msg_lock in acpi_ipmi.c struct acpi_ipmi_device.
    
     =================================
     [ INFO: inconsistent lock state ]
     2.6.32-415.el6.x86_64-debug-splck #1
     ---------------------------------
     inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage.
     ksoftirqd/3/17 [HC0[0]:SC1[1]:HE1:SE0] takes:
      (&ipmi_device->tx_msg_lock){+.?...}, at: [<ffffffff81337a27>] ipmi_msg_handler+0x71/0x126
     {SOFTIRQ-ON-W} state was registered at:
       [<ffffffff810ba11c>] __lock_acquire+0x63c/0x1570
       [<ffffffff810bb0f4>] lock_acquire+0xa4/0x120
       [<ffffffff815581cc>] __mutex_lock_common+0x4c/0x400
       [<ffffffff815586ea>] mutex_lock_nested+0x4a/0x60
       [<ffffffff8133789d>] acpi_ipmi_space_handler+0x11b/0x234
       [<ffffffff81321c62>] acpi_ev_address_space_dispatch+0x170/0x1be
    
    The fix implemented by this change has been tested by Tony:
    
     Tested the patch in a boot loop with lockdep debug enabled and never
     saw the problem in over 400 reboots.
    
    Reported-and-tested-by: Tony Camuso <tcamuso@redhat.com>
    Signed-off-by: Lv Zheng <lv.zheng@intel.com>
    Reviewed-by: Huang Ying <ying.huang@intel.com>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Cc: Jonghwan Choi <jhbird.choi@samsung.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 36b6481134dc79cd80ab9b410334623134042e9d
Author: Michael Grzeschik <m.grzeschik@pengutronix.de>
Date:   Tue Sep 17 15:56:06 2013 +0200

    dmaengine: imx-dma: fix slow path issue in prep_dma_cyclic
    
    commit edc530fe7ee5a562680615d2e7cd205879c751a7 upstream.
    
    When perparing cyclic_dma buffers by the sound layer, it will dump the
    following lockdep trace. The leading snd_pcm_action_single get called
    with read_lock_irq called. To fix this, we change the kcalloc call from
    GFP_KERNEL to GFP_ATOMIC.
    
    WARNING: at kernel/lockdep.c:2740 lockdep_trace_alloc+0xcc/0x114()
    DEBUG_LOCKS_WARN_ON(irqs_disabled_flags(flags))
    Modules linked in:
    CPU: 0 PID: 832 Comm: aplay Not tainted 3.11.0-20130823+ #903
    Backtrace:
    [<c000b98c>] (dump_backtrace+0x0/0x10c) from [<c000bb28>] (show_stack+0x18/0x1c)
     r6:c004c090 r5:00000009 r4:c2e0bd18 r3:00404000
    [<c000bb10>] (show_stack+0x0/0x1c) from [<c02f397c>] (dump_stack+0x20/0x28)
    [<c02f395c>] (dump_stack+0x0/0x28) from [<c001531c>] (warn_slowpath_common+0x54/0x70)
    [<c00152c8>] (warn_slowpath_common+0x0/0x70) from [<c00153dc>] (warn_slowpath_fmt+0x38/0x40)
     r8:00004000 r7:a3b90000 r6:000080d0 r5:60000093 r4:c2e0a000 r3:00000009
    [<c00153a4>] (warn_slowpath_fmt+0x0/0x40) from [<c004c090>] (lockdep_trace_alloc+0xcc/0x114)
     r3:c03955d8 r2:c03907db
    [<c004bfc4>] (lockdep_trace_alloc+0x0/0x114) from [<c008f16c>] (__kmalloc+0x34/0x118)
     r6:000080d0 r5:c3800120 r4:000080d0 r3:c040a0f8
    [<c008f138>] (__kmalloc+0x0/0x118) from [<c019c95c>] (imxdma_prep_dma_cyclic+0x64/0x168)
     r7:a3b90000 r6:00000004 r5:c39d8420 r4:c3847150
    [<c019c8f8>] (imxdma_prep_dma_cyclic+0x0/0x168) from [<c024618c>] (snd_dmaengine_pcm_trigger+0xa8/0x160)
    [<c02460e4>] (snd_dmaengine_pcm_trigger+0x0/0x160) from [<c0241fa8>] (soc_pcm_trigger+0x90/0xb4)
     r8:c058c7b0 r7:c3b8140c r6:c39da560 r5:00000001 r4:c3b81000
    [<c0241f18>] (soc_pcm_trigger+0x0/0xb4) from [<c022ece4>] (snd_pcm_do_start+0x2c/0x38)
     r7:00000000 r6:00000003 r5:c058c7b0 r4:c3b81000
    [<c022ecb8>] (snd_pcm_do_start+0x0/0x38) from [<c022e958>] (snd_pcm_action_single+0x40/0x6c)
    [<c022e918>] (snd_pcm_action_single+0x0/0x6c) from [<c022ea64>] (snd_pcm_action_lock_irq+0x7c/0x9c)
     r7:00000003 r6:c3b810f0 r5:c3b810f0 r4:c3b81000
    [<c022e9e8>] (snd_pcm_action_lock_irq+0x0/0x9c) from [<c023009c>] (snd_pcm_common_ioctl1+0x7f8/0xfd0)
     r8:c3b7f888 r7:005407b8 r6:c2c991c0 r5:c3b81000 r4:c3b81000 r3:00004142
    [<c022f8a4>] (snd_pcm_common_ioctl1+0x0/0xfd0) from [<c023117c>] (snd_pcm_playback_ioctl1+0x464/0x488)
    [<c0230d18>] (snd_pcm_playback_ioctl1+0x0/0x488) from [<c02311d4>] (snd_pcm_playback_ioctl+0x34/0x40)
     r8:c3b7f888 r7:00004142 r6:00000004 r5:c2c991c0 r4:005407b8
    [<c02311a0>] (snd_pcm_playback_ioctl+0x0/0x40) from [<c00a14a4>] (vfs_ioctl+0x30/0x44)
    [<c00a1474>] (vfs_ioctl+0x0/0x44) from [<c00a1fe8>] (do_vfs_ioctl+0x55c/0x5c0)
    [<c00a1a8c>] (do_vfs_ioctl+0x0/0x5c0) from [<c00a208c>] (SyS_ioctl+0x40/0x68)
    [<c00a204c>] (SyS_ioctl+0x0/0x68) from [<c0009380>] (ret_fast_syscall+0x0/0x44)
     r8:c0009544 r7:00000036 r6:bedeaa58 r5:00000000 r4:000000c0
    
    Signed-off-by: Michael Grzeschik <m.grzeschik@pengutronix.de>
    Signed-off-by: Vinod Koul <vinod.koul@intel.com>
    Cc: Jonghwan Choi <jhbird.choi@samsung.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f9fa9891694cee70b74684e06bf9e9523d02677f
Author: Michael Grzeschik <m.grzeschik@pengutronix.de>
Date:   Tue Sep 17 15:56:08 2013 +0200

    dmaengine: imx-dma: fix callback path in tasklet
    
    commit fcaaba6c7136fe47e5a13352f99a64b019b6d2c5 upstream.
    
    We need to free the ld_active list head before jumping into the callback
    routine. Otherwise the callback could run into issue_pending and change
    our ld_active list head we just going to free. This will run the channel
    list into an currupted and undefined state.
    
    Signed-off-by: Michael Grzeschik <m.grzeschik@pengutronix.de>
    Signed-off-by: Vinod Koul <vinod.koul@intel.com>
    Cc: Jonghwan Choi <jhbird.choi@samsung.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0d2849483477202aa9e376460ad370c878d16781
Author: Michael Grzeschik <m.grzeschik@pengutronix.de>
Date:   Tue Sep 17 15:56:07 2013 +0200

    dmaengine: imx-dma: fix lockdep issue between irqhandler and tasklet
    
    commit 5a276fa6bdf82fd442046969603968c83626ce0b upstream.
    
    The tasklet and irqhandler are using spin_lock while other routines are
    using spin_lock_irqsave/restore. This leads to lockdep issues as
    described bellow. This patch is changing the code to use
    spinlock_irq_save/restore in both code pathes.
    
    As imxdma_xfer_desc always gets called with spin_lock_irqsave lock held,
    this patch also removes the spare call inside the routine to avoid
    double locking.
    
    [  403.358162] =================================
    [  403.362549] [ INFO: inconsistent lock state ]
    [  403.366945] 3.10.0-20130823+ #904 Not tainted
    [  403.371331] ---------------------------------
    [  403.375721] inconsistent {IN-HARDIRQ-W} -> {HARDIRQ-ON-W} usage.
    [  403.381769] swapper/0 [HC0[0]:SC1[1]:HE1:SE0] takes:
    [  403.386762]  (&(&imxdma->lock)->rlock){?.-...}, at: [<c019d77c>] imxdma_tasklet+0x20/0x134
    [  403.395201] {IN-HARDIRQ-W} state was registered at:
    [  403.400108]   [<c004b264>] mark_lock+0x2a0/0x6b4
    [  403.404798]   [<c004d7c8>] __lock_acquire+0x650/0x1a64
    [  403.410004]   [<c004f15c>] lock_acquire+0x94/0xa8
    [  403.414773]   [<c02f74e4>] _raw_spin_lock+0x54/0x8c
    [  403.419720]   [<c019d094>] dma_irq_handler+0x78/0x254
    [  403.424845]   [<c0061124>] handle_irq_event_percpu+0x38/0x1b4
    [  403.430670]   [<c00612e4>] handle_irq_event+0x44/0x64
    [  403.435789]   [<c0063a70>] handle_level_irq+0xd8/0xf0
    [  403.440903]   [<c0060a20>] generic_handle_irq+0x28/0x38
    [  403.446194]   [<c0009cc4>] handle_IRQ+0x68/0x8c
    [  403.450789]   [<c0008714>] avic_handle_irq+0x3c/0x48
    [  403.455811]   [<c0008f84>] __irq_svc+0x44/0x74
    [  403.460314]   [<c0040b04>] cpu_startup_entry+0x88/0xf4
    [  403.465525]   [<c02f00d0>] rest_init+0xb8/0xe0
    [  403.470045]   [<c03e07dc>] start_kernel+0x28c/0x2d4
    [  403.474986]   [<a0008040>] 0xa0008040
    [  403.478709] irq event stamp: 50854
    [  403.482140] hardirqs last  enabled at (50854): [<c001c6b8>] tasklet_action+0x38/0xdc
    [  403.489954] hardirqs last disabled at (50853): [<c001c6a0>] tasklet_action+0x20/0xdc
    [  403.497761] softirqs last  enabled at (50850): [<c001bc64>] _local_bh_enable+0x14/0x18
    [  403.505741] softirqs last disabled at (50851): [<c001c268>] irq_exit+0x88/0xdc
    [  403.513026]
    [  403.513026] other info that might help us debug this:
    [  403.519593]  Possible unsafe locking scenario:
    [  403.519593]
    [  403.525548]        CPU0
    [  403.528020]        ----
    [  403.530491]   lock(&(&imxdma->lock)->rlock);
    [  403.534828]   <Interrupt>
    [  403.537474]     lock(&(&imxdma->lock)->rlock);
    [  403.541983]
    [  403.541983]  *** DEADLOCK ***
    [  403.541983]
    [  403.547951] no locks held by swapper/0.
    [  403.551813]
    [  403.551813] stack backtrace:
    [  403.556222] CPU: 0 PID: 0 Comm: swapper Not tainted 3.10.0-20130823+ #904
    [  403.563039] Backtrace:
    [  403.565581] [<c000b98c>] (dump_backtrace+0x0/0x10c) from [<c000bb28>] (show_stack+0x18/0x1c)
    [  403.574054]  r6:00000000 r5:c05c51d8 r4:c040bd58 r3:00200000
    [  403.579872] [<c000bb10>] (show_stack+0x0/0x1c) from [<c02f398c>] (dump_stack+0x20/0x28)
    [  403.587955] [<c02f396c>] (dump_stack+0x0/0x28) from [<c02f29c8>] (print_usage_bug.part.28+0x224/0x28c)
    [  403.597340] [<c02f27a4>] (print_usage_bug.part.28+0x0/0x28c) from [<c004b404>] (mark_lock+0x440/0x6b4)
    [  403.606682]  r8:c004a41c r7:00000000 r6:c040bd58 r5:c040c040 r4:00000002
    [  403.613566] [<c004afc4>] (mark_lock+0x0/0x6b4) from [<c004d844>] (__lock_acquire+0x6cc/0x1a64)
    [  403.622244] [<c004d178>] (__lock_acquire+0x0/0x1a64) from [<c004f15c>] (lock_acquire+0x94/0xa8)
    [  403.631010] [<c004f0c8>] (lock_acquire+0x0/0xa8) from [<c02f74e4>] (_raw_spin_lock+0x54/0x8c)
    [  403.639614] [<c02f7490>] (_raw_spin_lock+0x0/0x8c) from [<c019d77c>] (imxdma_tasklet+0x20/0x134)
    [  403.648434]  r6:c3847010 r5:c040e890 r4:c38470d4
    [  403.653194] [<c019d75c>] (imxdma_tasklet+0x0/0x134) from [<c001c70c>] (tasklet_action+0x8c/0xdc)
    [  403.662013]  r8:c0599160 r7:00000000 r6:00000000 r5:c040e890 r4:c3847114 r3:c019d75c
    [  403.670042] [<c001c680>] (tasklet_action+0x0/0xdc) from [<c001bd4c>] (__do_softirq+0xe4/0x1f0)
    [  403.678687]  r7:00000101 r6:c0402000 r5:c059919c r4:00000001
    [  403.684498] [<c001bc68>] (__do_softirq+0x0/0x1f0) from [<c001c268>] (irq_exit+0x88/0xdc)
    [  403.692652] [<c001c1e0>] (irq_exit+0x0/0xdc) from [<c0009cc8>] (handle_IRQ+0x6c/0x8c)
    [  403.700514]  r4:00000030 r3:00000110
    [  403.704192] [<c0009c5c>] (handle_IRQ+0x0/0x8c) from [<c0008714>] (avic_handle_irq+0x3c/0x48)
    [  403.712664]  r5:c0403f28 r4:c0593ebc
    [  403.716343] [<c00086d8>] (avic_handle_irq+0x0/0x48) from [<c0008f84>] (__irq_svc+0x44/0x74)
    [  403.724733] Exception stack(0xc0403f28 to 0xc0403f70)
    [  403.729841] 3f20:                   00000001 00000004 00000000 20000013 c0402000 c04104a8
    [  403.738078] 3f40: 00000002 c0b69620 a0004000 41069264 a03fb5f4 c0403f7c c0403f40 c0403f70
    [  403.746301] 3f60: c004b92c c0009e74 20000013 ffffffff
    [  403.751383]  r6:ffffffff r5:20000013 r4:c0009e74 r3:c004b92c
    [  403.757210] [<c0009e30>] (arch_cpu_idle+0x0/0x4c) from [<c0040b04>] (cpu_startup_entry+0x88/0xf4)
    [  403.766161] [<c0040a7c>] (cpu_startup_entry+0x0/0xf4) from [<c02f00d0>] (rest_init+0xb8/0xe0)
    [  403.774753] [<c02f0018>] (rest_init+0x0/0xe0) from [<c03e07dc>] (start_kernel+0x28c/0x2d4)
    [  403.783051]  r6:c03fc484 r5:ffffffff r4:c040a0e0
    [  403.787797] [<c03e0550>] (start_kernel+0x0/0x2d4) from [<a0008040>] (0xa0008040)
    
    Signed-off-by: Michael Grzeschik <m.grzeschik@pengutronix.de>
    Signed-off-by: Vinod Koul <vinod.koul@intel.com>
    Cc: Jonghwan Choi <jhbird.choi@samsung.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 681231c66e1953a91addca97eb83d5565d3bffaa
Author: Rafał Miłecki <zajec5@gmail.com>
Date:   Tue Oct 8 11:36:58 2013 +0200

    drm/radeon: fix hdmi callbacks for rv6xx (incorrectly added to r520)
    
    Commit 99d79aa2f3b7729e7290e8bda5d0dd8b0240ec62 was backported slightly
    wrong adding callbacks in the wrong struct. This moves callbacks to the
    correct place (matching mainline patch/code).
    
    Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
    Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3e1fee600177eed70abbd7e7703a40b5edb6cb8f
Author: Frederic Weisbecker <fweisbec@gmail.com>
Date:   Tue Sep 24 00:50:25 2013 +0200

    irq: Force hardirq exit's softirq processing on its own stack
    
    commit ded797547548a5b8e7b92383a41e4c0e6b0ecb7f upstream.
    
    The commit facd8b80c67a3cf64a467c4a2ac5fb31f2e6745b
    ("irq: Sanitize invoke_softirq") converted irq exit
    calls of do_softirq() to __do_softirq() on all architectures,
    assuming it was only used there for its irq disablement
    properties.
    
    But as a side effect, the softirqs processed in the end
    of the hardirq are always called on the inline current
    stack that is used by irq_exit() instead of the softirq
    stack provided by the archs that override do_softirq().
    
    The result is mostly safe if the architecture runs irq_exit()
    on a separate irq stack because then softirqs are processed
    on that same stack that is near empty at this stage (assuming
    hardirq aren't nesting).
    
    Otherwise irq_exit() runs in the task stack and so does the softirq
    too. The interrupted call stack can be randomly deep already and
    the softirq can dig through it even further. To add insult to the
    injury, this softirq can be interrupted by a new hardirq, maximizing
    the chances for a stack overrun as reported in powerpc for example:
    
    	do_IRQ: stack overflow: 1920
    	CPU: 0 PID: 1602 Comm: qemu-system-ppc Not tainted 3.10.4-300.1.fc19.ppc64p7 #1
    	Call Trace:
    	[c0000000050a8740] .show_stack+0x130/0x200 (unreliable)
    	[c0000000050a8810] .dump_stack+0x28/0x3c
    	[c0000000050a8880] .do_IRQ+0x2b8/0x2c0
    	[c0000000050a8930] hardware_interrupt_common+0x154/0x180
    	--- Exception: 501 at .cp_start_xmit+0x3a4/0x820 [8139cp]
    		LR = .cp_start_xmit+0x390/0x820 [8139cp]
    	[c0000000050a8d40] .dev_hard_start_xmit+0x394/0x640
    	[c0000000050a8e00] .sch_direct_xmit+0x110/0x260
    	[c0000000050a8ea0] .dev_queue_xmit+0x260/0x630
    	[c0000000050a8f40] .br_dev_queue_push_xmit+0xc4/0x130 [bridge]
    	[c0000000050a8fc0] .br_dev_xmit+0x198/0x270 [bridge]
    	[c0000000050a9070] .dev_hard_start_xmit+0x394/0x640
    	[c0000000050a9130] .dev_queue_xmit+0x428/0x630
    	[c0000000050a91d0] .ip_finish_output+0x2a4/0x550
    	[c0000000050a9290] .ip_local_out+0x50/0x70
    	[c0000000050a9310] .ip_queue_xmit+0x148/0x420
    	[c0000000050a93b0] .tcp_transmit_skb+0x4e4/0xaf0
    	[c0000000050a94a0] .__tcp_ack_snd_check+0x7c/0xf0
    	[c0000000050a9520] .tcp_rcv_established+0x1e8/0x930
    	[c0000000050a95f0] .tcp_v4_do_rcv+0x21c/0x570
    	[c0000000050a96c0] .tcp_v4_rcv+0x734/0x930
    	[c0000000050a97a0] .ip_local_deliver_finish+0x184/0x360
    	[c0000000050a9840] .ip_rcv_finish+0x148/0x400
    	[c0000000050a98d0] .__netif_receive_skb_core+0x4f8/0xb00
    	[c0000000050a99d0] .netif_receive_skb+0x44/0x110
    	[c0000000050a9a70] .br_handle_frame_finish+0x2bc/0x3f0 [bridge]
    	[c0000000050a9b20] .br_nf_pre_routing_finish+0x2ac/0x420 [bridge]
    	[c0000000050a9bd0] .br_nf_pre_routing+0x4dc/0x7d0 [bridge]
    	[c0000000050a9c70] .nf_iterate+0x114/0x130
    	[c0000000050a9d30] .nf_hook_slow+0xb4/0x1e0
    	[c0000000050a9e00] .br_handle_frame+0x290/0x330 [bridge]
    	[c0000000050a9ea0] .__netif_receive_skb_core+0x34c/0xb00
    	[c0000000050a9fa0] .netif_receive_skb+0x44/0x110
    	[c0000000050aa040] .napi_gro_receive+0xe8/0x120
    	[c0000000050aa0c0] .cp_rx_poll+0x31c/0x590 [8139cp]
    	[c0000000050aa1d0] .net_rx_action+0x1dc/0x310
    	[c0000000050aa2b0] .__do_softirq+0x158/0x330
    	[c0000000050aa3b0] .irq_exit+0xc8/0x110
    	[c0000000050aa430] .do_IRQ+0xdc/0x2c0
    	[c0000000050aa4e0] hardware_interrupt_common+0x154/0x180
    	 --- Exception: 501 at .bad_range+0x1c/0x110
    		 LR = .get_page_from_freelist+0x908/0xbb0
    	[c0000000050aa7d0] .list_del+0x18/0x50 (unreliable)
    	[c0000000050aa850] .get_page_from_freelist+0x908/0xbb0
    	[c0000000050aa9e0] .__alloc_pages_nodemask+0x21c/0xae0
    	[c0000000050aaba0] .alloc_pages_vma+0xd0/0x210
    	[c0000000050aac60] .handle_pte_fault+0x814/0xb70
    	[c0000000050aad50] .__get_user_pages+0x1a4/0x640
    	[c0000000050aae60] .get_user_pages_fast+0xec/0x160
    	[c0000000050aaf10] .__gfn_to_pfn_memslot+0x3b0/0x430 [kvm]
    	[c0000000050aafd0] .kvmppc_gfn_to_pfn+0x64/0x130 [kvm]
    	[c0000000050ab070] .kvmppc_mmu_map_page+0x94/0x530 [kvm]
    	[c0000000050ab190] .kvmppc_handle_pagefault+0x174/0x610 [kvm]
    	[c0000000050ab270] .kvmppc_handle_exit_pr+0x464/0x9b0 [kvm]
    	[c0000000050ab320]  kvm_start_lightweight+0x1ec/0x1fc [kvm]
    	[c0000000050ab4f0] .kvmppc_vcpu_run_pr+0x168/0x3b0 [kvm]
    	[c0000000050ab9c0] .kvmppc_vcpu_run+0xc8/0xf0 [kvm]
    	[c0000000050aba50] .kvm_arch_vcpu_ioctl_run+0x5c/0x1a0 [kvm]
    	[c0000000050abae0] .kvm_vcpu_ioctl+0x478/0x730 [kvm]
    	[c0000000050abc90] .do_vfs_ioctl+0x4ec/0x7c0
    	[c0000000050abd80] .SyS_ioctl+0xd4/0xf0
    	[c0000000050abe30] syscall_exit+0x0/0x98
    
    Since this is a regression, this patch proposes a minimalistic
    and low-risk solution by blindly forcing the hardirq exit processing of
    softirqs on the softirq stack. This way we should reduce significantly
    the opportunities for task stack overflow dug by softirqs.
    
    Longer term solutions may involve extending the hardirq stack coverage to
    irq_exit(), etc...
    
    Reported-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
    Acked-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Frederic Weisbecker <fweisbec@gmail.com>
    Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
    Cc: Paul Mackerras <paulus@au1.ibm.com>
    Cc: Ingo Molnar <mingo@kernel.org>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: H. Peter Anvin <hpa@zytor.com>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Paul Mackerras <paulus@au1.ibm.com>
    Cc: James Hogan <james.hogan@imgtec.com>
    Cc: James E.J. Bottomley <jejb@parisc-linux.org>
    Cc: Helge Deller <deller@gmx.de>
    Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
    Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
    Cc: David S. Miller <davem@davemloft.net>
    Cc: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3eb17daca655363dfd12241f50837b8593cd5ec7
Author: Eric W. Biederman <ebiederm@xmission.com>
Date:   Sat Oct 5 13:15:30 2013 -0700

    net: Update the sysctl permissions handler to test effective uid/gid
    
    commit 2433c8f094a008895e66f25bd1773cdb01c91d01 upstream.
    
    Modify the code to use current_euid(), and in_egroup_p, as in done
    in fs/proc/proc_sysctl.c:test_perm()
    
    Reviewed-by: Eric Sandeen <sandeen@redhat.com>
    Reported-by: Eric Sandeen <sandeen@redhat.com>
    Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 67c90f9d826e5cee09d3dcb4554462f0ba6df38e
Author: Nicholas Bellinger <nab@linux-iscsi.org>
Date:   Thu Oct 3 13:37:21 2013 -0700

    iscsi-target: Only perform wait_for_tasks when performing shutdown
    
    commit e255a28598e8e63070322fc89bd34189dd660a89 upstream.
    
    This patch changes transport_generic_free_cmd() to only wait_for_tasks
    when shutdown=true is passed to iscsit_free_cmd().
    
    With the advent of >= v3.10 iscsi-target code using se_cmd->cmd_kref,
    the extra wait_for_tasks with shutdown=false is unnecessary, and may
    end up causing an extra context switch when releasing WRITEs.
    
    Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 126f292a117cf69989c0d17169abfdd715619c7b
Author: Rafael Aquini <aquini@redhat.com>
Date:   Mon Sep 30 13:45:16 2013 -0700

    mm: avoid reinserting isolated balloon pages into LRU lists
    
    commit 117aad1e9e4d97448d1df3f84b08bd65811e6d6a upstream.
    
    Isolated balloon pages can wrongly end up in LRU lists when
    migrate_pages() finishes its round without draining all the isolated
    page list.
    
    The same issue can happen when reclaim_clean_pages_from_list() tries to
    reclaim pages from an isolated page list, before migration, in the CMA
    path.  Such balloon page leak opens a race window against LRU lists
    shrinkers that leads us to the following kernel panic:
    
      BUG: unable to handle kernel NULL pointer dereference at 0000000000000028
      IP: [<ffffffff810c2625>] shrink_page_list+0x24e/0x897
      PGD 3cda2067 PUD 3d713067 PMD 0
      Oops: 0000 [#1] SMP
      CPU: 0 PID: 340 Comm: kswapd0 Not tainted 3.12.0-rc1-22626-g4367597 #87
      Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
      RIP: shrink_page_list+0x24e/0x897
      RSP: 0000:ffff88003da499b8  EFLAGS: 00010286
      RAX: 0000000000000000 RBX: ffff88003e82bd60 RCX: 00000000000657d5
      RDX: 0000000000000000 RSI: 000000000000031f RDI: ffff88003e82bd40
      RBP: ffff88003da49ab0 R08: 0000000000000001 R09: 0000000081121a45
      R10: ffffffff81121a45 R11: ffff88003c4a9a28 R12: ffff88003e82bd40
      R13: ffff88003da0e800 R14: 0000000000000001 R15: ffff88003da49d58
      FS:  0000000000000000(0000) GS:ffff88003fc00000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: 00000000067d9000 CR3: 000000003ace5000 CR4: 00000000000407b0
      Call Trace:
        shrink_inactive_list+0x240/0x3de
        shrink_lruvec+0x3e0/0x566
        __shrink_zone+0x94/0x178
        shrink_zone+0x3a/0x82
        balance_pgdat+0x32a/0x4c2
        kswapd+0x2f0/0x372
        kthread+0xa2/0xaa
        ret_from_fork+0x7c/0xb0
      Code: 80 7d 8f 01 48 83 95 68 ff ff ff 00 4c 89 e7 e8 5a 7b 00 00 48 85 c0 49 89 c5 75 08 80 7d 8f 00 74 3e eb 31 48 8b 80 18 01 00 00 <48> 8b 74 0d 48 8b 78 30 be 02 00 00 00 ff d2 eb
      RIP  [<ffffffff810c2625>] shrink_page_list+0x24e/0x897
       RSP <ffff88003da499b8>
      CR2: 0000000000000028
      ---[ end trace 703d2451af6ffbfd ]---
      Kernel panic - not syncing: Fatal exception
    
    This patch fixes the issue, by assuring the proper tests are made at
    putback_movable_pages() & reclaim_clean_pages_from_list() to avoid
    isolated balloon pages being wrongly reinserted in LRU lists.
    
    [akpm@linux-foundation.org: clarify awkward comment text]
    Signed-off-by: Rafael Aquini <aquini@redhat.com>
    Reported-by: Luiz Capitulino <lcapitulino@redhat.com>
    Tested-by: Luiz Capitulino <lcapitulino@redhat.com>
    Cc: Mel Gorman <mel@csn.ul.ie>
    Cc: Rik van Riel <riel@redhat.com>
    Cc: Hugh Dickins <hughd@google.com>
    Cc: Johannes Weiner <hannes@cmpxchg.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 95f985cc6a26d421ddd6617822235dd4597c13ea
Author: Christian Lamparter <chunkeey@googlemail.com>
Date:   Tue Sep 24 21:56:46 2013 +0200

    p54usb: add USB ID for Corega WLUSB2GTST USB adapter
    
    commit 1e43692cdb7cc445d6347d8a5207d9cef0c71434 upstream.
    
    Added USB ID for Corega WLUSB2GTST USB adapter.
    
    Reported-by: Joerg Kalisch <the_force@gmx.de>
    Signed-off-by: Christian Lamparter <chunkeey@googlemail.com>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a349c365d5db2b96780078249c73285ac2941920
Author: Larry Finger <Larry.Finger@lwfinger.net>
Date:   Wed Sep 18 21:21:35 2013 -0500

    rtlwifi: Align private space in rtl_priv struct
    
    commit 60ce314d1750fef843e9db70050e09e49f838b69 upstream.
    
    The private array at the end of the rtl_priv struct is not aligned.
    On ARM architecture, this causes an alignment trap and is fixed by aligning
    that array with __align(sizeof(void *)). That should properly align that
    space according to the requirements of all architectures.
    
    Reported-by: Jason Andrews <jasona@cadence.com>
    Tested-by: Jason Andrews <jasona@cadence.com>
    Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5cd8446d12b70185dc2a89993e5b58d5623d9432
Author: Jack Wang <jinpu.wang@profitbricks.com>
Date:   Mon Sep 30 10:09:05 2013 +0200

    ib_srpt: always set response for task management
    
    commit c807f64340932e19f0d2ac9b30c8381e1f60663a upstream.
    
    The SRP specification requires:
    
      "Response data shall be provided in any SRP_RSP response that is sent in
       response to an SRP_TSK_MGMT request (see 6.7). The information in the
       RSP_CODE field (see table 24) shall indicate the completion status of
       the task management function."
    
    So fix this to avoid the SRP initiator interprets task management functions
    that succeeded as failed.
    
    Signed-off-by: Jack Wang <jinpu.wang@profitbricks.com>
    Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 08c8454beba7398842b7d5310d69f9e6ce3b8f47
Author: Nicholas Bellinger <nab@linux-iscsi.org>
Date:   Wed Sep 18 12:48:27 2013 -0700

    ib_srpt: Destroy cm_id before destroying QP.
    
    commit 0b41d6ca616ddeb3b6c0a80e8770b6f53cd42806 upstream.
    
    This patch fixes a bug where ib_destroy_cm_id() was incorrectly being called
    after srpt_destroy_ch_ib() had destroyed the active QP.
    
    This would result in the following failed SRP_LOGIN_REQ messages:
    
    Received SRP_LOGIN_REQ with i_port_id 0x0:0x2590ffff1762bd, t_port_id 0x2c903009f8f40:0x2c903009f8f40 and it_iu_len 260 on port 1 (guid=0xfe80000000000000:0x2c903009f8f41)
    Received SRP_LOGIN_REQ with i_port_id 0x0:0x2590ffff1758f9, t_port_id 0x2c903009f8f40:0x2c903009f8f40 and it_iu_len 260 on port 2 (guid=0xfe80000000000000:0x2c903009f8f42)
    Received SRP_LOGIN_REQ with i_port_id 0x0:0x2590ffff175941, t_port_id 0x2c903009f8f40:0x2c903009f8f40 and it_iu_len 260 on port 2 (guid=0xfe80000000000000:0x2c90300a3cfb2)
    Received SRP_LOGIN_REQ with i_port_id 0x0:0x2590ffff176299, t_port_id 0x2c903009f8f40:0x2c903009f8f40 and it_iu_len 260 on port 1 (guid=0xfe80000000000000:0x2c90300a3cfb1)
    mlx4_core 0000:84:00.0: command 0x19 failed: fw status = 0x9
    rejected SRP_LOGIN_REQ because creating a new RDMA channel failed.
    Received SRP_LOGIN_REQ with i_port_id 0x0:0x2590ffff176299, t_port_id 0x2c903009f8f40:0x2c903009f8f40 and it_iu_len 260 on port 1 (guid=0xfe80000000000000:0x2c90300a3cfb1)
    mlx4_core 0000:84:00.0: command 0x19 failed: fw status = 0x9
    rejected SRP_LOGIN_REQ because creating a new RDMA channel failed.
    Received SRP_LOGIN_REQ with i_port_id 0x0:0x2590ffff176299, t_port_id 0x2c903009f8f40:0x2c903009f8f40 and it_iu_len 260 on port 1 (guid=0xfe80000000000000:0x2c90300a3cfb1)
    
    Reported-by: Navin Ahuja <navin.ahuja@saratoga-speed.com>
    Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 38038ddd5b625af75f038501ae5e0f07ed892f95
Author: David Vrabel <david.vrabel@citrix.com>
Date:   Tue Oct 1 19:00:49 2013 +0100

    xen/hvc: allow xenboot console to be used again
    
    commit a9fbf4d591da6cd1d3eaab826c7c15f77fc8f6a3 upstream.
    
    Commit d0380e6c3c0f6edb986d8798a23acfaf33d5df23 (early_printk:
    consolidate random copies of identical code) added in 3.10 introduced
    a check for con->index == -1 in early_console_register().
    
    Initialize index to -1 for the xenboot console so earlyprintk=xen
    works again.
    
    Signed-off-by: David Vrabel <david.vrabel@citrix.com>
    Cc: Jiri Slaby <jslaby@suse.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit daf2f72265f68c1c1100d1bc6a4c4faed0344be2
Author: Michal Malý <madcatxster@prifuk.cz>
Date:   Sat Sep 28 19:50:27 2013 +0200

    USB: serial: option: Ignore card reader interface on Huawei E1750
    
    commit eb2addd4044b4b2ce77693bde5bc810536dd96ee upstream.
    
    Hi,
    
    my Huawei 3G modem has an embedded Smart Card reader which causes
    trouble when the modem is being detected (a bunch of "<warn>  (ttyUSBx):
    open blocked by driver for more than 7 seconds!" in messages.log). This
    trivial patch corrects the problem for me. The modem identifies itself
    as "12d1:1406 Huawei Technologies Co., Ltd. E1750" in lsusb although the
    description on the body says "Model E173u-1"
    
    Signed-off-by: Michal Malý <madcatxster@prifuk.cz>
    Cc: Bjørn Mork <bjorn@mork.no>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit de1ea2e145864889db295e1723386fa986aa1fd6
Author: David Cohen <david.a.cohen@linux.intel.com>
Date:   Tue Oct 1 14:32:58 2013 -0700

    usb: chipidea: add Intel Clovertrail pci id
    
    commit a214339d764a07b99dc0418685d6cc8a0a1970d5 upstream.
    
    Also clean up the last item of the pci id list to be "cleaner".
    
    Signed-off-by: David Cohen <david.a.cohen@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3ebf6d7dae94cd4a92cf23d428bc9f196835e6f2
Author: Bing Zhao <bzhao@marvell.com>
Date:   Fri Sep 20 19:56:45 2013 -0700

    mwifiex: fix PCIe hs_cfg cancel cmd timeout
    
    commit b7be1522def9a9988b67afd0be999c50a96394b5 upstream.
    
    For pcie8897, the hs_cfg cancel command (0xe5) times out when host
    comes out of suspend. This is caused by an incompleted host sleep
    handshake between driver and firmware.
    
    Like SDIO interface, PCIe also needs to go through firmware power
    save events to complete the handshake for host sleep configuration.
    Only USB interface doesn't require power save events for hs_cfg.
    
    Signed-off-by: Bing Zhao <bzhao@marvell.com>
    Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit eaac40050d90a35e97cf965529de4c5ef127d0d4
Author: Amitkumar Karwar <akarwar@marvell.com>
Date:   Tue Sep 24 19:31:24 2013 -0700

    mwifiex: fix hang issue for USB chipsets
    
    commit bd1c6142edce787b8ac1be15635f845aa9905333 upstream.
    
    Bug 60815 - Interface hangs in mwifiex_usb
    https://bugzilla.kernel.org/show_bug.cgi?id=60815
    
    We have 4 bytes of interface header for packets delivered to SDIO
    and PCIe, but not for USB interface.
    
    In Tx AMSDU case, currently 4 bytes of garbage data is unnecessarily
    appended for USB packets. This sometimes leads to a firmware hang,
    because it may not interpret the data packet correctly.
    
    Problem is fixed by removing this redundant headroom for USB.
    
    Tested-by: Dmitry Khromov <icechrome@gmail.com>
    Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
    Signed-off-by: Bing Zhao <bzhao@marvell.com>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1d1f004891d5aa00ee75974e4864e8d5b321e491
Author: Bing Zhao <bzhao@marvell.com>
Date:   Tue Sep 24 19:31:25 2013 -0700

    mwifiex: fix NULL pointer dereference in usb suspend handler
    
    commit 346ece0b7ba2730b4d633b9e371fe55488803102 upstream.
    
    Bug 60815 - Interface hangs in mwifiex_usb
    https://bugzilla.kernel.org/show_bug.cgi?id=60815
    
    [ 2.883807] BUG: unable to handle kernel NULL pointer dereference
                at 0000000000000048
    [ 2.883813] IP: [<ffffffff815a65e0>] pfifo_fast_enqueue+0x90/0x90
    
    [ 2.883834] CPU: 1 PID: 3220 Comm: kworker/u8:90 Not tainted
                3.11.1-monotone-l0 #6
    [ 2.883834] Hardware name: Microsoft Corporation Surface with
                Windows 8 Pro/Surface with Windows 8 Pro,
                BIOS 1.03.0450 03/29/2013
    
    On Surface Pro, suspend to ram gives a NULL pointer dereference in
    pfifo_fast_enqueue(). The stack trace reveals that the offending
    call is clearing carrier in mwifiex_usb suspend handler.
    
    Since commit 1499d9f "mwifiex: don't drop carrier flag over suspend"
    has removed the carrier flag handling over suspend/resume in SDIO
    and PCIe drivers, I'm removing it in USB driver too. This also fixes
    the bug for Surface Pro.
    
    Tested-by: Dmitry Khromov <icechrome@gmail.com>
    Signed-off-by: Bing Zhao <bzhao@marvell.com>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3b12032f89e27f139828bad8120149b1584bc898
Author: Trond Myklebust <Trond.Myklebust@netapp.com>
Date:   Thu Sep 26 14:08:36 2013 -0400

    NFSv4.1: nfs4_fl_prepare_ds - fix bugs when the connect attempt fails
    
    commit 52b26a3e1bb3e065c32b3febdac1e1f117d88e15 upstream.
    
    - Fix an Oops when nfs4_ds_connect() returns an error.
    - Always check the device status after waiting for a connect to complete.
    
    Reported-by: Andy Adamson <andros@netapp.com>
    Reported-by: Jeff Layton <jlayton@redhat.com>
    Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d6170004af8bed70922ef94fa404ccb617d000e5
Author: Ian Abbott <abbotti@mev.co.uk>
Date:   Wed Oct 2 14:57:51 2013 +0100

    staging: comedi: ni_65xx: (bug fix) confine insn_bits to one subdevice
    
    commit 677a31565692d596ef42ea589b53ba289abf4713 upstream.
    
    The `insn_bits` handler `ni_65xx_dio_insn_bits()` has a `for` loop that
    currently writes (optionally) and reads back up to 5 "ports" consisting
    of 8 channels each.  It reads up to 32 1-bit channels but can only read
    and write a whole port at once - it needs to handle up to 5 ports as the
    first channel it reads might not be aligned on a port boundary.  It
    breaks out of the loop early if the next port it handles is beyond the
    final port on the card.  It also breaks out early on the 5th port in the
    loop if the first channel was aligned.  Unfortunately, it doesn't check
    that the current port it is dealing with belongs to the comedi subdevice
    the `insn_bits` handler is acting on.  That's a bug.
    
    Redo the `for` loop to terminate after the final port belonging to the
    subdevice, changing the loop variable in the process to simplify things
    a bit.  The `for` loop could now try and handle more than 5 ports if the
    subdevice has more than 40 channels, but the test `if (bitshift >= 32)`
    ensures it will break out early after 4 or 5 ports (depending on whether
    the first channel is aligned on a port boundary).  (`bitshift` will be
    between -7 and 7 inclusive on the first iteration, increasing by 8 for
    each subsequent operation.)
    
    Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 29416e26236a2e6b9cfe67260835300dc07b2d26
Author: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Date:   Mon Sep 30 13:45:08 2013 -0700

    kernel/kmod.c: check for NULL in call_usermodehelper_exec()
    
    commit 4c1c7be95c345cf2ad537a0c48e9aeadc7304527 upstream.
    
    If /proc/sys/kernel/core_pattern contains only "|", a NULL pointer
    dereference happens upon core dump because argv_split("") returns
    argv[0] == NULL.
    
    This bug was once fixed by commit 264b83c07a84 ("usermodehelper: check
    subprocess_info->path != NULL") but was by error reintroduced by commit
    7f57cfa4e2aa ("usermodehelper: kill the sub_info->path[0] check").
    
    This bug seems to exist since 2.6.19 (the version which core dump to
    pipe was added).  Depending on kernel version and config, some side
    effect might happen immediately after this oops (e.g.  kernel panic with
    2.6.32-358.18.1.el6).
    
    Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
    Acked-by: Oleg Nesterov <oleg@redhat.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 3e446da23ffc230fbd3d9cf52f2a2d94ba8e941c
Author: Darrick J. Wong <darrick.wong@oracle.com>
Date:   Mon Sep 30 13:45:09 2013 -0700

    mm/bounce.c: fix a regression where MS_SNAP_STABLE (stable pages snapshotting) was ignored
    
    commit 83b2944fd2532b92db099cb3ada12df32a05b368 upstream.
    
    The "force" parameter in __blk_queue_bounce was being ignored, which
    means that stable page snapshots are not always happening (on ext3).
    This of course leads to DIF disks reporting checksum errors, so fix this
    regression.
    
    The regression was introduced in commit 6bc454d15004 ("bounce: Refactor
    __blk_queue_bounce to not use bi_io_vec")
    
    Reported-by: Mel Gorman <mgorman@suse.de>
    Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
    Cc: Kent Overstreet <koverstreet@google.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b8a118efef12f11e6f726d46b9d918200d59e479
Author: David Miller <davem@davemloft.net>
Date:   Wed Oct 2 14:25:09 2013 -0400

    mm: Fix generic hugetlb pte check return type.
    
    [ Upstream commit 26794942461f438a6bc725ec7294b08a6bd782c4 ]
    
    The include/asm-generic/hugetlb.h stubs that just vector huge_pte_*()
    calls to the pte_*() implementations won't work in certain situations.
    
    x86 and sparc, for example, return "unsigned long" from the bit
    checks, and just go "return pte_val(pte) & PTE_BIT_FOO;"
    
    But since huge_pte_*() returns 'int', if any high bits on 64-bit are
    relevant, they get chopped off.
    
    The net effect is that we can loop forever trying to COW a huge page,
    because the huge_pte_write() check signals false all the time.
    
    Reported-by: Gurudas Pai <gurudas.pai@oracle.com>
    Tested-by: Gurudas Pai <gurudas.pai@oracle.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Acked-by: David Rientjes <rientjes@google.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8e810c7aabe8a9c7451a7ef2fd2fe09ad6fafae5
Author: Kirill Tkhai <tkhai@yandex.ru>
Date:   Fri Jul 26 01:17:15 2013 +0400

    sparc32: Fix exit flag passed from traced sys_sigreturn
    
    [ Upstream commit 7a3b0f89e3fea680f93932691ca41a68eee7ab5e ]
    
    Pass 1 in %o1 to indicate that syscall_trace accounts exit.
    
    Signed-off-by: Kirill Tkhai <tkhai@yandex.ru>
    CC: David Miller <davem@davemloft.net>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a2a4623f0cdb10525a69f52bfe4ff8e51f889dc2
Author: Kirill Tkhai <tkhai@yandex.ru>
Date:   Fri Jul 26 17:21:12 2013 +0400

    sparc64: Fix not SRA'ed %o5 in 32-bit traced syscall
    
    [ Upstream commit ab2abda6377723e0d5fbbfe5f5aa16a5523344d1 ]
    
    (From v1 to v2: changed comment)
    
    On the way linux_sparc_syscall32->linux_syscall_trace32->goto 2f,
    register %o5 doesn't clear its second 32-bit.
    
    Fix that.
    
    Signed-off-by: Kirill Tkhai <tkhai@yandex.ru>
    CC: David Miller <davem@davemloft.net>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3a55b1aeb552077db8b6700e9a93a16ca1a8d94b
Author: David S. Miller <davem@davemloft.net>
Date:   Thu Aug 22 16:38:46 2013 -0700

    sparc64: Fix off by one in trampoline TLB mapping installation loop.
    
    [ Upstream commit 63d499662aeec1864ec36d042aca8184ea6a938e ]
    
    Reported-by: Kirill Tkhai <tkhai@yandex.ru>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7de5c6bba258f2d3390ed73c938a98f15440213b
Author: David S. Miller <davem@davemloft.net>
Date:   Thu Aug 1 18:08:34 2013 -0700

    esp_scsi: Fix tag state corruption when autosensing.
    
    [ Upstream commit 21af8107f27878813d0364733c0b08813c2c192a ]
    
    Meelis Roos reports a crash in esp_free_lun_tag() in the presense
    of a disk which has died.
    
    The issue is that when we issue an autosense command, we do so by
    hijacking the original command that caused the check-condition.
    
    When we do so we clear out the ent->tag[] array when we issue it via
    find_and_prep_issuable_command().  This is so that the autosense
    command is forced to be issued non-tagged.
    
    That is problematic, because it is the value of ent->tag[] which
    determines whether we issued the original scsi command as tagged
    vs. non-tagged (see esp_alloc_lun_tag()).
    
    And that, in turn, is what trips up the sanity checks in
    esp_free_lun_tag().  That function needs the original ->tag[] values
    in order to free up the tag slot properly.
    
    Fix this by remembering the original command's tag values, and
    having esp_alloc_lun_tag() and esp_free_lun_tag() use them.
    
    Reported-by: Meelis Roos <mroos@linux.ee>
    Tested-by: Meelis Roos <mroos@linux.ee>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1e0a3f6f4660aca6578d768038972cd12727f64d
Author: Kirill Tkhai <tkhai@yandex.ru>
Date:   Fri Aug 2 19:23:18 2013 +0400

    sparc64: Fix ITLB handler of null page
    
    [ Upstream commit 1c2696cdaad84580545a2e9c0879ff597880b1a9 ]
    
    1)Use kvmap_itlb_longpath instead of kvmap_dtlb_longpath.
    
    2)Handle page #0 only, don't handle page #1: bleu -> blu
    
     (KERNBASE is 0x400000, so #1 does not exist too. But everything
      is possible in the future. Fix to not to have problems later.)
    
    3)Remove unused kvmap_itlb_nonlinear.
    
    Signed-off-by: Kirill Tkhai <tkhai@yandex.ru>
    CC: David Miller <davem@davemloft.net>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 47da75cd1eccef5e203c326bcf74a70701d4f158
Author: Kirill Tkhai <tkhai@yandex.ru>
Date:   Mon Aug 12 16:02:24 2013 +0400

    sparc64: Remove RWSEM export leftovers
    
    [ Upstream commit 61d9b9355b0d427bd1e732bd54628ff9103e496f ]
    
    The functions
    
    			__down_read
    			__down_read_trylock
    			__down_write
    			__down_write_trylock
    			__up_read
    			__up_write
    			__downgrade_write
    
    are implemented inline, so remove corresponding EXPORT_SYMBOLs
    (They lead to compile errors on RT kernel).
    
    Signed-off-by: Kirill Tkhai <tkhai@yandex.ru>
    CC: David Miller <davem@davemloft.net>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e07bd058eae5c8c210e9238ef1895b80d628952d
Author: Kees Cook <keescook@chromium.org>
Date:   Tue Oct 1 22:13:34 2013 -0700

    sparc: fix ldom_reboot buffer overflow harder
    
    [ Upstream commit 20928bd3f08afb036c096d9559d581926b895918 ]
    
    The length argument to strlcpy was still wrong. It could overflow the end of
    full_boot_str by 5 bytes. Instead of strcat and strlcpy, just use snprint.
    
    Reported-by: Brad Spengler <spender@grsecurity.net>
    Signed-off-by: Kees Cook <keescook@chromium.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit bbe57190784d7a3bc024853da48e0eef5b5c4b2e
Author: David S. Miller <davem@davemloft.net>
Date:   Fri Sep 27 13:46:04 2013 -0700

    sparc64: Fix buggy strlcpy() conversion in ldom_reboot().
    
    [ Upstream commit 2bd161a605f1f84a5fc8a4fe8410113a94f79355 ]
    
    Commit 117a0c5fc9c2d06045bd217385b2b39ea426b5a6 ("sparc: kernel: using
    strlcpy() instead of strcpy()") added a bug to ldom_reboot in
    arch/sparc/kernel/ds.c
    
    -		strcpy(full_boot_str + strlen("boot "), boot_command);
    +				     strlcpy(full_boot_str + strlen("boot "), boot_command,
    +				     			     sizeof(full_boot_str + strlen("boot ")));
    
    That last sizeof() expression evaluates to sizeof(size_t) which is
    not what was intended.
    
    Also even the corrected:
    
         sizeof(full_boot_str) + strlen("boot ")
    
    is not right as the destination buffer length is just plain
    "sizeof(full_boot_str)" and that's what the final argument
    should be.
    
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 38d7d8fe82963c73447177676d32494140652690
Author: Davidlohr Bueso <davidlohr@hp.com>
Date:   Mon Sep 23 17:04:45 2013 -0700

    ipc: fix race with LSMs
    
    commit 53dad6d3a8e5ac1af8bacc6ac2134ae1a8b085f1 upstream.
    
    Currently, IPC mechanisms do security and auditing related checks under
    RCU.  However, since security modules can free the security structure,
    for example, through selinux_[sem,msg_queue,shm]_free_security(), we can
    race if the structure is freed before other tasks are done with it,
    creating a use-after-free condition.  Manfred illustrates this nicely,
    for instance with shared mem and selinux:
    
     -> do_shmat calls rcu_read_lock()
     -> do_shmat calls shm_object_check().
         Checks that the object is still valid - but doesn't acquire any locks.
         Then it returns.
     -> do_shmat calls security_shm_shmat (e.g. selinux_shm_shmat)
     -> selinux_shm_shmat calls ipc_has_perm()
     -> ipc_has_perm accesses ipc_perms->security
    
    shm_close()
     -> shm_close acquires rw_mutex & shm_lock
     -> shm_close calls shm_destroy
     -> shm_destroy calls security_shm_free (e.g. selinux_shm_free_security)
     -> selinux_shm_free_security calls ipc_free_security(&shp->shm_perm)
     -> ipc_free_security calls kfree(ipc_perms->security)
    
    This patch delays the freeing of the security structures after all RCU
    readers are done.  Furthermore it aligns the security life cycle with
    that of the rest of IPC - freeing them based on the reference counter.
    For situations where we need not free security, the current behavior is
    kept.  Linus states:
    
     "... the old behavior was suspect for another reason too: having the
      security blob go away from under a user sounds like it could cause
      various other problems anyway, so I think the old code was at least
      _prone_ to bugs even if it didn't have catastrophic behavior."
    
    I have tested this patch with IPC testcases from LTP on both my
    quad-core laptop and on a 64 core NUMA server.  In both cases selinux is
    enabled, and tests pass for both voluntary and forced preemption models.
    While the mentioned races are theoretical (at least no one as reported
    them), I wanted to make sure that this new logic doesn't break anything
    we weren't aware of.
    
    Suggested-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Davidlohr Bueso <davidlohr@hp.com>
    Acked-by: Manfred Spraul <manfred@colorfullife.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f4e9906e4bf46437d7bc59f093190a8de643c91b
Author: Davidlohr Bueso <davidlohr@hp.com>
Date:   Mon Sep 30 13:45:26 2013 -0700

    ipc,msg: prevent race with rmid in msgsnd,msgrcv
    
    commit 4271b05a227dc6175b66c3d9941aeab09048aeb2 upstream.
    
    This fixes a race in both msgrcv() and msgsnd() between finding the msg
    and actually dealing with the queue, as another thread can delete shmid
    underneath us if we are preempted before acquiring the
    kern_ipc_perm.lock.
    
    Manfred illustrates this nicely:
    
    Assume a preemptible kernel that is preempted just after
    
        msq = msq_obtain_object_check(ns, msqid)
    
    in do_msgrcv().  The only lock that is held is rcu_read_lock().
    
    Now the other thread processes IPC_RMID.  When the first task is
    resumed, then it will happily wait for messages on a deleted queue.
    
    Fix this by checking for if the queue has been deleted after taking the
    lock.
    
    Signed-off-by: Davidlohr Bueso <davidlohr@hp.com>
    Reported-by: Manfred Spraul <manfred@colorfullife.com>
    Cc: Rik van Riel <riel@redhat.com>
    Cc: Mike Galbraith <efault@gmx.de>
    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 a4e89936a1067a220c2e3946a89233fb8b7abd61
Author: Manfred Spraul <manfred@colorfullife.com>
Date:   Mon Sep 30 13:45:04 2013 -0700

    ipc/sem.c: fix race in sem_lock()
    
    commit 5e9d527591421ccdb16acb8c23662231135d8686 upstream.
    
    The exclusion of complex operations in sem_lock() is insufficient: after
    acquiring the per-semaphore lock, a simple op must first check that
    sem_perm.lock is not locked and only after that test check
    complex_count.  The current code does it the other way around - and that
    creates a race.  Details are below.
    
    The patch is a complete rewrite of sem_lock(), based in part on the code
    from Mike Galbraith.  It removes all gotos and all loops and thus the
    risk of livelocks.
    
    I have tested the patch (together with the next one) on my i3 laptop and
    it didn't cause any problems.
    
    The bug is probably also present in 3.10 and 3.11, but for these kernels
    it might be simpler just to move the test of sma->complex_count after
    the spin_is_locked() test.
    
    Details of the bug:
    
    Assume:
     - sma->complex_count = 0.
     - Thread 1: semtimedop(complex op that must sleep)
     - Thread 2: semtimedop(simple op).
    
    Pseudo-Trace:
    
    Thread 1: sem_lock(): acquire sem_perm.lock
    Thread 1: sem_lock(): check for ongoing simple ops
    			Nothing ongoing, thread 2 is still before sem_lock().
    Thread 1: try_atomic_semop()
    	<<< preempted.
    
    Thread 2: sem_lock():
            static inline int sem_lock(struct sem_array *sma, struct sembuf *sops,
                                          int nsops)
            {
                    int locknum;
             again:
                    if (nsops == 1 && !sma->complex_count) {
                            struct sem *sem = sma->sem_base + sops->sem_num;
    
                            /* Lock just the semaphore we are interested in. */
                            spin_lock(&sem->lock);
    
                            /*
                             * If sma->complex_count was set while we were spinning,
                             * we may need to look at things we did not lock here.
                             */
                            if (unlikely(sma->complex_count)) {
                                    spin_unlock(&sem->lock);
                                    goto lock_array;
                            }
            <<<<<<<<<
    	<<< complex_count is still 0.
    	<<<
            <<< Here it is preempted
            <<<<<<<<<
    
    Thread 1: try_atomic_semop() returns, notices that it must sleep.
    Thread 1: increases sma->complex_count.
    Thread 1: drops sem_perm.lock
    Thread 2:
                    /*
                     * Another process is holding the global lock on the
                     * sem_array; we cannot enter our critical section,
                     * but have to wait for the global lock to be released.
                     */
                    if (unlikely(spin_is_locked(&sma->sem_perm.lock))) {
                            spin_unlock(&sem->lock);
                            spin_unlock_wait(&sma->sem_perm.lock);
                            goto again;
                    }
    	<<< sem_perm.lock already dropped, thus no "goto again;"
    
                    locknum = sops->sem_num;
    
    Signed-off-by: Manfred Spraul <manfred@colorfullife.com>
    Cc: Mike Galbraith <bitbucket@online.de>
    Cc: Rik van Riel <riel@redhat.com>
    Cc: Davidlohr Bueso <davidlohr.bueso@hp.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 8f67918af09fc0ffd426a9b6f87697976d3fbc7b
Author: Vyacheslav Dubeyko <slava@dubeyko.com>
Date:   Mon Sep 30 13:45:12 2013 -0700

    nilfs2: fix issue with race condition of competition between segments for dirty blocks
    
    commit 7f42ec3941560f0902fe3671e36f2c20ffd3af0a upstream.
    
    Many NILFS2 users were reported about strange file system corruption
    (for example):
    
       NILFS: bad btree node (blocknr=185027): level = 0, flags = 0x0, nchildren = 768
       NILFS error (device sda4): nilfs_bmap_last_key: broken bmap (inode number=11540)
    
    But such error messages are consequence of file system's issue that takes
    place more earlier.  Fortunately, Jerome Poulin <jeromepoulin@gmail.com>
    and Anton Eliasson <devel@antoneliasson.se> were reported about another
    issue not so recently.  These reports describe the issue with segctor
    thread's crash:
    
      BUG: unable to handle kernel paging request at 0000000000004c83
      IP: nilfs_end_page_io+0x12/0xd0 [nilfs2]
    
      Call Trace:
       nilfs_segctor_do_construct+0xf25/0x1b20 [nilfs2]
       nilfs_segctor_construct+0x17b/0x290 [nilfs2]
       nilfs_segctor_thread+0x122/0x3b0 [nilfs2]
       kthread+0xc0/0xd0
       ret_from_fork+0x7c/0xb0
    
    These two issues have one reason.  This reason can raise third issue
    too.  Third issue results in hanging of segctor thread with eating of
    100% CPU.
    
    REPRODUCING PATH:
    
    One of the possible way or the issue reproducing was described by
    Jermoe me Poulin <jeromepoulin@gmail.com>:
    
    1. init S to get to single user mode.
    2. sysrq+E to make sure only my shell is running
    3. start network-manager to get my wifi connection up
    4. login as root and launch "screen"
    5. cd /boot/log/nilfs which is a ext3 mount point and can log when NILFS dies.
    6. lscp | xz -9e > lscp.txt.xz
    7. mount my snapshot using mount -o cp=3360839,ro /dev/vgUbuntu/root /mnt/nilfs
    8. start a screen to dump /proc/kmsg to text file since rsyslog is killed
    9. start a screen and launch strace -f -o find-cat.log -t find
    /mnt/nilfs -type f -exec cat {} > /dev/null \;
    10. start a screen and launch strace -f -o apt-get.log -t apt-get update
    11. launch the last command again as it did not crash the first time
    12. apt-get crashes
    13. ps aux > ps-aux-crashed.log
    13. sysrq+W
    14. sysrq+E  wait for everything to terminate
    15. sysrq+SUSB
    
    Simplified way of the issue reproducing is starting kernel compilation
    task and "apt-get update" in parallel.
    
    REPRODUCIBILITY:
    
    The issue is reproduced not stable [60% - 80%].  It is very important to
    have proper environment for the issue reproducing.  The critical
    conditions for successful reproducing:
    
    (1) It should have big modified file by mmap() way.
    
    (2) This file should have the count of dirty blocks are greater that
        several segments in size (for example, two or three) from time to time
        during processing.
    
    (3) It should be intensive background activity of files modification
        in another thread.
    
    INVESTIGATION:
    
    First of all, it is possible to see that the reason of crash is not valid
    page address:
    
      NILFS [nilfs_segctor_complete_write]:2100 bh->b_count 0, bh->b_blocknr 13895680, bh->b_size 13897727, bh->b_page 0000000000001a82
      NILFS [nilfs_segctor_complete_write]:2101 segbuf->sb_segnum 6783
    
    Moreover, value of b_page (0x1a82) is 6786.  This value looks like segment
    number.  And b_blocknr with b_size values look like block numbers.  So,
    buffer_head's pointer points on not proper address value.
    
    Detailed investigation of the issue is discovered such picture:
    
      [-----------------------------SEGMENT 6783-------------------------------]
      NILFS [nilfs_segctor_do_construct]:2310 nilfs_segctor_begin_construction
      NILFS [nilfs_segctor_do_construct]:2321 nilfs_segctor_collect
      NILFS [nilfs_segctor_do_construct]:2336 nilfs_segctor_assign
      NILFS [nilfs_segctor_do_construct]:2367 nilfs_segctor_update_segusage
      NILFS [nilfs_segctor_do_construct]:2371 nilfs_segctor_prepare_write
      NILFS [nilfs_segctor_do_construct]:2376 nilfs_add_checksums_on_logs
      NILFS [nilfs_segctor_do_construct]:2381 nilfs_segctor_write
      NILFS [nilfs_segbuf_submit_bio]:464 bio->bi_sector 111149024, segbuf->sb_segnum 6783
    
      [-----------------------------SEGMENT 6784-------------------------------]
      NILFS [nilfs_segctor_do_construct]:2310 nilfs_segctor_begin_construction
      NILFS [nilfs_segctor_do_construct]:2321 nilfs_segctor_collect
      NILFS [nilfs_lookup_dirty_data_buffers]:782 bh->b_count 1, bh->b_page ffffea000709b000, page->index 0, i_ino 1033103, i_size 25165824
      NILFS [nilfs_lookup_dirty_data_buffers]:783 bh->b_assoc_buffers.next ffff8802174a6798, bh->b_assoc_buffers.prev ffff880221cffee8
      NILFS [nilfs_segctor_do_construct]:2336 nilfs_segctor_assign
      NILFS [nilfs_segctor_do_construct]:2367 nilfs_segctor_update_segusage
      NILFS [nilfs_segctor_do_construct]:2371 nilfs_segctor_prepare_write
      NILFS [nilfs_segctor_do_construct]:2376 nilfs_add_checksums_on_logs
      NILFS [nilfs_segctor_do_construct]:2381 nilfs_segctor_write
      NILFS [nilfs_segbuf_submit_bh]:575 bh->b_count 1, bh->b_page ffffea000709b000, page->index 0, i_ino 1033103, i_size 25165824
      NILFS [nilfs_segbuf_submit_bh]:576 segbuf->sb_segnum 6784
      NILFS [nilfs_segbuf_submit_bh]:577 bh->b_assoc_buffers.next ffff880218a0d5f8, bh->b_assoc_buffers.prev ffff880218bcdf50
      NILFS [nilfs_segbuf_submit_bio]:464 bio->bi_sector 111150080, segbuf->sb_segnum 6784, segbuf->sb_nbio 0
      [----------] ditto
      NILFS [nilfs_segbuf_submit_bio]:464 bio->bi_sector 111164416, segbuf->sb_segnum 6784, segbuf->sb_nbio 15
    
      [-----------------------------SEGMENT 6785-------------------------------]
      NILFS [nilfs_segctor_do_construct]:2310 nilfs_segctor_begin_construction
      NILFS [nilfs_segctor_do_construct]:2321 nilfs_segctor_collect
      NILFS [nilfs_lookup_dirty_data_buffers]:782 bh->b_count 2, bh->b_page ffffea000709b000, page->index 0, i_ino 1033103, i_size 25165824
      NILFS [nilfs_lookup_dirty_data_buffers]:783 bh->b_assoc_buffers.next ffff880219277e80, bh->b_assoc_buffers.prev ffff880221cffc88
      NILFS [nilfs_segctor_do_construct]:2367 nilfs_segctor_update_segusage
      NILFS [nilfs_segctor_do_construct]:2371 nilfs_segctor_prepare_write
      NILFS [nilfs_segctor_do_construct]:2376 nilfs_add_checksums_on_logs
      NILFS [nilfs_segctor_do_construct]:2381 nilfs_segctor_write
      NILFS [nilfs_segbuf_submit_bh]:575 bh->b_count 2, bh->b_page ffffea000709b000, page->index 0, i_ino 1033103, i_size 25165824
      NILFS [nilfs_segbuf_submit_bh]:576 segbuf->sb_segnum 6785
      NILFS [nilfs_segbuf_submit_bh]:577 bh->b_assoc_buffers.next ffff880218a0d5f8, bh->b_assoc_buffers.prev ffff880222cc7ee8
      NILFS [nilfs_segbuf_submit_bio]:464 bio->bi_sector 111165440, segbuf->sb_segnum 6785, segbuf->sb_nbio 0
      [----------] ditto
      NILFS [nilfs_segbuf_submit_bio]:464 bio->bi_sector 111177728, segbuf->sb_segnum 6785, segbuf->sb_nbio 12
    
      NILFS [nilfs_segctor_do_construct]:2399 nilfs_segctor_wait
      NILFS [nilfs_segbuf_wait]:676 segbuf->sb_segnum 6783
      NILFS [nilfs_segbuf_wait]:676 segbuf->sb_segnum 6784
      NILFS [nilfs_segbuf_wait]:676 segbuf->sb_segnum 6785
    
      NILFS [nilfs_segctor_complete_write]:2100 bh->b_count 0, bh->b_blocknr 13895680, bh->b_size 13897727, bh->b_page 0000000000001a82
    
      BUG: unable to handle kernel paging request at 0000000000001a82
      IP: [<ffffffffa024d0f2>] nilfs_end_page_io+0x12/0xd0 [nilfs2]
    
    Usually, for every segment we collect dirty files in list.  Then, dirty
    blocks are gathered for every dirty file, prepared for write and
    submitted by means of nilfs_segbuf_submit_bh() call.  Finally, it takes
    place complete write phase after calling nilfs_end_bio_write() on the
    block layer.  Buffers/pages are marked as not dirty on final phase and
    processed files removed from the list of dirty files.
    
    It is possible to see that we had three prepare_write and submit_bio
    phases before segbuf_wait and complete_write phase.  Moreover, segments
    compete between each other for dirty blocks because on every iteration
    of segments processing dirty buffer_heads are added in several lists of
    payload_buffers:
    
      [SEGMENT 6784]: bh->b_assoc_buffers.next ffff880218a0d5f8, bh->b_assoc_buffers.prev ffff880218bcdf50
      [SEGMENT 6785]: bh->b_assoc_buffers.next ffff880218a0d5f8, bh->b_assoc_buffers.prev ffff880222cc7ee8
    
    The next pointer is the same but prev pointer has changed.  It means
    that buffer_head has next pointer from one list but prev pointer from
    another.  Such modification can be made several times.  And, finally, it
    can be resulted in various issues: (1) segctor hanging, (2) segctor
    crashing, (3) file system metadata corruption.
    
    FIX:
    This patch adds:
    
    (1) setting of BH_Async_Write flag in nilfs_segctor_prepare_write()
        for every proccessed dirty block;
    
    (2) checking of BH_Async_Write flag in
        nilfs_lookup_dirty_data_buffers() and
        nilfs_lookup_dirty_node_buffers();
    
    (3) clearing of BH_Async_Write flag in nilfs_segctor_complete_write(),
        nilfs_abort_logs(), nilfs_forget_buffer(), nilfs_clear_dirty_page().
    
    Reported-by: Jerome Poulin <jeromepoulin@gmail.com>
    Reported-by: Anton Eliasson <devel@antoneliasson.se>
    Cc: Paul Fertser <fercerpav@gmail.com>
    Cc: ARAI Shun-ichi <hermes@ceres.dti.ne.jp>
    Cc: Piotr Szymaniak <szarpaj@grubelek.pl>
    Cc: Juan Barry Manuel Canham <Linux@riotingpacifist.net>
    Cc: Zahid Chowdhury <zahid.chowdhury@starsolutions.com>
    Cc: Elmer Zhang <freeboy6716@gmail.com>
    Cc: Kenneth Langga <klangga@gmail.com>
    Signed-off-by: Vyacheslav Dubeyko <slava@dubeyko.com>
    Acked-by: Ryusuke Konishi <konishi.ryusuke@lab.ntt.co.jp>
    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 cca2f2a8812309f45db931c5d6bb1f1cb3eee117
Author: Johan Hedberg <johan.hedberg@intel.com>
Date:   Fri Sep 13 08:58:18 2013 +0300

    Bluetooth: Fix rfkill functionality during the HCI setup stage
    
    commit bf5430360ebe4b2d0c51d91f782e649107b502eb upstream.
    
    We need to let the setup stage complete cleanly even when the HCI device
    is rfkilled. Otherwise the HCI device will stay in an undefined state
    and never get notified to user space through mgmt (even when it gets
    unblocked through rfkill).
    
    This patch makes sure that hci_dev_open() can be called in the HCI_SETUP
    stage, that blocking the device doesn't abort the setup stage, and that
    the device gets proper powered down as soon as the setup stage completes
    in case it was blocked meanwhile.
    
    The bug that this patch fixed can be very easily reproduced using e.g.
    the rfkill command line too. By running "rfkill block all" before
    inserting a Bluetooth dongle the resulting HCI device goes into a state
    where it is never announced over mgmt, not even when "rfkill unblock all"
    is run.
    
    Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
    Acked-by: Marcel Holtmann <marcel@holtmann.org>
    Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fe3500ee45a4649a6837051572a02872e3017375
Author: Johan Hedberg <johan.hedberg@intel.com>
Date:   Fri Sep 13 08:58:17 2013 +0300

    Bluetooth: Introduce a new HCI_RFKILLED flag
    
    commit 5e130367d43ff22836bbae380d197d600fe8ddbb upstream.
    
    This makes it more convenient to check for rfkill (no need to check for
    dev->rfkill before calling rfkill_blocked()) and also avoids potential
    races if the RFKILL state needs to be checked from within the rfkill
    callback.
    
    Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
    Acked-by: Marcel Holtmann <marcel@holtmann.org>
    Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8eb8de3184c823fb3d4a4ddcae1fa4a9b1162b29
Author: Raphael Kubo da Costa <rakuco@FreeBSD.org>
Date:   Mon Sep 2 14:57:51 2013 +0300

    Bluetooth: Add support for BCM20702A0 [0b05, 17cb]
    
    commit 38a172bef8c93ecbfd69715fd88396988e4073fd upstream.
    
    Yet another vendor specific ID for this chipset; this one for the ASUS
    USB-BT400 Bluetooth 4.0 adapter.
    
    T:  Bus=03 Lev=02 Prnt=02 Port=01 Cnt=01 Dev#=  6 Spd=12  MxCh= 0
    D:  Ver= 2.00 Cls=ff(vend.) Sub=01 Prot=01 MxPS=64 #Cfgs=  1
    P:  Vendor=0b05 ProdID=17cb Rev=01.12
    S:  Manufacturer=Broadcom Corp
    S:  Product=BCM20702A0
    S:  SerialNumber=000272C64400
    C:  #Ifs= 4 Cfg#= 1 Atr=a0 MxPwr=100mA
    I:  If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=01 Prot=01 Driver=(none)
    I:  If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=(none)
    I:  If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
    I:  If#= 3 Alt= 0 #EPs= 0 Cls=fe(app. ) Sub=01 Prot=01 Driver=(none)
    
    Signed-off-by: Raphael Kubo da Costa <rakuco@FreeBSD.org>
    Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 800a63ce43cd78388594c2370de11c096e412bd6
Author: Peng Chen <pengchen@qti.qualcomm.com>
Date:   Fri Aug 30 17:41:40 2013 +0800

    Bluetooth: Add a new PID/VID 0cf3/e005 for AR3012.
    
    commit 0a3658cccdf5326ea508efeb1879b0e2508bb0c3 upstream.
    
    usb device info:
    
    T:  Bus=06 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#= 15 Spd=12   MxCh= 0
    D:  Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs=  1
    P:  Vendor=0cf3 ProdID=e005 Rev= 0.02
    C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA
    I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    E:  Ad=81(I) Atr=03(Int.) MxPS=  16 Ivl=1ms
    E:  Ad=82(I) Atr=02(Bulk) MxPS=  64 Ivl=0ms
    E:  Ad=02(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms
    I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    E:  Ad=83(I) Atr=01(Isoc) MxPS=   0 Ivl=1ms
    E:  Ad=03(O) Atr=01(Isoc) MxPS=   0 Ivl=1ms
    
    Signed-off-by: Peng Chen <pengchen@qca.qualcomm.com>
    Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2d1c789bb88cdcc4a9dd731575d5ed634d9a4965
Author: Andre Guedes <andre.guedes@openbossa.org>
Date:   Wed Jul 31 16:25:29 2013 -0300

    Bluetooth: Fix encryption key size for peripheral role
    
    commit 89cbb4da0abee2f39d75f67f9fd57f7410c8b65c upstream.
    
    This patch fixes the connection encryption key size information when
    the host is playing the peripheral role. We should set conn->enc_key_
    size in hci_le_ltk_request_evt, otherwise it is left uninitialized.
    
    Signed-off-by: Andre Guedes <andre.guedes@openbossa.org>
    Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 441e69e1d6e12050c74fb80b1368c0194cd51e05
Author: Andre Guedes <andre.guedes@openbossa.org>
Date:   Wed Jul 31 16:25:28 2013 -0300

    Bluetooth: Fix security level for peripheral role
    
    commit f8776218e8546397be64ad2bc0ebf4748522d6e3 upstream.
    
    While playing the peripheral role, the host gets a LE Long Term Key
    Request Event from the controller when a connection is established
    with a bonded device. The host then informs the LTK which should be
    used for the connection. Once the link is encrypted, the host gets
    an Encryption Change Event.
    
    Therefore we should set conn->pending_sec_level instead of conn->
    sec_level in hci_le_ltk_request_evt. This way, conn->sec_level is
    properly updated in hci_encrypt_change_evt.
    
    Moreover, since we have a LTK associated to the device, we have at
    least BT_SECURITY_MEDIUM security level.
    
    Signed-off-by: Andre Guedes <andre.guedes@openbossa.org>
    Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 17828296b122ed60cf5274cfb481aa1cc0308250
Author: Arend van Spriel <arend@broadcom.com>
Date:   Wed Sep 25 12:11:01 2013 +0200

    brcmfmac: obtain platform data upon module initialization
    
    commit db4efbbeb457b6f9f4d8c4b090d1170d12f026e1 upstream.
    
    The driver uses platform_driver_probe() to obtain platform data
    if any. However, that function is placed in the .init section so
    it must be called upon driver module initialization.
    
    The problem was reported by Fenguang Wu resulting in a kernel
    oops because the .init section was already freed.
    
    [   48.966342] Switched to clocksource tsc
    [   48.970002] kernel tried to execute NX-protected page - exploit attempt? (uid: 0)
    [   48.970851] BUG: unable to handle kernel paging request at ffffffff82196446
    [   48.970957] IP: [<ffffffff82196446>] classes_init+0x26/0x26
    [   48.970957] PGD 1e76067 PUD 1e77063 PMD f388063 PTE 8000000002196163
    [   48.970957] Oops: 0011 [#1]
    [   48.970957] CPU: 0 PID: 17 Comm: kworker/0:1 Not tainted 3.11.0-rc7-00444-gc52dd7f #23
    [   48.970957] Workqueue: events brcmf_driver_init
    [   48.970957] task: ffff8800001d2000 ti: ffff8800001d4000 task.ti: ffff8800001d4000
    [   48.970957] RIP: 0010:[<ffffffff82196446>]  [<ffffffff82196446>] classes_init+0x26/0x26
    [   48.970957] RSP: 0000:ffff8800001d5d40  EFLAGS: 00000286
    [   48.970957] RAX: 0000000000000001 RBX: ffffffff820c5620 RCX: 0000000000000000
    [   48.970957] RDX: 0000000000000001 RSI: ffffffff816f7380 RDI: ffffffff820c56c0
    [   48.970957] RBP: ffff8800001d5d50 R08: ffff8800001d2508 R09: 0000000000000002
    [   48.970957] R10: 0000000000000000 R11: 0001f7ce298c5620 R12: ffff8800001c76b0
    [   48.970957] R13: ffffffff81e91d40 R14: 0000000000000000 R15: ffff88000e0ce300
    [   48.970957] FS:  0000000000000000(0000) GS:ffffffff81e84000(0000) knlGS:0000000000000000
    [   48.970957] CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
    [   48.970957] CR2: ffffffff82196446 CR3: 0000000001e75000 CR4: 00000000000006b0
    [   48.970957] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    [   48.970957] DR3: 0000000000000000 DR6: 0000000000000000 DR7: 0000000000000000
    [   48.970957] Stack:
    [   48.970957]  ffffffff816f7df8 ffffffff820c5620 ffff8800001d5d60 ffffffff816eeec9
    [   48.970957]  ffff8800001d5de0 ffffffff81073dc5 ffffffff81073d68 ffff8800001d5db8
    [   48.970957]  0000000000000086 ffffffff820c5620 ffffffff824f7fd0 0000000000000000
    [   48.970957] Call Trace:
    [   48.970957]  [<ffffffff816f7df8>] ? brcmf_sdio_init+0x18/0x70
    [   48.970957]  [<ffffffff816eeec9>] brcmf_driver_init+0x9/0x10
    [   48.970957]  [<ffffffff81073dc5>] process_one_work+0x1d5/0x480
    [   48.970957]  [<ffffffff81073d68>] ? process_one_work+0x178/0x480
    [   48.970957]  [<ffffffff81074188>] worker_thread+0x118/0x3a0
    [   48.970957]  [<ffffffff81074070>] ? process_one_work+0x480/0x480
    [   48.970957]  [<ffffffff8107aa17>] kthread+0xe7/0xf0
    [   48.970957]  [<ffffffff810829f7>] ? finish_task_switch.constprop.57+0x37/0xd0
    [   48.970957]  [<ffffffff8107a930>] ? __kthread_parkme+0x80/0x80
    [   48.970957]  [<ffffffff81a6923a>] ret_from_fork+0x7a/0xb0
    [   48.970957]  [<ffffffff8107a930>] ? __kthread_parkme+0x80/0x80
    [   48.970957] Code: cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc
    cc cc cc cc cc cc <cc> cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc
    [   48.970957] RIP  [<ffffffff82196446>] classes_init+0x26/0x26
    [   48.970957]  RSP <ffff8800001d5d40>
    [   48.970957] CR2: ffffffff82196446
    [   48.970957] ---[ end trace 62980817cd525f14 ]---
    
    Reported-by: Fengguang Wu <fengguang.wu@intel.com>
    Reviewed-by: Hante Meuleman <meuleman@broadcom.com>
    Reviewed-by: Pieter-Paul Giesberts <pieterpg@broadcom.com>
    Tested-by: Fengguang Wu <fengguang.wu@intel.com>
    Signed-off-by: Arend van Spriel <arend@broadcom.com>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a327074d8674c8ce44afca35a1a93fab11870f0d
Author: Maxim Patlasov <MPatlasov@parallels.com>
Date:   Fri Sep 13 19:20:16 2013 +0400

    fuse: fix fallocate vs. ftruncate race
    
    commit 0ab08f576b9e6a6b689fc6b4e632079b978e619b upstream.
    
    A former patch introducing FUSE_I_SIZE_UNSTABLE flag provided detailed
    description of races between ftruncate and anyone who can extend i_size:
    
    > 1. As in the previous scenario fuse_dentry_revalidate() discovered that i_size
    > changed (due to our own fuse_do_setattr()) and is going to call
    > truncate_pagecache() for some  'new_size' it believes valid right now. But by
    > the time that particular truncate_pagecache() is called ...
    > 2. fuse_do_setattr() returns (either having called truncate_pagecache() or
    > not -- it doesn't matter).
    > 3. The file is extended either by write(2) or ftruncate(2) or fallocate(2).
    > 4. mmap-ed write makes a page in the extended region dirty.
    
    This patch adds necessary bits to fuse_file_fallocate() to protect from that
    race.
    
    Signed-off-by: Maxim Patlasov <mpatlasov@parallels.com>
    Signed-off-by: Miklos Szeredi <mszeredi@suse.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3a06b47c8aba5928a1a14a0c9c0592e32f74b671
Author: Maxim Patlasov <MPatlasov@parallels.com>
Date:   Fri Sep 13 19:19:54 2013 +0400

    fuse: wait for writeback in fuse_file_fallocate()
    
    commit bde52788bdb755b9e4b75db6c434f30e32a0ca0b upstream.
    
    The patch fixes a race between mmap-ed write and fallocate(PUNCH_HOLE):
    
    1) An user makes a page dirty via mmap-ed write.
    2) The user performs fallocate(2) with mode == PUNCH_HOLE|KEEP_SIZE
       and <offset, size> covering the page.
    3) Before truncate_pagecache_range call from fuse_file_fallocate,
       the page goes to write-back. The page is fully processed by fuse_writepage
       (including end_page_writeback on the page), but fuse_flush_writepages did
       nothing because fi->writectr < 0.
    4) truncate_pagecache_range is called and fuse_file_fallocate is finishing
       by calling fuse_release_nowrite. The latter triggers processing queued
       write-back request which will write stale data to the hole soon.
    
    Changed in v2 (thanks to Brian for suggestion):
     - Do not truncate page cache until FUSE_FALLOCATE succeeded. Otherwise,
       we can end up in returning -ENOTSUPP while user data is already punched
       from page cache. Use filemap_write_and_wait_range() instead.
    Changed in v3 (thanks to Miklos for suggestion):
     - fuse_wait_on_writeback() is prone to livelocks; use fuse_set_nowrite()
       instead. So far as we need a dirty-page barrier only, fuse_sync_writes()
       should be enough.
     - rebased to for-linus branch of fuse.git
    
    Signed-off-by: Maxim Patlasov <mpatlasov@parallels.com>
    Signed-off-by: Miklos Szeredi <mszeredi@suse.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c7ab1ac72571ea06719e989a9fade5f51e1b8688
Author: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Date:   Tue Oct 1 17:11:35 2013 +1000

    powerpc: Restore registers on error exit from csum_partial_copy_generic()
    
    commit 8f21bd0090052e740944f9397e2be5ac7957ded7 upstream.
    
    The csum_partial_copy_generic() function saves the PowerPC non-volatile
    r14, r15, and r16 registers for the main checksum-and-copy loop.
    Unfortunately, it fails to restore them upon error exit from this loop,
    which results in silent corruption of these registers in the presumably
    rare event of an access exception within that loop.
    
    This commit therefore restores these register on error exit from the loop.
    
    Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
    Signed-off-by: Anton Blanchard <anton@samba.org>
    Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 907a2dd41bc56bb8bee077ad09e5a84ea652e79b
Author: Madhavan Srinivasan <maddy@linux.vnet.ibm.com>
Date:   Wed Oct 2 00:34:10 2013 +0530

    powerpc/sysfs: Disable writing to PURR in guest mode
    
    commit d1211af3049f4c9c1d8d4eb8f8098cc4f4f0d0c7 upstream.
    
    arch/powerpc/kernel/sysfs.c exports PURR with write permission.
    This may be valid for kernel in phyp mode. But writing to
    the file in guest mode causes crash due to a priviledge violation
    
    Signed-off-by: Madhavan Srinivasan <maddy@linux.vnet.ibm.com>
    Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8feeb87d772d6611d7eaf9e0e870d1ed981ef322
Author: Nathan Fontenot <nfont@linux.vnet.ibm.com>
Date:   Fri Sep 27 10:18:09 2013 -0500

    powerpc: Fix memory hotplug with sparse vmemmap
    
    commit f7e3334a6bcb42e7295a9bd9cb36ca4e6e4e66b4 upstream.
    
    Previous commit 46723bfa540... introduced a new config option
    HAVE_BOOTMEM_INFO_NODE that ended up breaking memory hot-remove for ppc
    when sparse vmemmap is not defined.
    
    This patch defines HAVE_BOOTMEM_INFO_NODE for ppc and adds the call to
    register_page_bootmem_info_node. Without this we get a BUG_ON for memory
    hot remove in put_page_bootmem().
    
    This also adds a stub for register_page_bootmem_memmap to allow ppc to build
    with sparse vmemmap defined. Leaving this as a stub is fine since the same
    vmemmap addresses are also handled in vmemmap_populate and as such are
    properly mapped.
    
    Signed-off-by: Nathan Fontenot <nfont@linux.vnet.ibm.com>
    Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 698dc640e9dc5722d8ce4bf34524986ef5236390
Author: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Date:   Tue Oct 1 16:54:05 2013 +1000

    powerpc: Fix parameter clobber in csum_partial_copy_generic()
    
    commit d9813c3681a36774b254c0cdc9cce53c9e22c756 upstream.
    
    The csum_partial_copy_generic() uses register r7 to adjust the remaining
    bytes to process.  Unfortunately, r7 also holds a parameter, namely the
    address of the flag to set in case of access exceptions while reading
    the source buffer.  Lacking a quantum implementation of PowerPC, this
    commit instead uses register r9 to do the adjusting, leaving r7's
    pointer uncorrupted.
    
    Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
    Signed-off-by: Anton Blanchard <anton@samba.org>
    Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6de61dfab8587ebe36be11150496ca76e1915e7e
Author: Prarit Bhargava <prarit@redhat.com>
Date:   Mon Sep 23 09:33:36 2013 -0400

    powerpc/vio: Fix modalias_show return values
    
    commit e82b89a6f19bae73fb064d1b3dd91fcefbb478f4 upstream.
    
    modalias_show() should return an empty string on error, not -ENODEV.
    
    This causes the following false and annoying error:
    
    > find /sys/devices -name modalias -print0 | xargs -0 cat >/dev/null
    cat: /sys/devices/vio/4000/modalias: No such device
    cat: /sys/devices/vio/4001/modalias: No such device
    cat: /sys/devices/vio/4002/modalias: No such device
    cat: /sys/devices/vio/4004/modalias: No such device
    cat: /sys/devices/vio/modalias: No such device
    
    Signed-off-by: Prarit Bhargava <prarit@redhat.com>
    Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fb1c209733e25177b634f825848c78c998f54e30
Author: Michael Neuling <mikey@neuling.org>
Date:   Wed Oct 2 17:15:15 2013 +1000

    powerpc/tm: Turn interrupts hard off in tm_reclaim()
    
    commit c69e63b0f135fa51d6e1c38b5ac8a1def15ea3fa upstream.
    
    We can't take IRQs in tm_reclaim as we might have a bogus r13 and r1.
    
    This turns IRQs hard off in this function.
    
    Signed-off-by: Michael Neuling <mikey@neuling.org>
    Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 39302163d7368f0960f30cf7d785eec2ccae1c26
Author: Michael Neuling <mikey@neuling.org>
Date:   Thu Sep 26 13:29:09 2013 +1000

    powerpc/tm: Switch out userspace PPR and DSCR sooner
    
    commit e9bdc3d6143d1c4b8d8ce5231fc958268331f983 upstream.
    
    When we do a treclaim or trecheckpoint we end up running with userspace
    PPR and DSCR values.  Currently we don't do anything special to avoid
    running with user values which could cause a severe performance
    degradation.
    
    This patch moves the PPR and DSCR save and restore around treclaim and
    trecheckpoint so that we run with user values for a much shorter period.
    More care is taken with the PPR as it's impact is greater than the DSCR.
    
    This is similar to user exceptions, where we run HTM_MEDIUM early to
    ensure that we don't run with a userspace PPR values in the kernel.
    
    Signed-off-by: Michael Neuling <mikey@neuling.org>
    Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ee4801ffed249525a8080581fdd6380f324c6086
Author: Michael Ellerman <michael@ellerman.id.au>
Date:   Wed Oct 2 18:04:06 2013 +1000

    powerpc/perf: Fix handling of FAB events
    
    commit a53b27b3abeef406de92a2bb0ceb6fb4c3fb8fc4 upstream.
    
    Commit 4df4899 "Add power8 EBB support" included a bug in the handling
    of the FAB_CRESP_MATCH and FAB_TYPE_MATCH fields.
    
    These values are pulled out of the event code using EVENT_THR_CTL_SHIFT,
    however we were then or'ing that value directly into MMCR1.
    
    This meant we were failing to set the FAB fields correctly, and also
    potentially corrupting the value for PMC4SEL. Leading to no counts for
    the FAB events and incorrect counts for PMC4.
    
    The fix is simply to shift left the FAB value correctly before or'ing it
    with MMCR1.
    
    Reported-by: Sooraj Ravindran Nair <soonair3@in.ibm.com>
    Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
    Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1a92f1a5860c38105a80293717db9448d6fbce78
Author: Nishanth Aravamudan <nacc@linux.vnet.ibm.com>
Date:   Tue Oct 1 14:04:53 2013 -0700

    powerpc/iommu: Use GFP_KERNEL instead of GFP_ATOMIC in iommu_init_table()
    
    commit 1cf389df090194a0976dc867b7fffe99d9d490cb upstream.
    
    Under heavy (DLPAR?) stress, we tripped this panic() in
    arch/powerpc/kernel/iommu.c::iommu_init_table():
    
    	page = alloc_pages_node(nid, GFP_ATOMIC, get_order(sz));
    	if (!page)
    		panic("iommu_init_table: Can't allocate %ld bytes\n", sz);
    
    Before the panic() we got a page allocation failure for an order-2
    allocation. There appears to be memory free, but perhaps not in the
    ATOMIC context. I looked through all the call-sites of
    iommu_init_table() and didn't see any obvious reason to need an ATOMIC
    allocation. Most call-sites in fact have an explicit GFP_KERNEL
    allocation shortly before the call to iommu_init_table(), indicating we
    are not in an atomic context. There is some indirection for some paths,
    but I didn't see any locks indicating that GFP_KERNEL is inappropriate.
    
    With this change under the same conditions, we have not been able to
    reproduce the panic.
    
    Signed-off-by: Nishanth Aravamudan <nacc@us.ibm.com>
    Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c92d069acbd6b7852eee27f062b62d1521efe75b
Author: Will Deacon <will.deacon@arm.com>
Date:   Wed Aug 21 13:56:34 2013 +0100

    iommu/arm-smmu: don't enable SMMU device until probing has completed
    
    commit fd90cecbde065eac6ecc3ef38abace725ad27010 upstream.
    
    We currently reset and enable the SMMU before the device has finished
    being probed, so if we fail later on (for example, because we couldn't
    request a global irq successfully) then we will leave the device in an
    active state.
    
    This patch delays the reset and enabling of the SMMU hardware until
    probing has completed.
    
    Signed-off-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 81ac5e7f75c97089f3e86955768f81096c7c5c22
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Wed Aug 21 09:34:20 2013 +0100

    iommu/arm-smmu: fix iommu_present() test in init
    
    commit 6614ee77f49d37f9bb77eb3e81431ca8fcc4042e upstream.
    
    The extra semi-colon on the end breaks the test.
    
    Tested-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5f854447d6119d0dc79680fe0c1ced324fe2e03b
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Wed Aug 21 09:33:30 2013 +0100

    iommu/arm-smmu: fix a signedness bug
    
    commit faea13b72dbdb77e4d6ad83344596486611708b0 upstream.
    
    Unsigned char is never equal to -1.
    
    Tested-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit bbe7602997289ee415a7767150ef6b599d56cf4a
Author: Joerg Roedel <joro@8bytes.org>
Date:   Wed Sep 25 12:11:33 2013 +0200

    ARM: mach-integrator: Add stub for pci_v3_early_init() for !CONFIG_PCI
    
    commit 4dc3231f818baf7415c67ee06c51ace0973ae736 upstream.
    
    This fixes a compile error where CONFIG_PCI is disabled:
    
      LD      init/built-in.o
    arch/arm/mach-integrator/built-in.o: In function `ap_map_io':
    integrator_cp.c:(.init.text+0x570): undefined reference to `pci_v3_early_init'
    make[1]: *** [vmlinux] Error 1
    make: *** [sub-make] Error 2
    
    Signed-off-by: Joerg Roedel <joro@8bytes.org>
    Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Olof Johansson <olof@lixom.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c6bdbcd2f5f55d7f61a61ceee2f342bcfeddbe15
Author: Olof Johansson <olof@lixom.net>
Date:   Wed Sep 11 15:27:41 2013 -0700

    ARM: kvm: rename cpu_reset to avoid name clash
    
    commit ac570e0493815e0b41681c89cb50d66421429d27 upstream.
    
    cpu_reset is already #defined in <asm/proc-fns.h> as processor.reset,
    so it expands here and causes problems.
    
    Signed-off-by: Olof Johansson <olof@lixom.net>
    Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 961bd4a98ca7e14b6656a10c943aa3f5e8aa099f
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Fri Sep 13 10:53:36 2013 +0300

    ASoC: ab8500-codec: info leak in anc_status_control_put()
    
    commit d63733aed90b432e5cc489ddfa28e342f91b4652 upstream.
    
    If the user passes an invalid value it leads to an info leak when we
    print the error message or it could oops.  This is called with user
    supplied data from snd_ctl_elem_write().
    
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: Mark Brown <broonie@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit dd0395fd28b3baf53a1cf0878638c5e6f472e391
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Fri Sep 13 10:52:49 2013 +0300

    ASoC: 88pm860x: array overflow in snd_soc_put_volsw_2r_st()
    
    commit d967967e8d1116fb38bad25e58714b5dddd03cca upstream.
    
    This is called from snd_ctl_elem_write() with user supplied data so we
    need to add some bounds checking.
    
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: Mark Brown <broonie@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 83b7e1568698b35be50f26eddfa17aafdb57e43d
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Fri Sep 13 10:52:14 2013 +0300

    ASoC: max98095: a couple array underflows
    
    commit f8d7b13e14357ed19d2ca2799539600418dc3939 upstream.
    
    The ->put() function are called from snd_ctl_elem_write() with user
    supplied data.  The limit checks here could underflow leading to a
    crash.
    
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: Mark Brown <broonie@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e64141c1c311b840235d99baf17a3620cd35cb19
Author: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
Date:   Wed Sep 25 02:36:54 2013 +0200

    gpio/omap: auto-setup a GPIO when used as an IRQ
    
    commit fac7fa162a19100298d5d91359960037dc5bfca9 upstream.
    
    The OMAP GPIO controller HW requires a pin to be configured in GPIO
    input mode in order to operate as an interrupt input. Since drivers
    should not be aware of whether an interrupt pin is also a GPIO or not,
    the HW should be fully configured/enabled as an IRQ if a driver solely
    uses IRQ APIs such as request_irq(), and never calls any GPIO-related
    APIs. As such, add the missing HW setup to the OMAP GPIO controller's
    irq_chip driver.
    
    Since this bypasses the GPIO subsystem we have to ensure that another
    driver won't be able to request the same GPIO pin that is used as an
    IRQ and set its direction as output. Requesting the GPIO and setting
    its direction as input is allowed though.
    
    This fixes smsc911x ethernet support for tobi and igep OMAP3 boards
    and OMAP4 SDP SPI based ethernet that use a GPIO as an interrupt line.
    
    Acked-by: Stephen Warren <swarren@nvidia.com>
    Tested-by: George Cherian <george.cherian@ti.com>
    Tested-by: Aaro Koskinen <aaro.koskinen@iki.fi>
    Tested-by: Lars Poeschel <poeschel@lemonage.de>
    Reviewed-by: Kevin Hilman <khilman@linaro.org>
    Tested-by: Kevin Hilman <khilman@linaro.org>
    Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
    Acked-by: Tony Lindgren <tony@atomide.com>
    Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 80bd2ccb14f0b09d4daa8a87d5668d91e8f3702d
Author: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
Date:   Wed Sep 25 02:36:52 2013 +0200

    gpio/omap: maintain GPIO and IRQ usage separately
    
    commit fa365e4d729065b5e85165df3dc9699ed47489cc upstream.
    
    The GPIO OMAP controller pins can be used as IRQ and GPIO
    independently so is necessary to keep track GPIO pins and
    IRQ lines usage separately to make sure that the bank will
    always be enabled while being used.
    
    Also move gpio_is_input() definition in preparation for the
    next patch that setups the controller's irq_chip driver when
    a caller requests an interrupt line.
    
    Acked-by: Stephen Warren <swarren@nvidia.com>
    Tested-by: George Cherian <george.cherian@ti.com>
    Tested-by: Aaro Koskinen <aaro.koskinen@iki.fi>
    Tested-by: Lars Poeschel <poeschel@lemonage.de>
    Reviewed-by: Kevin Hilman <khilman@linaro.org>
    Tested-by: Kevin Hilman <khilman@linaro.org>
    Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
    Acked-by: Tony Lindgren <tony@atomide.com>
    Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b53bd7476d61cdf45458029769a043993913bc40
Author: Dan Aloni <alonid@stratoscale.com>
Date:   Mon Sep 30 13:45:02 2013 -0700

    fs/binfmt_elf.c: prevent a coredump with a large vm_map_count from Oopsing
    
    commit 72023656961b8c81a168a7a6762d589339d0d7ec upstream.
    
    A high setting of max_map_count, and a process core-dumping with a large
    enough vm_map_count could result in an NT_FILE note not being written,
    and the kernel crashing immediately later because it has assumed
    otherwise.
    
    Reproduction of the oops-causing bug described here:
    
        https://lkml.org/lkml/2013/8/30/50
    
    Rge ussue originated in commit 2aa362c49c31 ("coredump: extend core dump
    note section to contain file names of mapped file") from Oct 4, 2012.
    
    This patch make that section optional in that case.  fill_files_note()
    should signify the error, and also let the info struct in
    elf_core_dump() be zero-initialized so that we can check for the
    optionally written note.
    
    [akpm@linux-foundation.org: avoid abusing E2BIG, remove a couple of not-really-needed local variables]
    [akpm@linux-foundation.org: fix sparse warning]
    Signed-off-by: Dan Aloni <alonid@stratoscale.com>
    Cc: Al Viro <viro@zeniv.linux.org.uk>
    Cc: Denys Vlasenko <vda.linux@googlemail.com>
    Reported-by: Martin MOKREJS <mmokrejs@gmail.com>
    Tested-by: Martin MOKREJS <mmokrejs@gmail.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 f05f1c657da0414362444919341d97d07e53b30d
Author: Nishanth Menon <nm@ti.com>
Date:   Fri Sep 27 08:25:14 2013 -0500

    regulator: ti-abb: Fix bias voltage glitch in transition to bypass mode
    
    commit bf00ca35cec8f0894dcfd90f88b03af1d5c7b86f upstream.
    
    As documented in Application Note SWPA117 v2.1(NDA), LDO override has a
    requirement that when switching from Bias active + override active
    mode(FBB/RBB) to Bypass(nominal) mode, LDO reset must be performed
    *after* LDO transitions to Bypass(nominal) mode.
    
    The same rule in reverse applies when switching from a ABB bypass mode
    to ABB enabled - LDO override *must* be performed prior to transition to
    required ABB mode, if we do not do that, the same glitch takes place.
    
    Currently while transitioning to ABB bypass, we reset the LDO overide
    prior to the transition which causes a few milliseconds where ABB LDO
    voltage could go all the way to 800mV(based on SoC process node),
    during this period, the delta voltage between VDD rail and VBB rail
    could cause the system to improperly function.
    
    Signed-off-by: Nishanth Menon <nm@ti.com>
    Signed-off-by: Mark Brown <broonie@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d9b834c61f22b8fc38a32cfde86017381f370336
Author: Gabor Juhos <juhosg@openwrt.org>
Date:   Wed Sep 25 15:32:35 2013 +0200

    avr32: fix clockevents kernel warning
    
    commit 1b0135b5e20c56b2edae29e92b91c0b12c983432 upstream.
    
    Since commit 01426478df3a8791ff5c8b6b82d409e699cfaf38
    (avr32: Use generic idle loop) the kernel throws the
    following warning on avr32:
    
      WARNING: at 900322e4 [verbose debug info unavailable]
      Modules linked in:
      CPU: 0 PID: 0 Comm: swapper Not tainted 3.12.0-rc2 #117
      task: 901c3ecc ti: 901c0000 task.ti: 901c0000
      PC is at cpu_idle_poll_ctrl+0x1c/0x38
      LR is at comparator_mode+0x3e/0x40
      pc : [<900322e4>]    lr : [<90014882>]    Not tainted
      sp : 901c1f74  r12: 00000000  r11: 901c74a0
      r10: 901d2510  r9 : 00000001  r8 : 901db4de
      r7 : 901c74a0  r6 : 00000001  r5 : 00410020  r4 : 901db574
      r3 : 00410024  r2 : 90206fe0  r1 : 00000000  r0 : 007f0000
      Flags: qvnzc
      Mode bits: hjmde....G
      CPU Mode: Supervisor
      Call trace:
       [<90039ede>] clockevents_set_mode+0x16/0x2e
       [<90039f00>] clockevents_shutdown+0xa/0x1e
       [<9003a078>] clockevents_exchange_device+0x58/0x70
       [<9003a78c>] tick_check_new_device+0x38/0x54
       [<9003a1a2>] clockevents_register_device+0x32/0x90
       [<900035c4>] time_init+0xa8/0x108
       [<90000520>] start_kernel+0x128/0x23c
    
    When the 'avr32_comparator' clockevent device is registered,
    the clockevent core sets the mode of that clockevent device
    to CLOCK_EVT_MODE_SHUTDOWN. Due to this, the 'comparator_mode'
    function calls the 'cpu_idle_poll_ctrl' to disables idle poll.
    This results in the aforementioned warning because the polling
    is not enabled yet.
    
    Change the code to only disable idle poll if it is enabled by
    the same function to avoid the warning.
    
    Signed-off-by: Gabor Juhos <juhosg@openwrt.org>
    Acked-by: Hans-Christian Egtvedt <egtvedt@samfundet.no>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a3e15ec9f732f9dbdcf327dd50ec376bdef75728
Author: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Date:   Tue Oct 1 18:05:00 2013 +0200

    ip6tnl: allow to use rtnl ops on fb tunnel
    
    [ Upstream commit bb8140947a247b9aa15652cc24dc555ebb0b64b0 ]
    
    rtnl ops where introduced by c075b13098b3 ("ip6tnl: advertise tunnel param via
    rtnl"), but I forget to assign rtnl ops to fb tunnels.
    
    Now that it is done, we must remove the explicit call to
    unregister_netdevice_queue(), because  the fallback tunnel is added to the queue
    in ip6_tnl_destroy_tunnels() when checking rtnl_link_ops of all netdevices (this
    is valid since commit 0bd8762824e7 ("ip6tnl: add x-netns support")).
    
    Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3783100374653e2e7fbdf68c710f5f9562880326
Author: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Date:   Tue Oct 1 18:04:59 2013 +0200

    sit: allow to use rtnl ops on fb tunnel
    
    [ Upstream commit 205983c43700ac3a81e7625273a3fa83cd2759b5 ]
    
    rtnl ops where introduced by ba3e3f50a0e5 ("sit: advertise tunnel param via
    rtnl"), but I forget to assign rtnl ops to fb tunnels.
    
    Now that it is done, we must remove the explicit call to
    unregister_netdevice_queue(), because  the fallback tunnel is added to the queue
    in sit_destroy_tunnels() when checking rtnl_link_ops of all netdevices (this
    is valid since commit 5e6700b3bf98 ("sit: add support of x-netns")).
    
    Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 196eb57b30433a60f2a488e06dd46cf56999b15c
Author: Steffen Klassert <steffen.klassert@secunet.com>
Date:   Tue Oct 1 11:35:51 2013 +0200

    ip_tunnel_core: Change __skb_push back to skb_push
    
    [ Upstream commit 78a3694d44a029242dd0830b34ab20ef1704be35 ]
    
    Git commit 0e6fbc5b ("ip_tunnels: extend iptunnel_xmit()")
    moved the IP header installation to iptunnel_xmit() and
    changed skb_push() to __skb_push(). This makes possible
    bugs hard to track down, so change it back to skb_push().
    
    Cc: Pravin Shelar <pshelar@nicira.com>
    Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0accb77476d803ae62f2519c04e32f9eb2495698
Author: Steffen Klassert <steffen.klassert@secunet.com>
Date:   Tue Oct 1 11:33:59 2013 +0200

    ip_tunnel: Fix a memory corruption in ip_tunnel_xmit
    
    [ Upstream commit 3e08f4a72f689c6296d336c2aab4bddd60c93ae2 ]
    
    We might extend the used aera of a skb beyond the total
    headroom when we install the ipip header. Fix this by
    calling skb_cow_head() unconditionally.
    
    Bug was introduced with commit c544193214
    ("GRE: Refactor GRE tunneling code.")
    
    Cc: Pravin Shelar <pshelar@nicira.com>
    Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit eeb6df7a3b949813f257680802fda8dd4a3996ab
Author: Ricardo Ribalda <ricardo.ribalda@gmail.com>
Date:   Tue Oct 1 08:17:10 2013 +0200

    ll_temac: Reset dma descriptors indexes on ndo_open
    
    [ Upstream commit 7167cf0e8cd10287b7912b9ffcccd9616f382922 ]
    
    The dma descriptors indexes are only initialized on the probe function.
    
    If a packet is on the buffer when temac_stop is called, the dma
    descriptors indexes can be left on a incorrect state where no other
    package can be sent.
    
    So an interface could be left in an usable state after ifdow/ifup.
    
    This patch makes sure that the descriptors indexes are in a proper
    status when the device is open.
    
    Signed-off-by: Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6b13db47f96a5ec8705ea90fc209256f227ec1b1
Author: Salam Noureddine <noureddine@aristanetworks.com>
Date:   Sun Sep 29 13:41:34 2013 -0700

    ipv6 mcast: use in6_dev_put in timer handlers instead of __in6_dev_put
    
    [ Upstream commit 9260d3e1013701aa814d10c8fc6a9f92bd17d643 ]
    
    It is possible for the timer handlers to run after the call to
    ipv6_mc_down so use in6_dev_put instead of __in6_dev_put in the
    handler function in order to do proper cleanup when the refcnt
    reaches 0. Otherwise, the refcnt can reach zero without the
    inet6_dev being destroyed and we end up leaking a reference to
    the net_device and see messages like the following,
    
    unregister_netdevice: waiting for eth0 to become free. Usage count = 1
    
    Tested on linux-3.4.43.
    
    Signed-off-by: Salam Noureddine <noureddine@aristanetworks.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6644f8f7fd8b580ba118d6403a670b2daab06e01
Author: Salam Noureddine <noureddine@aristanetworks.com>
Date:   Sun Sep 29 13:39:42 2013 -0700

    ipv4 igmp: use in_dev_put in timer handlers instead of __in_dev_put
    
    [ Upstream commit e2401654dd0f5f3fb7a8d80dad9554d73d7ca394 ]
    
    It is possible for the timer handlers to run after the call to
    ip_mc_down so use in_dev_put instead of __in_dev_put in the handler
    function in order to do proper cleanup when the refcnt reaches 0.
    Otherwise, the refcnt can reach zero without the in_device being
    destroyed and we end up leaking a reference to the net_device and
    see messages like the following,
    
    unregister_netdevice: waiting for eth0 to become free. Usage count = 1
    
    Tested on linux-3.4.43.
    
    Signed-off-by: Salam Noureddine <noureddine@aristanetworks.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ea3ba3a33a3bc71bff6e6d58b3cfd1adbc94b2af
Author: Hannes Frederic Sowa <hannes@stressinduktion.org>
Date:   Sun Sep 29 05:40:50 2013 +0200

    ipv6: gre: correct calculation of max_headroom
    
    [ Upstream commit 3da812d860755925da890e8c713f2d2e2d7b1bae ]
    
    gre_hlen already accounts for sizeof(struct ipv6_hdr) + gre header,
    so initialize max_headroom to zero. Otherwise the
    
    	if (encap_limit >= 0) {
    		max_headroom += 8;
    		mtu -= 8;
    	}
    
    increments an uninitialized variable before max_headroom was reset.
    
    Found with coverity: 728539
    
    Cc: Dmitry Kozlov <xeb@mail.ru>
    Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
    Acked-by: Eric Dumazet <edumazet@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 57451ff312bea094ecd5abdd983e910cbd8cfd24
Author: Neil Horman <nhorman@tuxdriver.com>
Date:   Fri Sep 27 12:22:15 2013 -0400

    bonding: Fix broken promiscuity reference counting issue
    
    [ Upstream commit 5a0068deb611109c5ba77358be533f763f395ee4 ]
    
    Recently grabbed this report:
    https://bugzilla.redhat.com/show_bug.cgi?id=1005567
    
    Of an issue in which the bonding driver, with an attached vlan encountered the
    following errors when bond0 was taken down and back up:
    
    dummy1: promiscuity touches roof, set promiscuity failed. promiscuity feature of
    device might be broken.
    
    The error occurs because, during __bond_release_one, if we release our last
    slave, we take on a random mac address and issue a NETDEV_CHANGEADDR
    notification.  With an attached vlan, the vlan may see that the vlan and bond
    mac address were in sync, but no longer are.  This triggers a call to dev_uc_add
    and dev_set_rx_mode, which enables IFF_PROMISC on the bond device.  Then, when
    we complete __bond_release_one, we use the current state of the bond flags to
    determine if we should decrement the promiscuity of the releasing slave.  But
    since the bond changed promiscuity state during the release operation, we
    incorrectly decrement the slave promisc count when it wasn't in promiscuous mode
    to begin with, causing the above error
    
    Fix is pretty simple, just cache the bonding flags at the start of the function
    and use those when determining the need to set promiscuity.
    
    This is also needed for the ALLMULTI flag
    
    Reported-by: Mark Wu <wudxw@linux.vnet.ibm.com>
    CC: Jay Vosburgh <fubar@us.ibm.com>
    CC: Andy Gospodarek <andy@greyhouse.net>
    CC: Mark Wu <wudxw@linux.vnet.ibm.com>
    CC: "David S. Miller" <davem@davemloft.net>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 39f8795aaca352e482c1d0a0dff4be5feeef00e9
Author: Peter Korsgaard <peter@korsgaard.com>
Date:   Mon Sep 30 23:28:20 2013 +0200

    dm9601: fix IFF_ALLMULTI handling
    
    [ Upstream commit bf0ea6380724beb64f27a722dfc4b0edabff816e ]
    
    Pass-all-multicast is controlled by bit 3 in RX control, not bit 2
    (pass undersized frames).
    
    Reported-by: Joseph Chang <joseph_chang@davicom.com.tw>
    Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 55f08149b0ebdd3ed44f9b361829ca924c35e3a8
Author: Pravin B Shelar <pshelar@nicira.com>
Date:   Wed Sep 25 09:57:47 2013 -0700

    ip_tunnel: Do not use stale inner_iph pointer.
    
    [ Upstream commit d4a71b155c12d0d429c6b69d94076d6d57e2a7a7 ]
    
    While sending packet skb_cow_head() can change skb header which
    invalidates inner_iph pointer to skb header. Following patch
    avoid using it. Found by code inspection.
    
    This bug was introduced by commit 0e6fbc5b6c6218 (ip_tunnels: extend
    iptunnel_xmit()).
    
    Signed-off-by: Pravin B Shelar <pshelar@nicira.com>
    Acked-by: Eric Dumazet <edumazet@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1d9aa1c2278f3c77af5c5c5132afe596a97f8d13
Author: Eric Dumazet <edumazet@google.com>
Date:   Tue Sep 24 06:19:57 2013 -0700

    net: net_secret should not depend on TCP
    
    [ Upstream commit 9a3bab6b05383f1e4c3716b3615500c51285959e ]
    
    A host might need net_secret[] and never open a single socket.
    
    Problem added in commit aebda156a570782
    ("net: defer net_secret[] initialization")
    
    Based on prior patch from Hannes Frederic Sowa.
    
    Reported-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Acked-by: Hannes Frederic Sowa <hannes@strressinduktion.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3e459c8c1de3e9098e7fb0b97d5cb6121bef48a8
Author: Catalin(ux) M. BOIE <catab@embedromix.ro>
Date:   Mon Sep 23 23:04:19 2013 +0300

    IPv6 NAT: Do not drop DNATed 6to4/6rd packets
    
    [ Upstream commit 7df37ff33dc122f7bd0614d707939fe84322d264 ]
    
    When a router is doing DNAT for 6to4/6rd packets the latest
    anti-spoofing commit 218774dc ("ipv6: add anti-spoofing checks for
    6to4 and 6rd") will drop them because the IPv6 address embedded does
    not match the IPv4 destination. This patch will allow them to pass by
    testing if we have an address that matches on 6to4/6rd interface.  I
    have been hit by this problem using Fedora and IPV6TO4_IPV4ADDR.
    Also, log the dropped packets (with rate limit).
    
    Signed-off-by: Catalin(ux) M. BOIE <catab@embedromix.ro>
    Acked-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3c984a0f41f7cfffe2c44f3e66c1883270b07bfc
Author: Roger Luethi <rl@hellgate.ch>
Date:   Sat Sep 21 14:24:11 2013 +0200

    via-rhine: fix VLAN priority field (PCP, IEEE 802.1p)
    
    [ Upstream commit 207070f5221e2a901d56a49df9cde47d9b716cd7 ]
    
    Outgoing packets sent by via-rhine have their VLAN PCP field off by one
    (when hardware acceleration is enabled). The TX descriptor expects only VID
    and PCP (without a CFI/DEI bit).
    
    Peter Boström noticed and reported the bug.
    
    Signed-off-by: Roger Luethi <rl@hellgate.ch>
    Cc: Peter Boström <peter.bostrom@netrounds.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e44294a4239f412272553f9c0a168e545b1f341b
Author: Hannes Frederic Sowa <hannes@stressinduktion.org>
Date:   Sat Sep 21 06:27:00 2013 +0200

    ipv6: udp packets following an UFO enqueued packet need also be handled by UFO
    
    [ Upstream commit 2811ebac2521ceac84f2bdae402455baa6a7fb47 ]
    
    In the following scenario the socket is corked:
    If the first UDP packet is larger then the mtu we try to append it to the
    write queue via ip6_ufo_append_data. A following packet, which is smaller
    than the mtu would be appended to the already queued up gso-skb via
    plain ip6_append_data. This causes random memory corruptions.
    
    In ip6_ufo_append_data we also have to be careful to not queue up the
    same skb multiple times. So setup the gso frame only when no first skb
    is available.
    
    This also fixes a shortcoming where we add the current packet's length to
    cork->length but return early because of a packet > mtu with dontfrag set
    (instead of sutracting it again).
    
    Found with trinity.
    
    Cc: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
    Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
    Reported-by: Dmitry Vyukov <dvyukov@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a1c008db75b819e29a62ff3fbeffe493bf7ece93
Author: Mikulas Patocka <mpatocka@redhat.com>
Date:   Fri Sep 20 13:53:22 2013 -0400

    skge: fix invalid value passed to pci_unmap_sigle
    
    [ Upstream commit 3361dc9538832a2a9150a8c722374ca844bf8dc8 ]
    
    In my patch c194992cbe71c20bb3623a566af8d11b0bfaa721 ("skge: fix
    broken driver") I didn't fix the skge bug correctly. The value of the
    new mapping (not old) was passed to pci_unmap_single.
    
    If we enable CONFIG_DMA_API_DEBUG, it results in this warning:
    WARNING: CPU: 0 PID: 0 at lib/dma-debug.c:986 check_sync+0x4c4/0x580()
    skge 0000:02:07.0: DMA-API: device driver tries to sync DMA memory it has
    not allocated [device address=0x000000023a0096c0] [size=1536 bytes]
    
    This patch makes the skge driver pass the correct value to
    pci_unmap_single and fixes the warning. It copies the old descriptor to
    on-stack variable "ee" and unmaps it if mapping of the new descriptor
    succeeded.
    
    This patch should be backported to 3.11-stable.
    
    Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
    Reported-by: Francois Romieu <romieu@fr.zoreil.com>
    Tested-by: Mikulas Patocka <mpatocka@redhat.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c66097370b7dcfc508dc5a7b8e52adc77fba9961
Author: Ansis Atteka <aatteka@nicira.com>
Date:   Wed Sep 18 15:29:53 2013 -0700

    ip: generate unique IP identificator if local fragmentation is allowed
    
    [ Upstream commit 703133de331a7a7df47f31fb9de51dc6f68a9de8 ]
    
    If local fragmentation is allowed, then ip_select_ident() and
    ip_select_ident_more() need to generate unique IDs to ensure
    correct defragmentation on the peer.
    
    For example, if IPsec (tunnel mode) has to encrypt large skbs
    that have local_df bit set, then all IP fragments that belonged
    to different ESP datagrams would have used the same identificator.
    If one of these IP fragments would get lost or reordered, then
    peer could possibly stitch together wrong IP fragments that did
    not belong to the same datagram. This would lead to a packet loss
    or data corruption.
    
    Signed-off-by: Ansis Atteka <aatteka@nicira.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b55876a61f91eb73dcbf3eae25923f13f12eb5ab
Author: Ansis Atteka <aatteka@nicira.com>
Date:   Wed Sep 18 15:29:52 2013 -0700

    ip: use ip_hdr() in __ip_make_skb() to retrieve IP header
    
    [ Upstream commit 749154aa56b57652a282cbde57a57abc278d1205 ]
    
    skb->data already points to IP header, but for the sake of
    consistency we can also use ip_hdr() to retrieve it.
    
    Signed-off-by: Ansis Atteka <aatteka@nicira.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5ebe03a86dc7a7837b7451c4190c276356ff6de1
Author: Duan Jiong <duanj.fnst@cn.fujitsu.com>
Date:   Wed Sep 18 20:03:27 2013 +0800

    net:dccp: do not report ICMP redirects to user space
    
    [ Upstream commit bd784a140712fd06674f2240eecfc4ccae421129 ]
    
    DCCP shouldn't be setting sk_err on redirects as it
    isn't an error condition. it should be doing exactly
    what tcp is doing and leaving the error handler without
    touching the socket.
    
    Signed-off-by: Duan Jiong <duanj.fnst@cn.fujitsu.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0f316d06ee3e54e9ea1ebe29668a40a7dd625648
Author: Antonio Quartulli <antonio@open-mesh.com>
Date:   Wed Sep 11 19:14:44 2013 +0200

    batman-adv: set the TAG flag for the vid passed to BLA
    
    [ Upstream commit 4c18c425b2d228415b635e97a64737d7f27c5536 ]
    
    When receiving or sending a packet a packet on a VLAN, the
    vid has to be marked with the TAG flag in order to make any
    component in batman-adv understand that the packet is coming
    from a really tagged network.
    
    This fix the Bridge Loop Avoidance behaviour which was not
    able to send announces over VLAN interfaces.
    
    Introduced by 0b1da1765fdb00ca5d53bc95c9abc70dfc9aae5b
    ("batman-adv: change VID semantic in the BLA code")
    
    Signed-off-by: Antonio Quartulli <antonio@open-mesh.org>
    Acked-by: Simon Wunderlich <siwu@hrz.tu-chemnitz.de>
    Signed-off-by: Marek Lindner <mareklindner@neomailbox.ch>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 936cac0cc8457c4d79b14244ceb050a7487edabe
Author: Sridhar Samudrala <sri@us.ibm.com>
Date:   Tue Sep 17 12:12:40 2013 -0700

    vxlan: Avoid creating fdb entry with NULL destination
    
    [ Upstream commit 2936b6ab455433a5ad14c7a1d2473afe1fa3faa7 ]
    
    Commit afbd8bae9c798c5cdbe4439d3a50536b5438247c
       vxlan: add implicit fdb entry for default destination
    creates an implicit fdb entry for default destination. This results
    in an invalid fdb entry if default destination is not specified.
    For ex:
      ip link add vxlan1 type vxlan id 100
    creates the following fdb entry
      00:00:00:00:00:00 dev vxlan1 dst 0.0.0.0 self permanent
    
    This patch fixes this issue by creating an fdb entry only if a
    valid default destination is specified.
    
    Signed-off-by: Sridhar Samudrala <sri@us.ibm.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6a5bb65640a56fbb23e578e2891eb3639458cabb
Author: Vineet Gupta <Vineet.Gupta1@synopsys.com>
Date:   Wed Sep 4 17:17:15 2013 +0530

    ethernet/arc/arc_emac: Fix huge delays in large file copies
    
    [ Upstream commit 27082ee1b92f4d41e78b85fe40f6ab39673fba00 ]
    
    copying large files to a NFS mounted host was taking absurdly large
    time.
    
    Turns out that TX BD reclaim had a sublte bug.
    
    Loop starts off from @txbd_dirty cursor and stops when it hits a BD
    still in use by controller. However when it stops it needs to keep the
    cursor at that very BD to resume scanning in next iteration. However it
    was erroneously incrementing the cursor, causing the next scan(s) to
    fail too, unless the BD chain was completely drained out.
    
    [ARCLinux]$ ls -l -sh /disk/log.txt
     17976 -rw-r--r--    1 root     root       17.5M Sep  /disk/log.txt
    
    ========== Before =====================
    [ARCLinux]$ time cp /disk/log.txt /mnt/.
    real    31m 7.95s
    user    0m 0.00s
    sys     0m 0.10s
    
    ========== After =====================
    [ARCLinux]$ time cp /disk/log.txt /mnt/.
    real    0m 24.33s
    user    0m 0.00s
    sys     0m 0.19s
    
    Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
    Cc: Alexey Brodkin <abrodkin@synopsys.com> (commit_signer:3/4=75%)
    Cc: "David S. Miller" <davem@davemloft.net> (commit_signer:3/4=75%)
    Cc: netdev@vger.kernel.org
    Cc: linux-kernel@vger.kernel.org
    Cc: arc-linux-dev@synopsys.com
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6f4a38bf6dfeda68612299aaf7cb8f0e5f7e1245
Author: Daniel Borkmann <dborkman@redhat.com>
Date:   Mon Sep 16 12:36:02 2013 +0200

    net: sctp: rfc4443: do not report ICMP redirects to user space
    
    [ Upstream commit 3f96a532113131d5a65ac9e00fc83cfa31b0295f ]
    
    Adapt the same behaviour for SCTP as present in TCP for ICMP redirect
    messages. For IPv6, RFC4443, section 2.4. says:
    
      ...
      (e) An ICMPv6 error message MUST NOT be originated as a result of
          receiving the following:
      ...
           (e.2) An ICMPv6 redirect message [IPv6-DISC].
      ...
    
    Therefore, do not report an error to user space, just invoke dst's redirect
    callback and leave, same for IPv4 as done in TCP as well. The implication
    w/o having this patch could be that the reception of such packets would
    generate a poll notification and in worst case it could even tear down the
    whole connection. Therefore, stop updating sk_err on redirects.
    
    Reported-by: Duan Jiong <duanj.fnst@cn.fujitsu.com>
    Reported-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
    Suggested-by: Vlad Yasevich <vyasevich@gmail.com>
    Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 63e80cdb250fe817e0d6dd101cb92f73d006de9a
Author: Ding Zhi <zhi.ding@6wind.com>
Date:   Mon Sep 16 11:31:15 2013 +0200

    ip6_tunnels: raddr and laddr are inverted in nl msg
    
    [ Upstream commit 0d2ede929f61783aebfb9228e4d32a0546ee4d23 ]
    
    IFLA_IPTUN_LOCAL and IFLA_IPTUN_REMOTE were inverted.
    
    Introduced by c075b13098b3 (ip6tnl: advertise tunnel param via rtnl).
    
    Signed-off-by: Ding Zhi <zhi.ding@6wind.com>
    Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 120edba7e46f928b7fd13b40ede405bbd6a1b290
Author: Hong Zhiguo <zhiguohong@tencent.com>
Date:   Sat Sep 14 22:42:28 2013 +0800

    bridge: fix NULL pointer deref of br_port_get_rcu
    
    [ Upstream commit 716ec052d2280d511e10e90ad54a86f5b5d4dcc2 ]
    
    The NULL deref happens when br_handle_frame is called between these
    2 lines of del_nbp:
    	dev->priv_flags &= ~IFF_BRIDGE_PORT;
    	/* --> br_handle_frame is called at this time */
    	netdev_rx_handler_unregister(dev);
    
    In br_handle_frame the return of br_port_get_rcu(dev) is dereferenced
    without check but br_port_get_rcu(dev) returns NULL if:
    	!(dev->priv_flags & IFF_BRIDGE_PORT)
    
    Eric Dumazet pointed out the testing of IFF_BRIDGE_PORT is not necessary
    here since we're in rcu_read_lock and we have synchronize_net() in
    netdev_rx_handler_unregister. So remove the testing of IFF_BRIDGE_PORT
    and by the previous patch, make sure br_port_get_rcu is called in
    bridging code.
    
    Signed-off-by: Hong Zhiguo <zhiguohong@tencent.com>
    Acked-by: Eric Dumazet <edumazet@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6a0cacf7e1ddc3669019f260ab86f11024a73ce3
Author: Hong Zhiguo <zhiguohong@tencent.com>
Date:   Sat Sep 14 22:42:27 2013 +0800

    bridge: use br_port_get_rtnl within rtnl lock
    
    [ Upstream commit 1fb1754a8c70d69ab480763c423e0a74369c4a67 ]
    
    current br_port_get_rcu is problematic in bridging path
    (NULL deref). Change these calls in netlink path first.
    
    Signed-off-by: Hong Zhiguo <zhiguohong@tencent.com>
    Acked-by: Eric Dumazet <edumazet@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0e308361d7ca0bf8b23fd472b90aae0fb10a1c32
Author: Herbert Xu <herbert@gondor.apana.org.au>
Date:   Thu Sep 12 17:12:05 2013 +1000

    bridge: Clamp forward_delay when enabling STP
    
    [ Upstream commit be4f154d5ef0ca147ab6bcd38857a774133f5450 ]
    
    At some point limits were added to forward_delay.  However, the
    limits are only enforced when STP is enabled.  This created a
    scenario where you could have a value outside the allowed range
    while STP is disabled, which then stuck around even after STP
    is enabled.
    
    This patch fixes this by clamping the value when we enable STP.
    
    I had to move the locking around a bit to ensure that there is
    no window where someone could insert a value outside the range
    while we're in the middle of enabling STP.
    
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    
    Cheers,
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2e122eb8248a02f941b1e53a43e4e6431f41b5cc
Author: Chris Healy <cphealy@gmail.com>
Date:   Wed Sep 11 21:37:47 2013 -0700

    resubmit bridge: fix message_age_timer calculation
    
    [ Upstream commit 9a0620133ccce9dd35c00a96405c8d80938c2cc0 ]
    
    This changes the message_age_timer calculation to use the BPDU's max age as
    opposed to the local bridge's max age.  This is in accordance with section
    8.6.2.3.2 Step 2 of the 802.1D-1998 sprecification.
    
    With the current implementation, when running with very large bridge
    diameters, convergance will not always occur even if a root bridge is
    configured to have a longer max age.
    
    Tested successfully on bridge diameters of ~200.
    
    Signed-off-by: Chris Healy <cphealy@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1bc5d1065ee4ed31bc6632d707118e5d7bafdf57
Author: David Vrabel <david.vrabel@citrix.com>
Date:   Wed Sep 11 14:52:48 2013 +0100

    xen-netback: count number required slots for an skb more carefully
    
    [ Upstream commit 6e43fc04a6bc357d260583b8440882f28069207f ]
    
    When a VM is providing an iSCSI target and the LUN is used by the
    backend domain, the generated skbs for direct I/O writes to the disk
    have large, multi-page skb->data but no frags.
    
    With some lengths and starting offsets, xen_netbk_count_skb_slots()
    would be one short because the simple calculation of
    DIV_ROUND_UP(skb_headlen(), PAGE_SIZE) was not accounting for the
    decisions made by start_new_rx_buffer() which does not guarantee
    responses are fully packed.
    
    For example, a skb with length < 2 pages but which spans 3 pages would
    be counted as requiring 2 slots but would actually use 3 slots.
    
    skb->data:
    
        |        1111|222222222222|3333        |
    
    Fully packed, this would need 2 slots:
    
        |111122222222|22223333    |
    
    But because the 2nd page wholy fits into a slot it is not split across
    slots and goes into a slot of its own:
    
        |1111        |222222222222|3333        |
    
    Miscounting the number of slots means netback may push more responses
    than the number of available requests.  This will cause the frontend
    to get very confused and report "Too many frags/slots".  The frontend
    never recovers and will eventually BUG.
    
    Fix this by counting the number of required slots more carefully.  In
    xen_netbk_count_skb_slots(), more closely follow the algorithm used by
    xen_netbk_gop_skb() by introducing xen_netbk_count_frag_slots() which
    is the dry-run equivalent of netbk_gop_frag_copy().
    
    Signed-off-by: David Vrabel <david.vrabel@citrix.com>
    Acked-by: Ian Campbell <ian.campbell@citrix.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit dca97a6264d985986ee3a38ed01df8cfa6b40288
Author: Daniel Borkmann <dborkman@redhat.com>
Date:   Wed Sep 11 16:58:36 2013 +0200

    net: sctp: fix ipv6 ipsec encryption bug in sctp_v6_xmit
    
    [ Upstream commit 95ee62083cb6453e056562d91f597552021e6ae7 ]
    
    Alan Chester reported an issue with IPv6 on SCTP that IPsec traffic is not
    being encrypted, whereas on IPv4 it is. Setting up an AH + ESP transport
    does not seem to have the desired effect:
    
    SCTP + IPv4:
    
      22:14:20.809645 IP (tos 0x2,ECT(0), ttl 64, id 0, offset 0, flags [DF], proto AH (51), length 116)
        192.168.0.2 > 192.168.0.5: AH(spi=0x00000042,sumlen=16,seq=0x1): ESP(spi=0x00000044,seq=0x1), length 72
      22:14:20.813270 IP (tos 0x2,ECT(0), ttl 64, id 0, offset 0, flags [DF], proto AH (51), length 340)
        192.168.0.5 > 192.168.0.2: AH(spi=0x00000043,sumlen=16,seq=0x1):
    
    SCTP + IPv6:
    
      22:31:19.215029 IP6 (class 0x02, hlim 64, next-header SCTP (132) payload length: 364)
        fe80::222:15ff:fe87:7fc.3333 > fe80::92e6:baff:fe0d:5a54.36767: sctp
        1) [INIT ACK] [init tag: 747759530] [rwnd: 62464] [OS: 10] [MIS: 10]
    
    Moreover, Alan says:
    
      This problem was seen with both Racoon and Racoon2. Other people have seen
      this with OpenSwan. When IPsec is configured to encrypt all upper layer
      protocols the SCTP connection does not initialize. After using Wireshark to
      follow packets, this is because the SCTP packet leaves Box A unencrypted and
      Box B believes all upper layer protocols are to be encrypted so it drops
      this packet, causing the SCTP connection to fail to initialize. When IPsec
      is configured to encrypt just SCTP, the SCTP packets are observed unencrypted.
    
    In fact, using `socat sctp6-listen:3333 -` on one end and transferring "plaintext"
    string on the other end, results in cleartext on the wire where SCTP eventually
    does not report any errors, thus in the latter case that Alan reports, the
    non-paranoid user might think he's communicating over an encrypted transport on
    SCTP although he's not (tcpdump ... -X):
    
      ...
      0x0030: 5d70 8e1a 0003 001a 177d eb6c 0000 0000  ]p.......}.l....
      0x0040: 0000 0000 706c 6169 6e74 6578 740a 0000  ....plaintext...
    
    Only in /proc/net/xfrm_stat we can see XfrmInTmplMismatch increasing on the
    receiver side. Initial follow-up analysis from Alan's bug report was done by
    Alexey Dobriyan. Also thanks to Vlad Yasevich for feedback on this.
    
    SCTP has its own implementation of sctp_v6_xmit() not calling inet6_csk_xmit().
    This has the implication that it probably never really got updated along with
    changes in inet6_csk_xmit() and therefore does not seem to invoke xfrm handlers.
    
    SCTP's IPv4 xmit however, properly calls ip_queue_xmit() to do the work. Since
    a call to inet6_csk_xmit() would solve this problem, but result in unecessary
    route lookups, let us just use the cached flowi6 instead that we got through
    sctp_v6_get_dst(). Since all SCTP packets are being sent through sctp_packet_transmit(),
    we do the route lookup / flow caching in sctp_transport_route(), hold it in
    tp->dst and skb_dst_set() right after that. If we would alter fl6->daddr in
    sctp_v6_xmit() to np->opt->srcrt, we possibly could run into the same effect
    of not having xfrm layer pick it up, hence, use fl6_update_dst() in sctp_v6_get_dst()
    instead to get the correct source routed dst entry, which we assign to the skb.
    
    Also source address routing example from 625034113 ("sctp: fix sctp to work with
    ipv6 source address routing") still works with this patch! Nevertheless, in RFC5095
    it is actually 'recommended' to not use that anyway due to traffic amplification [1].
    So it seems we're not supposed to do that anyway in sctp_v6_xmit(). Moreover, if
    we overwrite the flow destination here, the lower IPv6 layer will be unable to
    put the correct destination address into IP header, as routing header is added in
    ipv6_push_nfrag_opts() but then probably with wrong final destination. Things aside,
    result of this patch is that we do not have any XfrmInTmplMismatch increase plus on
    the wire with this patch it now looks like:
    
    SCTP + IPv6:
    
      08:17:47.074080 IP6 2620:52:0:102f:7a2b:cbff:fe27:1b0a > 2620:52:0:102f:213:72ff:fe32:7eba:
        AH(spi=0x00005fb4,seq=0x1): ESP(spi=0x00005fb5,seq=0x1), length 72
      08:17:47.074264 IP6 2620:52:0:102f:213:72ff:fe32:7eba > 2620:52:0:102f:7a2b:cbff:fe27:1b0a:
        AH(spi=0x00003d54,seq=0x1): ESP(spi=0x00003d55,seq=0x1), length 296
    
    This fixes Kernel Bugzilla 24412. This security issue seems to be present since
    2.6.18 kernels. Lets just hope some big passive adversary in the wild didn't have
    its fun with that. lksctp-tools IPv6 regression test suite passes as well with
    this patch.
    
     [1] http://www.secdev.org/conf/IPv6_RH_security-csw07.pdf
    
    Reported-by: Alan Chester <alan.chester@tekelec.com>
    Reported-by: Alexey Dobriyan <adobriyan@gmail.com>
    Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
    Cc: Steffen Klassert <steffen.klassert@secunet.com>
    Cc: Hannes Frederic Sowa <hannes@stressinduktion.org>
    Acked-by: Vlad Yasevich <vyasevich@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6fc265f7a86d81e052508d03da555188f5882c3e
Author: Jason Wang <jasowang@redhat.com>
Date:   Wed Sep 11 18:09:48 2013 +0800

    tuntap: correctly handle error in tun_set_iff()
    
    [ Upstream commit 662ca437e714caaab855b12415d6ffd815985bc0 ]
    
    Commit c8d68e6be1c3b242f1c598595830890b65cea64a
    (tuntap: multiqueue support) only call free_netdev() on error in
    tun_set_iff(). This causes several issues:
    
    - memory of tun security were leaked
    - use after free since the flow gc timer was not deleted and the tfile
      were not detached
    
    This patch solves the above issues.
    
    Reported-by: Wannes Rombouts <wannes.rombouts@epitech.eu>
    Cc: Michael S. Tsirkin <mst@redhat.com>
    Signed-off-by: Jason Wang <jasowang@redhat.com>
    Acked-by: Michael S. Tsirkin <mst@redhat.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8ef8f14f527d12332fc459b0cabb6424872cb3fc
Author: Nikolay Aleksandrov <nikolay@redhat.com>
Date:   Thu Sep 19 15:02:35 2013 +0200

    netpoll: fix NULL pointer dereference in netpoll_cleanup
    
    [ Upstream commit d0fe8c888b1fd1a2f84b9962cabcb98a70988aec ]
    
    I've been hitting a NULL ptr deref while using netconsole because the
    np->dev check and the pointer manipulation in netpoll_cleanup are done
    without rtnl and the following sequence happens when having a netconsole
    over a vlan and we remove the vlan while disabling the netconsole:
    	CPU 1					CPU2
    					removes vlan and calls the notifier
    enters store_enabled(), calls
    netdev_cleanup which checks np->dev
    and then waits for rtnl
    					executes the netconsole netdev
    					release notifier making np->dev
    					== NULL and releases rtnl
    continues to dereference a member of
    np->dev which at this point is == NULL
    
    Signed-off-by: Nikolay Aleksandrov <nikolay@redhat.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f6dbceef21f13dc27e9b51a2ff372072fee962a4
Author: Sonic Zhang <sonic.zhang@analog.com>
Date:   Wed Sep 11 11:31:53 2013 +0800

    netpoll: Should handle ETH_P_ARP other than ETH_P_IP in netpoll_neigh_reply
    
    [ Upstream commit b0dd663b60944a3ce86430fa35549fb37968bda0 ]
    
    The received ARP request type in the Ethernet packet head is ETH_P_ARP other than ETH_P_IP.
    
    [ Bug introduced by commit b7394d2429c198b1da3d46ac39192e891029ec0f
      ("netpoll: prepare for ipv6") ]
    
    Signed-off-by: Sonic Zhang <sonic.zhang@analog.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b3483fd035fc4bb3e902fbbca11f5eec7dfa947e
Author: Francois Romieu <romieu@fr.zoreil.com>
Date:   Sun Sep 8 01:15:35 2013 +0200

    r8169: enforce RX_MULTI_EN for the 8168f.
    
    [ Upstream commit 3ced8c955e74d319f3e3997f7169c79d524dfd06 ]
    
    Same narrative as eb2dc35d99028b698cdedba4f5522bc43e576bd2 ("r8169: RxConfig
    hack for the 8168evl.") regarding AMD IOMMU errors.
    
    RTL_GIGA_MAC_VER_36 - 8168f as well - has not been reported to behave the
    same.
    
    Tested-by: David R <david@unsolicited.net>
    Tested-by: Frédéric Leroy <fredo@starox.org>
    Cc: Hayes Wang <hayeswang@realtek.com>
    Signed-off-by: Francois Romieu <romieu@fr.zoreil.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 122f032845078092adcb98b5e12a7cd94b08b5bc
Author: Vimalkumar <j.vimal@gmail.com>
Date:   Tue Sep 10 17:36:37 2013 -0700

    net_sched: htb: fix a typo in htb_change_class()
    
    [ Upstream commit f3ad857e3da1abaea780dc892b592cd86c541c52 ]
    
    Fix a typo added in commit 56b765b79 ("htb: improved accuracy at high
    rates")
    
    cbuffer should not be a copy of buffer.
    
    Signed-off-by: Vimalkumar <j.vimal@gmail.com>
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Cc: Jesper Dangaard Brouer <brouer@redhat.com>
    Cc: Jiri Pirko <jpirko@redhat.com>
    Reviewed-by: Jiri Pirko <jiri@resnulli.us>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 56fee7fee4bfbcb812eb719d1937eda8ddabc059
Author: Eric Dumazet <edumazet@google.com>
Date:   Thu Sep 26 08:44:06 2013 -0700

    net: flow_dissector: fix thoff for IPPROTO_AH
    
    [ Upstream commit b86783587b3d1d552326d955acee37eac48800f1 ]
    
    In commit 8ed781668dd49 ("flow_keys: include thoff into flow_keys for
    later usage"), we missed that existing code was using nhoff as a
    temporary variable that could not always contain transport header
    offset.
    
    This is not a problem for TCP/UDP because port offset (@poff)
    is 0 for these protocols.
    
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Cc: Daniel Borkmann <dborkman@redhat.com>
    Cc: Nikolay Aleksandrov <nikolay@redhat.com>
    Acked-by: Nikolay Aleksandrov <nikolay@redhat.com>
    Acked-by: Daniel Borkmann <dborkman@redhat.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit bfd16631035163f9ceeda50d544b0ac7c29838d8
Author: Eric Dumazet <edumazet@google.com>
Date:   Sat Sep 7 12:02:57 2013 -0700

    net: fix multiqueue selection
    
    [ Upstream commit 50d1784ee4683f073c0362ee360bfae7a3333d6c ]
    
    commit 416186fbf8c5b4e4465 ("net: Split core bits of netdev_pick_tx
    into __netdev_pick_tx") added a bug that disables caching of queue
    index in the socket.
    
    This is the source of packet reorders for TCP flows, and
    again this is happening more often when using FQ pacing.
    
    Old code was doing
    
    if (queue_index != old_index)
    	sk_tx_queue_set(sk, queue_index);
    
    Alexander renamed the variables but forgot to change sk_tx_queue_set()
    2nd parameter.
    
    if (queue_index != new_index)
    	sk_tx_queue_set(sk, queue_index);
    
    This means we store -1 over and over in sk->sk_tx_queue_mapping
    
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Cc: Alexander Duyck <alexander.h.duyck@intel.com>
    Acked-by: Alexander Duyck <alexander.h.duyck@intel.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6d88c9f48083a2c76347ca4390362f0bfb8c2bd2
Author: Daniel Borkmann <dborkman@redhat.com>
Date:   Sat Sep 7 20:51:21 2013 +0200

    net: sctp: fix smatch warning in sctp_send_asconf_del_ip
    
    [ Upstream commit 88362ad8f9a6cea787420b57cc27ccacef000dbe ]
    
    This was originally reported in [1] and posted by Neil Horman [2], he said:
    
      Fix up a missed null pointer check in the asconf code. If we don't find
      a local address, but we pass in an address length of more than 1, we may
      dereference a NULL laddr pointer. Currently this can't happen, as the only
      users of the function pass in the value 1 as the addrcnt parameter, but
      its not hot path, and it doesn't hurt to check for NULL should that ever
      be the case.
    
    The callpath from sctp_asconf_mgmt() looks okay. But this could be triggered
    from sctp_setsockopt_bindx() call with SCTP_BINDX_REM_ADDR and addrcnt > 1
    while passing all possible addresses from the bind list to SCTP_BINDX_REM_ADDR
    so that we do *not* find a single address in the association's bind address
    list that is not in the packed array of addresses. If this happens when we
    have an established association with ASCONF-capable peers, then we could get
    a NULL pointer dereference as we only check for laddr == NULL && addrcnt == 1
    and call later sctp_make_asconf_update_ip() with NULL laddr.
    
    BUT: this actually won't happen as sctp_bindx_rem() will catch such a case
    and return with an error earlier. As this is incredably unintuitive and error
    prone, add a check to catch at least future bugs here. As Neil says, its not
    hot path. Introduced by 8a07eb0a5 ("sctp: Add ASCONF operation on the
    single-homed host").
    
     [1] http://www.spinics.net/lists/linux-sctp/msg02132.html
     [2] http://www.spinics.net/lists/linux-sctp/msg02133.html
    
    Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
    Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
    Cc: Michio Honda <micchie@sfc.wide.ad.jp>
    Acked-By: Neil Horman <nhorman@tuxdriver.com>
    Acked-by: Vlad Yasevich <vyasevich@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7ee57d2c33149913e581a9408946cc0b53cf5a9d
Author: Daniel Borkmann <dborkman@redhat.com>
Date:   Sat Sep 7 16:44:59 2013 +0200

    net: sctp: fix bug in sctp_poll for SOCK_SELECT_ERR_QUEUE
    
    [ Upstream commit a0fb05d1aef0f5df936f80b726d1b3bfd4275f95 ]
    
    If we do not add braces around ...
    
      mask |= POLLERR |
              sock_flag(sk, SOCK_SELECT_ERR_QUEUE) ? POLLPRI : 0;
    
    ... then this condition always evaluates to true as POLLERR is
    defined as 8 and binary or'd with whatever result comes out of
    sock_flag(). Hence instead of (X | Y) ? A : B, transform it into
    X | (Y ? A : B). Unfortunatelty, commit 8facd5fb73 ("net: fix
    smatch warnings inside datagram_poll") forgot about SCTP. :-(
    
    Introduced by 7d4c04fc170 ("net: add option to enable error queue
    packets waking select").
    
    Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
    Cc: Jacob Keller <jacob.e.keller@intel.com>
    Acked-by: Neil Horman <nhorman@tuxdriver.com>
    Acked-by: Vlad Yasevich <vyasevich@gmail.com>
    Acked-by: Jacob Keller <jacob.e.keller@intel.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 12a5dc7cb582e1dd3cac0b82b43b9c26a049e794
Author: Daniel Borkmann <dborkman@redhat.com>
Date:   Sat Sep 7 15:13:20 2013 +0200

    net: fib: fib6_add: fix potential NULL pointer dereference
    
    [ Upstream commit ae7b4e1f213aa659aedf9c6ecad0bf5f0476e1e2 ]
    
    When the kernel is compiled with CONFIG_IPV6_SUBTREES, and we return
    with an error in fn = fib6_add_1(), then error codes are encoded into
    the return pointer e.g. ERR_PTR(-ENOENT). In such an error case, we
    write the error code into err and jump to out, hence enter the if(err)
    condition. Now, if CONFIG_IPV6_SUBTREES is enabled, we check for:
    
      if (pn != fn && pn->leaf == rt)
        ...
      if (pn != fn && !pn->leaf && !(pn->fn_flags & RTN_RTINFO))
        ...
    
    Since pn is NULL and fn is f.e. ERR_PTR(-ENOENT), then pn != fn
    evaluates to true and causes a NULL-pointer dereference on further
    checks on pn. Fix it, by setting both NULL in error case, so that
    pn != fn already evaluates to false and no further dereference
    takes place.
    
    This was first correctly implemented in 4a287eba2 ("IPv6 routing,
    NLM_F_* flag support: REPLACE and EXCL flags support, warn about
    missing CREATE flag"), but the bug got later on introduced by
    188c517a0 ("ipv6: return errno pointers consistently for fib6_add_1()").
    
    Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
    Cc: Lin Ming <mlin@ss.pku.edu.cn>
    Cc: Matti Vaittinen <matti.vaittinen@nsn.com>
    Cc: Hannes Frederic Sowa <hannes@stressinduktion.org>
    Acked-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
    Acked-by: Matti Vaittinen <matti.vaittinen@nsn.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 825e186e6a5cf14a539c55a5eca2cf17f442e57a
Author: Jiri Pirko <jiri@resnulli.us>
Date:   Fri Sep 6 16:02:25 2013 +0200

    ipv6/exthdrs: accept tlv which includes only padding
    
    [ Upstream commit 8112b1fe071be01a28a774ed55909e6f4b29712d ]
    
    In rfc4942 and rfc2460 I cannot find anything which would implicate to
    drop packets which have only padding in tlv.
    
    Current behaviour breaks TAHI Test v6LC.1.2.6.
    
    Problem was intruduced in:
    9b905fe6843 "ipv6/exthdrs: strict Pad1 and PadN check"
    
    Signed-off-by: Jiri Pirko <jiri@resnulli.us>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 893da29ecf2fd0aceb8d54ba8b3075e26728a33d
Author: Dave Jones <davej@redhat.com>
Date:   Thu Sep 5 13:43:34 2013 -0400

    tcp: Add missing braces to do_tcp_setsockopt
    
    [ Upstream commit e2e5c4c07caf810d7849658dca42f598b3938e21 ]
    
    Signed-off-by: Dave Jones <davej@fedoraproject.org>
    Acked-by: Neal Cardwell <ncardwell@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a0a686e2f93fab512b074fa334794d27c90e9898
Author: Dave Jones <davej@redhat.com>
Date:   Thu Sep 5 00:11:19 2013 -0400

    caif: Add missing braces to multiline if in cfctrl_linkup_request
    
    [ Upstream commit 0c1db731bfcf3a9fd6c58132134f8b0f423552f0 ]
    
    The indentation here implies this was meant to be a multi-line if.
    
    Introduced several years back in commit c85c2951d4da1236e32f1858db418221e624aba5
    ("caif: Handle dev_queue_xmit errors.")
    
    Signed-off-by: Dave Jones <davej@fedoraproject.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 971610ebfb945c194f828c98b55040606aee2367
Author: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Date:   Wed Sep 4 02:41:27 2013 +0400

    sh_eth: fix napi_{en|dis}able() calls racing against interrupts
    
    [ Upstream commit d2779e99468fd83ef1493c34f3803fec9aad8345 ]
    
    While implementing NAPI for the driver, I overlooked the race conditions where
    interrupt  handler might have called napi_schedule_prep() before napi_enable()
    was called or after napi_disable() was called. If RX interrupt happens, this
    would cause the endless interrupts and messages like:
    
    sh-eth eth0: ignoring interrupt, status 0x00040000, mask 0x01ff009f.
    
    The interrupt wouldn't even be masked by the kernel eventually since the handler
    would return IRQ_HANDLED all the time.
    
    As a fix, move napi_enable() call before request_irq() call and napi_disable()
    call after free_irq() call.
    
    Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3ff9ad9d2be9c139d55adab0604d3914c0ba97a9
Author: Jiri Kosina <jkosina@suse.cz>
Date:   Mon Jul 22 17:11:44 2013 +0200

    HID: fix unused rsize usage
    
    commit bc197eedef1ae082ec662c64c3f4aa302821fb7a upstream.
    
    27ce4050 ("HID: fix data access in implement()") by mistake removed
    a setting of buffer size in hidp. Fix that by putting it back.
    
    Reported-by: kbuild test robot <fengguang.wu@intel.com>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fe6c9b48ebc920ff21c10c50ab2729440c734254
Author: Jiri Kosina <jkosina@suse.cz>
Date:   Wed Jul 10 19:56:27 2013 +0200

    HID: fix data access in implement()
    
    commit 27ce405039bfe6d3f4143415c638f56a3df77dca upstream.
    
    implement() is setting bytes in LE data stream. In case the data is not
    aligned to 64bits, it reads past the allocated buffer. It doesn't really
    change any value there (it's properly bitmasked), but in case that this
    read past the boundary hits a page boundary, pagefault happens when
    accessing 64bits of 'x' in implement(), and kernel oopses.
    
    This happens much more often when numbered reports are in use, as the
    initial 8bit skip in the buffer makes the whole process work on values
    which are not aligned to 64bits.
    
    This problem dates back to attempts in 2005 and 2006 to make implement()
    and extract() as generic as possible, and even back then the problem
    was realized by Adam Kroperlin, but falsely assumed to be impossible
    to cause any harm:
    
      http://www.mail-archive.com/linux-usb-devel@lists.sourceforge.net/msg47690.html
    
    I have made several attempts at fixing it "on the spot" directly in
    implement(), but the results were horrible; the special casing for processing
    last 64bit chunk and switching to different math makes it unreadable mess.
    
    I therefore took a path to allocate a few bytes more which will never make
    it into final report, but are there as a cushion for all the 64bit math
    operations happening in implement() and extract().
    
    All callers of hid_output_report() are converted at the same time to allocate
    the buffer by newly introduced hid_alloc_report_buf() helper.
    
    Bruno noticed that the whole raw_size test can be dropped as well, as
    hid_alloc_report_buf() makes sure that the buffer is always of a proper
    size.
    
    Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
    Acked-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3cd1fa8b0cd14f25f0a6cfb60db3251f2d361095
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Tue Sep 24 15:27:45 2013 -0700

    cciss: fix info leak in cciss_ioctl32_passthru()
    
    commit 58f09e00ae095e46ef9edfcf3a5fd9ccdfad065e upstream.
    
    The arg64 struct has a hole after ->buf_size which isn't cleared.  Or if
    any of the calls to copy_from_user() fail then that would cause an
    information leak as well.
    
    This was assigned CVE-2013-2147.
    
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Acked-by: Mike Miller <mike.miller@hp.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 d19ac1faca409e8451c143941c42ad50afa16ae8
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Tue Sep 24 15:27:44 2013 -0700

    cpqarray: fix info leak in ida_locked_ioctl()
    
    commit 627aad1c01da6f881e7f98d71fd928ca0c316b1a upstream.
    
    The pciinfo struct has a two byte hole after ->dev_fn so stack
    information could be leaked to the user.
    
    This was assigned CVE-2013-2147.
    
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Acked-by: Mike Miller <mike.miller@hp.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 ba3460519e393d0f212403ae3535305f423d84ed
Author: J. Bruce Fields <bfields@redhat.com>
Date:   Thu Aug 15 16:55:26 2013 -0400

    nfsd4: fix leak of inode reference on delegation failure
    
    commit bf7bd3e98be5c74813bee6ad496139fb0a011b3b upstream.
    
    This fixes a regression from 68a3396178e6688ad7367202cdf0af8ed03c8727
    "nfsd4: shut down more of delegation earlier".
    
    After that commit, nfs4_set_delegation() failures result in
    nfs4_put_delegation being called, but nfs4_put_delegation doesn't free
    the nfs4_file that has already been set by alloc_init_deleg().
    
    This can result in an oops on later unmounting the exported filesystem.
    
    Note also delaying the fi_had_conflict check we're able to return a
    better error (hence give 4.1 clients a better idea why the delegation
    failed; though note CONFLICT isn't an exact match here, as that's
    supposed to indicate a current conflict, but all we know here is that
    there was one recently).
    
    Reported-by: Toralf Förster <toralf.foerster@gmx.de>
    Tested-by: Toralf Förster <toralf.foerster@gmx.de>
    Signed-off-by: J. Bruce Fields <bfields@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>