On 02/17, Andres Freund wrote:
>
> Could this patch please be picked up? I very regularly hit the problems
> caused due to this in gdb (just single step out of a system call that
> returns due to EINTR to reproduce and then single step some more...).
>
> I've first spent an embarassing amount of
On 02/17, Andres Freund wrote:
Could this patch please be picked up? I very regularly hit the problems
caused due to this in gdb (just single step out of a system call that
returns due to EINTR to reproduce and then single step some more...).
I've first spent an embarassing amount of time
Hi,
Could this patch please be picked up? I very regularly hit the problems
caused due to this in gdb (just single step out of a system call that
returns due to EINTR to reproduce and then single step some more...).
I've first spent an embarassing amount of time trying to figure out
what's
Hi,
Could this patch please be picked up? I very regularly hit the problems
caused due to this in gdb (just single step out of a system call that
returns due to EINTR to reproduce and then single step some more...).
I've first spent an embarassing amount of time trying to figure out
what's
ping ;)
Should I resend? This fixes the real (although not that serious) bug
and nobody objected.
On 11/03, Oleg Nesterov wrote:
>
> When the TIF_SINGLESTEP tracee dequeues a signal, handle_signal()
> clears TIF_FORCED_TF and X86_EFLAGS_TF but leaves TIF_SINGLESTEP set.
>
> If the tracer does
ping ;)
Should I resend? This fixes the real (although not that serious) bug
and nobody objected.
On 11/03, Oleg Nesterov wrote:
When the TIF_SINGLESTEP tracee dequeues a signal, handle_signal()
clears TIF_FORCED_TF and X86_EFLAGS_TF but leaves TIF_SINGLESTEP set.
If the tracer does
On 11/04/2014 11:55 PM, Oleg Nesterov wrote:
> On 11/03, Pedro Alves wrote:
>>
>> Thanks a lot Oleg.
>
> thanks for the detailed report ;)
>
>> Question - shouldn't ptrace tests be put in
>> tools/testing/selftests/ptrace/ in the kernel tree nowadays?
>
> Oh, I do not know. Personally I am not
On 11/04/2014 11:55 PM, Oleg Nesterov wrote:
On 11/03, Pedro Alves wrote:
Thanks a lot Oleg.
thanks for the detailed report ;)
Question - shouldn't ptrace tests be put in
tools/testing/selftests/ptrace/ in the kernel tree nowadays?
Oh, I do not know. Personally I am not sure that
On 11/03, Pedro Alves wrote:
>
> Thanks a lot Oleg.
thanks for the detailed report ;)
> Question - shouldn't ptrace tests be put in
> tools/testing/selftests/ptrace/ in the kernel tree nowadays?
Oh, I do not know. Personally I am not sure that selftests/ptrace/
makes sense and I did not even
On 11/03, Pedro Alves wrote:
Thanks a lot Oleg.
thanks for the detailed report ;)
Question - shouldn't ptrace tests be put in
tools/testing/selftests/ptrace/ in the kernel tree nowadays?
Oh, I do not know. Personally I am not sure that selftests/ptrace/
makes sense and I did not even know
Thanks a lot Oleg.
Question - shouldn't ptrace tests be put in
tools/testing/selftests/ptrace/ in the kernel tree nowadays?
Thanks,
Pedro Alves
On 11/03/2014 08:13 PM, Oleg Nesterov wrote:
> When the TIF_SINGLESTEP tracee dequeues a signal, handle_signal()
> clears TIF_FORCED_TF and
When the TIF_SINGLESTEP tracee dequeues a signal, handle_signal()
clears TIF_FORCED_TF and X86_EFLAGS_TF but leaves TIF_SINGLESTEP set.
If the tracer does PTRACE_SINGLESTEP again, enable_single_step() sets
X86_EFLAGS_TF but not TIF_FORCED_TF. This means that the subsequent
PTRACE_CONT doesn't not
When the TIF_SINGLESTEP tracee dequeues a signal, handle_signal()
clears TIF_FORCED_TF and X86_EFLAGS_TF but leaves TIF_SINGLESTEP set.
If the tracer does PTRACE_SINGLESTEP again, enable_single_step() sets
X86_EFLAGS_TF but not TIF_FORCED_TF. This means that the subsequent
PTRACE_CONT doesn't not
Thanks a lot Oleg.
Question - shouldn't ptrace tests be put in
tools/testing/selftests/ptrace/ in the kernel tree nowadays?
Thanks,
Pedro Alves
On 11/03/2014 08:13 PM, Oleg Nesterov wrote:
When the TIF_SINGLESTEP tracee dequeues a signal, handle_signal()
clears TIF_FORCED_TF and X86_EFLAGS_TF
14 matches
Mail list logo