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]
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.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ