netdev - Re: [PATCH net-next 1/2] bridge: Add a limit on FDB entries

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: Tue, 16 May 2023 14:04:30 +0300
From: Nikolay Aleksandrov <razor@...ckwall.org>
To: Vladimir Oltean <vladimir.oltean@....com>
Cc: Andrew Lunn <andrew@...n.ch>, Florian Fainelli <f.fainelli@...il.com>,
 Oleksij Rempel <linux@...pel-privat.de>,
 Johannes Nixdorf <jnixdorf-oss@....de>, netdev@...r.kernel.org,
 bridge@...ts.linux-foundation.org, "David S. Miller" <davem@...emloft.net>,
 Eric Dumazet <edumazet@...gle.com>, Jakub Kicinski <kuba@...nel.org>,
 Paolo Abeni <pabeni@...hat.com>, Roopa Prabhu <roopa@...dia.com>,
 Ido Schimmel <idosch@...dia.com>
Subject: Re: [PATCH net-next 1/2] bridge: Add a limit on FDB entries

On 16/05/2023 13:55, Vladimir Oltean wrote:
> On Tue, May 16, 2023 at 01:47:47PM +0300, Nikolay Aleksandrov wrote:
>> Having the current count is just a helper, if you have a high limit dumping the table
>> and counting might take awhile. Thanks for the feedback, then we'll polish and move
>> on with the set for a global limit.
> 
> Ok, but to be useful, the current count will have to be directly
> comparable to the limit, I guess. So the current count will also be for
> dynamically learned entries? Or is the plan to enforce the global limit
> for any kind of FDB entries?

That was one of the questions actually. More that I'm thinking about this, the more
I want to break it apart by type because we discussed being able to specify a flag
mask for the limit (all, dynamic, dynamic+static etc). If we embed these stats into a
bridge fdb count attribute, it can be easily extended later if anything new comes along.
If switchdev doesn't support some of these global limit configs, we can pass the option
and it can deny setting it later. I think this should be more than enough as a first step.