On Sat, 2018-08-04 at 11:01 +0200, Greg Kroah-Hartman wrote:
> 4.4-stable review patch. If anyone has any objections, please let me know.
>
> ------------------
>
> From: Xiao Liang <xiliang@xxxxxxxxxx>
>
> [ Upstream commit 822fb18a82abaf4ee7058793d95d340f5dab7bfc ]
>
> 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.
[...]
> --- a/drivers/net/xen-netfront.c
> +++ b/drivers/net/xen-netfront.c
> @@ -86,6 +86,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 {
> @@ -1335,6 +1336,11 @@ static struct net_device *xennet_create_
> 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:
This won't work; it will hang. Something (maybe netback_changed()?)
needs to wake up tasks on the module_load_q.
Ben.
--
Ben Hutchings, Software Developer Codethink Ltd
https://www.codethink.co.uk/ Dale House, 35 Dale Street
Manchester, M1 2HF, United Kingdom
