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, 5 Jun 2017 16:44:59 +0300
From:   Nikolay Aleksandrov <nikolay@...ulusnetworks.com>
To:     Jiri Pirko <jiri@...nulli.us>, netdev@...r.kernel.org
Cc:     davem@...emloft.net, idosch@...lanox.com, arkadis@...lanox.com,
        mlxsw@...lanox.com, roopa@...ulusnetworks.com,
        stephen@...workplumber.org, ivecera@...hat.com
Subject: Re: [patch net-next 06/19] net: bridge: Receive notification about
 successful FDB offload

On 05/06/17 12:20, Jiri Pirko wrote:
> From: Arkadi Sharshevsky <arkadis@...lanox.com>
> 
> When a new static FDB is added to the bridge a notification is sent to
> the driver for offload. In case of successful offload the driver should
> notify the bridge back, which in turn should mark the FDB as offloaded.
> 
> Currently, externally learned is equivalent for being offloaded which is
> not correct due to the fact that FDBs which are added from user-space are
> also marked as externally learned. In order to specify if an FDB was
> successfully offloaded a new flag is introduced.
> 
> Signed-off-by: Arkadi Sharshevsky <arkadis@...lanox.com>
> Reviewed-by: Ido Schimmel <idosch@...lanox.com>
> Signed-off-by: Jiri Pirko <jiri@...lanox.com>
> ---
>  include/net/switchdev.h        |  1 +
>  include/uapi/linux/neighbour.h |  1 +
>  net/bridge/br.c                | 11 ++++++++++-
>  net/bridge/br_fdb.c            | 22 +++++++++++++++++++++-
>  net/bridge/br_private.h        |  5 ++++-
>  5 files changed, 37 insertions(+), 3 deletions(-)
> 

Overall the patch looks good to me, one thing to note is that there's a race
window between the call to br_fdb_external_learn_add() and br_fdb_offloaded_set()
where a sw port can take over the entry (and thus set added_by_external_learn = 0)
but have br_fdb_offloaded_set() set its offloaded flag to 1. Now I know the bridge
generally has these known race conditions between fdb flag manipulations so just wanted
to mention it.

Reviewed-by: Nikolay Aleksandrov <nikolay@...ulusnetworks.com>


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ