Re: [PATCH net v5] failover: allow name change on IFF_UP slave interfaces
On 4/2/2019 8:14 PM, Stephen Hemminger wrote: On Tue, 2 Apr 2019 15:23:29 -0700 si-wei liu wrote: On 4/2/2019 2:53 PM, Stephen Hemminger wrote: On Mon, 1 Apr 2019 19:04:53 -0400 Si-Wei Liu 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 approach meaning that it is incompatible yet with this live name change flag if need be. ;-) I thought Sridhar did not like to introduce an additional IFF_SLAVE_RENAME_OK flag given that failover slave is the only consumer for the time being. Even though I can get it back, patch is needed for netvsc to remove the VF takeover delay IMHO. Sridhar, what do you think we revive the IFF_SLAVE_RENAME_OK flag which allows netvsc to be used later on? Or maybe, IFF_LIVE_RENAME_OK for a better name? -Siwei I would name it IFF_LIVE_NAME_CHANGE to match IFF_LIVE_ADDR_CHANGE there is no reason its use should be restricted to SLAVE devices. Stephen, May be you should consider moving netvsc to use the net_failover driver now? ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH net v5] failover: allow name change on IFF_UP slave interfaces
On Tue, 2 Apr 2019 15:23:29 -0700 si-wei liu wrote: > On 4/2/2019 2:53 PM, Stephen Hemminger wrote: > > On Mon, 1 Apr 2019 19:04:53 -0400 > > Si-Wei Liu 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 approach meaning that it > is incompatible yet with this live name change flag if need be. ;-) > > I thought Sridhar did not like to introduce an additional > IFF_SLAVE_RENAME_OK flag given that failover slave is the only consumer > for the time being. Even though I can get it back, patch is needed for > netvsc to remove the VF takeover delay IMHO. > > Sridhar, what do you think we revive the IFF_SLAVE_RENAME_OK flag which > allows netvsc to be used later on? Or maybe, IFF_LIVE_RENAME_OK for a > better name? > > -Siwei I would name it IFF_LIVE_NAME_CHANGE to match IFF_LIVE_ADDR_CHANGE there is no reason its use should be restricted to SLAVE devices. ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH net v5] failover: allow name change on IFF_UP slave interfaces
On Mon, 1 Apr 2019 19:04:53 -0400 Si-Wei Liu 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? ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH net v5] failover: allow name change on IFF_UP slave interfaces
On Mon, Apr 01, 2019 at 07:04:53PM -0400, Si-Wei Liu wrote:
> When a netdev appears through hot plug then gets enslaved by a failover
> master that is already up and running, the slave will be opened
> right away after getting enslaved. Today there's a race that userspace
> (udev) may fail to rename the slave if the kernel (net_failover)
> opens the slave earlier than when the userspace rename happens.
> Unlike bond or team, the primary slave of failover can't be renamed by
> userspace ahead of time, since the kernel initiated auto-enslavement is
> unable to, or rather, is never meant to be synchronized with the rename
> request from userspace.
>
> As the failover slave interfaces are not designed to be operated
> directly by userspace apps: IP configuration, filter rules with
> regard to network traffic passing and etc., should all be done on master
> interface. In general, userspace apps only care about the
> name of master interface, while slave names are less important as long
> as admin users can 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 expectation for device
> enumeration and bring-up order is already broken. Previously initramfs
> and various userspace config tools were modified to bypass failover
> slaves because 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.
>
> It's less risky to lift up the rename restriction on failover slave
> which is already UP. Although it's possible this change may potentially
> break userspace component (most likely configuration scripts or
> management software) that assumes slave name can't be changed while
> UP, it's relatively a limited and controllable set among all userspace
> components, which can be fixed specifically to listen for the rename
> and/or link down/up events on failover slaves. Userspace component
> interacting with slaves is expected to be changed to operate on failover
> master interface instead, as the failover slave is dynamic in nature
> which may come and go at any point. The goal is to make the role of
> failover slaves less relevant, and userspace components should only
> deal with failover master in the long run.
>
> Fixes: 30c8bd5aa8b2 ("net: Introduce generic failover module")
> Signed-off-by: Si-Wei Liu
> Reviewed-by: Liran Alon
>
> --
> v1 -> v2:
> - Drop configurable module parameter (Sridhar)
>
> v2 -> v3:
> - Drop additional IFF_SLAVE_RENAME_OK flag (Sridhar)
> - Send down and up events around rename (Michael S. Tsirkin)
>
> v3 -> v4:
> - Simplify notification to be sent (Stephen Hemminger)
>
> v4 -> v5:
> - Sync up code with latest net-next (Sridhar)
> - Use proper structure initialization (Stephen, Jiri)
> ---
Acked-by: Michael S. Tsirkin
> net/core/dev.c | 25 -
> 1 file changed, 24 insertions(+), 1 deletion(-)
>
> diff --git a/net/core/dev.c b/net/core/dev.c
> index 9823b77..b694184 100644
> --- a/net/core/dev.c
> +++ b/net/core/dev.c
> @@ -1185,7 +1185,21 @@ int dev_change_name(struct net_device *dev, const char
> *newname)
> BUG_ON(!dev_net(dev));
>
> net = dev_net(dev);
> - if (dev->flags & IFF_UP)
> +
> + /* Allow failover slave to rename even when
> + * it is up and running.
> + *
> + * Failover slaves are special, since userspace
> + * might rename the slave after the interface
> + * has been brought up and running due to
> + * auto-enslavement.
> + *
> + * Failover users don't actually care about slave
> + * name change, as they are only expected to operate
> + * on master interface directly.
> + */
> + if (dev->flags & IFF_UP &&
> + likely(!(dev->priv_flags & IFF_FAILOVER_SLAVE)))
> return -EBUSY;
>
> write_seqcount_begin(_rename_seq);
> @@ -1232,6 +1246,15 @@ int dev_change_name(struct net_device *dev, const char
> *newname)
> hlist_add_head_rcu(>name_hlist, dev_name_hash(net, dev->name));
> write_unlock_bh(_base_lock);
>
> + if (unlikely(dev->flags & IFF_UP)) {
> + struct netdev_notifier_change_info change_info = {
> + .info.dev = dev,
> + };
> +
> + call_netdevice_notifiers_info(NETDEV_CHANGE,
> + _info.info);
> + }
> +
> ret = call_netdevice_notifiers(NETDEV_CHANGENAME, dev);
> ret =
Re: [PATCH net v5] failover: allow name change on IFF_UP slave interfaces
On 4/1/2019 4:04 PM, Si-Wei Liu wrote:
When a netdev appears through hot plug then gets enslaved by a failover
master that is already up and running, the slave will be opened
right away after getting enslaved. Today there's a race that userspace
(udev) may fail to rename the slave if the kernel (net_failover)
opens the slave earlier than when the userspace rename happens.
Unlike bond or team, the primary slave of failover can't be renamed by
userspace ahead of time, since the kernel initiated auto-enslavement is
unable to, or rather, is never meant to be synchronized with the rename
request from userspace.
As the failover slave interfaces are not designed to be operated
directly by userspace apps: IP configuration, filter rules with
regard to network traffic passing and etc., should all be done on master
interface. In general, userspace apps only care about the
name of master interface, while slave names are less important as long
as admin users can 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 expectation for device
enumeration and bring-up order is already broken. Previously initramfs
and various userspace config tools were modified to bypass failover
slaves because 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.
It's less risky to lift up the rename restriction on failover slave
which is already UP. Although it's possible this change may potentially
break userspace component (most likely configuration scripts or
management software) that assumes slave name can't be changed while
UP, it's relatively a limited and controllable set among all userspace
components, which can be fixed specifically to listen for the rename
and/or link down/up events on failover slaves. Userspace component
interacting with slaves is expected to be changed to operate on failover
master interface instead, as the failover slave is dynamic in nature
which may come and go at any point. The goal is to make the role of
failover slaves less relevant, and userspace components should only
deal with failover master in the long run.
Fixes: 30c8bd5aa8b2 ("net: Introduce generic failover module")
Signed-off-by: Si-Wei Liu
Reviewed-by: Liran Alon
Acked-by: Sridhar Samudrala
--
v1 -> v2:
- Drop configurable module parameter (Sridhar)
v2 -> v3:
- Drop additional IFF_SLAVE_RENAME_OK flag (Sridhar)
- Send down and up events around rename (Michael S. Tsirkin)
v3 -> v4:
- Simplify notification to be sent (Stephen Hemminger)
v4 -> v5:
- Sync up code with latest net-next (Sridhar)
- Use proper structure initialization (Stephen, Jiri)
---
net/core/dev.c | 25 -
1 file changed, 24 insertions(+), 1 deletion(-)
diff --git a/net/core/dev.c b/net/core/dev.c
index 9823b77..b694184 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -1185,7 +1185,21 @@ int dev_change_name(struct net_device *dev, const char
*newname)
BUG_ON(!dev_net(dev));
net = dev_net(dev);
- if (dev->flags & IFF_UP)
+
+ /* Allow failover slave to rename even when
+* it is up and running.
+*
+* Failover slaves are special, since userspace
+* might rename the slave after the interface
+* has been brought up and running due to
+* auto-enslavement.
+*
+* Failover users don't actually care about slave
+* name change, as they are only expected to operate
+* on master interface directly.
+*/
+ if (dev->flags & IFF_UP &&
+ likely(!(dev->priv_flags & IFF_FAILOVER_SLAVE)))
return -EBUSY;
write_seqcount_begin(_rename_seq);
@@ -1232,6 +1246,15 @@ int dev_change_name(struct net_device *dev, const char
*newname)
hlist_add_head_rcu(>name_hlist, dev_name_hash(net, dev->name));
write_unlock_bh(_base_lock);
+ if (unlikely(dev->flags & IFF_UP)) {
+ struct netdev_notifier_change_info change_info = {
+ .info.dev = dev,
+ };
+
+ call_netdevice_notifiers_info(NETDEV_CHANGE,
+ _info.info);
+ }
+
ret = call_netdevice_notifiers(NETDEV_CHANGENAME, dev);
ret = notifier_to_errno(ret);
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
[PATCH 2/2] drm/cirrus: drop mode_info.mode_config_initialized
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/cirrus/cirrus_drv.h | 1 -
drivers/gpu/drm/cirrus/cirrus_mode.c | 9 ++---
2 files changed, 2 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/cirrus/cirrus_drv.h
b/drivers/gpu/drm/cirrus/cirrus_drv.h
index 915709739257..828b150cdb20 100644
--- a/drivers/gpu/drm/cirrus/cirrus_drv.h
+++ b/drivers/gpu/drm/cirrus/cirrus_drv.h
@@ -101,7 +101,6 @@ struct cirrus_crtc {
struct cirrus_fbdev;
struct cirrus_mode_info {
- boolmode_config_initialized;
struct cirrus_crtc *crtc;
/* pointer to fbdev info structure */
struct cirrus_fbdev *gfbdev;
diff --git a/drivers/gpu/drm/cirrus/cirrus_mode.c
b/drivers/gpu/drm/cirrus/cirrus_mode.c
index 32ce2c1040b4..b109cd71426f 100644
--- a/drivers/gpu/drm/cirrus/cirrus_mode.c
+++ b/drivers/gpu/drm/cirrus/cirrus_mode.c
@@ -575,7 +575,6 @@ int cirrus_modeset_init(struct cirrus_device *cdev)
int ret;
drm_mode_config_init(cdev->dev);
- cdev->mode_info.mode_config_initialized = true;
cdev->dev->mode_config.max_width = CIRRUS_MAX_FB_WIDTH;
cdev->dev->mode_config.max_height = CIRRUS_MAX_FB_HEIGHT;
@@ -613,10 +612,6 @@ int cirrus_modeset_init(struct cirrus_device *cdev)
void cirrus_modeset_fini(struct cirrus_device *cdev)
{
cirrus_fbdev_fini(cdev);
-
- if (cdev->mode_info.mode_config_initialized) {
- drm_helper_force_disable_all(cdev->dev);
- drm_mode_config_cleanup(cdev->dev);
- cdev->mode_info.mode_config_initialized = false;
- }
+ drm_helper_force_disable_all(cdev->dev);
+ drm_mode_config_cleanup(cdev->dev);
}
--
2.18.1
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
[PATCH 1/2] drm/bochs: drop mode_config_initialized
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/bochs/bochs.h | 1 -
drivers/gpu/drm/bochs/bochs_kms.c | 8 ++--
2 files changed, 2 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/bochs/bochs.h b/drivers/gpu/drm/bochs/bochs.h
index 03711394f1ed..a7f6723bebdd 100644
--- a/drivers/gpu/drm/bochs/bochs.h
+++ b/drivers/gpu/drm/bochs/bochs.h
@@ -73,7 +73,6 @@ struct bochs_device {
struct drm_crtc crtc;
struct drm_encoder encoder;
struct drm_connector connector;
- bool mode_config_initialized;
/* ttm */
struct {
diff --git a/drivers/gpu/drm/bochs/bochs_kms.c
b/drivers/gpu/drm/bochs/bochs_kms.c
index 93cb27f93d39..485f9cf05e8b 100644
--- a/drivers/gpu/drm/bochs/bochs_kms.c
+++ b/drivers/gpu/drm/bochs/bochs_kms.c
@@ -267,7 +267,6 @@ const struct drm_mode_config_funcs bochs_mode_funcs = {
int bochs_kms_init(struct bochs_device *bochs)
{
drm_mode_config_init(bochs->dev);
- bochs->mode_config_initialized = true;
bochs->dev->mode_config.max_width = 8192;
bochs->dev->mode_config.max_height = 8192;
@@ -292,9 +291,6 @@ int bochs_kms_init(struct bochs_device *bochs)
void bochs_kms_fini(struct bochs_device *bochs)
{
- if (bochs->mode_config_initialized) {
- drm_atomic_helper_shutdown(bochs->dev);
- drm_mode_config_cleanup(bochs->dev);
- bochs->mode_config_initialized = false;
- }
+ drm_atomic_helper_shutdown(bochs->dev);
+ drm_mode_config_cleanup(bochs->dev);
}
--
2.18.1
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH 2/3] drm/bochs: add missing drm_atomic_helper_shutdown() call.
On Mon, Apr 01, 2019 at 04:03:05PM +0200, Gerd Hoffmann wrote:
> Signed-off-by: Gerd Hoffmann
> ---
> drivers/gpu/drm/bochs/bochs_kms.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/drm/bochs/bochs_kms.c
> b/drivers/gpu/drm/bochs/bochs_kms.c
> index 9e7cd6b34106..93cb27f93d39 100644
> --- a/drivers/gpu/drm/bochs/bochs_kms.c
> +++ b/drivers/gpu/drm/bochs/bochs_kms.c
> @@ -293,6 +293,7 @@ int bochs_kms_init(struct bochs_device *bochs)
> void bochs_kms_fini(struct bochs_device *bochs)
> {
> if (bochs->mode_config_initialized) {
This mode_config_initialized is hilarious. I think (from looking at git
history and all) this started in radeon, back when kms was an add-on, and
radeon.ko still supported ums. Then it was dutifully copypasted into
cirrus, bochs, mgag200, hisilicon and also amdgpu.
Afaict none of these drivers need this (but I didn't bother to review
amdgpu and radeon fully). Would be nice little cleanup to follow up with.
Anyway, on your 3 patches here:
Reviewed-by: Daniel Vetter
> + drm_atomic_helper_shutdown(bochs->dev);
> drm_mode_config_cleanup(bochs->dev);
> bochs->mode_config_initialized = false;
> }
> --
> 2.18.1
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
