From mboxrd@z Thu Jan 1 00:00:00 1970 From: Boris Ostrovsky Subject: Re: [PATCH] xen-netfront: wait xenbus state change when load module manually Date: Fri, 27 Jul 2018 14:40:51 -0400 Message-ID: <4dfca465-8da3-7ebf-aac1-08ffe34a74ac@oracle.com> References: <20180727095608.25210-1-xiliang@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Cc: linux-kernel@vger.kernel.org To: Xiao Liang , netdev@vger.kernel.org, xen-devel@lists.xenproject.org, davem@davemloft.net, jgross@suse.com Return-path: In-Reply-To: <20180727095608.25210-1-xiliang@redhat.com> Content-Language: en-US Sender: linux-kernel-owner@vger.kernel.org List-Id: netdev.vger.kernel.org On 07/27/2018 05:56 AM, Xiao Liang wrote: > When loading module manually, after call xenbus_switch_state to initializes > the state of the netfront device, the driver state did not change so fast > that may lead no dev created in latest kernel. This patch adds wait to make > sure xenbus knows the driver is not in closed/unknown state. > > Current state: > [vm]# ethtool eth0 > Settings for eth0: > Link detected: yes > [vm]# modprobe -r xen_netfront > [vm]# modprobe xen_netfront > [vm]# ethtool eth0 > Settings for eth0: > Cannot get device settings: No such device > Cannot get wake-on-lan settings: No such device > Cannot get message level: No such device > Cannot get link status: No such device > No data available > > With the patch installed. > [vm]# ethtool eth0 > Settings for eth0: > Link detected: yes > [vm]# modprobe -r xen_netfront > [vm]# modprobe xen_netfront > [vm]# ethtool eth0 > Settings for eth0: > Link detected: yes > > Signed-off-by: Xiao Liang > --- > drivers/net/xen-netfront.c | 6 ++++++ > 1 file changed, 6 insertions(+) > > diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c > index a57daecf1d57..2d8812dd1534 100644 > --- a/drivers/net/xen-netfront.c > +++ b/drivers/net/xen-netfront.c > @@ -87,6 +87,7 @@ struct netfront_cb { > /* IRQ name is queue name with "-tx" or "-rx" appended */ > #define IRQ_NAME_SIZE (QUEUE_NAME_SIZE + 3) > > +static DECLARE_WAIT_QUEUE_HEAD(module_load_q); > static DECLARE_WAIT_QUEUE_HEAD(module_unload_q); > > struct netfront_stats { > @@ -1330,6 +1331,11 @@ static struct net_device *xennet_create_dev(struct xenbus_device *dev) > netif_carrier_off(netdev); > > xenbus_switch_state(dev, XenbusStateInitialising); > + wait_event(module_load_q, > + xenbus_read_driver_state(dev->otherend) != > + XenbusStateClosed && > + xenbus_read_driver_state(dev->otherend) != > + XenbusStateUnknown); > return netdev; > > exit: Should we have a wake_up somewhere? And what about other states --- is, for example, XenbusStateClosing a valid reason to continue? -boris