On Wed, Oct 07, 2015 at 10:34:19AM +0100, Michael Kerrisk (man-pages) wrote:
> On 08/19/2015 03:40 PM, Thomas Gleixner wrote:
> > On Wed, 5 Aug 2015, Darren Hart wrote:
> >> On Mon, Jul 27, 2015 at 02:07:15PM +0200, Michael Kerrisk (man-pages)
> >> wrote:
> >>> .\" FIXME XXX = Start of adapted
On Wed, Oct 07, 2015 at 09:30:46AM +0100, Michael Kerrisk (man-pages) wrote:
> Hello Thomas,
>
> Thanks for the follow up!
>
> Some open questions below are marked with the string ###.
A couple of comments from me below, although I suspect you have this much
covered already.
>
> On 08/19/2015
On 08/19/2015 03:40 PM, Thomas Gleixner wrote:
> On Wed, 5 Aug 2015, Darren Hart wrote:
>> On Mon, Jul 27, 2015 at 02:07:15PM +0200, Michael Kerrisk (man-pages) wrote:
>>> .\" FIXME XXX = Start of adapted Hart/Guniguntala text =
>>> .\" The following text is drawn from the Hart/Gunigu
Hello Thomas,
Thanks for the follow up!
Some open questions below are marked with the string ###.
On 08/19/2015 04:17 PM, Thomas Gleixner wrote:
> On Sat, 8 Aug 2015, Michael Kerrisk (man-pages) wrote:
FUTEX_CMP_REQUEUE (since Linux 2.6.7)
This operation first c
On Thu, Aug 20, 2015 at 01:17:03AM +0200, Thomas Gleixner wrote:
...
> > >> .\" FIXME XXX In discussing errors for FUTEX_CMP_REQUEUE_PI, Darren Hart
> > >> .\" made the observation that "EINVAL is returned if the non-pi
> > >> .\" to pi or op pairing semantics are violated."
> > >> .
On Sat, Aug 08, 2015 at 08:57:35AM +0200, Michael Kerrisk (man-pages) wrote:
...
> >> .\" FIXME = End of adapted Hart/Guniguntala text =
> >>
> >>
> >>
> >> .\" FIXME We need some explanation in the following paragraph of *why*
> >> .\" it is important to note that "the kernel will
On Thu, Aug 20, 2015 at 12:40:46AM +0200, Thomas Gleixner wrote:
> On Wed, 5 Aug 2015, Darren Hart wrote:
> > On Mon, Jul 27, 2015 at 02:07:15PM +0200, Michael Kerrisk (man-pages) wrote:
> > > .\" FIXME XXX = Start of adapted Hart/Guniguntala text =
> > > .\" The following text is dra
On Sat, 8 Aug 2015, Michael Kerrisk (man-pages) wrote:
> >>FUTEX_CMP_REQUEUE (since Linux 2.6.7)
> >> This operation first checks whether the location uaddr
> >> still contains the value val3. If not, the operation
> >> fails with the e
On Wed, 5 Aug 2015, Darren Hart wrote:
> On Mon, Jul 27, 2015 at 02:07:15PM +0200, Michael Kerrisk (man-pages) wrote:
> > .\" FIXME XXX = Start of adapted Hart/Guniguntala text =
> > .\" The following text is drawn from the Hart/Guniguntala paper
> > .\" (listed in SEE ALSO), bu
Hi Darren,
Some of my comments below will refer to the reply I just sent
to tglx (and the list) a few minutes ago.
On 08/06/2015 12:21 AM, Darren Hart wrote:
> On Mon, Jul 27, 2015 at 02:07:15PM +0200, Michael Kerrisk (man-pages) wrote:
>> Hello all,
>>
>
> Michael, thank you for your diligence
On 07/28/2015 11:03 PM, Thomas Gleixner wrote:
> On Tue, 28 Jul 2015, Peter Zijlstra wrote:
>
>> On Tue, Jul 28, 2015 at 10:23:51PM +0200, Thomas Gleixner wrote:
>>
FUTEX_WAKE (since Linux 2.6.0)
This operation wakes at most val of the waiters that are
Hi Thomas,
Thank you for the comments below. This helps hugely:
more than 30 of my FIXMEs have now gone away!
I have a few open questions, which you can find
by searching for the string "???". If you would have
a chance to look at those, I'd appreciate it.
On 07/28/2015 10:23 PM, Thomas Gleixner
On Mon, Jul 27, 2015 at 02:07:15PM +0200, Michael Kerrisk (man-pages) wrote:
> Hello all,
>
Michael, thank you for your diligence in following up and collecting
reviews. I've attempted to respond to what I was specifically called out
in or where I had something specific to add in addition to othe
On 07/29/2015 06:21 AM, Darren Hart wrote:
> On Tue, Jul 28, 2015 at 09:11:41PM -0700, Darren Hart wrote:
>> On Tue, Jul 28, 2015 at 10:23:51PM +0200, Thomas Gleixner wrote:
>>> On Mon, 27 Jul 2015, Michael Kerrisk (man-pages) wrote:
>>
>> ...
>>
FUTEX_REQUEUE (since Linux 2.6.0)
.
On Tue, 28 Jul 2015, Darren Hart wrote:
> Found it on libc-alpha, here it is for reference:
>
> From: Rich Felker
> Date: Wed, 29 Oct 2014 22:43:17 -0400
> To: Darren Hart
> Cc: Carlos O'Donell , Roland McGrath
> ,
> Torvald Riegel , GLIBC Devel
> ,
> Michae
On Tue, Jul 28, 2015 at 09:11:41PM -0700, Darren Hart wrote:
> On Tue, Jul 28, 2015 at 10:23:51PM +0200, Thomas Gleixner wrote:
> > On Mon, 27 Jul 2015, Michael Kerrisk (man-pages) wrote:
>
> ...
>
> > >FUTEX_REQUEUE (since Linux 2.6.0)
> > > .\" FIXME(Torvald) Is there some indication th
On Tue, Jul 28, 2015 at 10:23:51PM +0200, Thomas Gleixner wrote:
> On Mon, 27 Jul 2015, Michael Kerrisk (man-pages) wrote:
...
> >FUTEX_REQUEUE (since Linux 2.6.0)
> > .\" FIXME(Torvald) Is there some indication that FUTEX_REQUEUE is broken
> > .\" in general, or is this comment impli
On Tue, 2015-07-28 at 22:45 +0200, Peter Zijlstra wrote:
> Also, this code seems to use plist, which means it won't do the right
> thing for SCHED_DEADLINE either.
Ick, I don't look forward to seeing nice futex plists converted into
rbtrees. As opposed to, eg. rtmutexes, there are a few caveats:
On Tue, 28 Jul 2015, Peter Zijlstra wrote:
> On Tue, Jul 28, 2015 at 10:23:51PM +0200, Thomas Gleixner wrote:
>
> > >FUTEX_WAKE (since Linux 2.6.0)
> > > This operation wakes at most val of the waiters that are
> > > waiting (e.g., inside FUTEX_WAIT) on the f
On Tue, Jul 28, 2015 at 10:23:51PM +0200, Thomas Gleixner wrote:
> >FUTEX_WAKE (since Linux 2.6.0)
> > This operation wakes at most val of the waiters that are
> > waiting (e.g., inside FUTEX_WAIT) on the futex word at the
> > address uaddr. Mo
On Mon, 27 Jul 2015, Michael Kerrisk (man-pages) wrote:
>FUTEX_CLOCK_REALTIME (since Linux 2.6.28)
> This option bit can be employed only with the
> FUTEX_WAIT_BITSET and FUTEX_WAIT_REQUEUE_PI operations.
>
> If this option is set, the
On 07/28/2015 07:52 PM, Davidlohr Bueso wrote:
> On Tue, 2015-07-28 at 09:44 +0200, Michael Kerrisk (man-pages) wrote:
>> Maybe you still have some further improvements for the paragraph?
>
> Nah, this is fine enough. Looks good.
Okay. Thanks. I added a Reviewed-by: for you.
Cheers,
Michael
-
On Tue, 2015-07-28 at 09:44 +0200, Michael Kerrisk (man-pages) wrote:
> Maybe you still have some further improvements for the paragraph?
Nah, this is fine enough. Looks good.
Thanks,
Davidlohr
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Hi David,
On 07/28/2015 05:16 AM, Davidlohr Bueso wrote:
> On Mon, 2015-07-27 at 13:10 +0200, Michael Kerrisk (man-pages) wrote:
>> Hi David,
>>
>> On 03/31/2015 04:45 PM, Davidlohr Bueso wrote:
>>> On Sat, 2015-03-28 at 12:47 +0100, Peter Zijlstra wrote:
>>>
The condition is represent
On Tue, 2015-07-28 at 07:44 +0200, Heinrich Schuchardt wrote:
> Hello David,
>
> >> A futex is in essence a 32-bit user-space address.
> I know what a 32 bit integer is.
> I am not aware of 32 bit addresses on my 64 bit operating system.
Well I am referring to in the context of a user-space addre
On 07/28/2015 04:52 AM, Davidlohr Bueso wrote:
> On Sat, 2015-03-28 at 12:47 +0100, Peter Zijlstra wrote:
>> SEE ALSO
>>get_robust_list(2), restart_syscall(2), futex(7)
>
> For pi futexes, I also suggest pthread_mutexattr_getprotocol(3), which
> is a common entry point.
Thanks. Added.
Ch
On Mon, 2015-07-27 at 13:10 +0200, Michael Kerrisk (man-pages) wrote:
> Hi David,
>
> On 03/31/2015 04:45 PM, Davidlohr Bueso wrote:
> > On Sat, 2015-03-28 at 12:47 +0100, Peter Zijlstra wrote:
> >
> >>The condition is represented by the futex word, which is an address
> >> in
> >>
On Sat, 2015-03-28 at 12:47 +0100, Peter Zijlstra wrote:
> SEE ALSO
>get_robust_list(2), restart_syscall(2), futex(7)
For pi futexes, I also suggest pthread_mutexattr_getprotocol(3), which
is a common entry point.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel"
On 07/27/2015 04:17 PM, Heinrich Schuchardt wrote:
> instruction. A thread maybe unable
>
> to << missing word
>
> acquire a lock because it is
> already acquired by another thread. It then may pass the lock's
> flag as futex word and the value representing the acquired state
> as the expected va
Hello all,
>From a draft sent out in March, I got a few useful comments that
I've now incorporated into this draft. And I got some complaints
from people who did not want to read groff source. My point
was that there are a bunch of FIXMEs in the page source that I
wanted people to look at... Anywa
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 conta
On 04/15/2015 12:28 PM, Torvald Riegel wrote:
> On Tue, 2015-04-14 at 23:40 +0200, Thomas Gleixner wrote:
>> On Sat, 28 Mar 2015, Peter Zijlstra wrote:
>>> On Sat, Mar 28, 2015 at 09:53:21AM +0100, Michael Kerrisk (man-pages) wrote:
So, please take a look at the page below. At this point,
Hello Pavel,
On 04/27/2015 10:37 PM, Pavel Machek wrote:
> Hi!
>
>> The FUTEX_WAIT_OP operation is equivalent to execute the
>> follow???
>> ing code atomically and totally ordered with respect to
>> other
>> futex operations on any of the two suppli
Hi David,
On 03/31/2015 04:45 PM, Davidlohr Bueso wrote:
> On Sat, 2015-03-28 at 12:47 +0100, Peter Zijlstra wrote:
>
>>The condition is represented by the futex word, which is an address
>> in
>>memory supplied to the futex() system call, and the value at this
>> mem‐
>>
On 03/31/2015 03:48 AM, Rusty Russell wrote:
> "Michael Kerrisk (man-pages)" writes:
>> When executing a futex operation that requests to block a thread,
>> the kernel will only block if the futex word has the value that the
>> calling thread supplied as expected value.
>> The load from the futex
Hi David,
On 03/31/2015 10:36 PM, Davidlohr Bueso wrote:
> On Sat, 2015-03-28 at 13:03 +0100, Peter Zijlstra wrote:
>>> If the timeout argument is non-NULL, its contents specify a
>>> rel‐
>>> ative timeout for the wait, measured according to
>>> the
>>>
Hi!
> The FUTEX_WAIT_OP operation is equivalent to execute the
> follow???
> ing code atomically and totally ordered with respect to other
> futex operations on any of the two supplied futex words:
"to executing"?
> The operation and
On Tue, 2015-04-14 at 23:40 +0200, Thomas Gleixner wrote:
> On Sat, 28 Mar 2015, Peter Zijlstra wrote:
> > On Sat, Mar 28, 2015 at 09:53:21AM +0100, Michael Kerrisk (man-pages) wrote:
> > > So, please take a look at the page below. At this point,
> > > I would most especially appreciate help with t
On Sat, 28 Mar 2015, Peter Zijlstra wrote:
> On Sat, Mar 28, 2015 at 09:53:21AM +0100, Michael Kerrisk (man-pages) wrote:
> > So, please take a look at the page below. At this point,
> > I would most especially appreciate help with the FIXMEs.
>
> For people who cannot read that troff gibberish (m
On Sat, 2015-03-28 at 13:03 +0100, Peter Zijlstra wrote:
> > 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 r
On Sat, 2015-03-28 at 12:47 +0100, Peter Zijlstra wrote:
>The condition is represented by the futex word, which is an address in
>memory supplied to the futex() system call, and the value at this mem‐
>ory location. (While the virtual addresses for the same memory in sep
"Michael Kerrisk (man-pages)" writes:
> When executing a futex operation that requests to block a thread,
> the kernel will only block if the futex word has the value that the
> calling thread supplied as expected value.
> The load from the futex word, the comparison with
> the expected value,
> a
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 sle
On Sat, Mar 28, 2015 at 09:53:21AM +0100, Michael Kerrisk (man-pages) wrote:
> So, please take a look at the page below. At this point,
> I would most especially appreciate help with the FIXMEs.
For people who cannot read that troff gibberish (me)..
---
FUTEX(2) Linux Programmer
On 03/28/2015 09:53 AM, Michael Kerrisk (man-pages) wrote:
> Hello all,
[...]
> So, please take a look at the page below. At this point,
> I would most especially appreciate help with the FIXMEs.
One more point I should have added. The revised page
currently sits in a Git branch, here:
http://git.
Hello all,
As becomes quickly obvious upon reading it, the current futex(2)
man page is in a sorry state, lacking many important details, and
also the various additions that have been made to the interface
over the last years. I've been working on revising it, first
of all based on input I got in
46 matches
Mail list logo
