This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
[Bug nptl/16816] pthread_once: ABA issue related to the fork generation counter
- From: "carlos at redhat dot com" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sourceware dot org
- Date: Wed, 09 Apr 2014 19:09:45 +0000
- Subject: [Bug nptl/16816] pthread_once: ABA issue related to the fork generation counter
- Auto-submitted: auto-generated
- References: <bug-16816-131 at http dot sourceware dot org/bugzilla/>
https://sourceware.org/bugzilla/show_bug.cgi?id=16816
Carlos O'Donell <carlos at redhat dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |carlos at redhat dot com
--- Comment #1 from Carlos O'Donell <carlos at redhat dot com> ---
(In reply to Torvald Riegel from comment #0)
> The pthread_once algorithm (see nptl/sysdeps/unix/sysv/linux/pthread_once.c
> after the pthread_once unification) has an ABA issue related to the fork
> generation: If an initialization is interrupted, we then fork 2^30 times (30
> bits of once_control are used for the fork generation), and try to
> initialize again, we can deadlock because we can't distinguish the
> in-progress and interrupted cases anymore.
>
> This should be rather unlikely to hit in practice given that we need to be
> suspended for exactly 2^30 fork calls; also, any subsequent pthread_once
> call to the same pthread_once instance will wake the futex_wait again.
My problem with "unlikely" is that eventually this leads to security issues.
At the very least I'd like to know the cost of detecting the overflow and
asserting, which prevents deadlock by killing the process.
--
You are receiving this mail because:
You are on the CC list for the bug.