From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.1 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE, SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 1B25BC43465 for ; Sat, 19 Sep 2020 13:53:14 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 33FC623447 for ; Sat, 19 Sep 2020 13:53:13 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726437AbgISNxL (ORCPT ); Sat, 19 Sep 2020 09:53:11 -0400 Received: from aibo.runbox.com ([91.220.196.211]:46090 "EHLO aibo.runbox.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726159AbgISNxL (ORCPT ); Sat, 19 Sep 2020 09:53:11 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=runbox.com; s=selector2; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: MIME-Version:Date:Message-ID:References:Cc:To:Subject:From; bh=x4PvldqpBh6r5oG1qvZNgwCA+P5SnAhYQfcqcPXTvb0=; b=ODqOnMPPHj2lewdreRBtovUFB4 /bj0uxyny/sbG5NruPIuFgfYGERTUPpcBpk1dEvIpqzWhwPROTNvkMG7Yd3BuTr7p2qKEcu9g8+M0 HVHa8JHLb3QUtOlYqQ3RJbSaZ4+CgTUDAsV/km4S9pX0YYt/BmSpEfun+mwEPiNV2JnkqcJb6k3iM 4oGxuvYQ7nUV5+bT0y8+YFodCFS+2Jl6NQ8dqr9WoOAFaFAcNuU4oA9iNpwCc7Yuvq8VHMjVzW0dN bojm1QYc3sK5n+ocGVqMsOEvBYzRfq9pA5xcFBpwglmJ7LlKozwe0CEb8mlJCy5AlDdMSqVOXqxI4 rrAJOOzg==; Received: from [10.9.9.74] (helo=submission03.runbox) by mailtransmit03.runbox with esmtp (Exim 4.86_2) (envelope-from ) id 1kJdIY-0006kP-Mu; Sat, 19 Sep 2020 15:53:06 +0200 Received: by submission03.runbox with esmtpsa [Authenticated alias (536975)] (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) id 1kJdIJ-0000zW-PL; Sat, 19 Sep 2020 15:52:51 +0200 From: "M. Vefa Bicakci" Subject: Re: [PATCH 1/3] usbcore/driver: Fix specific driver selection To: Alan Stern Cc: linux-usb@vger.kernel.org, Andrey Konovalov , stable@vger.kernel.org, Greg Kroah-Hartman , Bastien Nocera , syzkaller@googlegroups.com, Shuah Khan References: <20200917144151.355848-1-m.v.b@runbox.com> <363eab9a-c32a-4c60-4d6b-14ae8d873c52@runbox.com> <20200918145231.GA1130146@rowland.harvard.edu> Message-ID: <50d2232f-cb08-5881-828d-cb9e465d5d05@runbox.com> Date: Sat, 19 Sep 2020 16:52:48 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 MIME-Version: 1.0 In-Reply-To: <20200918145231.GA1130146@rowland.harvard.edu> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-CA Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-usb@vger.kernel.org On 18/09/2020 17.52, Alan Stern wrote: > 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 Thanks for the feedback, Alan! Given Shuah's answer to my other question, it looks like there is a need for further work. Vefa