[v1,0/6] nptl: Introduce and use FUTEX_LOCK_PI2

  Linux real time applications often make use of mutexes with priority inheritance
enabled due to problems such as unbounded priority inversion. In addition, some
applications make use of timeouts e.g., by utilizing pthread_mutex_clocklock().

However, the combination of priority inheritance enabled mutexes with timeouts
based on CLOCK_MONOTONIC doesn't work. That is because the underlying Linux
kernel futex interface didn't support it, yet. Using CLOCK_REALTIME is possible,
but it is subject to adjustments (NTP, PTP, ...). Therefore, Thomas proposed and
introduced a new futex operation called FUTEX_LOCK_PI2 with support for
selectable clocks [1].

Here is a proof of concept patch set adding FUTEX_LOCK_PI2 in order to support
pthread_mutex_clocklock(MONOTONIC)/PI. The idea is to use futex_lock_pi2() by
default, and fallback to futex_lock_pi() in case the kernel is too old.

There's also a bugreport for glibc with a test case:

 https://sourceware.org/bugzilla/show_bug.cgi?id=26801

Changes since RFC:

 * FUTEX_LOCK_PI2 merged in upstream Linux kernel (Thomas Gleixner, Peter Zijlstra)
 * Make of __ASSUME_FUTEX_LOCK_PI2 in the implementation (Adhemerval Zanella)
 * Get rid of probing for FUTEX_LOCK_PI2 in timedlock (Adhemerval Zanella)
 * Adjust the test cases (Adhemerval Zanella)
 * Use correct Linux kernel version (Joseph Myers)

Previous versions:

 * https://sourceware.org/pipermail/libc-alpha/2021-June/127798.html

Thanks,
Kurt

[1] - https://lkml.kernel.org/lkml/20210422194417.866740847@linutronix.de/

Kurt Kanzenbach (6):
  Linux: Add FUTEX_LOCK_PI2
  nptl: Introduce futex_lock_pi2()
  nptl: Use futex_lock_pi2()
  nptl: Remove mutex test 10
  nptl: mutex-test5: Include CLOCK_MONOTONIC for PI
  nptl: mutex-test9: Include CLOCK_MONOTONIC for PI

 nptl/Makefile                             |   2 +-
 nptl/pthread_mutex_timedlock.c            |  10 +-
 nptl/tst-mutexpi10.c                      |  68 -----------
 sysdeps/nptl/futex-internal.h             | 131 ++++++++++++++++++++++
 sysdeps/nptl/lowlevellock-futex.h         |   1 +
 sysdeps/pthread/tst-mutex5.c              |  20 +++-
 sysdeps/pthread/tst-mutex9.c              |   9 +-
 sysdeps/unix/sysv/linux/kernel-features.h |   8 ++
 8 files changed, 163 insertions(+), 86 deletions(-)
 delete mode 100644 nptl/tst-mutexpi10.c
  

On Fri Jun 25 2021, Kurt Kanzenbach wrote:
> Linux real time applications often make use of mutexes with priority inheritance
> enabled due to problems such as unbounded priority inversion. In addition, some
> applications make use of timeouts e.g., by utilizing pthread_mutex_clocklock().
>
> However, the combination of priority inheritance enabled mutexes with timeouts
> based on CLOCK_MONOTONIC doesn't work. That is because the underlying Linux
> kernel futex interface didn't support it, yet. Using CLOCK_REALTIME is possible,
> but it is subject to adjustments (NTP, PTP, ...). Therefore, Thomas proposed and
> introduced a new futex operation called FUTEX_LOCK_PI2 with support for
> selectable clocks [1].
>
> Here is a proof of concept patch set adding FUTEX_LOCK_PI2 in order to support
> pthread_mutex_clocklock(MONOTONIC)/PI. The idea is to use futex_lock_pi2() by
> default, and fallback to futex_lock_pi() in case the kernel is too old.
>
> There's also a bugreport for glibc with a test case:
>
>  https://sourceware.org/bugzilla/show_bug.cgi?id=26801
>
> Changes since RFC:
>
>  * FUTEX_LOCK_PI2 merged in upstream Linux kernel (Thomas Gleixner, Peter Zijlstra)
>  * Make of __ASSUME_FUTEX_LOCK_PI2 in the implementation (Adhemerval Zanella)
>  * Get rid of probing for FUTEX_LOCK_PI2 in timedlock (Adhemerval Zanella)
>  * Adjust the test cases (Adhemerval Zanella)
>  * Use correct Linux kernel version (Joseph Myers)
>
> Previous versions:
>
>  * https://sourceware.org/pipermail/libc-alpha/2021-June/127798.html

Ping. Any comments on this version?

Thanks,
Kurt
  

On 25/06/2021 05:10, Kurt Kanzenbach wrote:
> Linux real time applications often make use of mutexes with priority inheritance
> enabled due to problems such as unbounded priority inversion. In addition, some
> applications make use of timeouts e.g., by utilizing pthread_mutex_clocklock().
> 
> However, the combination of priority inheritance enabled mutexes with timeouts
> based on CLOCK_MONOTONIC doesn't work. That is because the underlying Linux
> kernel futex interface didn't support it, yet. Using CLOCK_REALTIME is possible,
> but it is subject to adjustments (NTP, PTP, ...). Therefore, Thomas proposed and
> introduced a new futex operation called FUTEX_LOCK_PI2 with support for
> selectable clocks [1].
> 
> Here is a proof of concept patch set adding FUTEX_LOCK_PI2 in order to support
> pthread_mutex_clocklock(MONOTONIC)/PI. The idea is to use futex_lock_pi2() by
> default, and fallback to futex_lock_pi() in case the kernel is too old.
> 
> There's also a bugreport for glibc with a test case:
> 
>  https://sourceware.org/bugzilla/show_bug.cgi?id=26801
> 
> Changes since RFC:
> 
>  * FUTEX_LOCK_PI2 merged in upstream Linux kernel (Thomas Gleixner, Peter Zijlstra)
>  * Make of __ASSUME_FUTEX_LOCK_PI2 in the implementation (Adhemerval Zanella)
>  * Get rid of probing for FUTEX_LOCK_PI2 in timedlock (Adhemerval Zanella)
>  * Adjust the test cases (Adhemerval Zanella)
>  * Use correct Linux kernel version (Joseph Myers)
> 
> Previous versions:
> 
>  * https://sourceware.org/pipermail/libc-alpha/2021-June/127798.html
> 
> Thanks,
> Kurt
> 
> [1] - https://lkml.kernel.org/lkml/20210422194417.866740847@linutronix.de/

Patch looks ok in general, I think I have only minor comments.  I see that
FUTEX_LOCK_PI2 is already on Linus tree, should it should be safe to assume
it will on v5.14 (although is not yet released).

We are in the slush freeze for the 2.34 release, so you would like to check
with Carlos O'Donell if this set is suitable to inclusion.  It does not
change any ABI, but I will need to some time to boot a kernel to actually
test it.
  

On Fri Jul 09 2021, Adhemerval Zanella wrote:
> Patch looks ok in general, I think I have only minor comments.  I see that
> FUTEX_LOCK_PI2 is already on Linus tree, should it should be safe to assume
> it will on v5.14 (although is not yet released).
>
> We are in the slush freeze for the 2.34 release, so you would like to check
> with Carlos O'Donell if this set is suitable to inclusion.  It does not
> change any ABI, but I will need to some time to boot a kernel to actually
> test it.

There is no hurry. I just wanted to make sure that the implementation is
moving into the right direction. I'll integrate your review comments and
post v2 when Linux v5.14.0 is actually released. That should make it
easier for testing.

Thanks,
Kurt