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: Wed, 14 May 2014 17:28:32 -0700 From: "H. Peter Anvin" <hpa@...or.com> To: Davidlohr Bueso <davidlohr@...com>, mtk.manpages@...il.com CC: Darren Hart <dvhart@...ux.intel.com>, Thomas Gleixner <tglx@...utronix.de>, Ingo Molnar <mingo@...e.hu>, Jakub Jelinek <jakub@...hat.com>, "linux-man@...r.kernel.org" <linux-man@...r.kernel.org>, lkml <linux-kernel@...r.kernel.org>, Davidlohr Bueso <davidlohr.bueso@...com>, Arnd Bergmann <arnd@...db.de>, Steven Rostedt <rostedt@...dmis.org>, Peter Zijlstra <peterz@...radead.org>, Linux API <linux-api@...r.kernel.org>, "Carlos O'Donell" <carlos@...hat.com> Subject: Re: futex(2) man page update help request On 05/14/2014 01:56 PM, Davidlohr Bueso wrote: >> >>> However, unless I'm sorely mistaken, the larger problem is that glibc >>> removed the futex() call entirely, so these man pages don't describe >> >> I don't think futex() ever was in glibc--that's by design, and >> completely understandable: no user-space application would want to >> directly use futex(). > > That's actually not quite true. There are plenty of software efforts out > there that use futex calls directly to implement userspace serialization > mechanisms as an alternative to the bulky sysv semaphores. I worked > closely with an in-memory DB project that makes heavy use of them. Not > everyone can simply rely on pthreads. > More fundamentally, futex(2), like clone(2), are things that can be legitimately by user space without automatically breaking all of glibc. There are some other things where that is *not* true, because glibc relies on being able to mediate all accesses to a kernel facility, but not here. -hpa -- 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