search for: slave_rename_ok

...ause of auto-enslavement and duplicate MAC address. Similarly, >in case that users care about seeing reliable slave name, the new type >of failover slaves needs to be taken care of specifically in userspace >anyway. > >For that to work, now introduce a module-level tunable, >"slave_rename_ok" that allows users to lift up the rename restriction on >failover slave which is already UP. Although it's possible this change >potentially break userspace component (most likely configuration scripts >or management software) that assumes slave name can't be changed while &gt...

...f auto-enslavement and duplicate MAC address. Similarly, > in case that users care about seeing reliable slave name, the new type > of failover slaves needs to be taken care of specifically in userspace > anyway. > > For that to work, now introduce a module-level tunable, > "slave_rename_ok" that allows users to lift up the rename restriction on > failover slave which is already UP. Although it's possible this change > potentially break userspace component (most likely configuration scripts > or management software) that assumes slave name can't be changed while...

...; > > in case that users care about seeing reliable slave name, the new type > > > of failover slaves needs to be taken care of specifically in userspace > > > anyway. > > > > > > For that to work, now introduce a module-level tunable, > > > "slave_rename_ok" that allows users to lift up the rename restriction on > > > failover slave which is already UP. Although it's possible this change > > > potentially break userspace component (most likely configuration scripts > > > or management software) that assumes slave na...

...gt; > > On 3/6/2019 4:04 AM, Jiri Pirko wrote: >>> --- a/net/core/failover.c >>> +++ b/net/core/failover.c >>> @@ -16,6 +16,11 @@ >>> >>> static LIST_HEAD(failover_list); >>> static DEFINE_SPINLOCK(failover_lock); >>> +static bool slave_rename_ok = true; >>> + >>> +module_param(slave_rename_ok, bool, (S_IRUGO | S_IWUSR)); >>> +MODULE_PARM_DESC(slave_rename_ok, >>> + "If set allow renaming the slave when failover master is up"); >> No module parameters please. If you need to set something...

...>>>> --- a/net/core/failover.c >>>>> +++ b/net/core/failover.c >>>>> @@ -16,6 +16,11 @@ >>>>> >>>>> static LIST_HEAD(failover_list); >>>>> static DEFINE_SPINLOCK(failover_lock); >>>>> +static bool slave_rename_ok = true; >>>>> + >>>>> +module_param(slave_rename_ok, bool, (S_IRUGO | S_IWUSR)); >>>>> +MODULE_PARM_DESC(slave_rename_ok, >>>>> + "If set allow renaming the slave when failover master is up"); >>>>> >>>...

.../linux/netdevice.h > @@ -1487,6 +1487,7 @@ struct net_device_ops { > * @IFF_NO_RX_HANDLER: device doesn't support the rx_handler hook > * @IFF_FAILOVER: device is a failover master device > * @IFF_FAILOVER_SLAVE: device is lower dev of a failover master device > + * @IFF_SLAVE_RENAME_OK: rename is allowed while slave device is running > */ > enum netdev_priv_flags { > IFF_802_1Q_VLAN = 1<<0, > @@ -1518,6 +1519,7 @@ enum netdev_priv_flags { > IFF_NO_RX_HANDLER = 1<<26, > IFF_FAILOVER = 1<<27, > IFF_FAILOVER_SLAVE = 1<...

On 3/19/2019 10:20 PM, si-wei liu wrote: > Hi Sridhar, > > Are you fine with leaving the IFF_SLAVE_RENAME_OK flag as is, and thus > can provide your Ack-by or Reviewed-by? I can change the code if you > feel strong. My preference would be not to introduce a new flag unless there is any usecase where we want a IFF_FAILOVER_SLAVE type of device to support 2 different behaviors. (rename_ok and ren...