linux-kernel - Re: Revised futex(2) man page for review

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <55B611BF.8040908@gmail.com>
Date:	Mon, 27 Jul 2015 13:10:55 +0200
From:	"Michael Kerrisk (man-pages)" <mtk.manpages@...il.com>
To:	Peter Zijlstra <peterz@...radead.org>
CC:	mtk.manpages@...il.com, Thomas Gleixner <tglx@...utronix.de>,
	Darren Hart <dvhart@...ux.intel.com>,
	Carlos O'Donell <carlos@...hat.com>,
	Ingo Molnar <mingo@...e.hu>, Jakub Jelinek <jakub@...hat.com>,
	"linux-man@...r.kernel.org" <linux-man@...r.kernel.org>,
	lkml <linux-kernel@...r.kernel.org>,
	Davidlohr Bueso <dave@...olabs.net>,
	Arnd Bergmann <arnd@...db.de>,
	Steven Rostedt <rostedt@...dmis.org>,
	Linux API <linux-api@...r.kernel.org>,
	Torvald Riegel <triegel@...hat.com>,
	Roland McGrath <roland@...k.frob.com>,
	Darren Hart <dvhart@...radead.org>,
	Anton Blanchard <anton@...ba.org>,
	Eric Dumazet <edumazet@...gle.com>,
	bill o gallmeister <bgallmeister@...il.com>,
	Jan Kiszka <jan.kiszka@...mens.com>,
	Daniel Wagner <wagi@...om.org>, Rich Felker <dalias@...c.org>,
	Andy Lutomirski <luto@...capital.net>,
	bert hubert <bert.hubert@...herlabs.nl>,
	Rusty Russell <rusty@...tcorp.com.au>,
	Heinrich Schuchardt <xypron.glpk@....de>
Subject: Re: Revised futex(2) man page for review

Hi Peter,

On 03/28/2015 01:03 PM, Peter Zijlstra wrote:
> On Sat, Mar 28, 2015 at 12:47:25PM +0100, Peter Zijlstra wrote:
>>        FUTEX_WAIT (since Linux 2.6.0)
>>               This operation tests that the value at the futex word pointed to
>>               by the address uaddr still contains the expected value val,  and
>>               if  so,  then sleeps awaiting FUTEX_WAKE on the futex word.  The
>>               load of the value of the futex word is an atomic  memory  access
>>               (i.e.,  using  atomic  machine  instructions  of  the respective
>>               architecture).  This load,  the  comparison  with  the  expected
>>               value,  and  starting  to  sleep  are  performed  atomically and
>>               totally ordered with respect to other futex  operations  on  the
>>               same  futex  word.  If the thread starts to sleep, it is consid‐
>>               ered a waiter on this futex word.  If the futex value  does  not
>>               match  val,  then  the  call  fails  immediately  with the error
>>               EAGAIN.
>>
>>               The purpose of the comparison with the expected value is to pre‐
>>               vent  lost  wake-ups: If another thread changed the value of the
>>               futex word after the calling thread decided to  block  based  on
>>               the  prior  value, and if the other thread executed a FUTEX_WAKE
>>               operation (or similar wake-up) after the value change and before
>>               this  FUTEX_WAIT  operation,  then  the  latter will observe the
>>               value change and will not start to sleep.
>>
>>               If the timeout argument is non-NULL, its contents specify a rel‐
>>               ative   timeout   for   the  wait,  measured  according  to  the
>>               CLOCK_MONOTONIC clock.  (This interval will be rounded up to the
>>               system clock granularity, and kernel scheduling delays mean that
>>               the blocking interval may overrun by a small amount.)  If  time‐
>>               out is NULL, the call blocks indefinitely.
> 
> Would it not be better to only state that the wait will not return
> before the timeout -- unless woken -- and not bother with clock
> granularity and scheduling delays?

Many of the pages that talk about system calls that have timeouts
carry similar language, since people often have confusions about what time
timeout (e.g., that it's an upper limit, not a minimum; or that it's precise
to some very small granularity). Why do you think the language here is a
problem?

Cheers,

Michael



-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/