| 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
| ||
|
Message-ID: <0e661e6a-6057-4a16-bc41-b96cd18e8fe7@ti.com>
Date: Mon, 4 Nov 2024 16:50:47 +0530
From: MD Danish Anwar <danishanwar@...com>
To: Paolo Abeni <pabeni@...hat.com>, <geliang@...nel.org>,
<liuhangbin@...il.com>, <dan.carpenter@...aro.org>, <jiri@...nulli.us>,
<n.zhandarovich@...tech.ru>, <aleksander.lobakin@...el.com>,
<lukma@...x.de>, <horms@...nel.org>, <jan.kiszka@...mens.com>,
<diogo.ivo@...mens.com>, <shuah@...nel.org>, <kuba@...nel.org>,
<edumazet@...gle.com>, <davem@...emloft.net>, <andrew+netdev@...n.ch>
CC: <linux-kselftest@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
<netdev@...r.kernel.org>, <linux-arm-kernel@...ts.infradead.org>,
<srk@...com>, Vignesh Raghavendra <vigneshr@...com>,
Roger Quadros
<rogerq@...nel.org>, <m-malladi@...com>
Subject: Re: [PATCH net-next v2 2/4] net: hsr: Add VLAN CTAG filter support
Hi Paolo,
On 31/10/24 8:07 pm, Paolo Abeni wrote:
>
>
> On 10/24/24 12:30, MD Danish Anwar wrote:
>> From: Murali Karicheri <m-karicheri2@...com>
>>
>> This patch adds support for VLAN ctag based filtering at slave devices.
>> The slave ethernet device may be capable of filtering ethernet packets
>> based on VLAN ID. This requires that when the VLAN interface is created
>> over an HSR/PRP interface, it passes the VID information to the
>> associated slave ethernet devices so that it updates the hardware
>> filters to filter ethernet frames based on VID. This patch adds the
>> required functions to propagate the vid information to the slave
>> devices.
>>
>> Signed-off-by: Murali Karicheri <m-karicheri2@...com>
>> Signed-off-by: MD Danish Anwar <danishanwar@...com>
>> ---
>> net/hsr/hsr_device.c | 71 +++++++++++++++++++++++++++++++++++++++++++-
>> 1 file changed, 70 insertions(+), 1 deletion(-)
>>
>> diff --git a/net/hsr/hsr_device.c b/net/hsr/hsr_device.c
>> index 0ca47ebb01d3..ff586bdc2bde 100644
>> --- a/net/hsr/hsr_device.c
>> +++ b/net/hsr/hsr_device.c
>> @@ -515,6 +515,68 @@ static void hsr_change_rx_flags(struct net_device *dev, int change)
>> }
>> }
>>
>> +static int hsr_ndo_vlan_rx_add_vid(struct net_device *dev,
>> + __be16 proto, u16 vid)
>> +{
>> + struct hsr_port *port;
>> + struct hsr_priv *hsr;
>> + int ret = 0;
>> +
>> + hsr = netdev_priv(dev);
>> +
>> + hsr_for_each_port(hsr, port) {
>> + if (port->type == HSR_PT_MASTER)
>> + continue;
>
> If the desired behavior is to ignore INTERLINK port, I think you should
> explicitly skip them here, otherwise you will end-up in a
> nondeterministic state.
>
Sure, I will change this to
hsr_for_each_port(hsr, port) {
if (port->type == HSR_PT_MASTER ||
port->type = HSR_PT_INTERLINK)
continue;
>> + ret = vlan_vid_add(port->dev, proto, vid);
>> + switch (port->type) {
>> + case HSR_PT_SLAVE_A:
>> + if (ret) {
>> + netdev_err(dev, "add vid failed for Slave-A\n");
>> + return ret;
>> + }
>> + break;
>> +
>> + case HSR_PT_SLAVE_B:
>> + if (ret) {
>> + /* clean up Slave-A */
>> + netdev_err(dev, "add vid failed for Slave-B\n");
>> + vlan_vid_del(port->dev, proto, vid);
>
> This code relies on a specific port_list order - which is actually
> respected at list creation time. Still such assumption looks fragile and
> may lead to long term bugs.
>
Agreed. The code is expecting HSR_PT_SLAVE_A to come first and add vid
for it. Then vid is added for HSR_PT_SLAVE_B. if vlan_vid_add fails for
HSR_PT_SLAVE_B, vid is deleted for HSR_PT_SLAVE_A before returning.
> I think would be better to refactor the above loop handling arbitrary
> HSR_PT_SLAVE_A, HSR_PT_SLAVE_B order. Guestimate is that the complexity
> will not increase measurably.
>
I understand this will be better. But how would I figure out which port
came first.
The current implementation is to add vid for first port. If it fails it
returns. If it passes it adds vid for second port. If it fails it clears
vid of first port and returns. If it passes function returns 0.
Now how do I keep this behavior and also handle ports arbitrary. If the
same order is not guaranteed to be preserved, how would I know which
port came first so that it can be deleted if second port fails?
One idea I have is to keep two boolean flags is_slave_a_added,
is_slave_b_added. And based on these flags we can determine if cleanup
is needed or not.
The add function will then look like this,
static int hsr_ndo_vlan_rx_add_vid(struct net_device *dev,
__be16 proto, u16 vid)
{
bool is_slave_a_added, is_slave_b_added;
struct hsr_port *port;
struct hsr_priv *hsr;
int ret = 0;
hsr = netdev_priv(dev);
hsr_for_each_port(hsr, port) {
if (port->type == HSR_PT_MASTER ||
port->type = HSR_PT_INTERLINK)
continue;
ret = vlan_vid_add(port->dev, proto, vid);
switch (port->type) {
case HSR_PT_SLAVE_A:
if (ret) {
/* clean up Slave-B */
netdev_err(dev, "add vid failed for Slave-A\n");
if (is_slave_b_added)
vlan_vid_del(port->dev, proto, vid);
return ret;
} else {
is_slave_a_added = true;
}
break;
case HSR_PT_SLAVE_B:
if (ret) {
/* clean up Slave-A */
netdev_err(dev, "add vid failed for Slave-B\n");
if (is_slave_a_added)
vlan_vid_del(port->dev, proto, vid);
return ret;
} else {
is_slave_b_added = true;
}
break;
default:
break;
}
}
return 0;
}
Let me know if this is OK. Or if you have some other method to handle
the ports arbitrary.
>> + return ret;
>> + }
>> + break;
>> + default:
>> + break;
>> + }
>> + }
>> +
>> + return 0;
>> +}
>> +
>> +static int hsr_ndo_vlan_rx_kill_vid(struct net_device *dev,
>> + __be16 proto, u16 vid)
>> +{
>> + struct hsr_port *port;
>> + struct hsr_priv *hsr;
>> +
>> + hsr = netdev_priv(dev);
>> +
>> + hsr_for_each_port(hsr, port) {
>> + if (port->type == HSR_PT_MASTER)
>> + continue;
>
> I think it would be more consistent just removing the above statement...
>
Sure. I'll do it.
>> + switch (port->type) {
>> + case HSR_PT_SLAVE_A:
>> + case HSR_PT_SLAVE_B:
>> + vlan_vid_del(port->dev, proto, vid);
>> + break;
>> + default:> + break;
>
> ... MASTER and INTERLINK port will be ignored anyway.
>
Sure.
>> + }
>> + }
>> +
>> + return 0;
>> +}
>> +
>> static const struct net_device_ops hsr_device_ops = {
>> .ndo_change_mtu = hsr_dev_change_mtu,
>> .ndo_open = hsr_dev_open,
>
> Cheers,
>
> Paolo
>
--
Thanks and Regards,
Danish
Powered by blists - more mailing lists