linux-kernel - Re: futex(3) man page, final draft for pre-release 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: <56718607.2080600@gmail.com>
Date:	Wed, 16 Dec 2015 16:40:55 +0100
From:	"Michael Kerrisk (man-pages)" <mtk.manpages@...il.com>
To:	Davidlohr Bueso <dave@...olabs.net>
CC:	mtk.manpages@...il.com, Thomas Gleixner <tglx@...utronix.de>,
	Darren Hart <dvhart@...radead.org>,
	Torvald Riegel <triegel@...hat.com>,
	lkml <linux-kernel@...r.kernel.org>,
	libc-alpha <libc-alpha@...rceware.org>,
	linux-man <linux-man@...r.kernel.org>,
	Carlos O'Donell <carlos@...hat.com>,
	Roland McGrath <roland@...k.frob.com>,
	Jakub Jelinek <jakub@...hat.com>, Ingo Molnar <mingo@...e.hu>,
	bill o gallmeister <bgallmeister@...il.com>,
	bert hubert <bert.hubert@...herlabs.nl>,
	Jan Kiszka <jan.kiszka@...mens.com>,
	Eric Dumazet <edumazet@...gle.com>,
	Arnd Bergmann <arnd@...db.de>,
	Rusty Russell <rusty@...tcorp.com.au>,
	Heinrich Schuchardt <xypron.glpk@....de>,
	Andy Lutomirski <luto@...capital.net>,
	Daniel Wagner <wagi@...om.org>,
	Anton Blanchard <anton@...ba.org>,
	Steven Rostedt <rostedt@...dmis.org>,
	Rich Felker <dalias@...c.org>,
	Jonathan Wakely <jwakely@...hat.com>,
	Mike Frysinger <vapier@...too.org>,
	Peter Zijlstra <peterz@...radead.org>
Subject: Re: futex(3) man page, final draft for pre-release review

Hi David,

On 12/15/2015 11:41 PM, Davidlohr Bueso wrote:
> On Tue, 15 Dec 2015, Michael Kerrisk (man-pages) wrote:
> 
>>       When executing a futex operation that requests to block a thread,
>>       the kernel will block only if the futex word has the  value  that
>>       the  calling  thread  supplied  (as  one  of the arguments of the
>>       futex() call) as the expected value of the futex word.  The load???
>>       ing  of the futex word's value, the comparison of that value with
>>       the expected value, and the actual blocking  will  happen  atomi???
>>
>> FIXME: for next line, it would be good to have an explanation of
>> "totally ordered" somewhere around here.
>>
>>       cally  and totally ordered with respect to concurrently executing
>>       futex operations on the same futex word.
> 
> So there are two things here regarding ordering. One is the most obvious
> which is ordered due to the taking/dropping the hb spinlock. Secondly, its
> the cases which Peter brought up a while ago that involves atomic futex ops
> futex_atomic_*(), which	do not have clearly defined semantics, and you get
> inconsistencies with certain archs (tile being the worst iirc).
> 
> But anyway, the important thing users need to know about is that the atomic
> futex operation must be totally ordered wrt any other user tasks that are trying
> to access that address. This is not necessarily the case for kernel ops. Peter
> illustrates this nicely with lock stealing example; 
> (see https://lkml.org/lkml/2015/8/26/596).

Thanks. I reworded things here a little.

> Internally, I believe we decided that making it fully ordered (as opposed to
> making use of implicit barriers for ACQUIRE/RELEASE), so you'd endup having
> an MB ll/sc MB kind of setup.
> 
> [...]
> 
>>       #include <stdio.h>
>>       #include <errno.h>
>>       #include <stdlib.h>
>>       #include <unistd.h>
>>       #include <sys/wait.h>
>>       #include <sys/mman.h>
>>       #include <sys/syscall.h>
>>       #include <linux/futex.h>
>>       #include <sys/time.h>
>>
>>       #define errExit(msg)    do { perror(msg); exit(EXIT_FAILURE); \
>>                               } while (0)
> 
> Nit, but for this we have err(3).

I don't much like them though (not in POSIX).

Thanks for the help David.

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/