Hi!
> I'll follow up with you in a couple weeks most likely. I have some urgent
> things that will be taking all my time and then some until then. Feel free
> to poke me though if I lose track of it :-)
FYI I've started to work on futex testcases for LTP. The first batch has
been commited in:
Hi!
I'll follow up with you in a couple weeks most likely. I have some urgent
things that will be taking all my time and then some until then. Feel free
to poke me though if I lose track of it :-)
FYI I've started to work on futex testcases for LTP. The first batch has
been commited in:
On 1/24/15, 3:35 AM, "Thomas Gleixner" wrote:
>On Fri, 23 Jan 2015, Torvald Riegel wrote:
>> Second, the current documentation for EINTR is that it can happen due to
>> receiving a signal *or* due to a spurious wake-up. This is difficult to
>
>I don't think so. I went through all callchains
On 1/24/15, 3:35 AM, Thomas Gleixner t...@linutronix.de wrote:
On Fri, 23 Jan 2015, Torvald Riegel wrote:
Second, the current documentation for EINTR is that it can happen due to
receiving a signal *or* due to a spurious wake-up. This is difficult to
I don't think so. I went through all
Hello Torvald,
On 01/24/2015 02:12 PM, Torvald Riegel wrote:
> On Sat, 2015-01-24 at 12:35 +0100, Thomas Gleixner wrote:
>> So we should never see -EINTR in the case of a spurious wakeup here.
>>
>> But, here is the not so good news:
>>
>> I did some archaeology. The restart handling of
Hello Torvald,
On 01/24/2015 02:12 PM, Torvald Riegel wrote:
On Sat, 2015-01-24 at 12:35 +0100, Thomas Gleixner wrote:
So we should never see -EINTR in the case of a spurious wakeup here.
But, here is the not so good news:
I did some archaeology. The restart handling of futex_wait() got
On Sat, 24 Jan 2015, Torvald Riegel wrote:
> On Sat, 2015-01-24 at 11:05 +0100, Thomas Gleixner wrote:
> > On Fri, 23 Jan 2015, Torvald Riegel wrote:
> >
> > > On Fri, 2015-01-16 at 16:46 -0800, Darren Hart wrote:
> > > > On 1/16/15, 12:54 PM, "Michael Kerrisk (man-pages)"
> > > > wrote:
> > > >
On Sat, 2015-01-24 at 12:35 +0100, Thomas Gleixner wrote:
> So we should never see -EINTR in the case of a spurious wakeup here.
>
> But, here is the not so good news:
>
> I did some archaeology. The restart handling of futex_wait() got
> introduced in kernel 2.6.22, so anything older than
On Sat, 2015-01-24 at 11:05 +0100, Thomas Gleixner wrote:
> On Fri, 23 Jan 2015, Torvald Riegel wrote:
>
> > On Fri, 2015-01-16 at 16:46 -0800, Darren Hart wrote:
> > > On 1/16/15, 12:54 PM, "Michael Kerrisk (man-pages)"
> > > wrote:
> > >
> > > >Color me stupid, but I can't see this in
On Fri, 23 Jan 2015, Torvald Riegel wrote:
> Second, the current documentation for EINTR is that it can happen due to
> receiving a signal *or* due to a spurious wake-up. This is difficult to
I don't think so. I went through all callchains again with a fine comb.
futex_wait()
retry:
ret
On Fri, 23 Jan 2015, Torvald Riegel wrote:
> On Fri, 2015-01-16 at 16:46 -0800, Darren Hart wrote:
> > On 1/16/15, 12:54 PM, "Michael Kerrisk (man-pages)"
> > wrote:
> >
> > >Color me stupid, but I can't see this in futex_requeue(). Where is that
> > >check that is "independent of the requeue
On Sat, 24 Jan 2015, Torvald Riegel wrote:
On Sat, 2015-01-24 at 11:05 +0100, Thomas Gleixner wrote:
On Fri, 23 Jan 2015, Torvald Riegel wrote:
On Fri, 2015-01-16 at 16:46 -0800, Darren Hart wrote:
On 1/16/15, 12:54 PM, Michael Kerrisk (man-pages)
mtk.manpa...@gmail.com wrote:
On Fri, 23 Jan 2015, Torvald Riegel wrote:
On Fri, 2015-01-16 at 16:46 -0800, Darren Hart wrote:
On 1/16/15, 12:54 PM, Michael Kerrisk (man-pages)
mtk.manpa...@gmail.com wrote:
Color me stupid, but I can't see this in futex_requeue(). Where is that
check that is independent of the
On Fri, 23 Jan 2015, Torvald Riegel wrote:
Second, the current documentation for EINTR is that it can happen due to
receiving a signal *or* due to a spurious wake-up. This is difficult to
I don't think so. I went through all callchains again with a fine comb.
futex_wait()
retry:
ret =
On Sat, 2015-01-24 at 11:05 +0100, Thomas Gleixner wrote:
On Fri, 23 Jan 2015, Torvald Riegel wrote:
On Fri, 2015-01-16 at 16:46 -0800, Darren Hart wrote:
On 1/16/15, 12:54 PM, Michael Kerrisk (man-pages)
mtk.manpa...@gmail.com wrote:
Color me stupid, but I can't see this in
On Sat, 2015-01-24 at 12:35 +0100, Thomas Gleixner wrote:
So we should never see -EINTR in the case of a spurious wakeup here.
But, here is the not so good news:
I did some archaeology. The restart handling of futex_wait() got
introduced in kernel 2.6.22, so anything older than that will
On Thu, 2015-01-15 at 16:10 +0100, Michael Kerrisk (man-pages) wrote:
> [Adding a few people to CC that have expressed interest in the
> progress of the updates of this page, or who may be able to
> provide review feedback. Eventually, you'll all get CCed on
> the new draft of the page.]
>
>
On Fri, 2015-01-16 at 16:46 -0800, Darren Hart wrote:
> On 1/16/15, 12:54 PM, "Michael Kerrisk (man-pages)"
> wrote:
>
> >Color me stupid, but I can't see this in futex_requeue(). Where is that
> >check that is "independent of the requeue type (normal/pi)"?
> >
> >When I look through
On Thu, 2015-01-15 at 16:10 +0100, Michael Kerrisk (man-pages) wrote:
[Adding a few people to CC that have expressed interest in the
progress of the updates of this page, or who may be able to
provide review feedback. Eventually, you'll all get CCed on
the new draft of the page.]
Hello
On Fri, 2015-01-16 at 16:46 -0800, Darren Hart wrote:
On 1/16/15, 12:54 PM, Michael Kerrisk (man-pages)
mtk.manpa...@gmail.com wrote:
Color me stupid, but I can't see this in futex_requeue(). Where is that
check that is independent of the requeue type (normal/pi)?
When I look through
On 01/19/2015 11:45 AM, Thomas Gleixner wrote:
> On Fri, 16 Jan 2015, Darren Hart wrote:
>> On 1/16/15, 12:54 PM, "Michael Kerrisk (man-pages)"
>> wrote:
>>
>>> On 01/16/2015 04:20 PM, Thomas Gleixner wrote:
On Fri, 16 Jan 2015, Michael Kerrisk (man-pages) wrote:
> Hello Thomas,
On Fri, 16 Jan 2015, Darren Hart wrote:
> On 1/16/15, 12:54 PM, "Michael Kerrisk (man-pages)"
> wrote:
>
> >On 01/16/2015 04:20 PM, Thomas Gleixner wrote:
> >> On Fri, 16 Jan 2015, Michael Kerrisk (man-pages) wrote:
> >>
> >>> Hello Thomas,
> >>>
> >>> On 01/15/2015 11:23 PM, Thomas Gleixner
On Fri, 16 Jan 2015, Darren Hart wrote:
On 1/16/15, 12:54 PM, Michael Kerrisk (man-pages)
mtk.manpa...@gmail.com wrote:
On 01/16/2015 04:20 PM, Thomas Gleixner wrote:
On Fri, 16 Jan 2015, Michael Kerrisk (man-pages) wrote:
Hello Thomas,
On 01/15/2015 11:23 PM, Thomas Gleixner
On 01/19/2015 11:45 AM, Thomas Gleixner wrote:
On Fri, 16 Jan 2015, Darren Hart wrote:
On 1/16/15, 12:54 PM, Michael Kerrisk (man-pages)
mtk.manpa...@gmail.com wrote:
On 01/16/2015 04:20 PM, Thomas Gleixner wrote:
On Fri, 16 Jan 2015, Michael Kerrisk (man-pages) wrote:
Hello Thomas,
On
Hello Darren,
On 01/17/2015 08:26 PM, Darren Hart wrote:
>
> On 1/17/15, 1:16 AM, "Michael Kerrisk (man-pages)"
> wrote:
[...]
In the meantime, I have a couple of questions, which, if
you could answer them, I would work some changes into the
page before sending.
1. In
Hello Darren,
On 01/17/2015 08:26 PM, Darren Hart wrote:
On 1/17/15, 1:16 AM, Michael Kerrisk (man-pages)
mtk.manpa...@gmail.com wrote:
[...]
In the meantime, I have a couple of questions, which, if
you could answer them, I would work some changes into the
page before sending.
1. In
On 1/17/15, 1:16 AM, "Michael Kerrisk (man-pages)"
wrote:
>Hello Darren,
>
>On 01/17/2015 02:33 AM, Darren Hart wrote:
>> Corrected Davidlohr's email address.
>
>Thanks!
>
>> On 1/15/15, 7:12 AM, "Michael Kerrisk (man-pages)"
>> wrote:
>>
>>> Hello Darren,
>>>
>>> I give you the same apology
Hello Darren,
On 01/17/2015 02:33 AM, Darren Hart wrote:
> Corrected Davidlohr's email address.
Thanks!
> On 1/15/15, 7:12 AM, "Michael Kerrisk (man-pages)"
> wrote:
>
>> Hello Darren,
>>
>> I give you the same apology as to Thomas for the
>> long-delayed response to your mail.
>>
>> And I
On 1/17/15, 1:16 AM, Michael Kerrisk (man-pages)
mtk.manpa...@gmail.com wrote:
Hello Darren,
On 01/17/2015 02:33 AM, Darren Hart wrote:
Corrected Davidlohr's email address.
Thanks!
On 1/15/15, 7:12 AM, Michael Kerrisk (man-pages)
mtk.manpa...@gmail.com wrote:
Hello Darren,
I give you
Hello Darren,
On 01/17/2015 02:33 AM, Darren Hart wrote:
Corrected Davidlohr's email address.
Thanks!
On 1/15/15, 7:12 AM, Michael Kerrisk (man-pages)
mtk.manpa...@gmail.com wrote:
Hello Darren,
I give you the same apology as to Thomas for the
long-delayed response to your mail.
And
Corrected Davidlohr's email address.
On 1/15/15, 7:12 AM, "Michael Kerrisk (man-pages)"
wrote:
>Hello Darren,
>
>I give you the same apology as to Thomas for the
>long-delayed response to your mail.
>
>And I repeat my note to Thomas:
>In the next day or two, I hope to send out the new version
On 1/16/15, 4:56 PM, "Davidlohr Bueso" wrote:
>On Fri, 2015-01-16 at 21:54 +0100, Michael Kerrisk (man-pages) wrote:
>> On 01/16/2015 04:20 PM, Thomas Gleixner wrote:
>> > On Fri, 16 Jan 2015, Michael Kerrisk (man-pages) wrote:
>> >
>> >> Hello Thomas,
>> >>
>> >> On 01/15/2015 11:23 PM,
On Fri, 2015-01-16 at 21:54 +0100, Michael Kerrisk (man-pages) wrote:
> On 01/16/2015 04:20 PM, Thomas Gleixner wrote:
> > On Fri, 16 Jan 2015, Michael Kerrisk (man-pages) wrote:
> >
> >> Hello Thomas,
> >>
> >> On 01/15/2015 11:23 PM, Thomas Gleixner wrote:
> >>> On Thu, 15 Jan 2015, Michael
On 1/16/15, 12:54 PM, "Michael Kerrisk (man-pages)"
wrote:
>On 01/16/2015 04:20 PM, Thomas Gleixner wrote:
>> On Fri, 16 Jan 2015, Michael Kerrisk (man-pages) wrote:
>>
>>> Hello Thomas,
>>>
>>> On 01/15/2015 11:23 PM, Thomas Gleixner wrote:
On Thu, 15 Jan 2015, Michael Kerrisk
On 01/16/2015 04:20 PM, Thomas Gleixner wrote:
> On Fri, 16 Jan 2015, Michael Kerrisk (man-pages) wrote:
>
>> Hello Thomas,
>>
>> On 01/15/2015 11:23 PM, Thomas Gleixner wrote:
>>> On Thu, 15 Jan 2015, Michael Kerrisk (man-pages) wrote:
> [EINVAL] uaddr equal uaddr2. Requeue to same futex.
On Fri, 16 Jan 2015, Michael Kerrisk (man-pages) wrote:
> Hello Thomas,
>
> On 01/15/2015 11:23 PM, Thomas Gleixner wrote:
> > On Thu, 15 Jan 2015, Michael Kerrisk (man-pages) wrote:
> >>> [EINVAL] uaddr equal uaddr2. Requeue to same futex.
> >>
> >> ??? I added this, but does this error not
Hello Thomas,
On 01/15/2015 11:23 PM, Thomas Gleixner wrote:
> On Thu, 15 Jan 2015, Michael Kerrisk (man-pages) wrote:
>>> [EINVAL] uaddr equal uaddr2. Requeue to same futex.
>>
>> ??? I added this, but does this error not occur only for PI requeues?
>
> It's equally wrong for normal futexes.
On 01/16/2015 04:20 PM, Thomas Gleixner wrote:
On Fri, 16 Jan 2015, Michael Kerrisk (man-pages) wrote:
Hello Thomas,
On 01/15/2015 11:23 PM, Thomas Gleixner wrote:
On Thu, 15 Jan 2015, Michael Kerrisk (man-pages) wrote:
[EINVAL] uaddr equal uaddr2. Requeue to same futex.
??? I added
On 1/16/15, 12:54 PM, Michael Kerrisk (man-pages)
mtk.manpa...@gmail.com wrote:
On 01/16/2015 04:20 PM, Thomas Gleixner wrote:
On Fri, 16 Jan 2015, Michael Kerrisk (man-pages) wrote:
Hello Thomas,
On 01/15/2015 11:23 PM, Thomas Gleixner wrote:
On Thu, 15 Jan 2015, Michael Kerrisk
On Fri, 2015-01-16 at 21:54 +0100, Michael Kerrisk (man-pages) wrote:
On 01/16/2015 04:20 PM, Thomas Gleixner wrote:
On Fri, 16 Jan 2015, Michael Kerrisk (man-pages) wrote:
Hello Thomas,
On 01/15/2015 11:23 PM, Thomas Gleixner wrote:
On Thu, 15 Jan 2015, Michael Kerrisk (man-pages)
On 1/16/15, 4:56 PM, Davidlohr Bueso d...@stgolabs.net wrote:
On Fri, 2015-01-16 at 21:54 +0100, Michael Kerrisk (man-pages) wrote:
On 01/16/2015 04:20 PM, Thomas Gleixner wrote:
On Fri, 16 Jan 2015, Michael Kerrisk (man-pages) wrote:
Hello Thomas,
On 01/15/2015 11:23 PM, Thomas
Corrected Davidlohr's email address.
On 1/15/15, 7:12 AM, Michael Kerrisk (man-pages)
mtk.manpa...@gmail.com wrote:
Hello Darren,
I give you the same apology as to Thomas for the
long-delayed response to your mail.
And I repeat my note to Thomas:
In the next day or two, I hope to send out the
Hello Thomas,
On 01/15/2015 11:23 PM, Thomas Gleixner wrote:
On Thu, 15 Jan 2015, Michael Kerrisk (man-pages) wrote:
[EINVAL] uaddr equal uaddr2. Requeue to same futex.
??? I added this, but does this error not occur only for PI requeues?
It's equally wrong for normal futexes. And its
On Fri, 16 Jan 2015, Michael Kerrisk (man-pages) wrote:
Hello Thomas,
On 01/15/2015 11:23 PM, Thomas Gleixner wrote:
On Thu, 15 Jan 2015, Michael Kerrisk (man-pages) wrote:
[EINVAL] uaddr equal uaddr2. Requeue to same futex.
??? I added this, but does this error not occur only for PI
On Thu, 15 Jan 2015, Michael Kerrisk (man-pages) wrote:
> > [EINVAL] uaddr equal uaddr2. Requeue to same futex.
>
> ??? I added this, but does this error not occur only for PI requeues?
It's equally wrong for normal futexes. And its actually the same code
checking for this for all variants.
> >
Hello Darren,
I give you the same apology as to Thomas for the
long-delayed response to your mail.
And I repeat my note to Thomas:
In the next day or two, I hope to send out the new version
of the futex(2) page for review. The new draft is a bit
bigger (okay -- 4 x bigger) than the current
[Adding a few people to CC that have expressed interest in the
progress of the updates of this page, or who may be able to
provide review feedback. Eventually, you'll all get CCed on
the new draft of the page.]
Hello Thomas,
On 05/15/2014 04:14 PM, Thomas Gleixner wrote:
> On Thu, 15 May 2014,
[Adding a few people to CC that have expressed interest in the
progress of the updates of this page, or who may be able to
provide review feedback. Eventually, you'll all get CCed on
the new draft of the page.]
Hello Thomas,
On 05/15/2014 04:14 PM, Thomas Gleixner wrote:
On Thu, 15 May 2014,
Hello Darren,
I give you the same apology as to Thomas for the
long-delayed response to your mail.
And I repeat my note to Thomas:
In the next day or two, I hope to send out the new version
of the futex(2) page for review. The new draft is a bit
bigger (okay -- 4 x bigger) than the current
On Thu, 15 Jan 2015, Michael Kerrisk (man-pages) wrote:
[EINVAL] uaddr equal uaddr2. Requeue to same futex.
??? I added this, but does this error not occur only for PI requeues?
It's equally wrong for normal futexes. And its actually the same code
checking for this for all variants.
Hi!
> >For this complexity of tests you would just need to call the tst_resm()
> >interface to report success/failure and, at the end of the test,
> >tst_exit() to return the stored overall test status.
> >
> >And ideally call the standard option parsing code and call the test in
> >standard loop
Hi!
For this complexity of tests you would just need to call the tst_resm()
interface to report success/failure and, at the end of the test,
tst_exit() to return the stored overall test status.
And ideally call the standard option parsing code and call the test in
standard loop so that the
Hi!
> >> How much LTP harness type code needs to be used?
> >
> >Not much.
> >
> >For this complexity of tests you would just need to call the tst_resm()
> >interface to report success/failure and, at the end of the test,
> >tst_exit() to return the stored overall test status.
> >
> >And ideally
Hi!
How much LTP harness type code needs to be used?
Not much.
For this complexity of tests you would just need to call the tst_resm()
interface to report success/failure and, at the end of the test,
tst_exit() to return the stored overall test status.
And ideally call the standard
On 05/15/2014 04:19 PM, Michael Kerrisk (man-pages) wrote:
> On 05/15/2014 04:14 PM, Thomas Gleixner wrote:
>> On Thu, 15 May 2014, Michael Kerrisk (man-pages) wrote:
>>> And that universe would love to have your documentation of
>>> FUTEX_WAKE_BITSET and FUTEX_WAIT_BITSET ;-),
>>
>> I give you
On 05/15/2014 04:19 PM, Michael Kerrisk (man-pages) wrote:
On 05/15/2014 04:14 PM, Thomas Gleixner wrote:
On Thu, 15 May 2014, Michael Kerrisk (man-pages) wrote:
And that universe would love to have your documentation of
FUTEX_WAKE_BITSET and FUTEX_WAIT_BITSET ;-),
I give you almost the full
On 5/15/14, 7:14, "Thomas Gleixner" wrote:
Wow Thomas, I planned to do exactly this and you beat me to it. Again.
Thanks for getting this started.
Michael, I imagine you want something more condensed, and I'll add to what
tglx posted (inline below) to try and get you that, but if you have
On 05/15/2014 04:14 PM, Thomas Gleixner wrote:
> On Thu, 15 May 2014, Michael Kerrisk (man-pages) wrote:
>> And that universe would love to have your documentation of
>> FUTEX_WAKE_BITSET and FUTEX_WAIT_BITSET ;-),
>
> I give you almost the full treatment, but I leave REQUEUE_PI to Darren
> and
On 5/15/14, 12:05, "chru...@suse.cz" wrote:
>Hi!
>> >> I've used LTP in the past (quite a bit), and I felt there was some
>> >> advantage to keeping futextest independent.
>> >
>> >What advantages did you have in mind?
>>
>> Not CVS was a big one at the time ;-)
>>
>> OK, I don't mean to be
On 05/14/2014 08:28 PM, H. Peter Anvin wrote:
> On 05/14/2014 01:56 PM, Davidlohr Bueso wrote:
>>>
However, unless I'm sorely mistaken, the larger problem is that glibc
removed the futex() call entirely, so these man pages don't describe
>>>
>>> I don't think futex() ever was in
Hi!
> >> I've used LTP in the past (quite a bit), and I felt there was some
> >> advantage to keeping futextest independent.
> >
> >What advantages did you have in mind?
>
> Not CVS was a big one at the time ;-)
>
> OK, I don't mean to be disparaging here... But since you asked, back in
> '09
On 5/15/14, 9:30, "chru...@suse.cz" wrote:
>Hi!
>> I've used LTP in the past (quite a bit), and I felt there was some
>> advantage to keeping futextest independent.
>
>What advantages did you have in mind?
Not CVS was a big one at the time ;-)
OK, I don't mean to be disparaging here... But
Hi!
> > That is not the main concern here. If I extract the code I would have to
> > watch for any changes manually. If it was in a library or a separate
> > repository all that would be needed is to add it as dependency/git
> > submodule and I would get all updates automatically.
> >
>
> Yes,
On 05/15/2014 09:17 AM, chru...@suse.cz wrote:
>>
>> It should be quite easy to extract from klibc.
>
> That is not the main concern here. If I extract the code I would have to
> watch for any changes manually. If it was in a library or a separate
> repository all that would be needed is to add
Hi!
> I've used LTP in the past (quite a bit), and I felt there was some
> advantage to keeping futextest independent.
What advantages did you have in mind?
> Perhaps things have changed enough since then (~2009 era) that we
> should reconsider.
I've been working on LTP for a about three years
Hi!
> >> I really believe the proper fix is to use assembly syscall stubs. In
> >> klibc I build a fairly elaborate machinery to autogenerate such syscall
> >> stubs for a variety of architectures.
> >
> > Then it would be nice to share these between klibc and LTP (and possible
> > everybody
On 5/15/14, 8:28, "chru...@suse.cz" wrote:
>Hi!
>>
>> However, unless I'm sorely mistaken, the larger problem is that glibc
>> removed the futex() call entirely, so these man pages don't describe
>> something users even have access to anymore. I had to revert to calling
>> the syscalls directly
On 05/15/2014 09:01 AM, chru...@suse.cz wrote:
>
>> I really believe the proper fix is to use assembly syscall stubs. In
>> klibc I build a fairly elaborate machinery to autogenerate such syscall
>> stubs for a variety of architectures.
>
> Then it would be nice to share these between klibc and
Hi!
> > Have a look at this commit that tries to deal with passing 64 bit
> > numbers to syscalls. On 32 bit ABI (but not on X32) these needs to be
> > split up (accordingly to machine endianity).
> >
> > https://github.com/linux-test-project/ltp/commit/04afb02b4280a20c262054e8f99a3fad4ad54916
>
On 05/15/2014 08:42 AM, chru...@suse.cz wrote:
> Hi!
>> People have a number of times noted that there are problems
>> with syscall(), but I'm not knowledgeable on the details.
>> I'd happily take a patch to the man page (which, for historical
>> reasons, is actually syscall(2)) that explains the
On 5/15/14, 1:13, "Peter Zijlstra" wrote:
>On Wed, May 14, 2014 at 04:23:38PM -0400, Carlos O'Donell wrote:
>> On 05/14/2014 03:03 PM, Michael Kerrisk (man-pages) wrote:
>> >> However, unless I'm sorely mistaken, the larger problem is that glibc
>> >> removed the futex() call entirely, so these
On 5/15/14, 6:46, "Michael Kerrisk (man-pages)"
wrote:
>On 05/15/2014 07:21 AM, Darren Hart wrote:
>> On 5/14/14, 17:18, "H. Peter Anvin" wrote:
>>
>>> On 05/14/2014 09:18 AM, Darren Hart wrote:
However, unless I'm sorely mistaken, the larger problem is that glibc
removed the
On Thu, 15 May 2014 17:28:35 +0200
chru...@suse.cz wrote:
> Hi!
> >
> > However, unless I'm sorely mistaken, the larger problem is that glibc
> > removed the futex() call entirely, so these man pages don't describe
> > something users even have access to anymore. I had to revert to calling
> >
Hi!
> People have a number of times noted that there are problems
> with syscall(), but I'm not knowledgeable on the details.
> I'd happily take a patch to the man page (which, for historical
> reasons, is actually syscall(2)) that explains the the problems
> (and ideally notes those platforms
Hi!
> > However, unless I'm sorely mistaken, the larger problem is that glibc
> > removed the futex() call entirely, so these man pages don't describe
> > something users even have access to anymore. I had to revert to calling
> > the syscalls directly in the futextest test suite because of this:
Hi!
>
> However, unless I'm sorely mistaken, the larger problem is that glibc
> removed the futex() call entirely, so these man pages don't describe
> something users even have access to anymore. I had to revert to calling
> the syscalls directly in the futextest test suite because of this:
>
>
On Wed, 14 May 2014, Davidlohr Bueso wrote:
> > If I'm wrong, or we can restore the futex() call, great. If not... Should
> > we keep the man-pages and document it as syscall(SYS_futex, ..., op, ...) ?
>
> +1, is there anything preventing adding a futex wrapper... glibc folks?
See what I said
On Thu, May 15, 2014 at 10:39:09AM -0400, Carlos O'Donell wrote:
> For example does gettid *really* return a pid_t as considered by
> userspace? It's not a full out process...
Yeah, PIDs and TIDs are the same namespace in the kernel. All we have
are tasks and each task has an id. gettid()
On 05/15/2014 06:46 AM, Michael Kerrisk (man-pages) wrote:
>
> People have a number of times noted that there are problems
> with syscall(), but I'm not knowledgeable on the details.
> I'd happily take a patch to the man page (which, for historical
> reasons, is actually syscall(2)) that explains
On 05/15/2014 09:49 AM, Michael Kerrisk (man-pages) wrote:
> On Thu, May 15, 2014 at 3:22 PM, Peter Zijlstra wrote:
>> On Thu, May 15, 2014 at 09:18:22AM -0400, Carlos O'Donell wrote:
>>> On 05/15/2014 04:14 AM, Peter Zijlstra wrote:
On Wed, May 14, 2014 at 04:23:38PM -0400, Carlos O'Donell
On Thu, 15 May 2014, Michael Kerrisk (man-pages) wrote:
> And that universe would love to have your documentation of
> FUTEX_WAKE_BITSET and FUTEX_WAIT_BITSET ;-),
I give you almost the full treatment, but I leave REQUEUE_PI to Darren
and FUTEX_WAKE_OP to Jakub. :)
FUTEX_WAIT
<
On Thu, May 15, 2014 at 03:49:10PM +0200, Michael Kerrisk (man-pages) wrote:
> On Thu, May 15, 2014 at 3:22 PM, Peter Zijlstra wrote:
> > On Thu, May 15, 2014 at 09:18:22AM -0400, Carlos O'Donell wrote:
> >> On 05/15/2014 04:14 AM, Peter Zijlstra wrote:
> >> > On Wed, May 14, 2014 at 04:23:38PM
On Thu, May 15, 2014 at 3:22 PM, Peter Zijlstra wrote:
> On Thu, May 15, 2014 at 09:18:22AM -0400, Carlos O'Donell wrote:
>> On 05/15/2014 04:14 AM, Peter Zijlstra wrote:
>> > On Wed, May 14, 2014 at 04:23:38PM -0400, Carlos O'Donell wrote:
>> >> There are other syscalls like gettid() that have
On 05/15/2014 07:21 AM, Darren Hart wrote:
> On 5/14/14, 17:18, "H. Peter Anvin" wrote:
>
>> On 05/14/2014 09:18 AM, Darren Hart wrote:
>>>
>>> However, unless I'm sorely mistaken, the larger problem is that glibc
>>> removed the futex() call entirely, so these man pages don't describe
>>>
On Thu, May 15, 2014 at 09:18:22AM -0400, Carlos O'Donell wrote:
> On 05/15/2014 04:14 AM, Peter Zijlstra wrote:
> > On Wed, May 14, 2014 at 04:23:38PM -0400, Carlos O'Donell wrote:
> >> There are other syscalls like gettid() that have a:
> >> NOTE: There is no glibc wrapper for this system call;
On 05/15/2014 04:14 AM, Peter Zijlstra wrote:
> On Wed, May 14, 2014 at 04:23:38PM -0400, Carlos O'Donell wrote:
>> There are other syscalls like gettid() that have a:
>> NOTE: There is no glibc wrapper for this system call; see NOTES.
>
> Yes, can we finally fix that please? It gets tedious
On Wed, May 14, 2014 at 10:21:52PM -0700, Darren Hart wrote:
> On 5/14/14, 17:18, "H. Peter Anvin" wrote:
>
> >On 05/14/2014 09:18 AM, Darren Hart wrote:
> >>
> >> However, unless I'm sorely mistaken, the larger problem is that glibc
> >> removed the futex() call entirely, so these man pages
On Wed, May 14, 2014 at 04:23:38PM -0400, Carlos O'Donell wrote:
> There are other syscalls like gettid() that have a:
> NOTE: There is no glibc wrapper for this system call; see NOTES.
Yes, can we finally fix that please? It gets tedious having to endlessly
copy/paste that thing around.
On Wed, May 14, 2014 at 04:23:38PM -0400, Carlos O'Donell wrote:
> On 05/14/2014 03:03 PM, Michael Kerrisk (man-pages) wrote:
> >> However, unless I'm sorely mistaken, the larger problem is that glibc
> >> removed the futex() call entirely, so these man pages don't describe
> >
> > I don't think
On Wed, May 14, 2014 at 04:23:38PM -0400, Carlos O'Donell wrote:
On 05/14/2014 03:03 PM, Michael Kerrisk (man-pages) wrote:
However, unless I'm sorely mistaken, the larger problem is that glibc
removed the futex() call entirely, so these man pages don't describe
I don't think futex()
On Wed, May 14, 2014 at 04:23:38PM -0400, Carlos O'Donell wrote:
There are other syscalls like gettid() that have a:
NOTE: There is no glibc wrapper for this system call; see NOTES.
Yes, can we finally fix that please? It gets tedious having to endlessly
copy/paste that thing around.
On Wed, May 14, 2014 at 10:21:52PM -0700, Darren Hart wrote:
On 5/14/14, 17:18, H. Peter Anvin h...@zytor.com wrote:
On 05/14/2014 09:18 AM, Darren Hart wrote:
However, unless I'm sorely mistaken, the larger problem is that glibc
removed the futex() call entirely, so these man pages
On 05/15/2014 04:14 AM, Peter Zijlstra wrote:
On Wed, May 14, 2014 at 04:23:38PM -0400, Carlos O'Donell wrote:
There are other syscalls like gettid() that have a:
NOTE: There is no glibc wrapper for this system call; see NOTES.
Yes, can we finally fix that please? It gets tedious having to
On Thu, May 15, 2014 at 09:18:22AM -0400, Carlos O'Donell wrote:
On 05/15/2014 04:14 AM, Peter Zijlstra wrote:
On Wed, May 14, 2014 at 04:23:38PM -0400, Carlos O'Donell wrote:
There are other syscalls like gettid() that have a:
NOTE: There is no glibc wrapper for this system call; see
On 05/15/2014 07:21 AM, Darren Hart wrote:
On 5/14/14, 17:18, H. Peter Anvin h...@zytor.com wrote:
On 05/14/2014 09:18 AM, Darren Hart wrote:
However, unless I'm sorely mistaken, the larger problem is that glibc
removed the futex() call entirely, so these man pages don't describe
something
On Thu, May 15, 2014 at 3:22 PM, Peter Zijlstra pet...@infradead.org wrote:
On Thu, May 15, 2014 at 09:18:22AM -0400, Carlos O'Donell wrote:
On 05/15/2014 04:14 AM, Peter Zijlstra wrote:
On Wed, May 14, 2014 at 04:23:38PM -0400, Carlos O'Donell wrote:
There are other syscalls like gettid()
On Thu, May 15, 2014 at 03:49:10PM +0200, Michael Kerrisk (man-pages) wrote:
On Thu, May 15, 2014 at 3:22 PM, Peter Zijlstra pet...@infradead.org wrote:
On Thu, May 15, 2014 at 09:18:22AM -0400, Carlos O'Donell wrote:
On 05/15/2014 04:14 AM, Peter Zijlstra wrote:
On Wed, May 14, 2014 at
On Thu, 15 May 2014, Michael Kerrisk (man-pages) wrote:
And that universe would love to have your documentation of
FUTEX_WAKE_BITSET and FUTEX_WAIT_BITSET ;-),
I give you almost the full treatment, but I leave REQUEUE_PI to Darren
and FUTEX_WAKE_OP to Jakub. :)
FUTEX_WAIT
Existing
On 05/15/2014 09:49 AM, Michael Kerrisk (man-pages) wrote:
On Thu, May 15, 2014 at 3:22 PM, Peter Zijlstra pet...@infradead.org wrote:
On Thu, May 15, 2014 at 09:18:22AM -0400, Carlos O'Donell wrote:
On 05/15/2014 04:14 AM, Peter Zijlstra wrote:
On Wed, May 14, 2014 at 04:23:38PM -0400, Carlos
On 05/15/2014 06:46 AM, Michael Kerrisk (man-pages) wrote:
People have a number of times noted that there are problems
with syscall(), but I'm not knowledgeable on the details.
I'd happily take a patch to the man page (which, for historical
reasons, is actually syscall(2)) that explains the
1 - 100 of 159 matches
Mail list logo
