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]
Date:   Fri, 27 Oct 2017 09:44:58 -0400
From:   Vivien Didelot <vivien.didelot@...oirfairelinux.com>
To:     Egil Hjelmeland <privat@...l-hjelmeland.no>,
        netdev <netdev@...r.kernel.org>, Andrew Lunn <andrew@...n.ch>,
        Florian Fainelli <f.fainelli@...il.com>,
        David Miller <davem@...emloft.net>
Cc:     "linux-kernel\@vger.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH net-next 0/9] net: dsa: define port types

Hi Egil,

Egil Hjelmeland <privat@...l-hjelmeland.no> writes:

>  > The DSA code currently has 3 bitmaps in the dsa_switch structure:
>  > cpu_port_mask, dsa_port_mask and enabled_port_mask.
>
>
> First I must apologize to everybody for not replying in-thread. Problem
> is that I was not subscribed to netdev. But now I am, so I promise it
> will not happen again :-)
>
> So to the point. I think DSA need to keep track of multicast
> memberships. As it is now, dsa_switch_mdb_add() include
> the CPU/DSA port(s) in the multicast. But  multicast is never
> removed from the CPU/DSA port(s).

We don't have support for this yet, but we do need to be able to remove
multicast from CPU port, if your linux processing is not interested
about a given slave multicast traffic.

> One option could be that DSA remember mulitcast memberships as bitmaps
> of ports. Then it could be handy to have the CPU and DSA ports as
> bitmaps too.
>
> It might not fall out that way in the end. But anyway, my suggestion is:
> Do patch 1 - 6, which isolates the drivers from the internal structure
> of dsa. But hold on to 7 - 9 until there is a plan for better multicast
> handling in DSA.

No. There is no need to have such bitmaps in dsa_switch. The port type
is a static information which belongs in dsa_port as an enum. For
multicast we'll see what is more handy, but caching can make things more
complex. Until then if we do need bitmaps, we'll provide helpers such as
dsa_user_ports. In a next iteration we'll provide better helpers taking
an unsigned long * as parameter so that we use the bitmap API and
finally get rid of the fixed length data type.


Thanks,

        Vivien

Powered by blists - more mailing lists