netdev - Re: [patch net-next 0/7] mlxsw: Identical routes handling

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: <20170210.113444.1607640729939984965.davem@davemloft.net>
Date:   Fri, 10 Feb 2017 11:34:44 -0500 (EST)
From:   David Miller <davem@...emloft.net>
To:     jiri@...nulli.us
Cc:     netdev@...r.kernel.org, idosch@...lanox.com, eladr@...lanox.com,
        mlxsw@...lanox.com
Subject: Re: [patch net-next 0/7] mlxsw: Identical routes handling

From: Jiri Pirko <jiri@...nulli.us>
Date: Thu,  9 Feb 2017 10:28:37 +0100

> From: Jiri Pirko <jiri@...lanox.com>
> 
> Ido says:
> 
> The kernel can store several FIB aliases that share the same prefix and
> length. These aliases can differ in other parameters such as TOS and
> metric, which are taken into account during lookup.
> 
> Offloading devices might not have the same flexibility, allowing only a
> single route with the same prefix and length to be reflected. mlxsw is
> one such device.
> 
> This patchset aims to correctly handle this situation in the mlxsw
> driver. The first four patches introduce small changes in the IPv4 FIB
> code, so that listeners of the FIB notification chain will be able to
> correctly handle identical routes.
> 
> The last three patches build on top of previous work and introduce the
> necessary changes in the mlxsw driver. The biggest change is the
> introduction of a FIB node, where identical routes are chained, instead
> of a primitive reference counting. This is explained in detail in the
> fifth patch.

Looks good, series applied, thanks Jiri and Ido.

I think you took care of this properly, but just always make sure that
if a delete event is emitted the object is not in the table any longer
and cannot be discovered by a parallel thread of execution at that
point.

Likewise a good rule of thumb is to make sure the object is
discoverable when you emit the add event.

Thanks again.