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] [day] [month] [year] [list]
Message-ID: <cba8bbb2-7068-c7c9-8ef4-1781a393eb45@egil-hjelmeland.no>
Date:   Wed, 18 Oct 2017 16:47:02 +0200
From:   Egil Hjelmeland <privat@...l-hjelmeland.no>
To:     Vivien Didelot <vivien.didelot@...oirfairelinux.com>,
        andrew@...n.ch, f.fainelli@...il.com, netdev@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH net-next 2/2] net: dsa: lan9303: Add fdb/mdb manipulation

On 18. okt. 2017 16:38, Vivien Didelot wrote:
> Hi Egil,
> 
> Egil Hjelmeland <privat@...l-hjelmeland.no> writes:
> 
>> +/* Delete static port from ALR entry, delete entry if last port */
>> +static int lan9303_alr_del_port(struct lan9303 *chip, const u8 *mac,
>> +				int port)
>> +{
>> +	struct lan9303_alr_cache_entry *entr;
>> +
>> +	entr = lan9303_alr_cache_find_mac(chip, mac);
>> +	if (!entr)
>> +		return 0;  /* no static entry found */
>> +		/* Question: Should we delete any learned entry?
>> +		 * { lan9303_alr_set_entry(chip, mac, 0, false); return 0; }
> 
> .port_fdb_del is meant to remove the association between a port and a
> MAC address in a given forwarding database. Deleting any learned entry
> is therefore out of scope of this function.
> 
> Please mark such patchset as RFC next time so that the maintainer knows
> that it is not meant to be applied.
> 
Thanks. And I will keep the RFC remark in mind.

>> +		 */
>> +
>> +	entr->port_map &= ~BIT(port);
>> +	if (entr->port_map == 0) /* zero means its free again */
>> +		eth_zero_addr(&entr->port_map);
>> +	lan9303_alr_set_entry(chip, mac, entr->port_map, entr->stp_override);
>> +	return 0;
>> +}
> 
> ...
> 
>> +static int lan9303_port_fdb_add(struct dsa_switch *ds, int port,
>> +				const unsigned char *addr, u16 vid)
>> +{
>> +	struct lan9303 *chip = ds->priv;
>> +
>> +	dev_dbg(chip->dev, "%s(%d, %pM, %d)\n", __func__, port, addr, vid);
>> +	if (vid)
>> +		return -EOPNOTSUPP;
>> +	return lan9303_alr_add_port(chip, addr, port, false);
>> +}
>> +
>> +static int lan9303_port_fdb_del(struct dsa_switch *ds, int port,
>> +				const unsigned char *addr, u16 vid)
>> +
>> +{
>> +	struct lan9303 *chip = ds->priv;
>> +
>> +	dev_dbg(chip->dev, "%s(%d, %pM, %d)\n", __func__, port, addr, vid);
>> +	if (vid)
>> +		return -EOPNOTSUPP;
>> +	lan9303_alr_del_port(chip, addr, port);
>> +	return 0;
>> +}
> 
> I don't remember, this chip has a single forwarding database for the
> whole switch, is that correct?
> 
Correct.

And the forwarding database (ALR) does not handle VLAN.
VLAN filtering is a separate step, with its own table.

> 
> Thanks,
> 
>          Vivien
> 

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ