search for: iff_up

...n 3/5/2019 11:24 AM, Stephen Hemminger wrote: > > > > On Tue, 5 Mar 2019 11:19:32 -0800 > > > > si-wei liu <si-wei.liu at oracle.com> wrote: > > > > > > > > > > I have a vague idea: would it work to *not* set > > > > > > IFF_UP on slave devices at all? > > > > > Hmm, I ever thought about this option, and it appears this solution is > > > > > more invasive than required to convert existing scripts, despite the > > > > > controversy of introducing internal netdev state to differe...

...> > > > > On Tue, 5 Mar 2019 11:19:32 -0800 > > > > > > si-wei liu <si-wei.liu at oracle.com> wrote: > > > > > > > > > > > > > > I have a vague idea: would it work to *not* set > > > > > > > > IFF_UP on slave devices at all? > > > > > > > Hmm, I ever thought about this option, and it appears this solution is > > > > > > > more invasive than required to convert existing scripts, despite the > > > > > > > controversy of introducing in...

...5:50AM -0800, si-wei liu wrote: > > > On 3/5/2019 11:24 AM, Stephen Hemminger wrote: > > On Tue, 5 Mar 2019 11:19:32 -0800 > > si-wei liu <si-wei.liu at oracle.com> wrote: > > > > > > I have a vague idea: would it work to *not* set > > > > IFF_UP on slave devices at all? > > > Hmm, I ever thought about this option, and it appears this solution is > > > more invasive than required to convert existing scripts, despite the > > > controversy of introducing internal netdev state to differentiate user > > > vis...

...2019 11:19:32 -0800 > > > > > > > > si-wei liu <si-wei.liu at oracle.com> wrote: > > > > > > > > > > > > > > > > > > I have a vague idea: would it work to *not* set > > > > > > > > > > IFF_UP on slave devices at all? > > > > > > > > > Hmm, I ever thought about this option, and it appears this solution is > > > > > > > > > more invasive than required to convert existing scripts, despite the > > > > > > > > >...

On Tue, 5 Mar 2019 11:19:32 -0800 si-wei liu <si-wei.liu at oracle.com> wrote: > > I have a vague idea: would it work to *not* set > > IFF_UP on slave devices at all? > Hmm, I ever thought about this option, and it appears this solution is > more invasive than required to convert existing scripts, despite the > controversy of introducing internal netdev state to differentiate user > visible state. Either we disallow slav...

On Wed, 3 Apr 2019 00:52:47 -0400 Si-Wei Liu <si-wei.liu at oracle.com> wrote: > > + if (unlikely(dev->flags & IFF_UP)) { > + struct netdev_notifier_change_info change_info = { > + .info.dev = dev, > + }; > + > + call_netdevice_notifiers_info(NETDEV_CHANGE, > + &change_info.info); > + } This notifier is not really necessary, there already is a CHANGENAME that gets sent. NE...

On Wed, 3 Apr 2019 00:52:47 -0400 Si-Wei Liu <si-wei.liu at oracle.com> wrote: > > + if (unlikely(dev->flags & IFF_UP)) { > + struct netdev_notifier_change_info change_info = { > + .info.dev = dev, > + }; > + > + call_netdevice_notifiers_info(NETDEV_CHANGE, > + &change_info.info); > + } This notifier is not really necessary, there already is a CHANGENAME that gets sent. NE...

...reliable names that may carry > other information describing the netdev. For e.g., they can infer that > "ens3nsby" is a standby slave of "ens3", while for a > name like "eth0" they can't tell which master it belongs to. > > Historically the name of IFF_UP interface can't be changed because > there might be admin script or management software that is already > relying on such behavior and assumes that the slave name can't be > changed once UP. But failover is special: with the in-kernel > auto-enslavement mechanism, the userspace...

...reliable names that may carry > other information describing the netdev. For e.g., they can infer that > "ens3nsby" is a standby slave of "ens3", while for a > name like "eth0" they can't tell which master it belongs to. > > Historically the name of IFF_UP interface can't be changed because > there might be admin script or management software that is already > relying on such behavior and assumes that the slave name can't be > changed once UP. But failover is special: with the in-kernel > auto-enslavement mechanism, the userspace...

...reliable names that may carry > other information describing the netdev. For e.g., they can infer that > "ens3nsby" is a standby slave of "ens3", while for a > name like "eth0" they can't tell which master it belongs to. > > Historically the name of IFF_UP interface can't be changed because > there might be admin script or management software that is already > relying on such behavior and assumes that the slave name can't be > changed once UP. But failover is special: with the in-kernel > auto-enslavement mechanism, the userspace...

On Thu, 28 Mar 2019 19:47:27 -0400 Si-Wei Liu <si-wei.liu at oracle.com> wrote: > + if (unlikely(dev->flags & IFF_UP)) { > + struct netdev_notifier_change_info change_info; > + > + change_info.flags_changed = 0; Simpler to use structure initialization, which also avoid any chance of unititialized fields. struct netdev_notifier_change_info change_info = { .flags_changed = 0 };

...information describing the netdev. For e.g., they can infer that > > > "ens3nsby" is a standby slave of "ens3", while for a > > > name like "eth0" they can't tell which master it belongs to. > > > > > > Historically the name of IFF_UP interface can't be changed because > > > there might be admin script or management software that is already > > > relying on such behavior and assumes that the slave name can't be > > > changed once UP. But failover is special: with the in-kernel > > > au...

Hi Si-Wei, Thank you for the patch! Yet something to improve: [auto build test ERROR on net/master] url: https://github.com/0day-ci/linux/commits/Si-Wei-Liu/failover-allow-name-change-on-IFF_UP-slave-interfaces/20190329-195445 config: x86_64-lkp (attached as .config) compiler: gcc-7 (Debian 7.3.0-1) 7.3.0 reproduce: # save the attached .config to linux build tree make ARCH=x86_64 All errors (new ones prefixed by >>): net/core/dev.c: In function 'dev_change_...

On Tue, 2 Apr 2019 15:23:29 -0700 si-wei liu <si-wei.liu at oracle.com> wrote: > On 4/2/2019 2:53 PM, Stephen Hemminger wrote: > > On Mon, 1 Apr 2019 19:04:53 -0400 > > Si-Wei Liu <si-wei.liu at oracle.com> wrote: > > > >> + if (dev->flags & IFF_UP && > >> + likely(!(dev->priv_flags & IFF_FAILOVER_SLAVE))) > > Why is property limited to failover slave, it would make sense for netvsc > > as well. Why not make it a flag like live address change? > Well, netvsc today is still taking the delayed appr...

On Tue, 2 Apr 2019 15:23:29 -0700 si-wei liu <si-wei.liu at oracle.com> wrote: > On 4/2/2019 2:53 PM, Stephen Hemminger wrote: > > On Mon, 1 Apr 2019 19:04:53 -0400 > > Si-Wei Liu <si-wei.liu at oracle.com> wrote: > > > >> + if (dev->flags & IFF_UP && > >> + likely(!(dev->priv_flags & IFF_FAILOVER_SLAVE))) > > Why is property limited to failover slave, it would make sense for netvsc > > as well. Why not make it a flag like live address change? > Well, netvsc today is still taking the delayed appr...

...information describing the netdev. For e.g., they can infer that > > > "ens3nsby" is a standby slave of "ens3", while for a > > > name like "eth0" they can't tell which master it belongs to. > > > > > > Historically the name of IFF_UP interface can't be changed because > > > there might be admin script or management software that is already > > > relying on such behavior and assumes that the slave name can't be > > > changed once UP. But failover is special: with the in-kernel > > > au...

...reliable names that may carry > other information describing the netdev. For e.g., they can infer that > "ens3nsby" is a standby slave of "ens3", while for a > name like "eth0" they can't tell which master it belongs to. > > Historically the name of IFF_UP interface can't be changed because > there might be admin script or management software that is already > relying on such behavior and assumes that the slave name can't be > changed once UP. But failover is special: with the in-kernel > auto-enslavement mechanism, the userspace...

...other information describing the netdev. For e.g., they can infer that > >> "ens3nsby" is a standby slave of "ens3", while for a > >> name like "eth0" they can't tell which master it belongs to. > >> > >> Historically the name of IFF_UP interface can't be changed because > >> there might be admin script or management software that is already > >> relying on such behavior and assumes that the slave name can't be > >> changed once UP. But failover is special: with the in-kernel > >> auto-e...

...see reliable names that may carry >other information describing the netdev. For e.g., they can infer that >"ens3nsby" is a standby slave of "ens3", while for a >name like "eth0" they can't tell which master it belongs to. > >Historically the name of IFF_UP interface can't be changed because >there might be admin script or management software that is already >relying on such behavior and assumes that the slave name can't be >changed once UP. But failover is special: with the in-kernel >auto-enslavement mechanism, the userspace expe...

...reliable names that may carry > other information describing the netdev. For e.g., they can infer that > "ens3nsby" is a standby slave of "ens3", while for a > name like "eth0" they can't tell which master it belongs to. > > Historically the name of IFF_UP interface can't be changed because > there might be admin script or management software that is already > relying on such behavior and assumes that the slave name can't be > changed once UP. But failover is special: with the in-kernel > auto-enslavement mechanism, the userspace...