netdev - Re: [PATCH net-next v2 0/8] net: bridge: add flush filtering support

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]

Message-ID: <20220411124910.772dc7a0@kernel.org>
Date:   Mon, 11 Apr 2022 12:49:10 -0700
From:   Jakub Kicinski <kuba@...nel.org>
To:     Roopa Prabhu <roopa@...dia.com>
Cc:     Nikolay Aleksandrov <razor@...ckwall.org>, netdev@...r.kernel.org,
        idosch@...sch.org, davem@...emloft.net,
        bridge@...ts.linux-foundation.org
Subject: Re: [PATCH net-next v2 0/8] net: bridge: add flush filtering
 support

On Mon, 11 Apr 2022 12:22:24 -0700 Roopa Prabhu wrote:
> >> I thought about that option, but I didn't like overloading delneigh like that.
> >> del currently requires a mac address and we need to either signal the device supports> a null mac, or we should push that verification to ndo_fdb_del users. Also we'll have  
> > that's the only thing, overloading delneigh with a flush-behaviour (multi-del or whatever)
> > would require to push the mac check to ndo_fdb_del implementers
> >
> > I don't mind going that road if others agree that we should do it through delneigh
> > + a bit/option to signal flush, instead of a new rtm type.
> >  
> >> attributes which are flush-specific and will work only when flushing as opposed to when
> >> deleting a specific mac, so handling them in the different cases can become a pain.  
> > scratch the specific attributes, those can be adapted for both cases
> >  
> >> MDBs will need DELMDB to be modified in a similar way.
> >>
> >> IMO a separate flush op is cleaner, but I don't have a strong preference.
> >> This can very easily be adapted to delneigh with just a bit more mechanical changes
> >> if the mac check is pushed to the ndo implementers.
> >>
> >> FLUSHNEIGH can easily work for neighs, just need another address family rtnl_register
> >> that implements it, the new ndo is just for PF_BRIDGE. :)  
> 
> all great points. My only reason to explore RTM_DELNEIGH is to see if we 
> can find a recipe to support similar bulk deletes of other objects 
> handled via rtm msgs in the future. Plus, it allows you to maintain 
> symmetry between flush requests and object delete notification msg types.
> 
> Lets see if there are other opinions.

I'd vote for reusing RTM_DELNEIGH, but that's purely based on
intuition, I don't know this code. I'd also lean towards core
creating struct net_bridge_fdb_flush_desc rather than piping
raw netlink attrs thru. Lastly feels like fdb ops should find 
a new home rather than ndos, but that's largely unrelated..