Re: [RFC 0/5] fix races in CDC-WDM

[Oliver Neukum <oneukum@suse.com>]

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