netdev - Re: [PATCH net-next v3 6/7] fib: hook IPv4 fib for hardware offload

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 03 Mar 2015 16:01:12 -0800
From:	Alexander Duyck <alexander.h.duyck@...hat.com>
To:	sfeldma@...il.com, netdev@...r.kernel.org, davem@...emloft.net,
	jiri@...nulli.us, roopa@...ulusnetworks.com
Subject: Re: [PATCH net-next v3 6/7] fib: hook IPv4 fib for hardware offload


On 03/03/2015 03:31 PM, sfeldma@...il.com wrote:
> From: Scott Feldman <sfeldma@...il.com>
>
> Call into the switchdev driver any time an IPv4 fib entry is
> added/modified/deleted from the kernel's FIB.  The switchdev driver may or
> may not install the route to the offload device.  In the case where the
> driver tries to install the route and something goes wrong (device's routing
> table is full, etc), then all of the offloaded routes will be flushed from the
> device, and route forwarding falls back to the kernel.
>
> We can refine this fail-over logic in subsequent patches.  For now, use the
> simplist model of offloading routes up to the point of failure, and then on
> failure, undo everything.
>
> Signed-off-by: Scott Feldman <sfeldma@...il.com>
> ---
>   net/ipv4/fib_trie.c |   36 +++++++++++++++++++++++++++++++++---
>   1 file changed, 33 insertions(+), 3 deletions(-)
>
> diff --git a/net/ipv4/fib_trie.c b/net/ipv4/fib_trie.c
> index 32c0117..668f09b 100644
> --- a/net/ipv4/fib_trie.c
> +++ b/net/ipv4/fib_trie.c
> @@ -79,6 +79,7 @@
>   #include <net/tcp.h>
>   #include <net/sock.h>
>   #include <net/ip_fib.h>
> +#include <net/switchdev.h>
>   #include "fib_lookup.h"
>   
>   #define MAX_STAT_DEPTH 32
> @@ -1161,7 +1162,18 @@ int fib_table_insert(struct fib_table *tb, struct fib_config *cfg)
>   			new_fa->fa_state = state & ~FA_S_ACCESSED;
>   			new_fa->fa_slen = fa->fa_slen;
>   
> +			err = netdev_switch_fib_ipv4_add(key, plen, fi,
> +							 new_fa->fa_tos,
> +							 cfg->fc_type,
> +							 tb->tb_id);
> +			if (err) {
> +				fib_flush_external(fi->fib_net);
> +				kmem_cache_free(fn_alias_kmem, new_fa);
> +				goto out;
> +			}
> +
>   			hlist_replace_rcu(&fa->fa_list, &new_fa->fa_list);
> +
>   			alias_free_mem_rcu(fa);
>   
>   			fib_release_info(fi_drop);
> @@ -1197,12 +1209,20 @@ int fib_table_insert(struct fib_table *tb, struct fib_config *cfg)
>   	new_fa->fa_state = 0;
>   	new_fa->fa_slen = slen;
>   
> +	/* (Optionally) offload fib entry to switch hardware. */
> +	err = netdev_switch_fib_ipv4_add(key, plen, fi, tos,
> +					 cfg->fc_type, tb->tb_id);
> +	if (err) {
> +		fib_flush_external(fi->fib_net);
> +		goto out_free_new_fa;
> +	}
> +
>   	/* Insert new entry to the list. */
>   	if (!l) {
>   		l = fib_insert_node(t, key, plen);
>   		if (unlikely(!l)) {
>   			err = -ENOMEM;
> -			goto out_free_new_fa;
> +			goto out_sw_fib_del;
>   		}
>   	}
>   

Wouldn't it make more sense to insert the route in the trie first, and 
then notify the hardware of the new route?  It seems like it would be 
much easier to pull the route back out of the trie on failure rather 
than having to delete a route from the hardware on a failure to allocate 
memory to store it.

- Alex
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html