All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Gleixner <tglx@linutronix.de>
To: Darren Hart <dvhart@infradead.org>
Cc: Matthieu CASTET <matthieu.castet@parrot.com>,
	linux-kernel@vger.kernel.org,
	Michael Kerrisk <mtk.manpages@gmail.com>,
	Darren Hart <dvhart@linux.intel.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Davidlohr Bueso <dave@stgolabs.net>,
	Eric Dumazet <dada1@cosmosbay.com>
Subject: Re: futex: Allow FUTEX_CLOCK_REALTIME with FUTEX_WAIT op
Date: Thu, 23 Jun 2016 09:18:42 +0200 (CEST)	[thread overview]
Message-ID: <alpine.DEB.2.11.1606230913570.5839@nanos> (raw)
In-Reply-To: <20160623044828.GA3379@f23x64.localdomain>

On Wed, 22 Jun 2016, Darren Hart wrote:
> However, I don't think the patch below is correct. The existing logic
> determines the type of timeout based on the futex_op when it should instead
> determine the type of timeout based on the FUTEX_CLOCK_REALTIME flag.

No.
 
> My reading of the man page is that FUTEX_WAIT_BITSET abides by the timeout
> interpretation defined by the FUTEX_CLOCK_REALTIME attribute, so
> SYSCALL_DEFINE6 was misbehaving for FUTEX_WAIT|FUTEX_CLOCK_REALTIME (where the
> timeout should have been treated as absolute) as well as for
> FUTEX_WAIT_BITSET|FUTEX_CLOCK_MONOTONIC (where the timeout should have been
> treated as relative).
> 
> Consider the following:
> 
> diff --git a/kernel/futex.c b/kernel/futex.c
> index 33664f7..fa2af29 100644
> --- a/kernel/futex.c
> +++ b/kernel/futex.c
> @@ -3230,7 +3230,7 @@ SYSCALL_DEFINE6(futex, u32 __user *, uaddr, int, op, u32, val,
>  			return -EINVAL;
>  
>  		t = timespec_to_ktime(ts);
> -		if (cmd == FUTEX_WAIT)
> +		if (!(cmd & FUTEX_CLOCK_REALTIME))
>  			t = ktime_add_safe(ktime_get(), t);

That breaks LOCK_PI, REQUEUE_PI and FUTEX_WAIT_BITSET

> The concern for me is whether the code is incorrect, or if the man page is
> incorrect. Does existing userspace code expect the FUTEX_WAIT_BITSET op to
> always use an absolute timeout, regardless of the CLOCK used?

FUTEX_WAIT_BITSET, LOCK_PI and REQUEUE_PI always expect absolute time in
CLOCK_REALTIME independent of the CLOCK_REALTIME flag.

The flag was explicitely added to allow FUTEX_WAIT to hand in absolute time.

> > diff --git a/kernel/futex.c b/kernel/futex.c
> > index 33664f7..4bee915 100644
> > --- a/kernel/futex.c
> > +++ b/kernel/futex.c
> > @@ -3230,7 +3230,7 @@ SYSCALL_DEFINE6(futex, u32 __user *, uaddr, int, op, u32, val,
> >  			return -EINVAL;
> >  
> >  		t = timespec_to_ktime(ts);
> > -		if (cmd == FUTEX_WAIT)
> > +		if (cmd == FUTEX_WAIT && !(op & FUTEX_CLOCK_REALTIME))
> >  			t = ktime_add_safe(ktime_get(), t);
> >  		tp = &t;
> >  	}

So this patch is correct and if the man page is unclear about it then we need
to fix that.

Thanks,

	tglx

  reply	other threads:[~2016-06-23  7:20 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-06-20 14:26 futex: Allow FUTEX_CLOCK_REALTIME with FUTEX_WAIT op Matthieu CASTET
2016-06-23  4:48 ` Darren Hart
2016-06-23  7:18   ` Thomas Gleixner [this message]
2016-06-23 10:52     ` Michael Kerrisk (man-pages)
2016-06-23 13:40       ` Thomas Gleixner
2016-06-23 16:16         ` Darren Hart
2016-06-23 17:26           ` Thomas Gleixner
2016-06-23 18:28             ` Darren Hart
2016-06-23 18:41               ` Michael Kerrisk (man-pages)
2016-06-23 19:55                 ` Darren Hart
2016-06-23 20:31                   ` Darren Hart
     [not found]                     ` <d8bcb621-012e-f34c-4cf9-2d09aa23a43c@gmail.com>
2016-06-24  9:52                       ` Thomas Gleixner
2016-06-24 10:00                         ` Michael Kerrisk (man-pages)
2016-07-06 18:57                 ` Thomas Gleixner
2016-06-23 18:35           ` Michael Kerrisk (man-pages)
2016-06-23 19:53             ` Darren Hart
2016-06-24  8:13               ` Michael Kerrisk (man-pages)
2016-06-23 10:53   ` Michael Kerrisk (man-pages)

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=alpine.DEB.2.11.1606230913570.5839@nanos \
    --to=tglx@linutronix.de \
    --cc=dada1@cosmosbay.com \
    --cc=dave@stgolabs.net \
    --cc=dvhart@infradead.org \
    --cc=dvhart@linux.intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=matthieu.castet@parrot.com \
    --cc=mtk.manpages@gmail.com \
    --cc=peterz@infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.