linux-kernel - Re: [PATCH 0/5] staging: fsl-dpaa2/ethsw: add the .ndo_fdb

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 29 Jul 2019 18:35:06 +0200
From:   Andrew Lunn <andrew@...n.ch>
To:     Ioana Ciornei <ioana.ciornei@....com>
Cc:     gregkh@...uxfoundation.org, linux-kernel@...r.kernel.org,
        netdev@...r.kernel.org, davem@...emloft.net, f.fainelli@...il.com,
        jiri@...lanox.com
Subject: Re: [PATCH 0/5] staging: fsl-dpaa2/ethsw: add the .ndo_fdb_dump
 callback

On Mon, Jul 29, 2019 at 07:11:47PM +0300, Ioana Ciornei wrote:
> This patch set adds some features and small fixes in the
> FDB table manipulation area.
> 
> First of all, we implement the .ndo_fdb_dump netdev callback so that all
> offloaded FDB entries, either static or learnt, are available to the user.
> This is necessary because the DPAA2 switch does not emit interrupts when a
> new FDB is learnt or deleted, thus we are not able to keep the software
> bridge state and the HW in sync by calling the switchdev notifiers.
> 
> The patch set also adds the .ndo_fdb_[add|del] callbacks in order to
> facilitate adding FDB entries not associated with any master device.
> 
> One interesting thing that I observed is that when adding an FDB entry
> associated with a bridge (ie using the 'master' keywork appended to the
> bridge command) and then dumping the FDB entries, there will be duplicates
> of the same entry: one listed by the bridge device and one by the
> driver's .ndo_fdb_dump).
> It raises the question whether this is the expected behavior or not.

DSA devices are the same, they don't provide an interrupt when a new
entry is added by the hardware. So we can have two entries, or just
the SW bridge entry, or just the HW entry, depending on ageing.
 
> Another concern is regarding the correct/desired machanism for drivers to
> signal errors back to switchdev on adding or deleting an FDB entry.
> In the switchdev documentation, there is a TODO in the place of this topic.

It used to be a two state prepare/commit transaction, but that was
changed a while back.

Maybe the DSA core code can give you ideas?

      Andrew