| Message ID | 1527180917-39737-3-git-send-email-sridhar.samudrala@intel.com |
|---|---|
| State | Accepted, archived |
| Delegated to: | David Miller |
| Headers | show |
| Series | Enable virtio_net to act as a standby for a passthru device | expand |
On Thu, 24 May 2018 09:55:14 -0700 Sridhar Samudrala <sridhar.samudrala@intel.com> wrote: > --- a/drivers/net/hyperv/Kconfig > +++ b/drivers/net/hyperv/Kconfig > @@ -2,5 +2,6 @@ config HYPERV_NET > tristate "Microsoft Hyper-V virtual network driver" > depends on HYPERV > select UCS2_STRING > + select FAILOVER When I take a working kernel config, add the patches then do make oldconfig It is not autoselecting FAILOVER, it prompts me for it. This means if user says no then a non-working netvsc device is made.
On 5/25/2018 3:34 PM, Stephen Hemminger wrote: > On Thu, 24 May 2018 09:55:14 -0700 > Sridhar Samudrala <sridhar.samudrala@intel.com> wrote: > >> --- a/drivers/net/hyperv/Kconfig >> +++ b/drivers/net/hyperv/Kconfig >> @@ -2,5 +2,6 @@ config HYPERV_NET >> tristate "Microsoft Hyper-V virtual network driver" >> depends on HYPERV >> select UCS2_STRING >> + select FAILOVER > When I take a working kernel config, add the patches then do > make oldconfig > > It is not autoselecting FAILOVER, it prompts me for it. This means > if user says no then a non-working netvsc device is made. I see Generic failover module (FAILOVER) [M/y/?] (NEW) So the user is given an option to either build as a Module or part of the kernel. 'n' is not an option.
On Fri, 25 May 2018 16:11:47 -0700 "Samudrala, Sridhar" <sridhar.samudrala@intel.com> wrote: > On 5/25/2018 3:34 PM, Stephen Hemminger wrote: > > On Thu, 24 May 2018 09:55:14 -0700 > > Sridhar Samudrala <sridhar.samudrala@intel.com> wrote: > > > >> --- a/drivers/net/hyperv/Kconfig > >> +++ b/drivers/net/hyperv/Kconfig > >> @@ -2,5 +2,6 @@ config HYPERV_NET > >> tristate "Microsoft Hyper-V virtual network driver" > >> depends on HYPERV > >> select UCS2_STRING > >> + select FAILOVER > > When I take a working kernel config, add the patches then do > > make oldconfig > > > > It is not autoselecting FAILOVER, it prompts me for it. This means > > if user says no then a non-working netvsc device is made. > > I see > Generic failover module (FAILOVER) [M/y/?] (NEW) > > So the user is given an option to either build as a Module or part of the > kernel. 'n' is not an option. With most libraries there is no prompt at all.
On 5/25/2018 4:28 PM, Stephen Hemminger wrote: > On Fri, 25 May 2018 16:11:47 -0700 > "Samudrala, Sridhar" <sridhar.samudrala@intel.com> wrote: > >> On 5/25/2018 3:34 PM, Stephen Hemminger wrote: >>> On Thu, 24 May 2018 09:55:14 -0700 >>> Sridhar Samudrala <sridhar.samudrala@intel.com> wrote: >>> >>>> --- a/drivers/net/hyperv/Kconfig >>>> +++ b/drivers/net/hyperv/Kconfig >>>> @@ -2,5 +2,6 @@ config HYPERV_NET >>>> tristate "Microsoft Hyper-V virtual network driver" >>>> depends on HYPERV >>>> select UCS2_STRING >>>> + select FAILOVER >>> When I take a working kernel config, add the patches then do >>> make oldconfig >>> >>> It is not autoselecting FAILOVER, it prompts me for it. This means >>> if user says no then a non-working netvsc device is made. >> I see >> Generic failover module (FAILOVER) [M/y/?] (NEW) >> >> So the user is given an option to either build as a Module or part of the >> kernel. 'n' is not an option. > With most libraries there is no prompt at all. Not sure what you meant by this. Without any patches applied, i had a .config file with HYPERV_NET configured as a module. Then after applying the first 2 patches in this series, i did a make oldconfig and i see the above prompt. Are you saying that on some distros, 'make oldconfig creates a .config file without any prompt and FAILOVER is not getting selected even when HYPERV_NET is enabled?
Sat, May 26, 2018 at 09:22:18AM CEST, sridhar.samudrala@intel.com wrote: >On 5/25/2018 4:28 PM, Stephen Hemminger wrote: >> On Fri, 25 May 2018 16:11:47 -0700 >> "Samudrala, Sridhar" <sridhar.samudrala@intel.com> wrote: >> >> > On 5/25/2018 3:34 PM, Stephen Hemminger wrote: >> > > On Thu, 24 May 2018 09:55:14 -0700 >> > > Sridhar Samudrala <sridhar.samudrala@intel.com> wrote: >> > > > --- a/drivers/net/hyperv/Kconfig >> > > > +++ b/drivers/net/hyperv/Kconfig >> > > > @@ -2,5 +2,6 @@ config HYPERV_NET >> > > > tristate "Microsoft Hyper-V virtual network driver" >> > > > depends on HYPERV >> > > > select UCS2_STRING >> > > > + select FAILOVER >> > > When I take a working kernel config, add the patches then do >> > > make oldconfig >> > > >> > > It is not autoselecting FAILOVER, it prompts me for it. This means >> > > if user says no then a non-working netvsc device is made. >> > I see >> > Generic failover module (FAILOVER) [M/y/?] (NEW) >> > >> > So the user is given an option to either build as a Module or part of the >> > kernel. 'n' is not an option. >> With most libraries there is no prompt at all. > >Not sure what you meant by this. >Without any patches applied, i had a .config file with HYPERV_NET configured >as a module. >Then after applying the first 2 patches in this series, i did a > make oldconfig >and i see the above prompt. > >Are you saying that on some distros, 'make oldconfig creates a .config >file without any prompt and FAILOVER is not getting selected even when HYPERV_NET >is enabled? > > Well the thing is that for a user, it makes no sense to select "FAILOVER" by hand. It is a lib, so it should be only select it by a user. It has no sense to have it turned on by hand - no lib user. You can achieve that by simply removing "help" for the Kconfig item. Same thing for "NET_FAILOVER".
'On 5/26/2018 12:51 AM, Jiri Pirko wrote: > Sat, May 26, 2018 at 09:22:18AM CEST, sridhar.samudrala@intel.com wrote: >> On 5/25/2018 4:28 PM, Stephen Hemminger wrote: >>> On Fri, 25 May 2018 16:11:47 -0700 >>> "Samudrala, Sridhar" <sridhar.samudrala@intel.com> wrote: >>> >>>> On 5/25/2018 3:34 PM, Stephen Hemminger wrote: >>>>> On Thu, 24 May 2018 09:55:14 -0700 >>>>> Sridhar Samudrala <sridhar.samudrala@intel.com> wrote: >>>>>> --- a/drivers/net/hyperv/Kconfig >>>>>> +++ b/drivers/net/hyperv/Kconfig >>>>>> @@ -2,5 +2,6 @@ config HYPERV_NET >>>>>> tristate "Microsoft Hyper-V virtual network driver" >>>>>> depends on HYPERV >>>>>> select UCS2_STRING >>>>>> + select FAILOVER >>>>> When I take a working kernel config, add the patches then do >>>>> make oldconfig >>>>> >>>>> It is not autoselecting FAILOVER, it prompts me for it. This means >>>>> if user says no then a non-working netvsc device is made. >>>> I see >>>> Generic failover module (FAILOVER) [M/y/?] (NEW) >>>> >>>> So the user is given an option to either build as a Module or part of the >>>> kernel. 'n' is not an option. >>> With most libraries there is no prompt at all. >> Not sure what you meant by this. >> Without any patches applied, i had a .config file with HYPERV_NET configured >> as a module. >> Then after applying the first 2 patches in this series, i did a >> make oldconfig >> and i see the above prompt. >> >> Are you saying that on some distros, 'make oldconfig creates a .config >> file without any prompt and FAILOVER is not getting selected even when HYPERV_NET >> is enabled? >> >> > Well the thing is that for a user, it makes no sense to select > "FAILOVER" by hand. It is a lib, so it should be only select it by a > user. It has no sense to have it turned on by hand - no lib user. > You can achieve that by simply removing "help" for the Kconfig > item. Same thing for "NET_FAILOVER". I played around with the CONFIG options and i see that FAILOVER options do get selected correctly when virtio-net/netvsc are enabled. Even if the FAILOVER is turned off by the user before the hyperv-net/virtio-net patches are applied, it gets selected automatically when hyperv-net/virtio-net patches are applied and enabled in config. If we don't want to allow the user to see these options, then i think we need to remove them from Kconfig files. Just removing "help" doesn't seem to make a difference. Can we address any config issues (i don't see any at this point) as a bug-fix on top of this series?
On Thu, 24 May 2018 09:55:14 -0700 Sridhar Samudrala <sridhar.samudrala@intel.com> wrote: > Use the registration/notification framework supported by the generic > failover infrastructure. > > Signed-off-by: Sridhar Samudrala <sridhar.samudrala@intel.com> Why was this merged? It was never signed off by any of the netvsc maintainers, and there were still issues unresolved. There are also namespaces issues I am fixing and this breaks them. Will start my patch set with a revert for this. Sorry
On 5/30/2018 7:06 PM, Stephen Hemminger wrote: > On Thu, 24 May 2018 09:55:14 -0700 > Sridhar Samudrala <sridhar.samudrala@intel.com> wrote: > >> Use the registration/notification framework supported by the generic >> failover infrastructure. >> >> Signed-off-by: Sridhar Samudrala <sridhar.samudrala@intel.com> > Why was this merged? It was never signed off by any of the netvsc maintainers, > and there were still issues unresolved. > > There are also namespaces issues I am fixing and this breaks them. > Will start my patch set with a revert for this. Sorry I would appreciate if you can make the fixes on top of this patch series. I tried hard to make sure that netvsc functionality and behavior doesn't change. It is possible that there could be some bugs introduced, but they can be fixed. Looks like Wei already found a bug and submitted a fix for that.
On Wed, 30 May 2018 20:03:11 -0700 "Samudrala, Sridhar" <sridhar.samudrala@intel.com> wrote: > On 5/30/2018 7:06 PM, Stephen Hemminger wrote: > > On Thu, 24 May 2018 09:55:14 -0700 > > Sridhar Samudrala <sridhar.samudrala@intel.com> wrote: > > > >> Use the registration/notification framework supported by the generic > >> failover infrastructure. > >> > >> Signed-off-by: Sridhar Samudrala <sridhar.samudrala@intel.com> > > Why was this merged? It was never signed off by any of the netvsc maintainers, > > and there were still issues unresolved. > > > > There are also namespaces issues I am fixing and this breaks them. > > Will start my patch set with a revert for this. Sorry > > I would appreciate if you can make the fixes on top of this patch series. I tried hard > to make sure that netvsc functionality and behavior doesn't change. > > It is possible that there could be some bugs introduced, but they can be fixed. > Looks like Wei already found a bug and submitted a fix for that. > Ok, but several of these may clash with what you want for virtio. Like: - VF should be moved to namespace of virt device - VF should be associated based on message from host with serial # not registration notifier and MAC address. - control operations should use master device reference rather than searching based on MAC. As you can see these are structural changes.
On Thu, May 31, 2018 at 08:58:12AM -0400, Stephen Hemminger wrote: > On Wed, 30 May 2018 20:03:11 -0700 > "Samudrala, Sridhar" <sridhar.samudrala@intel.com> wrote: > > > On 5/30/2018 7:06 PM, Stephen Hemminger wrote: > > > On Thu, 24 May 2018 09:55:14 -0700 > > > Sridhar Samudrala <sridhar.samudrala@intel.com> wrote: > > > > > >> Use the registration/notification framework supported by the generic > > >> failover infrastructure. > > >> > > >> Signed-off-by: Sridhar Samudrala <sridhar.samudrala@intel.com> > > > Why was this merged? It was never signed off by any of the netvsc maintainers, > > > and there were still issues unresolved. > > > > > > There are also namespaces issues I am fixing and this breaks them. > > > Will start my patch set with a revert for this. Sorry > > > > I would appreciate if you can make the fixes on top of this patch series. I tried hard > > to make sure that netvsc functionality and behavior doesn't change. > > > > It is possible that there could be some bugs introduced, but they can be fixed. > > Looks like Wei already found a bug and submitted a fix for that. > > > > Ok, but several of these may clash with what you want for virtio. > Like: > - VF should be moved to namespace of virt device > - VF should be associated based on message from host with serial # not > registration notifier and MAC address. > - control operations should use master device reference rather than > searching based on MAC. > > As you can see these are structural changes. We might want to do these for virtio as well, at least as an option.
On Wed, May 30, 2018 at 10:06:35PM -0400, Stephen Hemminger wrote: > On Thu, 24 May 2018 09:55:14 -0700 > Sridhar Samudrala <sridhar.samudrala@intel.com> wrote: > > > Use the registration/notification framework supported by the generic > > failover infrastructure. > > > > Signed-off-by: Sridhar Samudrala <sridhar.samudrala@intel.com> > > Why was this merged? It was never signed off by any of the netvsc maintainers, > and there were still issues unresolved. > > There are also namespaces issues I am fixing and this breaks them. > Will start my patch set with a revert for this. Sorry As long as you finish the patch set with re-integrating with failover, that's fine IMHO. I suspect it's easier to add the code to failover though - namespace things likely affect virtio as well. Lookup by ID would be an optional feature for virtio, but probably a useful one - I won't ask you to add it to virtio but it could be a mode in failover that virtio will activate down the road. And reducing the number of times we look cards up based on ID can only be a good thing.
On Thu, May 31, 2018 at 11:35 AM, Michael S. Tsirkin <mst@redhat.com> wrote: > On Wed, May 30, 2018 at 10:06:35PM -0400, Stephen Hemminger wrote: >> On Thu, 24 May 2018 09:55:14 -0700 >> Sridhar Samudrala <sridhar.samudrala@intel.com> wrote: >> >> > Use the registration/notification framework supported by the generic >> > failover infrastructure. >> > >> > Signed-off-by: Sridhar Samudrala <sridhar.samudrala@intel.com> >> >> Why was this merged? It was never signed off by any of the netvsc maintainers, >> and there were still issues unresolved. >> >> There are also namespaces issues I am fixing and this breaks them. >> Will start my patch set with a revert for this. Sorry > > As long as you finish the patch set with re-integrating with failover, > that's fine IMHO. > > I suspect it's easier to add the code to failover though - namespace > things likely affect virtio as well. Lookup by ID would be an optional > feature for virtio, but probably a useful one - I won't ask you I would think for production uses this is a required feature and should be enabled by default. Venu (cc'ed) is working on the group ID stuff currently for pairing virtio and passthrough devices. Would appreciate feedback on the group ID proposal on virtio-dev. -Siwei > to add it to virtio but it could be a mode in failover > that virtio will activate down the road. And reducing the number of > times we look cards up based on ID can only be a good thing. > > -- > MST
diff --git a/drivers/net/hyperv/Kconfig b/drivers/net/hyperv/Kconfig index 0765d5f61714..23a2d145813a 100644 --- a/drivers/net/hyperv/Kconfig +++ b/drivers/net/hyperv/Kconfig @@ -2,5 +2,6 @@ config HYPERV_NET tristate "Microsoft Hyper-V virtual network driver" depends on HYPERV select UCS2_STRING + select FAILOVER help Select this option to enable the Hyper-V virtual network driver. diff --git a/drivers/net/hyperv/hyperv_net.h b/drivers/net/hyperv/hyperv_net.h index 1be34d2e3563..99d8e7398a5b 100644 --- a/drivers/net/hyperv/hyperv_net.h +++ b/drivers/net/hyperv/hyperv_net.h @@ -932,6 +932,8 @@ struct net_device_context { u32 vf_alloc; /* Serial number of the VF to team with */ u32 vf_serial; + + struct failover *failover; }; /* Per channel data */ diff --git a/drivers/net/hyperv/netvsc_drv.c b/drivers/net/hyperv/netvsc_drv.c index da07ccdf84bf..62eb136c5e73 100644 --- a/drivers/net/hyperv/netvsc_drv.c +++ b/drivers/net/hyperv/netvsc_drv.c @@ -43,6 +43,7 @@ #include <net/pkt_sched.h> #include <net/checksum.h> #include <net/ip6_checksum.h> +#include <net/failover.h> #include "hyperv_net.h" @@ -1763,46 +1764,6 @@ static void netvsc_link_change(struct work_struct *w) rtnl_unlock(); } -static struct net_device *get_netvsc_bymac(const u8 *mac) -{ - struct net_device *dev; - - ASSERT_RTNL(); - - for_each_netdev(&init_net, dev) { - if (dev->netdev_ops != &device_ops) - continue; /* not a netvsc device */ - - if (ether_addr_equal(mac, dev->perm_addr)) - return dev; - } - - return NULL; -} - -static struct net_device *get_netvsc_byref(struct net_device *vf_netdev) -{ - struct net_device *dev; - - ASSERT_RTNL(); - - for_each_netdev(&init_net, dev) { - struct net_device_context *net_device_ctx; - - if (dev->netdev_ops != &device_ops) - continue; /* not a netvsc device */ - - net_device_ctx = netdev_priv(dev); - if (!rtnl_dereference(net_device_ctx->nvdev)) - continue; /* device is removed */ - - if (rtnl_dereference(net_device_ctx->vf_netdev) == vf_netdev) - return dev; /* a match */ - } - - return NULL; -} - /* Called when VF is injecting data into network stack. * Change the associated network device from VF to netvsc. * note: already called with rcu_read_lock @@ -1825,46 +1786,6 @@ static rx_handler_result_t netvsc_vf_handle_frame(struct sk_buff **pskb) return RX_HANDLER_ANOTHER; } -static int netvsc_vf_join(struct net_device *vf_netdev, - struct net_device *ndev) -{ - struct net_device_context *ndev_ctx = netdev_priv(ndev); - int ret; - - ret = netdev_rx_handler_register(vf_netdev, - netvsc_vf_handle_frame, ndev); - if (ret != 0) { - netdev_err(vf_netdev, - "can not register netvsc VF receive handler (err = %d)\n", - ret); - goto rx_handler_failed; - } - - ret = netdev_master_upper_dev_link(vf_netdev, ndev, - NULL, NULL, NULL); - if (ret != 0) { - netdev_err(vf_netdev, - "can not set master device %s (err = %d)\n", - ndev->name, ret); - goto upper_link_failed; - } - - /* set slave flag before open to prevent IPv6 addrconf */ - vf_netdev->flags |= IFF_SLAVE; - - schedule_delayed_work(&ndev_ctx->vf_takeover, VF_TAKEOVER_INT); - - call_netdevice_notifiers(NETDEV_JOIN, vf_netdev); - - netdev_info(vf_netdev, "joined to %s\n", ndev->name); - return 0; - -upper_link_failed: - netdev_rx_handler_unregister(vf_netdev); -rx_handler_failed: - return ret; -} - static void __netvsc_vf_setup(struct net_device *ndev, struct net_device *vf_netdev) { @@ -1915,85 +1836,95 @@ static void netvsc_vf_setup(struct work_struct *w) rtnl_unlock(); } -static int netvsc_register_vf(struct net_device *vf_netdev) +static int netvsc_pre_register_vf(struct net_device *vf_netdev, + struct net_device *ndev) { - struct net_device *ndev; struct net_device_context *net_device_ctx; struct netvsc_device *netvsc_dev; - if (vf_netdev->addr_len != ETH_ALEN) - return NOTIFY_DONE; - - /* - * We will use the MAC address to locate the synthetic interface to - * associate with the VF interface. If we don't find a matching - * synthetic interface, move on. - */ - ndev = get_netvsc_bymac(vf_netdev->perm_addr); - if (!ndev) - return NOTIFY_DONE; - net_device_ctx = netdev_priv(ndev); netvsc_dev = rtnl_dereference(net_device_ctx->nvdev); if (!netvsc_dev || rtnl_dereference(net_device_ctx->vf_netdev)) - return NOTIFY_DONE; + return -ENODEV; + + return 0; +} + +static int netvsc_register_vf(struct net_device *vf_netdev, + struct net_device *ndev) +{ + struct net_device_context *ndev_ctx = netdev_priv(ndev); - if (netvsc_vf_join(vf_netdev, ndev) != 0) - return NOTIFY_DONE; + /* set slave flag before open to prevent IPv6 addrconf */ + vf_netdev->flags |= IFF_SLAVE; - netdev_info(ndev, "VF registering: %s\n", vf_netdev->name); + schedule_delayed_work(&ndev_ctx->vf_takeover, VF_TAKEOVER_INT); + + call_netdevice_notifiers(NETDEV_JOIN, vf_netdev); + + netdev_info(vf_netdev, "joined to %s\n", ndev->name); dev_hold(vf_netdev); - rcu_assign_pointer(net_device_ctx->vf_netdev, vf_netdev); - return NOTIFY_OK; + rcu_assign_pointer(ndev_ctx->vf_netdev, vf_netdev); + + return 0; } /* VF up/down change detected, schedule to change data path */ -static int netvsc_vf_changed(struct net_device *vf_netdev) +static int netvsc_vf_changed(struct net_device *vf_netdev, + struct net_device *ndev) { struct net_device_context *net_device_ctx; struct netvsc_device *netvsc_dev; - struct net_device *ndev; bool vf_is_up = netif_running(vf_netdev); - ndev = get_netvsc_byref(vf_netdev); - if (!ndev) - return NOTIFY_DONE; - net_device_ctx = netdev_priv(ndev); netvsc_dev = rtnl_dereference(net_device_ctx->nvdev); if (!netvsc_dev) - return NOTIFY_DONE; + return -ENODEV; netvsc_switch_datapath(ndev, vf_is_up); netdev_info(ndev, "Data path switched %s VF: %s\n", vf_is_up ? "to" : "from", vf_netdev->name); - return NOTIFY_OK; + return 0; } -static int netvsc_unregister_vf(struct net_device *vf_netdev) +static int netvsc_pre_unregister_vf(struct net_device *vf_netdev, + struct net_device *ndev) { - struct net_device *ndev; struct net_device_context *net_device_ctx; - ndev = get_netvsc_byref(vf_netdev); - if (!ndev) - return NOTIFY_DONE; - net_device_ctx = netdev_priv(ndev); cancel_delayed_work_sync(&net_device_ctx->vf_takeover); + return 0; +} + +static int netvsc_unregister_vf(struct net_device *vf_netdev, + struct net_device *ndev) +{ + struct net_device_context *net_device_ctx; + + net_device_ctx = netdev_priv(ndev); + netdev_info(ndev, "VF unregistering: %s\n", vf_netdev->name); - netdev_rx_handler_unregister(vf_netdev); - netdev_upper_dev_unlink(vf_netdev, ndev); RCU_INIT_POINTER(net_device_ctx->vf_netdev, NULL); dev_put(vf_netdev); - return NOTIFY_OK; + return 0; } +static struct failover_ops netvsc_failover_ops = { + .slave_pre_register = netvsc_pre_register_vf, + .slave_register = netvsc_register_vf, + .slave_pre_unregister = netvsc_pre_unregister_vf, + .slave_unregister = netvsc_unregister_vf, + .slave_link_change = netvsc_vf_changed, + .slave_handle_frame = netvsc_vf_handle_frame, +}; + static int netvsc_probe(struct hv_device *dev, const struct hv_vmbus_device_id *dev_id) { @@ -2083,8 +2014,14 @@ static int netvsc_probe(struct hv_device *dev, goto register_failed; } + net_device_ctx->failover = failover_register(net, &netvsc_failover_ops); + if (IS_ERR(net_device_ctx->failover)) + goto err_failover; + return ret; +err_failover: + unregister_netdev(net); register_failed: rndis_filter_device_remove(dev, nvdev); rndis_failed: @@ -2125,13 +2062,15 @@ static int netvsc_remove(struct hv_device *dev) rtnl_lock(); vf_netdev = rtnl_dereference(ndev_ctx->vf_netdev); if (vf_netdev) - netvsc_unregister_vf(vf_netdev); + failover_slave_unregister(vf_netdev); if (nvdev) rndis_filter_device_remove(dev, nvdev); unregister_netdevice(net); + failover_unregister(ndev_ctx->failover); + rtnl_unlock(); rcu_read_unlock(); @@ -2158,54 +2097,8 @@ static struct hv_driver netvsc_drv = { .remove = netvsc_remove, }; -/* - * On Hyper-V, every VF interface is matched with a corresponding - * synthetic interface. The synthetic interface is presented first - * to the guest. When the corresponding VF instance is registered, - * we will take care of switching the data path. - */ -static int netvsc_netdev_event(struct notifier_block *this, - unsigned long event, void *ptr) -{ - struct net_device *event_dev = netdev_notifier_info_to_dev(ptr); - - /* Skip our own events */ - if (event_dev->netdev_ops == &device_ops) - return NOTIFY_DONE; - - /* Avoid non-Ethernet type devices */ - if (event_dev->type != ARPHRD_ETHER) - return NOTIFY_DONE; - - /* Avoid Vlan dev with same MAC registering as VF */ - if (is_vlan_dev(event_dev)) - return NOTIFY_DONE; - - /* Avoid Bonding master dev with same MAC registering as VF */ - if ((event_dev->priv_flags & IFF_BONDING) && - (event_dev->flags & IFF_MASTER)) - return NOTIFY_DONE; - - switch (event) { - case NETDEV_REGISTER: - return netvsc_register_vf(event_dev); - case NETDEV_UNREGISTER: - return netvsc_unregister_vf(event_dev); - case NETDEV_UP: - case NETDEV_DOWN: - return netvsc_vf_changed(event_dev); - default: - return NOTIFY_DONE; - } -} - -static struct notifier_block netvsc_netdev_notifier = { - .notifier_call = netvsc_netdev_event, -}; - static void __exit netvsc_drv_exit(void) { - unregister_netdevice_notifier(&netvsc_netdev_notifier); vmbus_driver_unregister(&netvsc_drv); } @@ -2225,7 +2118,6 @@ static int __init netvsc_drv_init(void) if (ret) return ret; - register_netdevice_notifier(&netvsc_netdev_notifier); return 0; }
Use the registration/notification framework supported by the generic failover infrastructure. Signed-off-by: Sridhar Samudrala <sridhar.samudrala@intel.com> --- drivers/net/hyperv/Kconfig | 1 + drivers/net/hyperv/hyperv_net.h | 2 + drivers/net/hyperv/netvsc_drv.c | 222 +++++++++++----------------------------- 3 files changed, 60 insertions(+), 165 deletions(-)