Linux 3.0.99

commit 5b31202a3604ef905d0433402aaf8aadf4660774
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Sat Oct 5 07:00:59 2013 -0700

    Linux 3.0.99

commit 2e4e7cb96933d2c9794125b038bd9ea9cba9bcfc
Author: Eric Dumazet <edumazet@google.com>
Date:   Tue Jun 12 15:24:40 2012 +0200

    splice: fix racy pipe->buffers uses

    commit 047fe3605235888f3ebcda0c728cb31937eadfe6 upstream.

    Dave Jones reported a kernel BUG at mm/slub.c:3474! triggered
    by splice_shrink_spd() called from vmsplice_to_pipe()

    commit 35f3d14dbbc5 (pipe: add support for shrinking and growing pipes)
    added capability to adjust pipe->buffers.

    Problem is some paths don't hold pipe mutex and assume pipe->buffers
    doesn't change for their duration.

    Fix this by adding nr_pages_max field in struct splice_pipe_desc, and
    use it in place of pipe->buffers where appropriate.

    splice_shrink_spd() loses its struct pipe_inode_info argument.

    Reported-by: Dave Jones <davej@redhat.com>
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Cc: Jens Axboe <axboe@kernel.dk>
    Cc: Alexander Viro <viro@zeniv.linux.org.uk>
    Cc: Tom Herbert <therbert@google.com>
    Cc: stable <stable@vger.kernel.org> # 2.6.35
    Tested-by: Dave Jones <davej@redhat.com>
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 96ec909de79e2cc422126fdeb427fe8d0ffb4b95
Author: Henrik Rydberg <rydberg@euromail.se>
Date:   Thu Jan 26 06:08:41 2012 -0500

    hwmon: (applesmc) Silence uninitialized warnings

    commit 0fc86eca1b338d06ec500b34ef7def79c32b602b upstream.

    Some error paths do not set a result, leading to the (false)
    assumption that the value may be used uninitialized. Set results for
    those paths as well.

    Signed-off-by: Henrik Rydberg <rydberg@euromail.se>
    Signed-off-by: Guenter Roeck <guenter.roeck@ericsson.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 94c7268325e30ecb4767b9c080e8cec9c92d6689
Author: Henrik Rydberg <rydberg@euromail.se>
Date:   Thu Sep 26 08:33:16 2013 +0200

    hwmon: (applesmc) Check key count before proceeding

    commit 5f4513864304672e6ea9eac60583eeac32e679f2 upstream.

    After reports from Chris and Josh Boyer of a rare crash in applesmc,
    Guenter pointed at the initialization problem fixed below. The patch
    has not been verified to fix the crash, but should be applied
    regardless.

    Reported-by: <jwboyer@fedoraproject.org>
    Suggested-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Henrik Rydberg <rydberg@euromail.se>
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d0d0e6c36f6d9fdf0df50c4d1877156b7bcff565
Author: Jani Nikula <jani.nikula@intel.com>
Date:   Fri Sep 20 16:42:15 2013 +0300

    drm/i915/dp: increase i2c-over-aux retry interval on AUX DEFER

    commit 8d16f258217f2f583af1fd57c5144aa4bbe73e48 upstream.

    There is no clear cut rules or specs for the retry interval, as there
    are many factors that affect overall response time. Increase the
    interval, and even more so on branch devices which may have limited i2c
    bit rates.

    Signed-off-by: Jani Nikula <jani.nikula@intel.com>
    Reference: https://bugs.freedesktop.org/show_bug.cgi?id=60263
    Tested-by: Nicolas Suzor <nic@suzor.com>
    Reviewed-by: Todd Previte <tprevite@gmail.com>
    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1f6014d357c7884e176c9d78c321ded23bdbd985
Author: Mikulas Patocka <mpatocka@redhat.com>
Date:   Wed Sep 18 19:40:42 2013 -0400

    dm-snapshot: fix performance degradation due to small hash size

    commit 60e356f381954d79088d0455e357db48cfdd6857 upstream.

    LVM2, since version 2.02.96, creates origin with zero size, then loads
    the snapshot driver and then loads the origin.  Consequently, the
    snapshot driver sees the origin size zero and sets the hash size to the
    lower bound 64.  Such small hash table causes performance degradation.

    This patch changes it so that the hash size is determined by the size of
    snapshot volume, not minimum of origin and snapshot size.  It doesn't
    make sense to set the snapshot size significantly larger than the origin
    size, so we do not need to take origin size into account when
    calculating the hash size.

    Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
    Signed-off-by: Mike Snitzer <snitzer@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 434b9ee66a512e9b91b9e1687b8183cd48a353fb
Author: Mikulas Patocka <mpatocka@redhat.com>
Date:   Wed Sep 18 19:14:22 2013 -0400

    dm snapshot: workaround for a false positive lockdep warning

    commit 5ea330a75bd86b2b2a01d7b85c516983238306fb upstream.

    The kernel reports a lockdep warning if a snapshot is invalidated because
    it runs out of space.

    The lockdep warning was triggered by commit 0976dfc1d0cd80a4e9dfaf87bd87
    ("workqueue: Catch more locking problems with flush_work()") in v3.5.

    The warning is false positive.  The real cause for the warning is that
    the lockdep engine treats different instances of md->lock as a single
    lock.

    This patch is a workaround - we use flush_workqueue instead of flush_work.
    This code path is not performance sensitive (it is called only on
    initialization or invalidation), thus it doesn't matter that we flush the
    whole workqueue.

    The real fix for the problem would be to teach the lockdep engine to treat
    different instances of md->lock as separate locks.

    Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
    Acked-by: Alasdair G Kergon <agk@redhat.com>
    Signed-off-by: Mike Snitzer <snitzer@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0c61d8a1d51e6f701ee17af5fa33bdeefaa02b75
Author: Kurt Garloff <kurt@garloff.de>
Date:   Tue Sep 24 14:13:48 2013 +0200

    usb/core/devio.c: Don't reject control message to endpoint with wrong direction bit

    commit 831abf76643555a99b80a3b54adfa7e4fa0a3259 upstream.

    Trying to read data from the Pegasus Technologies NoteTaker (0e20:0101)
    [1] with the Windows App (EasyNote) works natively but fails when
    Windows is running under KVM (and the USB device handed to KVM).

    The reason is a USB control message
     usb 4-2.2: control urb: bRequestType=22 bRequest=09 wValue=0200 wIndex=0001 wLength=0008
    This goes to endpoint address 0x01 (wIndex); however, endpoint address
    0x01 does not exist. There is an endpoint 0x81 though (same number,
    but other direction); the app may have meant that endpoint instead.

    The kernel thus rejects the IO and thus we see the failure.

    Apparently, Linux is more strict here than Windows ... we can't change
    the Win app easily, so that's a problem.

    It seems that the Win app/driver is buggy here and the driver does not
    behave fully according to the USB HID class spec that it claims to
    belong to.  The device seems to happily deal with that though (and
    seems to not really care about this value much).

    So the question is whether the Linux kernel should filter here.
    Rejecting has the risk that somewhat non-compliant userspace apps/
    drivers (most likely in a virtual machine) are prevented from working.
    Not rejecting has the risk of confusing an overly sensitive device with
    such a transfer. Given the fact that Windows does not filter it makes
    this risk rather small though.

    The patch makes the kernel more tolerant: If the endpoint address in
    wIndex does not exist, but an endpoint with toggled direction bit does,
    it will let the transfer through. (It does NOT change the message.)

    With attached patch, the app in Windows in KVM works.
     usb 4-2.2: check_ctrlrecip: process 13073 (qemu-kvm) requesting ep 01 but needs 81

    I suspect this will mostly affect apps in virtual environments; as on
    Linux the apps would have been adapted to the stricter handling of the
    kernel. I have done that for mine[2].

    [1] http://www.pegatech.com/
    [2] https://sourceforge.net/projects/notetakerpen/

    Signed-off-by: Kurt Garloff <kurt@garloff.de>
    Acked-by: Alan Stern <stern@rowland.harvard.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 314bb48ec028ae62cec4a1371cdd84b672d5a759
Author: Florian Wolter <wolly84@web.de>
Date:   Wed Aug 14 10:33:16 2013 +0200

    xhci: Fix race between ep halt and URB cancellation

    commit 526867c3ca0caa2e3e846cb993b0f961c33c2abb upstream.

    The halted state of a endpoint cannot be cleared over CLEAR_HALT from a
    user process, because the stopped_td variable was overwritten in the
    handle_stopped_endpoint() function. So the xhci_endpoint_reset() function will
    refuse the reset and communication with device can not run over this endpoint.
    https://bugzilla.kernel.org/show_bug.cgi?id=60699

    Signed-off-by: Florian Wolter <wolly84@web.de>
    Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
    Cc: Jonghwan Choi <jhbird.choi@samsung.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a86384dbc0bf86e10301eb8eaafb9d49c90e3183
Author: Mathias Nyman <mathias.nyman@linux.intel.com>
Date:   Thu Sep 5 11:01:20 2013 +0300

    xhci: Fix oops happening after address device timeout

    commit 284d20552461466b04d6bfeafeb1c47a8891b591 upstream.

    When a command times out, the command ring is first aborted,
    and then stopped. If the command ring is empty when it is stopped
    the stop event will point to next command which is not yet set.
    xHCI tries to handle this next event often causing an oops.

    Don't handle command completion events on stopped cmd ring if ring is
    empty.

    This patch should be backported to kernels as old as 3.7, that contain
    the commit b92cc66c047ff7cf587b318fe377061a353c120f "xHCI: add aborting
    command ring function"

    Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
    Reported-by: Giovanni <giovanni.nervi@yahoo.com>
    Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 79e1fc8a531ebe5da1078d765fadf6662edad612
Author: Malcolm Priestley <tvboxspy@gmail.com>
Date:   Sun Sep 22 19:48:54 2013 +0100

    staging: vt6656: [BUG] main_usb.c oops on device_close move flag earlier.

    commit e3eb270fab7734427dd8171a93e4946fe28674bc upstream.

    The vt6656 is prone to resetting on the usb bus.

    It seems there is a race condition and wpa supplicant is
    trying to open the device via iw_handlers before its actually
    closed at a stage that the buffers are being removed.

    The device is longer considered open when the
    buffers are being removed. So move ~DEVICE_FLAGS_OPENED
    flag to before freeing the device buffers.

    Signed-off-by: Malcolm Priestley <tvboxspy@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e8cf7dd6baa2ac1817ab4a8ef92f2b6791254870
Author: Josh Boyer <jwboyer@redhat.com>
Date:   Thu Apr 18 07:51:34 2013 -0700

    x86, efi: Don't map Boot Services on i386

    commit 700870119f49084da004ab588ea2b799689efaf7 upstream.

    Add patch to fix 32bit EFI service mapping (rhbz 726701)

    Multiple people are reporting hitting the following WARNING on i386,

      WARNING: at arch/x86/mm/ioremap.c:102 __ioremap_caller+0x3d3/0x440()
      Modules linked in:
      Pid: 0, comm: swapper Not tainted 3.9.0-rc7+ #95
      Call Trace:
       [<c102b6af>] warn_slowpath_common+0x5f/0x80
       [<c1023fb3>] ? __ioremap_caller+0x3d3/0x440
       [<c1023fb3>] ? __ioremap_caller+0x3d3/0x440
       [<c102b6ed>] warn_slowpath_null+0x1d/0x20
       [<c1023fb3>] __ioremap_caller+0x3d3/0x440
       [<c106007b>] ? get_usage_chars+0xfb/0x110
       [<c102d937>] ? vprintk_emit+0x147/0x480
       [<c1418593>] ? efi_enter_virtual_mode+0x1e4/0x3de
       [<c102406a>] ioremap_cache+0x1a/0x20
       [<c1418593>] ? efi_enter_virtual_mode+0x1e4/0x3de
       [<c1418593>] efi_enter_virtual_mode+0x1e4/0x3de
       [<c1407984>] start_kernel+0x286/0x2f4
       [<c1407535>] ? repair_env_string+0x51/0x51
       [<c1407362>] i386_start_kernel+0x12c/0x12f

    Due to the workaround described in commit 916f676f8 ("x86, efi: Retain
    boot service code until after switching to virtual mode") EFI Boot
    Service regions are mapped for a period during boot. Unfortunately, with
    the limited size of the i386 direct kernel map it's possible that some
    of the Boot Service regions will not be directly accessible, which
    causes them to be ioremap()'d, triggering the above warning as the
    regions are marked as E820_RAM in the e820 memmap.

    There are currently only two situations where we need to map EFI Boot
    Service regions,

      1. To workaround the firmware bug described in 916f676f8
      2. To access the ACPI BGRT image

    but since we haven't seen an i386 implementation that requires either,
    this simple fix should suffice for now.

    [ Added to changelog - Matt ]

    Reported-by: Bryan O'Donoghue <bryan.odonoghue.lkml@nexus-software.ie>
    Acked-by: Tom Zanussi <tom.zanussi@intel.com>
    Acked-by: Darren Hart <dvhart@linux.intel.com>
    Cc: Josh Triplett <josh@joshtriplett.org>
    Cc: Matthew Garrett <mjg59@srcf.ucam.org>
    Cc: H. Peter Anvin <hpa@zytor.com>
    Cc: Ingo Molnar <mingo@kernel.org>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Josh Boyer <jwboyer@redhat.com>
    Signed-off-by: Matt Fleming <matt.fleming@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 58f5bc0c124fb8338e91c8a4110ad64259632dd9
Author: Masoud Sharbiani <msharbiani@twitter.com>
Date:   Fri Sep 20 15:59:07 2013 -0700

    x86/reboot: Add quirk to make Dell C6100 use reboot=pci automatically

    commit 4f0acd31c31f03ba42494c8baf6c0465150e2621 upstream.

    Dell PowerEdge C6100 machines fail to completely reboot about 20% of the time.

    Signed-off-by: Masoud Sharbiani <msharbiani@twitter.com>
    Signed-off-by: Vinson Lee <vlee@twitter.com>
    Cc: Robin Holt <holt@sgi.com>
    Cc: Russell King <rmk+kernel@arm.linux.org.uk>
    Cc: Guan Xuetao <gxt@mprc.pku.edu.cn>
    Link: http://lkml.kernel.org/r/1379717947-18042-1-git-send-email-vlee@freedesktop.org
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Linux 3.0.100

commit dccc509a2c4ddf1568a4a6f3e8d4406270fb5307
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Sun Oct 13 15:07:28 2013 -0700

    Linux 3.0.100

commit fd819bdaa91422cf6b568bb76c40d0e5d8fbddaf
Author: Olaf Hering <olaf@aepfle.de>
Date:   Thu May 31 16:40:06 2012 +0200

    Tools: hv: verify origin of netlink connector message

    commit bcc2c9c3fff859e0eb019fe6fec26f9b8eba795c upstream.

    The SuSE security team suggested to use recvfrom instead of recv to be
    certain that the connector message is originated from kernel.

    CVE-2012-2669

    Signed-off-by: Olaf Hering <olaf@aepfle.de>
    Signed-off-by: Marcus Meissner <meissner@suse.de>
    Signed-off-by: Sebastian Krahmer <krahmer@suse.de>
    Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

commit 7b3c1a8576716d825c73ac1739b2b3f0d7226dcf
Author: Kees Cook <keescook@chromium.org>
Date:   Wed Mar 27 06:40:50 2013 +0000

    tg3: fix length overflow in VPD firmware parsing

    commit 715230a44310a8cf66fbfb5a46f9a62a9b2de424 upstream.

    Commit 184b89044fb6e2a74611dafa69b1dce0d98612c6 ("tg3: Use VPD fw version
    when present") introduced VPD parsing that contained a potential length
    overflow.

    Limit the hardware's reported firmware string length (max 255 bytes) to
    stay inside the driver's firmware string length (32 bytes). On overflow,
    truncate the formatted firmware string instead of potentially overwriting
    portions of the tg3 struct.

    http://cansecwest.com/slides/2013/PrivateCore%20CSW%202013.pdf

    -js: This fixes CVE-2013-1929.

    Signed-off-by: Kees Cook <keescook@chromium.org>
    Reported-by: Oded Horovitz <oded@privatecore.com>
    Reported-by: Brad Spengler <spender@grsecurity.net>
    Cc: stable@vger.kernel.org
    Cc: Matt Carlson <mcarlson@broadcom.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Acked-by: Jeff Mahoney <jeffm@suse.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6ac3a550f14a5b4a24417097cd6abcb8c79a0d5a
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 3609e1162ce723d3269924e95f2663d8bd72a537
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 a9f1434b8e47776e2b6d42a5556516209f5ba3ae
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 b8a3fdb8cfff87da926b868c3263a8a51c02af47
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 c724d4f0439a7af388de3929d80a933137168db5
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 8e0e2535ad3cdcd6e17d11ac52b5fb6487679e6c
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 d3f0cca5d5a167a7e154a7e4065f7e858539df4c
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 6a89ff9ebd1f81f6449b4c3c7a5e8861a0a6edf1
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 5391cb09f10c98af52458b4fd6e331a6465797f7
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 ee0ab40d6810a03cbd74715889dad558c5f9f02d
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 e6114d1d56548014e6f5323d8c71e9de61486786
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 ca0bd2082f83ccf6abbb2db2e4475bb81b415118
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 8107520ccf6a1f88d2139ba99e831ca8eeca8a77
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 ffc8f511cbea2ff61941c26a243c70136994094d
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 a821af3f7d73022d45550200241e6e671127ec81
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 46779b3c9f75cb80573a1ceb82b16b831bfb349c
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 4067bddb238b1f8d91add21ea38ae2cd32c1acac
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 4de33238bdb4664288000a1a5592fd1f3a1455b7
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 a7abc25bd4142a45bbcd90281a1869850a922876
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 67a8bceeb8f58b365104b0b35285205bff488727
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 dbe48e5b8c4f5f3096102d98cc53441178e67aa2
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 edd423cc3e80c43ca95c8a8ad292dc1f29d8a936
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 6838208d0662ff90eab0df3e36c481644083e888
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 daf468318a3a1548bf5cf8b1be493af104f5868f
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 a9092e91e01a1f1902c24d1d55cad8a472c282d0
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 8964c6487cf14fa5f00cedceab256b9aaab69acc
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 2a6a2791b1e6ebd7ad29f137a309471f92d71c55
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 20218d3d355cb32bdf1d737438958aa75f6ab21a
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 ae9f7cfdfc708c1c323e7e02e3ba067ddc96b671
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 956c741a9eef6a4e7a6755062d4afc1e686a1c5d
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 f6f88d6f41938e39971a5c0fce3aa8d26d3dd9de
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 63195262c5555dc90fde66d1be41ab102cf00adb
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 67ea0764ff204966d8f45b35dd26e939e2377b5a
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 dcad3ae646c253f445658d695f3e1f3ba0f2ac69
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 00dd675556f5c6a17bcba5f7e47c2552daeed84c
Author: Alex Williamson <alex.williamson@redhat.com>
Date:   Sat Jun 15 10:27:19 2013 -0600

    intel-iommu: Fix leaks in pagetable freeing

    commit 3269ee0bd6686baf86630300d528500ac5b516d7 upstream.

    At best the current code only seems to free the leaf pagetables and
    the root.  If you're unlucky enough to have a large gap (like any
    QEMU guest with more than 3G of memory), only the first chunk of leaf
    pagetables are freed (plus the root).  This is a massive memory leak.
    This patch re-writes the pagetable freeing function to use a
    recursive algorithm and manages to not only free all the pagetables,
    but does it without any apparent performance loss versus the current
    broken version.

    Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
    Cc: stable@vger.kernel.org
    Reviewed-by: Marcelo Tosatti <mtosatti@redhat.com>
    Signed-off-by: Joerg Roedel <joro@8bytes.org>
    Signed-off-by: Borislav Petkov <bp@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Linux 3.0.101

commit 5dba9ddd98cbc7ad319d687887981a0ea0062c75
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Tue Oct 22 08:58:59 2013 +0100

    Linux 3.0.101

commit 676d438e25b8b1fe251c1d474fab86187dbc6293
Author: Eric Dumazet <eric.dumazet@gmail.com>
Date:   Wed Nov 23 15:49:31 2011 -0500

    ipv6: tcp: fix panic in SYN processing

    commit c16a98ed91597b40b22b540c6517103497ef8e74 upstream.

    commit 72a3effaf633bc ([NET]: Size listen hash tables using backlog
    hint) added a bug allowing inet6_synq_hash() to return an out of bound
    array index, because of u16 overflow.

    Bug can happen if system admins set net.core.somaxconn &
    net.ipv4.tcp_max_syn_backlog sysctls to values greater than 65536

    Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Cc: Willy Tarreau <w@1wt.eu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f11d481f8f81dec26d3370bcf8f4c1f2d53ccefc
Author: wojciech kapuscinski <wojtask9@wp.pl>
Date:   Tue Oct 1 19:54:33 2013 -0400

    drm/radeon: fix hw contexts for SUMO2 asics

    commit 50b8f5aec04ebec7dbdf2adb17220b9148c99e63 upstream.

    They have 4 rather than 8.

    Fixes:
    https://bugs.freedesktop.org/show_bug.cgi?id=63599

    Signed-off-by: wojciech kapuscinski <wojtask9@wp.pl>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 826380d59f09185201d4327121f4919d2914a2cc
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Fri Aug 23 11:40:59 2013 +0300

    watchdog: ts72xx_wdt: locking bug in ioctl

    commit 8612ed0d97abcf1c016d34755b7cf2060de71963 upstream.

    Calling the WDIOC_GETSTATUS & WDIOC_GETBOOTSTATUS and twice will cause a
    interruptible deadlock.

    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Reviewed-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Wim Van Sebroeck <wim@iguana.be>
    Cc: Jonghwan Choi <jhbird.choi@samsung.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ac008905d50badfe8b695fa3f1eef20ac352e3e6
Author: Helge Deller <deller@gmx.de>
Date:   Tue Oct 1 21:54:46 2013 +0200

    parisc: fix interruption handler to respect pagefault_disable()

    commit 59b33f148cc08fb33cbe823fca1e34f7f023765e upstream.

    Running an "echo t > /proc/sysrq-trigger" crashes the parisc kernel.  The
    problem is, that in print_worker_info() we try to read the workqueue info via
    the probe_kernel_read() functions which use pagefault_disable() to avoid
    crashes like this:
        probe_kernel_read(&pwq, &worker->current_pwq, sizeof(pwq));
        probe_kernel_read(&wq, &pwq->wq, sizeof(wq));
        probe_kernel_read(name, wq->name, sizeof(name) - 1);

    The problem here is, that the first probe_kernel_read(&pwq) might return zero
    in pwq and as such the following probe_kernel_reads() try to access contents of
    the page zero which is read protected and generate a kernel segfault.

    With this patch we fix the interruption handler to call parisc_terminate()
    directly only if pagefault_disable() was not called (in which case
    preempt_count()==0).  Otherwise we hand over to the pagefault handler which
    will try to look up the faulting address in the fixup tables.

    Signed-off-by: Helge Deller <deller@gmx.de>
    Signed-off-by: John David Anglin  <dave.anglin@bell.net>
    Signed-off-by: Helge Deller <deller@gmx.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 546a50594e6241e2002cddbef7c350e177e08e52
Author: Dave Jones <davej@redhat.com>
Date:   Thu Oct 10 20:05:35 2013 -0400

    ext4: fix memory leak in xattr

    commit 6e4ea8e33b2057b85d75175dd89b93f5e26de3bc upstream.

    If we take the 2nd retry path in ext4_expand_extra_isize_ea, we
    potentionally return from the function without having freed these
    allocations.  If we don't do the return, we over-write the previous
    allocation pointers, so we leak either way.

    Spotted with Coverity.

    [ Fixed by tytso to set is and bs to NULL after freeing these
      pointers, in case in the retry loop we later end up triggering an
      error causing a jump to cleanup, at which point we could have a double
      free bug. -- Ted ]

    Signed-off-by: Dave Jones <davej@fedoraproject.org>
    Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
    Reviewed-by: Eric Sandeen <sandeen@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0ffc34c0d09a7d36ff84d1ac506a352a06ef5e4e
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Mon Sep 30 08:35:10 2013 -0700

    vfs: allow O_PATH file descriptors for fstatfs()

    commit 9d05746e7b16d8565dddbe3200faa1e669d23bbf upstream.

    Olga reported that file descriptors opened with O_PATH do not work with
    fstatfs(), found during further development of ksh93's thread support.

    There is no reason to not allow O_PATH file descriptors here (fstatfs is
    very much a path operation), so use "fdget_raw()".  See commit
    55815f70147d ("vfs: make O_PATH file descriptors usable for 'fstat()'")
    for a very similar issue reported for fstat() by the same team.

    Reported-and-tested-by: ольга крыжановская <olga.kryzhanovska@gmail.com>
    Acked-by: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fa759b5d100c8b0d2ec2b83fcac990f2c3ac13b7
Author: Theodore Ts'o <tytso@mit.edu>
Date:   Tue Sep 10 10:52:35 2013 -0400

    random: run random_int_secret_init() run after all late_initcalls

    commit 47d06e532e95b71c0db3839ebdef3fe8812fca2c upstream.

    The some platforms (e.g., ARM) initializes their clocks as
    late_initcalls for some unknown reason.  So make sure
    random_int_secret_init() is run after all of the late_initcalls are
    run.

    Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>