From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751892AbdJPHu5 (ORCPT ); Mon, 16 Oct 2017 03:50:57 -0400 Received: from mail.linuxfoundation.org ([140.211.169.12]:48920 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751284AbdJPHu4 (ORCPT ); Mon, 16 Oct 2017 03:50:56 -0400 Date: Mon, 16 Oct 2017 09:51:03 +0200 From: Greg Kroah-Hartman To: Tyler Hall Cc: Linux Kernel Mailing List , Nicolai Stange , Johannes Berg , "Paul E.McKenney" Subject: Re: deadlock in debugfs synchronize_srcu() when unplugging USB Message-ID: <20171016075103.GC3044@kroah.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.1 (2017-09-22) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Oct 12, 2017 at 04:01:48PM -0400, Tyler Hall wrote: > Hi, > > I have a reproducible scenario wherein removing a USB device while > reading /sys/kernel/debug/usb/devices causes a deadlock. This should > not be specific to any USB device. Any USB device removal that causes > a call to debugfs_remove() has inverted lock ordering with respect to > the read() of debug/usb/devices. > > e.g. > read thread: srcu_read_lock(&debugfs_srcu); > -- usb unplug -- > remove thread: mutex_lock(&usb_bus_idr_lock); > remove thread: synchronize_srcu(&debugfs_srcu); <- blocked > read thread: mutex_lock(&usb_bus_idr_lock); <- blocked > read thread: srcu_read_unlock(&debugfs_srcu, ...); > > This seems to be another flavor of what Johannes Berg reported: > deadlock in synchronize_srcu() in debugfs? > https://lkml.org/lkml/2017/3/23/415 > > I applied this patch set from Nicolai Stange and can no longer > reproduce the hang. > [RFC PATCH v2 0/9] debugfs: per-file removal protection > https://lkml.org/lkml/2017/5/3/292 > > As patch 2/9 in the series indicates, commit 49d200deaa68 ("debugfs: > prevent access to removed files' private data") is where this was > first introduced, and it is reproducible on v4.14-rc4. > > How should we move forward with the resolution of this debugfs change? > It seems to me that the USB locking is reasonable but the debugfs > global srcu is overly restrictive. This could lead to unexpected lock > inversion any time a driver shares a mutex between its debugfs read > and removal paths. As Paul stated, fixing up the patches and sending them in is the best solution, can you help out with that? thanks, greg k-h