From: Alan Stern <stern@rowland.harvard.edu>
To: "M. Vefa Bicakci" <m.v.b@runbox.com>
Cc: linux-usb@vger.kernel.org,
Andrey Konovalov <andreyknvl@google.com>,
stable@vger.kernel.org,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Bastien Nocera <hadess@hadess.net>,
syzkaller@googlegroups.com,
Shuah Khan <skhan@linuxfoundation.org>
Subject: Re: [PATCH 1/3] usbcore/driver: Fix specific driver selection
Date: Fri, 18 Sep 2020 10:52:31 -0400 [thread overview]
Message-ID: <20200918145231.GA1130146@rowland.harvard.edu> (raw)
In-Reply-To: <363eab9a-c32a-4c60-4d6b-14ae8d873c52@runbox.com>
On Fri, Sep 18, 2020 at 05:31:26PM +0300, M. Vefa Bicakci wrote:
> Hello all,
>
> I noticed that applying this patch on its own to the kernel causes the following
> unexpected behaviour: As soon as the usbip_host module is loaded, all of the
> USB devices are re-probed() by their drivers, and this causes the USB devices
> connected to my system to be momentarily unavailable. This happens because
> *without* the third patch in this patch set, the match function for the usbip_host
> device driver unconditionally returns true.
>
> The third patch in this patch set [1] makes this unexpected behaviour go
> away, as it makes the usbip device driver's match function only match devices
> that were requested by user-space to be used with USB-IP.
>
> Is this something to be concerned about? I was thinking of people who might be
> using git-bisect, who might encounter this issue in an unexpected manner.
>
> As a potential solution, I can prepare another patch to revert commit
> 7a2f2974f2 ("usbip: Implement a match function to fix usbip") so that this
> unexpected behaviour will not be observed. This revert would be placed as
> the first patch in the patch series.
Yes, that sounds like a good solution.
Alan Stern
next prev parent reply other threads:[~2020-09-18 14:52 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-16 13:33 USB driver ID matching broken Andrey Konovalov
2020-09-16 14:15 ` Greg Kroah-Hartman
2020-09-16 14:39 ` Bastien Nocera
2020-09-16 15:58 ` M. Vefa Bicakci
2020-09-17 9:59 ` [PATCH 1/2] usbcore/driver: Fix specific driver selection M. Vefa Bicakci
2020-09-17 9:59 ` [PATCH 2/2] usbip: Make the driver's match function specific M. Vefa Bicakci
2020-09-17 10:23 ` [PATCH 1/2] usbcore/driver: Fix specific driver selection Bastien Nocera
2020-09-17 10:39 ` M. Vefa Bicakci
2020-09-17 10:49 ` Bastien Nocera
2020-09-17 14:41 ` [PATCH 1/3] " M. Vefa Bicakci
2020-09-17 14:41 ` [PATCH 2/3] usbcore/driver: Fix incorrect downcast M. Vefa Bicakci
2020-09-17 15:01 ` Alan Stern
2020-09-18 9:26 ` M. Vefa Bicakci
2020-09-17 14:41 ` [PATCH 3/3] usbip: Make the driver's match function specific M. Vefa Bicakci
2020-09-17 15:21 ` Shuah Khan
2020-09-18 9:26 ` M. Vefa Bicakci
2020-09-18 14:31 ` M. Vefa Bicakci
2020-09-18 15:49 ` Shuah Khan
2020-09-19 13:54 ` M. Vefa Bicakci
2020-09-21 17:03 ` M. Vefa Bicakci
2020-09-18 14:31 ` [PATCH 1/3] usbcore/driver: Fix specific driver selection M. Vefa Bicakci
2020-09-18 14:52 ` Alan Stern [this message]
2020-09-19 13:52 ` M. Vefa Bicakci
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=20200918145231.GA1130146@rowland.harvard.edu \
--to=stern@rowland.harvard.edu \
--cc=andreyknvl@google.com \
--cc=gregkh@linuxfoundation.org \
--cc=hadess@hadess.net \
--cc=linux-usb@vger.kernel.org \
--cc=m.v.b@runbox.com \
--cc=skhan@linuxfoundation.org \
--cc=stable@vger.kernel.org \
--cc=syzkaller@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 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.