Messages in this thread | | | Subject | Re: [PATCH 5/6] futex: unlock before returning -EFAULT | From | Peter Zijlstra <> | Date | Thu, 12 Mar 2009 11:13:36 +0100 |
| |
On Thu, 2009-03-12 at 00:56 -0700, Darren Hart wrote: > futex_lock_pi can potentially return -EFAULT with the rt_mutex held. This > seems like the wrong thing to do as userspace should assume -EFAULT means the > lock was not taken. Even if it could figure this out, we'd be leaving the > pi_state->owner in an inconsistent state. This patch unlocks the rt_mutex > prior to returning -EFAULT to userspace.
lockdep would complain, one is not to leave the kernel with locks held.
> Build and boot tested on a 4 way Intel x86_64 workstation. Passes basic > pthread_mutex and PI tests out of ltp/testcases/realtime.
You keep mentioning these tests.. makes me wonder how much of the futex code paths they actually test. Got any coverage info on them?
> Signed-off-by: Darren Hart <dvhltc@us.ibm.com> > Cc: Thomas Gleixner <tglx@linutronix.de> > Cc: Peter Zijlstra <peterz@infradead.org> > Cc: Ingo Molnar <mingo@elte.hu> > Cc: Rusty Russell <rusty@rustcorp.com.au> > --- > > kernel/futex.c | 7 +++++++ > 1 files changed, 7 insertions(+), 0 deletions(-) > > diff --git a/kernel/futex.c b/kernel/futex.c > index 6579912..c980a55 100644 > --- a/kernel/futex.c > +++ b/kernel/futex.c > @@ -1567,6 +1567,13 @@ retry_locked: > } > } > > + /* > + * If fixup_pi_state_owner() faulted and was unable to handle the > + * fault, unlock it and return the fault to userspace. > + */ > + if (ret && (rt_mutex_owner(&q.pi_state->pi_mutex) == current)) > + rt_mutex_unlock(&q.pi_state->pi_mutex); > + > /* Unqueue and drop the lock */ > unqueue_me_pi(&q); > >
| |