* Thomas Gleixner <[EMAIL PROTECTED]> wrote:
> Just a minor nit. Can we please use "futex" instead of "fu" ? I'm just
> envisioning the next union member named "ba".
>
> Acked-by: Thomas Gleixner <[EMAIL PROTECTED]>
>
> Please apply with the s/fu/futex/ change. This needs to go into stable
>
* Thomas Gleixner [EMAIL PROTECTED] wrote:
Just a minor nit. Can we please use futex instead of fu ? I'm just
envisioning the next union member named ba.
Acked-by: Thomas Gleixner [EMAIL PROTECTED]
Please apply with the s/fu/futex/ change. This needs to go into stable
.22/.23 as well.
Thanks for clarifying that Linus.
Regards,
David Holmes
Linus Torvalds said the following on 5/12/07 04:06 PM:
On Wed, 5 Dec 2007, David Holmes - Sun Microsystems wrote:
While this was observed with process control signals, my concern was that
other signals might cause
On Wed, 5 Dec 2007, David Holmes - Sun Microsystems wrote:
>
> While this was observed with process control signals, my concern was that
> other signals might cause pthread_cond_timedwait to return immediately in the
> same way. The test program allows for SIGUSR1 and SIGRTMIN testing as well,
On Tue, 4 Dec 2007, Linus Torvalds wrote:
>
> Patch looks fine to me.
>
> On Tue, 4 Dec 2007, Steven Rostedt wrote:
> >
> > Note: I'm a bit nervious to add "linux/types.h" and use u32 and u64
> > in thread_info.h, when there's a #ifdef __KERNEL__ just below that.
> > Not sure what that is there
Linus Torvalds said the following on 5/12/07 01:41 PM:
So here's a question for David Holmes: What caused you to actually notice
this behaviour? Can this actually be seen in real life usage?
We observed an application "hang" that turned out to be caused by a
clock mismatch between that used
On Tue, 4 Dec 2007, Randy Dunlap wrote:
>
> Steve/David,
>
> where can I find the test case, please?
David attached it to the RH Bugzilla:
https://bugzilla.redhat.com/show_bug.cgi?id=408321
-- Steve
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a
On Tue, 4 Dec 2007 19:41:32 -0800 (PST) Linus Torvalds wrote:
>
> Patch looks fine to me.
>
> On Tue, 4 Dec 2007, Steven Rostedt wrote:
> >
> > Note: I'm a bit nervious to add "linux/types.h" and use u32 and u64
> > in thread_info.h, when there's a #ifdef __KERNEL__ just below that.
> > Not
Patch looks fine to me.
On Tue, 4 Dec 2007, Steven Rostedt wrote:
>
> Note: I'm a bit nervious to add "linux/types.h" and use u32 and u64
> in thread_info.h, when there's a #ifdef __KERNEL__ just below that.
> Not sure what that is there for.
Hmm. I'd not expect user-mode headers to ever
David Holmes found a bug in the RT patch with respect to
pthread_cond_timedwait. After trying his test program on the latest git
from mainline, I found the bug was there too. The bug he was seeing
that his test program showed, was that if one were to do a "Ctrl-Z" on a
process that was in the
David Holmes found a bug in the RT patch with respect to
pthread_cond_timedwait. After trying his test program on the latest git
from mainline, I found the bug was there too. The bug he was seeing
that his test program showed, was that if one were to do a Ctrl-Z on a
process that was in the
Patch looks fine to me.
On Tue, 4 Dec 2007, Steven Rostedt wrote:
Note: I'm a bit nervious to add linux/types.h and use u32 and u64
in thread_info.h, when there's a #ifdef __KERNEL__ just below that.
Not sure what that is there for.
Hmm. I'd not expect user-mode headers to ever include
On Tue, 4 Dec 2007 19:41:32 -0800 (PST) Linus Torvalds wrote:
Patch looks fine to me.
On Tue, 4 Dec 2007, Steven Rostedt wrote:
Note: I'm a bit nervious to add linux/types.h and use u32 and u64
in thread_info.h, when there's a #ifdef __KERNEL__ just below that.
Not sure what that
On Tue, 4 Dec 2007, Randy Dunlap wrote:
Steve/David,
where can I find the test case, please?
David attached it to the RH Bugzilla:
https://bugzilla.redhat.com/show_bug.cgi?id=408321
-- Steve
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message
Linus Torvalds said the following on 5/12/07 01:41 PM:
So here's a question for David Holmes: What caused you to actually notice
this behaviour? Can this actually be seen in real life usage?
We observed an application hang that turned out to be caused by a
clock mismatch between that used
On Tue, 4 Dec 2007, Linus Torvalds wrote:
Patch looks fine to me.
On Tue, 4 Dec 2007, Steven Rostedt wrote:
Note: I'm a bit nervious to add linux/types.h and use u32 and u64
in thread_info.h, when there's a #ifdef __KERNEL__ just below that.
Not sure what that is there for.
Hmm.
On Wed, 5 Dec 2007, David Holmes - Sun Microsystems wrote:
While this was observed with process control signals, my concern was that
other signals might cause pthread_cond_timedwait to return immediately in the
same way. The test program allows for SIGUSR1 and SIGRTMIN testing as well,
but
Thanks for clarifying that Linus.
Regards,
David Holmes
Linus Torvalds said the following on 5/12/07 04:06 PM:
On Wed, 5 Dec 2007, David Holmes - Sun Microsystems wrote:
While this was observed with process control signals, my concern was that
other signals might cause
18 matches
Mail list logo
