From: Yves-Alexis Perez <corsac@corsac.net>
To: linux-kernel@vger.kernel.org
Cc: Ming Lei <ming.lei@canonical.com>,
"Luis R. Rodriguez" <mcgrof@kernel.org>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
stable@vger.kernel.org
Subject: Re: [PATCH] firmware: fix async/manual firmware loading
Date: Sun, 30 Oct 2016 18:28:58 +0100 [thread overview]
Message-ID: <1477848538.3456.1.camel@corsac.net> (raw)
In-Reply-To: <20161030145048.6291-2-corsac@corsac.net>
[-- Attachment #1: Type: text/plain, Size: 2872 bytes --]
On Sun, 2016-10-30 at 15:50 +0100, Yves-Alexis Perez wrote:
> wait_for_completion_interruptible_timeout() return value is either
> -ERESTARTSYS (in case it was interrupted), 0 (in case the timeout expired)
> or the number of jiffies left until timeout. The return value is stored in
> a long, but in _request_firmware_load() it's silently casted to an int,
> which can overflow and give a negative value, indicating an error.
>
> Fix this by re-using the timeout variable and only set retval when it's
> safe.
I completely messed-up my git send-email (sorry), so the cover letter only
went to LKML and I assume nobody read it. So just in case, I'm pasting it
below because it gives some more explanation about how I tested this:
when trying to (ab)use the firmware loading interface in a local kernel module
(in order to load the EEPROM content into a PCIE card), I noticed that the
manual firmware loading interface (the one from
/sys/class/firmware/<foo>/{loading,data}) was broken.
After instrumenting the kernel I noticed an issue with the way
wait_for_completion_interruptible_timeout() is called in _request_firmware()
and especially how the return value is handled: it's supposed to be a long, but
here it's silently casted to an int and tested if positive. The initial timeout
seems to be LONG_MAX (since it's a manual firmware loading you're supposed to
have all the time you want to do it), so the return value overflows the int.
Attached patch fixes the problem here, although there might be a better way. I
tested it using lib/test_firmware.c kernel module, with the following patch to
enable manual loading:
diff --git a/lib/test_firmware.c b/lib/test_firmware.c
index a3e8ec3..01d333c 100644
--- a/lib/test_firmware.c
+++ b/lib/test_firmware.c
@@ -105,7 +105,7 @@ static ssize_t trigger_async_request_store(struct device *dev,
mutex_lock(&test_fw_mutex);
release_firmware(test_firmware);
test_firmware = NULL;
- rc = request_firmware_nowait(THIS_MODULE, 1, name, dev, GFP_KERNEL,
+ rc = request_firmware_nowait(THIS_MODULE, 0, name, dev, GFP_KERNEL,
NULL, trigger_async_request_cb);
if (rc) {
pr_info("async load of '%s' failed: %d\n", name, rc);
Then load test_firmware and:
# echo -n test > /sys/devices/virtual/misc/test_firmware/trigger_async_request
In another terminal, do:
# echo -n 1 > /sys/class/firmware/test/loading
# echo -n data > /sys/class/firmware/test/data
# echo -n 0 > /sys/class/firmware/test/loading
Without the patch, the loading fails right after the "echo -n 0", with it the loading succeeds with:
[ 96.405171] test_firmware: loaded: 4
Regards,
--
Yves-Alexis
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 455 bytes --]
next prev parent reply other threads:[~2016-10-30 17:29 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20161030145048.6291-1-corsac@corsac.net>
2016-10-30 14:50 ` [PATCH] firmware: fix async/manual firmware loading Yves-Alexis Perez
2016-10-30 17:28 ` Yves-Alexis Perez [this message]
2016-11-09 20:36 ` Luis R. Rodriguez
2016-11-09 22:02 ` Luis R. Rodriguez
2016-11-10 6:57 ` Yves-Alexis Perez
2016-11-09 20:39 ` Luis R. Rodriguez
2016-11-10 15:55 ` Greg Kroah-Hartman
2016-11-10 16:07 ` Luis R. Rodriguez
2016-11-10 18:52 ` Bjorn Andersson
2016-11-10 19:48 ` Luis R. Rodriguez
2016-11-10 21:04 ` Yves-Alexis Perez
2016-11-10 21:22 ` Luis R. Rodriguez
2016-11-10 19:18 ` Greg Kroah-Hartman
2016-11-10 19:49 ` Luis R. Rodriguez
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=1477848538.3456.1.camel@corsac.net \
--to=corsac@corsac.net \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mcgrof@kernel.org \
--cc=ming.lei@canonical.com \
--cc=stable@vger.kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).