From: Ulrich Drepper <drepper@redhat.com>
To: Eric Dumazet <dada1@cosmosbay.com>,
Linux Kernel <linux-kernel@vger.kernel.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Subject: first little problem with private futexes
Date: Sun, 20 May 2007 11:39:33 -0700 [thread overview]
Message-ID: <465095E5.4050508@redhat.com> (raw)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Here's a first little issue with private futex I came across. But a
real bug but a hole.
When we use clone() with CLONE_CHILD_CLEARTID possible waiters are woken
upon termination of the thread. This operation uses FUTEX_WAKE so far.
But it in almost all cases local memory and I would even be in favor of
setting this into stone. It wouldn't break anything I know of.
The problem is we cannot just go over to using
FUTEX_WAIT|FUTEX_PRIVATE_FLAG since this would break binaries using any
glibc out there so far.
There are three ways out of this I can see:
1. do nothing, always use the shared futexes. Not very attractive IMO
2. try private futexes first, then shared one. This is even less
attractive since in the many cases there is no waiter and we cannot
determine whether the private futex notification succeeded and we're
doing the expensive work as well
3. tell the kernel whether we want the new or the old notification.
This can be done using a number of ways
a) using some prctl(). Another unconditional syscall, not nice.
b) using a new CLONE_* flag. We have currently 5 bits left and can
recover two more (CLONE_DETACHED, CLONE_STOPPED). And we can
invent ways to add more bits.
I'm in favor of 3b but if somebody argues the costs are not justified
because the effects of using the shared futex notification isn't high
enough I can accept that, too.
- --
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
iD8DBQFGUJXl2ijCOnn/RHQRAvkOAJsEmm+TiWlWRJvT5nbk0lXrpvpTaQCgo/5j
FPWYxtgUIZwrdFk/K79dIi8=
=kbfx
-----END PGP SIGNATURE-----
next reply other threads:[~2007-05-20 18:41 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-05-20 18:39 Ulrich Drepper [this message]
2007-05-20 18:53 ` first little problem with private futexes Eric Dumazet
2007-05-20 19:01 ` Ulrich Drepper
2007-05-20 19:13 ` Eric Dumazet
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=465095E5.4050508@redhat.com \
--to=drepper@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=dada1@cosmosbay.com \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).