datapath: fix panic with multiple vlan headers

When there are multiple vlan headers present in a received frame, the
first one is put into vlan_tci and protocol is set to ETH_P_8021Q.
Anything in the skb beyond the VLAN TPID may be still non-linear,
including the inner TCI and ethertype. While ovs_flow_extract takes
care of IP and IPv6 headers, it does nothing with ETH_P_8021Q. Later,
if OVS_ACTION_ATTR_POP_VLAN is executed, __pop_vlan_tci pulls the
next vlan header into vlan_tci.

This leads to two things:

1. Part of the resulting ethernet header is in the non-linear part of
   the skb. When eth_type_trans is called later as the result of
   OVS_ACTION_ATTR_OUTPUT, kernel BUGs in __skb_pull. Also,
   __pop_vlan_tci is in fact accessing random data when it reads
   past the TPID.

2. network_header points into the ethernet header instead of behind it.
   mac_len is set to a wrong value (10), too.

Reported-by: Yulong Pei <ypei@redhat.com>
Signed-off-by: Jiri Benc <jbenc@redhat.com>

I have dropped second change. Since it assumes inner mac header is of
ETH_HLEN len which is not always true.
Signed-off-by: Pravin B Shelar <pshelar@nicira.com>
datapath: distinguish between the dropped and consumed skb

distinguish between the dropped and consumed skb, not assume the skb
is consumed always

Cc: Thomas Graf <tgraf@noironetworks.com>
Cc: Pravin Shelar <pshelar@nicira.com>
Signed-off-by: Li RongQing <roy.qing.li@gmail.com>
Signed-off-by: Pravin B Shelar <pshelar@nicira.com>
datapath: Set packet egress_tun_info.

packet execute is setting egress_tun_info in skb->cb, rather
than packet->cb. skb is netlink msg skb. This causes corruption
in netlink skb state stored in skb->cb (NETLINK_CB) which
results in following deadlock in netlink code.

=============================================
[ INFO: possible recursive locking detected ]
3.2.62 #2
---------------------------------------------
handler55/22851 is trying to acquire lock:
 (genl_mutex){+.+.+.}, at: [<ffffffff81471ad7>] genl_lock+0x17/0x20

but task is already holding lock:
 (genl_mutex){+.+.+.}, at: [<ffffffff81471ad7>] genl_lock+0x17/0x20

other info that might help us debug this:
 Possible unsafe locking scenario:

       CPU0
       ----
  lock(genl_mutex);
  lock(genl_mutex);

 *** DEADLOCK ***

 May be due to missing lock nesting notation

1 lock held by handler55/22851:
 #0:  (genl_mutex){+.+.+.}, at: [<ffffffff81471ad7>] genl_lock+0x17/0x20

stack backtrace:
Pid: 22851, comm: handler55 Tainted: G           O 3.2.62 #2
Call Trace:
 [<ffffffff81097bb2>] print_deadlock_bug+0xf2/0x100
 [<ffffffff81099b99>] validate_chain+0x579/0x860
 [<ffffffff8109a17c>] __lock_acquire+0x2fc/0x4f0
 [<ffffffff8109aab0>] lock_acquire+0xa0/0x180
 [<ffffffff81519070>] __mutex_lock_common+0x60/0x420
 [<ffffffff8151959a>] mutex_lock_nested+0x4a/0x60
 [<ffffffff81471ad7>] genl_lock+0x17/0x20
 [<ffffffff81471af6>] genl_rcv+0x16/0x40
 [<ffffffff8146ff72>] netlink_unicast+0x2f2/0x310
 [<ffffffff81470159>] netlink_ack+0x109/0x1f0
 [<ffffffff8147030b>] netlink_rcv_skb+0xcb/0xd0
 [<ffffffff81471b05>] genl_rcv+0x25/0x40
 [<ffffffff8146ff72>] netlink_unicast+0x2f2/0x310
 [<ffffffff8147134c>] netlink_sendmsg+0x28c/0x3d0
 [<ffffffff8143375f>] sock_sendmsg+0xef/0x120
 [<ffffffff81435766>] ___sys_sendmsg+0x416/0x430
 [<ffffffff81435949>] __sys_sendmsg+0x49/0x90
 [<ffffffff814359a9>] sys_sendmsg+0x19/0x20
 [<ffffffff8152432b>] system_call_fastpath+0x16/0x1b

Reported-by: Joe Stringer <joestringer@nicira.com>
Signed-off-by: Pravin B Shelar <pshelar@nicira.com>
Acked-by: Joe Stringer <joestringer@nicira.com>
ovs-numa: Fix a missing initialization.

This commit updates the pointer to 'struct numa_node'
when initializing the 'struct cpu_core'.

Signed-off-by: Alex Wang <alexw@nicira.com>
Acked-by: Ben Pfaff <blp@nicira.com>
ofproto-dpif-upcall: Fix a free of uninitialized memory.

On current master, when 'upcall_receive()' returns error, the
ofpbuf 'upcall->put_actions' is uninitialized.  In some usecase,
the failure of 'upcall_receive()' will cause uninitialize of
'upcall->put_actions' and free of uninitialized pointer.

This commit fixes the issue by making the caller not conduct
the uninitialize of the 'upcall' when there is error.

Found by inspection.

Signed-off-by: Alex Wang <alexw@nicira.com>
Acked-by: Ben Pfaff <blp@nicira.com>
datapath: Remove unused dp parameter.

Signed-off-by: Pravin B Shelar <pshelar@nicira.com>
Acked-by: Andy Zhou <azhou@nicira.com>
lib/odp: Masked set action execution and printing.

Add a new action type OVS_ACTION_ATTR_SET_MASKED, and support for
parsing, printing, and committing them.

Masked set actions add a mask, immediately following the netlink
attribute data, within the netlink attribute itself.  Thus the key
attribute size for a masked set action is exactly double of the
non-masked set action.

Signed-off-by: Jarno Rajahalme <jrajahalme@nicira.com>
Acked-by: Ben Pfaff <blp@nicira.com>
lib/util: Change is_all_zeros and is_all_ones to take a void *.

is_all_zeros() and is_all_ones() operate on bytes, but just like with
memset, it is easier to use if the first argument is a void *.

Signed-off-by: Jarno Rajahalme <jrajahalme@nicira.com>
Acked-by: Ben Pfaff <blp@nicira.com>
lib/odp-util: Refine odp_mask_attr_is_exact().

Some attributes are exact matches even when all bits are not ones.
Make odp_mask_attr_is_exact() to return true if the mask is set for
all the bits we actually care about.

Signed-off-by: Jarno Rajahalme <jrajahalme@nicira.com>
Acked-by: Ben Pfaff <blp@nicira.com>
lib: Unify flags parsing and formatting.

Use the "+-" syntax more uniformly when printing masked flags, and use
the syntax of delimited 1-flags also for formatting fully masked TCP
flags.

The "+-" syntax only deals with masked flags, but if there are many of
those, the printout becomes long and confusing.  Typically there are
many flags only when flags are fully masked, but even then most of
them are zeros, so it makes sense to print the flags that are set
(ones) and omit the zero flags.

Signed-off-by: Jarno Rajahalme <jrajahalme@nicira.com>
Acked-by: Ben Pfaff <blp@nicira.com>
lib/odp-util: Add tunnel tp_src, tp_dst parsing and formatting.

tp_src and tp_dst fields were recently added to struct flow_tnl, but
parsing and printing was missing.

Signed-off-by: Jarno Rajahalme <jrajahalme@nicira.com>
Acked-by: Ben Pfaff <blp@nicira.com>
Change Travis CI notification email to ljakab@ac.upc.edu
userspace: add support for pop_eth and push_eth actions

These actions will allow L2->L3 and L3->L2 switching, and are supposed
to be added to flows installed in the datapath transparently by
ovs-vswitchd.

Signed-off-by: Lorand Jakab <lojakab@cisco.com>
userspace: add layer 3 flow and switching support

This commit relaxes the assumption that all packets have an Ethernet
header, and adds support for layer 3 flows.  For each packet received on
the Linux kernel datapath the l2 and l3 members of struct ofpbuf are
intialized appropriately, and some functions now expect this (notably
flow_extract()), in order to differentiate between layer 2 and layer 3
packets.  struct flow has now a new 'base_layer' member, because we
cannot assume that a flow has no Ethernet header when eth_src and
eth_dst are 0.  For layer 3 packets, the protocol type is still stored
in the eth_type member.

Switching L2->L3 and L3->L2 are both implemented by adding the pop_eth
and push_eth actions respectively when a transition is detected.  The
push_eth action puts 0s on both source and destination MACs.  These
addresses can be modified with mod_dl_dst and mod_dl_src actions.

Added new prerequisite MFP_ETHERNET for fields MFF_ETH_SRC, MFF_ETH_DST,
MFF_VLAN_TCI, MFF_DL_VLAN, MFF_VLAN_VID and MFF_DL_VLAN_PCP.

Signed-off-by: Lorand Jakab <lojakab@cisco.com>
datapath: add layer 3 flow/port support

Implementation of the pop_eth and push_eth actions in the kernel, and
layer 3 flow support.

Signed-off-by: Lorand Jakab <lojakab@cisco.com>
Address Jesse's comment #1
Address Jesse's comment #8
Address Jesse's comment #9
Address Jesse's comment #7
Address Jesse's comment #6