* [PATCH] firwmare: Correct handling of fw_state_wait() return value
@ 2016-12-07 1:01 Bjorn Andersson
2016-12-08 14:47 ` Daniel Wagner
0 siblings, 1 reply; 3+ messages in thread
From: Bjorn Andersson @ 2016-12-07 1:01 UTC (permalink / raw)
To: Ming Lei, Luis R. Rodriguez, Greg Kroah-Hartman
Cc: linux-kernel, linux-remoteproc
When request_firmware() finds an already open firmware object it will
wait for that object to become fully loaded and then check the status.
As __fw_state_wait_common() succeeds the timeout value returned will be
truncated in _request_firmware_prepare() and interpreted as -EPERM.
Prior to "firmware: do not use fw_lock for fw_state protection" the code
did test if we where in the "done" state before sleeping, causing this
particular code path to succeed, in some cases.
As the callers are interested in the result of the wait and not the
remaining timeout the return value of __fw_state_wait_common() is
changed to signal "done" or "error", which simplifies the logic in
_request_firmware_load() as well.
Fixes: 5b029624948d ("firmware: do not use fw_lock for fw_state protection")
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
---
The regression was introduced in next-20161201
drivers/base/firmware_class.c | 13 ++++++-------
1 file changed, 6 insertions(+), 7 deletions(-)
diff --git a/drivers/base/firmware_class.c b/drivers/base/firmware_class.c
index eb95cf7c3b28..4497d263209f 100644
--- a/drivers/base/firmware_class.c
+++ b/drivers/base/firmware_class.c
@@ -127,7 +127,7 @@ static inline bool __fw_state_is_done(enum fw_status status)
return status == FW_STATUS_DONE || status == FW_STATUS_ABORTED;
}
-static long __fw_state_wait_common(struct fw_state *fw_st, long timeout)
+static int __fw_state_wait_common(struct fw_state *fw_st, long timeout)
{
long ret;
@@ -136,8 +136,10 @@ static long __fw_state_wait_common(struct fw_state *fw_st, long timeout)
timeout);
if (ret != 0 && fw_st->status == FW_STATUS_ABORTED)
return -ENOENT;
+ if (!ret)
+ return -ETIMEDOUT;
- return ret;
+ return ret < 0 ? ret : 0;
}
static void __fw_state_set(struct fw_state *fw_st,
@@ -1017,14 +1019,11 @@ static int _request_firmware_load(struct firmware_priv *fw_priv,
timeout = MAX_JIFFY_OFFSET;
}
- timeout = fw_state_wait_timeout(&buf->fw_st, timeout);
- if (timeout == -ERESTARTSYS || !timeout) {
- retval = timeout;
+ retval = fw_state_wait_timeout(&buf->fw_st, timeout);
+ if (retval < 0) {
mutex_lock(&fw_lock);
fw_load_abort(fw_priv);
mutex_unlock(&fw_lock);
- } else if (timeout > 0) {
- retval = 0;
}
if (fw_state_is_aborted(&buf->fw_st))
--
2.5.0
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [PATCH] firwmare: Correct handling of fw_state_wait() return value
2016-12-07 1:01 [PATCH] firwmare: Correct handling of fw_state_wait() return value Bjorn Andersson
@ 2016-12-08 14:47 ` Daniel Wagner
2016-12-08 15:28 ` Luis R. Rodriguez
0 siblings, 1 reply; 3+ messages in thread
From: Daniel Wagner @ 2016-12-08 14:47 UTC (permalink / raw)
To: Bjorn Andersson, Ming Lei, Luis R. Rodriguez, Greg Kroah-Hartman
Cc: linux-kernel, linux-remoteproc
On 12/07/2016 02:01 AM, Bjorn Andersson wrote:
> When request_firmware() finds an already open firmware object it will
> wait for that object to become fully loaded and then check the status.
> As __fw_state_wait_common() succeeds the timeout value returned will be
> truncated in _request_firmware_prepare() and interpreted as -EPERM.
>
> Prior to "firmware: do not use fw_lock for fw_state protection" the code
> did test if we where in the "done" state before sleeping, causing this
> particular code path to succeed, in some cases.
>
> As the callers are interested in the result of the wait and not the
> remaining timeout the return value of __fw_state_wait_common() is
> changed to signal "done" or "error", which simplifies the logic in
> _request_firmware_load() as well.
Oops, sorry about that one. With your fix the code starts to make sense.
> Fixes: 5b029624948d ("firmware: do not use fw_lock for fw_state protection")
> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Reviewed-by: Daniel Wagner <daniel.wagner@bmw-carit.de>
Thanks,
Daniel
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [PATCH] firwmare: Correct handling of fw_state_wait() return value
2016-12-08 14:47 ` Daniel Wagner
@ 2016-12-08 15:28 ` Luis R. Rodriguez
0 siblings, 0 replies; 3+ messages in thread
From: Luis R. Rodriguez @ 2016-12-08 15:28 UTC (permalink / raw)
To: Daniel Wagner
Cc: Bjorn Andersson, Ming Lei, Luis R. Rodriguez, Greg Kroah-Hartman,
linux-kernel, linux-remoteproc
On Thu, Dec 08, 2016 at 03:47:22PM +0100, Daniel Wagner wrote:
> On 12/07/2016 02:01 AM, Bjorn Andersson wrote:
> > When request_firmware() finds an already open firmware object it will
> > wait for that object to become fully loaded and then check the status.
> > As __fw_state_wait_common() succeeds the timeout value returned will be
> > truncated in _request_firmware_prepare() and interpreted as -EPERM.
> >
> > Prior to "firmware: do not use fw_lock for fw_state protection" the code
> > did test if we where in the "done" state before sleeping, causing this
> > particular code path to succeed, in some cases.
> >
> > As the callers are interested in the result of the wait and not the
> > remaining timeout the return value of __fw_state_wait_common() is
> > changed to signal "done" or "error", which simplifies the logic in
> > _request_firmware_load() as well.
>
> Oops, sorry about that one. With your fix the code starts to make sense.
>
> > Fixes: 5b029624948d ("firmware: do not use fw_lock for fw_state protection")
> > Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
>
> Reviewed-by: Daniel Wagner <daniel.wagner@bmw-carit.de>
Acked-by: Luis R. Rodriguez <mcgrof@kernel.org>
Luis
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2016-12-08 15:28 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-12-07 1:01 [PATCH] firwmare: Correct handling of fw_state_wait() return value Bjorn Andersson
2016-12-08 14:47 ` Daniel Wagner
2016-12-08 15:28 ` Luis R. Rodriguez
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®