Re: [PATCH] Fix x86_64 TIF_SYSCALL_TRACE race in entry.S

2007-10-28 Thread Mathieu Desnoyers
* Andi Kleen ([EMAIL PROTECTED]) wrote: > > Setting the thread flag being an atomic operation, I would expect > > setting/clearing it asynchronously from another thread to be a valid > > It could be a very short stop. Also do you start kernel tracing that often? > It's not a matter of how often

Re: [PATCH] Fix x86_64 TIF_SYSCALL_TRACE race in entry.S

2007-10-28 Thread Andi Kleen
> Setting the thread flag being an atomic operation, I would expect > setting/clearing it asynchronously from another thread to be a valid It could be a very short stop. Also do you start kernel tracing that often? > Here is a modified version where I add my test only in the path where we > know

Re: [PATCH] Fix x86_64 TIF_SYSCALL_TRACE race in entry.S

2007-10-28 Thread Mathieu Desnoyers
* Andi Kleen ([EMAIL PROTECTED]) wrote: > Mathieu Desnoyers <[EMAIL PROTECTED]> writes: > > > We make sure that the thread flag read is coherent between our new test and > > the ALLWORK_MASK test by first saving it in a register used for both > > comparisons. > > > > That doesn't make sense. If

Re: [PATCH] Fix x86_64 TIF_SYSCALL_TRACE race in entry.S

2007-10-27 Thread Andi Kleen
Mathieu Desnoyers <[EMAIL PROTECTED]> writes: > We make sure that the thread flag read is coherent between our new test and > the ALLWORK_MASK test by first saving it in a register used for both > comparisons. > That doesn't make sense. If someone is setting those asynchronously you can always

[PATCH] Fix x86_64 TIF_SYSCALL_TRACE race in entry.S

2007-10-27 Thread Mathieu Desnoyers
Fix x86_64 TIF_SYSCALL_TRACE race in entry.S When the flag is inactive upon syscall entry and concurrently activated before exit, we seem to reach a state where the top of stack is incorrect upon return to user space. Fix this by fixing the top of stack and jumping to int_ret_from_sys_call if we