netdev - Re: [PATCH net-next 06/11] ipmr, ip6mr: Make mfc

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: <20180228205023.GA52760@dev-r-vrt-155.mtr.labs.mlnx>
Date:   Wed, 28 Feb 2018 22:50:24 +0200
From:   Yuval Mintz <yuvalm@...lanox.com>
To:     Nikolay Aleksandrov <nikolay@...ulusnetworks.com>
Cc:     Yuval Mintz <yuvalm@...lanox.com>, netdev@...r.kernel.org,
        mlxsw@...lanox.com, kuznet@....inr.ac.ru, yoshfuji@...ux-ipv6.org
Subject: Re: [PATCH net-next 06/11] ipmr, ip6mr: Make mfc_cache a common
 structure

On Wed, Feb 28, 2018 at 12:38:20AM +0200, Nikolay Aleksandrov wrote:
> On 27/02/18 20:58, Yuval Mintz wrote:
> > mfc_cache and mfc6_cache are almost identical - the main difference is
> > in the origin/group addresses and comparison-key. Make a common
> > structure encapsulating most of the multicast routing logic  - mr_mfc
> > and convert both ipmr and ip6mr into using it.
> > 
> > For easy conversion [casting, in this case] mr_mfc has to be the first
> > field inside every multicast routing abstraction utilizing it.
> > 
> > Signed-off-by: Yuval Mintz <yuvalm@...lanox.com>
> > ---
> >  drivers/net/ethernet/mellanox/mlxsw/spectrum_mr.c |  21 +-
> >  include/linux/mroute.h                            |  45 +---
> >  include/linux/mroute6.h                           |  23 +--
> >  include/linux/mroute_base.h                       |  45 ++++
> >  net/ipv4/ipmr.c                                   | 234 +++++++++++----------
> >  net/ipv6/ip6mr.c                                  | 241 +++++++++++-----------
> >  6 files changed, 312 insertions(+), 297 deletions(-)
> > 
> 
> I feel uneasy about these casts all over the place, anyway functionally
> the patch looks fine.

Well, testing revealed a bug in handling unresolved cache entries;
I'll fix it as well in v2.