On Thu, Mar 22, 2018 at 02:42:41PM +0000, Jay Vosburgh wrote:
> The operstate update logic will leave an interface in the
> default UNKNOWN operstate if the interface carrier state never changes
> from the default carrier up state set at creation. This includes the
> case of an explicit call to netif_carrier_on, as the carrier on to on
> transition has no effect on operstate.
>
> This affects virtio-net for the case that the virtio peer does
> not support VIRTIO_NET_F_STATUS (the feature that provides carrier state
> updates). Without this feature, the virtio specification states that
> "the link should be assumed active," so, logically, the operstate should
> be UP instead of UNKNOWN. This has impact on user space applications
> that use the operstate to make availability decisions for the interface.
>
> Resolve this by changing the virtio probe logic slightly to call
> netif_carrier_off for both the "with" and "without" VIRTIO_NET_F_STATUS
> cases, and then the existing call to netif_carrier_on for the "without"
> case will cause an operstate transition.
>
> Cc: "Michael S. Tsirkin" <m...@redhat.com>
> Cc: Jason Wang <jasow...@redhat.com>
> Cc: Ben Hutchings <b...@decadent.org.uk>
> Signed-off-by: Jay Vosburgh <jay.vosbu...@canonical.com>
Arguably userspace apps should learn to treat UNKNOWN as UP.
But on the balance this seems more likely to fix apps than to
break any, so
Acked-by: Michael S. Tsirkin <m...@redhat.com>
> ---
>
> I considered resolving this by changing linkwatch_init_dev to
> unconditionally call rfc2863_policy, as that would always set operstate
> for all interfaces.
>
> This would not have any impact on most cases (as most drivers
> call netif_carrier_off during probe), except for the loopback device,
> which currently has an operstate of UNKNOWN (because it never does any
> carrier state transitions). This change would add a round trip on the
> dev_base_lock for every loopback device creation, which could have a
> negative impact when creating many loopback devices, e.g., when
> concurrently creating large numbers of containers.
>
>
> drivers/net/virtio_net.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
> index 23374603e4d9..7b187ec7411e 100644
> --- a/drivers/net/virtio_net.c
> +++ b/drivers/net/virtio_net.c
> @@ -2857,8 +2857,8 @@ static int virtnet_probe(struct virtio_device *vdev)
>
> /* Assume link up if device can't report link status,
> otherwise get link status from config. */
> + netif_carrier_off(dev);
> if (virtio_has_feature(vi->vdev, VIRTIO_NET_F_STATUS)) {
> - netif_carrier_off(dev);
> schedule_work(&vi->config_work);
> } else {
> vi->status = VIRTIO_NET_S_LINK_UP;
> --
> 2.14.1
