All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Luis R. Rodriguez" <mcgrof@kernel.org>
To: cantabile.desu@gmail.com
Cc: kubakici@wp.pl, gregkh@linuxfoundation.org,
	akpm@linux-foundation.org, linux-wireless@vger.kernel.org,
	keescook@chromium.org, shuah@kernel.org, mfuzzey@parkeon.com,
	zohar@linux.vnet.ibm.com, dhowells@redhat.com,
	pali.rohar@gmail.com, tiwai@suse.de,
	arend.vanspriel@broadcom.com, zajec5@gmail.com, nbroeking@me.com,
	markivx@codeaurora.org, stephen.boyd@linaro.org,
	broonie@kernel.org, dmitry.torokhov@gmail.com,
	dwmw2@infradead.org, torvalds@linux-foundation.org,
	Abhay_Salunke@dell.com, bjorn.andersson@linaro.org,
	jewalt@lgsinnovations.com, oneukum@suse.com,
	linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org,
	"Luis R. Rodriguez" <mcgrof@kernel.org>
Subject: [RFT 2/7] firmware: fix checking for return values for fw_add_devm_name()
Date: Tue, 27 Feb 2018 15:20:56 -0800	[thread overview]
Message-ID: <20180227232101.20786-3-mcgrof@kernel.org> (raw)
In-Reply-To: <20180227232101.20786-1-mcgrof@kernel.org>

fw_add_devm_name() adds device's name onto the devres for the
device so that prior to suspend we cache the firmware onto memory,
so that on resume the firmware is reliably available. We never
were checking for success for this call though, meaning in some
really rare cases we my have never setup the firmware cache for
a device, which could in turn make resume fail.

This is all theoretical, no known issues have been reported.
This small issue has been present way since the addition of the
devres firmware cache names on v3.7.

Fixes: f531f05ae9437 ("firmware loader: store firmware name into devres list")
Signed-off-by: Luis R. Rodriguez <mcgrof@kernel.org>
---
 drivers/base/firmware_loader.c | 10 ++++++++--
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/drivers/base/firmware_loader.c b/drivers/base/firmware_loader.c
index 21dd31ef08ae..48932581c70c 100644
--- a/drivers/base/firmware_loader.c
+++ b/drivers/base/firmware_loader.c
@@ -431,6 +431,7 @@ int assign_fw(struct firmware *fw, struct device *device,
 	      unsigned int opt_flags)
 {
 	struct fw_priv *fw_priv = fw->priv;
+	int ret;
 
 	mutex_lock(&fw_lock);
 	if (!fw_priv->size || fw_state_is_aborted(fw_priv)) {
@@ -447,8 +448,13 @@ int assign_fw(struct firmware *fw, struct device *device,
 	 */
 	/* don't cache firmware handled without uevent */
 	if (device && (opt_flags & FW_OPT_UEVENT) &&
-	    !(opt_flags & FW_OPT_NOCACHE))
-		fw_add_devm_name(device, fw_priv->fw_name);
+	    !(opt_flags & FW_OPT_NOCACHE)) {
+		ret = fw_add_devm_name(device, fw_priv->fw_name);
+		if (ret && ret != 1) {
+			mutex_unlock(&fw_lock);
+			return ret;
+		}
+	}
 
 	/*
 	 * After caching firmware image is started, let it piggyback
-- 
2.16.2

  parent reply	other threads:[~2018-02-27 23:21 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-02-27 23:20 [RFT 0/7] firmware: enable caching of firmware for reboot optimization Luis R. Rodriguez
2018-02-27 23:20 ` [RFT 1/7] rename: _request_firmware_load() fw_load_sysfs_fallback() Luis R. Rodriguez
2018-02-27 23:28   ` Kees Cook
2018-02-28  1:21     ` Luis R. Rodriguez
2018-02-27 23:20 ` Luis R. Rodriguez [this message]
2018-02-27 23:29   ` [RFT 2/7] firmware: fix checking for return values for fw_add_devm_name() Kees Cook
2018-02-28  1:19     ` Luis R. Rodriguez
2018-02-27 23:20 ` [RFT 3/7] firmware: make fw_add_devm_name() return 0 if cache present Luis R. Rodriguez
2018-02-27 23:31   ` Kees Cook
2018-02-28  1:20     ` Luis R. Rodriguez
2018-02-27 23:20 ` [RFT 4/7] firmware: add helper to check to see if fw cache is setup Luis R. Rodriguez
2018-02-27 23:20 ` [RFT 5/7] firmware: ensure the firmware cache is not used on incompatible calls Luis R. Rodriguez
2018-02-27 23:21 ` [RFT 6/7] firmware: add request_firmware_cache() to help with cache on reboot Luis R. Rodriguez
2018-02-27 23:21 ` [RFT 7/7] mt7601u: use request_firmware_cache() to address " Luis R. Rodriguez
2018-02-28 18:03 ` [RFT 0/7] firmware: enable caching of firmware for reboot optimization cantabile
2018-02-28 18:45   ` Luis R. Rodriguez
2018-02-28 21:18     ` cantabile

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180227232101.20786-3-mcgrof@kernel.org \
    --to=mcgrof@kernel.org \
    --cc=Abhay_Salunke@dell.com \
    --cc=akpm@linux-foundation.org \
    --cc=arend.vanspriel@broadcom.com \
    --cc=bjorn.andersson@linaro.org \
    --cc=broonie@kernel.org \
    --cc=cantabile.desu@gmail.com \
    --cc=dhowells@redhat.com \
    --cc=dmitry.torokhov@gmail.com \
    --cc=dwmw2@infradead.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=jewalt@lgsinnovations.com \
    --cc=keescook@chromium.org \
    --cc=kubakici@wp.pl \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-wireless@vger.kernel.org \
    --cc=markivx@codeaurora.org \
    --cc=mfuzzey@parkeon.com \
    --cc=nbroeking@me.com \
    --cc=oneukum@suse.com \
    --cc=pali.rohar@gmail.com \
    --cc=shuah@kernel.org \
    --cc=stephen.boyd@linaro.org \
    --cc=tiwai@suse.de \
    --cc=torvalds@linux-foundation.org \
    --cc=zajec5@gmail.com \
    --cc=zohar@linux.vnet.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.