summaryrefslogtreecommitdiff
path: root/INSTALL.XenServer
diff options
context:
space:
mode:
authorBen Pfaff <blp@nicira.com>2011-02-18 20:53:51 -0800
committerBen Pfaff <blp@nicira.com>2011-02-18 20:53:51 -0800
commit088a727c9ca2a9b54e11de94e1fc4396a277523a (patch)
tree68df7d50b80e6971dd78465081b7b79e46d64b74 /INSTALL.XenServer
parent5cb12f2eeffdfcb7696bdcb652b581cfd13d1c3a (diff)
downloadopenvswitch-088a727c9ca2a9b54e11de94e1fc4396a277523a.tar.gz
datapath: Properly initialize ovs_skb_cb of packet from userspace.
The ovs_skb_cb in 'packet' in this function is initially a clone of the corresponding area in 'skb', which came from the Netlink layer and thus isn't necessarily all-zeros. This commit initializes it properly before passing it along to execute_actions(). The most common problem caused by failing to initialize the ovs_skb_cb properly was that on Linux 2.6.26 and earlier, where Open vSwitch keeps its own vlan_tci field inside ovs_skb_cb, the first packet of a flow would get sent out tagged with a random VLAN (usually 0x0001 or 0xffff in our testing). This commit should fix that problem. Another likely problem would be for turning on sFlow to randomly panic the kernel. That problem would not be kernel version dependent. We haven't been testing sFlow so we haven't noticed this problem. Signed-off-by: Ben Pfaff <blp@nicira.com> Acked-by: Justin Pettit <jpettit@nicira.com> Reported-by: Pankaj Thakkar <thakkar@nicira.com>
Diffstat (limited to 'INSTALL.XenServer')
0 files changed, 0 insertions, 0 deletions