This is the mail archive of the glibc-bugs@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug nptl/16816] pthread_once: ABA issue related to the fork generation counter


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]