Re: [PATCH 1/1] firmware: correct test of wait_for_completion_interruptible_timeout return

[Ming Lei]

On Tue, Apr 26, 2016 at 12:57 PM, Mario Limonciello
 wrote:
> 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: sta...@vger.kernel.org
> CC: stuart_ha...@dell.com
> Signed-off-by: Mario Limonciello 
> ---
>  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(>completion,
> -   timeout);
> -   if (retval == -ERESTARTSYS || !retval) {
> +   if (wait_for_completion_interruptible_timeout(>completion,
> +   timeout) <= 0) {
> mutex_lock(_lock);
> fw_load_abort(fw_priv);
> mutex_unlock(_lock);
> -   } else if (retval > 0) {
> -   retval = 0;
> }

Good catch, thanks!

Acked-by: Ming Lei 

>
> if (is_fw_load_aborted(buf))
> --
> 2.7.4
>

Re: [PATCH 1/1] firmware: correct test of wait_for_completion_interruptible_timeout return

[Ming Lei]

On Tue, Apr 26, 2016 at 12:57 PM, Mario Limonciello
 wrote:
> 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: sta...@vger.kernel.org
> CC: stuart_ha...@dell.com
> Signed-off-by: Mario Limonciello 
> ---
>  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(>completion,
> -   timeout);
> -   if (retval == -ERESTARTSYS || !retval) {
> +   if (wait_for_completion_interruptible_timeout(>completion,
> +   timeout) <= 0) {
> mutex_lock(_lock);
> fw_load_abort(fw_priv);
> mutex_unlock(_lock);
> -   } else if (retval > 0) {
> -   retval = 0;
> }

Good catch, thanks!

Acked-by: Ming Lei 

>
> if (is_fw_load_aborted(buf))
> --
> 2.7.4
>

[PATCH 1/1] firmware: correct test of wait_for_completion_interruptible_timeout return

[Mario Limonciello]

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: sta...@vger.kernel.org
CC: stuart_ha...@dell.com
Signed-off-by: Mario Limonciello 
---
 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(>completion,
-   timeout);
-   if (retval == -ERESTARTSYS || !retval) {
+   if (wait_for_completion_interruptible_timeout(>completion,
+   timeout) <= 0) {
mutex_lock(_lock);
fw_load_abort(fw_priv);
mutex_unlock(_lock);
-   } else if (retval > 0) {
-   retval = 0;
}
 
if (is_fw_load_aborted(buf))
-- 
2.7.4

[PATCH 1/1] firmware: correct test of wait_for_completion_interruptible_timeout return

[Mario Limonciello]

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: sta...@vger.kernel.org
CC: stuart_ha...@dell.com
Signed-off-by: Mario Limonciello 
---
 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(>completion,
-   timeout);
-   if (retval == -ERESTARTSYS || !retval) {
+   if (wait_for_completion_interruptible_timeout(>completion,
+   timeout) <= 0) {
mutex_lock(_lock);
fw_load_abort(fw_priv);
mutex_unlock(_lock);
-   } else if (retval > 0) {
-   retval = 0;
}
 
if (is_fw_load_aborted(buf))
-- 
2.7.4