2
0
mirror of https://github.com/openvswitch/ovs synced 2025-10-21 14:49:41 +00:00
Files
openvswitch/datapath/flow.c

616 lines
16 KiB
C
Raw Normal View History

/*
* Copyright (c) 2007-2013 Nicira, Inc.
*
* This program is free software; you can redistribute it and/or
* modify it under the terms of version 2 of the GNU General Public
* License as published by the Free Software Foundation.
*
* This program is distributed in the hope that it will be useful, but
* WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
* General Public License for more details.
*
* You should have received a copy of the GNU General Public License
* along with this program; if not, write to the Free Software
* Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
* 02110-1301, USA
*/
#include "flow.h"
#include "datapath.h"
#include <linux/uaccess.h>
#include <linux/netdevice.h>
#include <linux/etherdevice.h>
#include <linux/if_ether.h>
#include <linux/if_vlan.h>
#include <net/llc_pdu.h>
#include <linux/kernel.h>
#include <linux/jhash.h>
#include <linux/jiffies.h>
#include <linux/llc.h>
#include <linux/module.h>
#include <linux/in.h>
#include <linux/rcupdate.h>
#include <linux/if_arp.h>
#include <linux/ip.h>
#include <linux/ipv6.h>
#include <linux/sctp.h>
#include <linux/smp.h>
#include <linux/tcp.h>
#include <linux/udp.h>
#include <linux/icmp.h>
#include <linux/icmpv6.h>
#include <linux/rculist.h>
#include <net/ip.h>
#include <net/ipv6.h>
#include <net/ndisc.h>
#include "vlan.h"
u64 ovs_flow_used_time(unsigned long flow_jiffies)
{
struct timespec cur_ts;
u64 cur_ms, idle_ms;
ktime_get_ts(&cur_ts);
idle_ms = jiffies_to_msecs(jiffies - flow_jiffies);
cur_ms = (u64)cur_ts.tv_sec * MSEC_PER_SEC +
cur_ts.tv_nsec / NSEC_PER_MSEC;
return cur_ms - idle_ms;
}
#define TCP_FLAGS_BE16(tp) (*(__be16 *)&tcp_flag_word(tp) & htons(0x0FFF))
void ovs_flow_stats_update(struct sw_flow *flow, struct sk_buff *skb)
{
struct flow_stats *stats;
__be16 tcp_flags = 0;
if (!flow->stats.is_percpu)
stats = flow->stats.stat;
else
stats = this_cpu_ptr(flow->stats.cpu_stats);
if ((flow->key.eth.type == htons(ETH_P_IP) ||
flow->key.eth.type == htons(ETH_P_IPV6)) &&
flow->key.ip.proto == IPPROTO_TCP &&
likely(skb->len >= skb_transport_offset(skb) + sizeof(struct tcphdr))) {
tcp_flags = TCP_FLAGS_BE16(tcp_hdr(skb));
}
spin_lock(&stats->lock);
stats->used = jiffies;
stats->packet_count++;
stats->byte_count += skb->len;
stats->tcp_flags |= tcp_flags;
spin_unlock(&stats->lock);
}
datapath: Fix deadlock during stats update. Stats-read needs to lock stats but same lock is taken in stats update in irq context. Therefore it needs to disable irq to avoid following deadlock :- BUG: soft lockup - CPU#1 stuck for 23s! [ovs-vswitchd:1425] CPU 1 Pid: 1425, comm: ovs-vswitchd Tainted: G O 3.2.39-server-nn23 #1 VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform RIP: 0010:[<ffffffff8103db22>] [<ffffffff8103db22>] __ticket_spin_lock+0x22/0x30 RSP: 0018:ffff88003fd03b30 EFLAGS: 00000297 RAX: 0000000000000001 RBX: 0000000000000000 RCX: 0000000000000050 RDX: 0000000000000002 RSI: ffff88003d0a9900 RDI: ffff88003ae19598 RBP: ffff88003fd03b30 R08: 0000000000000000 R09: ffff88003ad44048 R10: 0000000000000001 R11: 0000000000000001 R12: ffff88003fd03aa8 R13: ffffffff8164e5de R14: ffff88003fd03b30 R15: ffff88003ae19580 FS: 00007ffb0b428940(0000) GS:ffff88003fd00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f3c0ef94000 CR3: 00000000250e2000 CR4: 00000000000006e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Process ovs-vswitchd (pid: 1425, threadinfo ffff88002514a000, task ffff8800250aae00) Stack: ffff88003fd03b40 ffffffff8164596e ffff88003fd03b70 ffffffffa027622d ffff88003d0a9900 ffffe8ffffd03800 ffff8800297f5a80 ffff88003fd03ba8 ffff88003fd03c60 ffffffffa02759af ffff88003fd03de0 ffff88003fd03e4c Call Trace: <IRQ> [<ffffffff8164596e>] _raw_spin_lock+0xe/0x20 [<ffffffffa027622d>] ovs_flow_stats_update+0x5d/0x100 [openvswitch] [<ffffffffa02759af>] ovs_dp_process_received_packet+0x8f/0x130 [openvswitch] [<ffffffffa027c0ca>] ovs_vport_receive+0x2a/0x30 [openvswitch] [<ffffffffa027db18>] netdev_frame_hook+0xb8/0x120 [openvswitch] [<ffffffffa027da60>] ? free_port_rcu+0x30/0x30 [openvswitch] [<ffffffff81539318>] __netif_receive_skb+0x1c8/0x620 [<ffffffff8153a4c0>] netif_receive_skb+0x80/0x90 [<ffffffff8115f14c>] ? ksize+0x1c/0xc0 [<ffffffff8153a610>] napi_skb_finish+0x50/0x70 [<ffffffff8153ac15>] napi_gro_receive+0xf5/0x140 [<ffffffffa00368ae>] vmxnet3_rq_rx_complete+0x51e/0x7c0 [vmxnet3] [<ffffffff8101ac90>] ? nommu_map_sg+0xe0/0xe0 [<ffffffffa0036da5>] vmxnet3_poll_rx_only+0x45/0xc0 [vmxnet3] [<ffffffff8153ae64>] net_rx_action+0x134/0x290 [<ffffffff8103db0d>] ? __ticket_spin_lock+0xd/0x30 [<ffffffff8106e1a8>] __do_softirq+0xa8/0x210 [<ffffffff8164596e>] ? _raw_spin_lock+0xe/0x20 [<ffffffff8164fd6c>] call_softirq+0x1c/0x30 [<ffffffff81016215>] do_softirq+0x65/0xa0 [<ffffffff8106e58e>] irq_exit+0x8e/0xb0 [<ffffffff81650633>] do_IRQ+0x63/0xe0 [<ffffffff81645e2e>] common_interrupt+0x6e/0x6e ----------- Bug #21853 Reported-by: Pawan Shukla <shuklap@vmware.com> Signed-off-by: Pravin B Shelar <pshelar@nicira.com> Acked-by: Jesse Gross <jesse@nicira.com>
2013-12-17 15:43:30 -08:00
static void stats_read(struct flow_stats *stats, bool lock_bh,
struct ovs_flow_stats *ovs_stats,
unsigned long *used, __be16 *tcp_flags)
{
datapath: Fix deadlock during stats update. Stats-read needs to lock stats but same lock is taken in stats update in irq context. Therefore it needs to disable irq to avoid following deadlock :- BUG: soft lockup - CPU#1 stuck for 23s! [ovs-vswitchd:1425] CPU 1 Pid: 1425, comm: ovs-vswitchd Tainted: G O 3.2.39-server-nn23 #1 VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform RIP: 0010:[<ffffffff8103db22>] [<ffffffff8103db22>] __ticket_spin_lock+0x22/0x30 RSP: 0018:ffff88003fd03b30 EFLAGS: 00000297 RAX: 0000000000000001 RBX: 0000000000000000 RCX: 0000000000000050 RDX: 0000000000000002 RSI: ffff88003d0a9900 RDI: ffff88003ae19598 RBP: ffff88003fd03b30 R08: 0000000000000000 R09: ffff88003ad44048 R10: 0000000000000001 R11: 0000000000000001 R12: ffff88003fd03aa8 R13: ffffffff8164e5de R14: ffff88003fd03b30 R15: ffff88003ae19580 FS: 00007ffb0b428940(0000) GS:ffff88003fd00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f3c0ef94000 CR3: 00000000250e2000 CR4: 00000000000006e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Process ovs-vswitchd (pid: 1425, threadinfo ffff88002514a000, task ffff8800250aae00) Stack: ffff88003fd03b40 ffffffff8164596e ffff88003fd03b70 ffffffffa027622d ffff88003d0a9900 ffffe8ffffd03800 ffff8800297f5a80 ffff88003fd03ba8 ffff88003fd03c60 ffffffffa02759af ffff88003fd03de0 ffff88003fd03e4c Call Trace: <IRQ> [<ffffffff8164596e>] _raw_spin_lock+0xe/0x20 [<ffffffffa027622d>] ovs_flow_stats_update+0x5d/0x100 [openvswitch] [<ffffffffa02759af>] ovs_dp_process_received_packet+0x8f/0x130 [openvswitch] [<ffffffffa027c0ca>] ovs_vport_receive+0x2a/0x30 [openvswitch] [<ffffffffa027db18>] netdev_frame_hook+0xb8/0x120 [openvswitch] [<ffffffffa027da60>] ? free_port_rcu+0x30/0x30 [openvswitch] [<ffffffff81539318>] __netif_receive_skb+0x1c8/0x620 [<ffffffff8153a4c0>] netif_receive_skb+0x80/0x90 [<ffffffff8115f14c>] ? ksize+0x1c/0xc0 [<ffffffff8153a610>] napi_skb_finish+0x50/0x70 [<ffffffff8153ac15>] napi_gro_receive+0xf5/0x140 [<ffffffffa00368ae>] vmxnet3_rq_rx_complete+0x51e/0x7c0 [vmxnet3] [<ffffffff8101ac90>] ? nommu_map_sg+0xe0/0xe0 [<ffffffffa0036da5>] vmxnet3_poll_rx_only+0x45/0xc0 [vmxnet3] [<ffffffff8153ae64>] net_rx_action+0x134/0x290 [<ffffffff8103db0d>] ? __ticket_spin_lock+0xd/0x30 [<ffffffff8106e1a8>] __do_softirq+0xa8/0x210 [<ffffffff8164596e>] ? _raw_spin_lock+0xe/0x20 [<ffffffff8164fd6c>] call_softirq+0x1c/0x30 [<ffffffff81016215>] do_softirq+0x65/0xa0 [<ffffffff8106e58e>] irq_exit+0x8e/0xb0 [<ffffffff81650633>] do_IRQ+0x63/0xe0 [<ffffffff81645e2e>] common_interrupt+0x6e/0x6e ----------- Bug #21853 Reported-by: Pawan Shukla <shuklap@vmware.com> Signed-off-by: Pravin B Shelar <pshelar@nicira.com> Acked-by: Jesse Gross <jesse@nicira.com>
2013-12-17 15:43:30 -08:00
if (lock_bh)
spin_lock_bh(&stats->lock);
else
spin_lock(&stats->lock);
if (time_after(stats->used, *used))
*used = stats->used;
*tcp_flags |= stats->tcp_flags;
ovs_stats->n_packets += stats->packet_count;
ovs_stats->n_bytes += stats->byte_count;
datapath: Fix deadlock during stats update. Stats-read needs to lock stats but same lock is taken in stats update in irq context. Therefore it needs to disable irq to avoid following deadlock :- BUG: soft lockup - CPU#1 stuck for 23s! [ovs-vswitchd:1425] CPU 1 Pid: 1425, comm: ovs-vswitchd Tainted: G O 3.2.39-server-nn23 #1 VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform RIP: 0010:[<ffffffff8103db22>] [<ffffffff8103db22>] __ticket_spin_lock+0x22/0x30 RSP: 0018:ffff88003fd03b30 EFLAGS: 00000297 RAX: 0000000000000001 RBX: 0000000000000000 RCX: 0000000000000050 RDX: 0000000000000002 RSI: ffff88003d0a9900 RDI: ffff88003ae19598 RBP: ffff88003fd03b30 R08: 0000000000000000 R09: ffff88003ad44048 R10: 0000000000000001 R11: 0000000000000001 R12: ffff88003fd03aa8 R13: ffffffff8164e5de R14: ffff88003fd03b30 R15: ffff88003ae19580 FS: 00007ffb0b428940(0000) GS:ffff88003fd00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f3c0ef94000 CR3: 00000000250e2000 CR4: 00000000000006e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Process ovs-vswitchd (pid: 1425, threadinfo ffff88002514a000, task ffff8800250aae00) Stack: ffff88003fd03b40 ffffffff8164596e ffff88003fd03b70 ffffffffa027622d ffff88003d0a9900 ffffe8ffffd03800 ffff8800297f5a80 ffff88003fd03ba8 ffff88003fd03c60 ffffffffa02759af ffff88003fd03de0 ffff88003fd03e4c Call Trace: <IRQ> [<ffffffff8164596e>] _raw_spin_lock+0xe/0x20 [<ffffffffa027622d>] ovs_flow_stats_update+0x5d/0x100 [openvswitch] [<ffffffffa02759af>] ovs_dp_process_received_packet+0x8f/0x130 [openvswitch] [<ffffffffa027c0ca>] ovs_vport_receive+0x2a/0x30 [openvswitch] [<ffffffffa027db18>] netdev_frame_hook+0xb8/0x120 [openvswitch] [<ffffffffa027da60>] ? free_port_rcu+0x30/0x30 [openvswitch] [<ffffffff81539318>] __netif_receive_skb+0x1c8/0x620 [<ffffffff8153a4c0>] netif_receive_skb+0x80/0x90 [<ffffffff8115f14c>] ? ksize+0x1c/0xc0 [<ffffffff8153a610>] napi_skb_finish+0x50/0x70 [<ffffffff8153ac15>] napi_gro_receive+0xf5/0x140 [<ffffffffa00368ae>] vmxnet3_rq_rx_complete+0x51e/0x7c0 [vmxnet3] [<ffffffff8101ac90>] ? nommu_map_sg+0xe0/0xe0 [<ffffffffa0036da5>] vmxnet3_poll_rx_only+0x45/0xc0 [vmxnet3] [<ffffffff8153ae64>] net_rx_action+0x134/0x290 [<ffffffff8103db0d>] ? __ticket_spin_lock+0xd/0x30 [<ffffffff8106e1a8>] __do_softirq+0xa8/0x210 [<ffffffff8164596e>] ? _raw_spin_lock+0xe/0x20 [<ffffffff8164fd6c>] call_softirq+0x1c/0x30 [<ffffffff81016215>] do_softirq+0x65/0xa0 [<ffffffff8106e58e>] irq_exit+0x8e/0xb0 [<ffffffff81650633>] do_IRQ+0x63/0xe0 [<ffffffff81645e2e>] common_interrupt+0x6e/0x6e ----------- Bug #21853 Reported-by: Pawan Shukla <shuklap@vmware.com> Signed-off-by: Pravin B Shelar <pshelar@nicira.com> Acked-by: Jesse Gross <jesse@nicira.com>
2013-12-17 15:43:30 -08:00
if (lock_bh)
spin_unlock_bh(&stats->lock);
else
spin_unlock(&stats->lock);
}
void ovs_flow_stats_get(struct sw_flow *flow, struct ovs_flow_stats *ovs_stats,
unsigned long *used, __be16 *tcp_flags)
{
int cpu, cur_cpu;
*used = 0;
*tcp_flags = 0;
memset(ovs_stats, 0, sizeof(*ovs_stats));
if (!flow->stats.is_percpu) {
datapath: Fix deadlock during stats update. Stats-read needs to lock stats but same lock is taken in stats update in irq context. Therefore it needs to disable irq to avoid following deadlock :- BUG: soft lockup - CPU#1 stuck for 23s! [ovs-vswitchd:1425] CPU 1 Pid: 1425, comm: ovs-vswitchd Tainted: G O 3.2.39-server-nn23 #1 VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform RIP: 0010:[<ffffffff8103db22>] [<ffffffff8103db22>] __ticket_spin_lock+0x22/0x30 RSP: 0018:ffff88003fd03b30 EFLAGS: 00000297 RAX: 0000000000000001 RBX: 0000000000000000 RCX: 0000000000000050 RDX: 0000000000000002 RSI: ffff88003d0a9900 RDI: ffff88003ae19598 RBP: ffff88003fd03b30 R08: 0000000000000000 R09: ffff88003ad44048 R10: 0000000000000001 R11: 0000000000000001 R12: ffff88003fd03aa8 R13: ffffffff8164e5de R14: ffff88003fd03b30 R15: ffff88003ae19580 FS: 00007ffb0b428940(0000) GS:ffff88003fd00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f3c0ef94000 CR3: 00000000250e2000 CR4: 00000000000006e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Process ovs-vswitchd (pid: 1425, threadinfo ffff88002514a000, task ffff8800250aae00) Stack: ffff88003fd03b40 ffffffff8164596e ffff88003fd03b70 ffffffffa027622d ffff88003d0a9900 ffffe8ffffd03800 ffff8800297f5a80 ffff88003fd03ba8 ffff88003fd03c60 ffffffffa02759af ffff88003fd03de0 ffff88003fd03e4c Call Trace: <IRQ> [<ffffffff8164596e>] _raw_spin_lock+0xe/0x20 [<ffffffffa027622d>] ovs_flow_stats_update+0x5d/0x100 [openvswitch] [<ffffffffa02759af>] ovs_dp_process_received_packet+0x8f/0x130 [openvswitch] [<ffffffffa027c0ca>] ovs_vport_receive+0x2a/0x30 [openvswitch] [<ffffffffa027db18>] netdev_frame_hook+0xb8/0x120 [openvswitch] [<ffffffffa027da60>] ? free_port_rcu+0x30/0x30 [openvswitch] [<ffffffff81539318>] __netif_receive_skb+0x1c8/0x620 [<ffffffff8153a4c0>] netif_receive_skb+0x80/0x90 [<ffffffff8115f14c>] ? ksize+0x1c/0xc0 [<ffffffff8153a610>] napi_skb_finish+0x50/0x70 [<ffffffff8153ac15>] napi_gro_receive+0xf5/0x140 [<ffffffffa00368ae>] vmxnet3_rq_rx_complete+0x51e/0x7c0 [vmxnet3] [<ffffffff8101ac90>] ? nommu_map_sg+0xe0/0xe0 [<ffffffffa0036da5>] vmxnet3_poll_rx_only+0x45/0xc0 [vmxnet3] [<ffffffff8153ae64>] net_rx_action+0x134/0x290 [<ffffffff8103db0d>] ? __ticket_spin_lock+0xd/0x30 [<ffffffff8106e1a8>] __do_softirq+0xa8/0x210 [<ffffffff8164596e>] ? _raw_spin_lock+0xe/0x20 [<ffffffff8164fd6c>] call_softirq+0x1c/0x30 [<ffffffff81016215>] do_softirq+0x65/0xa0 [<ffffffff8106e58e>] irq_exit+0x8e/0xb0 [<ffffffff81650633>] do_IRQ+0x63/0xe0 [<ffffffff81645e2e>] common_interrupt+0x6e/0x6e ----------- Bug #21853 Reported-by: Pawan Shukla <shuklap@vmware.com> Signed-off-by: Pravin B Shelar <pshelar@nicira.com> Acked-by: Jesse Gross <jesse@nicira.com>
2013-12-17 15:43:30 -08:00
stats_read(flow->stats.stat, true, ovs_stats, used, tcp_flags);
} else {
cur_cpu = get_cpu();
datapath: Fix deadlock during stats update. Stats-read needs to lock stats but same lock is taken in stats update in irq context. Therefore it needs to disable irq to avoid following deadlock :- BUG: soft lockup - CPU#1 stuck for 23s! [ovs-vswitchd:1425] CPU 1 Pid: 1425, comm: ovs-vswitchd Tainted: G O 3.2.39-server-nn23 #1 VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform RIP: 0010:[<ffffffff8103db22>] [<ffffffff8103db22>] __ticket_spin_lock+0x22/0x30 RSP: 0018:ffff88003fd03b30 EFLAGS: 00000297 RAX: 0000000000000001 RBX: 0000000000000000 RCX: 0000000000000050 RDX: 0000000000000002 RSI: ffff88003d0a9900 RDI: ffff88003ae19598 RBP: ffff88003fd03b30 R08: 0000000000000000 R09: ffff88003ad44048 R10: 0000000000000001 R11: 0000000000000001 R12: ffff88003fd03aa8 R13: ffffffff8164e5de R14: ffff88003fd03b30 R15: ffff88003ae19580 FS: 00007ffb0b428940(0000) GS:ffff88003fd00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f3c0ef94000 CR3: 00000000250e2000 CR4: 00000000000006e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Process ovs-vswitchd (pid: 1425, threadinfo ffff88002514a000, task ffff8800250aae00) Stack: ffff88003fd03b40 ffffffff8164596e ffff88003fd03b70 ffffffffa027622d ffff88003d0a9900 ffffe8ffffd03800 ffff8800297f5a80 ffff88003fd03ba8 ffff88003fd03c60 ffffffffa02759af ffff88003fd03de0 ffff88003fd03e4c Call Trace: <IRQ> [<ffffffff8164596e>] _raw_spin_lock+0xe/0x20 [<ffffffffa027622d>] ovs_flow_stats_update+0x5d/0x100 [openvswitch] [<ffffffffa02759af>] ovs_dp_process_received_packet+0x8f/0x130 [openvswitch] [<ffffffffa027c0ca>] ovs_vport_receive+0x2a/0x30 [openvswitch] [<ffffffffa027db18>] netdev_frame_hook+0xb8/0x120 [openvswitch] [<ffffffffa027da60>] ? free_port_rcu+0x30/0x30 [openvswitch] [<ffffffff81539318>] __netif_receive_skb+0x1c8/0x620 [<ffffffff8153a4c0>] netif_receive_skb+0x80/0x90 [<ffffffff8115f14c>] ? ksize+0x1c/0xc0 [<ffffffff8153a610>] napi_skb_finish+0x50/0x70 [<ffffffff8153ac15>] napi_gro_receive+0xf5/0x140 [<ffffffffa00368ae>] vmxnet3_rq_rx_complete+0x51e/0x7c0 [vmxnet3] [<ffffffff8101ac90>] ? nommu_map_sg+0xe0/0xe0 [<ffffffffa0036da5>] vmxnet3_poll_rx_only+0x45/0xc0 [vmxnet3] [<ffffffff8153ae64>] net_rx_action+0x134/0x290 [<ffffffff8103db0d>] ? __ticket_spin_lock+0xd/0x30 [<ffffffff8106e1a8>] __do_softirq+0xa8/0x210 [<ffffffff8164596e>] ? _raw_spin_lock+0xe/0x20 [<ffffffff8164fd6c>] call_softirq+0x1c/0x30 [<ffffffff81016215>] do_softirq+0x65/0xa0 [<ffffffff8106e58e>] irq_exit+0x8e/0xb0 [<ffffffff81650633>] do_IRQ+0x63/0xe0 [<ffffffff81645e2e>] common_interrupt+0x6e/0x6e ----------- Bug #21853 Reported-by: Pawan Shukla <shuklap@vmware.com> Signed-off-by: Pravin B Shelar <pshelar@nicira.com> Acked-by: Jesse Gross <jesse@nicira.com>
2013-12-17 15:43:30 -08:00
for_each_possible_cpu(cpu) {
struct flow_stats *stats;
datapath: Fix deadlock during stats update. Stats-read needs to lock stats but same lock is taken in stats update in irq context. Therefore it needs to disable irq to avoid following deadlock :- BUG: soft lockup - CPU#1 stuck for 23s! [ovs-vswitchd:1425] CPU 1 Pid: 1425, comm: ovs-vswitchd Tainted: G O 3.2.39-server-nn23 #1 VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform RIP: 0010:[<ffffffff8103db22>] [<ffffffff8103db22>] __ticket_spin_lock+0x22/0x30 RSP: 0018:ffff88003fd03b30 EFLAGS: 00000297 RAX: 0000000000000001 RBX: 0000000000000000 RCX: 0000000000000050 RDX: 0000000000000002 RSI: ffff88003d0a9900 RDI: ffff88003ae19598 RBP: ffff88003fd03b30 R08: 0000000000000000 R09: ffff88003ad44048 R10: 0000000000000001 R11: 0000000000000001 R12: ffff88003fd03aa8 R13: ffffffff8164e5de R14: ffff88003fd03b30 R15: ffff88003ae19580 FS: 00007ffb0b428940(0000) GS:ffff88003fd00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f3c0ef94000 CR3: 00000000250e2000 CR4: 00000000000006e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Process ovs-vswitchd (pid: 1425, threadinfo ffff88002514a000, task ffff8800250aae00) Stack: ffff88003fd03b40 ffffffff8164596e ffff88003fd03b70 ffffffffa027622d ffff88003d0a9900 ffffe8ffffd03800 ffff8800297f5a80 ffff88003fd03ba8 ffff88003fd03c60 ffffffffa02759af ffff88003fd03de0 ffff88003fd03e4c Call Trace: <IRQ> [<ffffffff8164596e>] _raw_spin_lock+0xe/0x20 [<ffffffffa027622d>] ovs_flow_stats_update+0x5d/0x100 [openvswitch] [<ffffffffa02759af>] ovs_dp_process_received_packet+0x8f/0x130 [openvswitch] [<ffffffffa027c0ca>] ovs_vport_receive+0x2a/0x30 [openvswitch] [<ffffffffa027db18>] netdev_frame_hook+0xb8/0x120 [openvswitch] [<ffffffffa027da60>] ? free_port_rcu+0x30/0x30 [openvswitch] [<ffffffff81539318>] __netif_receive_skb+0x1c8/0x620 [<ffffffff8153a4c0>] netif_receive_skb+0x80/0x90 [<ffffffff8115f14c>] ? ksize+0x1c/0xc0 [<ffffffff8153a610>] napi_skb_finish+0x50/0x70 [<ffffffff8153ac15>] napi_gro_receive+0xf5/0x140 [<ffffffffa00368ae>] vmxnet3_rq_rx_complete+0x51e/0x7c0 [vmxnet3] [<ffffffff8101ac90>] ? nommu_map_sg+0xe0/0xe0 [<ffffffffa0036da5>] vmxnet3_poll_rx_only+0x45/0xc0 [vmxnet3] [<ffffffff8153ae64>] net_rx_action+0x134/0x290 [<ffffffff8103db0d>] ? __ticket_spin_lock+0xd/0x30 [<ffffffff8106e1a8>] __do_softirq+0xa8/0x210 [<ffffffff8164596e>] ? _raw_spin_lock+0xe/0x20 [<ffffffff8164fd6c>] call_softirq+0x1c/0x30 [<ffffffff81016215>] do_softirq+0x65/0xa0 [<ffffffff8106e58e>] irq_exit+0x8e/0xb0 [<ffffffff81650633>] do_IRQ+0x63/0xe0 [<ffffffff81645e2e>] common_interrupt+0x6e/0x6e ----------- Bug #21853 Reported-by: Pawan Shukla <shuklap@vmware.com> Signed-off-by: Pravin B Shelar <pshelar@nicira.com> Acked-by: Jesse Gross <jesse@nicira.com>
2013-12-17 15:43:30 -08:00
bool lock_bh;
stats = per_cpu_ptr(flow->stats.cpu_stats, cpu);
datapath: Fix deadlock during stats update. Stats-read needs to lock stats but same lock is taken in stats update in irq context. Therefore it needs to disable irq to avoid following deadlock :- BUG: soft lockup - CPU#1 stuck for 23s! [ovs-vswitchd:1425] CPU 1 Pid: 1425, comm: ovs-vswitchd Tainted: G O 3.2.39-server-nn23 #1 VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform RIP: 0010:[<ffffffff8103db22>] [<ffffffff8103db22>] __ticket_spin_lock+0x22/0x30 RSP: 0018:ffff88003fd03b30 EFLAGS: 00000297 RAX: 0000000000000001 RBX: 0000000000000000 RCX: 0000000000000050 RDX: 0000000000000002 RSI: ffff88003d0a9900 RDI: ffff88003ae19598 RBP: ffff88003fd03b30 R08: 0000000000000000 R09: ffff88003ad44048 R10: 0000000000000001 R11: 0000000000000001 R12: ffff88003fd03aa8 R13: ffffffff8164e5de R14: ffff88003fd03b30 R15: ffff88003ae19580 FS: 00007ffb0b428940(0000) GS:ffff88003fd00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f3c0ef94000 CR3: 00000000250e2000 CR4: 00000000000006e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Process ovs-vswitchd (pid: 1425, threadinfo ffff88002514a000, task ffff8800250aae00) Stack: ffff88003fd03b40 ffffffff8164596e ffff88003fd03b70 ffffffffa027622d ffff88003d0a9900 ffffe8ffffd03800 ffff8800297f5a80 ffff88003fd03ba8 ffff88003fd03c60 ffffffffa02759af ffff88003fd03de0 ffff88003fd03e4c Call Trace: <IRQ> [<ffffffff8164596e>] _raw_spin_lock+0xe/0x20 [<ffffffffa027622d>] ovs_flow_stats_update+0x5d/0x100 [openvswitch] [<ffffffffa02759af>] ovs_dp_process_received_packet+0x8f/0x130 [openvswitch] [<ffffffffa027c0ca>] ovs_vport_receive+0x2a/0x30 [openvswitch] [<ffffffffa027db18>] netdev_frame_hook+0xb8/0x120 [openvswitch] [<ffffffffa027da60>] ? free_port_rcu+0x30/0x30 [openvswitch] [<ffffffff81539318>] __netif_receive_skb+0x1c8/0x620 [<ffffffff8153a4c0>] netif_receive_skb+0x80/0x90 [<ffffffff8115f14c>] ? ksize+0x1c/0xc0 [<ffffffff8153a610>] napi_skb_finish+0x50/0x70 [<ffffffff8153ac15>] napi_gro_receive+0xf5/0x140 [<ffffffffa00368ae>] vmxnet3_rq_rx_complete+0x51e/0x7c0 [vmxnet3] [<ffffffff8101ac90>] ? nommu_map_sg+0xe0/0xe0 [<ffffffffa0036da5>] vmxnet3_poll_rx_only+0x45/0xc0 [vmxnet3] [<ffffffff8153ae64>] net_rx_action+0x134/0x290 [<ffffffff8103db0d>] ? __ticket_spin_lock+0xd/0x30 [<ffffffff8106e1a8>] __do_softirq+0xa8/0x210 [<ffffffff8164596e>] ? _raw_spin_lock+0xe/0x20 [<ffffffff8164fd6c>] call_softirq+0x1c/0x30 [<ffffffff81016215>] do_softirq+0x65/0xa0 [<ffffffff8106e58e>] irq_exit+0x8e/0xb0 [<ffffffff81650633>] do_IRQ+0x63/0xe0 [<ffffffff81645e2e>] common_interrupt+0x6e/0x6e ----------- Bug #21853 Reported-by: Pawan Shukla <shuklap@vmware.com> Signed-off-by: Pravin B Shelar <pshelar@nicira.com> Acked-by: Jesse Gross <jesse@nicira.com>
2013-12-17 15:43:30 -08:00
lock_bh = (cpu == cur_cpu);
stats_read(stats, lock_bh, ovs_stats, used, tcp_flags);
}
put_cpu();
}
}
datapath: Fix deadlock during stats update. Stats-read needs to lock stats but same lock is taken in stats update in irq context. Therefore it needs to disable irq to avoid following deadlock :- BUG: soft lockup - CPU#1 stuck for 23s! [ovs-vswitchd:1425] CPU 1 Pid: 1425, comm: ovs-vswitchd Tainted: G O 3.2.39-server-nn23 #1 VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform RIP: 0010:[<ffffffff8103db22>] [<ffffffff8103db22>] __ticket_spin_lock+0x22/0x30 RSP: 0018:ffff88003fd03b30 EFLAGS: 00000297 RAX: 0000000000000001 RBX: 0000000000000000 RCX: 0000000000000050 RDX: 0000000000000002 RSI: ffff88003d0a9900 RDI: ffff88003ae19598 RBP: ffff88003fd03b30 R08: 0000000000000000 R09: ffff88003ad44048 R10: 0000000000000001 R11: 0000000000000001 R12: ffff88003fd03aa8 R13: ffffffff8164e5de R14: ffff88003fd03b30 R15: ffff88003ae19580 FS: 00007ffb0b428940(0000) GS:ffff88003fd00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f3c0ef94000 CR3: 00000000250e2000 CR4: 00000000000006e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Process ovs-vswitchd (pid: 1425, threadinfo ffff88002514a000, task ffff8800250aae00) Stack: ffff88003fd03b40 ffffffff8164596e ffff88003fd03b70 ffffffffa027622d ffff88003d0a9900 ffffe8ffffd03800 ffff8800297f5a80 ffff88003fd03ba8 ffff88003fd03c60 ffffffffa02759af ffff88003fd03de0 ffff88003fd03e4c Call Trace: <IRQ> [<ffffffff8164596e>] _raw_spin_lock+0xe/0x20 [<ffffffffa027622d>] ovs_flow_stats_update+0x5d/0x100 [openvswitch] [<ffffffffa02759af>] ovs_dp_process_received_packet+0x8f/0x130 [openvswitch] [<ffffffffa027c0ca>] ovs_vport_receive+0x2a/0x30 [openvswitch] [<ffffffffa027db18>] netdev_frame_hook+0xb8/0x120 [openvswitch] [<ffffffffa027da60>] ? free_port_rcu+0x30/0x30 [openvswitch] [<ffffffff81539318>] __netif_receive_skb+0x1c8/0x620 [<ffffffff8153a4c0>] netif_receive_skb+0x80/0x90 [<ffffffff8115f14c>] ? ksize+0x1c/0xc0 [<ffffffff8153a610>] napi_skb_finish+0x50/0x70 [<ffffffff8153ac15>] napi_gro_receive+0xf5/0x140 [<ffffffffa00368ae>] vmxnet3_rq_rx_complete+0x51e/0x7c0 [vmxnet3] [<ffffffff8101ac90>] ? nommu_map_sg+0xe0/0xe0 [<ffffffffa0036da5>] vmxnet3_poll_rx_only+0x45/0xc0 [vmxnet3] [<ffffffff8153ae64>] net_rx_action+0x134/0x290 [<ffffffff8103db0d>] ? __ticket_spin_lock+0xd/0x30 [<ffffffff8106e1a8>] __do_softirq+0xa8/0x210 [<ffffffff8164596e>] ? _raw_spin_lock+0xe/0x20 [<ffffffff8164fd6c>] call_softirq+0x1c/0x30 [<ffffffff81016215>] do_softirq+0x65/0xa0 [<ffffffff8106e58e>] irq_exit+0x8e/0xb0 [<ffffffff81650633>] do_IRQ+0x63/0xe0 [<ffffffff81645e2e>] common_interrupt+0x6e/0x6e ----------- Bug #21853 Reported-by: Pawan Shukla <shuklap@vmware.com> Signed-off-by: Pravin B Shelar <pshelar@nicira.com> Acked-by: Jesse Gross <jesse@nicira.com>
2013-12-17 15:43:30 -08:00
static void stats_reset(struct flow_stats *stats, bool lock_bh)
{
datapath: Fix deadlock during stats update. Stats-read needs to lock stats but same lock is taken in stats update in irq context. Therefore it needs to disable irq to avoid following deadlock :- BUG: soft lockup - CPU#1 stuck for 23s! [ovs-vswitchd:1425] CPU 1 Pid: 1425, comm: ovs-vswitchd Tainted: G O 3.2.39-server-nn23 #1 VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform RIP: 0010:[<ffffffff8103db22>] [<ffffffff8103db22>] __ticket_spin_lock+0x22/0x30 RSP: 0018:ffff88003fd03b30 EFLAGS: 00000297 RAX: 0000000000000001 RBX: 0000000000000000 RCX: 0000000000000050 RDX: 0000000000000002 RSI: ffff88003d0a9900 RDI: ffff88003ae19598 RBP: ffff88003fd03b30 R08: 0000000000000000 R09: ffff88003ad44048 R10: 0000000000000001 R11: 0000000000000001 R12: ffff88003fd03aa8 R13: ffffffff8164e5de R14: ffff88003fd03b30 R15: ffff88003ae19580 FS: 00007ffb0b428940(0000) GS:ffff88003fd00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f3c0ef94000 CR3: 00000000250e2000 CR4: 00000000000006e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Process ovs-vswitchd (pid: 1425, threadinfo ffff88002514a000, task ffff8800250aae00) Stack: ffff88003fd03b40 ffffffff8164596e ffff88003fd03b70 ffffffffa027622d ffff88003d0a9900 ffffe8ffffd03800 ffff8800297f5a80 ffff88003fd03ba8 ffff88003fd03c60 ffffffffa02759af ffff88003fd03de0 ffff88003fd03e4c Call Trace: <IRQ> [<ffffffff8164596e>] _raw_spin_lock+0xe/0x20 [<ffffffffa027622d>] ovs_flow_stats_update+0x5d/0x100 [openvswitch] [<ffffffffa02759af>] ovs_dp_process_received_packet+0x8f/0x130 [openvswitch] [<ffffffffa027c0ca>] ovs_vport_receive+0x2a/0x30 [openvswitch] [<ffffffffa027db18>] netdev_frame_hook+0xb8/0x120 [openvswitch] [<ffffffffa027da60>] ? free_port_rcu+0x30/0x30 [openvswitch] [<ffffffff81539318>] __netif_receive_skb+0x1c8/0x620 [<ffffffff8153a4c0>] netif_receive_skb+0x80/0x90 [<ffffffff8115f14c>] ? ksize+0x1c/0xc0 [<ffffffff8153a610>] napi_skb_finish+0x50/0x70 [<ffffffff8153ac15>] napi_gro_receive+0xf5/0x140 [<ffffffffa00368ae>] vmxnet3_rq_rx_complete+0x51e/0x7c0 [vmxnet3] [<ffffffff8101ac90>] ? nommu_map_sg+0xe0/0xe0 [<ffffffffa0036da5>] vmxnet3_poll_rx_only+0x45/0xc0 [vmxnet3] [<ffffffff8153ae64>] net_rx_action+0x134/0x290 [<ffffffff8103db0d>] ? __ticket_spin_lock+0xd/0x30 [<ffffffff8106e1a8>] __do_softirq+0xa8/0x210 [<ffffffff8164596e>] ? _raw_spin_lock+0xe/0x20 [<ffffffff8164fd6c>] call_softirq+0x1c/0x30 [<ffffffff81016215>] do_softirq+0x65/0xa0 [<ffffffff8106e58e>] irq_exit+0x8e/0xb0 [<ffffffff81650633>] do_IRQ+0x63/0xe0 [<ffffffff81645e2e>] common_interrupt+0x6e/0x6e ----------- Bug #21853 Reported-by: Pawan Shukla <shuklap@vmware.com> Signed-off-by: Pravin B Shelar <pshelar@nicira.com> Acked-by: Jesse Gross <jesse@nicira.com>
2013-12-17 15:43:30 -08:00
if (lock_bh)
spin_lock_bh(&stats->lock);
else
spin_lock(&stats->lock);
stats->used = 0;
stats->packet_count = 0;
stats->byte_count = 0;
stats->tcp_flags = 0;
datapath: Fix deadlock during stats update. Stats-read needs to lock stats but same lock is taken in stats update in irq context. Therefore it needs to disable irq to avoid following deadlock :- BUG: soft lockup - CPU#1 stuck for 23s! [ovs-vswitchd:1425] CPU 1 Pid: 1425, comm: ovs-vswitchd Tainted: G O 3.2.39-server-nn23 #1 VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform RIP: 0010:[<ffffffff8103db22>] [<ffffffff8103db22>] __ticket_spin_lock+0x22/0x30 RSP: 0018:ffff88003fd03b30 EFLAGS: 00000297 RAX: 0000000000000001 RBX: 0000000000000000 RCX: 0000000000000050 RDX: 0000000000000002 RSI: ffff88003d0a9900 RDI: ffff88003ae19598 RBP: ffff88003fd03b30 R08: 0000000000000000 R09: ffff88003ad44048 R10: 0000000000000001 R11: 0000000000000001 R12: ffff88003fd03aa8 R13: ffffffff8164e5de R14: ffff88003fd03b30 R15: ffff88003ae19580 FS: 00007ffb0b428940(0000) GS:ffff88003fd00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f3c0ef94000 CR3: 00000000250e2000 CR4: 00000000000006e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Process ovs-vswitchd (pid: 1425, threadinfo ffff88002514a000, task ffff8800250aae00) Stack: ffff88003fd03b40 ffffffff8164596e ffff88003fd03b70 ffffffffa027622d ffff88003d0a9900 ffffe8ffffd03800 ffff8800297f5a80 ffff88003fd03ba8 ffff88003fd03c60 ffffffffa02759af ffff88003fd03de0 ffff88003fd03e4c Call Trace: <IRQ> [<ffffffff8164596e>] _raw_spin_lock+0xe/0x20 [<ffffffffa027622d>] ovs_flow_stats_update+0x5d/0x100 [openvswitch] [<ffffffffa02759af>] ovs_dp_process_received_packet+0x8f/0x130 [openvswitch] [<ffffffffa027c0ca>] ovs_vport_receive+0x2a/0x30 [openvswitch] [<ffffffffa027db18>] netdev_frame_hook+0xb8/0x120 [openvswitch] [<ffffffffa027da60>] ? free_port_rcu+0x30/0x30 [openvswitch] [<ffffffff81539318>] __netif_receive_skb+0x1c8/0x620 [<ffffffff8153a4c0>] netif_receive_skb+0x80/0x90 [<ffffffff8115f14c>] ? ksize+0x1c/0xc0 [<ffffffff8153a610>] napi_skb_finish+0x50/0x70 [<ffffffff8153ac15>] napi_gro_receive+0xf5/0x140 [<ffffffffa00368ae>] vmxnet3_rq_rx_complete+0x51e/0x7c0 [vmxnet3] [<ffffffff8101ac90>] ? nommu_map_sg+0xe0/0xe0 [<ffffffffa0036da5>] vmxnet3_poll_rx_only+0x45/0xc0 [vmxnet3] [<ffffffff8153ae64>] net_rx_action+0x134/0x290 [<ffffffff8103db0d>] ? __ticket_spin_lock+0xd/0x30 [<ffffffff8106e1a8>] __do_softirq+0xa8/0x210 [<ffffffff8164596e>] ? _raw_spin_lock+0xe/0x20 [<ffffffff8164fd6c>] call_softirq+0x1c/0x30 [<ffffffff81016215>] do_softirq+0x65/0xa0 [<ffffffff8106e58e>] irq_exit+0x8e/0xb0 [<ffffffff81650633>] do_IRQ+0x63/0xe0 [<ffffffff81645e2e>] common_interrupt+0x6e/0x6e ----------- Bug #21853 Reported-by: Pawan Shukla <shuklap@vmware.com> Signed-off-by: Pravin B Shelar <pshelar@nicira.com> Acked-by: Jesse Gross <jesse@nicira.com>
2013-12-17 15:43:30 -08:00
if (lock_bh)
spin_unlock_bh(&stats->lock);
else
spin_unlock(&stats->lock);
}
void ovs_flow_stats_clear(struct sw_flow *flow)
{
int cpu, cur_cpu;
if (!flow->stats.is_percpu) {
datapath: Fix deadlock during stats update. Stats-read needs to lock stats but same lock is taken in stats update in irq context. Therefore it needs to disable irq to avoid following deadlock :- BUG: soft lockup - CPU#1 stuck for 23s! [ovs-vswitchd:1425] CPU 1 Pid: 1425, comm: ovs-vswitchd Tainted: G O 3.2.39-server-nn23 #1 VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform RIP: 0010:[<ffffffff8103db22>] [<ffffffff8103db22>] __ticket_spin_lock+0x22/0x30 RSP: 0018:ffff88003fd03b30 EFLAGS: 00000297 RAX: 0000000000000001 RBX: 0000000000000000 RCX: 0000000000000050 RDX: 0000000000000002 RSI: ffff88003d0a9900 RDI: ffff88003ae19598 RBP: ffff88003fd03b30 R08: 0000000000000000 R09: ffff88003ad44048 R10: 0000000000000001 R11: 0000000000000001 R12: ffff88003fd03aa8 R13: ffffffff8164e5de R14: ffff88003fd03b30 R15: ffff88003ae19580 FS: 00007ffb0b428940(0000) GS:ffff88003fd00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f3c0ef94000 CR3: 00000000250e2000 CR4: 00000000000006e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Process ovs-vswitchd (pid: 1425, threadinfo ffff88002514a000, task ffff8800250aae00) Stack: ffff88003fd03b40 ffffffff8164596e ffff88003fd03b70 ffffffffa027622d ffff88003d0a9900 ffffe8ffffd03800 ffff8800297f5a80 ffff88003fd03ba8 ffff88003fd03c60 ffffffffa02759af ffff88003fd03de0 ffff88003fd03e4c Call Trace: <IRQ> [<ffffffff8164596e>] _raw_spin_lock+0xe/0x20 [<ffffffffa027622d>] ovs_flow_stats_update+0x5d/0x100 [openvswitch] [<ffffffffa02759af>] ovs_dp_process_received_packet+0x8f/0x130 [openvswitch] [<ffffffffa027c0ca>] ovs_vport_receive+0x2a/0x30 [openvswitch] [<ffffffffa027db18>] netdev_frame_hook+0xb8/0x120 [openvswitch] [<ffffffffa027da60>] ? free_port_rcu+0x30/0x30 [openvswitch] [<ffffffff81539318>] __netif_receive_skb+0x1c8/0x620 [<ffffffff8153a4c0>] netif_receive_skb+0x80/0x90 [<ffffffff8115f14c>] ? ksize+0x1c/0xc0 [<ffffffff8153a610>] napi_skb_finish+0x50/0x70 [<ffffffff8153ac15>] napi_gro_receive+0xf5/0x140 [<ffffffffa00368ae>] vmxnet3_rq_rx_complete+0x51e/0x7c0 [vmxnet3] [<ffffffff8101ac90>] ? nommu_map_sg+0xe0/0xe0 [<ffffffffa0036da5>] vmxnet3_poll_rx_only+0x45/0xc0 [vmxnet3] [<ffffffff8153ae64>] net_rx_action+0x134/0x290 [<ffffffff8103db0d>] ? __ticket_spin_lock+0xd/0x30 [<ffffffff8106e1a8>] __do_softirq+0xa8/0x210 [<ffffffff8164596e>] ? _raw_spin_lock+0xe/0x20 [<ffffffff8164fd6c>] call_softirq+0x1c/0x30 [<ffffffff81016215>] do_softirq+0x65/0xa0 [<ffffffff8106e58e>] irq_exit+0x8e/0xb0 [<ffffffff81650633>] do_IRQ+0x63/0xe0 [<ffffffff81645e2e>] common_interrupt+0x6e/0x6e ----------- Bug #21853 Reported-by: Pawan Shukla <shuklap@vmware.com> Signed-off-by: Pravin B Shelar <pshelar@nicira.com> Acked-by: Jesse Gross <jesse@nicira.com>
2013-12-17 15:43:30 -08:00
stats_reset(flow->stats.stat, true);
} else {
cur_cpu = get_cpu();
for_each_possible_cpu(cpu) {
datapath: Fix deadlock during stats update. Stats-read needs to lock stats but same lock is taken in stats update in irq context. Therefore it needs to disable irq to avoid following deadlock :- BUG: soft lockup - CPU#1 stuck for 23s! [ovs-vswitchd:1425] CPU 1 Pid: 1425, comm: ovs-vswitchd Tainted: G O 3.2.39-server-nn23 #1 VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform RIP: 0010:[<ffffffff8103db22>] [<ffffffff8103db22>] __ticket_spin_lock+0x22/0x30 RSP: 0018:ffff88003fd03b30 EFLAGS: 00000297 RAX: 0000000000000001 RBX: 0000000000000000 RCX: 0000000000000050 RDX: 0000000000000002 RSI: ffff88003d0a9900 RDI: ffff88003ae19598 RBP: ffff88003fd03b30 R08: 0000000000000000 R09: ffff88003ad44048 R10: 0000000000000001 R11: 0000000000000001 R12: ffff88003fd03aa8 R13: ffffffff8164e5de R14: ffff88003fd03b30 R15: ffff88003ae19580 FS: 00007ffb0b428940(0000) GS:ffff88003fd00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f3c0ef94000 CR3: 00000000250e2000 CR4: 00000000000006e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Process ovs-vswitchd (pid: 1425, threadinfo ffff88002514a000, task ffff8800250aae00) Stack: ffff88003fd03b40 ffffffff8164596e ffff88003fd03b70 ffffffffa027622d ffff88003d0a9900 ffffe8ffffd03800 ffff8800297f5a80 ffff88003fd03ba8 ffff88003fd03c60 ffffffffa02759af ffff88003fd03de0 ffff88003fd03e4c Call Trace: <IRQ> [<ffffffff8164596e>] _raw_spin_lock+0xe/0x20 [<ffffffffa027622d>] ovs_flow_stats_update+0x5d/0x100 [openvswitch] [<ffffffffa02759af>] ovs_dp_process_received_packet+0x8f/0x130 [openvswitch] [<ffffffffa027c0ca>] ovs_vport_receive+0x2a/0x30 [openvswitch] [<ffffffffa027db18>] netdev_frame_hook+0xb8/0x120 [openvswitch] [<ffffffffa027da60>] ? free_port_rcu+0x30/0x30 [openvswitch] [<ffffffff81539318>] __netif_receive_skb+0x1c8/0x620 [<ffffffff8153a4c0>] netif_receive_skb+0x80/0x90 [<ffffffff8115f14c>] ? ksize+0x1c/0xc0 [<ffffffff8153a610>] napi_skb_finish+0x50/0x70 [<ffffffff8153ac15>] napi_gro_receive+0xf5/0x140 [<ffffffffa00368ae>] vmxnet3_rq_rx_complete+0x51e/0x7c0 [vmxnet3] [<ffffffff8101ac90>] ? nommu_map_sg+0xe0/0xe0 [<ffffffffa0036da5>] vmxnet3_poll_rx_only+0x45/0xc0 [vmxnet3] [<ffffffff8153ae64>] net_rx_action+0x134/0x290 [<ffffffff8103db0d>] ? __ticket_spin_lock+0xd/0x30 [<ffffffff8106e1a8>] __do_softirq+0xa8/0x210 [<ffffffff8164596e>] ? _raw_spin_lock+0xe/0x20 [<ffffffff8164fd6c>] call_softirq+0x1c/0x30 [<ffffffff81016215>] do_softirq+0x65/0xa0 [<ffffffff8106e58e>] irq_exit+0x8e/0xb0 [<ffffffff81650633>] do_IRQ+0x63/0xe0 [<ffffffff81645e2e>] common_interrupt+0x6e/0x6e ----------- Bug #21853 Reported-by: Pawan Shukla <shuklap@vmware.com> Signed-off-by: Pravin B Shelar <pshelar@nicira.com> Acked-by: Jesse Gross <jesse@nicira.com>
2013-12-17 15:43:30 -08:00
bool lock_bh;
datapath: Fix deadlock during stats update. Stats-read needs to lock stats but same lock is taken in stats update in irq context. Therefore it needs to disable irq to avoid following deadlock :- BUG: soft lockup - CPU#1 stuck for 23s! [ovs-vswitchd:1425] CPU 1 Pid: 1425, comm: ovs-vswitchd Tainted: G O 3.2.39-server-nn23 #1 VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform RIP: 0010:[<ffffffff8103db22>] [<ffffffff8103db22>] __ticket_spin_lock+0x22/0x30 RSP: 0018:ffff88003fd03b30 EFLAGS: 00000297 RAX: 0000000000000001 RBX: 0000000000000000 RCX: 0000000000000050 RDX: 0000000000000002 RSI: ffff88003d0a9900 RDI: ffff88003ae19598 RBP: ffff88003fd03b30 R08: 0000000000000000 R09: ffff88003ad44048 R10: 0000000000000001 R11: 0000000000000001 R12: ffff88003fd03aa8 R13: ffffffff8164e5de R14: ffff88003fd03b30 R15: ffff88003ae19580 FS: 00007ffb0b428940(0000) GS:ffff88003fd00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f3c0ef94000 CR3: 00000000250e2000 CR4: 00000000000006e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Process ovs-vswitchd (pid: 1425, threadinfo ffff88002514a000, task ffff8800250aae00) Stack: ffff88003fd03b40 ffffffff8164596e ffff88003fd03b70 ffffffffa027622d ffff88003d0a9900 ffffe8ffffd03800 ffff8800297f5a80 ffff88003fd03ba8 ffff88003fd03c60 ffffffffa02759af ffff88003fd03de0 ffff88003fd03e4c Call Trace: <IRQ> [<ffffffff8164596e>] _raw_spin_lock+0xe/0x20 [<ffffffffa027622d>] ovs_flow_stats_update+0x5d/0x100 [openvswitch] [<ffffffffa02759af>] ovs_dp_process_received_packet+0x8f/0x130 [openvswitch] [<ffffffffa027c0ca>] ovs_vport_receive+0x2a/0x30 [openvswitch] [<ffffffffa027db18>] netdev_frame_hook+0xb8/0x120 [openvswitch] [<ffffffffa027da60>] ? free_port_rcu+0x30/0x30 [openvswitch] [<ffffffff81539318>] __netif_receive_skb+0x1c8/0x620 [<ffffffff8153a4c0>] netif_receive_skb+0x80/0x90 [<ffffffff8115f14c>] ? ksize+0x1c/0xc0 [<ffffffff8153a610>] napi_skb_finish+0x50/0x70 [<ffffffff8153ac15>] napi_gro_receive+0xf5/0x140 [<ffffffffa00368ae>] vmxnet3_rq_rx_complete+0x51e/0x7c0 [vmxnet3] [<ffffffff8101ac90>] ? nommu_map_sg+0xe0/0xe0 [<ffffffffa0036da5>] vmxnet3_poll_rx_only+0x45/0xc0 [vmxnet3] [<ffffffff8153ae64>] net_rx_action+0x134/0x290 [<ffffffff8103db0d>] ? __ticket_spin_lock+0xd/0x30 [<ffffffff8106e1a8>] __do_softirq+0xa8/0x210 [<ffffffff8164596e>] ? _raw_spin_lock+0xe/0x20 [<ffffffff8164fd6c>] call_softirq+0x1c/0x30 [<ffffffff81016215>] do_softirq+0x65/0xa0 [<ffffffff8106e58e>] irq_exit+0x8e/0xb0 [<ffffffff81650633>] do_IRQ+0x63/0xe0 [<ffffffff81645e2e>] common_interrupt+0x6e/0x6e ----------- Bug #21853 Reported-by: Pawan Shukla <shuklap@vmware.com> Signed-off-by: Pravin B Shelar <pshelar@nicira.com> Acked-by: Jesse Gross <jesse@nicira.com>
2013-12-17 15:43:30 -08:00
lock_bh = (cpu == cur_cpu);
stats_reset(per_cpu_ptr(flow->stats.cpu_stats, cpu), lock_bh);
}
put_cpu();
}
}
static int check_header(struct sk_buff *skb, int len)
{
if (unlikely(skb->len < len))
return -EINVAL;
if (unlikely(!pskb_may_pull(skb, len)))
return -ENOMEM;
return 0;
}
static bool arphdr_ok(struct sk_buff *skb)
{
return pskb_may_pull(skb, skb_network_offset(skb) +
sizeof(struct arp_eth_header));
}
static int check_iphdr(struct sk_buff *skb)
{
unsigned int nh_ofs = skb_network_offset(skb);
unsigned int ip_len;
int err;
err = check_header(skb, nh_ofs + sizeof(struct iphdr));
if (unlikely(err))
return err;
ip_len = ip_hdrlen(skb);
if (unlikely(ip_len < sizeof(struct iphdr) ||
skb->len < nh_ofs + ip_len))
return -EINVAL;
skb_set_transport_header(skb, nh_ofs + ip_len);
return 0;
}
static bool tcphdr_ok(struct sk_buff *skb)
{
int th_ofs = skb_transport_offset(skb);
int tcp_len;
if (unlikely(!pskb_may_pull(skb, th_ofs + sizeof(struct tcphdr))))
return false;
tcp_len = tcp_hdrlen(skb);
if (unlikely(tcp_len < sizeof(struct tcphdr) ||
skb->len < th_ofs + tcp_len))
return false;
return true;
}
static bool udphdr_ok(struct sk_buff *skb)
{
return pskb_may_pull(skb, skb_transport_offset(skb) +
sizeof(struct udphdr));
}
static bool sctphdr_ok(struct sk_buff *skb)
{
return pskb_may_pull(skb, skb_transport_offset(skb) +
sizeof(struct sctphdr));
}
static bool icmphdr_ok(struct sk_buff *skb)
{
return pskb_may_pull(skb, skb_transport_offset(skb) +
sizeof(struct icmphdr));
}
static int parse_ipv6hdr(struct sk_buff *skb, struct sw_flow_key *key)
{
unsigned int nh_ofs = skb_network_offset(skb);
unsigned int nh_len;
int payload_ofs;
struct ipv6hdr *nh;
uint8_t nexthdr;
__be16 frag_off;
int err;
err = check_header(skb, nh_ofs + sizeof(*nh));
if (unlikely(err))
return err;
nh = ipv6_hdr(skb);
nexthdr = nh->nexthdr;
payload_ofs = (u8 *)(nh + 1) - skb->data;
key->ip.proto = NEXTHDR_NONE;
key->ip.tos = ipv6_get_dsfield(nh);
key->ip.ttl = nh->hop_limit;
key->ipv6.label = *(__be32 *)nh & htonl(IPV6_FLOWINFO_FLOWLABEL);
key->ipv6.addr.src = nh->saddr;
key->ipv6.addr.dst = nh->daddr;
payload_ofs = ipv6_skip_exthdr(skb, payload_ofs, &nexthdr, &frag_off);
if (unlikely(payload_ofs < 0))
return -EINVAL;
if (frag_off) {
if (frag_off & htons(~0x7))
key->ip.frag = OVS_FRAG_TYPE_LATER;
else
key->ip.frag = OVS_FRAG_TYPE_FIRST;
}
nh_len = payload_ofs - nh_ofs;
skb_set_transport_header(skb, nh_ofs + nh_len);
key->ip.proto = nexthdr;
return nh_len;
}
static bool icmp6hdr_ok(struct sk_buff *skb)
{
return pskb_may_pull(skb, skb_transport_offset(skb) +
sizeof(struct icmp6hdr));
}
static int parse_vlan(struct sk_buff *skb, struct sw_flow_key *key)
{
datapath: Fix handling of 802.1Q and SNAP headers. The kernel and user datapaths have code that assumes that 802.1Q headers are used only inside Ethernet II frames, not inside SNAP-encapsulated frames. But the kernel and user flow_extract() implementations would interpret 802.1Q headers inside SNAP headers as being valid VLANs. This would cause packet corruption if any VLAN-related actions were to be taken, so change the two flow_extract() implementations only to accept 802.1Q as an Ethernet II frame type, not as a SNAP-encoded frame type. 802.1Q-2005 says that this is correct anyhow: Where the ISS instance used to transmit and receive tagged frames is provided by a media access control method that can support Ethernet Type encoding directly (e.g., is an IEEE 802.3 or IEEE 802.11 MAC) or is media access method independent (e.g., 6.6), the TPID is Ethernet Type encoded, i.e., is two octets in length and comprises solely the assigned Ethernet Type value. Where the ISS instance is provided by a media access method that cannot directly support Ethernet Type encoding (e.g., is an IEEE 802.5 or FDDI MAC), the TPID is encoded according to the rule for a Subnetwork Access Protocol (Clause 10 of IEEE Std 802) that encapsulates Ethernet frames over LLC, and comprises the SNAP header (AA-AA-03) followed by the SNAP PID (00-00-00) followed by the two octets of the assigned Ethernet Type value. All of the media that OVS handles supports Ethernet Type fields, so to me that means that we don't have to handle 802.1Q-inside-SNAP. On the other hand, we *do* have to handle SNAP-inside-802.1Q, because this is actually allowed by the standards. So this commit also adds that support. I verified that, with this change, both SNAP and Ethernet packets are properly recognized both with and without 802.1Q encapsulation. I was a bit surprised to find out that Linux does not accept SNAP-encapsulated IP frames on Ethernet. Here's a summary of how frames are handled before and after this commit: Common cases ------------ Ethernet +------------+ 1. |dst|src|TYPE| +------------+ Ethernet LLC SNAP +------------+ +--------+ +-----------+ 2. |dst|src| len| |aa|aa|03| |000000|TYPE| +------------+ +--------+ +-----------+ Ethernet 802.1Q +------------+ +---------+ 3. |dst|src|8100| |VLAN|TYPE| +------------+ +---------+ Ethernet 802.1Q LLC SNAP +------------+ +---------+ +--------+ +-----------+ 4. |dst|src|8100| |VLAN| LEN| |aa|aa|03| |000000|TYPE| +------------+ +---------+ +--------+ +-----------+ Unusual cases ------------- Ethernet LLC SNAP 802.1Q +------------+ +--------+ +-----------+ +---------+ 5. |dst|src| len| |aa|aa|03| |000000|8100| |VLAN|TYPE| +------------+ +--------+ +-----------+ +---------+ Ethernet LLC +------------+ +--------+ 6. |dst|src| len| |xx|xx|xx| +------------+ +--------+ Ethernet LLC SNAP +------------+ +--------+ +-----------+ 7. |dst|src| len| |aa|aa|03| |xxxxxx|xxxx| +------------+ +--------+ +-----------+ Ethernet 802.1Q LLC +------------+ +---------+ +--------+ 8. |dst|src|8100| |VLAN| LEN| |xx|xx|xx| +------------+ +---------+ +--------+ Ethernet 802.1Q LLC SNAP +------------+ +---------+ +--------+ +-----------+ 9. |dst|src|8100| |VLAN| LEN| |aa|aa|03| |xxxxxx|xxxx| +------------+ +---------+ +--------+ +-----------+ Behavior -------- --------------- --------------- ------------------------------------- Before After this commit this commit dl_type dl_vlan dl_type dl_vlan Notes ------- ------- ------- ------- ------------------------------------- 1. TYPE ffff TYPE ffff no change 2. TYPE ffff TYPE ffff no change 3. TYPE VLAN TYPE VLAN no change 4. LEN VLAN TYPE VLAN proposal fixes behavior 5. TYPE VLAN 8100 ffff 802.1Q says this is invalid framing 6. 05ff ffff 05ff ffff no change 7. 05ff ffff 05ff ffff no change 8. LEN VLAN 05ff VLAN proposal fixes behavior 9. LEN VLAN 05ff VLAN proposal fixes behavior Signed-off-by: Ben Pfaff <blp@nicira.com>
2010-08-10 11:35:46 -07:00
struct qtag_prefix {
__be16 eth_type; /* ETH_P_8021Q */
__be16 tci;
};
struct qtag_prefix *qp;
if (unlikely(skb->len < sizeof(struct qtag_prefix) + sizeof(__be16)))
return 0;
if (unlikely(!pskb_may_pull(skb, sizeof(struct qtag_prefix) +
sizeof(__be16))))
return -ENOMEM;
datapath: Fix handling of 802.1Q and SNAP headers. The kernel and user datapaths have code that assumes that 802.1Q headers are used only inside Ethernet II frames, not inside SNAP-encapsulated frames. But the kernel and user flow_extract() implementations would interpret 802.1Q headers inside SNAP headers as being valid VLANs. This would cause packet corruption if any VLAN-related actions were to be taken, so change the two flow_extract() implementations only to accept 802.1Q as an Ethernet II frame type, not as a SNAP-encoded frame type. 802.1Q-2005 says that this is correct anyhow: Where the ISS instance used to transmit and receive tagged frames is provided by a media access control method that can support Ethernet Type encoding directly (e.g., is an IEEE 802.3 or IEEE 802.11 MAC) or is media access method independent (e.g., 6.6), the TPID is Ethernet Type encoded, i.e., is two octets in length and comprises solely the assigned Ethernet Type value. Where the ISS instance is provided by a media access method that cannot directly support Ethernet Type encoding (e.g., is an IEEE 802.5 or FDDI MAC), the TPID is encoded according to the rule for a Subnetwork Access Protocol (Clause 10 of IEEE Std 802) that encapsulates Ethernet frames over LLC, and comprises the SNAP header (AA-AA-03) followed by the SNAP PID (00-00-00) followed by the two octets of the assigned Ethernet Type value. All of the media that OVS handles supports Ethernet Type fields, so to me that means that we don't have to handle 802.1Q-inside-SNAP. On the other hand, we *do* have to handle SNAP-inside-802.1Q, because this is actually allowed by the standards. So this commit also adds that support. I verified that, with this change, both SNAP and Ethernet packets are properly recognized both with and without 802.1Q encapsulation. I was a bit surprised to find out that Linux does not accept SNAP-encapsulated IP frames on Ethernet. Here's a summary of how frames are handled before and after this commit: Common cases ------------ Ethernet +------------+ 1. |dst|src|TYPE| +------------+ Ethernet LLC SNAP +------------+ +--------+ +-----------+ 2. |dst|src| len| |aa|aa|03| |000000|TYPE| +------------+ +--------+ +-----------+ Ethernet 802.1Q +------------+ +---------+ 3. |dst|src|8100| |VLAN|TYPE| +------------+ +---------+ Ethernet 802.1Q LLC SNAP +------------+ +---------+ +--------+ +-----------+ 4. |dst|src|8100| |VLAN| LEN| |aa|aa|03| |000000|TYPE| +------------+ +---------+ +--------+ +-----------+ Unusual cases ------------- Ethernet LLC SNAP 802.1Q +------------+ +--------+ +-----------+ +---------+ 5. |dst|src| len| |aa|aa|03| |000000|8100| |VLAN|TYPE| +------------+ +--------+ +-----------+ +---------+ Ethernet LLC +------------+ +--------+ 6. |dst|src| len| |xx|xx|xx| +------------+ +--------+ Ethernet LLC SNAP +------------+ +--------+ +-----------+ 7. |dst|src| len| |aa|aa|03| |xxxxxx|xxxx| +------------+ +--------+ +-----------+ Ethernet 802.1Q LLC +------------+ +---------+ +--------+ 8. |dst|src|8100| |VLAN| LEN| |xx|xx|xx| +------------+ +---------+ +--------+ Ethernet 802.1Q LLC SNAP +------------+ +---------+ +--------+ +-----------+ 9. |dst|src|8100| |VLAN| LEN| |aa|aa|03| |xxxxxx|xxxx| +------------+ +---------+ +--------+ +-----------+ Behavior -------- --------------- --------------- ------------------------------------- Before After this commit this commit dl_type dl_vlan dl_type dl_vlan Notes ------- ------- ------- ------- ------------------------------------- 1. TYPE ffff TYPE ffff no change 2. TYPE ffff TYPE ffff no change 3. TYPE VLAN TYPE VLAN no change 4. LEN VLAN TYPE VLAN proposal fixes behavior 5. TYPE VLAN 8100 ffff 802.1Q says this is invalid framing 6. 05ff ffff 05ff ffff no change 7. 05ff ffff 05ff ffff no change 8. LEN VLAN 05ff VLAN proposal fixes behavior 9. LEN VLAN 05ff VLAN proposal fixes behavior Signed-off-by: Ben Pfaff <blp@nicira.com>
2010-08-10 11:35:46 -07:00
qp = (struct qtag_prefix *) skb->data;
key->eth.tci = qp->tci | htons(VLAN_TAG_PRESENT);
datapath: Fix handling of 802.1Q and SNAP headers. The kernel and user datapaths have code that assumes that 802.1Q headers are used only inside Ethernet II frames, not inside SNAP-encapsulated frames. But the kernel and user flow_extract() implementations would interpret 802.1Q headers inside SNAP headers as being valid VLANs. This would cause packet corruption if any VLAN-related actions were to be taken, so change the two flow_extract() implementations only to accept 802.1Q as an Ethernet II frame type, not as a SNAP-encoded frame type. 802.1Q-2005 says that this is correct anyhow: Where the ISS instance used to transmit and receive tagged frames is provided by a media access control method that can support Ethernet Type encoding directly (e.g., is an IEEE 802.3 or IEEE 802.11 MAC) or is media access method independent (e.g., 6.6), the TPID is Ethernet Type encoded, i.e., is two octets in length and comprises solely the assigned Ethernet Type value. Where the ISS instance is provided by a media access method that cannot directly support Ethernet Type encoding (e.g., is an IEEE 802.5 or FDDI MAC), the TPID is encoded according to the rule for a Subnetwork Access Protocol (Clause 10 of IEEE Std 802) that encapsulates Ethernet frames over LLC, and comprises the SNAP header (AA-AA-03) followed by the SNAP PID (00-00-00) followed by the two octets of the assigned Ethernet Type value. All of the media that OVS handles supports Ethernet Type fields, so to me that means that we don't have to handle 802.1Q-inside-SNAP. On the other hand, we *do* have to handle SNAP-inside-802.1Q, because this is actually allowed by the standards. So this commit also adds that support. I verified that, with this change, both SNAP and Ethernet packets are properly recognized both with and without 802.1Q encapsulation. I was a bit surprised to find out that Linux does not accept SNAP-encapsulated IP frames on Ethernet. Here's a summary of how frames are handled before and after this commit: Common cases ------------ Ethernet +------------+ 1. |dst|src|TYPE| +------------+ Ethernet LLC SNAP +------------+ +--------+ +-----------+ 2. |dst|src| len| |aa|aa|03| |000000|TYPE| +------------+ +--------+ +-----------+ Ethernet 802.1Q +------------+ +---------+ 3. |dst|src|8100| |VLAN|TYPE| +------------+ +---------+ Ethernet 802.1Q LLC SNAP +------------+ +---------+ +--------+ +-----------+ 4. |dst|src|8100| |VLAN| LEN| |aa|aa|03| |000000|TYPE| +------------+ +---------+ +--------+ +-----------+ Unusual cases ------------- Ethernet LLC SNAP 802.1Q +------------+ +--------+ +-----------+ +---------+ 5. |dst|src| len| |aa|aa|03| |000000|8100| |VLAN|TYPE| +------------+ +--------+ +-----------+ +---------+ Ethernet LLC +------------+ +--------+ 6. |dst|src| len| |xx|xx|xx| +------------+ +--------+ Ethernet LLC SNAP +------------+ +--------+ +-----------+ 7. |dst|src| len| |aa|aa|03| |xxxxxx|xxxx| +------------+ +--------+ +-----------+ Ethernet 802.1Q LLC +------------+ +---------+ +--------+ 8. |dst|src|8100| |VLAN| LEN| |xx|xx|xx| +------------+ +---------+ +--------+ Ethernet 802.1Q LLC SNAP +------------+ +---------+ +--------+ +-----------+ 9. |dst|src|8100| |VLAN| LEN| |aa|aa|03| |xxxxxx|xxxx| +------------+ +---------+ +--------+ +-----------+ Behavior -------- --------------- --------------- ------------------------------------- Before After this commit this commit dl_type dl_vlan dl_type dl_vlan Notes ------- ------- ------- ------- ------------------------------------- 1. TYPE ffff TYPE ffff no change 2. TYPE ffff TYPE ffff no change 3. TYPE VLAN TYPE VLAN no change 4. LEN VLAN TYPE VLAN proposal fixes behavior 5. TYPE VLAN 8100 ffff 802.1Q says this is invalid framing 6. 05ff ffff 05ff ffff no change 7. 05ff ffff 05ff ffff no change 8. LEN VLAN 05ff VLAN proposal fixes behavior 9. LEN VLAN 05ff VLAN proposal fixes behavior Signed-off-by: Ben Pfaff <blp@nicira.com>
2010-08-10 11:35:46 -07:00
__skb_pull(skb, sizeof(struct qtag_prefix));
return 0;
datapath: Fix handling of 802.1Q and SNAP headers. The kernel and user datapaths have code that assumes that 802.1Q headers are used only inside Ethernet II frames, not inside SNAP-encapsulated frames. But the kernel and user flow_extract() implementations would interpret 802.1Q headers inside SNAP headers as being valid VLANs. This would cause packet corruption if any VLAN-related actions were to be taken, so change the two flow_extract() implementations only to accept 802.1Q as an Ethernet II frame type, not as a SNAP-encoded frame type. 802.1Q-2005 says that this is correct anyhow: Where the ISS instance used to transmit and receive tagged frames is provided by a media access control method that can support Ethernet Type encoding directly (e.g., is an IEEE 802.3 or IEEE 802.11 MAC) or is media access method independent (e.g., 6.6), the TPID is Ethernet Type encoded, i.e., is two octets in length and comprises solely the assigned Ethernet Type value. Where the ISS instance is provided by a media access method that cannot directly support Ethernet Type encoding (e.g., is an IEEE 802.5 or FDDI MAC), the TPID is encoded according to the rule for a Subnetwork Access Protocol (Clause 10 of IEEE Std 802) that encapsulates Ethernet frames over LLC, and comprises the SNAP header (AA-AA-03) followed by the SNAP PID (00-00-00) followed by the two octets of the assigned Ethernet Type value. All of the media that OVS handles supports Ethernet Type fields, so to me that means that we don't have to handle 802.1Q-inside-SNAP. On the other hand, we *do* have to handle SNAP-inside-802.1Q, because this is actually allowed by the standards. So this commit also adds that support. I verified that, with this change, both SNAP and Ethernet packets are properly recognized both with and without 802.1Q encapsulation. I was a bit surprised to find out that Linux does not accept SNAP-encapsulated IP frames on Ethernet. Here's a summary of how frames are handled before and after this commit: Common cases ------------ Ethernet +------------+ 1. |dst|src|TYPE| +------------+ Ethernet LLC SNAP +------------+ +--------+ +-----------+ 2. |dst|src| len| |aa|aa|03| |000000|TYPE| +------------+ +--------+ +-----------+ Ethernet 802.1Q +------------+ +---------+ 3. |dst|src|8100| |VLAN|TYPE| +------------+ +---------+ Ethernet 802.1Q LLC SNAP +------------+ +---------+ +--------+ +-----------+ 4. |dst|src|8100| |VLAN| LEN| |aa|aa|03| |000000|TYPE| +------------+ +---------+ +--------+ +-----------+ Unusual cases ------------- Ethernet LLC SNAP 802.1Q +------------+ +--------+ +-----------+ +---------+ 5. |dst|src| len| |aa|aa|03| |000000|8100| |VLAN|TYPE| +------------+ +--------+ +-----------+ +---------+ Ethernet LLC +------------+ +--------+ 6. |dst|src| len| |xx|xx|xx| +------------+ +--------+ Ethernet LLC SNAP +------------+ +--------+ +-----------+ 7. |dst|src| len| |aa|aa|03| |xxxxxx|xxxx| +------------+ +--------+ +-----------+ Ethernet 802.1Q LLC +------------+ +---------+ +--------+ 8. |dst|src|8100| |VLAN| LEN| |xx|xx|xx| +------------+ +---------+ +--------+ Ethernet 802.1Q LLC SNAP +------------+ +---------+ +--------+ +-----------+ 9. |dst|src|8100| |VLAN| LEN| |aa|aa|03| |xxxxxx|xxxx| +------------+ +---------+ +--------+ +-----------+ Behavior -------- --------------- --------------- ------------------------------------- Before After this commit this commit dl_type dl_vlan dl_type dl_vlan Notes ------- ------- ------- ------- ------------------------------------- 1. TYPE ffff TYPE ffff no change 2. TYPE ffff TYPE ffff no change 3. TYPE VLAN TYPE VLAN no change 4. LEN VLAN TYPE VLAN proposal fixes behavior 5. TYPE VLAN 8100 ffff 802.1Q says this is invalid framing 6. 05ff ffff 05ff ffff no change 7. 05ff ffff 05ff ffff no change 8. LEN VLAN 05ff VLAN proposal fixes behavior 9. LEN VLAN 05ff VLAN proposal fixes behavior Signed-off-by: Ben Pfaff <blp@nicira.com>
2010-08-10 11:35:46 -07:00
}
static __be16 parse_ethertype(struct sk_buff *skb)
{
datapath: Fix handling of 802.1Q and SNAP headers. The kernel and user datapaths have code that assumes that 802.1Q headers are used only inside Ethernet II frames, not inside SNAP-encapsulated frames. But the kernel and user flow_extract() implementations would interpret 802.1Q headers inside SNAP headers as being valid VLANs. This would cause packet corruption if any VLAN-related actions were to be taken, so change the two flow_extract() implementations only to accept 802.1Q as an Ethernet II frame type, not as a SNAP-encoded frame type. 802.1Q-2005 says that this is correct anyhow: Where the ISS instance used to transmit and receive tagged frames is provided by a media access control method that can support Ethernet Type encoding directly (e.g., is an IEEE 802.3 or IEEE 802.11 MAC) or is media access method independent (e.g., 6.6), the TPID is Ethernet Type encoded, i.e., is two octets in length and comprises solely the assigned Ethernet Type value. Where the ISS instance is provided by a media access method that cannot directly support Ethernet Type encoding (e.g., is an IEEE 802.5 or FDDI MAC), the TPID is encoded according to the rule for a Subnetwork Access Protocol (Clause 10 of IEEE Std 802) that encapsulates Ethernet frames over LLC, and comprises the SNAP header (AA-AA-03) followed by the SNAP PID (00-00-00) followed by the two octets of the assigned Ethernet Type value. All of the media that OVS handles supports Ethernet Type fields, so to me that means that we don't have to handle 802.1Q-inside-SNAP. On the other hand, we *do* have to handle SNAP-inside-802.1Q, because this is actually allowed by the standards. So this commit also adds that support. I verified that, with this change, both SNAP and Ethernet packets are properly recognized both with and without 802.1Q encapsulation. I was a bit surprised to find out that Linux does not accept SNAP-encapsulated IP frames on Ethernet. Here's a summary of how frames are handled before and after this commit: Common cases ------------ Ethernet +------------+ 1. |dst|src|TYPE| +------------+ Ethernet LLC SNAP +------------+ +--------+ +-----------+ 2. |dst|src| len| |aa|aa|03| |000000|TYPE| +------------+ +--------+ +-----------+ Ethernet 802.1Q +------------+ +---------+ 3. |dst|src|8100| |VLAN|TYPE| +------------+ +---------+ Ethernet 802.1Q LLC SNAP +------------+ +---------+ +--------+ +-----------+ 4. |dst|src|8100| |VLAN| LEN| |aa|aa|03| |000000|TYPE| +------------+ +---------+ +--------+ +-----------+ Unusual cases ------------- Ethernet LLC SNAP 802.1Q +------------+ +--------+ +-----------+ +---------+ 5. |dst|src| len| |aa|aa|03| |000000|8100| |VLAN|TYPE| +------------+ +--------+ +-----------+ +---------+ Ethernet LLC +------------+ +--------+ 6. |dst|src| len| |xx|xx|xx| +------------+ +--------+ Ethernet LLC SNAP +------------+ +--------+ +-----------+ 7. |dst|src| len| |aa|aa|03| |xxxxxx|xxxx| +------------+ +--------+ +-----------+ Ethernet 802.1Q LLC +------------+ +---------+ +--------+ 8. |dst|src|8100| |VLAN| LEN| |xx|xx|xx| +------------+ +---------+ +--------+ Ethernet 802.1Q LLC SNAP +------------+ +---------+ +--------+ +-----------+ 9. |dst|src|8100| |VLAN| LEN| |aa|aa|03| |xxxxxx|xxxx| +------------+ +---------+ +--------+ +-----------+ Behavior -------- --------------- --------------- ------------------------------------- Before After this commit this commit dl_type dl_vlan dl_type dl_vlan Notes ------- ------- ------- ------- ------------------------------------- 1. TYPE ffff TYPE ffff no change 2. TYPE ffff TYPE ffff no change 3. TYPE VLAN TYPE VLAN no change 4. LEN VLAN TYPE VLAN proposal fixes behavior 5. TYPE VLAN 8100 ffff 802.1Q says this is invalid framing 6. 05ff ffff 05ff ffff no change 7. 05ff ffff 05ff ffff no change 8. LEN VLAN 05ff VLAN proposal fixes behavior 9. LEN VLAN 05ff VLAN proposal fixes behavior Signed-off-by: Ben Pfaff <blp@nicira.com>
2010-08-10 11:35:46 -07:00
struct llc_snap_hdr {
u8 dsap; /* Always 0xAA */
u8 ssap; /* Always 0xAA */
u8 ctrl;
u8 oui[3];
__be16 ethertype;
datapath: Fix handling of 802.1Q and SNAP headers. The kernel and user datapaths have code that assumes that 802.1Q headers are used only inside Ethernet II frames, not inside SNAP-encapsulated frames. But the kernel and user flow_extract() implementations would interpret 802.1Q headers inside SNAP headers as being valid VLANs. This would cause packet corruption if any VLAN-related actions were to be taken, so change the two flow_extract() implementations only to accept 802.1Q as an Ethernet II frame type, not as a SNAP-encoded frame type. 802.1Q-2005 says that this is correct anyhow: Where the ISS instance used to transmit and receive tagged frames is provided by a media access control method that can support Ethernet Type encoding directly (e.g., is an IEEE 802.3 or IEEE 802.11 MAC) or is media access method independent (e.g., 6.6), the TPID is Ethernet Type encoded, i.e., is two octets in length and comprises solely the assigned Ethernet Type value. Where the ISS instance is provided by a media access method that cannot directly support Ethernet Type encoding (e.g., is an IEEE 802.5 or FDDI MAC), the TPID is encoded according to the rule for a Subnetwork Access Protocol (Clause 10 of IEEE Std 802) that encapsulates Ethernet frames over LLC, and comprises the SNAP header (AA-AA-03) followed by the SNAP PID (00-00-00) followed by the two octets of the assigned Ethernet Type value. All of the media that OVS handles supports Ethernet Type fields, so to me that means that we don't have to handle 802.1Q-inside-SNAP. On the other hand, we *do* have to handle SNAP-inside-802.1Q, because this is actually allowed by the standards. So this commit also adds that support. I verified that, with this change, both SNAP and Ethernet packets are properly recognized both with and without 802.1Q encapsulation. I was a bit surprised to find out that Linux does not accept SNAP-encapsulated IP frames on Ethernet. Here's a summary of how frames are handled before and after this commit: Common cases ------------ Ethernet +------------+ 1. |dst|src|TYPE| +------------+ Ethernet LLC SNAP +------------+ +--------+ +-----------+ 2. |dst|src| len| |aa|aa|03| |000000|TYPE| +------------+ +--------+ +-----------+ Ethernet 802.1Q +------------+ +---------+ 3. |dst|src|8100| |VLAN|TYPE| +------------+ +---------+ Ethernet 802.1Q LLC SNAP +------------+ +---------+ +--------+ +-----------+ 4. |dst|src|8100| |VLAN| LEN| |aa|aa|03| |000000|TYPE| +------------+ +---------+ +--------+ +-----------+ Unusual cases ------------- Ethernet LLC SNAP 802.1Q +------------+ +--------+ +-----------+ +---------+ 5. |dst|src| len| |aa|aa|03| |000000|8100| |VLAN|TYPE| +------------+ +--------+ +-----------+ +---------+ Ethernet LLC +------------+ +--------+ 6. |dst|src| len| |xx|xx|xx| +------------+ +--------+ Ethernet LLC SNAP +------------+ +--------+ +-----------+ 7. |dst|src| len| |aa|aa|03| |xxxxxx|xxxx| +------------+ +--------+ +-----------+ Ethernet 802.1Q LLC +------------+ +---------+ +--------+ 8. |dst|src|8100| |VLAN| LEN| |xx|xx|xx| +------------+ +---------+ +--------+ Ethernet 802.1Q LLC SNAP +------------+ +---------+ +--------+ +-----------+ 9. |dst|src|8100| |VLAN| LEN| |aa|aa|03| |xxxxxx|xxxx| +------------+ +---------+ +--------+ +-----------+ Behavior -------- --------------- --------------- ------------------------------------- Before After this commit this commit dl_type dl_vlan dl_type dl_vlan Notes ------- ------- ------- ------- ------------------------------------- 1. TYPE ffff TYPE ffff no change 2. TYPE ffff TYPE ffff no change 3. TYPE VLAN TYPE VLAN no change 4. LEN VLAN TYPE VLAN proposal fixes behavior 5. TYPE VLAN 8100 ffff 802.1Q says this is invalid framing 6. 05ff ffff 05ff ffff no change 7. 05ff ffff 05ff ffff no change 8. LEN VLAN 05ff VLAN proposal fixes behavior 9. LEN VLAN 05ff VLAN proposal fixes behavior Signed-off-by: Ben Pfaff <blp@nicira.com>
2010-08-10 11:35:46 -07:00
};
struct llc_snap_hdr *llc;
__be16 proto;
proto = *(__be16 *) skb->data;
__skb_pull(skb, sizeof(__be16));
if (ntohs(proto) >= ETH_P_802_3_MIN)
datapath: Fix handling of 802.1Q and SNAP headers. The kernel and user datapaths have code that assumes that 802.1Q headers are used only inside Ethernet II frames, not inside SNAP-encapsulated frames. But the kernel and user flow_extract() implementations would interpret 802.1Q headers inside SNAP headers as being valid VLANs. This would cause packet corruption if any VLAN-related actions were to be taken, so change the two flow_extract() implementations only to accept 802.1Q as an Ethernet II frame type, not as a SNAP-encoded frame type. 802.1Q-2005 says that this is correct anyhow: Where the ISS instance used to transmit and receive tagged frames is provided by a media access control method that can support Ethernet Type encoding directly (e.g., is an IEEE 802.3 or IEEE 802.11 MAC) or is media access method independent (e.g., 6.6), the TPID is Ethernet Type encoded, i.e., is two octets in length and comprises solely the assigned Ethernet Type value. Where the ISS instance is provided by a media access method that cannot directly support Ethernet Type encoding (e.g., is an IEEE 802.5 or FDDI MAC), the TPID is encoded according to the rule for a Subnetwork Access Protocol (Clause 10 of IEEE Std 802) that encapsulates Ethernet frames over LLC, and comprises the SNAP header (AA-AA-03) followed by the SNAP PID (00-00-00) followed by the two octets of the assigned Ethernet Type value. All of the media that OVS handles supports Ethernet Type fields, so to me that means that we don't have to handle 802.1Q-inside-SNAP. On the other hand, we *do* have to handle SNAP-inside-802.1Q, because this is actually allowed by the standards. So this commit also adds that support. I verified that, with this change, both SNAP and Ethernet packets are properly recognized both with and without 802.1Q encapsulation. I was a bit surprised to find out that Linux does not accept SNAP-encapsulated IP frames on Ethernet. Here's a summary of how frames are handled before and after this commit: Common cases ------------ Ethernet +------------+ 1. |dst|src|TYPE| +------------+ Ethernet LLC SNAP +------------+ +--------+ +-----------+ 2. |dst|src| len| |aa|aa|03| |000000|TYPE| +------------+ +--------+ +-----------+ Ethernet 802.1Q +------------+ +---------+ 3. |dst|src|8100| |VLAN|TYPE| +------------+ +---------+ Ethernet 802.1Q LLC SNAP +------------+ +---------+ +--------+ +-----------+ 4. |dst|src|8100| |VLAN| LEN| |aa|aa|03| |000000|TYPE| +------------+ +---------+ +--------+ +-----------+ Unusual cases ------------- Ethernet LLC SNAP 802.1Q +------------+ +--------+ +-----------+ +---------+ 5. |dst|src| len| |aa|aa|03| |000000|8100| |VLAN|TYPE| +------------+ +--------+ +-----------+ +---------+ Ethernet LLC +------------+ +--------+ 6. |dst|src| len| |xx|xx|xx| +------------+ +--------+ Ethernet LLC SNAP +------------+ +--------+ +-----------+ 7. |dst|src| len| |aa|aa|03| |xxxxxx|xxxx| +------------+ +--------+ +-----------+ Ethernet 802.1Q LLC +------------+ +---------+ +--------+ 8. |dst|src|8100| |VLAN| LEN| |xx|xx|xx| +------------+ +---------+ +--------+ Ethernet 802.1Q LLC SNAP +------------+ +---------+ +--------+ +-----------+ 9. |dst|src|8100| |VLAN| LEN| |aa|aa|03| |xxxxxx|xxxx| +------------+ +---------+ +--------+ +-----------+ Behavior -------- --------------- --------------- ------------------------------------- Before After this commit this commit dl_type dl_vlan dl_type dl_vlan Notes ------- ------- ------- ------- ------------------------------------- 1. TYPE ffff TYPE ffff no change 2. TYPE ffff TYPE ffff no change 3. TYPE VLAN TYPE VLAN no change 4. LEN VLAN TYPE VLAN proposal fixes behavior 5. TYPE VLAN 8100 ffff 802.1Q says this is invalid framing 6. 05ff ffff 05ff ffff no change 7. 05ff ffff 05ff ffff no change 8. LEN VLAN 05ff VLAN proposal fixes behavior 9. LEN VLAN 05ff VLAN proposal fixes behavior Signed-off-by: Ben Pfaff <blp@nicira.com>
2010-08-10 11:35:46 -07:00
return proto;
if (skb->len < sizeof(struct llc_snap_hdr))
return htons(ETH_P_802_2);
datapath: Fix handling of 802.1Q and SNAP headers. The kernel and user datapaths have code that assumes that 802.1Q headers are used only inside Ethernet II frames, not inside SNAP-encapsulated frames. But the kernel and user flow_extract() implementations would interpret 802.1Q headers inside SNAP headers as being valid VLANs. This would cause packet corruption if any VLAN-related actions were to be taken, so change the two flow_extract() implementations only to accept 802.1Q as an Ethernet II frame type, not as a SNAP-encoded frame type. 802.1Q-2005 says that this is correct anyhow: Where the ISS instance used to transmit and receive tagged frames is provided by a media access control method that can support Ethernet Type encoding directly (e.g., is an IEEE 802.3 or IEEE 802.11 MAC) or is media access method independent (e.g., 6.6), the TPID is Ethernet Type encoded, i.e., is two octets in length and comprises solely the assigned Ethernet Type value. Where the ISS instance is provided by a media access method that cannot directly support Ethernet Type encoding (e.g., is an IEEE 802.5 or FDDI MAC), the TPID is encoded according to the rule for a Subnetwork Access Protocol (Clause 10 of IEEE Std 802) that encapsulates Ethernet frames over LLC, and comprises the SNAP header (AA-AA-03) followed by the SNAP PID (00-00-00) followed by the two octets of the assigned Ethernet Type value. All of the media that OVS handles supports Ethernet Type fields, so to me that means that we don't have to handle 802.1Q-inside-SNAP. On the other hand, we *do* have to handle SNAP-inside-802.1Q, because this is actually allowed by the standards. So this commit also adds that support. I verified that, with this change, both SNAP and Ethernet packets are properly recognized both with and without 802.1Q encapsulation. I was a bit surprised to find out that Linux does not accept SNAP-encapsulated IP frames on Ethernet. Here's a summary of how frames are handled before and after this commit: Common cases ------------ Ethernet +------------+ 1. |dst|src|TYPE| +------------+ Ethernet LLC SNAP +------------+ +--------+ +-----------+ 2. |dst|src| len| |aa|aa|03| |000000|TYPE| +------------+ +--------+ +-----------+ Ethernet 802.1Q +------------+ +---------+ 3. |dst|src|8100| |VLAN|TYPE| +------------+ +---------+ Ethernet 802.1Q LLC SNAP +------------+ +---------+ +--------+ +-----------+ 4. |dst|src|8100| |VLAN| LEN| |aa|aa|03| |000000|TYPE| +------------+ +---------+ +--------+ +-----------+ Unusual cases ------------- Ethernet LLC SNAP 802.1Q +------------+ +--------+ +-----------+ +---------+ 5. |dst|src| len| |aa|aa|03| |000000|8100| |VLAN|TYPE| +------------+ +--------+ +-----------+ +---------+ Ethernet LLC +------------+ +--------+ 6. |dst|src| len| |xx|xx|xx| +------------+ +--------+ Ethernet LLC SNAP +------------+ +--------+ +-----------+ 7. |dst|src| len| |aa|aa|03| |xxxxxx|xxxx| +------------+ +--------+ +-----------+ Ethernet 802.1Q LLC +------------+ +---------+ +--------+ 8. |dst|src|8100| |VLAN| LEN| |xx|xx|xx| +------------+ +---------+ +--------+ Ethernet 802.1Q LLC SNAP +------------+ +---------+ +--------+ +-----------+ 9. |dst|src|8100| |VLAN| LEN| |aa|aa|03| |xxxxxx|xxxx| +------------+ +---------+ +--------+ +-----------+ Behavior -------- --------------- --------------- ------------------------------------- Before After this commit this commit dl_type dl_vlan dl_type dl_vlan Notes ------- ------- ------- ------- ------------------------------------- 1. TYPE ffff TYPE ffff no change 2. TYPE ffff TYPE ffff no change 3. TYPE VLAN TYPE VLAN no change 4. LEN VLAN TYPE VLAN proposal fixes behavior 5. TYPE VLAN 8100 ffff 802.1Q says this is invalid framing 6. 05ff ffff 05ff ffff no change 7. 05ff ffff 05ff ffff no change 8. LEN VLAN 05ff VLAN proposal fixes behavior 9. LEN VLAN 05ff VLAN proposal fixes behavior Signed-off-by: Ben Pfaff <blp@nicira.com>
2010-08-10 11:35:46 -07:00
if (unlikely(!pskb_may_pull(skb, sizeof(struct llc_snap_hdr))))
return htons(0);
datapath: Fix handling of 802.1Q and SNAP headers. The kernel and user datapaths have code that assumes that 802.1Q headers are used only inside Ethernet II frames, not inside SNAP-encapsulated frames. But the kernel and user flow_extract() implementations would interpret 802.1Q headers inside SNAP headers as being valid VLANs. This would cause packet corruption if any VLAN-related actions were to be taken, so change the two flow_extract() implementations only to accept 802.1Q as an Ethernet II frame type, not as a SNAP-encoded frame type. 802.1Q-2005 says that this is correct anyhow: Where the ISS instance used to transmit and receive tagged frames is provided by a media access control method that can support Ethernet Type encoding directly (e.g., is an IEEE 802.3 or IEEE 802.11 MAC) or is media access method independent (e.g., 6.6), the TPID is Ethernet Type encoded, i.e., is two octets in length and comprises solely the assigned Ethernet Type value. Where the ISS instance is provided by a media access method that cannot directly support Ethernet Type encoding (e.g., is an IEEE 802.5 or FDDI MAC), the TPID is encoded according to the rule for a Subnetwork Access Protocol (Clause 10 of IEEE Std 802) that encapsulates Ethernet frames over LLC, and comprises the SNAP header (AA-AA-03) followed by the SNAP PID (00-00-00) followed by the two octets of the assigned Ethernet Type value. All of the media that OVS handles supports Ethernet Type fields, so to me that means that we don't have to handle 802.1Q-inside-SNAP. On the other hand, we *do* have to handle SNAP-inside-802.1Q, because this is actually allowed by the standards. So this commit also adds that support. I verified that, with this change, both SNAP and Ethernet packets are properly recognized both with and without 802.1Q encapsulation. I was a bit surprised to find out that Linux does not accept SNAP-encapsulated IP frames on Ethernet. Here's a summary of how frames are handled before and after this commit: Common cases ------------ Ethernet +------------+ 1. |dst|src|TYPE| +------------+ Ethernet LLC SNAP +------------+ +--------+ +-----------+ 2. |dst|src| len| |aa|aa|03| |000000|TYPE| +------------+ +--------+ +-----------+ Ethernet 802.1Q +------------+ +---------+ 3. |dst|src|8100| |VLAN|TYPE| +------------+ +---------+ Ethernet 802.1Q LLC SNAP +------------+ +---------+ +--------+ +-----------+ 4. |dst|src|8100| |VLAN| LEN| |aa|aa|03| |000000|TYPE| +------------+ +---------+ +--------+ +-----------+ Unusual cases ------------- Ethernet LLC SNAP 802.1Q +------------+ +--------+ +-----------+ +---------+ 5. |dst|src| len| |aa|aa|03| |000000|8100| |VLAN|TYPE| +------------+ +--------+ +-----------+ +---------+ Ethernet LLC +------------+ +--------+ 6. |dst|src| len| |xx|xx|xx| +------------+ +--------+ Ethernet LLC SNAP +------------+ +--------+ +-----------+ 7. |dst|src| len| |aa|aa|03| |xxxxxx|xxxx| +------------+ +--------+ +-----------+ Ethernet 802.1Q LLC +------------+ +---------+ +--------+ 8. |dst|src|8100| |VLAN| LEN| |xx|xx|xx| +------------+ +---------+ +--------+ Ethernet 802.1Q LLC SNAP +------------+ +---------+ +--------+ +-----------+ 9. |dst|src|8100| |VLAN| LEN| |aa|aa|03| |xxxxxx|xxxx| +------------+ +---------+ +--------+ +-----------+ Behavior -------- --------------- --------------- ------------------------------------- Before After this commit this commit dl_type dl_vlan dl_type dl_vlan Notes ------- ------- ------- ------- ------------------------------------- 1. TYPE ffff TYPE ffff no change 2. TYPE ffff TYPE ffff no change 3. TYPE VLAN TYPE VLAN no change 4. LEN VLAN TYPE VLAN proposal fixes behavior 5. TYPE VLAN 8100 ffff 802.1Q says this is invalid framing 6. 05ff ffff 05ff ffff no change 7. 05ff ffff 05ff ffff no change 8. LEN VLAN 05ff VLAN proposal fixes behavior 9. LEN VLAN 05ff VLAN proposal fixes behavior Signed-off-by: Ben Pfaff <blp@nicira.com>
2010-08-10 11:35:46 -07:00
llc = (struct llc_snap_hdr *) skb->data;
if (llc->dsap != LLC_SAP_SNAP ||
llc->ssap != LLC_SAP_SNAP ||
(llc->oui[0] | llc->oui[1] | llc->oui[2]) != 0)
return htons(ETH_P_802_2);
datapath: Fix handling of 802.1Q and SNAP headers. The kernel and user datapaths have code that assumes that 802.1Q headers are used only inside Ethernet II frames, not inside SNAP-encapsulated frames. But the kernel and user flow_extract() implementations would interpret 802.1Q headers inside SNAP headers as being valid VLANs. This would cause packet corruption if any VLAN-related actions were to be taken, so change the two flow_extract() implementations only to accept 802.1Q as an Ethernet II frame type, not as a SNAP-encoded frame type. 802.1Q-2005 says that this is correct anyhow: Where the ISS instance used to transmit and receive tagged frames is provided by a media access control method that can support Ethernet Type encoding directly (e.g., is an IEEE 802.3 or IEEE 802.11 MAC) or is media access method independent (e.g., 6.6), the TPID is Ethernet Type encoded, i.e., is two octets in length and comprises solely the assigned Ethernet Type value. Where the ISS instance is provided by a media access method that cannot directly support Ethernet Type encoding (e.g., is an IEEE 802.5 or FDDI MAC), the TPID is encoded according to the rule for a Subnetwork Access Protocol (Clause 10 of IEEE Std 802) that encapsulates Ethernet frames over LLC, and comprises the SNAP header (AA-AA-03) followed by the SNAP PID (00-00-00) followed by the two octets of the assigned Ethernet Type value. All of the media that OVS handles supports Ethernet Type fields, so to me that means that we don't have to handle 802.1Q-inside-SNAP. On the other hand, we *do* have to handle SNAP-inside-802.1Q, because this is actually allowed by the standards. So this commit also adds that support. I verified that, with this change, both SNAP and Ethernet packets are properly recognized both with and without 802.1Q encapsulation. I was a bit surprised to find out that Linux does not accept SNAP-encapsulated IP frames on Ethernet. Here's a summary of how frames are handled before and after this commit: Common cases ------------ Ethernet +------------+ 1. |dst|src|TYPE| +------------+ Ethernet LLC SNAP +------------+ +--------+ +-----------+ 2. |dst|src| len| |aa|aa|03| |000000|TYPE| +------------+ +--------+ +-----------+ Ethernet 802.1Q +------------+ +---------+ 3. |dst|src|8100| |VLAN|TYPE| +------------+ +---------+ Ethernet 802.1Q LLC SNAP +------------+ +---------+ +--------+ +-----------+ 4. |dst|src|8100| |VLAN| LEN| |aa|aa|03| |000000|TYPE| +------------+ +---------+ +--------+ +-----------+ Unusual cases ------------- Ethernet LLC SNAP 802.1Q +------------+ +--------+ +-----------+ +---------+ 5. |dst|src| len| |aa|aa|03| |000000|8100| |VLAN|TYPE| +------------+ +--------+ +-----------+ +---------+ Ethernet LLC +------------+ +--------+ 6. |dst|src| len| |xx|xx|xx| +------------+ +--------+ Ethernet LLC SNAP +------------+ +--------+ +-----------+ 7. |dst|src| len| |aa|aa|03| |xxxxxx|xxxx| +------------+ +--------+ +-----------+ Ethernet 802.1Q LLC +------------+ +---------+ +--------+ 8. |dst|src|8100| |VLAN| LEN| |xx|xx|xx| +------------+ +---------+ +--------+ Ethernet 802.1Q LLC SNAP +------------+ +---------+ +--------+ +-----------+ 9. |dst|src|8100| |VLAN| LEN| |aa|aa|03| |xxxxxx|xxxx| +------------+ +---------+ +--------+ +-----------+ Behavior -------- --------------- --------------- ------------------------------------- Before After this commit this commit dl_type dl_vlan dl_type dl_vlan Notes ------- ------- ------- ------- ------------------------------------- 1. TYPE ffff TYPE ffff no change 2. TYPE ffff TYPE ffff no change 3. TYPE VLAN TYPE VLAN no change 4. LEN VLAN TYPE VLAN proposal fixes behavior 5. TYPE VLAN 8100 ffff 802.1Q says this is invalid framing 6. 05ff ffff 05ff ffff no change 7. 05ff ffff 05ff ffff no change 8. LEN VLAN 05ff VLAN proposal fixes behavior 9. LEN VLAN 05ff VLAN proposal fixes behavior Signed-off-by: Ben Pfaff <blp@nicira.com>
2010-08-10 11:35:46 -07:00
__skb_pull(skb, sizeof(struct llc_snap_hdr));
if (ntohs(llc->ethertype) >= ETH_P_802_3_MIN)
return llc->ethertype;
return htons(ETH_P_802_2);
}
static int parse_icmpv6(struct sk_buff *skb, struct sw_flow_key *key,
int nh_len)
{
struct icmp6hdr *icmp = icmp6_hdr(skb);
/* The ICMPv6 type and code fields use the 16-bit transport port
* fields, so we need to store them in 16-bit network byte order.
*/
key->ipv6.tp.src = htons(icmp->icmp6_type);
key->ipv6.tp.dst = htons(icmp->icmp6_code);
if (icmp->icmp6_code == 0 &&
(icmp->icmp6_type == NDISC_NEIGHBOUR_SOLICITATION ||
icmp->icmp6_type == NDISC_NEIGHBOUR_ADVERTISEMENT)) {
int icmp_len = skb->len - skb_transport_offset(skb);
struct nd_msg *nd;
int offset;
/* In order to process neighbor discovery options, we need the
* entire packet.
*/
if (unlikely(icmp_len < sizeof(*nd)))
return 0;
if (unlikely(skb_linearize(skb)))
return -ENOMEM;
nd = (struct nd_msg *)skb_transport_header(skb);
key->ipv6.nd.target = nd->target;
icmp_len -= sizeof(*nd);
offset = 0;
while (icmp_len >= 8) {
struct nd_opt_hdr *nd_opt =
(struct nd_opt_hdr *)(nd->opt + offset);
int opt_len = nd_opt->nd_opt_len * 8;
if (unlikely(!opt_len || opt_len > icmp_len))
return 0;
/* Store the link layer address if the appropriate
* option is provided. It is considered an error if
* the same link layer option is specified twice.
*/
if (nd_opt->nd_opt_type == ND_OPT_SOURCE_LL_ADDR
&& opt_len == 8) {
if (unlikely(!is_zero_ether_addr(key->ipv6.nd.sll)))
goto invalid;
memcpy(key->ipv6.nd.sll,
&nd->opt[offset+sizeof(*nd_opt)], ETH_ALEN);
} else if (nd_opt->nd_opt_type == ND_OPT_TARGET_LL_ADDR
&& opt_len == 8) {
if (unlikely(!is_zero_ether_addr(key->ipv6.nd.tll)))
goto invalid;
memcpy(key->ipv6.nd.tll,
&nd->opt[offset+sizeof(*nd_opt)], ETH_ALEN);
}
icmp_len -= opt_len;
offset += opt_len;
}
}
return 0;
invalid:
memset(&key->ipv6.nd.target, 0, sizeof(key->ipv6.nd.target));
memset(key->ipv6.nd.sll, 0, sizeof(key->ipv6.nd.sll));
memset(key->ipv6.nd.tll, 0, sizeof(key->ipv6.nd.tll));
return 0;
}
/**
* ovs_flow_extract - extracts a flow key from an Ethernet frame.
* @skb: sk_buff that contains the frame, with skb->data pointing to the
* Ethernet header
* @in_port: port number on which @skb was received.
* @key: output flow key
*
* The caller must ensure that skb->len >= ETH_HLEN.
*
* Returns 0 if successful, otherwise a negative errno value.
*
* Initializes @skb header pointers as follows:
*
* - skb->mac_header: the Ethernet header.
*
* - skb->network_header: just past the Ethernet header, or just past the
* VLAN header, to the first byte of the Ethernet payload.
*
* - skb->transport_header: If key->eth.type is ETH_P_IP or ETH_P_IPV6
* on output, then just past the IP header, if one is present and
* of a correct length, otherwise the same as skb->network_header.
* For other key->eth.type values it is left untouched.
*/
int ovs_flow_extract(struct sk_buff *skb, u16 in_port, struct sw_flow_key *key)
{
int error;
struct ethhdr *eth;
memset(key, 0, sizeof(*key));
key->phy.priority = skb->priority;
if (OVS_CB(skb)->tun_key)
memcpy(&key->tun_key, OVS_CB(skb)->tun_key, sizeof(key->tun_key));
key->phy.in_port = in_port;
key->phy.skb_mark = skb->mark;
skb_reset_mac_header(skb);
/* Link layer. We are guaranteed to have at least the 14 byte Ethernet
* header in the linear data area.
*/
datapath: Fix handling of 802.1Q and SNAP headers. The kernel and user datapaths have code that assumes that 802.1Q headers are used only inside Ethernet II frames, not inside SNAP-encapsulated frames. But the kernel and user flow_extract() implementations would interpret 802.1Q headers inside SNAP headers as being valid VLANs. This would cause packet corruption if any VLAN-related actions were to be taken, so change the two flow_extract() implementations only to accept 802.1Q as an Ethernet II frame type, not as a SNAP-encoded frame type. 802.1Q-2005 says that this is correct anyhow: Where the ISS instance used to transmit and receive tagged frames is provided by a media access control method that can support Ethernet Type encoding directly (e.g., is an IEEE 802.3 or IEEE 802.11 MAC) or is media access method independent (e.g., 6.6), the TPID is Ethernet Type encoded, i.e., is two octets in length and comprises solely the assigned Ethernet Type value. Where the ISS instance is provided by a media access method that cannot directly support Ethernet Type encoding (e.g., is an IEEE 802.5 or FDDI MAC), the TPID is encoded according to the rule for a Subnetwork Access Protocol (Clause 10 of IEEE Std 802) that encapsulates Ethernet frames over LLC, and comprises the SNAP header (AA-AA-03) followed by the SNAP PID (00-00-00) followed by the two octets of the assigned Ethernet Type value. All of the media that OVS handles supports Ethernet Type fields, so to me that means that we don't have to handle 802.1Q-inside-SNAP. On the other hand, we *do* have to handle SNAP-inside-802.1Q, because this is actually allowed by the standards. So this commit also adds that support. I verified that, with this change, both SNAP and Ethernet packets are properly recognized both with and without 802.1Q encapsulation. I was a bit surprised to find out that Linux does not accept SNAP-encapsulated IP frames on Ethernet. Here's a summary of how frames are handled before and after this commit: Common cases ------------ Ethernet +------------+ 1. |dst|src|TYPE| +------------+ Ethernet LLC SNAP +------------+ +--------+ +-----------+ 2. |dst|src| len| |aa|aa|03| |000000|TYPE| +------------+ +--------+ +-----------+ Ethernet 802.1Q +------------+ +---------+ 3. |dst|src|8100| |VLAN|TYPE| +------------+ +---------+ Ethernet 802.1Q LLC SNAP +------------+ +---------+ +--------+ +-----------+ 4. |dst|src|8100| |VLAN| LEN| |aa|aa|03| |000000|TYPE| +------------+ +---------+ +--------+ +-----------+ Unusual cases ------------- Ethernet LLC SNAP 802.1Q +------------+ +--------+ +-----------+ +---------+ 5. |dst|src| len| |aa|aa|03| |000000|8100| |VLAN|TYPE| +------------+ +--------+ +-----------+ +---------+ Ethernet LLC +------------+ +--------+ 6. |dst|src| len| |xx|xx|xx| +------------+ +--------+ Ethernet LLC SNAP +------------+ +--------+ +-----------+ 7. |dst|src| len| |aa|aa|03| |xxxxxx|xxxx| +------------+ +--------+ +-----------+ Ethernet 802.1Q LLC +------------+ +---------+ +--------+ 8. |dst|src|8100| |VLAN| LEN| |xx|xx|xx| +------------+ +---------+ +--------+ Ethernet 802.1Q LLC SNAP +------------+ +---------+ +--------+ +-----------+ 9. |dst|src|8100| |VLAN| LEN| |aa|aa|03| |xxxxxx|xxxx| +------------+ +---------+ +--------+ +-----------+ Behavior -------- --------------- --------------- ------------------------------------- Before After this commit this commit dl_type dl_vlan dl_type dl_vlan Notes ------- ------- ------- ------- ------------------------------------- 1. TYPE ffff TYPE ffff no change 2. TYPE ffff TYPE ffff no change 3. TYPE VLAN TYPE VLAN no change 4. LEN VLAN TYPE VLAN proposal fixes behavior 5. TYPE VLAN 8100 ffff 802.1Q says this is invalid framing 6. 05ff ffff 05ff ffff no change 7. 05ff ffff 05ff ffff no change 8. LEN VLAN 05ff VLAN proposal fixes behavior 9. LEN VLAN 05ff VLAN proposal fixes behavior Signed-off-by: Ben Pfaff <blp@nicira.com>
2010-08-10 11:35:46 -07:00
eth = eth_hdr(skb);
memcpy(key->eth.src, eth->h_source, ETH_ALEN);
memcpy(key->eth.dst, eth->h_dest, ETH_ALEN);
datapath: Fix handling of 802.1Q and SNAP headers. The kernel and user datapaths have code that assumes that 802.1Q headers are used only inside Ethernet II frames, not inside SNAP-encapsulated frames. But the kernel and user flow_extract() implementations would interpret 802.1Q headers inside SNAP headers as being valid VLANs. This would cause packet corruption if any VLAN-related actions were to be taken, so change the two flow_extract() implementations only to accept 802.1Q as an Ethernet II frame type, not as a SNAP-encoded frame type. 802.1Q-2005 says that this is correct anyhow: Where the ISS instance used to transmit and receive tagged frames is provided by a media access control method that can support Ethernet Type encoding directly (e.g., is an IEEE 802.3 or IEEE 802.11 MAC) or is media access method independent (e.g., 6.6), the TPID is Ethernet Type encoded, i.e., is two octets in length and comprises solely the assigned Ethernet Type value. Where the ISS instance is provided by a media access method that cannot directly support Ethernet Type encoding (e.g., is an IEEE 802.5 or FDDI MAC), the TPID is encoded according to the rule for a Subnetwork Access Protocol (Clause 10 of IEEE Std 802) that encapsulates Ethernet frames over LLC, and comprises the SNAP header (AA-AA-03) followed by the SNAP PID (00-00-00) followed by the two octets of the assigned Ethernet Type value. All of the media that OVS handles supports Ethernet Type fields, so to me that means that we don't have to handle 802.1Q-inside-SNAP. On the other hand, we *do* have to handle SNAP-inside-802.1Q, because this is actually allowed by the standards. So this commit also adds that support. I verified that, with this change, both SNAP and Ethernet packets are properly recognized both with and without 802.1Q encapsulation. I was a bit surprised to find out that Linux does not accept SNAP-encapsulated IP frames on Ethernet. Here's a summary of how frames are handled before and after this commit: Common cases ------------ Ethernet +------------+ 1. |dst|src|TYPE| +------------+ Ethernet LLC SNAP +------------+ +--------+ +-----------+ 2. |dst|src| len| |aa|aa|03| |000000|TYPE| +------------+ +--------+ +-----------+ Ethernet 802.1Q +------------+ +---------+ 3. |dst|src|8100| |VLAN|TYPE| +------------+ +---------+ Ethernet 802.1Q LLC SNAP +------------+ +---------+ +--------+ +-----------+ 4. |dst|src|8100| |VLAN| LEN| |aa|aa|03| |000000|TYPE| +------------+ +---------+ +--------+ +-----------+ Unusual cases ------------- Ethernet LLC SNAP 802.1Q +------------+ +--------+ +-----------+ +---------+ 5. |dst|src| len| |aa|aa|03| |000000|8100| |VLAN|TYPE| +------------+ +--------+ +-----------+ +---------+ Ethernet LLC +------------+ +--------+ 6. |dst|src| len| |xx|xx|xx| +------------+ +--------+ Ethernet LLC SNAP +------------+ +--------+ +-----------+ 7. |dst|src| len| |aa|aa|03| |xxxxxx|xxxx| +------------+ +--------+ +-----------+ Ethernet 802.1Q LLC +------------+ +---------+ +--------+ 8. |dst|src|8100| |VLAN| LEN| |xx|xx|xx| +------------+ +---------+ +--------+ Ethernet 802.1Q LLC SNAP +------------+ +---------+ +--------+ +-----------+ 9. |dst|src|8100| |VLAN| LEN| |aa|aa|03| |xxxxxx|xxxx| +------------+ +---------+ +--------+ +-----------+ Behavior -------- --------------- --------------- ------------------------------------- Before After this commit this commit dl_type dl_vlan dl_type dl_vlan Notes ------- ------- ------- ------- ------------------------------------- 1. TYPE ffff TYPE ffff no change 2. TYPE ffff TYPE ffff no change 3. TYPE VLAN TYPE VLAN no change 4. LEN VLAN TYPE VLAN proposal fixes behavior 5. TYPE VLAN 8100 ffff 802.1Q says this is invalid framing 6. 05ff ffff 05ff ffff no change 7. 05ff ffff 05ff ffff no change 8. LEN VLAN 05ff VLAN proposal fixes behavior 9. LEN VLAN 05ff VLAN proposal fixes behavior Signed-off-by: Ben Pfaff <blp@nicira.com>
2010-08-10 11:35:46 -07:00
__skb_pull(skb, 2 * ETH_ALEN);
/* We are going to push all headers that we pull, so no need to
* update skb->csum here. */
if (vlan_tx_tag_present(skb))
key->eth.tci = htons(vlan_get_tci(skb));
else if (eth->h_proto == htons(ETH_P_8021Q))
if (unlikely(parse_vlan(skb, key)))
return -ENOMEM;
key->eth.type = parse_ethertype(skb);
if (unlikely(key->eth.type == htons(0)))
return -ENOMEM;
datapath: Fix handling of 802.1Q and SNAP headers. The kernel and user datapaths have code that assumes that 802.1Q headers are used only inside Ethernet II frames, not inside SNAP-encapsulated frames. But the kernel and user flow_extract() implementations would interpret 802.1Q headers inside SNAP headers as being valid VLANs. This would cause packet corruption if any VLAN-related actions were to be taken, so change the two flow_extract() implementations only to accept 802.1Q as an Ethernet II frame type, not as a SNAP-encoded frame type. 802.1Q-2005 says that this is correct anyhow: Where the ISS instance used to transmit and receive tagged frames is provided by a media access control method that can support Ethernet Type encoding directly (e.g., is an IEEE 802.3 or IEEE 802.11 MAC) or is media access method independent (e.g., 6.6), the TPID is Ethernet Type encoded, i.e., is two octets in length and comprises solely the assigned Ethernet Type value. Where the ISS instance is provided by a media access method that cannot directly support Ethernet Type encoding (e.g., is an IEEE 802.5 or FDDI MAC), the TPID is encoded according to the rule for a Subnetwork Access Protocol (Clause 10 of IEEE Std 802) that encapsulates Ethernet frames over LLC, and comprises the SNAP header (AA-AA-03) followed by the SNAP PID (00-00-00) followed by the two octets of the assigned Ethernet Type value. All of the media that OVS handles supports Ethernet Type fields, so to me that means that we don't have to handle 802.1Q-inside-SNAP. On the other hand, we *do* have to handle SNAP-inside-802.1Q, because this is actually allowed by the standards. So this commit also adds that support. I verified that, with this change, both SNAP and Ethernet packets are properly recognized both with and without 802.1Q encapsulation. I was a bit surprised to find out that Linux does not accept SNAP-encapsulated IP frames on Ethernet. Here's a summary of how frames are handled before and after this commit: Common cases ------------ Ethernet +------------+ 1. |dst|src|TYPE| +------------+ Ethernet LLC SNAP +------------+ +--------+ +-----------+ 2. |dst|src| len| |aa|aa|03| |000000|TYPE| +------------+ +--------+ +-----------+ Ethernet 802.1Q +------------+ +---------+ 3. |dst|src|8100| |VLAN|TYPE| +------------+ +---------+ Ethernet 802.1Q LLC SNAP +------------+ +---------+ +--------+ +-----------+ 4. |dst|src|8100| |VLAN| LEN| |aa|aa|03| |000000|TYPE| +------------+ +---------+ +--------+ +-----------+ Unusual cases ------------- Ethernet LLC SNAP 802.1Q +------------+ +--------+ +-----------+ +---------+ 5. |dst|src| len| |aa|aa|03| |000000|8100| |VLAN|TYPE| +------------+ +--------+ +-----------+ +---------+ Ethernet LLC +------------+ +--------+ 6. |dst|src| len| |xx|xx|xx| +------------+ +--------+ Ethernet LLC SNAP +------------+ +--------+ +-----------+ 7. |dst|src| len| |aa|aa|03| |xxxxxx|xxxx| +------------+ +--------+ +-----------+ Ethernet 802.1Q LLC +------------+ +---------+ +--------+ 8. |dst|src|8100| |VLAN| LEN| |xx|xx|xx| +------------+ +---------+ +--------+ Ethernet 802.1Q LLC SNAP +------------+ +---------+ +--------+ +-----------+ 9. |dst|src|8100| |VLAN| LEN| |aa|aa|03| |xxxxxx|xxxx| +------------+ +---------+ +--------+ +-----------+ Behavior -------- --------------- --------------- ------------------------------------- Before After this commit this commit dl_type dl_vlan dl_type dl_vlan Notes ------- ------- ------- ------- ------------------------------------- 1. TYPE ffff TYPE ffff no change 2. TYPE ffff TYPE ffff no change 3. TYPE VLAN TYPE VLAN no change 4. LEN VLAN TYPE VLAN proposal fixes behavior 5. TYPE VLAN 8100 ffff 802.1Q says this is invalid framing 6. 05ff ffff 05ff ffff no change 7. 05ff ffff 05ff ffff no change 8. LEN VLAN 05ff VLAN proposal fixes behavior 9. LEN VLAN 05ff VLAN proposal fixes behavior Signed-off-by: Ben Pfaff <blp@nicira.com>
2010-08-10 11:35:46 -07:00
skb_reset_network_header(skb);
__skb_push(skb, skb->data - skb_mac_header(skb));
/* Network layer. */
if (key->eth.type == htons(ETH_P_IP)) {
struct iphdr *nh;
Implement new fragment handling policy. Until now, OVS has handled IP fragments more awkwardly than necessary. It has not been possible to match on L4 headers, even in fragments with offset 0 where they are actually present. This means that there was no way to implement ACLs that treat, say, different TCP ports differently, on fragmented traffic; instead, all decisions for fragment forwarding had to be made on the basis of L2 and L3 headers alone. This commit improves the situation significantly. It is still not possible to match on L4 headers in fragments with nonzero offset, because that information is simply not present in such fragments, but this commit adds the ability to match on L4 headers for fragments with zero offset. This means that it becomes possible to implement ACLs that drop such "first fragments" on the basis of L4 headers. In practice, that effectively blocks even fragmented traffic on an L4 basis, because the receiving IP stack cannot reassemble a full packet when the first fragment is missing. This commit works by adding a new "fragment type" to the kernel flow match and making it available through OpenFlow as a new NXM field named NXM_NX_IP_FRAG. Because OpenFlow 1.0 explicitly says that the L4 fields are always 0 for IP fragments, it adds a new OpenFlow fragment handling mode that fills in the L4 fields for "first fragments". It also enhances ovs-ofctl to allow users to configure this new fragment handling mode and to parse the new field. Signed-off-by: Ben Pfaff <blp@nicira.com> Bug #7557.
2011-10-19 21:33:44 -07:00
__be16 offset;
error = check_iphdr(skb);
if (unlikely(error)) {
if (error == -EINVAL) {
skb->transport_header = skb->network_header;
error = 0;
}
return error;
}
nh = ip_hdr(skb);
key->ipv4.addr.src = nh->saddr;
key->ipv4.addr.dst = nh->daddr;
Implement new fragment handling policy. Until now, OVS has handled IP fragments more awkwardly than necessary. It has not been possible to match on L4 headers, even in fragments with offset 0 where they are actually present. This means that there was no way to implement ACLs that treat, say, different TCP ports differently, on fragmented traffic; instead, all decisions for fragment forwarding had to be made on the basis of L2 and L3 headers alone. This commit improves the situation significantly. It is still not possible to match on L4 headers in fragments with nonzero offset, because that information is simply not present in such fragments, but this commit adds the ability to match on L4 headers for fragments with zero offset. This means that it becomes possible to implement ACLs that drop such "first fragments" on the basis of L4 headers. In practice, that effectively blocks even fragmented traffic on an L4 basis, because the receiving IP stack cannot reassemble a full packet when the first fragment is missing. This commit works by adding a new "fragment type" to the kernel flow match and making it available through OpenFlow as a new NXM field named NXM_NX_IP_FRAG. Because OpenFlow 1.0 explicitly says that the L4 fields are always 0 for IP fragments, it adds a new OpenFlow fragment handling mode that fills in the L4 fields for "first fragments". It also enhances ovs-ofctl to allow users to configure this new fragment handling mode and to parse the new field. Signed-off-by: Ben Pfaff <blp@nicira.com> Bug #7557.
2011-10-19 21:33:44 -07:00
key->ip.proto = nh->protocol;
key->ip.tos = nh->tos;
key->ip.ttl = nh->ttl;
Implement new fragment handling policy. Until now, OVS has handled IP fragments more awkwardly than necessary. It has not been possible to match on L4 headers, even in fragments with offset 0 where they are actually present. This means that there was no way to implement ACLs that treat, say, different TCP ports differently, on fragmented traffic; instead, all decisions for fragment forwarding had to be made on the basis of L2 and L3 headers alone. This commit improves the situation significantly. It is still not possible to match on L4 headers in fragments with nonzero offset, because that information is simply not present in such fragments, but this commit adds the ability to match on L4 headers for fragments with zero offset. This means that it becomes possible to implement ACLs that drop such "first fragments" on the basis of L4 headers. In practice, that effectively blocks even fragmented traffic on an L4 basis, because the receiving IP stack cannot reassemble a full packet when the first fragment is missing. This commit works by adding a new "fragment type" to the kernel flow match and making it available through OpenFlow as a new NXM field named NXM_NX_IP_FRAG. Because OpenFlow 1.0 explicitly says that the L4 fields are always 0 for IP fragments, it adds a new OpenFlow fragment handling mode that fills in the L4 fields for "first fragments". It also enhances ovs-ofctl to allow users to configure this new fragment handling mode and to parse the new field. Signed-off-by: Ben Pfaff <blp@nicira.com> Bug #7557.
2011-10-19 21:33:44 -07:00
offset = nh->frag_off & htons(IP_OFFSET);
if (offset) {
key->ip.frag = OVS_FRAG_TYPE_LATER;
return 0;
Implement new fragment handling policy. Until now, OVS has handled IP fragments more awkwardly than necessary. It has not been possible to match on L4 headers, even in fragments with offset 0 where they are actually present. This means that there was no way to implement ACLs that treat, say, different TCP ports differently, on fragmented traffic; instead, all decisions for fragment forwarding had to be made on the basis of L2 and L3 headers alone. This commit improves the situation significantly. It is still not possible to match on L4 headers in fragments with nonzero offset, because that information is simply not present in such fragments, but this commit adds the ability to match on L4 headers for fragments with zero offset. This means that it becomes possible to implement ACLs that drop such "first fragments" on the basis of L4 headers. In practice, that effectively blocks even fragmented traffic on an L4 basis, because the receiving IP stack cannot reassemble a full packet when the first fragment is missing. This commit works by adding a new "fragment type" to the kernel flow match and making it available through OpenFlow as a new NXM field named NXM_NX_IP_FRAG. Because OpenFlow 1.0 explicitly says that the L4 fields are always 0 for IP fragments, it adds a new OpenFlow fragment handling mode that fills in the L4 fields for "first fragments". It also enhances ovs-ofctl to allow users to configure this new fragment handling mode and to parse the new field. Signed-off-by: Ben Pfaff <blp@nicira.com> Bug #7557.
2011-10-19 21:33:44 -07:00
}
if (nh->frag_off & htons(IP_MF) ||
skb_shinfo(skb)->gso_type & SKB_GSO_UDP)
key->ip.frag = OVS_FRAG_TYPE_FIRST;
Implement new fragment handling policy. Until now, OVS has handled IP fragments more awkwardly than necessary. It has not been possible to match on L4 headers, even in fragments with offset 0 where they are actually present. This means that there was no way to implement ACLs that treat, say, different TCP ports differently, on fragmented traffic; instead, all decisions for fragment forwarding had to be made on the basis of L2 and L3 headers alone. This commit improves the situation significantly. It is still not possible to match on L4 headers in fragments with nonzero offset, because that information is simply not present in such fragments, but this commit adds the ability to match on L4 headers for fragments with zero offset. This means that it becomes possible to implement ACLs that drop such "first fragments" on the basis of L4 headers. In practice, that effectively blocks even fragmented traffic on an L4 basis, because the receiving IP stack cannot reassemble a full packet when the first fragment is missing. This commit works by adding a new "fragment type" to the kernel flow match and making it available through OpenFlow as a new NXM field named NXM_NX_IP_FRAG. Because OpenFlow 1.0 explicitly says that the L4 fields are always 0 for IP fragments, it adds a new OpenFlow fragment handling mode that fills in the L4 fields for "first fragments". It also enhances ovs-ofctl to allow users to configure this new fragment handling mode and to parse the new field. Signed-off-by: Ben Pfaff <blp@nicira.com> Bug #7557.
2011-10-19 21:33:44 -07:00
/* Transport layer. */
if (key->ip.proto == IPPROTO_TCP) {
Implement new fragment handling policy. Until now, OVS has handled IP fragments more awkwardly than necessary. It has not been possible to match on L4 headers, even in fragments with offset 0 where they are actually present. This means that there was no way to implement ACLs that treat, say, different TCP ports differently, on fragmented traffic; instead, all decisions for fragment forwarding had to be made on the basis of L2 and L3 headers alone. This commit improves the situation significantly. It is still not possible to match on L4 headers in fragments with nonzero offset, because that information is simply not present in such fragments, but this commit adds the ability to match on L4 headers for fragments with zero offset. This means that it becomes possible to implement ACLs that drop such "first fragments" on the basis of L4 headers. In practice, that effectively blocks even fragmented traffic on an L4 basis, because the receiving IP stack cannot reassemble a full packet when the first fragment is missing. This commit works by adding a new "fragment type" to the kernel flow match and making it available through OpenFlow as a new NXM field named NXM_NX_IP_FRAG. Because OpenFlow 1.0 explicitly says that the L4 fields are always 0 for IP fragments, it adds a new OpenFlow fragment handling mode that fills in the L4 fields for "first fragments". It also enhances ovs-ofctl to allow users to configure this new fragment handling mode and to parse the new field. Signed-off-by: Ben Pfaff <blp@nicira.com> Bug #7557.
2011-10-19 21:33:44 -07:00
if (tcphdr_ok(skb)) {
struct tcphdr *tcp = tcp_hdr(skb);
key->ipv4.tp.src = tcp->source;
key->ipv4.tp.dst = tcp->dest;
key->ipv4.tp.flags = TCP_FLAGS_BE16(tcp);
}
} else if (key->ip.proto == IPPROTO_UDP) {
Implement new fragment handling policy. Until now, OVS has handled IP fragments more awkwardly than necessary. It has not been possible to match on L4 headers, even in fragments with offset 0 where they are actually present. This means that there was no way to implement ACLs that treat, say, different TCP ports differently, on fragmented traffic; instead, all decisions for fragment forwarding had to be made on the basis of L2 and L3 headers alone. This commit improves the situation significantly. It is still not possible to match on L4 headers in fragments with nonzero offset, because that information is simply not present in such fragments, but this commit adds the ability to match on L4 headers for fragments with zero offset. This means that it becomes possible to implement ACLs that drop such "first fragments" on the basis of L4 headers. In practice, that effectively blocks even fragmented traffic on an L4 basis, because the receiving IP stack cannot reassemble a full packet when the first fragment is missing. This commit works by adding a new "fragment type" to the kernel flow match and making it available through OpenFlow as a new NXM field named NXM_NX_IP_FRAG. Because OpenFlow 1.0 explicitly says that the L4 fields are always 0 for IP fragments, it adds a new OpenFlow fragment handling mode that fills in the L4 fields for "first fragments". It also enhances ovs-ofctl to allow users to configure this new fragment handling mode and to parse the new field. Signed-off-by: Ben Pfaff <blp@nicira.com> Bug #7557.
2011-10-19 21:33:44 -07:00
if (udphdr_ok(skb)) {
struct udphdr *udp = udp_hdr(skb);
key->ipv4.tp.src = udp->source;
key->ipv4.tp.dst = udp->dest;
}
} else if (key->ip.proto == IPPROTO_SCTP) {
if (sctphdr_ok(skb)) {
struct sctphdr *sctp = sctp_hdr(skb);
key->ipv4.tp.src = sctp->source;
key->ipv4.tp.dst = sctp->dest;
}
} else if (key->ip.proto == IPPROTO_ICMP) {
Implement new fragment handling policy. Until now, OVS has handled IP fragments more awkwardly than necessary. It has not been possible to match on L4 headers, even in fragments with offset 0 where they are actually present. This means that there was no way to implement ACLs that treat, say, different TCP ports differently, on fragmented traffic; instead, all decisions for fragment forwarding had to be made on the basis of L2 and L3 headers alone. This commit improves the situation significantly. It is still not possible to match on L4 headers in fragments with nonzero offset, because that information is simply not present in such fragments, but this commit adds the ability to match on L4 headers for fragments with zero offset. This means that it becomes possible to implement ACLs that drop such "first fragments" on the basis of L4 headers. In practice, that effectively blocks even fragmented traffic on an L4 basis, because the receiving IP stack cannot reassemble a full packet when the first fragment is missing. This commit works by adding a new "fragment type" to the kernel flow match and making it available through OpenFlow as a new NXM field named NXM_NX_IP_FRAG. Because OpenFlow 1.0 explicitly says that the L4 fields are always 0 for IP fragments, it adds a new OpenFlow fragment handling mode that fills in the L4 fields for "first fragments". It also enhances ovs-ofctl to allow users to configure this new fragment handling mode and to parse the new field. Signed-off-by: Ben Pfaff <blp@nicira.com> Bug #7557.
2011-10-19 21:33:44 -07:00
if (icmphdr_ok(skb)) {
struct icmphdr *icmp = icmp_hdr(skb);
/* The ICMP type and code fields use the 16-bit
* transport port fields, so we need to store
* them in 16-bit network byte order. */
key->ipv4.tp.src = htons(icmp->type);
key->ipv4.tp.dst = htons(icmp->code);
}
}
} else if ((key->eth.type == htons(ETH_P_ARP) ||
key->eth.type == htons(ETH_P_RARP)) && arphdr_ok(skb)) {
struct arp_eth_header *arp;
arp = (struct arp_eth_header *)skb_network_header(skb);
if (arp->ar_hrd == htons(ARPHRD_ETHER)
&& arp->ar_pro == htons(ETH_P_IP)
&& arp->ar_hln == ETH_ALEN
&& arp->ar_pln == 4) {
/* We only match on the lower 8 bits of the opcode. */
if (ntohs(arp->ar_op) <= 0xff)
key->ip.proto = ntohs(arp->ar_op);
memcpy(&key->ipv4.addr.src, arp->ar_sip, sizeof(key->ipv4.addr.src));
memcpy(&key->ipv4.addr.dst, arp->ar_tip, sizeof(key->ipv4.addr.dst));
memcpy(key->ipv4.arp.sha, arp->ar_sha, ETH_ALEN);
memcpy(key->ipv4.arp.tha, arp->ar_tha, ETH_ALEN);
}
} else if (key->eth.type == htons(ETH_P_IPV6)) {
int nh_len; /* IPv6 Header + Extensions */
nh_len = parse_ipv6hdr(skb, key);
if (unlikely(nh_len < 0)) {
if (nh_len == -EINVAL) {
skb->transport_header = skb->network_header;
error = 0;
} else {
error = nh_len;
}
return error;
}
if (key->ip.frag == OVS_FRAG_TYPE_LATER)
return 0;
Implement new fragment handling policy. Until now, OVS has handled IP fragments more awkwardly than necessary. It has not been possible to match on L4 headers, even in fragments with offset 0 where they are actually present. This means that there was no way to implement ACLs that treat, say, different TCP ports differently, on fragmented traffic; instead, all decisions for fragment forwarding had to be made on the basis of L2 and L3 headers alone. This commit improves the situation significantly. It is still not possible to match on L4 headers in fragments with nonzero offset, because that information is simply not present in such fragments, but this commit adds the ability to match on L4 headers for fragments with zero offset. This means that it becomes possible to implement ACLs that drop such "first fragments" on the basis of L4 headers. In practice, that effectively blocks even fragmented traffic on an L4 basis, because the receiving IP stack cannot reassemble a full packet when the first fragment is missing. This commit works by adding a new "fragment type" to the kernel flow match and making it available through OpenFlow as a new NXM field named NXM_NX_IP_FRAG. Because OpenFlow 1.0 explicitly says that the L4 fields are always 0 for IP fragments, it adds a new OpenFlow fragment handling mode that fills in the L4 fields for "first fragments". It also enhances ovs-ofctl to allow users to configure this new fragment handling mode and to parse the new field. Signed-off-by: Ben Pfaff <blp@nicira.com> Bug #7557.
2011-10-19 21:33:44 -07:00
if (skb_shinfo(skb)->gso_type & SKB_GSO_UDP)
key->ip.frag = OVS_FRAG_TYPE_FIRST;
Implement new fragment handling policy. Until now, OVS has handled IP fragments more awkwardly than necessary. It has not been possible to match on L4 headers, even in fragments with offset 0 where they are actually present. This means that there was no way to implement ACLs that treat, say, different TCP ports differently, on fragmented traffic; instead, all decisions for fragment forwarding had to be made on the basis of L2 and L3 headers alone. This commit improves the situation significantly. It is still not possible to match on L4 headers in fragments with nonzero offset, because that information is simply not present in such fragments, but this commit adds the ability to match on L4 headers for fragments with zero offset. This means that it becomes possible to implement ACLs that drop such "first fragments" on the basis of L4 headers. In practice, that effectively blocks even fragmented traffic on an L4 basis, because the receiving IP stack cannot reassemble a full packet when the first fragment is missing. This commit works by adding a new "fragment type" to the kernel flow match and making it available through OpenFlow as a new NXM field named NXM_NX_IP_FRAG. Because OpenFlow 1.0 explicitly says that the L4 fields are always 0 for IP fragments, it adds a new OpenFlow fragment handling mode that fills in the L4 fields for "first fragments". It also enhances ovs-ofctl to allow users to configure this new fragment handling mode and to parse the new field. Signed-off-by: Ben Pfaff <blp@nicira.com> Bug #7557.
2011-10-19 21:33:44 -07:00
/* Transport layer. */
if (key->ip.proto == NEXTHDR_TCP) {
if (tcphdr_ok(skb)) {
struct tcphdr *tcp = tcp_hdr(skb);
key->ipv6.tp.src = tcp->source;
key->ipv6.tp.dst = tcp->dest;
key->ipv6.tp.flags = TCP_FLAGS_BE16(tcp);
}
} else if (key->ip.proto == NEXTHDR_UDP) {
if (udphdr_ok(skb)) {
struct udphdr *udp = udp_hdr(skb);
key->ipv6.tp.src = udp->source;
key->ipv6.tp.dst = udp->dest;
}
} else if (key->ip.proto == NEXTHDR_SCTP) {
if (sctphdr_ok(skb)) {
struct sctphdr *sctp = sctp_hdr(skb);
key->ipv6.tp.src = sctp->source;
key->ipv6.tp.dst = sctp->dest;
}
} else if (key->ip.proto == NEXTHDR_ICMP) {
if (icmp6hdr_ok(skb)) {
error = parse_icmpv6(skb, key, nh_len);
if (error)
return error;
}
}
}
return 0;
}