1. 21 Jul, 2015 2 commits
  2. 01 Jun, 2015 1 commit
    • Neil McKee's avatar
      openvswitch: include datapath actions with sampled-packet upcall to userspace · ccea7445
      Neil McKee authored
      If new optional attribute OVS_USERSPACE_ATTR_ACTIONS is added to an
      OVS_ACTION_ATTR_USERSPACE action, then include the datapath actions
      in the upcall.
      This Directly associates the sampled packet with the path it takes
      through the virtual switch. Path information currently includes mangling,
      encapsulation and decapsulation actions for tunneling protocols GRE,
      VXLAN, Geneve, MPLS and QinQ, but this extension requires no further
      changes to accommodate datapath actions that may be added in the
      Adding path information enhances visibility into complex virtual
      Signed-off-by: default avatarNeil McKee <neil.mckee@inmon.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
  3. 05 May, 2015 1 commit
  4. 12 Mar, 2015 1 commit
  5. 20 Feb, 2015 1 commit
    • Pravin B Shelar's avatar
      openvswitch: Fix net exit. · 7b4577a9
      Pravin B Shelar authored
      Open vSwitch allows moving internal vport to different namespace
      while still connected to the bridge. But when namespace deleted
      OVS does not detach these vports, that results in dangling
      pointer to netdevice which causes kernel panic as follows.
      This issue is fixed by detaching all ovs ports from the deleted
      namespace at net-exit.
      BUG: unable to handle kernel NULL pointer dereference at 0000000000000028
      IP: [<ffffffffa0aadaa5>] ovs_vport_locate+0x35/0x80 [openvswitch]
      Oops: 0000 [#1] SMP
      Call Trace:
       [<ffffffffa0aa6391>] lookup_vport+0x21/0xd0 [openvswitch]
       [<ffffffffa0aa65f9>] ovs_vport_cmd_get+0x59/0xf0 [openvswitch]
       [<ffffffff8167e07c>] genl_family_rcv_msg+0x1bc/0x3e0
       [<ffffffff8167e319>] genl_rcv_msg+0x79/0xc0
       [<ffffffff8167d919>] netlink_rcv_skb+0xb9/0xe0
       [<ffffffff8167deac>] genl_rcv+0x2c/0x40
       [<ffffffff8167cffd>] netlink_unicast+0x12d/0x1c0
       [<ffffffff8167d3da>] netlink_sendmsg+0x34a/0x6b0
       [<ffffffff8162e140>] sock_sendmsg+0xa0/0xe0
       [<ffffffff8162e5e8>] ___sys_sendmsg+0x408/0x420
       [<ffffffff8162f541>] __sys_sendmsg+0x51/0x90
       [<ffffffff8162f592>] SyS_sendmsg+0x12/0x20
       [<ffffffff81764ee9>] system_call_fastpath+0x12/0x17
      Reported-by: default avatarAssaf Muller <amuller@redhat.com>
      Fixes: 46df7b81("openvswitch: Add support for network namespaces.")
      Signed-off-by: default avatarPravin B Shelar <pshelar@nicira.com>
      Reviewed-by: default avatarThomas Graf <tgraf@noironetworks.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
  6. 26 Jan, 2015 2 commits
    • Joe Stringer's avatar
      openvswitch: Add support for unique flow IDs. · 74ed7ab9
      Joe Stringer authored
      Previously, flows were manipulated by userspace specifying a full,
      unmasked flow key. This adds significant burden onto flow
      serialization/deserialization, particularly when dumping flows.
      This patch adds an alternative way to refer to flows using a
      variable-length "unique flow identifier" (UFID). At flow setup time,
      userspace may specify a UFID for a flow, which is stored with the flow
      and inserted into a separate table for lookup, in addition to the
      standard flow table. Flows created using a UFID must be fetched or
      deleted using the UFID.
      All flow dump operations may now be made more terse with OVS_UFID_F_*
      flags. For example, the OVS_UFID_F_OMIT_KEY flag allows responses to
      omit the flow key from a datapath operation if the flow has a
      corresponding UFID. This significantly reduces the time spent assembling
      and transacting netlink messages. With all OVS_UFID_F_OMIT_* flags
      enabled, the datapath only returns the UFID and statistics for each flow
      during flow dump, increasing ovs-vswitchd revalidator performance by 40%
      or more.
      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>
    • Joe Stringer's avatar
      openvswitch: Refactor ovs_nla_fill_match(). · 5b4237bb
      Joe Stringer authored
      Refactor the ovs_nla_fill_match() function into separate netlink
      serialization functions ovs_nla_put_{unmasked_key,mask}(). Modify
      ovs_nla_put_flow() to handle attribute nesting and expose the 'is_mask'
      parameter - all callers need to nest the flow, and callers have better
      knowledge about whether it is serializing a mask or not.
      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>
  7. 17 Jan, 2015 1 commit
    • Johannes Berg's avatar
      netlink: make nlmsg_end() and genlmsg_end() void · 053c095a
      Johannes Berg authored
      Contrary to common expectations for an "int" return, these functions
      return only a positive value -- if used correctly they cannot even
      return 0 because the message header will necessarily be in the skb.
      This makes the very common pattern of
        if (genlmsg_end(...) < 0) { ... }
      be a whole bunch of dead code. Many places also simply do
        return nlmsg_end(...);
      and the caller is expected to deal with it.
      This also commonly (at least for me) causes errors, because it is very
      common to write
        if (my_function(...))
          /* error condition */
      and if my_function() does "return nlmsg_end()" this is of course wrong.
      Additionally, there's not a single place in the kernel that actually
      needs the message length returned, and if anyone needs it later then
      it'll be very easy to just use skb->len there.
      Remove this, and make the functions void. This removes a bunch of dead
      code as described above. The patch adds lines because I did
      -	return nlmsg_end(...);
      +	nlmsg_end(...);
      +	return 0;
      I could have preserved all the function's return values by returning
      skb->len, but instead I've audited all the places calling the affected
      functions and found that none cared. A few places actually compared
      the return value with <= 0 in dump functionality, but that could just
      be changed to < 0 with no change in behaviour, so I opted for the more
      efficient version.
      One instance of the error I've made numerous times now is also present
      in net/phonet/pn_netlink.c in the route_dumpit() function - it didn't
      check for <0 or <=0 and thus broke out of the loop every single time.
      I've preserved this since it will (I think) have caused the messages to
      userspace to be formatted differently with just a single message for
      every SKB returned to userspace. It's possible that this isn't needed
      for the tools that actually use this, but I don't even know what they
      are so couldn't test that changing this behaviour would be acceptable.
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
  8. 14 Jan, 2015 1 commit
  9. 13 Jan, 2015 1 commit
  10. 27 Dec, 2014 1 commit
  11. 21 Nov, 2014 2 commits
  12. 14 Nov, 2014 1 commit
  13. 09 Nov, 2014 5 commits
  14. 06 Nov, 2014 8 commits
  15. 28 Oct, 2014 2 commits
  16. 20 Oct, 2014 1 commit
    • Florian Westphal's avatar
      net: make skb_gso_segment error handling more robust · 330966e5
      Florian Westphal authored
      skb_gso_segment has three possible return values:
      1. a pointer to the first segmented skb
      2. an errno value (IS_ERR())
      3. NULL.  This can happen when GSO is used for header verification.
      However, several callers currently test IS_ERR instead of IS_ERR_OR_NULL
      and would oops when NULL is returned.
      Note that these call sites should never actually see such a NULL return
      value; all callers mask out the GSO bits in the feature argument.
      However, there have been issues with some protocol handlers erronously not
      respecting the specified feature mask in some cases.
      It is preferable to get 'have to turn off hw offloading, else slow' reports
      rather than 'kernel crashes'.
      Signed-off-by: default avatarFlorian Westphal <fw@strlen.de>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
  17. 05 Oct, 2014 3 commits
  18. 19 Sep, 2014 1 commit
  19. 16 Sep, 2014 4 commits
  20. 03 Sep, 2014 1 commit