kernel/net/openvswitch/flow_table.c, branch linux-4.1.y

ovs: do not allocate memory from offline numa node

2015-10-27T00:51:50Z

[ Upstream commit 598c12d0ba6de9060f04999746eb1e015774044b ] When openvswitch tries allocate memory from offline numa node 0: stats = kmem_cache_alloc_node(flow_stats_cache, GFP_KERNEL | __GFP_ZERO, 0) It catches VM_BUG_ON(nid < 0 || nid >= MAX_NUMNODES || !node_online(nid)) [ replaced with VM_WARN_ON(!node_online(nid)) recently ] in linux/gfp.h This patch disables numa affinity in this case. Signed-off-by: Konstantin Khlebnikov Acked-by: Pravin B Shelar Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman

openvswitch: Zero flows on allocation.

2015-10-03T11:49:16Z

[ Upstream commit ae5f2fb1d51fa128a460bcfbe3c56d7ab8bf6a43 ] When support for megaflows was introduced, OVS needed to start installing flows with a mask applied to them. Since masking is an expensive operation, OVS also had an optimization that would only take the parts of the flow keys that were covered by a non-zero mask. The values stored in the remaining pieces should not matter because they are masked out. While this works fine for the purposes of matching (which must always look at the mask), serialization to netlink can be problematic. Since the flow and the mask are serialized separately, the uninitialized portions of the flow can be encoded with whatever values happen to be present. In terms of functionality, this has little effect since these fields will be masked out by definition. However, it leaks kernel memory to userspace, which is a potential security vulnerability. It is also possible that other code paths could look at the masked key and get uninitialized data, although this does not currently appear to be an issue in practice. This removes the mask optimization for flows that are being installed. This was always intended to be the case as the mask optimizations were really targetting per-packet flow operations. Fixes: 03f0d916 ("openvswitch: Mega flow implementation") Signed-off-by: Jesse Gross Acked-by: Pravin B Shelar Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman

openvswitch: Initialize unmasked key and uid len

2015-02-08T08:51:14Z

Flow alloc needs to initialize unmasked key pointer. Otherwise it can crash kernel trying to free random unmasked-key pointer. general protection fault: 0000 [#1] SMP 3.19.0-rc6-net-next+ #457 Hardware name: Supermicro X7DWU/X7DWU, BIOS 1.1 04/30/2008 RIP: 0010:[] [] kfree+0xac/0x196 Call Trace: [] flow_free+0x21/0x59 [openvswitch] [] ovs_flow_free+0x21/0x23 [openvswitch] [] ovs_packet_cmd_execute+0x2f3/0x35f [openvswitch] [] ? ovs_packet_cmd_execute+0x13e/0x35f [openvswitch] [] ? nla_parse+0x4f/0xec [] genl_family_rcv_msg+0x26d/0x2c9 [] ? __lock_acquire+0x90e/0x9aa [] genl_rcv_msg+0x66/0x89 [] ? genl_family_rcv_msg+0x2c9/0x2c9 [] netlink_rcv_skb+0x3e/0x95 [] ? genl_rcv+0x18/0x37 [] genl_rcv+0x27/0x37 [] netlink_unicast+0x103/0x191 [] netlink_sendmsg+0x2c1/0x310 [] ? might_fault+0x50/0xa0 [] do_sock_sendmsg+0x5f/0x7a [] sock_sendmsg+0xb/0xd [] ___sys_sendmsg+0x1a3/0x218 [] ? get_close_on_exec+0x86/0x86 [] ? fsnotify+0x32c/0x348 [] ? fsnotify+0x7c/0x348 [] ? __fget+0xaa/0xbf [] ? get_close_on_exec+0x86/0x86 [] __sys_sendmsg+0x3d/0x5e [] SyS_sendmsg+0x14/0x16 [] system_call_fastpath+0x12/0x17 Fixes: 74ed7ab9264("openvswitch: Add support for unique flow IDs.") CC: Joe Stringer Reported-by: Or Gerlitz Signed-off-by: Pravin B Shelar Acked-by: Eric Dumazet Signed-off-by: David S. Miller

openvswitch: Add support for unique flow IDs.

2015-01-26T23:45:50Z

Previously, flows were manipulated by userspace specifying a full, unmasked flow key. This adds significant burden onto flow serialization/deserialization, particularly when dumping flows. This patch adds an alternative way to refer to flows using a variable-length "unique flow identifier" (UFID). At flow setup time, userspace may specify a UFID for a flow, which is stored with the flow and inserted into a separate table for lookup, in addition to the standard flow table. Flows created using a UFID must be fetched or deleted using the UFID. All flow dump operations may now be made more terse with OVS_UFID_F_* flags. For example, the OVS_UFID_F_OMIT_KEY flag allows responses to omit the flow key from a datapath operation if the flow has a corresponding UFID. This significantly reduces the time spent assembling and transacting netlink messages. With all OVS_UFID_F_OMIT_* flags enabled, the datapath only returns the UFID and statistics for each flow during flow dump, increasing ovs-vswitchd revalidator performance by 40% or more. Signed-off-by: Joe Stringer Acked-by: Pravin B Shelar Signed-off-by: David S. Miller

openvswitch: Use sw_flow_key_range for key ranges.

2015-01-26T23:45:50Z

These minor tidyups make a future patch a little tidier. Signed-off-by: Joe Stringer Acked-by: Pravin B Shelar Signed-off-by: David S. Miller

openvswitch: Refactor ovs_flow_tbl_insert().

2015-01-26T23:45:49Z

Rework so that ovs_flow_tbl_insert() calls flow_{key,mask}_insert(). This tidies up a future patch. Signed-off-by: Joe Stringer Acked-by: Pravin B Shelar Signed-off-by: David S. Miller

net: replace remaining users of arch_fast_hash with jhash

2014-12-10T20:17:45Z

This patch effectively reverts commit 500f80872645 ("net: ovs: use CRC32 accelerated flow hash if available"), and other remaining arch_fast_hash() users such as from nfsd via commit 6282cd565553 ("NFSD: Don't hand out delegations for 30 seconds after recalling them.") where it has been used as a hash function for bloom filtering. While we think that these users are actually not much of concern, it has been requested to remove the arch_fast_hash() library bits that arose from [1] entirely as per recent discussion [2]. The main argument is that using it as a hash may introduce bias due to its linearity (see avalanche criterion) and thus makes it less clear (though we tried to document that) when this security/performance trade-off is actually acceptable for a general purpose library function. Lets therefore avoid any further confusion on this matter and remove it to prevent any future accidental misuse of it. For the time being, this is going to make hashing of flow keys a bit more expensive in the ovs case, but future work could reevaluate a different hashing discipline. [1] https://patchwork.ozlabs.org/patch/299369/ [2] https://patchwork.ozlabs.org/patch/418756/ Cc: Neil Brown Cc: Francesco Fusco Cc: Jesse Gross Cc: Thomas Graf Signed-off-by: Daniel Borkmann Signed-off-by: David S. Miller

openvswitch: Constify various function arguments

2014-11-10T02:58:44Z

Help produce better optimized code. Signed-off-by: Thomas Graf Signed-off-by: Pravin B Shelar

openvswitch: Move table destroy to dp-rcu callback.

2014-11-06T07:52:34Z

Ths simplifies flow-table-destroy API. No need to pass explicit parameter about context. Signed-off-by: Pravin B Shelar Acked-by: Thomas Graf

openvswitch: Use exact lookup for flow_get and flow_del.

2014-07-01T03:47:15Z

Due to the race condition in userspace, there is chance that two overlapping megaflows could be installed in datapath. And this causes userspace unable to delete the less inclusive megaflow flow even after it timeout, since the flow_del logic will stop at the first match of masked flow. This commit fixes the bug by making the kernel flow_del and flow_get logic check all masks in that case. Introduced by 03f0d916a (openvswitch: Mega flow implementation). Signed-off-by: Alex Wang Acked-by: Andy Zhou Signed-off-by: Pravin B Shelar