netdev - Re: [PATCH v3 net-next 0/5] IGMP snooping for local traffic

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: <87d14ut405.fsf@weeman.i-did-not-set--mail-host-address--so-tickle-me>
Date:   Tue, 07 Nov 2017 12:03:54 -0500
From:   Vivien Didelot <vivien.didelot@...oirfairelinux.com>
To:     Andrew Lunn <andrew@...n.ch>, David Miller <davem@...emloft.net>
Cc:     netdev <netdev@...r.kernel.org>,
        Florian Fainelli <f.fainelli@...il.com>,
        Andrew Lunn <andrew@...n.ch>
Subject: Re: [PATCH v3 net-next 0/5] IGMP snooping for local traffic

Hi Andrew,

Andrew Lunn <andrew@...n.ch> writes:

> Then starts the work passing down to the hardware that the host has
> joined/left a group. The existing switchdev mdb object cannot be used,
> since the semantics are different. The existing
> SWITCHDEV_OBJ_ID_PORT_MDB is used to indicate a specific multicast
> group should be forwarded out that port of the switch. However here we
> require the exact opposite. We want multicast frames for the group
> received on the port to the forwarded to the host. Hence add a new
> object SWITCHDEV_OBJ_ID_HOST_MDB, a multicast database entry to
> forward to the host. This new object is then propagated through the
> DSA layers. No DSA driver changes should be needed, this should just
> work...

The patchset looks good. I would like to ask you some details though,
because I don't understand why the semantics are different.

Technically, what happens is that an MDB entry is programmed on the
bridge interface. From the _bridge point of view_, there is no technical
difference as in programming an MDB entry on a bridged port. Correct?

So we can simply use an mdb switchdev_obj_port_mdb structure with:

    mdb.orig_dev = mdb.dev = br->dev;

The structure will still be propagated to all bridge members as usual
and switchdev users can check the above fields.

>From the _DSA point of view_, mdb->orig_dev == dp->bridge_dev would mean
that we must program dp->cpu_dp, the bridge port's dedicated CPU port.

To me it looks like the only confusion here is in the name of the
switchdev object, where SWITCHDEV_OBJ_ID_PORT_MDB and
switchdev_obj_port_mdb must be in fact SWITCHDEV_OBJ_ID_MDB and
switchdev_obj_mdb. Or I am missing something?

I just want to make sure I understand the whole picture correctly here.
About the patchset itself, introducing SWITCHDEV_OBJ_ID_HOST_MDB seems
to be only meant to avoid a noisy global renaming, in which case I'm
fine with that.

My only concern is that it looks like we'll have the same issue with
programming e.g. VLAN or static FDB entries on the bridge interface, in
which case the correct way to go would be to use and check orig_dev.

Thanks,

        Vivien