On 11/15, Oleg Nesterov wrote: > > On 11/13, Oleg Nesterov wrote: > > > > Roland, I pulled the last changes in your tree (utrace-cleanup merged > > in utrace-ptrace) and did some testing. > > > > In short: utrace-ptrace does not work at all. > > > > It fails a lot (if not most) of tests, in particular > > sa-resethand-on-cont-signal hangs and clone-multi-ptrace silently > > crashes the kernel. > > > > The quick investigation didn't help, utrace.c has too much changes, > > I will read the code tomorrow from the very beginning. > > Ooooooooooooohhhhhhhhh. > > In short, the code in utrace.c was broken even before utrace-cleanup > was merged
And your current tree has the same problem: utrace_attach_task() sets ->pending_attach, but utrace_get_signal() can miss it and dequeue/report a signal without splice_attaching(). Change utrace_get_signal() to check ->pending_attach. I do not understand the new code yet, I am not sure this patch is optimal. But it helps, the kernel doesn't crash/hang any longer. We still have problems, 5 tests fail. Some failures are expected, we know that the changes in utrace-cleanup must break the stepping logic in ptrace (to remind you just in case, utrace_control(STEP) doesn't call enable_step() synchronously). Some are not, ptrace_event_clone for example. Signed-off-by: Oleg Nesterov <o...@redhat.com> --- kernel/utrace.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) --- UTRACE-PTRACE/kernel/utrace.c~UTRACE_ATTACH_SIGNAL_RACE 2009-11-13 18:00:06.000000000 +0100 +++ UTRACE-PTRACE/kernel/utrace.c 2009-11-15 19:52:29.000000000 +0100 @@ -1955,7 +1955,8 @@ int utrace_get_signal(struct task_struct int signr; utrace = task_utrace_struct(task); - if (utrace->resume < UTRACE_RESUME || utrace->signal_handler) { + if (utrace->resume < UTRACE_RESUME || + utrace->pending_attach || utrace->signal_handler) { enum utrace_resume_action resume; /*