netdev - Re: [patch net-next 03/10] ipv4: fib_rules: Dump FIB rules when registering FIB notifier

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:   Mon, 13 Mar 2017 08:52:45 -0600
From:   David Ahern <dsa@...ulusnetworks.com>
To:     Jiri Pirko <jiri@...nulli.us>, netdev@...r.kernel.org
Cc:     davem@...emloft.net, idosch@...lanox.com, mlxsw@...lanox.com,
        shm@...ulusnetworks.com, kuznet@....inr.ac.ru, jmorris@...ei.org,
        yoshfuji@...ux-ipv6.org, kaber@...sh.net, lorenzo@...gle.com,
        mateusz.bajorski@...ia.com
Subject: Re: [patch net-next 03/10] ipv4: fib_rules: Dump FIB rules when
 registering FIB notifier

On 3/13/17 1:38 AM, Jiri Pirko wrote:
> From: Ido Schimmel <idosch@...lanox.com>
> 
> In commit c3852ef7f2f8 ("ipv4: fib: Replay events when registering FIB
> notifier") we dumped the FIB tables and replayed the events to the
> passed notification block.
> 
> However, we merely sent a RULE_ADD notification in case custom rules
> were in use. As explained in previous patches, this approach won't work
> anymore. Instead, we should notify the caller about all the FIB rules
> and let it act accordingly.
> 
> Upon registration to the FIB notification chain, replay a RULE_ADD
> notification for each programmed FIB rule, custom or not. The integrity
> of the dump is ensured by the mechanism introduced in the above
> mentioned commit.
> 
> Prevent regressions by making sure current listeners correctly sanitize
> the notified rules.
> 
> Signed-off-by: Ido Schimmel <idosch@...lanox.com>
> Signed-off-by: Jiri Pirko <jiri@...lanox.com>
> ---
>  drivers/net/ethernet/mellanox/mlxsw/Kconfig           |  1 +
>  drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c | 11 ++++++++++-
>  drivers/net/ethernet/rocker/Kconfig                   |  2 +-
>  drivers/net/ethernet/rocker/rocker_main.c             | 15 +++++++++++++--
>  net/ipv4/fib_rules.c                                  | 19 ++++++++++++++++---
>  5 files changed, 41 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/net/ethernet/mellanox/mlxsw/Kconfig b/drivers/net/ethernet/mellanox/mlxsw/Kconfig
> index ef23eae..a549a89 100644
> --- a/drivers/net/ethernet/mellanox/mlxsw/Kconfig
> +++ b/drivers/net/ethernet/mellanox/mlxsw/Kconfig
> @@ -73,6 +73,7 @@ config MLXSW_SWITCHX2
>  config MLXSW_SPECTRUM
>  	tristate "Mellanox Technologies Spectrum support"
>  	depends on MLXSW_CORE && MLXSW_PCI && NET_SWITCHDEV && VLAN_8021Q
> +	depends on IP_MULTIPLE_TABLES
>  	depends on PSAMPLE || PSAMPLE=n
>  	select PARMAN
>  	default m

Why require multiple tables just b/c the h/w has the ability to support
multiple tables?