linux-kernel - first little problem with private futexes

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <465095E5.4050508@redhat.com>
Date:	Sun, 20 May 2007 11:39:33 -0700
From:	Ulrich Drepper <drepper@...hat.com>
To:	Eric Dumazet <dada1@...mosbay.com>,
	Linux Kernel <linux-kernel@...r.kernel.org>
CC:	Andrew Morton <akpm@...ux-foundation.org>
Subject: first little problem with private futexes

-----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-----
-
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/