From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from shards.monkeyblade.net ([184.105.139.130]:43142 "EHLO shards.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750789AbeCWQRF (ORCPT ); Fri, 23 Mar 2018 12:17:05 -0400 Date: Fri, 23 Mar 2018 12:17:04 -0400 (EDT) Message-Id: <20180323.121704.2141481482842731916.davem@davemloft.net> To: jay.vosburgh@canonical.com Cc: netdev@vger.kernel.org, mst@redhat.com, jasowang@redhat.com, ben@decadent.org.uk Subject: Re: [PATCH v2 net-next] virtio-net: Fix operstate for virtio when no VIRTIO_NET_F_STATUS From: David Miller In-Reply-To: <23981.1521729761@nyx> References: <23981.1521729761@nyx> Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: netdev-owner@vger.kernel.org List-ID: From: Jay Vosburgh Date: Thu, 22 Mar 2018 14:42:41 +0000 > 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" > Cc: Jason Wang > Cc: Ben Hutchings > Signed-off-by: Jay Vosburgh Applied, thank you.