From: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>
To: Oliver Neukum <oneukum@suse.com>
Cc: bjorn@mork.no, linux-usb@vger.kernel.org
Subject: Re: [RFC 0/5] fix races in CDC-WDM
Date: Tue, 22 Sep 2020 17:34:16 +0900 [thread overview]
Message-ID: <94896ccd-e1b3-11c5-be98-954ee01081ac@i-love.sakura.ne.jp> (raw)
In-Reply-To: <1600759983.6926.9.camel@suse.com>
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().
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.
next prev parent reply other threads:[~2020-09-22 8:34 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-08-12 13:20 [RFC 0/5] fix races in CDC-WDM Oliver Neukum
2020-08-12 13:20 ` [RFC 1/5] CDC-WDM: fix hangs in flush() Oliver Neukum
2020-08-12 13:20 ` [RFC 2/5] CDC-WDM: introduce a timeout " Oliver Neukum
2020-08-12 13:20 ` [RFC 3/5] CDC-WDM: making flush() interruptible Oliver Neukum
2020-08-12 13:20 ` [RFC 4/5] CDC-WDM: fix race reporting errors in flush Oliver Neukum
2020-08-12 13:20 ` [RFC 5/5] CDC-WDM: remove use of intf->dev after potential disconnect Oliver Neukum
2020-08-12 14:29 ` [RFC 0/5] fix races in CDC-WDM Tetsuo Handa
2020-09-10 9:09 ` Oliver Neukum
2020-09-10 10:01 ` Tetsuo Handa
2020-09-15 9:14 ` Oliver Neukum
2020-09-15 10:30 ` Tetsuo Handa
2020-09-16 10:18 ` Oliver Neukum
2020-09-16 11:14 ` Tetsuo Handa
2020-09-17 9:50 ` Oliver Neukum
2020-09-17 11:24 ` Tetsuo Handa
2020-09-17 14:17 ` Oliver Neukum
2020-09-17 16:17 ` Tetsuo Handa
2020-09-21 10:52 ` Oliver Neukum
2020-09-22 1:56 ` Tetsuo Handa
2020-09-22 7:33 ` Oliver Neukum
2020-09-22 8:34 ` Tetsuo Handa [this message]
2020-09-22 9:45 ` Oliver Neukum
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=94896ccd-e1b3-11c5-be98-954ee01081ac@i-love.sakura.ne.jp \
--to=penguin-kernel@i-love.sakura.ne.jp \
--cc=bjorn@mork.no \
--cc=linux-usb@vger.kernel.org \
--cc=oneukum@suse.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).