netdev - Re: [PATCH net-next] team: account for oper state

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: <20180418191732.GB1922@nanopsycho>
Date:   Wed, 18 Apr 2018 21:17:32 +0200
From:   Jiri Pirko <jiri@...nulli.us>
To:     George Wilkie <gwilkie@...tta.att-mail.com>
Cc:     netdev@...r.kernel.org
Subject: Re: [PATCH net-next] team: account for oper state

Wed, Apr 18, 2018 at 05:33:12PM CEST, gwilkie@...tta.att-mail.com wrote:
>On Wed, Apr 18, 2018 at 04:58:22PM +0200, Jiri Pirko wrote:
>> Wed, Apr 18, 2018 at 03:35:49PM CEST, gwilkie@...tta.att-mail.com wrote:
>> >On Wed, Apr 18, 2018 at 02:56:44PM +0200, Jiri Pirko wrote:
>> >> Wed, Apr 18, 2018 at 12:29:50PM CEST, gwilkie@...tta.att-mail.com wrote:
>> >> >Account for operational state when determining port linkup state,
>> >> >as per Documentation/networking/operstates.txt.
>> >> 
>> >> Could you please point me to the exact place in the document where this
>> >> is suggested?
>> >> 
>> >
>> >Various places cover it I think.
>> >
>> >In 1. Introduction:
>> >"interface is not usable just because the admin enabled it"
>> >"userspace must be granted the possibility to
>> >influence operational state"
>> >
>> >In 4. Setting from userspace:
>> >"the userspace application can set IFLA_OPERSTATE
>> >to IF_OPER_DORMANT or IF_OPER_UP as long as the driver does not set
>> >netif_carrier_off() or netif_dormant_on()"
>> >
>> >We have a use case where we want to set the oper state of the team ports based
>> >on whether they are actually usable or not (as opposed to just admin up).
>> 
>> Are you running a supplicant there or what is the use-case?
>> 
>
>We are using tun/tap interfaces for the team ports with the physical interfaces
>under the control of a user process.
>
>> How is this handle in other drivers like bond, openvswitch, bridge, etc?
>
>It looks like bridge is using it, looking at br_port_carrier_check() and
>br_add_if().

Okay, so why do you still need to check netif_carrier_ok?
Looks like netif_oper_up is enough, right?


>
>Cheers.
>
>> 
>> >
>> >Cheers.
>> >
>> >> 
>> >> >
>> >> >Signed-off-by: George Wilkie <gwilkie@...tta.att-mail.com>
>> >> >---
>> >> > drivers/net/team/team.c | 3 ++-
>> >> > 1 file changed, 2 insertions(+), 1 deletion(-)
>> >> >
>> >> >diff --git a/drivers/net/team/team.c b/drivers/net/team/team.c
>> >> >index a6c6ce19eeee..231264a05e55 100644
>> >> >--- a/drivers/net/team/team.c
>> >> >+++ b/drivers/net/team/team.c
>> >> >@@ -2918,7 +2918,8 @@ static int team_device_event(struct notifier_block *unused,
>> >> > 	case NETDEV_CHANGE:
>> >> > 		if (netif_running(port->dev))
>> >> > 			team_port_change_check(port,
>> >> >-					       !!netif_carrier_ok(port->dev));
>> >> >+					       !!(netif_carrier_ok(port->dev) &&
>> >> >+						  netif_oper_up(port->dev)));
>> >> > 		break;
>> >> > 	case NETDEV_UNREGISTER:
>> >> > 		team_del_slave(port->team->dev, dev);
>> >> >-- 
>> >> >2.11.0
>> >> >