Michael S. Tsirkin <[email protected]> wrote:
>On Thu, Mar 22, 2018 at 09:05:52AM +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" <[email protected]>
>> Cc: Jason Wang <[email protected]>
>> Cc: Ben Hutchings <[email protected]>
>> Fixes: 167c25e4c550 ("virtio-net: init link state correctly")
>
>I'd say that's an abuse of this notation. openstate was UNKNOWN
>even before that fix.
I went back to the commit that added the dependency on
VIRTIO_NET_F_STATUS (and that this patch would thus apply on top of).
If that's an issue, I can resubmit without it.
-J
>> Signed-off-by: Jay Vosburgh <[email protected]>
>
>Acked-by: Michael S. Tsirkin <[email protected]>
>
>
>> ---
>>
>> 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
