Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755370Ab2HZQEu (ORCPT ); Sun, 26 Aug 2012 12:04:50 -0400 Received: from gate.crashing.org ([63.228.1.57]:59692 "EHLO gate.crashing.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753295Ab2HZQEh (ORCPT ); Sun, 26 Aug 2012 12:04:37 -0400 Message-ID: <1345997040.5138.1.camel@pasglop> Subject: Re: udev 182: response timeout for request_firmware in module_probe path From: Benjamin Herrenschmidt To: Alan Cox Cc: Ming Lei , Kay Sievers , Linux Kernel Mailing List , Greg Kroah-Hartman , Johannes Berg , Larry Finger , Linus Torvalds , systemd-devel@lists.freedesktop.org Date: Mon, 27 Aug 2012 02:04:00 +1000 In-Reply-To: <20120823174613.0489837d@pyramind.ukuu.org.uk> References: <20120823174613.0489837d@pyramind.ukuu.org.uk> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.2.3-0ubuntu6 Content-Transfer-Encoding: 7bit Mime-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1082 Lines: 30 On Thu, 2012-08-23 at 17:46 +0100, Alan Cox wrote: > > IMO, the driver probing path is allowed to sleep, so looks request > firmware > > should be allowed inside .probe(). > > I'm not convinced about that. It can sleep but its holding various > locks > in most cases, and it looks like that can end up in a complete heap. > > By all means *request* the firmware asynchronously in the probe, but > there needs to be a seperate method somewhere after the probe to > finish > the job once the firmware appears. Not necessarily enough in the general case, for example some stacks will cause a driver open to be call back from somewhere within the register_foo() the driver did to register itself with it's subsystem inside probe. For example register_framebuffer(), register_netdev(), ... This is clearly a udev bug :-) Cheers, Ben. -- 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/