On 2020/09/10 18:09, Oliver Neukum wrote: >> Does it make sense to wait for response of someone else's usb_submit_urb() when >> someone is calling close(), for there is no guarantee that failure notice received >> via wdm_flush() via some file descriptor corresponds to usb_submit_urb() request from >> wdm_write() call from that file descriptor? > > Well, user space may do multithreading. Whether it makes sense is > another question. We just need to return results confirming to the > standards. You noticed bugs. I think the next version will fix them. My question is how do you handle if App1 and App2 (not multithreading but multiprocessing) shares the "desc" ? Unless >> In patch "[RFC 3/5] CDC-WDM: making flush() interruptible", it is legal to return -EINTR >> from close(). But I think that returning -EINTR from close() is not recommended because >> it can confuse multithreaded application (retrying close() upon -EINTR is not safe). > > Well, but what is the alternative? Should we ignore signals? > we return the error from write() request (i.e. give up trying to report errors from close() event), we can't pass results to the intended recipients.
