Re: [PATCH 24-27] initial stop/resume changes

2009-09-09 Thread Roland McGrath
I merged it all. But I tend to think the function pointer is overkill. It's probably simpler and cleaner in the end to just store PTRACE_EVENT_* and have a switch, or something like that. Thanks, Roland

Re: [PATCH 4/4] utrace_release_task: check REAP before utrace_reap()

2009-09-09 Thread Roland McGrath
I think we can do this optimization, but see below. Nice work! I've merged it all. Thanks, Roland

Re: [PATCH 2/4] utrace_reap: do not play with -reporting

2009-09-09 Thread Roland McGrath
1. Can't we set -reporting _after_ checking engine-flags ? (unlikely) I'm not sure...it is early the morning again. ;-) 2. Is utrace_barrier() correct Note the example above, it assumes that utrace_barrier() itself is the barrier wrt reporting.

[PATCH 28] ptrace_report_syscall_exit: return UTRACE_STOP, not UTRACE_RESUME

2009-09-09 Thread Oleg Nesterov
Can't resist, I am sending this as a separate patch. Because I spent 3 hours debugging, and because the number and the ordering of these changes doesn't matter. As I said, I know that these initial changes of stop/resume model need fixes, but I don't understand some failures. Will test/debug

Re: [PATCH 24-27] initial stop/resume changes

2009-09-09 Thread Oleg Nesterov
On 09/09, Roland McGrath wrote: But I tend to think the function pointer is overkill. Yes, agreed. As I said, this code will be re-factored anyway. I added this pointer just because it is a bit easier to me to start the changes this way, currently I do not have the precise plan. Oleg.