Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1387134
| From | Mario Limonciello <mario_limonciello@dell.com> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | [PATCH 1/1] firmware: correct test of wait_for_completion_interruptible_timeout return |
| Date | 2016-04-26 07:10 +0200 |
| Message-ID | <rs3q1-1Sc-5@gated-at.bofh.it> (permalink) |
| Organization | linux.* mail to news gateway |
Before this commit both code paths (hotplug and not-hotplug as determined
by FW_OPT_UEVENT) would block on an interruptible completion, but the
hotplugscenario also would wait until timeout and then abort. The non
hotplugscenario (which dell-rbu followed) would block indefinitely until
interrupted.
After this commit both scenarios block on an interruptible condition but
the hotplug scenario follows the value of firmware_loading_timeout to end.
This changed the situation for the non hotplug scenario to instead wait
for MAX_JIFFY_OFFSET. This should have the same result, but dell-rbu was
failing with negative values returned from
wait_for_completion_interruptible_timeout after completion occurred.
This shouldn't be possible, but it was happening because the return is a
long but the value it was being saved to was an int. When completion
occurs quickly wait_for_completion_interruptible_timeout returns how much
time was left (which happens to be a very big number since the timeout was
MAX_JIFFY_OFFSET) One test run of mine returned 4611686018427368747.
Other parts of the kernel with this type of return don't have problems
because they use smaller timeouts.
So to fix this: change the test to not store the value to an int, but
rather directly compare against what
wait_for_completion_interruptible_timeout can return.
Fixes: 68ff2a00dbf59 (firmware_loader: handle timeout via wait_for_completion_interruptible_timeout())
CC: stable@vger.kernel.org
CC: stuart_hayes@dell.com
Signed-off-by: Mario Limonciello <mario_limonciello@dell.com>
---
drivers/base/firmware_class.c | 7 ++-----
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/drivers/base/firmware_class.c b/drivers/base/firmware_class.c
index 773fc30..223af70 100644
--- a/drivers/base/firmware_class.c
+++ b/drivers/base/firmware_class.c
@@ -917,14 +917,11 @@ static int _request_firmware_load(struct firmware_priv *fw_priv,
timeout = MAX_JIFFY_OFFSET;
}
- retval = wait_for_completion_interruptible_timeout(&buf->completion,
- timeout);
- if (retval == -ERESTARTSYS || !retval) {
+ if (wait_for_completion_interruptible_timeout(&buf->completion,
+ timeout) <= 0) {
mutex_lock(&fw_lock);
fw_load_abort(fw_priv);
mutex_unlock(&fw_lock);
- } else if (retval > 0) {
- retval = 0;
}
if (is_fw_load_aborted(buf))
--
2.7.4
Back to linux.kernel | Previous | Next — Next in thread | Find similar | Unroll thread
[PATCH 1/1] firmware: correct test of wait_for_completion_interruptible_timeout return Mario Limonciello <mario_limonciello@dell.com> - 2016-04-26 07:10 +0200 Re: [PATCH 1/1] firmware: correct test of wait_for_completion_interruptible_timeout return Ming Lei <ming.lei@canonical.com> - 2016-04-26 13:30 +0200
csiph-web