Script: Change to Google GCC 4.7
binfmt_elf.c: use get_random_int() to fix entropy depleting

Entropy is quickly depleted under normal operations like ls(1), cat(1),
etc...  between 2.6.30 to current mainline, for instance:

$ cat /proc/sys/kernel/random/entropy_avail
3428
$ cat /proc/sys/kernel/random/entropy_avail
2911
$cat /proc/sys/kernel/random/entropy_avail
2620

We observed this problem has been occurring since 2.6.30 with
fs/binfmt_elf.c: create_elf_tables()->get_random_bytes(), introduced by
f06295b44c296c8f ("ELF: implement AT_RANDOM for glibc PRNG seeding").

/*
 * Generate 16 random bytes for userspace PRNG seeding.
 */
get_random_bytes(k_rand_bytes, sizeof(k_rand_bytes));

The patch introduces a wrapper around get_random_int() which has lower
overhead than calling get_random_bytes() directly.

With this patch applied:
$ cat /proc/sys/kernel/random/entropy_avail
2731
$ cat /proc/sys/kernel/random/entropy_avail
2802
$ cat /proc/sys/kernel/random/entropy_avail
2878

Analyzed by John Sobecki.

Signed-off-by: Jie Liu <jeff.liu@oracle.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: Andreas Dilger <aedilger@gmail.com>
Cc: Alan Cox <alan@linux.intel.com>
Cc: Arnd Bergmann <arnn@arndb.de>
Cc: John Sobecki <john.sobecki@oracle.com>
Cc: James Morris <james.l.morris@oracle.com>
Cc: Jakub Jelinek <jakub@redhat.com>
Cc: Ted Ts'o <tytso@mit.edu>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Acked-by: Kees Cook <keescook@chromium.org>
Cc: Ulrich Drepper <drepper@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Linux 3.4.66

Squashed commit of the following:

commit dc3a8b0c212a563bf21c91ac9e776a0875861d3f
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Sun Oct 13 16:02:48 2013 -0700

    Linux 3.4.66

commit 016a3592cc34fa349235b5a8b48af5cece2cbfeb
Author: Theodore Ts'o <tytso@mit.edu>
Date:   Thu Dec 27 01:42:50 2012 -0500

    ext4: avoid hang when mounting non-journal filesystems with orphan list

    commit 0e9a9a1ad619e7e987815d20262d36a2f95717ca upstream.

    When trying to mount a file system which does not contain a journal,
    but which does have a orphan list containing an inode which needs to
    be truncated, the mount call with hang forever in
    ext4_orphan_cleanup() because ext4_orphan_del() will return
    immediately without removing the inode from the orphan list, leading
    to an uninterruptible loop in kernel code which will busy out one of
    the CPU's on the system.

    This can be trivially reproduced by trying to mount the file system
    found in tests/f_orphan_extents_inode/image.gz from the e2fsprogs
    source tree.  If a malicious user were to put this on a USB stick, and
    mount it on a Linux desktop which has automatic mounts enabled, this
    could be considered a potential denial of service attack.  (Not a big
    deal in practice, but professional paranoids worry about such things,
    and have even been known to allocate CVE numbers for such problems.)

    -js: This is a fix for CVE-2013-2015.

    Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
    Reviewed-by: Zheng Liu <wenqing.lz@taobao.com>
    Acked-by: Jan Kara <jack@suse.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 027a76bf3d56c7d7ef17aadfaec826a5d33f28f3
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 5df7085368ce132b9d93e5cff406df4684615419
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 b55ef2eddc365446b824aa9d457dd9daf4d4d4be
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 022a41db8aa1bc0b4ff4c013f889292324a1c465
Author: David Rientjes <rientjes@google.com>
Date:   Mon Apr 29 15:06:11 2013 -0700

    mm, show_mem: suppress page counts in non-blockable contexts

    commit 4b59e6c4730978679b414a8da61514a2518da512 upstream.

    On large systems with a lot of memory, walking all RAM to determine page
    types may take a half second or even more.

    In non-blockable contexts, the page allocator will emit a page allocation
    failure warning unless __GFP_NOWARN is specified.  In such contexts, irqs
    are typically disabled and such a lengthy delay may even result in NMI
    watchdog timeouts.

    To fix this, suppress the page walk in such contexts when printing the
    page allocation failure warning.

    Signed-off-by: David Rientjes <rientjes@google.com>
    Cc: Mel Gorman <mgorman@suse.de>
    Acked-by: Michal Hocko <mhocko@suse.cz>
    Cc: Dave Hansen <dave@linux.vnet.ibm.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Xishi Qiu <qiuxishi@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9712612a91e92824349ce9fece31dba6d2fbde70
Author: Ian Abbott <abbotti@mev.co.uk>
Date:   Thu Oct 10 10:53:46 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 d11fb4bbd90fd424834f51f8f85f6df51d76e5d9
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 cd8ccd534cf8782116049336a31b2476b9049ed2
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 218118c73db0a1b9aaece4c9ae697745218c3aa5
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 3047268fbd2a7db03f5b74177dd17ad11f1a99d8
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 5bbc247e1b0052553e278094efee5a8d40986d30
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 a2a88da3923e86a39755ae02737ba0af1ddae121
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 d08417dc4350604a5f8be7c144cb67a9f1bab806
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 03b88a25acc9ecfd0dfd5d1a9e95066e75e5fb9f
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 5d8bce850e56ccbfbf9d8c8d6db3e8c229c7b9bb
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 81cc233562f1b23db5bae2699f2f69e1f6dc9408
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 7df3eb5b0039aeec6e54b961dbebd61cb80a4bb3
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 cf818489ca512369e2c6ac57307284e171a1d588
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 cad9d82d9ba725ca6550b4fb9ed723331915a857
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 99363a2aa104ddb42ee45c520a73a0163e4910e2
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 aa33f22e3679f2dfc352a77089c11daa33db1e5b
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 ae63544e0e99b722cac42e7ba0b75df6f28f9a0e
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 77ddd59bbeb05825ee5126d128a31a0c6b461255
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 ff9c3c0a26b973735037843a7446d5fcc5e52ef0
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 e6629f15623d31e21775a1e5c28b8d5bd6559506
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 6b0dcab1d809ad6aab962c8df6ad4cd4e5986fc3
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 e504aeaec89c4b5c0e8617d59f937ae990297743
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 5b94af72dfa3c584463d8641c07130beb6763ce7
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 6b179d3a1422de6417691ff8de2e483563a13223
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 e723dd8bbde1ae36128fdeae766cd5447d747bf0
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 4f7a6b6fa0ffe6432ba37a82c7f29e583ffd3dc7
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 c8c242df7e23d4061acc25d38fe4790a1e942d4c
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 48ae8a45e24292fe3f6da9975314ca34ae334e02
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 d720ee298ff7ef1495e6f39cd751dd4bab1be85d
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 f72299da3e1a010a3d77fbed0b9ee6abd0a19911
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 832ae42a43dd7ea2a39d7cc0687363d0039da850
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 3c5bd142cbe6ca27b0e55451a4c37c703bc6ff66
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>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 12021622d44d200b0b7582bb7b9d31c2c36a9852
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 9dea496eb4b44b347fcf3667e98c70784b07fceb
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 a8e02b78193d24a73ccedfed64a0d8f5486b7c3c
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 a4942e9911a439060c744705178b766cf3ebe51e
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 835e0aace5b4d85b79e82b80da8da3ea14c4c419
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 8e307e20b3d7b4fc8af7a84762a7653dad486822
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 d45a3625d35eddca15327e99cd72eb5ed2c3ef31
Author: Claudiu Manoil <claudiu.manoil@freescale.com>
Date:   Sun Sep 23 22:39:08 2012 +0000

    gianfar: Change default HW Tx queue scheduling mode

    commit b98b8babd6e3370fadb7c6eaacb00eb2f6344a6c upstream.

    This is primarily to address transmission timeout occurrences, when
    multiple H/W Tx queues are being used concurrently. Because in
    the priority scheduling mode the controller does not service the
    Tx queues equally (but in ascending index order), Tx timeouts are
    being triggered rightaway for a basic test with multiple simultaneous
    connections like:
    iperf -c <server_ip> -n 100M -P 8

    resulting in kernel trace:
    NETDEV WATCHDOG: eth1 (fsl-gianfar): transmit queue <X> timed out
    ------------[ cut here ]------------
    WARNING: at net/sched/sch_generic.c:255
    ...
    and controller reset during intense traffic, and possibly further
    complications.

    This patch changes the default H/W Tx scheduling setting (TXSCHED)
    for multi-queue devices, from priority scheduling mode to a weighted
    round robin mode with equal weights for all H/W Tx queues, and
    addresses the issue above.

    Signed-off-by: Claudiu Manoil <claudiu.manoil@freescale.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f845e0c5753347df5331b6251da8ea7ddbf59ae9
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 dd7c44612de48b6bbd2f81d4b6e83a9801a902a6
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>
Linux 3.4.67

Conflicts:
	Makefile