From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757360Ab2IDQKI (ORCPT ); Tue, 4 Sep 2012 12:10:08 -0400 Received: from cantor2.suse.de ([195.135.220.15]:39662 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752716Ab2IDQKG (ORCPT ); Tue, 4 Sep 2012 12:10:06 -0400 Date: Tue, 04 Sep 2012 18:10:03 +0200 Message-ID: From: Takashi Iwai To: Ming Lei Cc: Greg Kroah-Hartman , "Rafael J. Wysocki" , Kay Sievers , linux-kernel@vger.kernel.org Subject: Re: A workaround for request_firmware() stuck in module_init In-Reply-To: References: User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL/10.8 Emacs/24.1 (x86_64-suse-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org At Tue, 4 Sep 2012 23:52:15 +0800, Ming Lei wrote: > > On Tue, Sep 4, 2012 at 9:06 PM, Takashi Iwai wrote: > > Hi, > > > > as I've got recently a few bug reports regarding the stuck with > > request_firmware() in module_init of some sound drivers, I started > > looking at the issue. Strangely, the problem doesn't happen on > > openSUSE 12.2 although it has the same udev version with libkmod as > > Fedora. So I installed Fedora 17, and indeed I could see a problem > > there. > > It should be a bug in udev, as discussed in the below link: > > http://marc.info/?t=134552745100002&r=1&w=2 Yeah, if udev has a fix, I'm fine. I'll proactively ignore these bug reports. But did it really happen...? > > Obviously a solution would be to rewrite the driver code to use > > request_firmware_nowait() instead. But it'd need a lot of code > > shuffling, and most of such drivers are old stuff I don't want to do a > > serious surgery. > > > > So I tried an easier workaround by using the deferred probing. > > An experimental patch is below. As you can see, from the driver side, > > it's simple: just add two lines at the head of each probe function. > > In fact, the defer probe should only be applied in situations which > driver is built in kernel and request_firmware is called in .probe(). Is it? I thought the deferred probe is basically not for this problem but rather for the dependency problem with other modules. That's the reason it's triggered only upon the successful binding. And IMO, the deferred probe for the built-in kernel is also silly. Did anyone really make it working for built-in kernel driver and external firmware files? (For the resume, it's of course a different issue. And I guess it's been solved by your fw cache patch, right?) > > Do you think this kind of hack is OK? If not, any better (IOW easier) > > solution? > > Looks your solution is a bit complicated, and I have wrote a similar > patch to address the problem, but Linus thought that it may hide the > problem of drivers. > > http://marc.info/?t=134278790800004&r=1&w=2 > > IMO, driver core needn't to be changed, and the defer probe can be > supported just by changes in request_firmware() and its caller. Ideally, yes. But it won't work in some drivers like sound drivers, that have its own device number counting changed at each probe call. For such drivers, the deferred probe check must be done before entering the normal probe procedure, and returning -EPROBE_DEFER would be too late (or need more complex fallbacks). thanks, Takashi