Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751881Ab3EIHe2 (ORCPT ); Thu, 9 May 2013 03:34:28 -0400 Received: from cantor2.suse.de ([195.135.220.15]:33055 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750879Ab3EIHe1 (ORCPT ); Thu, 9 May 2013 03:34:27 -0400 Date: Thu, 09 May 2013 09:34:27 +0200 Message-ID: From: Takashi Iwai To: Ming Lei Cc: linux-kernel@vger.kernel.org, Greg Kroah-Hartman Subject: Re: [PATCH 2/3] firmware: Avoid deadlock of usermodehelper lock at shutdown In-Reply-To: References: <1367996197-32748-1-git-send-email-tiwai@suse.de> <1367996197-32748-3-git-send-email-tiwai@suse.de> 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.2 (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 Content-Length: 3241 Lines: 94 At Thu, 9 May 2013 09:19:47 +0800, Ming Lei wrote: > > On Thu, May 9, 2013 at 12:15 AM, Takashi Iwai wrote: > > At Wed, 8 May 2013 23:56:51 +0800, > > Ming Lei wrote: > >> > >> On Wed, May 8, 2013 at 2:56 PM, Takashi Iwai wrote: > >> > When a system goes to reboot/shutdown, it tries to disable the > >> > usermode helper via usermodehelper_disable(). This might be blocked > >> > when a driver tries to load a firmware beforehand and it's stuck by > >> > some reason. > >> > >> IMO, it is better to find why the loading is stuck. Also we already provides > >> the timeout sysfs file to help to deal with the situation. > > > > The loading is done manually in the case of dell_rbu driver, so it may > > happen at any time that the f/w loading doesn't finish properly. > > > > > >> > In this patch, the firmware class driver registers a reboot notifier > >> > so that it can abort all pending f/w bufs. Also enable a flag for > >> > avoiding the call of usermodehelper after the reboot/shutdown starts. > >> > >> With this patch, maybe we only hide the real problem. > > > > No, you can simulate the hang easily. Try the below (you can run it > > on every x86 machine; it just loads the data onto the memory.) > > > > - modprobe dell_rbu > > > > - echo init > /sys/devices/platform/dell_rbu/image_type > > > > (... now /sys/class/firmware/dell_rbu/* appear) > > > > - echo 1 > /sys/class/firmware/dell_rbu/loading > > > > - halt -p > > > > Now the machine gets stuck. > > > > Yes, the real problem is obvious: you didn't finish the f/w loading in > > the above, and it will never happen. This doesn't justify that the > > machine can be stalled at shutdown, though. > > OK, got it, thanks for your explanation, but anyway the stall is caused > by not concluding the load in userspace(we have document about it), > not by firmware loader itself. It's the firmware loader who blocks the usermodelock :) > I think there is no reason to disable the loading timeout for !event, could > you test the below patch to see if it may avoid the stall? Please test on your machine (e.g. on VM). I'm off today for a holiday. As mentioned, dell_rbu can run on every machine and it's harmless. thanks, Takashi > diff --git a/drivers/base/firmware_class.c b/drivers/base/firmware_class.c > index 4b1f926..caf399e 100644 > --- a/drivers/base/firmware_class.c > +++ b/drivers/base/firmware_class.c > @@ -848,11 +848,12 @@ static int _request_firmware_load(struct > firmware_priv *fw_priv, bool uevent, > goto err_del_bin_attr; > } > > + if (timeout != MAX_SCHEDULE_TIMEOUT) > + schedule_delayed_work(&fw_priv->timeout_work, timeout); > + > if (uevent) { > dev_set_uevent_suppress(f_dev, false); > dev_dbg(f_dev, "firmware: requesting %s\n", buf->fw_id); > - if (timeout != MAX_SCHEDULE_TIMEOUT) > - schedule_delayed_work(&fw_priv->timeout_work, timeout); > > kobject_uevent(&fw_priv->dev.kobj, KOBJ_ADD); > } > > > Thanks, > -- > Ming Lei > -- 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/