Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Mon, 17 Dec 2018 11:21:55 -0500 (EST)
From:   Alan Stern <stern@rowland.harvard.edu>
To:     Andrew Worsley <amworsley@gmail.com>
cc:     Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        Mathias Nyman <mathias.nyman@linux.intel.com>,
        Nicolas Boichat <drinkcat@chromium.org>,
        Jon Flatley <jflat@chromium.org>,
        Kai-Heng Feng <kai.heng.feng@canonical.com>,
        Bin Liu <b-liu@ti.com>, Benson Leung <bleung@chromium.org>,
        "open list:USB SUBSYSTEM" <linux-usb@vger.kernel.org>,
        open list <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] Prevent race condition between USB authorisation and
 USB discovery events
In-Reply-To: <20181217061036.24143-1-amworsley@gmail.com>
Message-ID: <Pine.LNX.4.44L0.1812171114170.1630-100000@iolanthe.rowland.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Mon, 17 Dec 2018, Andrew Worsley wrote:

> A sysfs driven USB authorisation change can trigger a usb_set_configuration
> while a hub_event worker thread is running. This can result in a USB device
> being disabled just after it was configured and bringing down all the
> devices and impacting hardware and user processes that were established on
> top of this these interfaces. In some cases the USB disable never completed
> and the whole system hung.

Can you be more specific about this?  Disabling a USB device shouldn't
cause these kinds of problems, regardless of whether or not the device
was just configured.

> At my work I had an occasional hang due to this race condition. Roughly 1
> in 50 boots had the race occurrence and 1 in 4 of those resulted in a hang.
> This patch fixed the problem and I had no problems (spurious disables
> or hangs) in 750+ boots.

usb_authorize_device, usb_deauthorize_device, and hub_event all acquire 
the device mutex.  Why should adding another mutex make any difference?

In fact there's an actual disadvantage: Making hub_event acquire a
global mutex will prevent us from handling multiple hubs concurrently.  
Although we don't do this now, we might want to in the future.

Alan Stern