From: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>
To: Andrey Konovalov <andreyknvl@google.com>,
Oliver Neukum <oneukum@suse.com>
Cc: Alan Stern <stern@rowland.harvard.edu>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Colin Ian King <colin.king@canonical.com>,
Arnd Bergmann <arnd@arndb.de>,
USB list <linux-usb@vger.kernel.org>,
syzbot <syzbot+854768b99f19e89d7f81@syzkaller.appspotmail.com>,
syzkaller-bugs <syzkaller-bugs@googlegroups.com>
Subject: Re: [PATCH] USB: cdc-wdm: Call wake_up_all() when clearing WDM_IN_USE bit.
Date: Tue, 23 Jun 2020 20:20:08 +0900 [thread overview]
Message-ID: <c85331fc-874c-6e46-a77f-0ef1dc075308@i-love.sakura.ne.jp> (raw)
In-Reply-To: <CAAeHK+w+wBNksK_wpczad3AU4oLQRsjL_5G8p1R55Zh_FLhprg@mail.gmail.com>
On 2020/06/19 22:56, Andrey Konovalov wrote:
> Oliver, any chance you could help us with fixing the hang in this
> driver? You seem to be its original author. This hang is one of the
> top crashers on syzbot, with over 32000 crashed kernels.
>
Yes, I think that wdm_flush() has another bug and wdm_write() has yet another bug.
I need the authors' comments.
wdm_flush() says
/* cannot dereference desc->intf if WDM_DISCONNECTING */
if (test_bit(WDM_DISCONNECTING, &desc->flags))
return -ENODEV;
if (desc->werr < 0)
dev_err(&desc->intf->dev, "Error in flush path: %d\n",
desc->werr);
but it seems to me that nothing guarantees that test_bit(WDM_DISCONNECTING) == false
indicates dereferencing desc->intf->dev is safe, for wdm_flush() tests WDM_DISCONNECTING
without any lock whereas wdm_disconnect() sets WDM_DISCONNECTING under wdm_mutex and
desc->iuspin held. It might be safe to dereference from wdm_release() which holds wdm_mutex.
Also, if wait_event() in wdm_flush() might fail to wake up (due to close() dependency
problem this crash report is focusing on), wait_event_interruptible() in wdm_write() might
also fail to wake up (unless interrupted) due to the same dependency. Then, why can't we
wait for completion of wdm_out_callback() (with reasonable timeout) inside wdm_write() ?
I feel that wdm_flush() is so bogus (which could/should be removed).
next prev parent reply other threads:[~2020-06-23 11:20 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-20 23:31 [PATCH] USB: cdc-wdm: Call wake_up_all() when clearing WDM_IN_USE bit Tetsuo Handa
2020-05-21 7:33 ` Greg KH
2020-05-21 10:01 ` Tetsuo Handa
2020-05-21 19:50 ` Oliver Neukum
2020-05-21 22:48 ` Tetsuo Handa
2020-05-22 8:04 ` Oliver Neukum
2020-05-22 8:26 ` Tetsuo Handa
2020-05-25 12:06 ` Oliver Neukum
2020-05-25 13:32 ` Tetsuo Handa
2020-05-27 4:47 ` Tetsuo Handa
2020-05-28 15:18 ` Andrey Konovalov
2020-05-28 16:03 ` Tetsuo Handa
2020-05-28 19:03 ` Andrey Konovalov
2020-05-28 19:40 ` Alan Stern
2020-05-28 19:51 ` Andrey Konovalov
2020-05-28 20:58 ` Alan Stern
2020-05-29 20:41 ` Andrey Konovalov
2020-05-30 0:42 ` Tetsuo Handa
2020-05-30 1:10 ` Alan Stern
2020-05-30 4:58 ` Tetsuo Handa
2020-06-24 11:57 ` Oliver Neukum
2020-06-24 12:48 ` Tetsuo Handa
2020-05-30 6:08 ` Greg Kroah-Hartman
2020-06-01 12:26 ` Andrey Konovalov
2020-05-30 15:25 ` Oliver Neukum
2020-05-30 15:47 ` Alan Stern
2020-06-08 2:24 ` Tetsuo Handa
2020-06-18 0:48 ` Tetsuo Handa
2020-06-19 13:56 ` Andrey Konovalov
2020-06-23 11:20 ` Tetsuo Handa [this message]
2020-07-02 5:44 ` Tetsuo Handa
2020-07-02 7:24 ` Oliver Neukum
2020-07-15 6:15 ` Tetsuo Handa
2020-08-10 10:47 ` Tetsuo Handa
2020-09-24 15:09 ` [PATCH] USB: cdc-wdm: Make wdm_flush() interruptible and add wdm_fsync() Tetsuo Handa
2020-09-28 14:17 ` [PATCH (repost)] " Tetsuo Handa
2020-06-25 9:56 ` [PATCH] USB: cdc-wdm: Call wake_up_all() when clearing WDM_IN_USE bit Oliver Neukum
2020-06-25 11:15 ` Tetsuo Handa
2020-07-01 7:08 ` [TEST]Re: " 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=c85331fc-874c-6e46-a77f-0ef1dc075308@i-love.sakura.ne.jp \
--to=penguin-kernel@i-love.sakura.ne.jp \
--cc=andreyknvl@google.com \
--cc=arnd@arndb.de \
--cc=colin.king@canonical.com \
--cc=gregkh@linuxfoundation.org \
--cc=linux-usb@vger.kernel.org \
--cc=oneukum@suse.com \
--cc=stern@rowland.harvard.edu \
--cc=syzbot+854768b99f19e89d7f81@syzkaller.appspotmail.com \
--cc=syzkaller-bugs@googlegroups.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).