On Fri, 18 Dec 2015, bhuvanesh_surach...@mentor.com wrote:
From: Bhuvanesh Surachari <bhuvanesh_surach...@mentor.com>
In case of error from rt_mutex_start_proxy_lock pi_state is freed
twice in futex_requeue function. Hence removing free_pi_state in
else branch and branching to the location where pi_state is freed.
This reads weird.
Do note that free_pi_state is already protected against passing it a nil
pi_state, so this is merely cosmetic.
Hmm but yeah, looks legit. The cases were we free the pi_state on error
are when doing retry kind of paths, EDEADLK not being one of those cases.
Signed-off-by: Bhuvanesh Surachari <bhuvanesh_surach...@mentor.com>
Signed-off-by: Andy Lowe <andy_l...@mentor.com>
This last SoB tag is incorrect, Andy Lowe is not carrying the patch for you.
---
kernel/futex.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/kernel/futex.c b/kernel/futex.c
index 684d754..264b3f2 100644
--- a/kernel/futex.c
+++ b/kernel/futex.c
@@ -1815,7 +1815,6 @@ retry_private:
} else if (ret) {
/* -EDEADLK */
this->pi_state = NULL;
- free_pi_state(pi_state);
goto out_unlock;
}
}
Nit but I think we also want to set pi_state to nil after freeing it
in out_unlock. That way this scenario would simply be goto out_unlock.
Thanks,
Davidlohr
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
