This is the mail archive of the
mailing list for the glibc project.
Re: Make sem_timedwait use FUTEX_CLOCK_REALTIME (bug 18138)
- From: Torvald Riegel <triegel at redhat dot com>
- To: Joseph Myers <joseph at codesourcery dot com>
- Cc: libc-alpha at sourceware dot org, carlos at redhat dot com
- Date: Wed, 18 Mar 2015 12:14:37 +0100
- Subject: Re: Make sem_timedwait use FUTEX_CLOCK_REALTIME (bug 18138)
- Authentication-results: sourceware.org; auth=none
- References: <alpine dot DEB dot 2 dot 10 dot 1503180027220 dot 9536 at digraph dot polyomino dot org dot uk>
On Wed, 2015-03-18 at 00:28 +0000, Joseph Myers wrote:
> If a relative
> timeout is passed to the kernel, it is interpreted according to the
> CLOCK_MONOTONIC clock, and so fails to meet that POSIX requirement in
> the event of clock changes.
Thanks for realizing the clock change issue, which I had overlooked.
(I'd say that strictly speaking, this is "only" a QoI issue though,
because we give no hard guarantees around timing.)
> This patch makes sem_timedwait use lll_futex_timed_wait_bitset with
> FUTEX_CLOCK_REALTIME when possible, as done in some other places in
> NPTL. FUTEX_CLOCK_REALTIME is always available for supported Linux
> kernel versions; unavailability of lll_futex_timed_wait_bitset is only
> an issue for hppa (an issue noted in
> <https://sourceware.org/glibc/wiki/PortStatus>, and fixed by the
> <https://sourceware.org/ml/libc-alpha/2014-12/msg00655.html> that
> removes the hppa lowlevellock.h completely).
> In the FUTEX_CLOCK_REALTIME case, the glibc code still needs to check
> for negative tv_sec and handle that as timeout, because the Linux
> kernel returns EINVAL not ETIMEDOUT for that case, so resulting in
> failures of nptl/tst-abstime and nptl/tst-sem13 in the absence of that
> check. If we're trying to distinguish between Linux-specific and
> generic-futex NPTL code, I suppose having this in an nptl/ file isn't
> ideal, but there doesn't seem to be any better place at present.
Once I get back to the glibc-internal futex API, futex_abstimed_wait
will be the Linux-specific implementation of this internal API. IOW, I
expect we will take care of this in the hopefully near future, and will
then have just one place where we have this logic.
> It's not possible to add a testcase for this issue to the testsuite
> because of the requirement to change the system clock as part of a
> test (this is a case where testing would require some form of
> container, with root in that container, and one whose CLOCK_REALTIME
> is isolated from that of the host; I'm not sure what forms of
> containers, short of a full virtual machine, provide that clock
> Tested for x86_64. Also tested for powerpc with the testcase included
> in the bug.