On Tue, 4 Dec 2007, Steven Rostedt wrote:
>
> Since arg3 is out, which do you prefer? Creating an arg4 (and perhaps
> more) in the block or having a u64 arg? Changing all the args to u64 may
> be the best.
I suspect that the best option is probably to make that thing a unnamed
union of the ac
On Tue, 4 Dec 2007, Linus Torvalds wrote:
> On Tue, 4 Dec 2007, Steven Rostedt wrote:
> >
> > Seems that arg3 is not used here and since the timer is 64 bits, we can
> > store the bottom 32 bits in arg2 and the top in arg3 (this will work for
> > both 32 and 64 bit archs).
>
> Yes. That should wo
On Tue, 4 Dec 2007, Steven Rostedt wrote:
>
> Seems that arg3 is not used here and since the timer is 64 bits, we can
> store the bottom 32 bits in arg2 and the top in arg3 (this will work for
> both 32 and 64 bit archs).
Yes. That should work fine.
The restart logic sometimes results in odd c
On Tue, Dec 04, 2007 at 01:09:36PM -0800, Linus Torvalds wrote:
>
>
> On Tue, 4 Dec 2007, Steven Rostedt wrote:
> >
> > The solution I did to solve this is to allocate a temporary buffer when
> > setting up the block and free it in futex_wait_restart. This patch
> > allows David's test program to
On Tue, 4 Dec 2007, Steven Rostedt wrote:
>
> The solution I did to solve this is to allocate a temporary buffer when
> setting up the block and free it in futex_wait_restart. This patch
> allows David's test program to actually pass.
No. Unacceptable. This is a memory leak in case nobody retrie
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 pth
6 matches
Mail list logo
