From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754658AbcIIMMy (ORCPT ); Fri, 9 Sep 2016 08:12:54 -0400 Received: from atlantic540.startdedicated.de ([188.138.9.77]:58597 "EHLO atlantic540.startdedicated.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754584AbcIIMMv (ORCPT ); Fri, 9 Sep 2016 08:12:51 -0400 From: Daniel Wagner To: linux-kernel@vger.kernel.org Cc: Ming Lei , "Luis R . Rodriguez" , Greg Kroah-Hartman , "Srivatsa S . Bhat" , "Rafael J . Wysocki" , Daniel Vetter , Takashi Iwai , Bjorn Andersson , Arend van Spriel , Daniel Wagner Subject: [PATCH v5 1/5] firmware: document user mode helper lock usage Date: Fri, 9 Sep 2016 14:12:20 +0200 Message-Id: <1473423144-21734-2-git-send-email-wagi@monom.org> X-Mailer: git-send-email 2.7.4 In-Reply-To: <1473423144-21734-1-git-send-email-wagi@monom.org> References: <1473423144-21734-1-git-send-email-wagi@monom.org> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Daniel Wagner The lock is also used to generate warnings when a direct firmware load is requested too early. The usermodehelper locking code was added by b298d289c792 ("PM / Sleep: Fix freezer failures due to racy usermodehelper_is_disabled()"). As Luis points out: "Reviewing commit 247bc03742545 ("PM / Sleep: Mitigate race between the freezer and request_firmware()") which originally extended umh state machine from just being enabled/disabled, with the concepts of UMH_ENABLED, UMH_FREEZING, UMH_DISABLED -- its goal was to prevent UMH uses during suspend. So -- the "UMH lock" on firmware was actually added to help avoid races between freezing and request_firmware(). We should not re-use UMH status notifiers when the firmware UMH is disabled for the same concepts -- if we needed such a concept then we should take this out from UMH code and generalize it." After some discussion with Ming it was decided to put a comment to the code to document the usage of the umh and a TODO to resolve this by having some generic means to detect ongoing freezing operations. Cc: Ming Lei Cc: Luis R. Rodriguez Cc: Greg Kroah-Hartman Signed-off-by: Daniel Wagner --- drivers/base/firmware_class.c | 13 +++++++++++++ 1 file changed, 13 insertions(+) diff --git a/drivers/base/firmware_class.c b/drivers/base/firmware_class.c index 960f8f7..8eba1fb 100644 --- a/drivers/base/firmware_class.c +++ b/drivers/base/firmware_class.c @@ -1150,6 +1150,19 @@ _request_firmware(const struct firmware **firmware_p, const char *name, if (ret <= 0) /* error or already assigned */ goto out; + /* + * The usermode helper lock is taken to serialize the firmware + * loading even when no usermoder mode helper is used at all. + * + * Some drivers may not benefit from firmware loading cache + * when requesting loading in .resume(). In the situation of + * suspend vs. resume, it is still too early for direct + * loading. With UMH lock, we can get a warning or avoid the + * issue. + * + * TODO: Taking the UMH lock is a bit missleading and it makes + * sense to generalize this to a common freezer check. + */ ret = 0; timeout = firmware_loading_timeout(); if (opt_flags & FW_OPT_NOWAIT) { -- 2.7.4