At Wed, 08 May 2013 18:21:11 +0200, Takashi Iwai wrote: > > At Wed, 8 May 2013 23:52:02 +0800, > Ming Lei wrote: > > > > On Wed, May 8, 2013 at 2:56 PM, Takashi Iwai <ti...@suse.de> wrote: > > > When a firmware file can be loaded directly, there is no good reason > > > to lock usermodehelper. It's needed only when the direct fw load > > > fails and falls back to the user-mode helper. > > > > I remembered that we discussed the problem before, :-) > > > > Some crazy drivers might call request_firmware inside resume callback > > (for example, USB devices might be rebind in resume), with > > usermodehelper_read_lock, we can find the mistake easily and log it. > > > > I am wondering if it is good to remove the usermodehelper lock. > > > > Could you let us know any benefit to do it? > > Well, the question is whether usermodehelper lock is really an > appropriate stuff for *checking* the availability of direct fs > access. I find it doesn't fit well any longer, in the situation where > no actual user-space call is needed. Though, I'm not quite sure which > lock or flag can be used instead...
In other words, the first patch is no essential part of the fix. I can revisit the second patch without this one and resend if preferred. Takashi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
