netdev - Re: [net-next 07/15] net/mlx5: Bridge, expose FDB state via debugfs

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]

Message-ID: <20230619120515.5045132a@kernel.org>
Date: Mon, 19 Jun 2023 12:05:15 -0700
From: Jakub Kicinski <kuba@...nel.org>
To: Vlad Buslov <vladbu@...dia.com>
Cc: Saeed Mahameed <saeed@...nel.org>, "David S. Miller"
 <davem@...emloft.net>, Paolo Abeni <pabeni@...hat.com>, Eric Dumazet
 <edumazet@...gle.com>, Saeed Mahameed <saeedm@...dia.com>,
 <netdev@...r.kernel.org>, Tariq Toukan <tariqt@...dia.com>, Gal Pressman
 <gal@...dia.com>
Subject: Re: [net-next 07/15] net/mlx5: Bridge, expose FDB state via debugfs

On Mon, 19 Jun 2023 21:34:02 +0300 Vlad Buslov wrote:
> > Looks like my pw-bot shenanigans backfired / crashed, patches didn't
> > get marked as Changes Requested and Dave applied the series :S
> >
> > I understand the motivation but the information is easy enough to
> > understand to potentially tempt a user to start depending on it for
> > production needs. Then another vendor may get asked to implement
> > similar but not exactly the same set of stats etc. etc.  
> 
> That could happen (although consider that bridge offload functionality
> significantly predates mlx5 implementation and apparently no one really
> needed that until now), but such API would supplement, not replace the
> debugfs since we would like to have per-eswitch FDB state exposed
> together with our internal flags and everything as explained in my
> previous email.

Because crossing between eswitches incurs additional cost?

> > Do you have customer who will need this?  
> 
> Yes. But strictly for debugging (by human), not for building some
> proprietary weird user-space switch-controller application that would
> query this in normal mode of operation, if I understand your concern
> correctly.
> 
> > At the very least please follow up to make the files readable to only
> > root. Normal users should never look at debugfs IMO.  
> 
> Hmm, all other debugfs' in mlx5 that I tend to use for switching-related
> functionality debugging seems to be 0444 (lag, steering, tc hairpin).
> Why would this one be any different?

Querying the stats seems generally useful, so I'd like to narrow down
the access as much as possible. This way if the usage spreads we'll hear
complaints and can go back to creating a more appropriate API.