netdev - Re: [PATCH RFC net-next 00/13] RX filtering for DSA switches

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: <20201101161308.qt3i72e37qydtpwz@skbuf>
Date:   Sun, 1 Nov 2020 18:13:08 +0200
From:   Vladimir Oltean <olteanv@...il.com>
To:     Ido Schimmel <idosch@...sch.org>
Cc:     Andrew Lunn <andrew@...n.ch>,
        Florian Fainelli <f.fainelli@...il.com>,
        Vivien Didelot <vivien.didelot@...il.com>,
        "David S. Miller" <davem@...emloft.net>,
        Jiri Pirko <jiri@...nulli.us>,
        Jakub Kicinski <kuba@...nel.org>,
        Ivan Vecera <ivecera@...hat.com>, vyasevich@...il.com,
        netdev <netdev@...r.kernel.org>, UNGLinuxDriver@...rochip.com,
        Nikolay Aleksandrov <nikolay@...ulusnetworks.com>,
        Roopa Prabhu <roopa@...ulusnetworks.com>
Subject: Re: [PATCH RFC net-next 00/13] RX filtering for DSA switches

On Sun, Nov 01, 2020 at 05:39:06PM +0200, Ido Schimmel wrote:
> You also wondered which indication you would get down to the driver that
> eventually needs to program the hardware to get the packets:
> 
> "Who will notify me of these multicast addresses if I'm bridged and I
> need to terminate L2 or L4 PTP through the data path of the slave
> interfaces and not of the bridge."
> 
> Which kernel entity you want to get the notification from? The packet
> socket wants the packets, so it should notify you. The kernel is aware
> that traffic is offloaded and can do whatever it needs (e.g., calling
> the ndo) in order to extract packets from the hardware data path to the
> CPU and to the socket.

Honestly, just as I was saying, I was thinking about using the
dev_mc_add call that is emitted today, and simply auditing the
dev_mc_add and dev_uc_add calls which are unnecessary (like in the case
of non-automatic bridge interfaces), for example like this:

if (!(dev->features & NETIF_F_PROMISC_BY_DEFAULT))
	dev_uc_add(dev, static bridge fdb entry);

To me this would be the least painful way forward.