Am Dienstag, den 22.09.2020, 17:34 +0900 schrieb Tetsuo Handa: > On 2020/09/22 16:33, Oliver Neukum wrote: > > Am Dienstag, den 22.09.2020, 10:56 +0900 schrieb Tetsuo Handa: > > > On 2020/09/21 19:52, Oliver Neukum wrote: > > > To understand it, I must understand why it is safe to defer error reporting. > > > > It is not. There is nothing to understand here. If user space needs > > a guarantee that data has been pushed out without an error, it will > > have to call fsync() > > > I'm querying you about characteristics of data passed to wdm_write(). > > > Without knowing the difference between writing to cdc-wdm driver and normal file on > > > some filesystem, I can't judge whether it is acceptable to defer reporting errors. > > > > That is simply not a decision you or I make. The man page clearly > > says that it is acceptable. If user space does not like that, it must > > call fsync() after write(). > > Then, cdc-wdm driver did not implement fsync() was a big problem. Userspace > needs to be careful not to give up upon -EINVAL when running on older kernels > which did not implement wdm_fsync(). Very well. So I'll call the lack of fsync() a bug, which should be fixed in stable. > The remaining concern would be how to handle unresponding hardware, for blocking > wdm_write()/wdm_read() and wdm_fsync() are using wait_event_interruptible(). If > the caller do not have a mean to send a signal, the caller might hung up forever > when the hardware stopped responding. Please add a comment that userspace needs to > be careful when calling these functions. wdm_flush() has such a comment. Yet no driver can make a guarantee that a device will make progress in IO. The driver must, however, provide a means of dealing with such cases. Usually that means handling signals. That is the normal semantics of a write() syscall. I believe we are covered on that. Regards Oliver
