Linux 3.0.89

commit 83a5a29e61bc572110c0c4b8fc4e8d7838b8db53
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Sun Aug 4 15:45:13 2013 +0800

    Linux 3.0.89

commit 71ee5d037bc9d215e06248642ea28b559b9440fa
Author: Ren Bigcren <bigcren.ren@sonymobile.com>
Date:   Tue Jul 2 13:34:30 2013 +0200

    USB: storage: Add MicroVault Flash Drive to unusual_devs

    commit e7a6121f4929c17215f0cdca3726f4bf3e4e9529 upstream.

    The device report an error capacity when read_capacity_16().
    Using read_capacity_10() can get the correct capacity.

    Signed-off-by: Ren Bigcren <bigcren.ren@sonymobile.com>
    Cc: Matthew Dharm <mdharm-usb@one-eyed-alien.net>
    Signed-off-by: Oskar Andero <oskar.andero@sonymobile.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a5e9f97a04d86f9b4136d1be87d822df8e615f13
Author: Wanpeng Li <liwanp@linux.vnet.ibm.com>
Date:   Wed Jul 3 15:02:40 2013 -0700

    mm/memory-hotplug: fix lowmem count overflow when offline pages

    commit cea27eb2a202959783f81254c48c250ddd80e129 upstream.

    The logic for the memory-remove code fails to correctly account the
    Total High Memory when a memory block which contains High Memory is
    offlined as shown in the example below.  The following patch fixes it.

    Before logic memory remove:

    MemTotal:        7603740 kB
    MemFree:         6329612 kB
    Buffers:           94352 kB
    Cached:           872008 kB
    SwapCached:            0 kB
    Active:           626932 kB
    Inactive:         519216 kB
    Active(anon):     180776 kB
    Inactive(anon):   222944 kB
    Active(file):     446156 kB
    Inactive(file):   296272 kB
    Unevictable:           0 kB
    Mlocked:               0 kB
    HighTotal:       7294672 kB
    HighFree:        5704696 kB
    LowTotal:         309068 kB
    LowFree:          624916 kB

    After logic memory remove:

    MemTotal:        7079452 kB
    MemFree:         5805976 kB
    Buffers:           94372 kB
    Cached:           872000 kB
    SwapCached:            0 kB
    Active:           626936 kB
    Inactive:         519236 kB
    Active(anon):     180780 kB
    Inactive(anon):   222944 kB
    Active(file):     446156 kB
    Inactive(file):   296292 kB
    Unevictable:           0 kB
    Mlocked:               0 kB
    HighTotal:       7294672 kB
    HighFree:        5181024 kB
    LowTotal:       4294752076 kB
    LowFree:          624952 kB

    [mhocko@suse.cz: fix CONFIG_HIGHMEM=n build]
    Signed-off-by: Wanpeng Li <liwanp@linux.vnet.ibm.com>
    Reviewed-by: Michal Hocko <mhocko@suse.cz>
    Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
    Cc: David Rientjes <rientjes@google.com>
    Cc: <stable@vger.kernel.org>    [2.6.24+]
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Zhouping Liu <zliu@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 27fe2c366213592a862d8f5160c606eded3947c7
Author: Michael S. Tsirkin <mst@redhat.com>
Date:   Sun Aug 4 15:43:40 2013 +0800

    virtio_net: fix race in RX VQ processing

    commit cbdadbbf0c790f79350a8f36029208944c5487d0 upstream

    virtio net called virtqueue_enable_cq on RX path after napi_complete, so
    with NAPI_STATE_SCHED clear - outside the implicit napi lock.
    This violates the requirement to synchronize virtqueue_enable_cq wrt
    virtqueue_add_buf.  In particular, used event can move backwards,
    causing us to lose interrupts.
    In a debug build, this can trigger panic within START_USE.

    Jason Wang reports that he can trigger the races artificially,
    by adding udelay() in virtqueue_enable_cb() after virtio_mb().

    However, we must call napi_complete to clear NAPI_STATE_SCHED before
    polling the virtqueue for used buffers, otherwise napi_schedule_prep in
    a callback will fail, causing us to lose RX events.

    To fix, call virtqueue_enable_cb_prepare with NAPI_STATE_SCHED
    set (under napi lock), later call virtqueue_poll with
    NAPI_STATE_SCHED clear (outside the lock).

    Reported-by: Jason Wang <jasowang@redhat.com>
    Tested-by: Jason Wang <jasowang@redhat.com>
    Acked-by: Jason Wang <jasowang@redhat.com>
    Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    [wg: Backported to 3.2]
    Signed-off-by: Wolfram Gloger <wmglo@dent.med.uni-muenchen.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8ff3d73133cb5a8a3514cc184152c553637e74a8
Author: Michael S. Tsirkin <mst@redhat.com>
Date:   Sun Aug 4 15:43:40 2013 +0800

    virtio: support unlocked queue poll

    commit cc229884d3f77ec3b1240e467e0236c3e0647c0c upstream.

    This adds a way to check ring empty state after enable_cb outside any
    locks. Will be used by virtio_net.

    Note: there's room for more optimization: caller is likely to have a
    memory barrier already, which means we might be able to get rid of a
    barrier here.  Deferring this optimization until we do some
    benchmarking.

    Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    [wg: Backported to 3.2]
    Signed-off-by: Wolfram Gloger <wmglo@dent.med.uni-muenchen.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0b7b1cfac3b60be07d6b2ae8fe4db495de5883a6
Author: David Vrabel <david.vrabel@citrix.com>
Date:   Fri Jul 19 15:51:58 2013 +0100

    xen/evtchn: avoid a deadlock when unbinding an event channel

    commit 179fbd5a45f0d4034cc6fd37b8d367a3b79663c4 upstream.

    Unbinding an event channel (either with the ioctl or when the evtchn
    device is closed) may deadlock because disable_irq() is called with
    port_user_lock held which is also locked by the interrupt handler.

    Think of the IOCTL_EVTCHN_UNBIND is being serviced, the routine has
    just taken the lock, and an interrupt happens. The evtchn_interrupt
    is invoked, tries to take the lock and spins forever.

    A quick glance at the code shows that the spinlock is a local IRQ
    variant. Unfortunately that does not help as "disable_irq() waits for
    the interrupt handler on all CPUs to stop running.  If the irq occurs
    on another VCPU, it tries to take port_user_lock and can't because
    the unbind ioctl is holding it." (from David). Hence we cannot
    depend on the said spinlock to protect us. We could make it a system
    wide IRQ disable spinlock but there is a better way.

    We can piggyback on the fact that the existence of the spinlock is
    to make get_port_user() checks be up-to-date. And we can alter those
    checks to not depend on the spin lock (as it's protected by u->bind_mutex
    in the ioctl) and can remove the unnecessary locking (this is
    IOCTL_EVTCHN_UNBIND) path.

    In the interrupt handler we cannot use the mutex, but we do not
    need it.

    "The unbind disables the irq before making the port user stale, so when
    you clear it you are guaranteed that the interrupt handler that might
    use that port cannot be running." (from David).

    Hence this patch removes the spinlock usage on the teardown path
    and piggybacks on disable_irq happening before we muck with the
    get_port_user() data. This ensures that the interrupt handler will
    never run on stale data.

    Signed-off-by: David Vrabel <david.vrabel@citrix.com>
    Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
    [v1: Expanded the commit description a bit]
    Signed-off-by: Jonghwan Choi <jhbird.choi@samsung.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit dbb1314f28d3a5b561b9d3b7598ccf204f88472d
Author: Al Viro <viro@zeniv.linux.org.uk>
Date:   Sat Jul 20 03:13:55 2013 +0400

    livelock avoidance in sget()

    commit acfec9a5a892f98461f52ed5770de99a3e571ae2 upstream.

    Eric Sandeen has found a nasty livelock in sget() - take a mount(2) about
    to fail.  The superblock is on ->fs_supers, ->s_umount is held exclusive,
    ->s_active is 1.  Along comes two more processes, trying to mount the same
    thing; sget() in each is picking that superblock, bumping ->s_count and
    trying to grab ->s_umount.  ->s_active is 3 now.  Original mount(2)
    finally gets to deactivate_locked_super() on failure; ->s_active is 2,
    superblock is still ->fs_supers because shutdown will *not* happen until
    ->s_active hits 0.  ->s_umount is dropped and now we have two processes
    chasing each other:
    s_active = 2, A acquired ->s_umount, B blocked
    A sees that the damn thing is stillborn, does deactivate_locked_super()
    s_active = 1, A drops ->s_umount, B gets it
    A restarts the search and finds the same superblock.  And bumps it ->s_active.
    s_active = 2, B holds ->s_umount, A blocked on trying to get it
    ... and we are in the earlier situation with A and B switched places.

    The root cause, of course, is that ->s_active should not grow until we'd
    got MS_BORN.  Then failing ->mount() will have deactivate_locked_super()
    shut the damn thing down.  Fortunately, it's easy to do - the key point
    is that grab_super() is called only for superblocks currently on ->fs_supers,
    so it can bump ->s_count and grab ->s_umount first, then check MS_BORN and
    bump ->s_active; we must never increment ->s_count for superblocks past
    ->kill_sb(), but grab_super() is never called for those.

    The bug is pretty old; we would've caught it by now, if not for accidental
    exclusion between sget() for block filesystems; the things like cgroup or
    e.g. mtd-based filesystems don't have anything of that sort, so they get
    bitten.  The right way to deal with that is obviously to fix sget()...

    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2fcaa774ab8375516255249648af76ce16663b6a
Author: Rick Farina (Zero_Chaos) <zerochaos@gentoo.org>
Date:   Mon Jul 29 15:17:59 2013 -0400

    USB: serial: ftdi_sio: add more RT Systems ftdi devices

    commit fed1f1ed90bce42ea010e2904cbc04e7b8304940 upstream.

    RT Systems makes many usb serial cables based on the ftdi_sio driver for
    programming various amateur radios.  This patch is a full listing of
    their current product offerings and should allow these cables to all
    be recognized.

    Signed-off-by: Rick Farina (Zero_Chaos) <zerochaos@gentoo.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6ec322493ae29932c23a20ad015921fe133b9ff8
Author: Alex Deucher <alexander.deucher@amd.com>
Date:   Tue Jul 30 00:22:53 2013 -0400

    drm/radeon/atom: initialize more atom interpretor elements to 0

    commit 42a21826dc54583cdb79cc8477732e911ac9c376 upstream.

    The ProcessAuxChannel table on some rv635 boards assumes
    the divmul members are initialized to 0 otherwise we get
    an invalid fb offset since it has a bad mask set when
    setting the fb base.  While here initialize all the
    atom interpretor elements to 0.

    Fixes:
    https://bugzilla.kernel.org/show_bug.cgi?id=60639

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

commit e0d2313f66fea2e8a5286d5ccebb057810ad4e9b
Author: Alex Deucher <alexander.deucher@amd.com>
Date:   Fri Jul 19 17:44:43 2013 -0400

    drm/radeon: improve dac adjust heuristics for legacy pdac

    commit 03ed8cf9b28d886c64c7e705c7bb1a365fd8fb95 upstream.

    Hopefully avoid more quirks in the future due to bogus
    vbios dac data.

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

commit 720c2af54ebce30c402581384e2287e66b4dee8c
Author: Mark Kettenis <kettenis@openbsd.org>
Date:   Sun Jul 21 16:44:09 2013 -0400

    drm/radeon: fix combios tables on older cards

    commit cef1d00cd56f600121ad121875655ad410a001b8 upstream.

    Noticed that my old Radeon 7500 hung after printing

       drm: GPU not posted. posting now...

    when it wasn't selected as the primary card the BIOS.  Some digging
    revealed that it was hanging in combios_parse_mmio_table() while
    parsing the ASIC INIT 3 table.  Looking at the BIOS ROM for the card,
    it becomes obvious that there is no ASIC INIT 3 table in the BIOS.
    The code is just processing random garbage.  No surprise it hangs!

    Why do I say that there is no ASIC INIT 3 table is the BIOS?  This
    table is found through the MISC INFO table.  The MISC INFO table can
    be found at offset 0x5e in the COMBIOS header.  But the header is
    smaller than that.  The COMBIOS header starts at offset 0x126.  The
    standard PCI Data Structure (the bit that starts with 'PCIR') lives at
    offset 0x180.  That means that the COMBIOS header can not be larger
    than 0x5a bytes and therefore cannot contain a MISC INFO table.

    I looked at a dozen or so BIOS images, some my own, some downloaded from:

        <http://www.techpowerup.com/vgabios/index.php?manufacturer=ATI&page=1>

    It is fairly obvious that the size of the COMBIOS header can be found
    at offset 0x6 of the header.  Not sure if it is a 16-bit number or
    just an 8-bit number, but that doesn't really matter since the tables
    seems to be always smaller than 256 bytes.

    So I think combios_get_table_offset() should check if the requested
    table is present.  This can be done by checking the offset against the
    size of the header.  See the diff below.  The diff is against the WIP
    OpenBSD codebase that roughly corresponds to Linux 3.8.13 at this
    point.  But I don't think this bit of the code changed much since
    then.

    For what it is worth:

    Signed-off-by: Mark Kettenis <kettenis@openbsd.org>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8673e4e2f9b08fd036cf9a088a9fe16d681b6ab7
Author: Toshi Kani <toshi.kani@hp.com>
Date:   Wed Jul 10 10:47:13 2013 -0600

    ACPI / memhotplug: Fix a stale pointer in error path

    commit d19f503e22316a84c39bc19445e0e4fdd49b3532 upstream.

    device->driver_data needs to be cleared when releasing its data,
    mem_device, in an error path of acpi_memory_device_add().

    The function evaluates the _CRS of memory device objects, and fails
    when it gets an unexpected resource or cannot allocate memory.  A
    kernel crash or data corruption may occur when the kernel accesses
    the stale pointer.

    Signed-off-by: Toshi Kani <toshi.kani@hp.com>
    Reviewed-by: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2a20b17ba9f0636e757ecbdbd79d460ff1fde0d0
Author: Anton Blanchard <anton@samba.org>
Date:   Mon Jul 15 14:04:50 2013 +1000

    powerpc/modules: Module CRC relocation fix causes perf issues

    commit 0e0ed6406e61434d3f38fb58aa8464ec4722b77e upstream.

    Module CRCs are implemented as absolute symbols that get resolved by
    a linker script. We build an intermediate .o that contains an
    unresolved symbol for each CRC. genksysms parses this .o, calculates
    the CRCs and writes a linker script that "resolves" the symbols to
    the calculated CRC.

    Unfortunately the ppc64 relocatable kernel sees these CRCs as symbols
    that need relocating and relocates them at boot. Commit d4703aef
    (module: handle ppc64 relocating kcrctabs when CONFIG_RELOCATABLE=y)
    added a hook to reverse the bogus relocations. Part of this patch
    created a symbol at 0x0:

    # head -2 /proc/kallsyms
    0000000000000000 T reloc_start
    c000000000000000 T .__start

    This reloc_start symbol is causing lots of confusion to perf. It
    thinks reloc_start is a massive function that stretches from 0x0 to
    0xc000000000000000 and we get various cryptic errors out of perf,
    including:

    problem incrementing symbol count, skipping event

    This patch removes the  reloc_start linker script label and instead
    defines it as PHYSICAL_START. We also need to wrap it with
    CONFIG_PPC64 because the ppc32 kernel can set a non zero
    PHYSICAL_START at compile time and we wouldn't want to subtract
    it from the CRCs in that case.

    Signed-off-by: Anton Blanchard <anton@samba.org>
    Acked-by: Rusty Russell <rusty@rustcorp.com.au>
    Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d8ab3c8b69ba3922b06e077c39ffc4dbcbeabe64
Author: Tejun Heo <tj@kernel.org>
Date:   Mon Jul 22 16:53:36 2013 -0400

    libata: make it clear that sata_inic162x is experimental

    commit bb9696192826a7d9279caf872e95b41bc26c7eff upstream.

    sata_inic162x never reached a state where it's reliable enough for
    production use and data corruption is a relatively common occurrence.
    Make the driver generate warning about the issues and mark the Kconfig
    option as experimental.

    If the situation doesn't improve, we'd be better off making it depend
    on CONFIG_BROKEN.  Let's wait for several cycles and see if the kernel
    message draws any attention.

    Signed-off-by: Tejun Heo <tj@kernel.org>
    Reported-by: Martin Braure de Calignon <braurede@free.fr>
    Reported-by: Ben Hutchings <ben@decadent.org.uk>
    Reported-by: risc4all@yahoo.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit dbe048b2eebb75f9b5c17b0d948fe5a8ec396cc5
Author: Ian Abbott <abbotti@mev.co.uk>
Date:   Mon Jul 8 13:36:19 2013 +0100

    staging: comedi: COMEDI_CANCEL ioctl should wake up read/write

    commit 69acbaac303e8cb948801a9ddd0ac24e86cc4a1b upstream.

    Comedi devices can do blocking read() or write() (or poll()) if an
    asynchronous command has been set up, blocking for data (for read()) or
    buffer space (for write()).  Various events associated with the
    asynchronous command will wake up the blocked reader or writer (or
    poller).  It is also possible to force the asynchronous command to
    terminate by issuing a `COMEDI_CANCEL` ioctl.  That shuts down the
    asynchronous command, but does not currently wake up the blocked reader
    or writer (or poller).  If the blocked task could be woken up, it would
    see that the command is no longer active and return.  The caller of the
    `COMEDI_CANCEL` ioctl could attempt to wake up the blocked task by
    sending a signal, but that's a nasty workaround.

    Change `do_cancel_ioctl()` to wake up the wait queue after it returns
    from `do_cancel()`.  `do_cancel()` can propagate an error return value
    from the low-level comedi driver's cancel routine, but it always shuts
    the command down regardless, so `do_cancel_ioctl()` can wake up he wait
    queue regardless of the return value from `do_cancel()`.

    Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 94c3bbaf01202674a406d075429513e321a5b236
Author: William Gulland <wgulland@google.com>
Date:   Thu Jun 27 16:10:20 2013 -0700

    usb: Clear both buffers when clearing a control transfer TT buffer.

    commit 2c7b871b9102c497ba8f972aa5d38532f05b654d upstream.

    Control transfers have both IN and OUT (or SETUP) packets, so when
    clearing TT buffers for a control transfer it's necessary to send
    two HUB_CLEAR_TT_BUFFER requests to the hub.

    Signed-off-by: William Gulland <wgulland@google.com>
    Acked-by: Alan Stern <stern@rowland.harvard.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 54b404671f9535d0bd6bf388686cc5f8ee245c36
Author: Jóhann B. Guðmundsson <johannbg@fedoraproject.org>
Date:   Thu Jul 4 21:47:52 2013 +0000

    USB: misc: Add Manhattan Hi-Speed USB DVI Converter to sisusbvga

    commit 58fc90db8261b571c026bb8bf23aad48a7233118 upstream.

    Signed-off-by: Jóhann B. Guðmundsson <johannbg@fedoraproject.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit bd8f7d2c00c7ac86c9aa50fc73427009993cec03
Author: Johan Hovold <jhovold@gmail.com>
Date:   Fri Jun 28 12:24:26 2013 +0200

    USB: ti_usb_3410_5052: fix dynamic-id matching

    commit 1fad56424f5ad3ce4973505a357212b2e2282b3f upstream.

    The driver failed to take the dynamic ids into account when determining
    the device type and therefore all devices were detected as 2-port
    devices when using the dynamic-id interface.

    Match on the usb-serial-driver field instead of doing redundant id-table
    searches.

    Reported-by: Anders Hammarquist <iko@iko.pp.se>
    Signed-off-by: Johan Hovold <jhovold@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 11e8ea9e069e6012a634017ad534c25030b1104a
Author: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Date:   Wed Jul 24 10:27:13 2013 -0700

    xhci: Avoid NULL pointer deref when host dies.

    commit 203a86613fb3bf2767335659513fa98563a3eb71 upstream.

    When the host controller fails to respond to an Enable Slot command, and
    the host fails to respond to the register write to abort the command
    ring, the xHCI driver will assume the host is dead, and call
    usb_hc_died().

    The USB device's slot_id is still set to zero, and the pointer stored at
    xhci->devs[0] will always be NULL.  The call to xhci_check_args in
    xhci_free_dev should have caught the NULL virt_dev pointer.

    However, xhci_free_dev is designed to free the xhci_virt_device
    structures, even if the host is dead, so that we don't leak kernel
    memory.  xhci_free_dev checks the return value from the generic
    xhci_check_args function.  If the return value is -ENODEV, it carries on
    trying to free the virtual device.

    The issue is that xhci_check_args looks at the host controller state
    before it looks at the xhci_virt_device pointer.  It will return -ENIVAL
    because the host is dead, and xhci_free_dev will ignore the return
    value, and happily dereference the NULL xhci_virt_device pointer.

    The fix is to make sure that xhci_check_args checks the xhci_virt_device
    pointer before it checks the host state.

    See https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1203453 for
    further details.  This patch doesn't solve the underlying issue, but
    will ensure we don't see any more NULL pointer dereferences because of
    the issue.

    This patch should be backported to kernels as old as 3.1, that
    contain the commit 7bd89b4017f46a9b92853940fd9771319acb578a "xhci: Don't
    submit commands or URBs to halted hosts."

    Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
    Reported-by: Vincent Thiele <vincentthiele@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 67a6ad3b0ca2311d4209338eec23c14331da5d36
Author: Oleksij Rempel <linux@rempel-privat.de>
Date:   Sun Jul 21 15:36:19 2013 +0200

    xhci: fix null pointer dereference on ring_doorbell_for_active_rings

    commit d66eaf9f89502971fddcb0de550b01fa6f409d83 upstream.

    in some cases where device is attched to xhci port and do not responding,
    for example ath9k_htc with stalled firmware, kernel will
    crash on ring_doorbell_for_active_rings.
    This patch check if pointer exist before it is used.

    This patch should be backported to kernels as old as 2.6.35, that
    contain the commit e9df17eb1408cfafa3d1844bfc7f22c7237b31b8 "USB: xhci:
    Correct assumptions about number of rings per endpoint"

    Signed-off-by: Oleksij Rempel <linux@rempel-privat.de>
    Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 197d436deff13594bcc97740147c5ed9e7fe7ddb
Author: zhangwei(Jovi) <jovi.zhangwei@huawei.com>
Date:   Mon Jul 29 09:33:58 2013 +0800

    tracing: Fix irqs-off tag display in syscall tracing

    commit 11034ae9c20f4057a6127fc965906417978e69b2 upstream

    Initialization of variable irq_flags and pc was missed when backport
    11034ae9c to linux-3.0.y and linux-3.4.y, my fault.

    Signed-off-by: zhangwei(Jovi) <jovi.zhangwei@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 95a9769291fda8caa8a98c0eabff769509a6e1ba
Author: Saurav Kashyap <saurav.kashyap@qlogic.com>
Date:   Fri Jul 12 14:47:51 2013 -0400

    SCSI: qla2xxx: Properly set the tagging for commands.

    commit c3ccb1d7cf4c4549151876dd37c0944a682fd9e1 upstream.

    This fixes a regression where Xyratex controllers and disks were lost by the
    driver:

    https://bugzilla.kernel.org/show_bug.cgi?id=59601

    Reported-by: Jack Hill <jackhill@jackhill.us>
    Signed-off-by: Saurav Kashyap <saurav.kashyap@qlogic.com>
    Signed-off-by: Giridhar Malavali <giridhar.malavali@qlogic.com>
    Signed-off-by: James Bottomley <JBottomley@Parallels.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit eeba2290fa3d43e5d424964ef54836227c9c21c5
Author: Ewan D. Milne <emilne@redhat.com>
Date:   Fri Nov 2 09:38:34 2012 -0400

    SCSI: sd: fix crash when UA received on DIF enabled device

    commit 085b513f97d8d799d28491239be4b451bcd8c2c5 upstream.

    sd_prep_fn will allocate a larger CDB for the command via mempool_alloc
    for devices using DIF type 2 protection.  This CDB was being freed
    in sd_done, which results in a kernel crash if the command is retried
    due to a UNIT ATTENTION.  This change moves the code to free the larger
    CDB into sd_unprep_fn instead, which is invoked after the request is
    complete.

    It is no longer necessary to call scsi_print_command separately for
    this case as the ->cmnd will no longer be NULL in the normal code path.

    Also removed conditional test for DIF type 2 when freeing the larger
    CDB because the protection_type could have been changed via sysfs while
    the command was executing.

    Signed-off-by: Ewan D. Milne <emilne@redhat.com>
    Acked-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: James Bottomley <JBottomley@Parallels.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 45cbbc0dd83c048d2c231bfac9cb60ef3d8f0ea6
Author: Chih-Chung Chang <chihchung@chromium.org>
Date:   Mon Jul 15 09:38:46 2013 -0700

    ASoC: max98088 - fix element type of the register cache.

    commit cb6f66a2d278e57a6c9d8fb59bd9ebd8ab3965c2 upstream.

    The registers of max98088 are 8 bits, not 16 bits. This bug causes the
    contents of registers to be overwritten with bad values when the codec
    is suspended and then resumed.

    Signed-off-by: Chih-Chung Chang <chihchung@chromium.org>
    Signed-off-by: Dylan Reid <dgreid@chromium.org>
    Signed-off-by: Mark Brown <broonie@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 738ae485e65ea6304466ef22c7eb6981c5174d60
Author: Ren Bigcren <bigcren.ren@sonymobile.com>
Date:   Tue Jul 2 13:34:30 2013 +0200

    USB: storage: Add MicroVault Flash Drive to unusual_devs

    commit e7a6121f4929c17215f0cdca3726f4bf3e4e9529 upstream.

    The device report an error capacity when read_capacity_16().
    Using read_capacity_10() can get the correct capacity.

    Signed-off-by: Ren Bigcren <bigcren.ren@sonymobile.com>
    Cc: Matthew Dharm <mdharm-usb@one-eyed-alien.net>
    Signed-off-by: Oskar Andero <oskar.andero@sonymobile.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Merge branch 'cm-10.1-wip' of git://github.com/Mustaavalkosta/htc7x30-3.0 into rs-dev
serial/mxs-auart: fix race condition in interrupt handler

commit d970d7fe65adff5efe75b4a73c4ffc9be57089f7 upstream.

The handler needs to ack the pending events before actually handling them.
Otherwise a new event might come in after it it considered non-pending or
handled and is acked then without being handled. So this event is only
noticed when the next interrupt happens.

Without this patch an i.MX28 based machine running an rt-patched kernel
regularly hangs during boot.

Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
serial/mxs-auart: increase time to wait for transmitter to become idle

commit 079a036f4283e2b0e5c26080b8c5112bc0cc1831 upstream.

Without this patch the driver waits ~1 ms for the UART to become idle. At
115200n8 this time is (theoretically) enough to transfer 11.5 characters
(= 115200 bits/s / (10 Bits/char) * 1ms). As the mxs-auart has a fifo size
of 16 characters the clock is gated too early. The problem is worse for
lower baud rates.

This only happens to really shut down the transmitter in the middle of a
transfer if /dev/ttyAPPx isn't opened in userspace (e.g. by a getty) but
was at least once (because the bootloader doesn't disable the transmitter).

So increase the timeout to 20 ms which should be enough for 9600n8, too.
Moreover skip gating the clock if the timeout is elapsed.

Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
ath9k_htc: do some initial hardware configuration

commit dc2a87f519a4d8cb376ab54f22b6b98a943b51ce upstream.

Currently we configure harwdare and clock, only after
interface start. In this case, if we reload module or
reboot PC without configuring adapter, firmware will freeze.
There is no software way to reset adpter.

This patch add initial configuration and set it in
disabled state, to avoid this freeze. Behaviour of this patch
should be similar to: ifconfig wlan0 up; ifconfig wlan0 down.

Bug: https://github.com/qca/open-ath9k-htc-firmware/issues/1
Tested-by: Bo Shi <cnshibo@gmail.com>
Signed-off-by: Oleksij Rempel <linux@rempel-privat.de>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
nl80211: fix mgmt tx status and testmode reporting for netns

commit a0ec570f4f69c4cb700d743a915096c2c8f56a99 upstream.

These two events were sent to the default network
namespace.

This caused AP mode in a non-default netns to not
work correctly. Mgmt tx status was multicasted to
a different (default) netns instead of the one the
AP was in.

Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
mac80211: fix duplicate retransmission detection

commit 6b0f32745dcfba01d7be33acd1b40306c7a914c6 upstream.

The duplicate retransmission detection code in mac80211
erroneously attempts to do the check for every frame,
even frames that don't have a sequence control field or
that don't use it (QoS-Null frames.)

This is problematic because it causes the code to access
data beyond the end of the SKB and depending on the data
there will drop packets erroneously.

Correct the code to not do duplicate detection for such
frames.

I found this error while testing AP powersave, it lead
to retransmitted PS-Poll frames being dropped entirely
as the data beyond the end of the SKB was always zero.

Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
rt2x00: fix stop queue

commit e2288b66fe7ff0288382b2af671b4da558b44472 upstream.

Since we clear QUEUE_STARTED in rt2x00queue_stop_queue(), following
call to rt2x00queue_pause_queue() reduce to noop, i.e we do not
stop queue in mac80211.

To fix that introduce rt2x00queue_pause_queue_nocheck() function,
which will stop queue in mac80211 directly.

Note that rt2x00_start_queue() explicitly set QUEUE_PAUSED bit.

Note also that reordering operations i.e. first call to
rt2x00queue_pause_queue() and then clear QUEUE_STARTED bit, will race
with rt2x00queue_unpause_queue(), so calling ieee80211_stop_queue()
directly is the only available solution to fix the problem without
major rework.

Signed-off-by: Stanislaw Gruszka <stf_xl@wp.pl>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
mwifiex: Add missing endian conversion.

commit 83e612f632c3897be29ef02e0472f6d63e258378 upstream.

Both type and pkt_len variables are in host endian and these should be in
Little Endian in the payload.

Signed-off-by: Tomasz Moń <desowin@gmail.com>
Acked-by: Bing Zhao <bzhao@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
ACPI / battery: Fix parsing _BIX return value

commit 016d5baad04269e8559332df05f89bd95b52d6ad upstream.

The _BIX method returns extended battery info as a package.
According the ACPI spec (ACPI 5, Section 10.2.2.2), the first member
of that package should be "Revision".  However, the current ACPI
battery driver treats the first member as "Power Unit" which should
be the second member.  This causes the result of _BIX return data
parsing to be incorrect.

Fix this by adding a new member called 'revision' to struct
acpi_battery and adding the offsetof() information on it to
extended_info_offsets[] as the first row.

[rjw: Changelog]
Reported-and-tested-by: Jan Hoffmann <jan.christian.hoffmann@gmail.com>
References: http://bugzilla.kernel.org/show_bug.cgi?id=60519
Signed-off-by: Lan Tianyu <tianyu.lan@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
sched: Fix the broken sched_rr_get_interval()

commit a59f4e079d19464eebb9b06513a1d4f55fdae5ba upstream.

The caller of sched_sliced() should pass se.cfs_rq and se as the
arguments, however in sched_rr_get_interval() we gave it
rq.cfs_rq and se, which made the following computation obviously
wrong.

The change was introduced by commit:

  77034937dc45 sched: fix crash in sys_sched_rr_get_interval()

... 5 years ago, while it had been the correct 'cfs_rq_of' before
the commit. The change seems to be irrelevant to the commit
msg, which was to return a 0 timeslice for tasks that are on an
idle runqueue. So I believe that was just a plain typo.

Signed-off-by: Zhu Yanhai <gaoyang.zyh@taobao.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Paul Turner <pjt@google.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Link: http://lkml.kernel.org/r/1357621012-15039-1-git-send-email-gaoyang.zyh@taobao.com
[ Since this is an ABI and an old bug, we'll test this via a
  slow upstream route, to hopefully discover any app breakage. ]
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
fanotify: info leak in copy_event_to_user()

commit de1e0c40aceb9d5bff09c3a3b97b2f1b178af53f upstream.

The ->reserved field isn't cleared so we leak one byte of stack
information to userspace.

Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Cc: Eric Paris <eparis@redhat.com>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Luis Henriques <luis.henriques@canonical.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
MAINTAINERS: fix up stable_kernel_rules.txt location

There was a mismerge of 7b175c46720f8e6b92801bb634c93d1016f80c62 for the
3.0 kernel, so this fixes it up.

Also mark the stable stuff "Supported", as it is.

Reported-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
perf: Fix event group context move

commit 0231bb5336758426b44ccd798ccd3c5419c95d58 upstream.

When we have group with mixed events (hw/sw) we want to end up
with group leader being in hw context. So if group leader is
initialy sw event, we move all the events under hw context.

The move is done for each event by removing it from its context
and adding it back into proper one. As a part of the removal the
event is automatically disabled, which is not what we want at
this stage of creating groups.

The fix is to initialize event state after removal from sw
context.

This fix resulted from the following discussion:

  http://thread.gmane.org/gmane.linux.kernel.perf.user/1144

Reported-by: Andreas Hollmann <hollmann@in.tum.de>
Signed-off-by: Jiri Olsa <jolsa@redhat.com>
Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Corey Ashford <cjashfor@linux.vnet.ibm.com>
Cc: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Stephane Eranian <eranian@google.com>
Cc: Vince Weaver <vince@deater.net>
Link: http://lkml.kernel.org/r/1359714225-4231-1-git-send-email-jolsa@redhat.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Cc: Li Zefan <lizefan@huawei.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
x86, fpu: correct the asm constraints for fxsave, unbreak mxcsr.daz

commit eaa5a990191d204ba0f9d35dbe5505ec2cdd1460 upstream.

GCC will optimize mxcsr_feature_mask_init in arch/x86/kernel/i387.c:

		memset(&fx_scratch, 0, sizeof(struct i387_fxsave_struct));
		asm volatile("fxsave %0" : : "m" (fx_scratch));
		mask = fx_scratch.mxcsr_mask;
		if (mask == 0)
			mask = 0x0000ffbf;

to

		memset(&fx_scratch, 0, sizeof(struct i387_fxsave_struct));
		asm volatile("fxsave %0" : : "m" (fx_scratch));
		mask = 0x0000ffbf;

since asm statement doesn’t say it will update fx_scratch.  As the
result, the DAZ bit will be cleared.  This patch fixes it. This bug
dates back to at least kernel 2.6.12.

Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
perf: Use css_tryget() to avoid propping up css refcount

commit 9c5da09d266ca9b32eb16cf940f8161d949c2fe5 upstream.

An rmdir pushes css's ref count to zero.  However, if the associated
directory is open at the time, the dentry ref count is non-zero.  If
the fd for this directory is then passed into perf_event_open, it
does a css_get().  This bounces the ref count back up from zero.  This
is a problem by itself.  But what makes it turn into a crash is the
fact that we end up doing an extra dput, since we perform a dput
when css_put sees the ref count go down to zero.

css_tryget() does not fall into that trap. So, we use that instead.

Reproduction test-case for the bug:

 #include <unistd.h>
 #include <sys/types.h>
 #include <sys/stat.h>
 #include <fcntl.h>
 #include <linux/unistd.h>
 #include <linux/perf_event.h>
 #include <string.h>
 #include <errno.h>
 #include <stdio.h>

 #define PERF_FLAG_PID_CGROUP    (1U << 2)

 int perf_event_open(struct perf_event_attr *hw_event_uptr,
                     pid_t pid, int cpu, int group_fd, unsigned long flags) {
         return syscall(__NR_perf_event_open,hw_event_uptr, pid, cpu,
                 group_fd, flags);
 }

 /*
  * Directly poke at the perf_event bug, since it's proving hard to repro
  * depending on where in the kernel tree.  what moved?
  */
 int main(int argc, char **argv)
 {
        int fd;
        struct perf_event_attr attr;
        memset(&attr, 0, sizeof(attr));
        attr.exclude_kernel = 1;
        attr.size = sizeof(attr);
        mkdir("/dev/cgroup/perf_event/blah", 0777);
        fd = open("/dev/cgroup/perf_event/blah", O_RDONLY);
        perror("open");
        rmdir("/dev/cgroup/perf_event/blah");
        sleep(2);
        perf_event_open(&attr, fd, 0, -1,  PERF_FLAG_PID_CGROUP);
        perror("perf_event_open");
        close(fd);
        return 0;
 }

Signed-off-by: Salman Qazi <sqazi@google.com>
Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Acked-by: Tejun Heo <tj@kernel.org>
Link: http://lkml.kernel.org/r/20120614223108.1025.2503.stgit@dungbeetle.mtv.corp.google.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Cc: Li Zefan <lizefan@huawei.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
arcnet: cleanup sizeof parameter

[ Upstream commit 087d273caf4f7d3f2159256f255f1f432bc84a5b ]

This patch doesn't change the compiled code because ARC_HDR_SIZE is 4
and sizeof(int) is 4, but the intent was to use the header size and not
the sizeof the header size.

Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
sysctl net: Keep tcp_syn_retries inside the boundary

[ Upstream commit 651e92716aaae60fc41b9652f54cb6803896e0da ]

Limit the min/max value passed to the
/proc/sys/net/ipv4/tcp_syn_retries.

Signed-off-by: Michal Tesar <mtesar@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
sctp: fully initialize sctp_outq in sctp_outq_init

[ Upstream commit c5c7774d7eb4397891edca9ebdf750ba90977a69 ]

In commit 2f94aabd9f6c925d77aecb3ff020f1cc12ed8f86
(refactor sctp_outq_teardown to insure proper re-initalization)
we modified sctp_outq_teardown to use sctp_outq_init to fully re-initalize the
outq structure.  Steve West recently asked me why I removed the q->error = 0
initalization from sctp_outq_teardown.  I did so because I was operating under
the impression that sctp_outq_init would properly initalize that value for us,
but it doesn't.  sctp_outq_init operates under the assumption that the outq
struct is all 0's (as it is when called from sctp_association_init), but using
it in __sctp_outq_teardown violates that assumption. We should do a memset in
sctp_outq_init to ensure that the entire structure is in a known state there
instead.

Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
Reported-by: "West, Steve (NSN - US/Fort Worth)" <steve.west@nsn.com>
CC: Vlad Yasevich <vyasevich@gmail.com>
CC: netdev@vger.kernel.org
CC: davem@davemloft.net
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>
ipv6: take rtnl_lock and mark mrt6 table as freed on namespace cleanup

[ Upstream commit 905a6f96a1b18e490a75f810d733ced93c39b0e5 ]

Otherwise we end up dereferencing the already freed net->ipv6.mrt pointer
which leads to a panic (from Srivatsa S. Bhat):

BUG: unable to handle kernel paging request at ffff882018552020
IP: [<ffffffffa0366b02>] ip6mr_sk_done+0x32/0xb0 [ipv6]
PGD 290a067 PUD 207ffe0067 PMD 207ff1d067 PTE 8000002018552060
Oops: 0000 [#1] SMP DEBUG_PAGEALLOC
Modules linked in: ebtable_nat ebtables nfs fscache nf_conntrack_ipv4 nf_defrag_ipv4 ipt_REJECT xt_CHECKSUM iptable_mangle iptable_filter ip_tables nfsd lockd nfs_acl exportfs auth_rpcgss autofs4 sunrpc 8021q garp bridge stp llc ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 xt_state nf_conntrack ip6table_filter
+ip6_tables ipv6 vfat fat vhost_net macvtap macvlan vhost tun kvm_intel kvm uinput iTCO_wdt iTCO_vendor_support cdc_ether usbnet mii microcode i2c_i801 i2c_core lpc_ich mfd_core shpchp ioatdma dca mlx4_core be2net wmi acpi_cpufreq mperf ext4 jbd2 mbcache dm_mirror dm_region_hash dm_log dm_mod
CPU: 0 PID: 7 Comm: kworker/u33:0 Not tainted 3.11.0-rc1-ea45e-a #4
Hardware name: IBM  -[8737R2A]-/00Y2738, BIOS -[B2E120RUS-1.20]- 11/30/2012
Workqueue: netns cleanup_net
task: ffff8810393641c0 ti: ffff881039366000 task.ti: ffff881039366000
RIP: 0010:[<ffffffffa0366b02>]  [<ffffffffa0366b02>] ip6mr_sk_done+0x32/0xb0 [ipv6]
RSP: 0018:ffff881039367bd8  EFLAGS: 00010286
RAX: ffff881039367fd8 RBX: ffff882018552000 RCX: dead000000200200
RDX: 0000000000000000 RSI: ffff881039367b68 RDI: ffff881039367b68
RBP: ffff881039367bf8 R08: ffff881039367b68 R09: 2222222222222222
R10: 2222222222222222 R11: 2222222222222222 R12: ffff882015a7a040
R13: ffff882014eb89c0 R14: ffff8820289e2800 R15: 0000000000000000
FS:  0000000000000000(0000) GS:ffff88103fc00000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: ffff882018552020 CR3: 0000000001c0b000 CR4: 00000000000407f0
Stack:
 ffff881039367c18 ffff882014eb89c0 ffff882015e28c00 0000000000000000
 ffff881039367c18 ffffffffa034d9d1 ffff8820289e2800 ffff882014eb89c0
 ffff881039367c58 ffffffff815bdecb ffffffff815bddf2 ffff882014eb89c0
Call Trace:
 [<ffffffffa034d9d1>] rawv6_close+0x21/0x40 [ipv6]
 [<ffffffff815bdecb>] inet_release+0xfb/0x220
 [<ffffffff815bddf2>] ? inet_release+0x22/0x220
 [<ffffffffa032686f>] inet6_release+0x3f/0x50 [ipv6]
 [<ffffffff8151c1d9>] sock_release+0x29/0xa0
 [<ffffffff81525520>] sk_release_kernel+0x30/0x70
 [<ffffffffa034f14b>] icmpv6_sk_exit+0x3b/0x80 [ipv6]
 [<ffffffff8152fff9>] ops_exit_list+0x39/0x60
 [<ffffffff815306fb>] cleanup_net+0xfb/0x1a0
 [<ffffffff81075e3a>] process_one_work+0x1da/0x610
 [<ffffffff81075dc9>] ? process_one_work+0x169/0x610
 [<ffffffff81076390>] worker_thread+0x120/0x3a0
 [<ffffffff81076270>] ? process_one_work+0x610/0x610
 [<ffffffff8107da2e>] kthread+0xee/0x100
 [<ffffffff8107d940>] ? __init_kthread_worker+0x70/0x70
 [<ffffffff8162a99c>] ret_from_fork+0x7c/0xb0
 [<ffffffff8107d940>] ? __init_kthread_worker+0x70/0x70
Code: 20 48 89 5d e8 4c 89 65 f0 4c 89 6d f8 66 66 66 66 90 4c 8b 67 30 49 89 fd e8 db 3c 1e e1 49 8b 9c 24 90 08 00 00 48 85 db 74 06 <4c> 39 6b 20 74 20 bb f3 ff ff ff e8 8e 3c 1e e1 89 d8 4c 8b 65
RIP  [<ffffffffa0366b02>] ip6mr_sk_done+0x32/0xb0 [ipv6]
 RSP <ffff881039367bd8>
CR2: ffff882018552020

Reported-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
Tested-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>