Re: [PATCH 0/2] Was: introduce suppress_sigtrap() to prevent unwanted send_sigtrap()

2009-11-10 Thread Oleg Nesterov
Ugh. I sent the patches before I checked email. On 11/10, Roland McGrath wrote: Oh... this adds more naming problems. And this way x86's send_sigtrap() can't use this helper easily. It's true. Another approach would be to genericize send_sigtrap so that all arch's can use it, and call

Re: [PATCH 0/2] Was: introduce suppress_sigtrap() to prevent unwanted send_sigtrap()

2009-11-10 Thread Roland McGrath
But syscall_trace_leave() uses TRAP_BRKPT on x86. Should I change 4/5 ? Oh, I was sloppy in checking the values this time. Then probably the default TRAP_SINGLE_STEP should be 0 instead just to make clear that every arch needs to define it. But your other way is fine instead too. The new

Re: [PATCH 0/2] Was: introduce suppress_sigtrap() to prevent unwanted send_sigtrap()

2009-11-09 Thread Roland McGrath
OK, how about these 2 simple patches for upstream? Then we can change powerpc, etc. Perhaps, instead of arch_has_fill_sigtrap_info we can start with the patch below? Since tracehook_report_syscall_exit() is inline we can can add the if (step) code without ifdef's. I don't understand the

Re: [PATCH 0/2] Was: introduce suppress_sigtrap() to prevent unwanted send_sigtrap()

2009-11-09 Thread Oleg Nesterov
On 11/09, Roland McGrath wrote: OK, how about these 2 simple patches for upstream? Then we can change powerpc, etc. Perhaps, instead of arch_has_fill_sigtrap_info we can start with the patch below? Since tracehook_report_syscall_exit() is inline we can can add the if (step) code

[PATCH 0/2] Was: introduce suppress_sigtrap() to prevent unwanted send_sigtrap()

2009-11-08 Thread Oleg Nesterov
On 11/06, Roland McGrath wrote: All that part does is move all decisions about what to do into the tracehook/utrace/ptrace layers out of arch code. ... After the arch/tracehook cleanup we've been discussing, what happens here is consistent across machines. Yes, agreed. Just I greatly