Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757224Ab2EVOLn (ORCPT ); Tue, 22 May 2012 10:11:43 -0400 Received: from iolanthe.rowland.org ([192.131.102.54]:45983 "HELO iolanthe.rowland.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S1755444Ab2EVOLm (ORCPT ); Tue, 22 May 2012 10:11:42 -0400 Date: Tue, 22 May 2012 10:11:41 -0400 (EDT) From: Alan Stern X-X-Sender: stern@iolanthe.rowland.org To: Ming Lei cc: Greg KH , Wedson Almeida Filho , Andrew Morton , , Linux PM List Subject: =?UTF-8?Q?Re=3A_Race_condition_between_driver=5Fprobe=5Fdevice_and_d?= =?UTF-8?Q?evice=5Fshutdown=E2=80=8F?= In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=UTF-8 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1757 Lines: 45 On Tue, 22 May 2012, Ming Lei wrote: > On Tue, May 22, 2012 at 2:29 AM, Alan Stern wrote: > > On Mon, 21 May 2012, Ming Lei wrote: > >> Another candidate fix is to register a reboot notifier in driver core to prevent > >> driver from being bound or unbound from start of reboot/shutdown, but looks > >> not easy as the way of holding device locks. > > > > I'd guess it was done this way so that the shutdown task wouldn't have > > to wait for a buggy driver that didn't want to release the device lock > > (or that crashed while holding the lock). > > Maybe, so I understand you agree on adding the device lock as did > in the patch, don't I? I don't know. It depends on the intention behind the shutdown callback. Maybe each driver is supposed to be responsible for doing its own locking. Do you think that a buggy driver should be able to prevent the system from shutting down? > Also we can add below line before acquiring device lock to help > toubleshoot buggy driver. > > dev_dbg(dev, "acquiring device lock for shutdown\n"); > > > > > It's not clear that the reboot notifier approach would work. ?What > > about probes that had already started when notifier was called? > > Looks holding device lock is still needed in the notifier callback for > handling the case if reboot notifier approach is taken. > > IMO, the way of holding device lock is better than reboot notifier approach. Yes, it is better. The question is, is it right? Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/