On Sun, Oct 30, 2016 at 03:50:48PM +0100, Yves-Alexis Perez wrote:
> From: Yves-Alexis Perez <cor...@debian.org>
>
> 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.
Please amend the commit log as I noted in the previous response, and
resend.
> Signed-off-by: Yves-Alexis Perez <cor...@corsac.net>
> Cc: Ming Lei <ming....@canonical.com>
> Cc: "Luis R. Rodriguez" <mcg...@kernel.org>
> Cc: Greg Kroah-Hartman <gre...@linuxfoundation.org>
Other than the commit log you can add on you resend:
Acked-by: Luis R. Rodriguez.
Modulo I don't personally thing this this is sable material but I'll let
Greg decide.
Luis
> Cc: sta...@vger.kernel.org
>
> ---
> drivers/base/firmware_class.c | 7 ++++---
> 1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/base/firmware_class.c b/drivers/base/firmware_class.c
> index 22d1760..a95e1e5 100644
> --- a/drivers/base/firmware_class.c
> +++ b/drivers/base/firmware_class.c
> @@ -955,13 +955,14 @@ static int _request_firmware_load(struct firmware_priv
> *fw_priv,
> timeout = MAX_JIFFY_OFFSET;
> }
>
> - retval = wait_for_completion_interruptible_timeout(&buf->completion,
> + timeout = wait_for_completion_interruptible_timeout(&buf->completion,
> timeout);
> - if (retval == -ERESTARTSYS || !retval) {
> + if (timeout == -ERESTARTSYS || !timeout) {
> + retval = timeout;
> mutex_lock(&fw_lock);
> fw_load_abort(fw_priv);
> mutex_unlock(&fw_lock);
> - } else if (retval > 0) {
> + } else if (timeout > 0) {
> retval = 0;
> }
>
> --
> 2.10.1
>
>
--
Luis Rodriguez, SUSE LINUX GmbH
Maxfeldstrasse 5; D-90409 Nuernberg
