lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Tue,  6 Sep 2016 17:42:10 -0700
From:   "Luis R. Rodriguez" <mcgrof@...nel.org>
To:     ming.lei@...onical.com, akpm@...ux-foundation.org,
        gregkh@...uxfoundation.org
Cc:     daniel.wagner@...-carit.de, mmarek@...e.com,
        linux-kernel@...r.kernel.org, markivx@...eaurora.org,
        stephen.boyd@...aro.org, zohar@...ux.vnet.ibm.com,
        broonie@...nel.org, tiwai@...e.de, johannes@...solutions.net,
        chunkeey@...glemail.com, hauke@...ke-m.de,
        jwboyer@...oraproject.org, dmitry.torokhov@...il.com,
        dwmw2@...radead.org, jslaby@...e.com,
        torvalds@...ux-foundation.org, luto@...capital.net,
        fengguang.wu@...el.com, rpurdie@...ys.net,
        j.anaszewski@...sung.com, Abhay_Salunke@...l.com,
        Julia.Lawall@...6.fr, Gilles.Muller@...6.fr, nicolas.palix@...g.fr,
        teg@...m.no, dhowells@...hat.com, bjorn.andersson@...aro.org,
        arend.vanspriel@...adcom.com, kvalo@...eaurora.org,
        "Luis R. Rodriguez" <mcgrof@...nel.org>
Subject: [PATCH v4 5/5] firmware: fix fw cache to avoid usermode helper on suspend

The firmware cache purposely kills all non-udev (usermode helper)
pending requests prior to suspend with kill_requests_without_uevent()
right before it calls out to request for firmware for the fw cache.
It is pointless to again run into the possible issue of queing up
further usermode helpers during suspend, furthermore its actually
buggy to have required the usermode helper in some cases where
clearly the driver originally had not wanted that. Fix this by
simply using the direct call.

This doesn't fix any known bug however if it should be an optimization
for suspend/resume. While at it extend documentation to ensure folks of
the usermode helper are aware that they must cache the firmware on their
own for suspend / resume.

v3: patch introduced in this series

v4: as per Daniel Wagner since we're removing the usermode helper
    caller on the cache we can remove the timeout resetting on the
    cache code now as its is pointless.

Signed-off-by: Luis R. Rodriguez <mcgrof@...nel.org>
---
 Documentation/firmware_class/README |  3 +++
 drivers/base/firmware_class.c       | 16 +---------------
 2 files changed, 4 insertions(+), 15 deletions(-)

diff --git a/Documentation/firmware_class/README b/Documentation/firmware_class/README
index 9f8b2daf4c7c..173234005f33 100644
--- a/Documentation/firmware_class/README
+++ b/Documentation/firmware_class/README
@@ -174,3 +174,6 @@ $ make coccicheck MODE=report
  resume callback, and callers needn't cache the firmware by
  themselves any more for dealing with firmware loss during system
  resume.
+
+The firmware cache is only for non-user mode helper users. Drivers that
+require the usermode helper must deal with caching on their own.
diff --git a/drivers/base/firmware_class.c b/drivers/base/firmware_class.c
index 22d1760a4278..960f8f7c7aa2 100644
--- a/drivers/base/firmware_class.c
+++ b/drivers/base/firmware_class.c
@@ -1412,7 +1412,7 @@ static int cache_firmware(const char *fw_name)
 
 	pr_debug("%s: %s\n", __func__, fw_name);
 
-	ret = request_firmware(&fw, fw_name, NULL);
+	ret = request_firmware_direct(&fw, fw_name, NULL);
 	if (!ret)
 		kfree(fw);
 
@@ -1622,7 +1622,6 @@ static void __device_uncache_fw_images(void)
 static void device_cache_fw_images(void)
 {
 	struct firmware_cache *fwc = &fw_cache;
-	int old_timeout;
 	DEFINE_WAIT(wait);
 
 	pr_debug("%s\n", __func__);
@@ -1630,17 +1629,6 @@ static void device_cache_fw_images(void)
 	/* cancel uncache work */
 	cancel_delayed_work_sync(&fwc->work);
 
-	/*
-	 * use small loading timeout for caching devices' firmware
-	 * because all these firmware images have been loaded
-	 * successfully at lease once, also system is ready for
-	 * completing firmware loading now. The maximum size of
-	 * firmware in current distributions is about 2M bytes,
-	 * so 10 secs should be enough.
-	 */
-	old_timeout = loading_timeout;
-	loading_timeout = 10;
-
 	mutex_lock(&fw_lock);
 	fwc->state = FW_LOADER_START_CACHE;
 	dpm_for_each_dev(NULL, dev_cache_fw_image);
@@ -1648,8 +1636,6 @@ static void device_cache_fw_images(void)
 
 	/* wait for completion of caching firmware for all devices */
 	async_synchronize_full_domain(&fw_cache_domain);
-
-	loading_timeout = old_timeout;
 }
 
 /**
-- 
2.9.2

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ