linux-kernel - Re: [PATCH net-next v3 0/2] bridge: mrp: Extend MRP netlink interface with IFLA_BRIDGE_MRP

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] [day] [month] [year] [list]

Date:   Sun, 28 Jun 2020 14:59:25 +0200
From:   Horatiu Vultur <horatiu.vultur@...rochip.com>
To:     David Miller <davem@...emloft.net>
CC:     <nikolay@...ulusnetworks.com>, <roopa@...ulusnetworks.com>,
        <kuba@...nel.org>, <netdev@...r.kernel.org>,
        <linux-kernel@...r.kernel.org>, <bridge@...ts.linux-foundation.org>
Subject: Re: [PATCH net-next v3 0/2] bridge: mrp: Extend MRP netlink
 interface with IFLA_BRIDGE_MRP_CLEAR

The 06/26/2020 13:00, David Miller wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> 
> From: Horatiu Vultur <horatiu.vultur@...rochip.com>
> Date: Fri, 26 Jun 2020 09:33:47 +0200
> 
> > This patch series extends MRP netlink interface with IFLA_BRIDGE_MRP_CLEAR.
> > To allow the userspace to clear all MRP instances when is started. The
> > second patch in the series fix different sparse warnings.
> >
> > v3:
> >   - add the second patch to fix sparse warnings

Hi,
> 
> These changes are completely unrelated.
> 
> The sparse stuff should probably be submitted to 'net'.

I will send a patch for this to 'net'.

> 
> And I have to ask why you really need a clear operation. 

Because we didn't have any way for the userspace to know what ports are
part of the MRP ring. I thought the easiest way would be for the daemon
to clear everything when is started.

> Routing
> daemons come up and see what routes are installed, and update their
> internal SW tables to match.  This not only allows efficient restart
> after a crash, but it also allows multiple daemons to work
> cooperatively as an agent for the same forwarding/routing table.

I think it would be possible to have something similar for the MRP
daemon. But I still have problems to see how to have multiple MRP
daemons running at the same time. Because each deamon implements MRP
state machine. So for example if the link of one of the MRP ports is
changing then each daemon is notified about this change so then each
daemon will send some frames, and that would mean that we have duplicate
frames in the network.

> 
> Your usage model limits one daemon to manage the table and that
> limitation is completely unnecessary.
> 
> Furthermore, even in a one-daemon scenerio, it's wasteful to throw
> away all the work the previous daemon did to load the MRP entries into
> the bridge.
> 
> Thanks.
> 

-- 
/Horatiu