lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Thu, 12 Mar 2009 11:47:56 +0100 (CET) From: Thomas Gleixner <tglx@...utronix.de> To: Peter Zijlstra <peterz@...radead.org> cc: Darren Hart <dvhltc@...ibm.com>, linux-kernel@...r.kernel.org, Ingo Molnar <mingo@...e.hu>, Rusty Russell <rusty@...tcorp.com.au> Subject: Re: [PATCH 5/6] futex: unlock before returning -EFAULT On Thu, 12 Mar 2009, Peter Zijlstra wrote: > 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. That would break pi futexes in bits and pieces. T1 takes F1 T2 blocks on F1 -> T2 sets up rt_mutex and locks it for T1 T2 blocks on rt_mutex and boosts T1 T1 calls a non futex syscall T1 returns from syscall with the rt_mutex still locked Thanks, tglx -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists