1. 13 Oct, 2015 1 commit
  2. 11 Oct, 2015 7 commits
  3. 09 Oct, 2015 5 commits
  4. 08 Oct, 2015 6 commits
  5. 07 Oct, 2015 15 commits
  6. 06 Oct, 2015 1 commit
  7. 05 Oct, 2015 5 commits
    • Pravin B Shelar's avatar
      openvswitch: Fix ovs_vport_get_stats() · 83ffe99f
      Pravin B Shelar authored
      Not every device has dev->tstats set. So when OVS tries to calculate
      vport stats it causes kernel panic. Following patch fixes it by
      using standard API to get net-device stats.
      
      ---8<---
      Unable to handle kernel paging request at virtual address 766b4008
      Internal error: Oops: 96000005 [#1] PREEMPT SMP
      Modules linked in: vport_vxlan vxlan ip6_udp_tunnel udp_tunnel tun bridge stp llc openvswitch ipv6
      CPU: 7 PID: 1108 Comm: ovs-vswitchd Not tainted 4.3.0-rc3+ #82
      PC is at ovs_vport_get_stats+0x150/0x1f8 [openvswitch]
      <snip>
      Call trace:
       [<ffffffbffc0859f8>] ovs_vport_get_stats+0x150/0x1f8 [openvswitch]
       [<ffffffbffc07cdb0>] ovs_vport_cmd_fill_info+0x140/0x1e0 [openvswitch]
       [<ffffffbffc07cf0c>] ovs_vport_cmd_dump+0xbc/0x138 [openvswitch]
       [<ffffffc00045a5ac>] netlink_dump+0xb8/0x258
       [<ffffffc00045ace0>] __netlink_dump_start+0x120/0x178
       [<ffffffc00045dd9c>] genl_family_rcv_msg+0x2d4/0x308
       [<ffffffc00045de58>] genl_rcv_msg+0x88/0xc4
       [<ffffffc00045cf24>] netlink_rcv_skb+0xd4/0x100
       [<ffffffc00045dab0>] genl_rcv+0x30/0x48
       [<ffffffc00045c830>] netlink_unicast+0x154/0x200
       [<ffffffc00045cc9c>] netlink_sendmsg+0x308/0x364
       [<ffffffc00041e10c>] sock_sendmsg+0x14/0x2c
       [<ffffffc000420d58>] SyS_sendto+0xbc/0xf0
      Code: aa1603e1 f94037a4 aa1303e2 aa1703e0 (f9400465)
      Reported-by: default avatarTomasz Sawicki <tomasz.sawicki@objectiveintegration.uk>
      Fixes: 8c876639 ("openvswitch: Remove vport stats.")
      Signed-off-by: default avatarPravin B Shelar <pshelar@nicira.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      83ffe99f
    • Nicolas Schichan's avatar
      ARM: net: make BPF_LD | BPF_IND instruction trigger r_X initialisation to 0. · 8690f47d
      Nicolas Schichan authored
      Without this patch, if the only instructions using r_X are of the
      BPF_LD | BPF_IND type, r_X would not be reset to 0, using whatever
      value was there when entering the jited code. With this patch, r_X
      will be correctly marked as used so it will be reset to 0 in the
      prologue code.
      
      This fix also makes the test "LD_IND byte default X" pass in the
      test_bpf module when the ARM JIT is enabled.
      Signed-off-by: default avatarNicolas Schichan <nschichan@freebox.fr>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      8690f47d
    • Konstantin Khlebnikov's avatar
      ovs: do not allocate memory from offline numa node · 598c12d0
      Konstantin Khlebnikov authored
      When openvswitch tries allocate memory from offline numa node 0:
      stats = kmem_cache_alloc_node(flow_stats_cache, GFP_KERNEL | __GFP_ZERO, 0)
      It catches VM_BUG_ON(nid < 0 || nid >= MAX_NUMNODES || !node_online(nid))
      [ replaced with VM_WARN_ON(!node_online(nid)) recently ] in linux/gfp.h
      This patch disables numa affinity in this case.
      Signed-off-by: default avatarKonstantin Khlebnikov <khlebnikov@yandex-team.ru>
      Acked-by: default avatarPravin B Shelar <pshelar@nicira.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      598c12d0
    • Daniel Borkmann's avatar
      bpf: fix panic in SO_GET_FILTER with native ebpf programs · 93d08b69
      Daniel Borkmann authored
      When sockets have a native eBPF program attached through
      setsockopt(sk, SOL_SOCKET, SO_ATTACH_BPF, ...), and then try to
      dump these over getsockopt(sk, SOL_SOCKET, SO_GET_FILTER, ...),
      the following panic appears:
      
        [49904.178642] BUG: unable to handle kernel NULL pointer dereference at (null)
        [49904.178762] IP: [<ffffffff81610fd9>] sk_get_filter+0x39/0x90
        [49904.182000] PGD 86fc9067 PUD 531a1067 PMD 0
        [49904.185196] Oops: 0000 [#1] SMP
        [...]
        [49904.224677] Call Trace:
        [49904.226090]  [<ffffffff815e3d49>] sock_getsockopt+0x319/0x740
        [49904.227535]  [<ffffffff812f59e3>] ? sock_has_perm+0x63/0x70
        [49904.228953]  [<ffffffff815e2fc8>] ? release_sock+0x108/0x150
        [49904.230380]  [<ffffffff812f5a43>] ? selinux_socket_getsockopt+0x23/0x30
        [49904.231788]  [<ffffffff815dff36>] SyS_getsockopt+0xa6/0xc0
        [49904.233267]  [<ffffffff8171b9ae>] entry_SYSCALL_64_fastpath+0x12/0x71
      
      The underlying issue is the very same as in commit b382c086
      ("sock, diag: fix panic in sock_diag_put_filterinfo"), that is,
      native eBPF programs don't store an original program since this
      is only needed in cBPF ones.
      
      However, sk_get_filter() wasn't updated to test for this at the
      time when eBPF could be attached. Just throw an error to the user
      to indicate that eBPF cannot be dumped over this interface.
      That way, it can also be known that a program _is_ attached (as
      opposed to just return 0), and a different (future) method needs
      to be consulted for a dump.
      
      Fixes: 89aa0758 ("net: sock: allow eBPF programs to be attached to sockets")
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Acked-by: default avatarAlexei Starovoitov <ast@plumgrid.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      93d08b69
    • Joe Stringer's avatar
      openvswitch: Rename LABEL->LABELS · 33db4125
      Joe Stringer authored
      Conntrack LABELS (plural) are exposed by conntrack; rename the OVS name
      for these to be consistent with conntrack.
      
      Fixes: c2ac6673 "openvswitch: Allow matching on conntrack label"
      Signed-off-by: default avatarJoe Stringer <joestringer@nicira.com>
      Acked-by: default avatarPravin B Shelar <pshelar@nicira.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      33db4125