From: Oliver Neukum <oneukum@suse.com>
To: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>
Cc: bjorn@mork.no, linux-usb@vger.kernel.org
Subject: Re: [RFC 0/5] fix races in CDC-WDM
Date: Wed, 16 Sep 2020 12:18:06 +0200 [thread overview]
Message-ID: <1600251486.2424.17.camel@suse.com> (raw)
In-Reply-To: <4b8f6305-52fd-cb72-eb13-9d0a0bf07319@i-love.sakura.ne.jp>
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().
Hence a driver is supposed to start IO upon write() and report the
result to the next call, which can be either write() or close(), the
latter corresponding to flush().
> a userspace process reaches wdm_flush() due to being killed by SIGKILL (rather than
> via calling close() syscall). Then, that userspace process will never receive the error
If you are killed by a signal you are in a race condition
anyway. It cannot be handled.
> fetched from wdm_flush(). Also, if that userspace process is killed by the OOM killer,
> being able to terminate and release resources as soon as possible is more preferable
> than try to wait for response.
Right, so should we just proceed in case of a dieing task? How do we
do that?
Regards
Oliver
next prev parent reply other threads:[~2020-09-16 10:26 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 [this message]
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
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=1600251486.2424.17.camel@suse.com \
--to=oneukum@suse.com \
--cc=bjorn@mork.no \
--cc=linux-usb@vger.kernel.org \
--cc=penguin-kernel@i-love.sakura.ne.jp \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.