| 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: <CACcJQnT0+g9Wy=3tvjOd9p4ou6JTU-SFVaOkk-qO-AJ7YGd+pA@mail.gmail.com>
Date: Wed, 29 Apr 2015 15:11:42 -0700
From: Anuradha Karuppiah <anuradhak@...ulusnetworks.com>
To: Scott Feldman <sfeldma@...il.com>
Cc: "David S. Miller" <davem@...emloft.net>,
Netdev <netdev@...r.kernel.org>,
Roopa Prabhu <roopa@...ulusnetworks.com>,
Andy Gospodarek <gospo@...ulusnetworks.com>,
Wilson Kok <wkok@...ulusnetworks.com>
Subject: Re: [RFC PATCH net-next v3 3/4] rocker: Handle IFF_PROTODOWN by doing
a PHYS-DOWN on the switch port.
On Tue, Apr 28, 2015 at 10:51 PM, Scott Feldman <sfeldma@...il.com> wrote:
> On Tue, Apr 28, 2015 at 1:35 PM, Anuradha Karuppiah
> <anuradhak@...ulusnetworks.com> wrote:
>> On Tue, Apr 28, 2015 at 12:48 PM, Scott Feldman <sfeldma@...il.com> wrote:
>>> On Tue, Apr 28, 2015 at 8:49 AM, Anuradha Karuppiah
>>> <anuradhak@...ulusnetworks.com> wrote:
>>>> On Mon, Apr 27, 2015 at 10:51 PM, Scott Feldman <sfeldma@...il.com> wrote:
>>>>> On Mon, Apr 27, 2015 at 10:38 AM, <anuradhak@...ulusnetworks.com> wrote:
>>>>>> From: Anuradha Karuppiah <anuradhak@...ulusnetworks.com>
>>>>>>
>>>>>> IFF_PROTODOWN can be set by user space applications like MLAG on detecting
>>>>>> errors on a switch port. This patch provides sample switch driver changes
>>>>>> for handling IFF_PROTODOWN. Rocker PHYS disables the port in response to
>>>>>> protodown.
>>>>>>
>>>>>> Note: I understand Scott has some rocker changes on hold. I will re-spin
>>>>>> this patch once his changes are in.
>>>>>>
>>>>>> Signed-off-by: Anuradha Karuppiah <anuradhak@...ulusnetworks.com>
>>>>>> Signed-off-by: Andy Gospodarek <gospo@...ulusnetworks.com>
>>>>>> Signed-off-by: Roopa Prabhu <roopa@...ulusnetworks.com>
>>>>>> Signed-off-by: Wilson Kok <wkok@...ulusnetworks.com>
>>>>>> ---
>>>>>> drivers/net/ethernet/rocker/rocker.c | 16 +++++++++++++++-
>>>>>> 1 file changed, 15 insertions(+), 1 deletion(-)
>>>>>>
>>>>>> diff --git a/drivers/net/ethernet/rocker/rocker.c b/drivers/net/ethernet/rocker/rocker.c
>>>>>> index a87b177..e3084e3 100644
>>>>>> --- a/drivers/net/ethernet/rocker/rocker.c
>>>>>> +++ b/drivers/net/ethernet/rocker/rocker.c
>>>>>> @@ -3838,7 +3838,8 @@ static int rocker_port_open(struct net_device *dev)
>>>>>>
>>>>>> napi_enable(&rocker_port->napi_tx);
>>>>>> napi_enable(&rocker_port->napi_rx);
>>>>>> - rocker_port_set_enable(rocker_port, true);
>>>>>> + if (!(dev->flags & IFF_PROTO_DOWN))
>>>>>> + rocker_port_set_enable(rocker_port, true);
>>>>>> netif_start_queue(dev);
>>>>>> return 0;
>>>>>>
>>>>>> @@ -4238,6 +4239,18 @@ static int rocker_port_swdev_port_stp_update(struct net_device *dev, u8 state)
>>>>>> return rocker_port_stp_update(rocker_port, state);
>>>>>> }
>>>>>>
>>>>>> +static int rocker_port_swdev_port_phy_state_set(struct net_device *dev,
>>>>>> + bool enable)
>>>>>> +{
>>>>>> + struct rocker_port *rocker_port = netdev_priv(dev);
>>>>>> +
>>>>>> + if (enable && (dev->flags & IFF_UP) && !(dev->flags & IFF_PROTO_DOWN))
>>>>>> + rocker_port_set_enable(rocker_port, true);
>>>>>> + else
>>>>>> + rocker_port_set_enable(rocker_port, false);
>>>>>
>>>>> This isn't working like your expecting. PHY link is still up on the
>>>>> rocker port, so the other end of the wire still sees link UP even when
>>>>> IFF_PROTO_DOWN is set locally.
>>>>
>>>> I wanted to check with you first on the rocker handling; that is the main
>>>> reason for posting this an RFC (thanks for the review).
>>>>
>>>> I used rocker_port_set_enable/PORT_PHYS_ENABLE for setting the phy state
>>>> because I assumed that in the case of an offloaded switch driver it would be
>>>> the equivalent of doing "sdk port N en=1|0". Is that not the case? If not,
>>>> could you please point me in the right direction?
>>>
>>> To put PHY link down, on PORT_PHYS_ENABLE true, rocker device (qemu)
>>> would need to down the link state for the port so other end of wire
>>> sees link down. I think I remember looking into that but didn't
>>> implement it. In qemu monitor, you can manually set the link up/down
>>> (set_link <dev> [on|off]). We'd need to call the same from within the
>>> rocker device.
>>>
>>> So if we want to be able to test this with rocker, we'll need a device
>>> and driver change.
>>
>> Thanks for the details, Scott. We will looking into implementing the necessary
>> changes to get it working with rocker.
>
> Hmmm....looks like we can only go so far using rocker. The patch
> below for rocker device will set link up/down when phy is
> enabled/disabled, but that only affects the local link status. The
> remote will not see link down/up when the local changes because there
> is no physical signalling between two VM instances (local and remote)
> (duh!). I'll add the device patch to my queue just because it's a
> good things to have, but at this point I'm not seeing how you can use
> rocker to down the remote link.
>
> diff --git a/hw/net/rocker/rocker_fp.c b/hw/net/rocker/rocker_fp.c
> index 42354c3..d8d934c 100644
> --- a/hw/net/rocker/rocker_fp.c
> +++ b/hw/net/rocker/rocker_fp.c
> @@ -188,8 +188,19 @@ bool fp_port_enabled(FpPort *port)
> return port->enabled;
> }
>
> +static void fp_port_set_link(FpPort *port, bool up)
> +{
> + NetClientState *nc = qemu_get_queue(port->nic);
> +
> + if (up == nc->link_down) {
> + nc->link_down = !up;
> + nc->info->link_status_changed(nc);
> + }
> +}
> +
> void fp_port_enable(FpPort *port)
> {
> + fp_port_set_link(port, true);
> port->enabled = true;
> DPRINTF("port %d enabled\n", port->index);
> }
> @@ -197,6 +208,7 @@ void fp_port_enable(FpPort *port)
> void fp_port_disable(FpPort *port)
> {
> port->enabled = false;
> + fp_port_set_link(port, false);
> DPRINTF("port %d disabled\n", port->index);
> }
OK, thanks for the info and for including the changes needed to do the local
phy-to-link setting in rocker.
For the proto_down handling -
1. The local switch port state does need to be down to prevent loops and to
prevent protocols from converging.
2. Remote needs to be signalled (if possible) via a carrier down to stop
sending traffic to this down port. In the case of virtual/emulated switch
ports this is not going to be possible.
I wonder if it still make sense to provide sample usage of this attribute in
rocker along with the documentation that #2 is not possible because of the
emulation restrictions. And that it would be possible in an offloaded switch
driver that did have phy control via the corresponding SDK.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists