netdev - Re: [PATCH net-next 0/3] mlxsw: Removing dependency of mlxsw on GRE

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] [day] [month] [year] [list]

Message-Id: <20180312.110949.556490116501263200.davem@davemloft.net>
Date:   Mon, 12 Mar 2018 11:09:49 -0400 (EDT)
From:   David Miller <davem@...emloft.net>
To:     idosch@...lanox.com
Cc:     netdev@...r.kernel.org, petrm@...lanox.com, jiri@...lanox.com,
        dsahern@...il.com, mlxsw@...lanox.com
Subject: Re: [PATCH net-next 0/3] mlxsw: Removing dependency of mlxsw on GRE

From: Ido Schimmel <idosch@...lanox.com>
Date: Sun, 11 Mar 2018 09:44:39 +0200

> Petr says:
> 
> mlxsw_spectrum supports offloading of a tc action mirred egress mirror
> to a gretap or ip6gretap netdevice, which necessitates calls to
> functions defined in ip_gre, ip6_gre and ip6_tunnel modules. Previously
> this was enabled by introducing a hard dependency of MLXSW_SPECTRUM on
> NET_IPGRE and IPV6_GRE. However the rest of mlxsw is careful about
> picking which modules are absolutely required, and therefore the better
> approach is to make mlxsw_spectrum tolerant of absence of one or both of
> the GRE flavors.
> 
> One way this might be resolved is by keeping the code in mlxsw_spectrum
> intact, and defining defaults for functions that mlxsw_spectrum depends
> on. The downsides are that other modules end up littered with these
> do-nothing defaults; that the driver ends up carrying quite a bit of
> dead code; and that the driver ends up having to explicitly depend on
> IPV6_TUNNEL to prevent configurations where mlxsw_spectrum is compiled
> in and and ip6_tunnel is a module, something that it currently can treat
> as an implementation detail of the IPV6_GRE dependency.
> 
> Alternatively, the driver should just bite the bullet and ifdef-out the
> code that handles configurations that are not supported. Since that's
> what we are doing for IPv6 dependency, let's do the same for the GRE
> flavors.
> 
> Patch #1 introduces a wrapper function for determining the value of
> ipv6.sysctl.multipath_hash_policy, which defaults to 0 on non-IPv6
> builds. That function is then used from spectrum_router.c, instead of
> the direct variable reference that was introduced there during the short
> window when the Spectrum driver had a hard dependency on IPv6.
> 
> Patch #2 moves one function to keep together in one block all the
> callbacks for handling (IPv4) gretap mirroring.
> 
> Patch #3 then introduces the ifdefs to hide the irrelevant code.

Series applied.