Re: [PATCH 6/6] uio_hv_generic: defer opening vmbus until first use

2018-09-16 Thread kbuild test robot
Hi Stephen, I love your patch! Yet something to improve: [auto build test ERROR on linus/master] [also build test ERROR on v4.19-rc3 next-20180913] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url:

Re: [PATCH 6/6] uio_hv_generic: defer opening vmbus until first use

2018-09-16 Thread kbuild test robot
Hi Stephen, I love your patch! Yet something to improve: [auto build test ERROR on linus/master] [also build test ERROR on v4.19-rc3 next-20180913] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url:

[PATCH 6/6] uio_hv_generic: defer opening vmbus until first use

2018-09-14 Thread Stephen Hemminger
This fixes two design flaws in hv_uio_generic. Since hv_uio_probe is called from vmbus_probe with lock held it potentially can cause sleep in an atomic section because vmbus_open will wait for response from host. The hv_uio_generic driver could not handle applications exiting and restarting

Re: [PATCH 6/6] uio_hv_generic: defer opening vmbus until first use

2018-09-14 Thread Dan Carpenter
On Thu, Sep 13, 2018 at 03:25:27PM -0700, Stephen Hemminger wrote: > +/* VMBus primary channel is opened on first use */ > +static int > +hv_uio_open(struct uio_info *info, struct inode *inode) > +{ > + struct hv_uio_private_data *pdata > + = container_of(info, struct

[PATCH 6/6] uio_hv_generic: defer opening vmbus until first use

2018-09-13 Thread Stephen Hemminger
This fixes two design flaws in hv_uio_generic. Since hv_uio_probe is called from vmbus_probe with lock held it potentially can cause sleep in an atomic section because vmbus_open will wait for response from host. The hv_uio_generic driver could not handle applications exiting and restarting