net: wireless: bcmdhd: Enable p2p support bits for p2p device

Change-Id: Ie3537aaeecdbbddb5219b41c42f2f6ac5d85f5b4
Signed-off-by: Dmitry Shmidt <dimitrysh@google.com>
net: ipv6: add missing lock in ping_v6_sendmsg

[net-next commit a1bdc45580fc19e968b32ad27cd7e476a4aa58f6]

Bug: 9469865
Change-Id: I480f8ce95956dd8f17fbbb26dc60cc162f8ec933
Signed-off-by: Lorenzo Colitti <lorenzo@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
net: ipv6: fix wrong ping_v6_sendmsg return value

[net-next commit fbfe80c890a1dc521d0b629b870e32fcffff0da5]

ping_v6_sendmsg currently returns 0 on success. It should return
the number of bytes written instead.

Bug: 9469865
Change-Id: I82b7d3a37ba91ad24e6dbd97a4880745ce16ad31
Signed-off-by: Lorenzo Colitti <lorenzo@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
net: wireless: bcmdhd: Fix roaming to hidden AP

Change-Id: Id64d12962049833e19705fbe109ef04b60014079
Signed-off-by: Dmitry Shmidt <dimitrysh@google.com>
net: wireless: bcmdhd: Inject EID value if it has 0 length

Change-Id: Ifd102bee45e1a1e04ba015c39631a741ca74d6ee
Signed-off-by: Dmitry Shmidt <dimitrysh@google.com>
Linux 3.0.95

commit 03188ddd7dd3fdc65d626ac8bb9d1851502263c5
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Sat Sep 7 21:49:47 2013 -0700

    Linux 3.0.95

commit eb18ce5b78b1efb313a14532d2883420163e681a
Author: Roland Dreier <roland@purestorage.com>
Date:   Mon Aug 5 17:55:01 2013 -0700

    SCSI: sg: Fix user memory corruption when SG_IO is interrupted by a signal

    commit 35dc248383bbab0a7203fca4d722875bc81ef091 upstream.

    There is a nasty bug in the SCSI SG_IO ioctl that in some circumstances
    leads to one process writing data into the address space of some other
    random unrelated process if the ioctl is interrupted by a signal.
    What happens is the following:

     - A process issues an SG_IO ioctl with direction DXFER_FROM_DEV (ie the
       underlying SCSI command will transfer data from the SCSI device to
       the buffer provided in the ioctl)

     - Before the command finishes, a signal is sent to the process waiting
       in the ioctl.  This will end up waking up the sg_ioctl() code:

            result = wait_event_interruptible(sfp->read_wait,
                (srp_done(sfp, srp) || sdp->detached));

       but neither srp_done() nor sdp->detached is true, so we end up just
       setting srp->orphan and returning to userspace:

            srp->orphan = 1;
            write_unlock_irq(&sfp->rq_list_lock);
            return result;  /* -ERESTARTSYS because signal hit process */

       At this point the original process is done with the ioctl and
       blithely goes ahead handling the signal, reissuing the ioctl, etc.

     - Eventually, the SCSI command issued by the first ioctl finishes and
       ends up in sg_rq_end_io().  At the end of that function, we run through:

        write_lock_irqsave(&sfp->rq_list_lock, iflags);
        if (unlikely(srp->orphan)) {
            if (sfp->keep_orphan)
                srp->sg_io_owned = 0;
            else
                done = 0;
        }
        srp->done = done;
        write_unlock_irqrestore(&sfp->rq_list_lock, iflags);

        if (likely(done)) {
            /* Now wake up any sg_read() that is waiting for this
             * packet.
             */
            wake_up_interruptible(&sfp->read_wait);
            kill_fasync(&sfp->async_qp, SIGPOLL, POLL_IN);
            kref_put(&sfp->f_ref, sg_remove_sfp);
        } else {
            INIT_WORK(&srp->ew.work, sg_rq_end_io_usercontext);
            schedule_work(&srp->ew.work);
        }

       Since srp->orphan *is* set, we set done to 0 (assuming the
       userspace app has not set keep_orphan via an SG_SET_KEEP_ORPHAN
       ioctl), and therefore we end up scheduling sg_rq_end_io_usercontext()
       to run in a workqueue.

     - In workqueue context we go through sg_rq_end_io_usercontext() ->
       sg_finish_rem_req() -> blk_rq_unmap_user() -> ... ->
       bio_uncopy_user() -> __bio_copy_iov() -> copy_to_user().

       The key point here is that we are doing copy_to_user() on a
       workqueue -- that is, we're on a kernel thread with current->mm
       equal to whatever random previous user process was scheduled before
       this kernel thread.  So we end up copying whatever data the SCSI
       command returned to the virtual address of the buffer passed into
       the original ioctl, but it's quite likely we do this copying into a
       different address space!

    As suggested by James Bottomley <James.Bottomley@hansenpartnership.com>,
    add a check for current->mm (which is NULL if we're on a kernel thread
    without a real userspace address space) in bio_uncopy_user(), and skip
    the copy if we're on a kernel thread.

    There's no reason that I can think of for any caller of bio_uncopy_user()
    to want to do copying on a kernel thread with a random active userspace
    address space.

    Huge thanks to Costa Sapuntzakis <costa@purestorage.com> for the
    original pointer to this bug in the sg code.

    Signed-off-by: Roland Dreier <roland@purestorage.com>
    Tested-by: David Milburn <dmilburn@redhat.com>
    Cc: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: James Bottomley <JBottomley@Parallels.com>
    [lizf: backported to 3.4:
     - Use __bio_for_each_segment() instead of bio_for_each_segment_all()]
    Signed-off-by: Li Zefan <lizefan@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e9d581e05541c10c4eed1ea5718e084a80e10b8a
Author: Nicholas Bellinger <nab@linux-iscsi.org>
Date:   Wed Jul 24 16:15:08 2013 -0700

    target: Fix trailing ASCII space usage in INQUIRY vendor+model

    commit ee60bddba5a5f23e39598195d944aa0eb2d455e5 upstream.

    This patch fixes spc_emulate_inquiry_std() to add trailing ASCII
    spaces for INQUIRY vendor + model fields following SPC-4 text:

      "ASCII data fields described as being left-aligned shall have any
       unused bytes at the end of the field (i.e., highest offset) and
       the unused bytes shall be filled with ASCII space characters (20h)."

    This addresses a problem with Falconstor NSS multipathing.

    Reported-by: Tomas Molota <tomas.molota@lightstorm.sk>
    Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 833c9b848d8fab75497a7bb9741d58faeb2810cf
Author: Lan Tianyu <tianyu.lan@intel.com>
Date:   Mon Aug 26 10:19:18 2013 +0800

    ACPI / EC: Add ASUSTEK L4R to quirk list in order to validate ECDT

    commit 524f42fab787a9510be826ce3d736b56d454ac6d upstream.

    The ECDT of ASUSTEK L4R doesn't provide correct command and data
    I/O ports.  The DSDT provides the correct information instead.

    For this reason, add this machine to quirk list for ECDT validation
    and use the EC information from the DSDT.

    [rjw: Changelog]
    References: https://bugzilla.kernel.org/show_bug.cgi?id=60765
    Reported-and-tested-by: Daniele Esposti <expo@expobrain.net>
    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>

commit ed12ee72b75085866d3af2ded3a5177ef51c550a
Author: Helmut Schaa <helmut.schaa@googlemail.com>
Date:   Fri Aug 16 21:39:40 2013 +0200

    ath9k_htc: Restore skb headroom when returning skb to mac80211

    commit d2e9fc141e2aa21f4b35ee27072d84e9aa6e2ba0 upstream.

    ath9k_htc adds padding between the 802.11 header and the payload during
    TX by moving the header. When handing the frame back to mac80211 for TX
    status handling the header is not moved back into its original position.
    This can result in a too small skb headroom when entering ath9k_htc
    again (due to a soft retransmission for example) causing an
    skb_under_panic oops.

    Fix this by moving the 802.11 header back into its original position
    before returning the frame to mac80211 as other drivers like rt2x00
    or ath5k do.

    Reported-by: Marc Kleine-Budde <mkl@blackshift.org>
    Signed-off-by: Helmut Schaa <helmut.schaa@googlemail.com>
    Tested-by: Marc Kleine-Budde <mkl@blackshift.org>
    Signed-off-by: Marc Kleine-Budde <mkl@blackshift.org>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8e4c396fd61d6f00f1def1be3eec40cacffd3862
Author: Russ Anderson <rja@sgi.com>
Date:   Wed Aug 28 16:35:18 2013 -0700

    drivers/base/memory.c: fix show_mem_removable() to handle missing sections

    commit 21ea9f5ace3a7317cc3ba1fbc749758021a83136 upstream.

    "cat /sys/devices/system/memory/memory*/removable" crashed the system.

    The problem is that show_mem_removable() is passing a
    bad pfn to is_mem_section_removable(), which causes

        if (!node_online(page_to_nid(page)))

    to blow up.  Why is it passing in a bad pfn?

    The reason is that show_mem_removable() will loop sections_per_block
    times.  sections_per_block is 16, but mem->section_count is 8,
    indicating holes in this memory block.  Checking that the memory section
    is present before checking to see if the memory section is removable
    fixes the problem.

       harp5-sys:~ # cat /sys/devices/system/memory/memory*/removable
       0
       1
       1
       1
       1
       1
       1
       1
       1
       1
       1
       1
       1
       1
       BUG: unable to handle kernel paging request at ffffea00c3200000
       IP: [<ffffffff81117ed1>] is_pageblock_removable_nolock+0x1/0x90
       PGD 83ffd4067 PUD 37bdfce067 PMD 0
       Oops: 0000 [#1] SMP
       Modules linked in: autofs4 binfmt_misc rdma_ucm rdma_cm iw_cm ib_addr ib_srp scsi_transport_srp scsi_tgt ib_ipoib ib_cm ib_uverbs ib_umad iw_cxgb3 cxgb3 mdio mlx4_en mlx4_ib ib_sa mlx4_core ib_mthca ib_mad ib_core fuse nls_iso8859_1 nls_cp437 vfat fat joydev loop hid_generic usbhid hid hwperf(O) numatools(O) dm_mod iTCO_wdt ipv6 iTCO_vendor_support igb i2c_i801 ioatdma i2c_algo_bit ehci_pci pcspkr lpc_ich i2c_core ehci_hcd ptp sg mfd_core dca rtc_cmos pps_core mperf button xhci_hcd sd_mod crc_t10dif usbcore usb_common scsi_dh_emc scsi_dh_hp_sw scsi_dh_alua scsi_dh_rdac scsi_dh gru(O) xvma(O) xfs crc32c libcrc32c thermal sata_nv processor piix mptsas mptscsih scsi_transport_sas mptbase megaraid_sas fan thermal_sys hwmon ext3 jbd ata_piix ahci libahci libata scsi_mod
       CPU: 4 PID: 5991 Comm: cat Tainted: G           O 3.11.0-rc5-rja-uv+ #10
       Hardware name: SGI UV2000/ROMLEY, BIOS SGI UV 2000/3000 series BIOS 01/15/2013
       task: ffff88081f034580 ti: ffff880820022000 task.ti: ffff880820022000
       RIP: 0010:[<ffffffff81117ed1>]  [<ffffffff81117ed1>] is_pageblock_removable_nolock+0x1/0x90
       RSP: 0018:ffff880820023df8  EFLAGS: 00010287
       RAX: 0000000000040000 RBX: ffffea00c3200000 RCX: 0000000000000004
       RDX: ffffea00c30b0000 RSI: 00000000001c0000 RDI: ffffea00c3200000
       RBP: ffff880820023e38 R08: 0000000000000000 R09: 0000000000000001
       R10: 0000000000000000 R11: 0000000000000001 R12: ffffea00c33c0000
       R13: 0000160000000000 R14: 6db6db6db6db6db7 R15: 0000000000000001
       FS:  00007ffff7fb2700(0000) GS:ffff88083fc80000(0000) knlGS:0000000000000000
       CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
       CR2: ffffea00c3200000 CR3: 000000081b954000 CR4: 00000000000407e0
       Call Trace:
         show_mem_removable+0x41/0x70
         dev_attr_show+0x2a/0x60
         sysfs_read_file+0xf7/0x1c0
         vfs_read+0xc8/0x130
         SyS_read+0x5d/0xa0
         system_call_fastpath+0x16/0x1b

    Signed-off-by: Russ Anderson <rja@sgi.com>
    Cc: "Rafael J. Wysocki" <rafael.j.wysocki@intel.com>
    Cc: Yinghai Lu <yinghai@kernel.org>
    Reviewed-by: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.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 902ecc26fc6deb3b53d85496d53029777ddeecba
Author: Takashi Iwai <tiwai@suse.de>
Date:   Tue Aug 27 12:03:01 2013 +0200

    ALSA: opti9xx: Fix conflicting driver object name

    commit fb615499f0ad28ed74201c1cdfddf9e64e205424 upstream.

    The recent commit to delay the release of kobject triggered NULL
    dereferences of opti9xx drivers.  The cause is that all
    snd-opti92x-ad1848, snd-opti92x-cs4231 and snd-opti93x drivers
    register the PnP card driver with the very same name, and also
    snd-opti92x-ad1848 and -cs4231 drivers register the ISA driver with
    the same name, too.  When these drivers are built in, quick
    "register-release-and-re-register" actions occur, and this results in
    Oops because of the same name is assigned to the kobject.

    The fix is simply to assign individual names.  As a bonus, by using
    KBUILD_MODNAME, the patch reduces more lines than it adds.

    The fix is based on the suggestion by Russell King.

    Reported-and-tested-by: Fengguang Wu <fengguang.wu@intel.com>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 59fb9f6b1f98c9ab912bbac7b55ba5bc2e40750b
Author: Dave Kleikamp <dave.kleikamp@oracle.com>
Date:   Thu Aug 15 15:36:49 2013 -0500

    jfs: fix readdir cookie incompatibility with NFSv4

    commit 44512449c0ab368889dd13ae0031fba74ee7e1d2 upstream.

    NFSv4 reserves readdir cookie values 0-2 for special entries (. and ..),
    but jfs allows a value of 2 for a non-special entry. This incompatibility
    can result in the nfs client reporting a readdir loop.

    This patch doesn't change the value stored internally, but adds one to
    the value exposed to the iterate method.

    Signed-off-by: Dave Kleikamp <dave.kleikamp@oracle.com>
    [bwh: Backported to 3.2:
     - Adjust context
     - s/ctx->pos/filp->f_pos/]
    Tested-by: Christian Kujau <lists@nerdbynature.de>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
net: wireless: bcmdhd: Clean scan status if request is empty

Change-Id: I1c00b5a84846faf316305f57a6a74ded2288a6fd
Signed-off-by: Dmitry Shmidt <dimitrysh@google.com>
Linux 3.0.96

commit 04b25c9dde9337ea972147f47fa75709dd7377f3
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Sat Sep 14 05:58:09 2013 -0700

    Linux 3.0.96

commit 2ccddb4d6101ea65c3f716ca6546c4d82b767bdf
Author: Dominik Dingel <dingel@linux.vnet.ibm.com>
Date:   Fri Jul 26 15:04:00 2013 +0200

    KVM: s390: move kvm_guest_enter,exit closer to sie

    commit 2b29a9fdcb92bfc6b6f4c412d71505869de61a56 upstream.

    Any uaccess between guest_enter and guest_exit could trigger a page fault,
    the page fault handler would handle it as a guest fault and translate a
    user address as guest address.

    Signed-off-by: Dominik Dingel <dingel@linux.vnet.ibm.com>
    Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    [bwh: Backported to 3.2: adjust context and add the rc variable]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Reviewed-by: Dominik Dingel <dingel@linux.vnet.ibm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 40318c990ef6005a3c9933253e7b63a4f5e06c3a
Author: Geert Uytterhoeven <geert@linux-m68k.org>
Date:   Tue Jul 17 15:48:05 2012 -0700

    m32r: make memset() global for CONFIG_KERNEL_BZIP2=y

    commit 9a75c6e5240f7edc5955e8da5b94bde6f96070b3 upstream.

    Fix the m32r compile error:

      arch/m32r/boot/compressed/misc.c:31:14: error: static declaration of 'memset' follows non-static declaration
      make[5]: *** [arch/m32r/boot/compressed/misc.o] Error 1
      make[4]: *** [arch/m32r/boot/compressed/vmlinux] Error 2

    by removing the static keyword.

    Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
    Cc: Hirokazu Takata <takata@linux-m32r.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Ben Hutchings <ben@decadent.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4cfa1966cc4cec7ea37d572eca9f930b09dc3cf2
Author: Geert Uytterhoeven <geert@linux-m68k.org>
Date:   Tue Jul 17 15:48:04 2012 -0700

    m32r: add memcpy() for CONFIG_KERNEL_GZIP=y

    commit a8abbca6617e1caa2344d2d38d0a35f3e5928b79 upstream.

    Fix the m32r link error:

        LD      arch/m32r/boot/compressed/vmlinux
      arch/m32r/boot/compressed/misc.o: In function `zlib_updatewindow':
      misc.c:(.text+0x190): undefined reference to `memcpy'
      misc.c:(.text+0x190): relocation truncated to fit: R_M32R_26_PLTREL against undefined symbol `memcpy'
      make[5]: *** [arch/m32r/boot/compressed/vmlinux] Error 1

    by adding our own implementation of memcpy().

    Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
    Cc: Hirokazu Takata <takata@linux-m32r.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Ben Hutchings <ben@decadent.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 850cc18d180176194633acba57ff6bd443086ad9
Author: Geert Uytterhoeven <geert@linux-m68k.org>
Date:   Tue Jul 17 15:48:02 2012 -0700

    m32r: consistently use "suffix-$(...)"

    commit df12aef6a19bb2d69859a94936bda0e6ccaf3327 upstream.

    Commit a556bec9955c ("m32r: fix arch/m32r/boot/compressed/Makefile")
    changed "$(suffix_y)" to "$(suffix-y)", but didn't update any location
    where "suffix_y" is set, causing:

      make[5]: *** No rule to make target `arch/m32r/boot/compressed/vmlinux.bin.', needed by `arch/m32r/boot/compressed/piggy.o'.  Stop.
      make[4]: *** [arch/m32r/boot/compressed/vmlinux] Error 2
      make[3]: *** [zImage] Error 2

    Correct the other locations to fix this.

    Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
    Cc: Hirokazu Takata <takata@linux-m32r.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Ben Hutchings <ben@decadent.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit dbc93fb6085c4182233621a981e7ec0a3539cbf9
Author: Paul Gortmaker <paul.gortmaker@windriver.com>
Date:   Wed Apr 18 17:17:19 2012 -0400

    pci: frv architecture needs generic setup-bus infrastructure

    commit cd0a2bfb77a3edeecd652081e0b1a163d3b0696b upstream.

    Otherwise we get this link failure for frv's defconfig:

       LD      .tmp_vmlinux1
     drivers/built-in.o: In function `pci_assign_resource':
     (.text+0xbf0c): undefined reference to `pci_cardbus_resource_alignment'
     drivers/built-in.o: In function `pci_setup':
     pci.c:(.init.text+0x174): undefined reference to `pci_realloc_get_opt'
     pci.c:(.init.text+0x1a0): undefined reference to `pci_realloc_get_opt'
     make[1]: *** [.tmp_vmlinux1] Error 1

    Cc: David Howells <dhowells@redhat.com>
    Acked-by: Bjorn Helgaas <bhelgaas@google.com>
    Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
    Cc: Ben Hutchings <ben@decadent.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 288e9d859cc10e121a33dd603bd7174c98bd7ac8
Author: Cong Wang <xiyou.wangcong@gmail.com>
Date:   Fri Feb 3 15:34:16 2012 +0800

    PARISC: include <linux/prefetch.h> in drivers/parisc/iommu-helpers.h

    commit 650275dbfb2f4c12bc91420ad5a99f955eabec98 upstream.

    drivers/parisc/iommu-helpers.h:62: error: implicit declaration of function 'prefetchw'
    make[3]: *** [drivers/parisc/sba_iommu.o] Error 1

    drivers/parisc/iommu-helpers.h needs to #include <linux/prefetch.h>
    where prefetchw is declared.

    Signed-off-by: WANG Cong <xiyou.wangcong@gmail.com>
    Signed-off-by: James Bottomley <JBottomley@Parallels.com>
    Cc: Ben Hutchings <ben@decadent.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 49b74a1aebc95914fff369b746ce13558eb9063f
Author: Ying Xue <ying.xue@windriver.com>
Date:   Thu Aug 16 12:09:07 2012 +0000

    tipc: fix lockdep warning during bearer initialization

    [ Upstream commit 4225a398c1352a7a5c14dc07277cb5cc4473983b ]

    When the lockdep validator is enabled, it will report the below
    warning when we enable a TIPC bearer:

    [ INFO: possible irq lock inversion dependency detected ]
    ---------------------------------------------------------
    Possible interrupt unsafe locking scenario:

            CPU0                    CPU1
            ----                    ----
       lock(ptype_lock);
                                    local_irq_disable();
                                    lock(tipc_net_lock);
                                    lock(ptype_lock);
       <Interrupt>
       lock(tipc_net_lock);

      *** DEADLOCK ***

    the shortest dependencies between 2nd lock and 1st lock:
      -> (ptype_lock){+.+...} ops: 10 {
    [...]
    SOFTIRQ-ON-W at:
                          [<c1089418>] __lock_acquire+0x528/0x13e0
                          [<c108a360>] lock_acquire+0x90/0x100
                          [<c1553c38>] _raw_spin_lock+0x38/0x50
                          [<c14651ca>] dev_add_pack+0x3a/0x60
                          [<c182da75>] arp_init+0x1a/0x48
                          [<c182dce5>] inet_init+0x181/0x27e
                          [<c1001114>] do_one_initcall+0x34/0x170
                          [<c17f7329>] kernel_init+0x110/0x1b2
                          [<c155b6a2>] kernel_thread_helper+0x6/0x10
    [...]
       ... key      at: [<c17e4b10>] ptype_lock+0x10/0x20
       ... acquired at:
        [<c108a360>] lock_acquire+0x90/0x100
        [<c1553c38>] _raw_spin_lock+0x38/0x50
        [<c14651ca>] dev_add_pack+0x3a/0x60
        [<c8bc18d2>] enable_bearer+0xf2/0x140 [tipc]
        [<c8bb283a>] tipc_enable_bearer+0x1ba/0x450 [tipc]
        [<c8bb3a04>] tipc_cfg_do_cmd+0x5c4/0x830 [tipc]
        [<c8bbc032>] handle_cmd+0x42/0xd0 [tipc]
        [<c148e802>] genl_rcv_msg+0x232/0x280
        [<c148d3f6>] netlink_rcv_skb+0x86/0xb0
        [<c148e5bc>] genl_rcv+0x1c/0x30
        [<c148d144>] netlink_unicast+0x174/0x1f0
        [<c148ddab>] netlink_sendmsg+0x1eb/0x2d0
        [<c1456bc1>] sock_aio_write+0x161/0x170
        [<c1135a7c>] do_sync_write+0xac/0xf0
        [<c11360f6>] vfs_write+0x156/0x170
        [<c11361e2>] sys_write+0x42/0x70
        [<c155b0df>] sysenter_do_call+0x12/0x38
    [...]
    }
      -> (tipc_net_lock){+..-..} ops: 4 {
    [...]
        IN-SOFTIRQ-R at:
                         [<c108953a>] __lock_acquire+0x64a/0x13e0
                         [<c108a360>] lock_acquire+0x90/0x100
                         [<c15541cd>] _raw_read_lock_bh+0x3d/0x50
                         [<c8bb874d>] tipc_recv_msg+0x1d/0x830 [tipc]
                         [<c8bc195f>] recv_msg+0x3f/0x50 [tipc]
                         [<c146a5fa>] __netif_receive_skb+0x22a/0x590
                         [<c146ab0b>] netif_receive_skb+0x2b/0xf0
                         [<c13c43d2>] pcnet32_poll+0x292/0x780
                         [<c146b00a>] net_rx_action+0xfa/0x1e0
                         [<c103a4be>] __do_softirq+0xae/0x1e0
    [...]
    }

    >From the log, we can see three different call chains between
    CPU0 and CPU1:

    Time 0 on CPU0:

      kernel_init()->inet_init()->dev_add_pack()

    At time 0, the ptype_lock is held by CPU0 in dev_add_pack();

    Time 1 on CPU1:

      tipc_enable_bearer()->enable_bearer()->dev_add_pack()

    At time 1, tipc_enable_bearer() first holds tipc_net_lock, and then
    wants to take ptype_lock to register TIPC protocol handler into the
    networking stack.  But the ptype_lock has been taken by dev_add_pack()
    on CPU0, so at this time the dev_add_pack() running on CPU1 has to be
    busy looping.

    Time 2 on CPU0:

      netif_receive_skb()->recv_msg()->tipc_recv_msg()

    At time 2, an incoming TIPC packet arrives at CPU0, hence
    tipc_recv_msg() will be invoked. In tipc_recv_msg(), it first wants
    to hold tipc_net_lock.  At the moment, below scenario happens:

    On CPU0, below is our sequence of taking locks:

      lock(ptype_lock)->lock(tipc_net_lock)

    On CPU1, our sequence of taking locks looks like:

      lock(tipc_net_lock)->lock(ptype_lock)

    Obviously deadlock may happen in this case.

    But please note the deadlock possibly doesn't occur at all when the
    first TIPC bearer is enabled.  Before enable_bearer() -- running on
    CPU1 does not hold ptype_lock, so the TIPC receive handler (i.e.
    recv_msg()) is not registered successfully via dev_add_pack(), so
    the tipc_recv_msg() cannot be called by recv_msg() even if a TIPC
    message comes to CPU0. But when the second TIPC bearer is
    registered, the deadlock can perhaps really happen.

    To fix it, we will push the work of registering TIPC protocol
    handler into workqueue context. After the change, both paths taking
    ptype_lock are always in process contexts, thus, the deadlock should
    never occur.

    Signed-off-by: Ying Xue <ying.xue@windriver.com>
    Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
    Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2eeeacf627ab4bac67c3c1735b2c96fccbea6262
Author: Jiri Bohac <jbohac@suse.cz>
Date:   Fri Aug 30 11:18:45 2013 +0200

    ICMPv6: treat dest unreachable codes 5 and 6 as EACCES, not EPROTO

    [ Upstream commit 61e76b178dbe7145e8d6afa84bb4ccea71918994 ]

    RFC 4443 has defined two additional codes for ICMPv6 type 1 (destination
    unreachable) messages:
            5 - Source address failed ingress/egress policy
        6 - Reject route to destination

    Now they are treated as protocol error and icmpv6_err_convert() converts them
    to EPROTO.

    RFC 4443 says:
        "Codes 5 and 6 are more informative subsets of code 1."

    Treat codes 5 and 6 as code 1 (EACCES)

    Btw, connect() returning -EPROTO confuses firefox, so that fallback to
    other/IPv4 addresses does not work:
    https://bugzilla.mozilla.org/show_bug.cgi?id=910773

    Signed-off-by: Jiri Bohac <jbohac@suse.cz>
    Acked-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 238d6ce5d070b4f95a3deeaf979d8c7e30d7de5d
Author: Daniel Borkmann <dborkman@redhat.com>
Date:   Thu Aug 29 23:55:05 2013 +0200

    net: bridge: convert MLDv2 Query MRC into msecs_to_jiffies for max_delay

    [ Upstream commit 2d98c29b6fb3de44d9eaa73c09f9cf7209346383 ]

    While looking into MLDv1/v2 code, I noticed that bridging code does
    not convert it's max delay into jiffies for MLDv2 messages as we do
    in core IPv6' multicast code.

    RFC3810, 5.1.3. Maximum Response Code says:

      The Maximum Response Code field specifies the maximum time allowed
      before sending a responding Report. The actual time allowed, called
      the Maximum Response Delay, is represented in units of milliseconds,
      and is derived from the Maximum Response Code as follows: [...]

    As we update timers that work with jiffies, we need to convert it.

    Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
    Cc: Linus Lüssing <linus.luessing@web.de>
    Cc: Hannes Frederic Sowa <hannes@stressinduktion.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6ca04e8fc4c799a55b011d489b71a5732a9ae8dd
Author: Thomas Graf <tgraf@suug.ch>
Date:   Tue Sep 3 13:37:01 2013 +0200

    ipv6: Don't depend on per socket memory for neighbour discovery messages

    [ Upstream commit 25a6e6b84fba601eff7c28d30da8ad7cfbef0d43 ]

    Allocating skbs when sending out neighbour discovery messages
    currently uses sock_alloc_send_skb() based on a per net namespace
    socket and thus share a socket wmem buffer space.

    If a netdevice is temporarily unable to transmit due to carrier
    loss or for other reasons, the queued up ndisc messages will cosnume
    all of the wmem space and will thus prevent from any more skbs to
    be allocated even for netdevices that are able to transmit packets.

    The number of neighbour discovery messages sent is very limited,
    use of alloc_skb() bypasses the socket wmem buffer size enforcement
    while the manual call to skb_set_owner_w() maintains the socket
    reference needed for the IPv6 output path.

    This patch has orginally been posted by Eric Dumazet in a modified
    form.

    Signed-off-by: Thomas Graf <tgraf@suug.ch>
    Cc: Eric Dumazet <eric.dumazet@gmail.com>
    Cc: Hannes Frederic Sowa <hannes@stressinduktion.org>
    Cc: Stephen Warren <swarren@wwwdotorg.org>
    Cc: Fabio Estevam <festevam@gmail.com>
    Tested-by: Fabio Estevam <fabio.estevam@freescale.com>
    Tested-by: Stephen Warren <swarren@nvidia.com>
    Acked-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1eeceae48fdc6e6fcb71403010ef5dd863b7ef2f
Author: Hannes Frederic Sowa <hannes@stressinduktion.org>
Date:   Fri Aug 16 13:30:07 2013 +0200

    ipv6: drop packets with multiple fragmentation headers

    [ Upstream commit f46078cfcd77fa5165bf849f5e568a7ac5fa569c ]

    It is not allowed for an ipv6 packet to contain multiple fragmentation
    headers. So discard packets which were already reassembled by
    fragmentation logic and send back a parameter problem icmp.

    The updates for RFC 6980 will come in later, I have to do a bit more
    research here.

    Cc: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
    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>

commit 9b7bb7587b9165ad6325b2908a19849dbded3ce0
Author: Hannes Frederic Sowa <hannes@stressinduktion.org>
Date:   Fri Aug 16 13:02:27 2013 +0200

    ipv6: remove max_addresses check from ipv6_create_tempaddr

    [ Upstream commit 4b08a8f1bd8cb4541c93ec170027b4d0782dab52 ]

    Because of the max_addresses check attackers were able to disable privacy
    extensions on an interface by creating enough autoconfigured addresses:

    <http://seclists.org/oss-sec/2012/q4/292>

    But the check is not actually needed: max_addresses protects the
    kernel to install too many ipv6 addresses on an interface and guards
    addrconf_prefix_rcv to install further addresses as soon as this limit
    is reached. We only generate temporary addresses in direct response of
    a new address showing up. As soon as we filled up the maximum number of
    addresses of an interface, we stop installing more addresses and thus
    also stop generating more temp addresses.

    Even if the attacker tries to generate a lot of temporary addresses
    by announcing a prefix and removing it again (lifetime == 0) we won't
    install more temp addresses, because the temporary addresses do count
    to the maximum number of addresses, thus we would stop installing new
    autoconfigured addresses when the limit is reached.

    This patch fixes CVE-2013-0343 (but other layer-2 attacks are still
    possible).

    Thanks to Ding Tianhong to bring this topic up again.

    Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
    Cc: Ding Tianhong <dingtianhong@huawei.com>
    Cc: George Kargiotakis <kargig@void.gr>
    Cc: P J P <ppandit@redhat.com>
    Cc: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
    Acked-by: Ding Tianhong <dingtianhong@huawei.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7d2754c66e451ac82fd5e93bdb715e59c4bfdb02
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Thu Aug 15 15:52:57 2013 +0300

    tun: signedness bug in tun_get_user()

    [ Upstream commit 15718ea0d844e4816dbd95d57a8a0e3e264ba90e ]

    The recent fix d9bf5f1309 "tun: compare with 0 instead of total_len" is
    not totally correct.  Because "len" and "sizeof()" are size_t type, that
    means they are never less than zero.

    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Acked-by: Michael S. Tsirkin <mst@redhat.com>
    Acked-by: Neil Horman <nhorman@tuxdriver.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 24e6771d4fce7c77b2569fa33131c871a2c5642e
Author: Hannes Frederic Sowa <hannes@stressinduktion.org>
Date:   Wed Aug 7 02:34:31 2013 +0200

    ipv6: don't stop backtracking in fib6_lookup_1 if subtree does not match

    [ Upstream commit 3e3be275851bc6fc90bfdcd732cd95563acd982b ]

    In case a subtree did not match we currently stop backtracking and return
    NULL (root table from fib_lookup). This could yield in invalid routing
    table lookups when using subtrees.

    Instead continue to backtrack until a valid subtree or node is found
    and return this match.

    Also remove unneeded NULL check.

    Reported-by: Teco Boot <teco@inf-net.nl>
    Cc: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
    Cc: David Lamparter <equinox@diac24.net>
    Cc: <boutier@pps.univ-paris-diderot.fr>
    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>

commit dd3004635fe0607f64ca9ceca51f209fbc0a09a6
Author: Eric Dumazet <edumazet@google.com>
Date:   Mon Aug 5 20:05:12 2013 -0700

    tcp: cubic: fix bug in bictcp_acked()

    [ Upstream commit cd6b423afd3c08b27e1fed52db828ade0addbc6b ]

    While investigating about strange increase of retransmit rates
    on hosts ~24 days after boot, Van found hystart was disabled
    if ca->epoch_start was 0, as following condition is true
    when tcp_time_stamp high order bit is set.

    (s32)(tcp_time_stamp - ca->epoch_start) < HZ

    Quoting Van :

     At initialization & after every loss ca->epoch_start is set to zero so
     I believe that the above line will turn off hystart as soon as the 2^31
     bit is set in tcp_time_stamp & hystart will stay off for 24 days.
     I think we've observed that cubic's restart is too aggressive without
     hystart so this might account for the higher drop rate we observe.

    Diagnosed-by: Van Jacobson <vanj@google.com>
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Cc: Neal Cardwell <ncardwell@google.com>
    Cc: Yuchung Cheng <ycheng@google.com>
    Acked-by: Neal Cardwell <ncardwell@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 28e9a84cdf505686ac00ead1adcbc75f26b48487
Author: Eric Dumazet <edumazet@google.com>
Date:   Mon Aug 5 17:10:15 2013 -0700

    tcp: cubic: fix overflow error in bictcp_update()

    [ Upstream commit 2ed0edf9090bf4afa2c6fc4f38575a85a80d4b20 ]

    commit 17a6e9f1aa9 ("tcp_cubic: fix clock dependency") added an
    overflow error in bictcp_update() in following code :

    /* change the unit from HZ to bictcp_HZ */
    t = ((tcp_time_stamp + msecs_to_jiffies(ca->delay_min>>3) -
          ca->epoch_start) << BICTCP_HZ) / HZ;

    Because msecs_to_jiffies() being unsigned long, compiler does
    implicit type promotion.

    We really want to constrain (tcp_time_stamp - ca->epoch_start)
    to a signed 32bit value, or else 't' has unexpected high values.

    This bugs triggers an increase of retransmit rates ~24 days after
    boot [1], as the high order bit of tcp_time_stamp flips.

    [1] for hosts with HZ=1000

    Big thanks to Van Jacobson for spotting this problem.

    Diagnosed-by: Van Jacobson <vanj@google.com>
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Cc: Neal Cardwell <ncardwell@google.com>
    Cc: Yuchung Cheng <ycheng@google.com>
    Cc: Stephen Hemminger <stephen@networkplumber.org>
    Acked-by: Neal Cardwell <ncardwell@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 45ff4d68f223419b7d77bc64cb4bbc0bc86c54d4
Author: Eric Dumazet <edumazet@google.com>
Date:   Mon Aug 5 11:18:49 2013 -0700

    fib_trie: remove potential out of bound access

    [ Upstream commit aab515d7c32a34300312416c50314e755ea6f765 ]

    AddressSanitizer [1] dynamic checker pointed a potential
    out of bound access in leaf_walk_rcu()

    We could allocate one more slot in tnode_new() to leave the prefetch()
    in-place but it looks not worth the pain.

    Bug added in commit 82cfbb008572b ("[IPV4] fib_trie: iterator recode")

    [1] :
    https://code.google.com/p/address-sanitizer/wiki/AddressSanitizerForKernel

    Reported-by: Andrey Konovalov <andreyknvl@google.com>
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Cc: Dmitry Vyukov <dvyukov@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f879090a22c5a3c34ff7a60363078e28450e3005
Author: Roman Gushchin <klamm@yandex-team.ru>
Date:   Fri Aug 2 18:36:40 2013 +0400

    net: check net.core.somaxconn sysctl values

    [ Upstream commit 5f671d6b4ec3e6d66c2a868738af2cdea09e7509 ]

    It's possible to assign an invalid value to the net.core.somaxconn
    sysctl variable, because there is no checks at all.

    The sk_max_ack_backlog field of the sock structure is defined as
    unsigned short. Therefore, the backlog argument in inet_listen()
    shouldn't exceed USHRT_MAX. The backlog argument in the listen() syscall
    is truncated to the somaxconn value. So, the somaxconn value shouldn't
    exceed 65535 (USHRT_MAX).
    Also, negative values of somaxconn are meaningless.

    before:
    $ sysctl -w net.core.somaxconn=256
    net.core.somaxconn = 256
    $ sysctl -w net.core.somaxconn=65536
    net.core.somaxconn = 65536
    $ sysctl -w net.core.somaxconn=-100
    net.core.somaxconn = -100

    after:
    $ sysctl -w net.core.somaxconn=256
    net.core.somaxconn = 256
    $ sysctl -w net.core.somaxconn=65536
    error: "Invalid argument" setting key "net.core.somaxconn"
    $ sysctl -w net.core.somaxconn=-100
    error: "Invalid argument" setting key "net.core.somaxconn"

    Based on a prior patch from Changli Gao.

    Signed-off-by: Roman Gushchin <klamm@yandex-team.ru>
    Reported-by: Changli Gao <xiaosuo@gmail.com>
    Suggested-by: Eric Dumazet <edumazet@google.com>
    Acked-by: Eric Dumazet <edumazet@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 77e9ebfd7c33f34f42761db4194961320264a482
Author: stephen hemminger <stephen@networkplumber.org>
Date:   Thu Aug 1 22:32:07 2013 -0700

    htb: fix sign extension bug

    [ Upstream commit cbd375567f7e4811b1c721f75ec519828ac6583f ]

    When userspace passes a large priority value
    the assignment of the unsigned value hopt->prio
    to  signed int cl->prio causes cl->prio to become negative and the
    comparison is with TC_HTB_NUMPRIO is always false.

    The result is that HTB crashes by referencing outside
    the array when processing packets. With this patch the large value
    wraps around like other values outside the normal range.

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

    Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
    Acked-by: Eric Dumazet <edumazet@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Merge branch 'cm-10.1-wip' into cm-10.1