On Mon, Mar 01, 2021 at 08:52:58AM +0000, Zhang, Qiang wrote: > > > ________________________________________ > 发件人: Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> > 发送时间: 2021年3月1日 16:32 > 收件人: Zhang, Qiang > 抄送: zaitcev@xxxxxxxxxx; linux-usb@xxxxxxxxxxxxxxx > 主题: Re: 回复: [PATCH] USB: usblp: Add device status detection in usblp_poll() > > [Please note: This e-mail is from an EXTERNAL e-mail address] > > On Mon, Mar 01, 2021 at 08:26:22AM +0000, Zhang, Qiang wrote: > > > > > > ________________________________________ > > 发件人: Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> > > 发送时间: 2021年3月1日 16:00 > > 收件人: Zhang, Qiang > > 抄送: zaitcev@xxxxxxxxxx; linux-usb@xxxxxxxxxxxxxxx > > 主题: Re: [PATCH] USB: usblp: Add device status detection in usblp_poll() > > > > [Please note: This e-mail is from an EXTERNAL e-mail address] > > > > On Mon, Mar 01, 2021 at 12:03:00PM +0800, qiang.zhang@xxxxxxxxxxxxx wrote: > > > From: Zqiang <qiang.zhang@xxxxxxxxxxxxx> > > > > > > If usblp device has been disconnected, direct return > > > 'EPOLLHUP | EPOLLERR' in usblp_poll(). > > > > > >Why? What problem are you solving here? Is this fixing an >older > > >commit, if so, what one? > > > > > > > There is not need fix older commit. > > After the device is disconnected, if the userspace call >poll/select() function, will block and never be awakened . > > > >If the device is disconnected, how can the file be opened at >all? > >Shouldn't it have been torn down already? > > If the device disconnect happen after the file be opend, and then we call poll/select() will always blocked. > Also before we operate the device, we need to judge the state of the >device. If it is disconnected, there is no need for subsequent >operation . > >But shouldn't the normal call to poll_wait() fail here? poll_wait() is not fail, its main operation is to call add_wait_queue() > > >And now you are holding a lock across some poll_wait() calls, >is >that > >going to cause problems? > > The 'usblp->present' is portect by 'usblp->mut', when devices disconnect, will acquire 'usblp->mut', and set 'usblp->present' > zero. > >But you are now holding a mutex across a very very long period of >time, >what will that change? maybe acquire mutex lock will take a long time, but it's safe. and also I find similar usage in usb/class/usbtmc.c thanks Qiang > >thanks, > >greg k-h
