Re: Make sem_timedwait use FUTEX_CLOCK_REALTIME (bug 18138)

[Torvald Riegel <triegel at redhat dot com>]

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
> unreviewed
> <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
> isolation).
> 
> Tested for x86_64.  Also tested for powerpc with the testcase included
> in the bug.

LGTM.