Kbuild: copy msm headers

Change-Id: I52f38e2bda6a457bd0792ad9aa4e04de6986452e

Conflicts:
	include/linux/Kbuild
Linux 3.0.84

commit 863c94fa3948619d3e425f9a3c61e6baf72ee666
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Thu Jun 27 10:35:30 2013 -0700

    Linux 3.0.84

commit c77a0bc75e37339dcbd4caf20d5ce2a4e7070740
Author: Anders Hammarquist <iko@iko.pp.se>
Date:   Wed Jun 19 01:45:48 2013 +0200

    USB: serial: ti_usb_3410_5052: new device id for Abbot strip port cable

    commit 35a2fbc941accd0e9f1bfadd669311786118d874 upstream.

    Add product id for Abbott strip port cable for Precision meter which
    uses the TI 3410 chip.

    Signed-off-by: Anders Hammarquist <iko@iko.pp.se>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 60ab7833a93b180b420a18e24e88e3a9528a7038
Author: Guillaume Nault <g.nault@alphalink.fr>
Date:   Wed Jun 12 16:07:36 2013 +0200

    l2tp: Fix sendmsg() return value

    [ Upstream commit a6f79d0f26704214b5b702bbac525cb72997f984 ]

    PPPoL2TP sockets should comply with the standard send*() return values
    (i.e. return number of bytes sent instead of 0 upon success).

    Signed-off-by: Guillaume Nault <g.nault@alphalink.fr>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6e092615d27d7036832c18f1c14b691c6c1cbb1d
Author: Guillaume Nault <g.nault@alphalink.fr>
Date:   Wed Jun 12 16:07:23 2013 +0200

    l2tp: Fix PPP header erasure and memory leak

    [ Upstream commit 55b92b7a11690bc377b5d373872a6b650ae88e64 ]

    Copy user data after PPP framing header. This prevents erasure of the
    added PPP header and avoids leaking two bytes of uninitialised memory
    at the end of skb's data buffer.

    Signed-off-by: Guillaume Nault <g.nault@alphalink.fr>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b4d45a2af9c9ca5c14e00375366125e7c31d5293
Author: Daniel Borkmann <dborkman@redhat.com>
Date:   Wed Jun 12 16:02:27 2013 +0200

    packet: packet_getname_spkt: make sure string is always 0-terminated

    [ Upstream commit 2dc85bf323515e59e15dfa858d1472bb25cad0fe ]

    uaddr->sa_data is exactly of size 14, which is hard-coded here and
    passed as a size argument to strncpy(). A device name can be of size
    IFNAMSIZ (== 16), meaning we might leave the destination string
    unterminated. Thus, use strlcpy() and also sizeof() while we're
    at it. We need to memset the data area beforehand, since strlcpy
    does not padd the remaining buffer with zeroes for user space, so
    that we do not possibly leak anything.

    Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit bba0c7f5421c40314ef48be4a7540efa76166dcd
Author: Daniel Borkmann <dborkman@redhat.com>
Date:   Thu Jun 6 15:53:47 2013 +0200

    net: sctp: fix NULL pointer dereference in socket destruction

    [ Upstream commit 1abd165ed757db1afdefaac0a4bc8a70f97d258c ]

    While stress testing sctp sockets, I hit the following panic:

    BUG: unable to handle kernel NULL pointer dereference at 0000000000000020
    IP: [<ffffffffa0490c4e>] sctp_endpoint_free+0xe/0x40 [sctp]
    PGD 7cead067 PUD 7ce76067 PMD 0
    Oops: 0000 [#1] SMP
    Modules linked in: sctp(F) libcrc32c(F) [...]
    CPU: 7 PID: 2950 Comm: acc Tainted: GF            3.10.0-rc2+ #1
    Hardware name: Dell Inc. PowerEdge T410/0H19HD, BIOS 1.6.3 02/01/2011
    task: ffff88007ce0e0c0 ti: ffff88007b568000 task.ti: ffff88007b568000
    RIP: 0010:[<ffffffffa0490c4e>]  [<ffffffffa0490c4e>] sctp_endpoint_free+0xe/0x40 [sctp]
    RSP: 0018:ffff88007b569e08  EFLAGS: 00010292
    RAX: 0000000000000000 RBX: ffff88007db78a00 RCX: dead000000200200
    RDX: ffffffffa049fdb0 RSI: ffff8800379baf38 RDI: 0000000000000000
    RBP: ffff88007b569e18 R08: ffff88007c230da0 R09: 0000000000000001
    R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000
    R13: ffff880077990d00 R14: 0000000000000084 R15: ffff88007db78a00
    FS:  00007fc18ab61700(0000) GS:ffff88007fc60000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
    CR2: 0000000000000020 CR3: 000000007cf9d000 CR4: 00000000000007e0
    DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
    Stack:
     ffff88007b569e38 ffff88007db78a00 ffff88007b569e38 ffffffffa049fded
     ffffffff81abf0c0 ffff88007db78a00 ffff88007b569e58 ffffffff8145b60e
     0000000000000000 0000000000000000 ffff88007b569eb8 ffffffff814df36e
    Call Trace:
     [<ffffffffa049fded>] sctp_destroy_sock+0x3d/0x80 [sctp]
     [<ffffffff8145b60e>] sk_common_release+0x1e/0xf0
     [<ffffffff814df36e>] inet_create+0x2ae/0x350
     [<ffffffff81455a6f>] __sock_create+0x11f/0x240
     [<ffffffff81455bf0>] sock_create+0x30/0x40
     [<ffffffff8145696c>] SyS_socket+0x4c/0xc0
     [<ffffffff815403be>] ? do_page_fault+0xe/0x10
     [<ffffffff8153cb32>] ? page_fault+0x22/0x30
     [<ffffffff81544e02>] system_call_fastpath+0x16/0x1b
    Code: 0c c9 c3 66 2e 0f 1f 84 00 00 00 00 00 e8 fb fe ff ff c9 c3 66 0f
          1f 84 00 00 00 00 00 55 48 89 e5 53 48 83 ec 08 66 66 66 66 90 <48>
          8b 47 20 48 89 fb c6 47 1c 01 c6 40 12 07 e8 9e 68 01 00 48
    RIP  [<ffffffffa0490c4e>] sctp_endpoint_free+0xe/0x40 [sctp]
     RSP <ffff88007b569e08>
    CR2: 0000000000000020
    ---[ end trace e0d71ec1108c1dd9 ]---

    I did not hit this with the lksctp-tools functional tests, but with a
    small, multi-threaded test program, that heavily allocates, binds,
    listens and waits in accept on sctp sockets, and then randomly kills
    some of them (no need for an actual client in this case to hit this).
    Then, again, allocating, binding, etc, and then killing child processes.

    This panic then only occurs when ``echo 1 > /proc/sys/net/sctp/auth_enable''
    is set. The cause for that is actually very simple: in sctp_endpoint_init()
    we enter the path of sctp_auth_init_hmacs(). There, we try to allocate
    our crypto transforms through crypto_alloc_hash(). In our scenario,
    it then can happen that crypto_alloc_hash() fails with -EINTR from
    crypto_larval_wait(), thus we bail out and release the socket via
    sk_common_release(), sctp_destroy_sock() and hit the NULL pointer
    dereference as soon as we try to access members in the endpoint during
    sctp_endpoint_free(), since endpoint at that time is still NULL. Now,
    if we have that case, we do not need to do any cleanup work and just
    leave the destruction handler.

    Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
    Acked-by: Neil Horman <nhorman@tuxdriver.com>
    Acked-by: Vlad Yasevich <vyasevich@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0e7d0e50a7502671ff7deed63595ed2d20ac1e8c
Author: Gao feng <gaofeng@cn.fujitsu.com>
Date:   Sun Jun 2 22:16:21 2013 +0000

    ipv6: assign rt6_info to inet6_ifaddr in init_loopback

    [ Upstream commit 534c877928a16ae5f9776436a497109639bf67dc ]

    Commit 25fb6ca4ed9cad72f14f61629b68dc03c0d9713f
    "net IPv6 : Fix broken IPv6 routing table after loopback down-up"
    forgot to assign rt6_info to the inet6_ifaddr.
    When disable the net device, the rt6_info which allocated
    in init_loopback will not be destroied in __ipv6_ifa_notify.

    This will trigger the waring message below
    [23527.916091] unregister_netdevice: waiting for tap0 to become free. Usage count = 1

    Reported-by: Arkadiusz Miskiewicz <a.miskiewicz@gmail.com>
    Signed-off-by: Gao feng <gaofeng@cn.fujitsu.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 64274c35beebe1be22650a9353c0c33a7b8b723c
Author: Eric Dumazet <eric.dumazet@gmail.com>
Date:   Wed May 29 09:06:27 2013 +0000

    net: force a reload of first item in hlist_nulls_for_each_entry_rcu

    [ Upstream commit c87a124a5d5e8cf8e21c4363c3372bcaf53ea190 ]

    Roman Gushchin discovered that udp4_lib_lookup2() was not reloading
    first item in the rcu protected list, in case the loop was restarted.

    This produced soft lockups as in https://lkml.org/lkml/2013/4/16/37

    rcu_dereference(X)/ACCESS_ONCE(X) seem to not work as intended if X is
    ptr->field :

    In some cases, gcc caches the value or ptr->field in a register.

    Use a barrier() to disallow such caching, as documented in
    Documentation/atomic_ops.txt line 114

    Thanks a lot to Roman for providing analysis and numerous patches.

    Diagnosed-by: Roman Gushchin <klamm@yandex-team.ru>
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Reported-by: Boris Zhmurov <zhmurov@yandex-team.ru>
    Signed-off-by: Roman Gushchin <klamm@yandex-team.ru>
    Acked-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e1b796f9408a33d18709e9fdbf18ce91dfede962
Author: Andy Lutomirski <luto@amacapital.net>
Date:   Wed May 22 14:07:44 2013 -0700

    net: Block MSG_CMSG_COMPAT in send(m)msg and recv(m)msg

    [ Upstream commits 1be374a0518a288147c6a7398792583200a67261 and
      a7526eb5d06b0084ef12d7b168d008fcf516caab ]

    MSG_CMSG_COMPAT is (AFAIK) not intended to be part of the API --
    it's a hack that steals a bit to indicate to other networking code
    that a compat entry was used.  So don't allow it from a non-compat
    syscall.

    This prevents an oops when running this code:

    int main()
    {
        int s;
        struct sockaddr_in addr;
        struct msghdr *hdr;

        char *highpage = mmap((void*)(TASK_SIZE_MAX - 4096), 4096,
                              PROT_READ | PROT_WRITE,
                              MAP_PRIVATE | MAP_ANONYMOUS | MAP_FIXED, -1, 0);
        if (highpage == MAP_FAILED)
            err(1, "mmap");

        s = socket(AF_INET, SOCK_DGRAM, IPPROTO_UDP);
        if (s == -1)
            err(1, "socket");

            addr.sin_family = AF_INET;
            addr.sin_port = htons(1);
            addr.sin_addr.s_addr = htonl(INADDR_LOOPBACK);
        if (connect(s, (struct sockaddr*)&addr, sizeof(addr)) != 0)
            err(1, "connect");

        void *evil = highpage + 4096 - COMPAT_MSGHDR_SIZE;
        printf("Evil address is %p\n", evil);

        if (syscall(__NR_sendmmsg, s, evil, 1, MSG_CMSG_COMPAT) < 0)
            err(1, "sendmmsg");

        return 0;
    }

    Cc: David S. Miller <davem@davemloft.net>
    Signed-off-by: Andy Lutomirski <luto@amacapital.net>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 34e4c0aed353934a72809784999900fc7b5653ef
Author: Eric Dumazet <edumazet@google.com>
Date:   Fri May 24 05:49:58 2013 +0000

    ip_tunnel: fix kernel panic with icmp_dest_unreach

    [ Upstream commit a622260254ee481747cceaaa8609985b29a31565 ]

    Daniel Petre reported crashes in icmp_dst_unreach() with following call
    graph:

    Daniel found a similar problem mentioned in
     http://lkml.indiana.edu/hypermail/linux/kernel/1007.0/00961.html

    And indeed this is the root cause : skb->cb[] contains data fooling IP
    stack.

    We must clear IPCB in ip_tunnel_xmit() sooner in case dst_link_failure()
    is called. Or else skb->cb[] might contain garbage from GSO segmentation
    layer.

    A similar fix was tested on linux-3.9, but gre code was refactored in
    linux-3.10. I'll send patches for stable kernels as well.

    Many thanks to Daniel for providing reports, patches and testing !

    Reported-by: Daniel Petre <daniel.petre@rcs-rds.ro>
    Signed-off-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 04e093d128963bfe46f50dbcff4c70147464fd0a
Author: Eric Dumazet <edumazet@google.com>
Date:   Thu May 23 07:44:20 2013 +0000

    tcp: xps: fix reordering issues

    [ Upstream commit 547669d483e5783d722772af1483fa474da7caf9 ]

    commit 3853b5841c01a ("xps: Improvements in TX queue selection")
    introduced ooo_okay flag, but the condition to set it is slightly wrong.

    In our traces, we have seen ACK packets being received out of order,
    and RST packets sent in response.

    We should test if we have any packets still in host queue.

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

commit 54ba13b9018c810664923626be5b22d220a955e8
Author: Paul Moore <pmoore@redhat.com>
Date:   Fri May 17 09:08:50 2013 +0000

    netlabel: improve domain mapping validation

    [ Upstream commit 6b21e1b77d1a3d58ebfd513264c885695e8a0ba5 ]

    The net/netlabel/netlabel_domainhash.c:netlbl_domhsh_add() function
    does not properly validate new domain hash entries resulting in
    potential problems when an administrator attempts to add an invalid
    entry.  One such problem, as reported by Vlad Halilov, is a kernel
    BUG (found in netlabel_domainhash.c:netlbl_domhsh_audit_add()) when
    adding an IPv6 outbound mapping with a CIPSO configuration.

    This patch corrects this problem by adding the necessary validation
    code to netlbl_domhsh_add() via the newly created
    netlbl_domhsh_validate() function.

    Ideally this patch should also be pushed to the currently active
    -stable trees.

    Reported-by: Vlad Halilov <vlad.halilov@gmail.com>
    Signed-off-by: Paul Moore <pmoore@redhat.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8410e49bf36d9adf4aba8a5cb8e1540da6aec862
Author: Eric Dumazet <edumazet@google.com>
Date:   Fri May 17 04:53:13 2013 +0000

    ipv6: fix possible crashes in ip6_cork_release()

    [ Upstream commit 284041ef21fdf2e0d216ab6b787bc9072b4eb58a ]

    commit 0178b695fd6b4 ("ipv6: Copy cork options in ip6_append_data")
    added some code duplication and bad error recovery, leading to potential
    crash in ip6_cork_release() as kfree() could be called with garbage.

    use kzalloc() to make sure this wont happen.

    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Cc: Herbert Xu <herbert@gondor.apana.org.au>
    Cc: Hideaki YOSHIFUJI <yoshfuji@linux-ipv6.org>
    Cc: Neal Cardwell <ncardwell@google.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit cc56da01f9325fd72ebf4d759b8333020bdc5f6c
Author: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
Date:   Thu May 16 22:25:34 2013 +0000

    gianfar: add missing iounmap() on error in gianfar_ptp_probe()

    [ Upstream commit e5f5e380e0f3bb11f04ca5bc66a551e58e0ad26e ]

    Add the missing iounmap() before return from gianfar_ptp_probe()
    in the error handling case.

    Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 41a187532a9458873a603aee48f017c0288d03fe
Author: Eric Dumazet <edumazet@google.com>
Date:   Mon May 13 21:25:52 2013 +0000

    tcp: fix tcp_md5_hash_skb_data()

    [ Upstream commit 54d27fcb338bd9c42d1dfc5a39e18f6f9d373c2e ]

    TCP md5 communications fail [1] for some devices, because sg/crypto code
    assume page offsets are below PAGE_SIZE.

    This was discovered using mlx4 driver [2], but I suspect loopback
    might trigger the same bug now we use order-3 pages in tcp_sendmsg()

    [1] Failure is giving following messages.

    huh, entered softirq 3 NET_RX ffffffff806ad230 preempt_count 00000100,
    exited with 00000101?

    [2] mlx4 driver uses order-2 pages to allocate RX frags

    Reported-by: Matt Schnall <mischnal@google.com>
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Cc: Bernhard Beck <bbeck@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1819a873d94cd7abeb94f235175052f72fe6fa2c
Author: Zhanghaoyu (A) <haoyu.zhang@huawei.com>
Date:   Fri Jun 14 07:36:13 2013 +0000

    KVM: x86: remove vcpu's CPL check in host-invoked XCR set

    commit 764bcbc5a6d7a2f3e75c9f0e4caa984e2926e346 upstream.

    __kvm_set_xcr function does the CPL check when set xcr. __kvm_set_xcr is
    called in two flows, one is invoked by guest, call stack shown as below,

      handle_xsetbv(or xsetbv_interception)
        kvm_set_xcr
          __kvm_set_xcr

    the other one is invoked by host, for example during system reset:

      kvm_arch_vcpu_ioctl
        kvm_vcpu_ioctl_x86_set_xcrs
          __kvm_set_xcr

    The former does need the CPL check, but the latter does not.

    Signed-off-by: Zhang Haoyu <haoyu.zhang@huawei.com>
    [Tweaks to commit message. - Paolo]
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a0631b300bac987a591ae485d8a19a08aa57b4d2
Author: Chris Metcalf <cmetcalf@tilera.com>
Date:   Sat Jun 15 16:47:47 2013 -0400

    tilepro: work around module link error with gcc 4.7

    commit 3cb3f839d306443f3d1e79b0bde1a2ad2c12b555 upstream.

    gcc 4.7.x is emitting calls to __ffsdi2 where previously
    it used to inline the appropriate ctz instructions.
    While this needs to be fixed in gcc, it's also easy to avoid
    having it cause build failures when building with those
    compilers by exporting __ffsdi2 to modules.

    Signed-off-by: Chris Metcalf <cmetcalf@tilera.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 68af5a0e5cdb5e5c9ae53af4eb6e5ab8dbdd9cb4
Author: Clemens Ladisch <clemens@ladisch.de>
Date:   Sat Jun 15 11:21:09 2013 +0200

    ALSA: usb-audio: work around Android accessory firmware bug

    commit 342cda29343a6272c630f94ed56810a76740251b upstream.

    When the Android firmware enables the audio interfaces in accessory
    mode, it always declares in the control interface's baInterfaceNr array
    that interfaces 0 and 1 belong to the audio function.  However, the
    accessory interface itself, if also enabled, already is at index 0 and
    shifts the actual audio interface numbers to 1 and 2, which prevents the
    PCM streaming interface from being seen by the host driver.

    To get the PCM interface interface to work, detect when the descriptors
    point to the (for this driver useless) accessory interface, and redirect
    to the correct one.

    Reported-by: Jeremy Rosen <jeremy.rosen@openwide.fr>
    Tested-by: Jeremy Rosen <jeremy.rosen@openwide.fr>
    Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
config: use smartassv2 as default cpu gov
ipv6: introdcue __ipv6_addr_needs_scope_id and ipv6_iface_scope_id helper functions

[net-next commit b7ef213ef65256168df83ddfbb8131ed9adc10f9]

__ipv6_addr_needs_scope_id checks if an ipv6 address needs to supply
a 'sin6_scope_id != 0'. 'sin6_scope_id != 0' was enforced in case
of link-local addresses. To support interface-local multicast these
checks had to be enhanced and are now consolidated into these new helper
functions.

v2:
a) migrated to struct ipv6_addr_props

v3:
a) reverted changes for ipv6_addr_props
b) test for address type instead of comparing scope

v4:
a) unchanged

Change-Id: Id6fc54cec61f967928e08a9eba4f857157d973a3
Suggested-by: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
Cc: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
Acked-by: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
Acked-by: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
net: ipv6: Add IPv6 support to the ping socket.

[backport of net-next 6d0bfe22611602f36617bc7aa2ffa1bbb2f54c67]

This adds the ability to send ICMPv6 echo requests without a
raw socket. The equivalent ability for ICMPv4 was added in
2011.

Instead of having separate code paths for IPv4 and IPv6, make
most of the code in net/ipv4/ping.c dual-stack and only add a
few IPv6-specific bits (like the protocol definition) to a new
net/ipv6/ping.c. Hopefully this will reduce divergence and/or
duplication of bugs in the future.

Caveats:

- Setting options via ancillary data (e.g., using IPV6_PKTINFO
  to specify the outgoing interface) is not yet supported.
- There are no separate security settings for IPv4 and IPv6;
  everything is controlled by /proc/net/ipv4/ping_group_range.
- The proc interface does not yet display IPv6 ping sockets
  properly.

Tested with a patched copy of ping6 and using raw socket calls.
Compiles and works with all of CONFIG_IPV6={n,m,y}.

Change-Id: Ia359af556021344fc7f890c21383aadf950b6498
Signed-off-by: Lorenzo Colitti <lorenzo@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
[lorenzo@google.com: backported to 3.0]
Signed-off-by: Lorenzo Colitti <lorenzo@google.com>
ping: always initialize ->sin6_scope_id and ->sin6_flowinfo

[net-next commit c26d6b46da3ee86fa8a864347331e5513ca84c2b]

If we don't need scope id, we should initialize it to zero.
Same for ->sin6_flowinfo.

Change-Id: I28e4bc9593e76fc3434052182466fab4bb8ccf3a
Cc: Lorenzo Colitti <lorenzo@google.com>
Cc: David S. Miller <davem@davemloft.net>
Signed-off-by: Cong Wang <amwang@redhat.com>
Acked-by: Lorenzo Colitti <lorenzo@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
vfs: optimize inode cache access patterns

The inode structure layout is largely random, and some of the vfs paths
really do care.  The path lookup in particular is already quite D$
intensive, and profiles show that accessing the 'inode->i_op->xyz'
fields is quite costly.

We already optimized the dcache to not unnecessarily load the d_op
structure for members that are often NULL using the DCACHE_OP_xyz bits
in dentry->d_flags, and this does something very similar for the inode
ops that are used during pathname lookup.

It also re-orders the fields so that the fields accessed by 'stat' are
together at the beginning of the inode structure, and roughly in the
order accessed.

The effect of this seems to be in the 1-2% range for an empty kernel
"make -j" run (which is fairly kernel-intensive, mostly in filename
lookup), so it's visible.  The numbers are fairly noisy, though, and
likely depend a lot on exact microarchitecture.  So there's more tuning
to be done.

Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Bluetooth: Fix crash in l2cap_build_cmd() with small MTU

commit 300b962e5244a1ea010df7e88595faa0085b461d upstream.

If a too small MTU value is set with ioctl(HCISETACLMTU) or by a bogus
controller, memory corruption happens due to a memcpy() call with
negative length.

Fix this crash on either incoming or outgoing connections with a MTU
smaller than L2CAP_HDR_SIZE + L2CAP_CMD_HDR_SIZE:

[   46.885433] BUG: unable to handle kernel paging request at f56ad000
[   46.888037] IP: [<c03d94cd>] memcpy+0x1d/0x40
[   46.888037] *pdpt = 0000000000ac3001 *pde = 00000000373f8067 *pte = 80000000356ad060
[   46.888037] Oops: 0002 [#1] SMP DEBUG_PAGEALLOC
[   46.888037] Modules linked in: hci_vhci bluetooth virtio_balloon i2c_piix4 uhci_hcd usbcore usb_common
[   46.888037] CPU: 0 PID: 1044 Comm: kworker/u3:0 Not tainted 3.10.0-rc1+ #12
[   46.888037] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2007
[   46.888037] Workqueue: hci0 hci_rx_work [bluetooth]
[   46.888037] task: f59b15b0 ti: f55c4000 task.ti: f55c4000
[   46.888037] EIP: 0060:[<c03d94cd>] EFLAGS: 00010212 CPU: 0
[   46.888037] EIP is at memcpy+0x1d/0x40
[   46.888037] EAX: f56ac1c0 EBX: fffffff8 ECX: 3ffffc6e EDX: f55c5cf2
[   46.888037] ESI: f55c6b32 EDI: f56ad000 EBP: f55c5c68 ESP: f55c5c5c
[   46.888037]  DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
[   46.888037] CR0: 8005003b CR2: f56ad000 CR3: 3557d000 CR4: 000006f0
[   46.888037] DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000
[   46.888037] DR6: ffff0ff0 DR7: 00000400
[   46.888037] Stack:
[   46.888037]  fffffff8 00000010 00000003 f55c5cac f8c6a54c ffffffff f8c69eb2 00000000
[   46.888037]  f4783cdc f57f0070 f759c590 1001c580 00000003 0200000a 00000000 f5a88560
[   46.888037]  f5ba2600 f5a88560 00000041 00000000 f55c5d90 f8c6f4c7 00000008 f55c5cf2
[   46.888037] Call Trace:
[   46.888037]  [<f8c6a54c>] l2cap_send_cmd+0x1cc/0x230 [bluetooth]
[   46.888037]  [<f8c69eb2>] ? l2cap_global_chan_by_psm+0x152/0x1a0 [bluetooth]
[   46.888037]  [<f8c6f4c7>] l2cap_connect+0x3f7/0x540 [bluetooth]
[   46.888037]  [<c019b37b>] ? trace_hardirqs_off+0xb/0x10
[   46.888037]  [<c01a0ff8>] ? mark_held_locks+0x68/0x110
[   46.888037]  [<c064ad20>] ? mutex_lock_nested+0x280/0x360
[   46.888037]  [<c064b9d9>] ? __mutex_unlock_slowpath+0xa9/0x150
[   46.888037]  [<c01a118c>] ? trace_hardirqs_on_caller+0xec/0x1b0
[   46.888037]  [<c064ad08>] ? mutex_lock_nested+0x268/0x360
[   46.888037]  [<c01a125b>] ? trace_hardirqs_on+0xb/0x10
[   46.888037]  [<f8c72f8d>] l2cap_recv_frame+0xb2d/0x1d30 [bluetooth]
[   46.888037]  [<c01a0ff8>] ? mark_held_locks+0x68/0x110
[   46.888037]  [<c064b9d9>] ? __mutex_unlock_slowpath+0xa9/0x150
[   46.888037]  [<c01a118c>] ? trace_hardirqs_on_caller+0xec/0x1b0
[   46.888037]  [<f8c754f1>] l2cap_recv_acldata+0x2a1/0x320 [bluetooth]
[   46.888037]  [<f8c491d8>] hci_rx_work+0x518/0x810 [bluetooth]
[   46.888037]  [<f8c48df2>] ? hci_rx_work+0x132/0x810 [bluetooth]
[   46.888037]  [<c0158979>] process_one_work+0x1a9/0x600
[   46.888037]  [<c01588fb>] ? process_one_work+0x12b/0x600
[   46.888037]  [<c015922e>] ? worker_thread+0x19e/0x320
[   46.888037]  [<c015922e>] ? worker_thread+0x19e/0x320
[   46.888037]  [<c0159187>] worker_thread+0xf7/0x320
[   46.888037]  [<c0159090>] ? rescuer_thread+0x290/0x290
[   46.888037]  [<c01602f8>] kthread+0xa8/0xb0
[   46.888037]  [<c0656777>] ret_from_kernel_thread+0x1b/0x28
[   46.888037]  [<c0160250>] ? flush_kthread_worker+0x120/0x120
[   46.888037] Code: c3 90 8d 74 26 00 e8 63 fc ff ff eb e8 90 55 89 e5 83 ec 0c 89 5d f4 89 75 f8 89 7d fc 3e 8d 74 26 00 89 cb 89 c7 c1 e9 02 89 d6 <f3> a5 89 d9 83 e1 03 74 02 f3 a4 8b 5d f4 8b 75 f8 8b 7d fc 89
[   46.888037] EIP: [<c03d94cd>] memcpy+0x1d/0x40 SS:ESP 0068:f55c5c5c
[   46.888037] CR2: 00000000f56ad000
[   46.888037] ---[ end trace 0217c1f4d78714a9 ]---

Signed-off-by: Anderson Lizardo <anderson.lizardo@openbossa.org>
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
hw_breakpoint: Use cpu_possible_mask in {reserve,release}_bp_slot()

commit c790b0ad23f427c7522ffed264706238c57c007e upstream.

fetch_bp_busy_slots() and toggle_bp_slot() use
for_each_online_cpu(), this is obviously wrong wrt cpu_up() or
cpu_down(), we can over/under account the per-cpu numbers.

For example:

	# echo 0 >> /sys/devices/system/cpu/cpu1/online
	# perf record -e mem:0x10 -p 1 &
	# echo 1 >> /sys/devices/system/cpu/cpu1/online
	# perf record -e mem:0x10,mem:0x10,mem:0x10,mem:0x10 -C1 -a &
	# taskset -p 0x2 1

triggers the same WARN_ONCE("Can't find any breakpoint slot") in
arch_install_hw_breakpoint().

Reported-by: Vince Weaver <vincent.weaver@maine.edu>
Signed-off-by: Oleg Nesterov <oleg@redhat.com>
Acked-by: Frederic Weisbecker <fweisbec@gmail.com>
Link: http://lkml.kernel.org/r/20130620155009.GA6327@redhat.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
dlci: acquire rtnl_lock before calling __dev_get_by_name()

commit 11eb2645cbf38a08ae491bf6c602eea900ec0bb5 upstream.

Otherwise the net device returned can be freed at anytime.

Signed-off-by: Li Zefan <lizefan@huawei.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
dlci: validate the net device in dlci_del()

commit 578a1310f2592ba90c5674bca21c1dbd1adf3f0a upstream.

We triggered an oops while running trinity with 3.4 kernel:

BUG: unable to handle kernel paging request at 0000000100000d07
IP: [<ffffffffa0109738>] dlci_ioctl+0xd8/0x2d4 [dlci]
PGD 640c0d067 PUD 0
Oops: 0000 [#1] PREEMPT SMP
CPU 3
...
Pid: 7302, comm: trinity-child3 Not tainted 3.4.24.09+ 40 Huawei Technologies Co., Ltd. Tecal RH2285          /BC11BTSA
RIP: 0010:[<ffffffffa0109738>]  [<ffffffffa0109738>] dlci_ioctl+0xd8/0x2d4 [dlci]
...
Call Trace:
  [<ffffffff8137c5c3>] sock_ioctl+0x153/0x280
  [<ffffffff81195494>] do_vfs_ioctl+0xa4/0x5e0
  [<ffffffff8118354a>] ? fget_light+0x3ea/0x490
  [<ffffffff81195a1f>] sys_ioctl+0x4f/0x80
  [<ffffffff81478b69>] system_call_fastpath+0x16/0x1b
...

It's because the net device is not a dlci device.

Reported-by: Li Jinyue <lijinyue@huawei.com>
Signed-off-by: Li Zefan <lizefan@huawei.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
perf: Disable monitoring on setuid processes for regular users

commit 2976b10f05bd7f6dab9f9e7524451ddfed656a89 upstream.

There was a a bug in setup_new_exec(), whereby
the test to disabled perf monitoring was not
correct because the new credentials for the
process were not yet committed and therefore
the get_dumpable() test was never firing.

The patch fixes the problem by moving the
perf_event test until after the credentials
are committed.

Signed-off-by: Stephane Eranian <eranian@google.com>
Tested-by: Jiri Olsa <jolsa@redhat.com>
Acked-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
UBIFS: prepare to fix a horrid bug

commit 33f1a63ae84dfd9ad298cf275b8f1887043ced36 upstream.

Al Viro pointed me to the fact that '->readdir()' and '->llseek()' have no
mutual exclusion, which means the 'ubifs_dir_llseek()' can be run while we are
in the middle of 'ubifs_readdir()'.

First of all, this means that 'file->private_data' can be freed while
'ubifs_readdir()' uses it.  But this particular patch does not fix the problem.
This patch is only a preparation, and the fix will follow next.

In this patch we make 'ubifs_readdir()' stop using 'file->f_pos' directly,
because 'file->f_pos' can be changed by '->llseek()' at any point. This may
lead 'ubifs_readdir()' to returning inconsistent data: directory entry names
may correspond to incorrect file positions.

So here we introduce a local variable 'pos', read 'file->f_pose' once at very
the beginning, and then stick to 'pos'. The result of this is that when
'ubifs_dir_llseek()' changes 'file->f_pos' while we are in the middle of
'ubifs_readdir()', the latter "wins".

Reported-by: Al Viro <viro@zeniv.linux.org.uk>
Tested-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
UBIFS: fix a horrid bug

commit 605c912bb843c024b1ed173dc427cd5c08e5d54d upstream.

Al Viro pointed me to the fact that '->readdir()' and '->llseek()' have no
mutual exclusion, which means the 'ubifs_dir_llseek()' can be run while we are
in the middle of 'ubifs_readdir()'.

This means that 'file->private_data' can be freed while 'ubifs_readdir()' uses
it, and this is a very bad bug: not only 'ubifs_readdir()' can return garbage,
but this may corrupt memory and lead to all kinds of problems like crashes an
security holes.

This patch fixes the problem by using the 'file->f_version' field, which
'->llseek()' always unconditionally sets to zero. We set it to 1 in
'ubifs_readdir()' and whenever we detect that it became 0, we know there was a
seek and it is time to clear the state saved in 'file->private_data'.

I tested this patch by writing a user-space program which runds readdir and
seek in parallell. I could easily crash the kernel without these patches, but
could not crash it with these patches.

Reported-by: Al Viro <viro@zeniv.linux.org.uk>
Tested-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
pch_uart: fix a deadlock when pch_uart as console

commit 384e301e3519599b000c1a2ecd938b533fc15d85 upstream.

When we use pch_uart as system console like 'console=ttyPCH0,115200',
then 'send break' to it. We'll encounter the deadlock on a cpu/core,
with interrupts disabled on the core. When we happen to have all irqs
affinity to cpu0 then the deadlock on cpu0 actually deadlock whole
system.

In pch_uart_interrupt, we have spin_lock_irqsave(&priv->lock, flags)
then call pch_uart_err_ir when break is received. Then the call to
dev_err would actually call to pch_console_write then we'll run into
another spin_lock(&priv->lock), with interrupts disabled.

So in the call sequence lead by pch_uart_interrupt, we should be
carefully to call functions that will 'print message to console' only
in case the uart port is not being used as serial console.

Signed-off-by: Liang Li <liang.li@windriver.com>
Cc: Yijing Wang <wangyijing@huawei.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Linux 3.0.85
include: don't export msm_audio_aac.h

Change-Id: I77fb60d359ca311f935c318a5f6ec0aee464798c
drivers: remove some dsi changes from msm lcdc
Merge branch 'cm-10.1-wip' of git://github.com/Mustaavalkosta/htc7x30-3.0 into rs-dev

Conflicts:
	arch/arm/configs/spade-perf_defconfig
	arch/arm/configs/spade_defconfig
Linux 3.0.85

commit 2d0ed86595ca3a101c710efaec7aab0ca69c76da
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Wed Jul 3 11:03:56 2013 -0700

    Linux 3.0.85

commit db61e4ec623437237d05b5ab8ce97d9377682de2
Author: Liang Li <liang.li@windriver.com>
Date:   Sat Jan 19 17:52:10 2013 +0800

    pch_uart: fix a deadlock when pch_uart as console

    commit 384e301e3519599b000c1a2ecd938b533fc15d85 upstream.

    When we use pch_uart as system console like 'console=ttyPCH0,115200',
    then 'send break' to it. We'll encounter the deadlock on a cpu/core,
    with interrupts disabled on the core. When we happen to have all irqs
    affinity to cpu0 then the deadlock on cpu0 actually deadlock whole
    system.

    In pch_uart_interrupt, we have spin_lock_irqsave(&priv->lock, flags)
    then call pch_uart_err_ir when break is received. Then the call to
    dev_err would actually call to pch_console_write then we'll run into
    another spin_lock(&priv->lock), with interrupts disabled.

    So in the call sequence lead by pch_uart_interrupt, we should be
    carefully to call functions that will 'print message to console' only
    in case the uart port is not being used as serial console.

    Signed-off-by: Liang Li <liang.li@windriver.com>
    Cc: Yijing Wang <wangyijing@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c6c46477761504a89d5c68331f3b86fe31b51338
Author: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
Date:   Fri Jun 28 14:15:15 2013 +0300

    UBIFS: fix a horrid bug

    commit 605c912bb843c024b1ed173dc427cd5c08e5d54d upstream.

    Al Viro pointed me to the fact that '->readdir()' and '->llseek()' have no
    mutual exclusion, which means the 'ubifs_dir_llseek()' can be run while we are
    in the middle of 'ubifs_readdir()'.

    This means that 'file->private_data' can be freed while 'ubifs_readdir()' uses
    it, and this is a very bad bug: not only 'ubifs_readdir()' can return garbage,
    but this may corrupt memory and lead to all kinds of problems like crashes an
    security holes.

    This patch fixes the problem by using the 'file->f_version' field, which
    '->llseek()' always unconditionally sets to zero. We set it to 1 in
    'ubifs_readdir()' and whenever we detect that it became 0, we know there was a
    seek and it is time to clear the state saved in 'file->private_data'.

    I tested this patch by writing a user-space program which runds readdir and
    seek in parallell. I could easily crash the kernel without these patches, but
    could not crash it with these patches.

    Reported-by: Al Viro <viro@zeniv.linux.org.uk>
    Tested-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
    Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1f4f917e5e882de1e701d7b26955884ed16604d5
Author: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
Date:   Fri Jun 28 14:15:14 2013 +0300

    UBIFS: prepare to fix a horrid bug

    commit 33f1a63ae84dfd9ad298cf275b8f1887043ced36 upstream.

    Al Viro pointed me to the fact that '->readdir()' and '->llseek()' have no
    mutual exclusion, which means the 'ubifs_dir_llseek()' can be run while we are
    in the middle of 'ubifs_readdir()'.

    First of all, this means that 'file->private_data' can be freed while
    'ubifs_readdir()' uses it.  But this particular patch does not fix the problem.
    This patch is only a preparation, and the fix will follow next.

    In this patch we make 'ubifs_readdir()' stop using 'file->f_pos' directly,
    because 'file->f_pos' can be changed by '->llseek()' at any point. This may
    lead 'ubifs_readdir()' to returning inconsistent data: directory entry names
    may correspond to incorrect file positions.

    So here we introduce a local variable 'pos', read 'file->f_pose' once at very
    the beginning, and then stick to 'pos'. The result of this is that when
    'ubifs_dir_llseek()' changes 'file->f_pos' while we are in the middle of
    'ubifs_readdir()', the latter "wins".

    Reported-by: Al Viro <viro@zeniv.linux.org.uk>
    Tested-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
    Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5d28835c59b02d4389003bbfa7c4276375f39ed6
Author: Stephane Eranian <eranian@google.com>
Date:   Thu Jun 20 11:36:28 2013 +0200

    perf: Disable monitoring on setuid processes for regular users

    commit 2976b10f05bd7f6dab9f9e7524451ddfed656a89 upstream.

    There was a a bug in setup_new_exec(), whereby
    the test to disabled perf monitoring was not
    correct because the new credentials for the
    process were not yet committed and therefore
    the get_dumpable() test was never firing.

    The patch fixes the problem by moving the
    perf_event test until after the credentials
    are committed.

    Signed-off-by: Stephane Eranian <eranian@google.com>
    Tested-by: Jiri Olsa <jolsa@redhat.com>
    Acked-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 806f529730af538c2edbb805589c48cc19ad169b
Author: Zefan Li <lizefan@huawei.com>
Date:   Wed Jun 26 15:31:58 2013 +0800

    dlci: validate the net device in dlci_del()

    commit 578a1310f2592ba90c5674bca21c1dbd1adf3f0a upstream.

    We triggered an oops while running trinity with 3.4 kernel:

    BUG: unable to handle kernel paging request at 0000000100000d07
    IP: [<ffffffffa0109738>] dlci_ioctl+0xd8/0x2d4 [dlci]
    PGD 640c0d067 PUD 0
    Oops: 0000 [#1] PREEMPT SMP
    CPU 3
    ...
    Pid: 7302, comm: trinity-child3 Not tainted 3.4.24.09+ 40 Huawei Technologies Co., Ltd. Tecal RH2285          /BC11BTSA
    RIP: 0010:[<ffffffffa0109738>]  [<ffffffffa0109738>] dlci_ioctl+0xd8/0x2d4 [dlci]
    ...
    Call Trace:
      [<ffffffff8137c5c3>] sock_ioctl+0x153/0x280
      [<ffffffff81195494>] do_vfs_ioctl+0xa4/0x5e0
      [<ffffffff8118354a>] ? fget_light+0x3ea/0x490
      [<ffffffff81195a1f>] sys_ioctl+0x4f/0x80
      [<ffffffff81478b69>] system_call_fastpath+0x16/0x1b
    ...

    It's because the net device is not a dlci device.

    Reported-by: Li Jinyue <lijinyue@huawei.com>
    Signed-off-by: Li Zefan <lizefan@huawei.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 72ad35befc4715ebb0d715b90f27572ef11a15e2
Author: Zefan Li <lizefan@huawei.com>
Date:   Wed Jun 26 15:29:54 2013 +0800

    dlci: acquire rtnl_lock before calling __dev_get_by_name()

    commit 11eb2645cbf38a08ae491bf6c602eea900ec0bb5 upstream.

    Otherwise the net device returned can be freed at anytime.

    Signed-off-by: Li Zefan <lizefan@huawei.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e2652ea43028e5409c2fd2b585dc8388a6e75bd0
Author: Oleg Nesterov <oleg@redhat.com>
Date:   Thu Jun 20 17:50:09 2013 +0200

    hw_breakpoint: Use cpu_possible_mask in {reserve,release}_bp_slot()

    commit c790b0ad23f427c7522ffed264706238c57c007e upstream.

    fetch_bp_busy_slots() and toggle_bp_slot() use
    for_each_online_cpu(), this is obviously wrong wrt cpu_up() or
    cpu_down(), we can over/under account the per-cpu numbers.

    For example:

        # echo 0 >> /sys/devices/system/cpu/cpu1/online
        # perf record -e mem:0x10 -p 1 &
        # echo 1 >> /sys/devices/system/cpu/cpu1/online
        # perf record -e mem:0x10,mem:0x10,mem:0x10,mem:0x10 -C1 -a &
        # taskset -p 0x2 1

    triggers the same WARN_ONCE("Can't find any breakpoint slot") in
    arch_install_hw_breakpoint().

    Reported-by: Vince Weaver <vincent.weaver@maine.edu>
    Signed-off-by: Oleg Nesterov <oleg@redhat.com>
    Acked-by: Frederic Weisbecker <fweisbec@gmail.com>
    Link: http://lkml.kernel.org/r/20130620155009.GA6327@redhat.com
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3ddc55287a4505a5634643fec8e02f887498ffc8
Author: Anderson Lizardo <anderson.lizardo@openbossa.org>
Date:   Sun Jun 2 16:30:40 2013 -0400

    Bluetooth: Fix crash in l2cap_build_cmd() with small MTU

    commit 300b962e5244a1ea010df7e88595faa0085b461d upstream.

    If a too small MTU value is set with ioctl(HCISETACLMTU) or by a bogus
    controller, memory corruption happens due to a memcpy() call with
    negative length.

    Fix this crash on either incoming or outgoing connections with a MTU
    smaller than L2CAP_HDR_SIZE + L2CAP_CMD_HDR_SIZE:

    [   46.885433] BUG: unable to handle kernel paging request at f56ad000
    [   46.888037] IP: [<c03d94cd>] memcpy+0x1d/0x40
    [   46.888037] *pdpt = 0000000000ac3001 *pde = 00000000373f8067 *pte = 80000000356ad060
    [   46.888037] Oops: 0002 [#1] SMP DEBUG_PAGEALLOC
    [   46.888037] Modules linked in: hci_vhci bluetooth virtio_balloon i2c_piix4 uhci_hcd usbcore usb_common
    [   46.888037] CPU: 0 PID: 1044 Comm: kworker/u3:0 Not tainted 3.10.0-rc1+ #12
    [   46.888037] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2007
    [   46.888037] Workqueue: hci0 hci_rx_work [bluetooth]
    [   46.888037] task: f59b15b0 ti: f55c4000 task.ti: f55c4000
    [   46.888037] EIP: 0060:[<c03d94cd>] EFLAGS: 00010212 CPU: 0
    [   46.888037] EIP is at memcpy+0x1d/0x40
    [   46.888037] EAX: f56ac1c0 EBX: fffffff8 ECX: 3ffffc6e EDX: f55c5cf2
    [   46.888037] ESI: f55c6b32 EDI: f56ad000 EBP: f55c5c68 ESP: f55c5c5c
    [   46.888037]  DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
    [   46.888037] CR0: 8005003b CR2: f56ad000 CR3: 3557d000 CR4: 000006f0
    [   46.888037] DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000
    [   46.888037] DR6: ffff0ff0 DR7: 00000400
    [   46.888037] Stack:
    [   46.888037]  fffffff8 00000010 00000003 f55c5cac f8c6a54c ffffffff f8c69eb2 00000000
    [   46.888037]  f4783cdc f57f0070 f759c590 1001c580 00000003 0200000a 00000000 f5a88560
    [   46.888037]  f5ba2600 f5a88560 00000041 00000000 f55c5d90 f8c6f4c7 00000008 f55c5cf2
    [   46.888037] Call Trace:
    [   46.888037]  [<f8c6a54c>] l2cap_send_cmd+0x1cc/0x230 [bluetooth]
    [   46.888037]  [<f8c69eb2>] ? l2cap_global_chan_by_psm+0x152/0x1a0 [bluetooth]
    [   46.888037]  [<f8c6f4c7>] l2cap_connect+0x3f7/0x540 [bluetooth]
    [   46.888037]  [<c019b37b>] ? trace_hardirqs_off+0xb/0x10
    [   46.888037]  [<c01a0ff8>] ? mark_held_locks+0x68/0x110
    [   46.888037]  [<c064ad20>] ? mutex_lock_nested+0x280/0x360
    [   46.888037]  [<c064b9d9>] ? __mutex_unlock_slowpath+0xa9/0x150
    [   46.888037]  [<c01a118c>] ? trace_hardirqs_on_caller+0xec/0x1b0
    [   46.888037]  [<c064ad08>] ? mutex_lock_nested+0x268/0x360
    [   46.888037]  [<c01a125b>] ? trace_hardirqs_on+0xb/0x10
    [   46.888037]  [<f8c72f8d>] l2cap_recv_frame+0xb2d/0x1d30 [bluetooth]
    [   46.888037]  [<c01a0ff8>] ? mark_held_locks+0x68/0x110
    [   46.888037]  [<c064b9d9>] ? __mutex_unlock_slowpath+0xa9/0x150
    [   46.888037]  [<c01a118c>] ? trace_hardirqs_on_caller+0xec/0x1b0
    [   46.888037]  [<f8c754f1>] l2cap_recv_acldata+0x2a1/0x320 [bluetooth]
    [   46.888037]  [<f8c491d8>] hci_rx_work+0x518/0x810 [bluetooth]
    [   46.888037]  [<f8c48df2>] ? hci_rx_work+0x132/0x810 [bluetooth]
    [   46.888037]  [<c0158979>] process_one_work+0x1a9/0x600
    [   46.888037]  [<c01588fb>] ? process_one_work+0x12b/0x600
    [   46.888037]  [<c015922e>] ? worker_thread+0x19e/0x320
    [   46.888037]  [<c015922e>] ? worker_thread+0x19e/0x320
    [   46.888037]  [<c0159187>] worker_thread+0xf7/0x320
    [   46.888037]  [<c0159090>] ? rescuer_thread+0x290/0x290
    [   46.888037]  [<c01602f8>] kthread+0xa8/0xb0
    [   46.888037]  [<c0656777>] ret_from_kernel_thread+0x1b/0x28
    [   46.888037]  [<c0160250>] ? flush_kthread_worker+0x120/0x120
    [   46.888037] Code: c3 90 8d 74 26 00 e8 63 fc ff ff eb e8 90 55 89 e5 83 ec 0c 89 5d f4 89 75 f8 89 7d fc 3e 8d 74 26 00 89 cb 89 c7 c1 e9 02 89 d6 <f3> a5 89 d9 83 e1 03 74 02 f3 a4 8b 5d f4 8b 75 f8 8b 7d fc 89
    [   46.888037] EIP: [<c03d94cd>] memcpy+0x1d/0x40 SS:ESP 0068:f55c5c5c
    [   46.888037] CR2: 00000000f56ad000
    [   46.888037] ---[ end trace 0217c1f4d78714a9 ]---

    Signed-off-by: Anderson Lizardo <anderson.lizardo@openbossa.org>
    Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>