The following series started off looking into supporting selectable clocks
for FUTEX_LOCK_PI which is hardcoded to CLOCK_REALTIME and cannot be
changed.
On the way I found two bugs related to the timeout handling:
- The allowance for FUTEX_WAIT to use FUTEX_CLOCK_REALTIME is broken and
never worked.
- The recent time namespace support wreckaged FUTEX_LOCK_PI timeouts when
the task belongs to a namespace which has an CLOCK_MONOTONIC offset.
Both should have been caught by that Gleixner dude when merging them,
but it seems he's getting old.
Not having a selectable clock for PI futexes is inconsistent because all
other interfaces have it. Unfortunately this was figured out by glibc folks
quite some time ago, but nobody told us :(
The nasty hack to support it would be to treat FUTEX_CLOCK_REALTIME inverse
for FUTEX_LOCK_PI, but that's a horrible idea. Adding a new flag to the
futex op, i.e. FUTEX_CLOCK_MONOTONIC would be possible, but that's yet
another variant which makes is harder for libraries to have a consistent
clock selection handling.
So I went the way to let FUTEX_LOCK_PI alone and to add FUTEX_LOCK_PI2
which handles the clocks the same way as the other operands.
Thoughts?
The series is also available from git:
git://git.kernel.org/pub/scm/linux/kernel/git/tglx/devel.git futex
Thanks,
tglx
---
include/uapi/linux/futex.h | 1
kernel/futex.c | 89 +++++++++++++++++++++++----------------------
2 files changed, 47 insertions(+), 43 deletions(-)
On Thu, Apr 22, 2021 at 09:44:17PM +0200, Thomas Gleixner wrote:
> The following series started off looking into supporting selectable clocks
> for FUTEX_LOCK_PI which is hardcoded to CLOCK_REALTIME and cannot be
> changed.
>
> On the way I found two bugs related to the timeout handling:
>
> - The allowance for FUTEX_WAIT to use FUTEX_CLOCK_REALTIME is broken and
> never worked.
>
> - The recent time namespace support wreckaged FUTEX_LOCK_PI timeouts when
> the task belongs to a namespace which has an CLOCK_MONOTONIC offset.
>
> Both should have been caught by that Gleixner dude when merging them,
> but it seems he's getting old.
>
> Not having a selectable clock for PI futexes is inconsistent because all
> other interfaces have it. Unfortunately this was figured out by glibc folks
> quite some time ago, but nobody told us :(
>
> The nasty hack to support it would be to treat FUTEX_CLOCK_REALTIME inverse
> for FUTEX_LOCK_PI, but that's a horrible idea. Adding a new flag to the
> futex op, i.e. FUTEX_CLOCK_MONOTONIC would be possible, but that's yet
> another variant which makes is harder for libraries to have a consistent
> clock selection handling.
>
> So I went the way to let FUTEX_LOCK_PI alone and to add FUTEX_LOCK_PI2
> which handles the clocks the same way as the other operands.
>
> Thoughts?
With the missing FUTEX_LOCK_PI2 in #6, as spotted by Andr? Almeida, fixed:
Acked-by: Peter Zijlstra (Intel) <[email protected]>
It's all somewhat sad, but I don't see any other way out of this. Using
LOCK_PI2 will be a fairly horrible pile of hacks on the userspace side
of things given they need to first detect it's presence etc., but that
seems unavoidable whatever we do :/
On Wed May 05 2021, Peter Zijlstra wrote:
> It's all somewhat sad, but I don't see any other way out of this. Using
> LOCK_PI2 will be a fairly horrible pile of hacks on the userspace side
> of things given they need to first detect it's presence etc., but that
> seems unavoidable whatever we do :/
Well, that's the interesting point. I do have such horrible hacks for
glibc, which detect the presence of LOCK_PI2 at run time. However, the
glibc has also the notion of kernel features based on the Linux kernel
version. Then, it could be detected at compile time. At the end of the
day it depends on how this patch set is merged. I was hoping for the
glibc folks to share their opinion on this :-).
Thanks,
Kurt