linux-kernel - Re: [RFC PATCH net-next 2/5] net: 8021q: vlan_dev: add vid tag for uc and mc address lists

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: <20190122141519.GA3009@khorivan>
Date:   Tue, 22 Jan 2019 16:15:20 +0200
From:   Ivan Khoronzhuk <ivan.khoronzhuk@...aro.org>
To:     Florian Fainelli <f.fainelli@...il.com>
Cc:     davem@...emloft.net, linux-omap@...r.kernel.org,
        netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
        jiri@...lanox.com, andrew@...n.ch, idosch@...lanox.com
Subject: Re: [RFC PATCH net-next 2/5] net: 8021q: vlan_dev: add vid tag for
 uc and mc address lists

On Tue, Jan 08, 2019 at 10:21:25AM -0800, Florian Fainelli wrote:
>On 1/7/19 9:01 PM, Florian Fainelli wrote:
>> Le 12/4/18 à 4:04 PM, Ivan Khoronzhuk a écrit :
>>> On Tue, Dec 04, 2018 at 11:49:27AM -0800, Florian Fainelli wrote:
>>>
>>> ...
>>>
>>>>>
>>>>> I was thinking also about pinned list of vlans to the address, but in
>>>>> this case this information also has to be synced by members of device
>>>>> chain,
>>>>> because it can be modified on any device level and it looks not very
>>>>> friendly,
>>>>> and at the end address space has addresses with pinned lists of vlans
>>>>> with
>>>>> their pointers. But keeping this stuff in sync is not simplest decision.
>>>>>
>>>>>
>>>>
>>>> I really think we are not communicating properly, it really seems to me
>>>> that if you had the information about the upper device trying to add an
>>>> address to the lower device filter's either through notification or call
>>>> to ndo_set_rxmode, you could be solving your problems. What are we
>>>> missing here?
>>>
>>> Sry, missed this one. The problem in getting  the owner of address.
>>> Just simple case: vlan/macvlan/real_dev or vlan/.../.../real_dev
>>>
>>> The real dev hasn't simple way to get vid the address belong to, or it has?
>>
>> Humm looks like your right, by the time the address lists are
>> synchronized (e.g: from = vlan_dev, to = real_dev), we lost that
>> information. It looks like I just managed to find such an use case
>> myself with VLAN filtering enabled on a bridge (so switch is VLAN aware)
>> and a VLAN device created on the bridge (br0.42) but with IGMP snooping
>> turned off (so we don't get HOST_MDB notifications with correct VLAN ID).
>>
>> Maybe keeping the "from" net_device within the address list that is
>> processed by ndo_set_rx_mode() will do the job though?
>>
>> Then you can do things like:
>>
>> if (is_vlan_dev(ha->dev) && ha->dev != dev)
>> 	vid = vlan_dev_vlan_id(ha->dev);
>>
>> and it should scale to any type of stacked device, regardless of VID or
>> something else that we need?
>>
>> Can you remind me of your use case again? Is it because your switch has
>> VLAN filtering enabled and you need to make sure that MC addresses on
>> VLAN device get programmed into the switch's multicast database with
>> correct VID?
>
>Ivan, can you see if the following would work for you:
>
>https://github.com/ffainelli/linux/commit/19e173ebdcdd32f5f5b5ef29049e35d33ad058f2
>
>this should be more scalable approach in that we can support HOST_MDB
>notifications from the bridge, the same way we would get notified about
>IGMP snooping from the bridge and this does not impact any other driver
>than those that elect to receive switchdev object notifications, which
>cpsw should really implement by now...

Sorry missed 2 last comments and seems like it's clear now.
I need to be in TO or CC list my filters can parse it, probably I need
to create more smart filters.

>-- 
>Florian

-- 
Regards,
Ivan Khoronzhuk