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 (but I bet utrace-cleanup adds more problems which I don't understand yet), and the patch below "fixes" utrace.c (without utrace-cleanup applied). Cough. I guess you want to know why I didn't notice this before. Because the code in my utrace.c didn't match the code in your utrace-ptrace branch. How did this happen? I added some hacks to utrace.c for debugging purposes. In particular, I added the code to track engine alloc/free, and added the dirty hack to fix "access_process_vm() under spinlock" bug. And some more changes. But! I do not remember how, why and when the code below was added to utrace_attach_task() in my tree. I guess it was the temporary debugging change which I forgot to revert later. Will continue tomorrow. Oleg. --- OOPS/kernel/utrace.c~TTF 2009-11-15 03:48:09.000000000 +0100 +++ OOPS/kernel/utrace.c 2009-11-15 03:52:47.000000000 +0100 @@ -180,6 +180,10 @@ static int utrace_add_engine(struct task * notified about the event that precipitated its own * creation. This is not what the user wants. */ + +utrace->report = 1; +set_notify_resume(target); + list_add_tail(&engine->entry, &utrace->attaching); utrace->pending_attach = 1; ret = 0;