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

[Oliver Neukum <oneukum@suse.com>]

Am Mittwoch, den 16.09.2020, 20:14 +0900 schrieb Tetsuo Handa:
> On 2020/09/16 19:18, Oliver Neukum wrote:
> > Am Dienstag, den 15.09.2020, 19:30 +0900 schrieb Tetsuo Handa:
> > > On 2020/09/15 18:14, Oliver Neukum wrote
> > > > Is there something we can do in flush()?
> > > 
> > > I consider that wdm_flush() is a wrong place to return an error. It is possible that
> > 
> > I am afraid that is a basic problem we need to resolve. As I understand
> >  it, flush() as a method exists precisely to report errors. Otherwise
> > you could implement it in release(). But this is not called for every
> > close().
> 
> I think fsync() or ioctl() is a better method for reporting errors.

Very well, I am implementing fsync(). However, I must say that the very
existance of fsync() tells us that write() is not expected to push
data out to devices and hence report results.

> Whether N'th write() request succeeded remains unknown until (N+1)'th
> write() request or close() request is issued? That sounds a strange design.

Welcome to the world of Unix. This is necessary if you want to block
as rarely as possible.

> If there is nothing more to write(), how userspace process knows whether
> N'th write() request succeeded? Wait for writability using poll() ?

Technically fsync(). poll() will tell you that you can write again.
That is a related but different concept.

> What is the purpose of sending the error to the userspace process via write() or close()?

Yes. However to do so, user space must be running. That the death
of a process interferes with error handling is independent from that.

> And I think that wdm_flush() is a strange interface for reporting the error.

Well, POSIX is what it is.The close() syscall is supposed to return
errors. Hence flush() must report them.

	Regards
		Oliver